[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Recode to Play MP3?

bieling@terra.es wrote:

On 22 mayo, 18:49, biel...@terra.es wrote:


A way to be sure that the code is accelerated would be to relocate a
copy of it into main RAM, and use it instead for the transfers.




Also, if the code is relocated to RAM, it could also be tweaked a bit
(self-modifying code) in order to gain even some more cycles by
removing the indirections :

loop2   lda  ATADataLow,x (4 cycles)
   sta  IOBuffer,y (4 cycles)
   iny  (2 cycles)
   lda  ATADataHigh,x  (4 cycles)
   sta  IOBuffer,y  (4 cycles)
   iny  (2 cycles)
   bne  rLoop  (branch taken, 3 cycles)

One interation gets 2 bytes and takes 23 cycles, or 11.5 cycles per
byte, or 86.95 KB/s/MHz.

Unrolling it just a little bit :

loop2   lda  ATADataLow,x (4 cycles)
   sta  IOBuffer,y (4 cycles)
   iny  (2 cycles)
   lda  ATADataHigh,x  (4 cycles)
   sta  IOBuffer,y  (4 cycles)
   iny  (2 cycles)
   lda  ATADataLow,x (4 cycles)
   sta  IOBuffer,y (4 cycles)
   iny  (2 cycles)
   lda  ATADataHigh,x  (4 cycles)
   sta  IOBuffer,y  (4 cycles)
   iny  (2 cycles)
   bne  rLoop  (branch taken, 3 cycles)

Would give you 43/4 = 10.75 cycles/byte -->> 93.02 KB/s/MHz.


Even better would be writing data blocks "interleaved" on the CF card,
and reading them back while "deinterleaving" to two successive pages.

This would require two indirect addresses (if executed from ROM), but
would delete one INY from the loop and move 512 bytes per complete loop
execution.  The net improvement is the same as moving the non-unrolled
2-byte loop to RAM.

Of course, storing the data interleaved would complicate life slightly
for CiderPress...  ;-)  All utilties that access the card using CFFA
firmware would be fine.

This gets the data rate fast enough that I doubt that moving the code
to RAM is worth the trouble--remember, there *isn't* any "free RAM"
on an Apple II that doesn't run GSOS--and GSOS already has the benefit
of a CFFA driver that can do all these tricks if anyone cares.

If you *really* want to run it from RAM, then you'd have to move the
loop body to the stack (assuming that the stack has enough free space,
and that you do enough logic to ensure that the free space doesn't
"wrap" page 1).  Alternatively, stack "alignment" could be ignored
by running the code elsewhere (like page 0), with space saved to and
restored from the stack.

This would be a net loss for single block reads, but for larger ranges
would be a win.


Unrolling it completely would give you 10 cycles/byte or 100KB/s/MHz.


And clearly too big and past the point of diminishing returns--best not
to get greedy.  ;-)


All of the above without an accelerator.


If you want the benefits of an accelerator, the move loop (for both
reading and writing) should be put into the Csxx space of the CFFA,
and some of the less important initialization code moved up to the
$C800..$CFFE space.

In looking briefly at the CFFA firmware, it's clear that this was
not a consideration in laying out the code.


2 of the (about) 11 cycles per byte must be slow, non-accelerated 1000
nS memory cycles. A 4x accelerator could very likely manage to execute
the remaining 9 cycles in 3 1000ns cycles. That would translate to a
rate of 5 cycles/byte or 200KB/s. Or more than a floppy a second !
And although I'm not 100% sure I don't think that reading so fast
would be a problem for the flash card.


A "1x" card is 150kB/sec, and most cards are now substantially faster
than that, so I doubt the card would be a limiting factor.

-michael

NadaNet file server for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."