Edwin Blink wrote: >> Incidentally, what are the 5 cycles for an LDIR? > > It uses the same technique as used by relative jumps to add a value > of -2 to PC.
Without wishing to appear stupid (yeah, I know, too late, haha), I'm still not clear why that's a memory access. I've found a more helpful list to the one I was using and it says the final 5 is internal operations, so in ROM it should just take 5 cycles, surely? http://www.z80.info/z80ins.txt According to that, LDIR is 4,4,3,5,5 for fetch, fetch, read, write, internal ops. Shouldn't that round up to 4,4,8,8,5 if in ROM with display contention and 4,4,4,8,5 with RAM contention? That would mean that > 4,4,3+5,5,5+6 LDIR in ROM with Display contemption = 32Ts ought to be 4,4,3+5,5+3,5 = 29Ts since the next instruction fetch will also be in ROM and therefore uncontended. Compared to 24+48/14 or 27.43 means the stack method is still faster, but you also need to bear in mind the setup cost of storing the stack pointer (or leaving it in a known state) and any registers you want to keep, plus the lack of flexibility and memory costs. I wonder at what point it becomes worthwhile. Of course using ROM routines means you have to have the ROM paged in and therefore drop back to the system interrupt routines and lose 16k of memory access. So either way it's not win-win. The ideal solution, of course, would be to build a custom ROM with a set of PUSH/POP's. But that defeats the object somewhat, since if we're resorting to hardware solutions then a blitter accelerator board (or a redesigned ASIC with such capability built-in) would be far the best option :) G ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
