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