Andrew Collier wrote: > He didn't include code, but he described counting the number of NOP > instructions executed between two consecutive frame interrupts.
I've knocked up my own version, which uses the block of NOPs, but with a DEC A ; JP Z at the start to exit once the test is complete. They add 16T, which is the same as the 4 NOPs they replaced. There's also an EI a little later to re-enable interrupts when they're no longer active. The value I get in SimCoupe is 119792, which is 16T short of the expected full frame time. The difference is about what a contended push PC and jump to IM1 handler would be (as you mentioned below). I'll check it's the same on the real machine tonight. Code and bootable disk are here: http://obo.homeip.net/frame_time.zip > Although, thinking about it now, somewhere in this experiment you'll > need to account for the time it takes to the Z80 to find its interrupt > routine and to stack the PC. Does that take as much as 112 t-states? It's definitely too much to be just the handler overhead. It's suspiciously close to the 128T active interrupt period, so perhaps interrupts were enabled too soon for the next one? If only the last value on the stack was used, it'd be short by the amount it was held back due to re-triggering (approx 112-128T?). > Is this simply a question of notation? Where an instruction waits > several t-states before starting (presumably because of when the ASIC > allows memory access for the instruction fetch) I would normally have > counted that as part of the first instruction, whereas your examples are > counting it in the second. It does make sense to do that for coding notation, where the delays balance out. My timings were from a strict execution point of view - from the current cycle to the cycle after the instruction completes. Perhaps it does only matter to SimCoupe, which always needs to know the true picture. For instance, including the delay from the following instruction could affect whether an interrupt is accepted after the current instruction completes. > So in your final example, I would have expected an instruction following > that sequence to start 40T after the first ret nz did - each instruction > having started at intervals of 8T. Is this not the case? You're right - 37T rounds up to 40T, so I must have added them up wrong last night! I definitely remember cases sensitive to the ending alignment, but perhaps it was only for longer instructions that were stretched by contention delays. Or maybe one of the more contrived cases Dave and I created for testing. I'll see what I can dig up... Si
