yupferris

// Super high-level playroutine overview:
//  Timer reload set to 0x0004
//  Timer int fires every 120us (sample rate of ~8333.3hz)
//   Store 0x15 in timer control (small interval, zero interrupt disable, clear zero status, timer enable)
//   Output volumes to VOICE_1_VOLUME - VOICE_5_VOLUME
//   Store 0x19 in timer control (small interval, zero interrupt enable, timer enable)

* 0xfffffe10  7c44        add 28, r3
  0xfffffe12  23dc0000    st.w r1, 0[r3]
  0xfffffe16  20bc0207    movhi 0x702, r0, r1

yupferris

use std::io::{self, Write,  Read, BufWriter};
use std::fs::File;
use std::path::Path;

const NUM_CHANNELS: usize = 1;
const BITS_PER_SAMPLE: usize = 16;

fn main() {
    let rom_file_name = "C:\\msys64\\home\\ferris\\dev\\projects\\vb-rs-corpus\\Galactic Pinball (Japan, USA).vb";
    let buf = load(rom_file_name).unwrap();

yupferris

use std::io::{self, Read};
use std::fs::File;
use std::path::Path;

fn main() {
    let rom_file_name = "C:\\msys64\\home\\ferris\\dev\\projects\\vb-rs-corpus\\Mario's Tennis (Japan, USA).vb";
    let buf = load(rom_file_name).unwrap();
    let src = 0xfff9fb4c;
    let dst = 0x00078000;

yupferris

// Super high-level playroutine overview:
//  Timer reload set to 0x0002
//  Timer int fires every ~50us (no, that's not a typo)
//   Store 0x00 in timer control (large interval, zero interrupt disable, timer disable)
//   Store 0x19 in timer control (small interval, zero interrupt enable, timer enable)
//   Output volume to VOICE_1_ENVELOPE_DATA and VOICE_2_ENVELOPE_DATA

// Data stream
// 0xXX           where 0xXX != 0x0f => envelope data <- 0xXX << 4 (reload value = 0xXX & 0x0f; count down to 0)
// 0x0f 0xXX 0xYY where 0xXX != 0x0f => voice volume <- 0xXX; envelope data <- 0xYY << 4

yupferris

 - Lots of things seem to be indexed with r4; looks like it's always 0x05008000
   - This is consistent with the "global data pointer" info in the tech scroll
   - Looks like the offset into this mem is always negative

 - Known globals (as negative offsets from r4):
   -1402 (0x05007a86) - Effective OBJ group 3 ptr

Routine that hits obj group ptr's (occurs once per frame)
 - r6 = data pointer. Appears to be 0x05007a80 every time (I believe this is only called from the code below).
 - Looks like this just copies the 8 bytes starting at r6 into the OBJ group ptr reg's

yupferris

Generally, the emulator core should be more or less a black box, where you tell it to step and give it some sinks for audio/video, and it tells you how many clock cycles passed while stepping and it may or may not dump some data into those sinks. For the most part, the VirtualBoy struct already has this interface, along with AudioDriver and VideoDriver as sinks. However, it's a bit crap right now as the emu also relies on audio for a timing source, which means we can't really have a configuration that doesn't use that atm.

The reason we want to use audio as a timing source is because audio cards tend not to have timers that are perfectly synced to the computer's timer, esp. at weird sample rates. As a consequence, there will be periodic clicks and pops as the audio output buffers and the emulator go slightly out of sync. Relying on audio output as a timing source fixes this, but couples us to audio output.

It would be nice to have some kinds of abstractions; for example, a TimingSource abstraction,

yupferris

fn decompress(mut src: *const u8, dst: *mut u8) {
    // Skip first 2 bytes (they're always zero)
    src += 2;

    let original_dst = dst;

    // Load bytes_left
    let mut bytes_left = ((*src as i32) << 8) + 1;
    src += 1;
    bytes_left += *src as i32;

yupferris

Hey, so I was thinking about yupferris/rustendo64#15, yupferris/rustendo64#20, and yupferris/rustendo64#21, and I'm starting to get the feeling that these contributions might be becoming a bit too significant if that makes any sense. The main point of this project was to document all of the thought processes and resources that went into everything, and the unfortunate part of accepting certain PR's is that we lose quite a lot of that for significant amounts of code that I can't go over on the stream. So, while I certainly appreciate the contributions (they've been great so far), and I'm super stoked you guys are excited about and interested in the project, part of me is a bit on the fence in terms of accepting these.

I can also understand that I hadn't really set a precedent for what I would/wouldn't accept early enough in the project; to be honest I didn't really anticipate receiving any contributions for quite some time. This whole t

yupferris

$ fuse preview
Build started: FullCompile
Configuring
(2,250.51 ms)

Parsing source code
(376.84 ms)

Compiling syntax tree
(1,423.76 ms)

yupferris

$ ./t2-output/macosx-clang-debug-default/ProDBG.app/Contents/MacOS/prodbg 
ProDBG_create
[0:00:00.003] <570f:0> Started thread 'fs_monitor' (570f) ID 400
BgfxPluginUI::create 0x0 (1024 768)
[0:00:00.018] <570f:0> Started FS event stream for: t2-output/macosx-clang-debug-default
[0:00:00.018] <570f:0> Monitoring file system: t2-output/macosx-clang-debug-default
cerated dock grid 0x0
Unable to load data/current_layout_2.json
fastOpenKey 0x4f5
toggleBreakpointKey  0x1290