Steven Hirsch wrote:
Michael J. Mahon 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 pageand 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...Actually, as coded in the hacked Ramfast driver it checks the stack pointer to ensure sufficient space before copying in the transfer loop (which is self-modifying code to save cycles). It is not left in-place, but copied freshly prior to every IO operation. Possibly it's not really a net win, but with an 8Mhz. ZipChip it sure _felt_ faster.
I didn't expect it to expect it to stay intact, but I was wondering about what assumptions are valid regarding extent of the *stack* data. This is further complicated by various chunks of code "assuming" that they can push tens of bytes onto the stack without overflow...
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.Doesn't that require hardware with its own on-board RAM?
This case was code running from ROM using page 0 indirection, which is only 1 cycle slower per byte than absolute, indexed mode. -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."