emu-rs / rustual-boy Goto Github PK

Can this emulator have the option to play in a Gameboy-like resolution (or view)?

What do I mean by this? This emulator is about the Virtual Boy, right? A handheld console that had anaglyph 3D. My suggestion would be that if you can actually "fuse" the 3D colors (red and cyan) to make it look like you're playing a Gameboy game. This would actually be perfect for the people that don't have anaglyph glasses, like me.

Also, will this emulator come with its own debugger, and perhaps other tools, for hacking games and creating homebrew games?

Is it possible to use rustual-boy with a modern VR headset such as the HTC Vive and experience the 3D effects appropriately?

Using the step command in the debugger will cause a deadlock when it tries to mutex lock the audio driver, because its already being held by the main emulator loop.

Also would you prefer PRs for bugs instead?

impl Envelope {
...
    fn write_data_reg(&mut self, value: u8) {
        self.reg_data_reload = (value >> 4) as _;
        self.reg_data_direction = (value & 0x80) != 0; 
        self.reg_data_step_interval = (value & 0x07) as _;

The docs say the direction is the 4th bit, so the mask should be 0x08.

It's probably last raw pointer on libretro branch. It might be the cause of deserialization errors.

TL;DR: I'd like to mush USA and Japan columns together.

I come back randomly to see if anything's changed in compatibility and the split between USA and JP makes it hard to scan, especially when a title doesn't exist in a particular country.

Considering they match 100% of the time, I think it'll be easier for newcomers to scan and understand the compatibility. Notes can be added if USA or JP differ.

Worth it?

I made a side by side stereoscopy middleware that renders the left and right frame buffer side by side, so that you can view them with crossed eyes to achieve stereoscopy. This works great, but currently requires you to double the hardcoded width of both the window and the display resolution.

How should this problem be tackled?

I'm been messing with getting vb-rs working in linux. There is something screwy such that the emulated cpu seems to get stuck in a loop and no longer rendering video frames. When its in the state its not possible to get into the debugger since the F12 check will only happen when there are video frames available.

• Support all output pixel formats
  • Currently we request the frontend use XRGB8888 format, but sometimes retroarch doesn't listen to this call (something we should actually look into and try to debug, as the libretro folks have said this is pretty weird), and other frontends may not support this format at all, so we need to support all possible formats.
• Revisit controller/input impl to see if we actually need to map analog sticks like we do
  • It looks like libretro provides a couple different retropad options, one of which may do automatic analog stick -> dpad button conversion, which I would much rather rely on than doing it in the core.
• Support multiple stereo output options
  • Currently we only do mixed red/electric cyan output, but we should support additional types as well. bparker in the libretro community had some nice ideas/insight here from professional experience.
• Use buffered audio output instead of callback-per-sample
  • This is just an optimization, but something we're pretty well equipped to take care of actually.
• Reduce allocations/copies in the AV output chain
  • Right now we have a somewhat elegant sink system for converting/filtering output from the emulator. However, since the emulator's output is fairly regular, we can rather provide storage and expected packing info as input instead of a sink and have the emu itself output in specific formats. This is less elegant but should be much faster, and I'm fairly certain we can still make this pretty safe with Rust. Especially for pixel output, this is likely a major performance bottleneck in both frontends currently.
• Profile/benchmark perf in both libretro and cl frontends
• SRAM
• Consider exposing other types of RAM as well
  • The libretro API supports querying several types of memory, not just SRAM. This would allow a frontend to inspect system RAM, video RAM, etc.
• Serialization/deserialization
  • We need to be a bit careful here, since internal structures may change between versions. Specifically, an accuracy improvement/fix may introduce or remove an internal register, which we want to be a part of the serialized state ideally, but may not align with a previously-saved state. I'm not sure what the best approach here is yet, but I'm sure we can come up with something decent.
• Make sure rustual-boy-libretro's Cargo.toml info is up-to-date and matching the rest of the repo
• Get libretro core builds in CI/distribution pipeline
  • This includes distributing licensing docs, which differ from the CL license info as it uses a lot less IP.
  • We should also think through/document our manual release procedure (currently it's basically just pushing with a specific tag but I want to document that, and it may get a bit more complicated with version bumps etc as we progress).
• When libretro core is more mature, speak with libretro folks about making rustual boy a primary retroarch core
  • I'm not sure what this entails, but I know at least we'll need to provide and maintain documentation, hook up builds in their pipeline, investigate cross compilation for multiple [esoteric] targets, etc.

I noticed this when adding the showcpucache debugger command.

(vb-rs 0xfff40184) > showmem
Unable to parse command: Error(Position(Eof, [104, 111, 119, 109, 101, 109]))

That should have shown memory, but instead threw the above error. Those numbers end up being "howmem". The nom stuff is a bit confusing to me, but I assume whats happening is the tag!("s") is marking the input as complete even though there are more letters after it.

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 #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 #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 :)

$ g log
commit ae3e050dead3005e20720dc610e4f73f38f207da
Merge: e4d4a1e 12d1108
Author: ferris <[email protected]>
Date:   Mon Feb 6 01:23:07 2017 +0100

    Merge pull request #12 from bobtwinkles/command-line

    Command line refinement

$ cargo build --release
    Finished release [optimized] target(s) in 0.0 secs

$ target/release/rustual-boy-cli wario.vb
zsh: segmentation fault (core dumped)  target/release/rustual-boy-cli wario.vb

$ shasum wario.vb
274c328fbd904f20e69172ab826bf8f94ced1bdb  wario.vb

A quick git bisect gave this sha as the first bad one:
4ee4040

Everything before is good, everything after is bad.

so is there a way to reconfigure rustual boy like remapping the puttons/keys or using a controller. also are there more arguments to the exe to full screen the program.

'''
fn sample_clock(&mut self, audio_driver: &mut AudioDriver) {
...
let mut acc_left = 0;
let mut acc_right = 0;

        mix_sample(&mut acc_left, &mut acc_right, &self.voice1, self.voice1.output(&self.wave_tables)); 
        mix_sample(&mut acc_left, &mut acc_right, &self.voice2, self.voice2.output(&self.wave_tables));

...
let output_left = ((((acc_left & 0xfff8) << 3) as isize) - 32768) as i16;
let output_right = ((((acc_right & 0xfff8) << 3) as isize) - 32768) as i16;
'''

The assignment of output_left/right looks fishy.

The values in acc_left/right get truncated down to being 16bits wide, then you make it 19bits wide with the shift, subtract 32k (I assume to try and make it signed?), then truncate it down to a i16?

I seem to recall the << 3 being added as a hack to increase the volume. Seems like it would make more sense to do the shift before the 0xfff8 truncation?

I wanna know if the emulator is still active, just to see if all of its games are playable.