Steven Seagal wrote:A new insight we took from WinUAE is that STOP won't unstop before 8 cycles, apparently based on hardware tests.
npomarede wrote:In that specific case, that's something that came from Hatari and that I reported to Toni.
And it was already known and measurable on ST in fact : if you do a "STOP #2100" while an HBL int is already pending, you will see that the total time for stop + interrupt + E clock jitter will never go below 8+56+0 ... (from discussion with Toni/WinUAE, he had the feeling STOP could exit every 2 cycles (but not fully measured) ; so maybe the 68000 can STOP every 2 cycles after a minimum of 8, but that the visibility of the IPL is only every 4 cycles on the ST ?)
Finally I think I can give a detailed answer to the STOP exact behavior:
takes a multiple of 4 cycles. It can never take 4*n+2 cycles (well, except by a hardware RESET). This is generic for the 68000, nothing specific to the ST. The reason is how the microcode works. STOP operates like a regular instruction that takes 4 cycles. The only thing special about STOP is that no prefetch is being performed. So the same instruction is executed again and again until interrupted.
This is very different than the mechanism when the 68000 performs a bus access and it waits for the peripheral being ready. When performing a bus access any wait states would delay the CPU for any number of cycles, it is in effect "STOPPED" here. But in our case, when executing the STOP instruction it is really not stopped
STOP would keep executing and iterating until interrupted (or reset). But interrupts are triggered only at instructions borders, they don't stop instructions at the middle. So this could only happen at a multiple of 4 cycles because each STOP "iteration" takes 4 cycles.
Regarding a minimum of 8 cycles. That is not 100% accurate. If the interrupt was pending before but masked by the status register
, and it is being triggered only
as a consequence of the STOP instruction lowering the interrupt mask, then yes, it would take 8 cycles. This is because the CPU takes some time to update the status register. By the time the interrupt mask is updated and checked, it is already too late to interrupt the first STOP iteration, it would interrupt the second one and then it would take 8 cycles.
However, if the interrupt mask on the previous instruction was already low enough to accept the interrupt, but it didn't actually trigger because the interrupt reached the CPU too late by the end of the previous instruction, then STOP would take 4 cycles only. In this case the delay to update the interrupt mask is obviously not relevant, and then STOP would be interrupted at its first iteration.