Ian Collier wrote: > The z80 code and a short binary follow. You can test the binary <snip>
The binary seems munged again - could you please zip it and resend it? > defs 56-p What's the 'p' part of this? I can't see a label for it, so is it something specific to your assembler? What size should the gap be? I assembled the rest of it but it hung without doing anything, so I guess it > The real Sam is keeping the interrupt active for somewhere between > 120 and 132 cycles. On a related note, I was looking at a repeated interrupt problem with SimCoupe last night. I had a line interrupt routine that was very short so it completed while the interrupt was still active on the status port. This caused the handler to be run for a second time before the active interrupts were cleared from the status port after the 30us (180 cycles). I added an extra variable that is reset when the interrupt is processed, leaving the status_port alone so it can be read by the interrupt handler code. I can't see that it's anything that I've broken from the original code, but that did cross my mind! I noticed this when the scroller in my PacMan was being displayed incorrectly because the 2 line interrupts I used had got out of sync. This only happened after I'd tweaked the instruction timings in the Z80 core, which must have shortened the time taken by the handler to just below the active time, so it was still active when it returned. I noticed that shortening the interrupt active time to 20us (120 cycles) seemed to fix it, as that was short enough to to the reset before the interrupt handler had returned. I'm surprised the multiple interrupt effect doesn't happen with your short interrupt handler - when I can run it I'll have a look! So, would reducing the active time to about 125 cycles, taking the actual interrupt time into consideration for the active interrupt time, and adding the flag to prevent multiple handle calls, cover it? Si
