Of course up until now you're just looping through a byte stream and switching on some opcodes. Then you get to the point where you need to have stuff like the graphics and screen emulation working and synchronized with the emulated CPU, and that's when things start getting complicated.
The Sega Master System has separate CPU and video ("VDP") and I now have them talking to each other. The test ROM I'm using looks like it zeroes out work RAM and VRAM, and then loops waiting for a screen refresh interrupt. So the next steps are building cycle counters and timing and interrupt management.
Also I am enjoying writing this in Rust, it's a surprisingly good kind of project given how much is shuffling data and shared state around.
Finally got some shared timing stuff hooked up, and without any profiling or optimization and while being a complete Rust newbie, this thing is already running at 18 MHz, well above the 4 MHz needed by the Master System.
When I tried to build a Game Boy emulator in Swift, the performance was probably 100x slower by default, and needed a lot of tuning and measuring to get past the 4 MHz mark.
@stevestreza Oh yeah, CPU emulation is fun, emulating individual pieces of hardware is where it gets difficult AFAIK (my main difficulty is that it's hard to find documentation about the hardware unless you're a physicist who knows how to make the hardware from scratch.
@uliwitness There's a great emu dev community on Reddit with a matching Discord, they're an invaluable tool for finding resources and documentation (even if that also means they're impenetrably hard to search in)
@shadowfacts Swift does try to hide a lot of implementation detail from you, which makes it good for apps but less good for systems programming, so it's not a surprise that it's easier to write high-throughput code by default in a language like Rust. Probably also why Swift is moving in that direction.
The original server operated by the Mastodon gGmbH non-profit