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

Re: Recode to Play MP3?

bieling@terra.es wrote:

On May 21, 5:45 am, mdj <mdj....@gmail.com> wrote:


I wonder how much extra hardware would need to be added to the CFFA to
get a dramatic improvement? I would suspect that adding a 512 byte
buffer and implementing the IDE/ATA readblock/writeblock in hardware
would eliminate a lot of round-trip-sync delay, but I don't know if
the PLD on the CFFA has sufficient gates for something like this.




That's the code the CFFA uses to read a block:

rLoop:
   lda  ATAStatus,x  (4 cycles)
   bmi  rLoop  (branch not taken, 2 cycles)
   and  #$08   (2 cycles)
   beq  rShort (branch not taken, 2 cycles)

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

A single iteration of the loop takes 4+2+2+2+4+6+2+4+6+2+3=37 cycles,
and it gets 2 bytes, therefore the rate is 18,5 cycles per byte, or
5.5% of the memory bandwidth, or 55KB/s/MHz.

If you assume that the flash card is faster than the Apple II, then
you could change BNE rLoop to BNE loop2, and the rate would become :
4+6+2+4+6+2+3 = 27 cycles every 2 bytes, or 13.5 cycles per byte, or
7.4% of the memory bandwidth, or about 74 KB/s/Mhz.

Going from 5.5% to 7.4% is a 34% speedup.
And almost 20Kb/s more.


That would be a significant improvement, and it would be interesting
to determine what actual bounds on access time from the card exist.
I suspect that most current cards would allow this change, particularly
for 512-byte (non-flash-page-crossing) transfers.


I'm not sure that an accelerator will cache the c800.cfff range, I
think it won't,


An accelerator could detect the $CFFF/IOSTROBE protocol and invalidate
that tag range when necessary, but it would be tricky.  I expect that
accelerators simply don't cache the I/O expansion ROM space.

That's a *very* good argument for moving copy loops down into the
primary slot ROM space where they could be accelerated.


anyway, both the reads (LDAs) and the writes must be
performed at slow non-accelerated speeds, the reads because they come
from i/o space, the writes (STAs) because the cache is writethrough.
That leaves just the INYs and the branch to be accelerated, and then
only if the code at c800.cfff is being cached, and I wouldn't be sure.


Only the data accesses--one cycle per LDA/STA--would need to run slow,
(the LDA because of a guaranteed cache miss and the STA because of
writethrough), but most of the time is fetch time, and that would all
be cached.


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.


Slot ROM is easier (since there isn't any "scratch" main RAM).

-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."