Gymnasium VS 6502_65C02_functional_tests

"Show HN: Ghidra Plays Mario" (2023) https://news.ycombinator.com/item?id=37475761 :

[RL, MuZero reduxxxx ]

> Farama-Foundation/Gymnasium is a fork of OpenAI/gym and it has support for additional Environments like MuJoCo: https://github.com/Farama-Foundation/Gymnasium#environments

> Farama-Foundatiom/MO-Gymnasiun: "Multi-objective Gymnasium environments for reinforcement learning": https://github.com/Farama-Foundation/MO-Gymnasium

https://github.com/Farama-Foundation/Gymnasium#environments

Farama-Foundatiom/MO-Gymnasiun:

https://github.com/Farama-Foundation/Gymnasium - A framework Python library to build and train your own AI to play games

The only change in the environment from the one here is the reward function which is given its return value using the following code snippet (replacing lines 648-672 in the above url):

This may be useful: https://github.com/Farama-Foundation/Gymnasium

Here are all the environments. So for example, if instead of Hopper-v2 you want the acrobat environment from classic control you can write: env = gym.make('Acrobot-v1')

This release also includes a large number of documentation updates, minor bug fixes, and other minor improvements; the full release notes are available here if you’d like to learn more: https://github.com/Farama-Foundation/Gymnasium/releases/tag/v0.28.0.

Thanks! It really depends on the task that you want to implement. But in general, sticking to the standard gymnasium API is important. If you want to implement a 2D environment then PyGame is promising. If it's more like a game, check out Unity ML-Agents or Godot RL Agents. Anything simpler can also be just pure python code. You also need to carefully design your observation space, action space and reward function. My advice is to explore design choices of related environments.

You can read the release notes here: https://github.com/Farama-Foundation/Gymnasium/releases/tag/v0.27.0. You can upgrade from 0.26 without any changes unless you're doing something very uncommon; this is how releases will generally be going forward.

Klaus Dormann's 6502 tests don't rely on a particular emulator environment. They could be used with Ghidra.

https://github.com/Klaus2m5/6502_65C02_functional_tests

How about some assembler code to test all of the opcodes? https://github.com/klaus2m5/6502_65c02_functional_tests

https://github.com/Klaus2m5/6502_65C02_functional_tests might be worth a look, it's a comprehensive test suite

Great! (and not surprising). You may want to look into using a 6520 test suite to check correctness of your emulator, like this one -- note: I have no experience with it, but it took me some time to iron out the last error of my 6502 emulator, and in hindsight I should probably have used such test suite.

Currently i'm trying to implement 6502's instructions one by one using TDD. I was curious are there any test - corner cases already been written ? I found out ( https://github.com/Klaus2m5/6502_65C02_functional_tests ) but this requires all instructions to be implemented which I don't currently. Is there any way to test a single instruction in isolation for all the edge cases ?

By "bad branch", I mean the emulator takes the wrong branch because it fails to emulate some part of the Apple hardware properly. The 65C02 emulation has passed some pretty stringent tests (https://github.com/Klaus2m5/6502_65C02_functional_tests/blob/master/bin_files/65C02_extended_opcodes_test.lst), so I'm pretty confident in it. But the instruction trace file is around 90,000 lines, so is kinda hard to slog through.