Show HN: Ghidra Plays Mario

I've been exploring new ways of testing Ghidra processor modules. In this repo, I was able to emulate NES ROMs in Ghidra to test its 6502 specification, which resulted in finding and fixing some bugs.

Context: Ghidra is used for reverse engineering binary executables, complementing the usual disassembly view with function decompilation. Each supported architecture has a SLEIGH specification, which provides semantics for parsing and emulating instructions, not unlike the dispatch handlers you would find in interpreters written for console emulators.

Emulator devs have long had extensive test ROMs for popular consoles, but Ghidra only provides CPU emulation, so it can't run them without additional setup. What I did here is bridge the gap: by modifying a console emulator to instead delegate CPU execution to Ghidra, we can now use these same ROMs to validate Ghidra processor modules.

Previously [1], I went with a trace log diffing approach, where any hardware specific behaviour that affected CPU execution was also encoded in trace logs. However, it required writing hardware specific logic, and is still not complete. With the delegation approach, most of this effort is avoided, since it's easier to hook and delegate memory accesses.

I plan on continuing research in this space and generalizing my approaches, since it shows potencial for complementing existing test coverage provided by pcodetest. If a simple architecture like 6502 had a few bugs, who knows how many are in more complex architectures! I wasn't able to find similar attempts (outside of diffing and coverage analysis from trace logs), please let me know if I missed something, and any suggestions for improvements.

[1]: https://github.com/nevesnunes/ghidra-tlcs900h#emulation

Show HN: Ghidra Plays Mario
github.com

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.

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’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