nestadia VS moa

NES: https://github.com/zer0x64/nestadia

You can refer to my NES emulator to see how I do it: https://github.com/zer0x64/nestadia/blob/master/nestadia/src/lib.rs

Having written emulators in Rust myself, I have to warn that Rust enforces "good code architecture", and hardware architecture does not follow these principle, so you might need to do a bunch of unconventional hacks to make the borrow checker happy. (links to my NES emulator). Also, frontend development is still not really great. For me, I think the benefits of Rust still outweights the shortcoming, but that can vary from one individual to another.

The code is here if you're interested: https://github.com/transistorfet/moa System is the top level component and devices.rs has the traits that System uses to interact with the components. The machines directory has the system definitions that build a specific machine to emulate.

A few months ago, I wrote a 68000 emulator in Rust named Moa. My original goal was to emulate a simple computer I had previously built. After only a few weeks, I had that software up and running in the emulator, and my attention turned to what other platforms with 68000s I could try emulating. My thoughts quickly turned to the Sega Genesis and without thinking about it too much, I dove right in. What started as an unserious half-thought of "wouldn't that be cool" turned into a few months of fighting documentation, game programming hacks, and my sanity with some side quests along the way, all in the name of finding and squashing bugs in the 68k emulator I had already written.

There's not much to it. Only one window can be created at the moment, and input is not yet supported. The threaded option is also not shown here. Before long, the code grew more complicated, and now includes parsing of command line arguments with the clap crate. To see the latest version, check out the Genesis machine-specific binary and the MiniFB host impl and main loop

Since the 68000 has a reasonably orthogonal instruction set, we can break down the opcode word into sub-components, and build up instructions by separately interpreting those sub-components, rather than having a match arm for each of the 65536 combinations. There is a really helpful chart by GoldenCrystal which shows the full breakdown of opcodes for the 68000. We can look at the first 4 bits of the instruction word to separate it into 16 broad categories of instruction, and then further break it down from there. The full code can be seen here