4 ms·

Do we really need all this complexity? how about if having, let's say, N chips to emulate, do a simple loop and call 'emulate' for each of the chips? for(E

Do we really need all this complexity? how about if having, let's say, N chips to emulate, do a simple loop and call 'emulate' for each of the chips? for(EmulatedChip &chip : chips) { chip.emulate(time); } Why would the above not be suitable for emulation?

joppy 7y ago
I think this approach is the "state machine" approach given in the article. The added complexity in moving to a coroutines/co-operative threading model is balanced by the drastic code reduction, pointed out in the article by "Yes, it's really that dramatic of a difference".
- fwsgonzo 7y ago
  Yes, you inevitably end up implementing a state machine like that.
  - byuu 7y ago
    I consider it something of a trap in fact. 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.
boomlinde 7y ago
That model is unsuitable for a system where chips are interconnected. Your model breaks down once chip x needs to produce something on a bus for chip y on cycle z. Of course, then you could emulate with time = 1 cycle, but at that point you are stuck implementing a state machine either way. If you just have a bunch of chips operating separately without the need for synchronous communication your model works, but that's unrealistic.

joppy 7y ago

I think this approach is the "state machine" approach given in the article. The added complexity in moving to a coroutines/co-operative threading model is balanced by the drastic code reduction, pointed out in the article by "Yes, it's really that dramatic of a difference".

fwsgonzo 7y ago
Yes, you inevitably end up implementing a state machine like that.
- byuu 7y ago
  I consider it something of a trap in fact. 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.

boomlinde 7y ago

That model is unsuitable for a system where chips are interconnected. Your model breaks down once chip x needs to produce something on a bus for chip y on cycle z. Of course, then you could emulate with time = 1 cycle, but at that point you are stuck implementing a state machine either way. If you just have a bunch of chips operating separately without the need for synchronous communication your model works, but that's unrealistic.