You start writing a new emulator for the first time, dispatching entire instructions in one go, and so you don't even really need a state machine at all.
Then you start trying to get the timing better with opcode-cycle granularity, and in comes a separate state machine for every instruction.
Then you realize you need clock-cycle granularity to fix certain edge-case games (eg emulating the effects that occur during bus accesses), and suddenly the prospect of a state machine for every cycle of every instruction becomes overwhelming.
You would then be realistically stuck with the choice to either stop improving your accuracy, or rewriting things cooperatively.
Since I'm focusing byuu.net articles toward aspiring emulator developers, I thought it would be an important topic to cover.
You start writing a new emulator for the first time, dispatching entire instructions in one go, and so you don't even really need a state machine at all.
Then you start trying to get the timing better with opcode-cycle granularity, and in comes a separate state machine for every instruction.
Then you realize you need clock-cycle granularity to fix certain edge-case games (eg emulating the effects that occur during bus accesses), and suddenly the prospect of a state machine for every cycle of every instruction becomes overwhelming.
You would then be realistically stuck with the choice to either stop improving your accuracy, or rewriting things cooperatively.
Since I'm focusing byuu.net articles toward aspiring emulator developers, I thought it would be an important topic to cover.