Andrew Collier wrote: > That would mean there should be 384*312=119808 t-states between frame > interrupts, but according to that article, if you measure the number > of instructions executed during a frame, then even with the screen off > it turns out to be slightly fewer than expected.
I'd be interested to see how the article measured a difference, as I've only ever seen the official 119808 value myself. Is issue 2 available anywhere? The difference could be an error in the expected timing values, due to mis-alignment with T3. Instruction timings are affected by the cycle alignment left after the previous instruction completed. That's what prevents a definitive list of SAM instruction timings, even when you're only considering the simple border case (same as with screen off). Even a simple NOP in the border area can have 4 different timings, depending on what comes before it: scf ; 4T nop ; 4T (normal) ld (hl),a ; 7T nop ; 5T! inc hl ; 6T nop ; 6T! ret nz ; 5T (assume condition not met) nop ; 7T! I picked 1-byte instructions with timings of 4-7T, which leaves a different alignment for the following instruction. That results in a different amount of contention delay for the NOP opcode fetch. In most of these cases the old-style rounding up to the next multiple of 4 still gives the same timings. Instructions that are a multiple of 4T will mask the effects, but it's easy to create problems using a sequences of non-4T multiples: ret nz ; 5T inc hl ; 9T! ret nz ; 7T! ret nz ; 8T ret nz ; 8T Repeated instructions usually sync with T3 to settle on a consistent (rounded) timing value, as seen in last two instructions. All that fun using just 1-byte instructions! Si
