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

Re: Recode to Play MP3?

bieling@terra.es wrote:

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)


No, it was just a general point related to "available RAM" on a II.


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


Removing the indirection only saves 1 cycle per STA--the indirect STA
is only 2 bytes long.


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


And since the "gain" from removing the indirection is only 256 cycles,
I think we've established that this is not a win unless more than one
block is being transferred.


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.


Sounds reasonable.

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