I’d be careful of making this too usable, since accurate NES emulation is a non-trivial problem. Of the 8-bit machines, the NES is particularly nasty because the PPU is notoriously temperamental. This is a property captured by precious few emulators, which ends up causing lots of grief for NES homebrew/demo coders. That said, it looks like it’s been a good learning experience
Just so I understand, are you saying there’s a tradeoff between usability and accuracy? Or just that you would want to avoid encouraging people to actually use a toy emulator? (If it’s the latter, I feel like most people know the difference between a polished, highly accurate emulator and something built as a learning toy.)
Both, sort of. But mostly that it’d be nice if everyone who writes a new NES emulator spent that energy improving the ones we already have :) There’s a situation now where there’s NES ROMs that only work in certain emulators, and not in more accurate emulators nor on real hardware. NESticle is an example of such an offender
It’s a hobby project to learn something. That’s great. I’ve worked on a 65816 clone from scratch, written a Pascal compiler from scratch…hell, I’ve written an MP3 decoder from scratch, I think in C, but maybe it was Free Pascal. Thing is, I learned a ton from these projects, and they’re a lot easier than contributing to RISC-V, LLVM, or LAME, respectively. And likewise, what machrider did (write a basic NES emulator from scratch) is gonna be way easier than fixing some inevitably interface/timing-based issues with the NES PPU in some already-complicated emulator that probably has whole subsystems dedicated to replicating NTSC rendering artifacts.
I get very grumpy when someone sees a project that was built out of love and a desire to learn, and tells its author that they instead should have contributed to an already-existing project. That’s a toxic and self-defeating attitude. Let people learn how they need to learn. If they like what they did, then, afterwards, you should let them know that these other projects could use their help. And it’s okay if they still demur, either because they want to work on something else, or because they don’t feel up to e.g. figuring out how to efficiently replicate composite rendering issues.
But don’t say things like “I’d be careful about making this too usable.” Let them build this project how they want. You don’t have to use it, but at least let them enjoy having accomplished something so exciting.
I’m just worried of there being more crap to deal with when writing new NES programs
I feel like as a learning project, writing a toy from scratch is a lot more fun though. :)
Where are details of the NES? I’d love to explore writing my own NES emu.
edit: https://wiki.nesdev.com/w/index.php/Nesdev_Wiki – it was linked in the post. i skimmed over it -_-
Is the NES the most emulated machine in history at this point?
I feel like many other emulators have one or two or maybe even three, but NES has become a de-rigeur project for folks wanting to play with perf intensive problem sets that leverage low level code.
I would have guessed Chip 8 (which is more of a VM) is more emulated than NES.
Very nice write-up. Amazing how many people learn Rust by writing NES or Gameboy emulators! It’s starting to feel like a rite of passage.
Some of your unsafe stuff as demonstrated in your PPU section might be eliminated by using the Cell type to make interior mutability. That at least makes explicit the parts you’d have to replace with Mutex to make it multithreaded, as you suggested. The raw pointers in your CpuPpuInterconnect puzzle me more, it feels like it should be possible to arrange your memory structures to form a DAG, but I don’t know much about the NES and I only skimmed your code.
After a point it gets so clutter-y it’s kinda not worth it though, sometimes a pointer is just a pointer. Maybe there should be a new term for trying to eliminate technically-perfectly-reasonable uses of unsafe; safety-golfing?