From: Geoff Winkless <[EMAIL PROTECTED]> > Without wishing to appear stupid (yeah, I know, too late, haha), I'm still > not clear why that's a memory access.
It's not. The delay is added there for convenience. But in fact it will delay the next opcode fetch (unless it is in rom but read below). >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? The delay shifts to the next (HL) cycle on next LDIR. > > 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. Wish it was but it is will be 4,4,8,5,5 for 1st LDIR then next 4,10,8,5,5 etc the RAM can be accessed once every 8T during display(PAPER for Ales) contention and once every 4Ts during RAM contention (the +X wait-states are applied to next RAM cycle) > 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. Speed will always have it's price. > 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. If needed IM2 can be used. > 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 :) I'd prefer a redesigned ASIC (with a few other fixes). I see little advantage in having a accelerator board Because the extra power is needed in handling video memory. An accelerator board would have to wait just like the Z80 does. Edwin
