Went to check if any of the 6502 bugs were flags related and yep there was. It's a simple chip but in particular the overflow flag behavior is often done incorrectly.
Show HN: Ghidra Plays Mario
31–34 of 34 posts
Re: Show HN: Ghidra Plays Mario
#32Cool 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-…
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.
@19s?
Re: Show HN: Ghidra Plays Mario
#33Thanks 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.
Re: Show HN: Ghidra Plays Mario
#34Thanks 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 for…
Nice, I'll give it a closer look. My only concern so far is memory hooking (still needed for hardware registers), which on Java side was called by FilteredMemoryState [1]. In memstate.cc it looks like just the simpler MemoryState is implemented [2], and there's no equivalent to MemoryAccessFilter. But it might not be that complicated to add...
[1]: https://github.com/NationalSecurityAgency/ghidra/blob/4561e8...
[2]: https://github.com/NationalSecurityAgency/ghidra/blob/4561e8...