Re: Recode to Play MP3?

[bieling@terra.es]

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.

I'm not sure that an accelerator will cache the c800.cfff range, I
think it won't, 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.

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.

--Jorge.