Muzero-unplugged
ghidra-tlcs900h
Our great sponsors
| Muzero-unplugged | ghidra-tlcs900h | |
|---|---|---|
| 3 | 1 | |
| 20 | 9 | |
| - | - | |
| 10.0 | 7.3 | |
| about 1 year ago | 4 months ago | |
| Python | Java | |
| GNU General Public License v3.0 only | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Muzero-unplugged
-
Show HN: Ghidra Plays Mario
https://github.com/DHDev0/Muzero-unplugged
Gym is now gymnasium and it has support for additional Environments like Mujoco:
- Implementation of MuZero, MuZero Unplugged and Stochastic MuZero
ghidra-tlcs900h
-
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
What are some alternatives?
Stochastic-muzero - Pytorch Implementation of Stochastic MuZero for gym environment. This algorithm is capable of supporting a wide range of action and observation spaces, including both discrete and continuous variations.
ghidra - Ghidra is a software reverse engineering (SRE) framework
Muzero - Pytorch Implementation of MuZero for gym environment. It support any Discrete , Box and Box2D configuration for the action space and observation space.
retro - Retro Games in Gym
pytorch-A3C - Simple A3C implementation with pytorch + multiprocessing
Gymnasium - An API standard for single-agent reinforcement learning environments, with popular reference environments and related utilities (formerly Gym)
nn-morse - Decode morse using a neural network
6502_65C02_functional_tests - Tests for all valid opcodes of the 6502 and 65C02 processor
MO-Gymnasium - Multi-objective Gymnasium environments for reinforcement learning
neural-network-scratch - build a neural network to show as a demonstration on inner workings of a neural network
ghidra-plays-mario - Playing NES ROMs with Ghidra's PCode Emulator