From: "Stuart Brady" <[EMAIL PROTECTED]> > 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?
This I don't know.I'll add it to my checklist unless anyone else can tell us ? > 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? I see what you mean now. Another wonderful idea to repair the stack. I think A dedicated interrupt routine needs to be one to repair the stack. It should simply do a PUSH BC INC SP,INC SP if we can garantee BC will not change. if a index register is sacrificed for it the following could be used interrupt handler: POP IY ;fetch return address PUSH BC ;repair stack ;more interrupt handler POP BC ;restore BC and SP JP (IY) ;return to code BC register can be used to switch external memory to normal memory which holds the rest of the code. Perhaps AF should be saved instead of BC because OUT (C),r does corrupt flags sometimes The memory configuration I think would be best is: 0000-7FFF 32K RAM easier for crossing page boundaries 8000-BFFF MEMIO or RAM code calling ROM code C000-FFFF ROM1 with patched code When 0000-3FFF is used to store code and no buffer is used to r/w data then the code must copied to source/destination page-1 every time a page boundary is crossed while r/w-ing I think using IM2 would be a good solution. But would require a 257 byte table again. > 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. DECA can be ommited if The overflow flag is used instead. Load BC with the length and jump to the [length] MOD [repeated LDIs] LDI before the jump. ie: BC =512 bytes #of repeated LDI =6 then a JP PE (or was it PO?) so jump to 2nd LDI before the jump. > I didn't mean the whole lot -- those were just some ideas. CRC and > compression sounds good to me. considering a IM2 table too I think I need to beat the bytes out a lot more! Edwin
