We're using cookies to ensure you get the best experience on our website. More info
Understood
@mic_Registered January 29, 2010Active 15 years, 3 months ago
7 Replies made

If you can supply some good info about the sound hardware (and other general stuff, like memory maps), I might add support for the VB to my MML compiler.

I doubt I’d be of much use for writing an input plugin for winamp though. Sound emulation isn’t exactly my forte.

Being able to log VB music from an emulator (from commercial games) wasn’t really what I was interested in anyway, though I guess some people would appreciate that.

What I wanted was just to have a format specified for VB music (be it rips or newly created songs), and a plugin for winamp that could play those files. I suggested piggy-backing on VGM since that would be one of the simpler solutions, but if a sub-format of PSF was chosen, that’d be ok with me as well.

Virtual Boy remains one of the few consoles out there (that more than 2 people have heard of) that doesn’t have a dedicated format for sound rips.

Also, like you said, all the registers shouldn’t be written 44.1k times per second, so you’re wasting ~235 bytes every time it’s sampled that it doesn’t change. Even with a 256MB buffer, that’s only ~25 seconds.

No. A VGM logger only _checks_ if there have been any changes 44100 times/second. It outputs only those values that have changed, when they have changed.

So if you had a write to some sound register, then nothing happened for 16 ms, and then another write to a sound register, the output sequence would look something like:

0x55 aa nn (output nn to register aa)
0x62 (wait 1/60 s)
0x55 aa nn (output nn to register aa)

Logging a small amount of changes isn’t too bad (like background music), but logging where there’s lots of changes, like speech takes forever. It doesn’t really have anything to do with the emu author… it’s just using fprintf to log an 8MB file a few bytes at a time is REALLY slow.

No need for printf. VGM is a binary format, not a text format. And yeah, allocating even something like 128 or 256 MB for a buffer won’t be a problem for a computer bought in the last 7-8 years.

Logging register values only 44100 times per second won’t work (or won’t be completely accurate), because the outputs depend on previous states, as well as the fact that Reality Boy doesn’t run at the correct speed (though it’s kinda close). I’ve gotta believe that dumping the entire sound register set 44100 times per second would bog things down as well.

Well, you’ve got the previous state since every write is logged – it’s just done at a fixed rate. Surely it’ll be very rare for a game to change the sound registers at more than 44100 times/second for music playback purposes.
There already exists emulators for other systems that can do VGM logging; e.g. Kega Fusion, Dega and Meka. I think there’s a version of MAME that supports it as well, and there might be others. And it doesn’t really matter if the emulator runs faster than real-time, if you keep track of the number of V810 cycles you’ve emulated you can determine how many audio samples you need to generate.

However, if there’s an open-source WinAmp plugin for VGMs, that would be a good starting point for a VBSG plugin.

There is.

And because of that, and that Reality Boy isn’t cycle accurate, you really can’t get an accurate delay value (you could count cycles, but that’ll be wrong, and you could use a real PC timer, but that’d be wrong because the emu would be running really slow

Logging only the sound registers can’t possibly be that slow, unless the emu author totally messed up the code. The point of VGM is that you log at a fixed sample rate (44100 Hz). So the emu only needs to check 44100 times per second if any of the sound register values have changed, and output the new value along with the delay (in samples) since the previous write.

The alternative to a logged format would be an executable format, like NSF/GBS etc, where you’d dump the V810 code and data necessary to play back the music, and let the winamp plugin emulate almost the entire VB. This is a better approach in some ways, but it takes a lot more work to implement.

I was thinking more along the lines of having something like VGM files (http://www.smspower.org/music/uploads/Help/vgmspec150.txt) with values to write to the VSU and delays, and the input plugin would allow listening to these files directly in winamp.

I second the idea for a winamp plugin, that would be great.