[ComputerGuru]

This is great. I’m not clear on if the bugs you are finding are in Ghidra’s processor model or in the emulator? (Though I think it’s the latter?) Also, why would Ghidra have the best (most accurate?) processor model vs some of the highest quality emulators?

One other question: when the cpu is being emulated at a 50th of its actual speed (or less!) how does replaying recorded input work? Do all games strictly use interrupts to read input or do any poll the state instead (or maybe just at certain sequences or for certain portions of the gameplay)? If the latter, did you have to adjust the key down/key up events you were replaying to avoid a slow-executing cpu missing inputs? (As you might be able to guess, I’m an embedded dev but haven’t dabbled with emulators beyond using them.)

Thanks in advance and again, awesome work!

[wgjordan]

> I’m not clear on if the bugs you are finding are in Ghidra’s processor model or in the emulator? (Though I think it’s the latter?)

The project README includes a link to a commit fixing bugs in Ghidra's processor model, here is the author's PR submitting those fixes upstream: https://github.com/NationalSecurityAgency/ghidra/pull/5740

[0d0a]

From what I've seen, it's usually read at the vblank interrupt.

The input recording has entries in format "<instruction_number> <buttons_bitmask>". If I press a button and it's read from the hardware register after let's say 0x1000 instructions have been stepped, it is stored as "0x1000 0x80", and in the Ghidra emulator script, I only need to count up to 0x1000 instructions before I send that memory write to the other emulator. While the real timings are vastly different, the input will be read after roughly the same number of vblank calls. I say "roughly" because indeed I found a differential on the expected call where it should be read, but it isn't yet clear if that's a logic bug on my side, I'll have to eventually look into it again.

[ComputerGuru]

Thanks - that’s along the lines of what I was expecting.