In "panic" under Hatari, I sometimes get a "move.w a4,(a4)" at cycle 52 to go back to 50 Hz. With a move at cycle 52, it means the write in ff820a is complete at cycle 56 and in Hatari this creates a 60 Hz line that starts 4 cycles earlier with +2 bytes and mess the rest of the timings (in most cases, switch is made before cycle 56, so line has correct length).
Is 56 a position that is wakeup dependent, and the 60 Hz line should be emulated only for certain WU state ? (Hatari doesn't handle WU state at the moment).
Hmm. I wonder if this is an issue with timing conventions. So, the tables I've created (which match Paulo's timings etc) are for the cycle when the instruction starts - when it comes to move.b d0,(a0) changes and the like. So, a move back to 50Hz at cycle 52 would indeed (for WS1/WS3) mean that the 60Hz check for start of line (+2) does not trigger. In WS2/WS4 the check would be at cycle 54 so it wouldn't trigger either.
It's not really positions that are wakeup dependent, but the fact that the exact cycle when GLUE reads the contents of the RES and FREQ registers that differ between the different wakeups (wakestates). All reads are thus "wakeup dependent" - but in reality it's only an issue when the used timings are at the limit when the GLUE statemachine changes condition.
I've probed the timings described on the wiki extensively and believe they are correct: http://atari-forum.com/wiki/index.php?t ... _Scanlines
If 820a is "60Hz" a switch back to 50Hz must be made (start of move instruction) at the latest cycle 52 (54 in WS2/WS4) for a line to be 50Hz. Example table below:
60/50Hz - WS1/WS3
0/52 = 512 cycle line, 50Hz starting position
0/54 = 512 cycle line, 60Hz starting position (+2)
0/56 = 508 cycle line, 60Hz starting position (+2)
60/50Hz - WS2/WS4
0/54 = 512 cycle line, 50Hz starting position
0/56 = 512 cycle line, 60Hz starting position (+2)
0/58 = 508 cycle line, 60Hz starting position (+2)
I hope it's of any use.