Road to 1.0

[yupferris]

I've been thinking about what Rustual Boy 1.0 looks like, and I think the following things are what would make a great first proper release:

• libretro/retroarch as the primary, full-featured frontend
• cli frontend for something more minimal and with a basic debugger
• 100% game compatibility (at least in playable status)
• Comparable or lower resource usage with other Virtual Boy emulators
• Some basic documentation

So, I'd like to track this as an issue to get it out of my head and also get some feedback on other things we could do for this. I think keeping this list as minimal as possible is necessary to keep it reachable, and I also think we're already pretty close!

In order to reach these points, I think some elaboration/tracking would be useful, so here's an attempt to enumerate/explain things in more detail. Note that I'm quite open to discussion about what these steps should look like, so feel free to discuss here and/or on discord, but at least I'd like to just lay something out initially to put a pin on what to discuss:

• libretro/retroarch as the primary, full-featured frontend
  • I don't think this means we need to support all of the platforms that libretro supports right off the bat, but Windows, Mac, and Linux should be a must.
  • Initial frontend implementation (see https://github.com/sebbert/rustual-boy-libretro for current status/progress)
  • Migrate frontend implementation into main repo
  • Refactor/fix up/mature frontend impl
    • See libretro tracking issue #36 for more info
• cli frontend for something more minimal and with a basic debugger
  • We're almost there, except for some stability stuff on x86_64 on mac (see Currently core dumps under Mac OS X #13 for more info).
• 100% game compatibility
  • At least in playable status (see https://github.com/emu-rs/rustual-boy#known-game-compatibility for current status)
  • Space Invaders Virtual Collection
    • Lazers (from both the player and the invaders) aren't visible in the main play area in Virtual 3D mode. Haven't investigated this specifically, but I suspect some CPU tests against the hardware wrt floats and bit strings might explain it.
  • Nester's Funky Bowling
    • Screen goes black after initial warning screen and appears to softlock. Need to investigate further.
    • Turns out this was fixed in 4bc178e, as well as the softlock bugs in Golf. I'm guessing VIP interrupts were being swallowed if the CPU couldn't handle them (i.e. if the CPU was already handling another VIP interrupt). This newer (simpler) behavior will fire a new VIP interrupt when the current one is finished in that case.
  • Mario's Tennis
    • Severe graphical glitches when transitioning between screens. After a lot of investigation, I'm thinking this has to do with a CPU emulation bug, but I don't know where. I'd like to make some program fuzzing tests to test for precise differences with the hardware.
    • Fixed in b648fb7. The issue ended up being that DPRST/XPRST bits of DPCTRL/XPCRTL not only clear interrupt pending bits, but interrupt enable bits as well. This means certain interrupts won't fire until explicitly enabled after these reset bits are set.
  • Space Squash
    • Game doesn't start; seems to be waiting on an interrupt. Some previous investigation:
      • 7423524
      • 0ff9c61
    • One thing we don't emulate that the hw does is a startup period where the display mirrors stabilize before the "display ready" bit is set. After trying a very simple implementation it didn't seem to affect much, but I'd like to do more debugging here to figure this out.
    • Interestingly, if for some reason the hardware would enable the display once it became stable, the game appears to boot. However, I don't recall reading anything like this in any of the hardware docs. Should make a hardware test to see if this might be the case.
    • This ended up being an incorrect fix in 0ff9c61. The correct fix is in c39ef8a.
  • Vertical Force
    • Powerups/enemies often disappear/reappear along their paths; game softlocks on first boss. Some investigation:
      • 9e1ad57
      • https://gist.github.com/yupferris/f7a11c9bd48a69b1b8ff08719c1e5f9a
      • 6bdcae8
    • In the end, all it took to fix this was a couple of sign extensions: 09cb078
  • Implement bit string op's
    • Assuming this implementation doesn't introduce/uncover additional bugs, this should cover the following titles:
      • 3-D Tetris
      • Golf
      • Nester's Funky Bowling
      • Red Alarm
• Comparable or lower resource usage with other Virtual Boy emulators
  • For example, mednafen uses max ~4% cpu on my box; Rustual Boy is currently max ~9%. This is understandable, as we haven't really got at this much specifically, but I'd like to tackle this head-on (preferably after the libretro and compatibility issues are resolved in order to not break moving parts).
  • There are some places in the emu where we use unsafe code and pointers to avoid bounds checks. In certain places this is quite sensible (reading ROM after masking the address, for example), but I'd like to actually revert all of these changes and only add them back if performance profiling points to them being a bottleneck. Basically, I want to be a bit more rigorous here than I was before other people were contributing to the emu. :)
  • Before tackling this we should also try to agree on some good metrics, get some real data, and make concrete goals from those
• Some basic documentation
  • Content-wise, we're lacking quite a bit, esp. re the debugger, keymap, anything libretro-related, etc.
  • Format-wise, the markdown here on github is ok, but it would be nice to have something redistributable that would go out with the releases (currently we have this readme, but that's really just a placeholder).

With all of these, I think we're looking pretty good for a first proper version :)

[Dr-Emann]

Perhaps this should be a milestone? I'm not sure how all that works in github.

[yupferris]

I considered a milestone, but that would mean separating the other bits into separate tickets. While that might also make sense, I'd prefer to have it in one tracking ticket as that makes it easier (at least for me) to see the whole thing at once and have overview.