Re: Recode to Play MP3?

[bieling@terra.es]

> >>>biel...@terra.es wrote:
> >>>>I'm not sure that an accelerator will cache the c800.cfff range
>
> >>Steven Hirsch wrote:
> >>>The ZipChip (II/IIe) certainly does not, since it's not smart enough to
> >>>know when or whether that region has been switched out underneath it.  
> >>>To work around that, you can clone the transfer loop into the stack page
> >>>and run it full-clip from there.
>
> >>"Michael J. Mahon" <mjma...@aol.com> wrote:
> >>Which, for me, raises the question of what "high water marks" are for
> >>the stack under various conditions...
>
> >>It would be easy enough to do the experiment by initializing the stack
> >>to an obvious mark byte, but I've never seen any studies that would
> >>suggest how much of page 1 can be considered "free" at, say, ProDOS READ
> >>or WRITE time.
>
> >>I'd begin to get uncomfortable around 32 bytes...
>
> >biel...@terra.es wrote:
> > What about the keyboard buffer ?
> > IIRC sometimes it's used for things like that.
> > Probably by the time the disk xfers start, the keyboard buffer has
> > been scanned already, and probably the keyboard won't be polled again
> > until after the xfers have taken place... ?

On May 26, 4:09 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
> Good point.  ProDOS already appropriated the second half of page 2
> for a pathname buffer (which is probably also free at the time of
> data transfer--unless error handling uses it).
>

But we've found already that this is not needed to make the CFFA's
sector-read code "accelerator-able".
To make it "accelerator-able", moving the code to IOSelect space is
enough.
Is the goal to remove the indirections then ? (I think so)

What gains do we expect to realize with this ?

GAINS : 2 cycles/byte (by removing the STAs indirections) in a 256
bytes xfer -->> 512 cycles

COST : overhead for copying ~17 bytes of code to RAM. The code to do
it is :

LDY#17 (2, but does not count, as it replaces an LDY#$0 in the
unmodified code)

loop :
LDA source,Y (4)
STA dest,Y (5)
DEY (2)
BNE loop (2 not taken, 3 taken)

JSR (6) + RTS (6) (don't count, also present if moved to IOSelect
space)

(17*(4+5+2+3))-1 = 237 cycles.

This won't put the right code in RAM : still the STAs,Y operand
addresses have to be "tweaked"... so:

+ the time to "correct" the STAs in the xfer-loop (some tens of cycles
more).

Therefore, the gain is going to be of about or less than a cycle/
byte...

I'd say that's too much mess for a small gain, and comes with a risk
of breaking code elsewhere. I'd prefer to run the xfer code from
IOSelect space, "4-unrolled" if possible.

--Jorge.