I copy it here where it belongs. It discusses some timing imprecisions and hacks.
Only the little table can't be properly reproduced.
Prefetch Timing
Prefetch for a microprocessor means loading the next instruction (or more) while an instruction is being executed.
To learn more about prefetch on the 68000, check this article by ijor:
http://pasti.fxatari.com/68kdocs/68kPrefetch.html
Before this article, very little was known about prefetch on the M68000, the concept was still mysterious.
Steem authors had to try things out and see if they worked with games and demos.
They did an amazing work, so many demos already work in Steem 3.2 because the timings globally are very good, but unfortunately the prefetch timings weren't well placed in general. They came at the start of an instruction, even before operands of the current instruction were gathered. It doesn't make sense if you know that operands and instructions follow the "PC" (program counter) and the next instruction is fetched while the current one is being executed (all directly commanded by microcode), but there was much confusion about prefetch really (and about "extra prefetch").
Code: Select all
PC -> PC -> PC -> PC -> PC ->
Instruction 1 Operand 1 Operand 2 Instruction 2 Operand 1Steem authors suspected that something was wrong, as indicated by a comment in MOVE, where the premature fetch must be compensated later in the instruction, with strange things like INSTRUCTION_TIME(10-4);
A consequence of this premature fetch timing is that memory was read too late in emulation. In particular when reading the shifter counter, Steem was 4 cycles backward. To make up for that, so that programs work, the value returned is different from what a real ST would return at the same cycle. In other words, it's a hack compensating wrong timings of almost all instructions! Steem authors weren't aware of that, they just returned the value that worked.
Note that the exact same problems seem to plague Hatari (AFAIK, v1.6.2)!
Hopefully, the "read SDP" hack will be removed in Steem v3.5 (depending on... timing).
It remains to be seen if other parts of emulation were dependent on bad timings.
(at least when I don't forget a column when cutting & pasting ! 
)
