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.

PR to support common mode anaglyph rendering through an intermediate crate (rustual-boy-middleware). Marked as WIP because I'd like I'd like feedback on the anaglyph implementation;

• The mixing stage is pretty expensive right now (lots of casting to floats and doing math and back to integers) and can probably be "cuter" but it'll probably be less clear. It seems fast enough for now, but I haven't run any numbers to see if that's sustainable
• I'm also not confident that the color mixing is correct because color spaces bend my brain a bit. Additive is probably good enough but I think to be technically correct we should be converting from the response curve of the VB LEDs -> linear, performing the addition, and then converting from linear to sRGB.
• Not sure how I feel about rolling our own color type. I'm not really sure where we would pull it from without adding a bunch of unnecessary dependencies though.

The v810 cpu has a 1k direct-mapping instruction cache that's broken up in to 128x 8 byte blocks. Each 8 byte block is further broken up in to 2x 4 byte subblocks.

The instruction cache implementation only keeps track of which memory addresses would be cached and not any actual instruction data. All halfword instruction reads were replaced with a wrapper function that returns the halfword and a bool if the read would have been cached or not. Nothing is currently being done with the cached bool result other then stop rust for throwing a dead_code notice. So there should be no real visual/audio change to emulation until its hooked in better.

showcpucache command was added to the debugger to dump the contents of the cache and some basic stats on hits/misses.

The CHCW system register implementation supports being able to enable/disable the cpu instruction cache as well as being able to clear entries within the cache. This leaves being able to dump/restore the cache from ram missing.

Both implementations are based on info provided in the v810 architecture user's manual (U10082EJ1V0UM00.pdf). Chapter 7 for cpu instruction cache and chapter 2 (2.2.3) for CHCW.

$ 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: 4ee404049d749e6f1feca1a65edb619876aa480f

Everything before is good, everything after is bad.

cpu tracing allows tracking the before and after states of the registers/memory/etc that an instruction will use. This before and after data can then be displayed when using the step function in the debugger.

(vb-rs 0xfff90fea) > cputrace cpu trace enabled: true

Then when you run the step command it will look like this

(vb-rs 0x07000c00) > s 0x07000c00 0fce0400 ld.w 4[r15], r16 before PC: 0x07000c00 PSW: 0x00010000 r15: 0x0500085c r16: 0x00000000 disp: 4 mem.w: [addr: 0x05000860, value: 0x0500089c] cpu cycles: 4 after PC: 0x07000c04 PSW: 0x00010000 r15: 0x0500085c r16: 0x0500089c disp: 4 mem.w: [addr: 0x05000860, value: 0x0500089c]

This required tweaking the debugger step function which used to cpu.step(), then disassemble() to disassemble(), then cpu.step(). This was needed to make the pc reg and the disassembled instruction match up.

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.

Because libretro has an API that asks for the size seperately, and we have to serialize to get the size, the end result is that we change from 2 serializations for each save state down to 1.

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?

''' 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?

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?

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.

• Make a cargo workspace at the top of the repo
• Update all dependencies except combine to the newest version
  • cpal version 0.4 to 0.12 introduced some differences
• Fix warnings

• [x] 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.
• [x] 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.
• [x] 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
• [x] SRAM
• [x] 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.
• [x] 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 wasnt able to find any docs that indicate how many cpu cycles it takes to enter an exception. I ended up going with 10, which is how many it takes to leave an exception (reti). However I suspect entering an exception is really going to be a few more then that.

The added cpu cycles are applied to the first instruction executed in the exception.

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?

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?