Excellent results. As I’m sure you’ll agree there are many stones left to overturn in researching how to play video games without direct human input. I’m looking forward to your next developments.

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!

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.

Very old ML project from a master's student's thesis which is what originally got me into CS. He taught it to play NES games other than mario and had a good breakdown of his results.

http://tom7.org/mario/

Cool project! I'm very interested in accurate preservation of the behavior of these old systems (chip decapping and scanning, FPGA reimplementation, accuracy-focused emulators) and using Ghidra to reverse engineer old games, especially on the 6502 and m68k architectures. Just an enthusiastic spectator at this point, but I hope to contribute something to the field eventually.

A sidenote: the action at 0:19 in the 50x-speed demo is intriguing. I've played many hours of Super Mario Brothers and watched various tool-assisted speedruns of it, but I don't recall seeing a Goomba reverse direction like that instead of just plowing into Mario. Is that a game glitch that you intended to show off with your recorded keyboard inputs? I haven't played in a long time, so I also wouldn't be surprised to hear that such behavior is common. I didn't find an obvious reference to it in the TAS info here [0].

Edit: there is precedent for that Goomba behavior [1].

[0] https://tasvideos.org/GameResources/NES/SuperMarioBros

[1] https://www.reddit.com/r/Mario/comments/add1fx/changing_goom...

I think that goomba bumped into the squished goomba Mario had just squished. Mario was just a bit to the left so the flat goombas hit box stuck out to the right a bit and the other goomba hit it.

Is it a 6502 processor model in specific? Because the NES used the 2A03 in NTSC regions:

https://www.nesdev.org/wiki/2A03

The emulator in Ghidra is really cool. I’ve been improving my Wasm processor module to support better emulation, and I’ve made use of their comprehensive specification tests to validate the implementation.

One thing that I run into a fair bit is the tension between keeping the decompiler output sane vs. implementing every nuance of a particular instruction. Trying to emulate every quirk turns into very complex P-code, which can clutter up the decompiled output. One strategy is to use custom operations (pcodeops) plus an emulator helper, but this makes the operation totally opaque to the decompiler, so it’s not suitable for common instructions.

In general though it’s super cool to have this kind of functionality available. It will be awesome if Ghidra can someday be a powerful tool for dynamic reverse engineering, not just static reversing.

I thought I recognized the GitHub username, you contributed to my GNOME Shell extension years ago!

Just wondering, what was the extension?

At 17 seconds into the demo video, Mario appears to run into a Goomba horizontally without being harmed, and it just changes course to head in the other direction as if it bounced off him.

Is this the correct game mechanic behavior? My recollection as a 90's kid is this worked differently: If you run into a Goomba horizontally, Mario is toast (or loses his mushroom bigness).

Am I confused? :D

Edit: Thanks to @h0l0cube and @cylon13 for explaining this in another comment- it turns out nothing is wrong. If you look closely after reading their explanation, you can see it. Certainly a subtle detail.

I think that goomba bumped into the squished goomba Mario had just squished. Mario was just a bit to the left so the flat goombas hit box stuck out to the right a bit and the other goomba hit it.

I noticed that as well.

Thanks for sharing, I enjoyed your project.

I'm also interested in processor module verification. May I offer some performance suggestions:

- You don't need Ghidra to use Ghidra's p-code emulator

- Ghidra's p-code emulator is part of the decompiler which is cpp not Java. It's located in ~/Ghidra/Features/Decompiler/src/decompile/cpp in source. There are examples there as well

- So instead of communicating back in forth with Ghidra itself, hack up your emulator to also use Ghidra's p-code emulator. At every step you can save state, run your emulator and the p-code emulator, and diff the final state. If there's any differences one (or both) emulators are wrong.

This will likely be too slow to play but should be much faster than your current approach. Hope this helps.