On Sat, Jul 10, 2004 at 02:43:53PM +0200, Edwin Blink wrote: > I assume the code is in ROM. The POP will take probably 12 Ts because SP > will point to RAM (in ram a POP takes 12Ts, PUSH 16Ts)
Yeah, that's the idea! > I really like it too and I Didn't think of it myself ! Way to go ! Thanks! I suppose it was never really needed until now... I expect someone would have suggested it sooner or later, though. > I will check out if your 'POP LD' idea will take 26 Ts and also will check > LDI timing again when code is in ROM and DE,HL,SP are in RAM Do the "LD (HL), C" and "LD (HL), B" instructions take any longer when they're using MMIO? If not, is writing to MMIO from an LDI slowed down? I just realised that the "LD (HL), C" should come first, since the Z80 is little-endian. > If this method realy works out as good as it looks I'd free as much > bytes as possible for it ! However Using the stackpointer will not > permit use of NMI and Interrupts. Not using NMIs is not a problem > since it should not be used during disk access anyway. Not beeing able > to use interrupts is a pitty though. I figured that if you could use your own interrupt handler, you should be able to examine the contents of the stack to determine which instruction was interrupted, and repair the damage. That depends on being able to place your own code in Segment A (0x0000-0x3fff), whilst running this routine. Is that possible? BTW, repeated LDIs followed by a "DEC A, JPNZ loop; EXX; JP HL" would be a great thing to have in ROM, too (even if it's just a small loop), since it could be used for any large copying. > > I've noticed that stack-copying can be used to write to the interface, > > but the registers just need to be pushed in the same order that you > > popped them in (I.e. the opposite order to ordinary stack-copying). > > Adjusting the SP will just take too much time I think. I've not tested it, but I think it's marginally faster than ordinary stack copying. Ordinary stack copying *just* beats LDI, at least if there's no memory contention. When loading into AF, BC, DE, HL, AF', BC', DE', HL' and IX, you can get about 31 cycles per word. Because MMIO addresses do not need to be updated (which saves some cycles in itself), you can copy using whichever register usually holds the destination address, which saves some additional cycles. This is such a small saving (and the unrolled loop is huge) that I don't think it's worth bothering with. LDI would give better performance because you'd be able to pack more iterations in. > > Checksum, error correction and compression code seem like good ways to > > use any spare ROM space, as well as sorts and searches, and manipulation > > of trees, lists and hash tables. How much space is there? > > I think there would be not enough for it. I'd go for on the fly CRC and > compression I didn't mean the whole lot -- those were just some ideas. CRC and compression sounds good to me. -- Stuart Brady
