Original Post

The only thing I wasn’t able to nail down in the Sacred Tech Scroll was the algorithm behind the pseudorandom noise generator in the sound processor. The one resource we have that says anything about it, well, isn’t very informative. But! Thanks to dasi’s help running my test software and recording the sound output, as well as help from a blast from the past, we have the answers!

What dasi was able to produce for me was a .wav file of the first few seconds of random noise, played with a particular setting at a particular frequency. This is what the first tenth of a second of that file looks like:

Obviously, the voltage in that signal decays after being set, but the data is pretty clearly there: any time it’s above 0 it’s “up”, and any time it’s below zero it’s “down”. See that narrow spike around 0.06? That represents a single bit of “up” status, and gives us a measurement for how wide a single bit is in this waveform. Using that, I was able to scrawl on the picture to produce its status for every bit starting at the beginning:

Again, the signal decay makes for a weird curve, but we can pretty plainly see what’s going on: we have 8 ups, then 7 downs, then 1 up, then 8 downs, then 3 ups. That, my friends, is the original digital signal that came out of the noise generator.

DogP wrote a program a while back by doing much the same work dasi and I did. He made recordings of the various sound settings, then picked through the resulting .wav files to figure out what the original digital signal must have looked like. Don’t worry, though, he wrote a program to do that for him. He didn’t spend weeks staring at an audio editor like this.

As it turns out, DogP used his findings to write a program. It was an audio emulator for Virtual Boy, and he released the source code. Within that code, there was a large byte array that contained the ups and downs for every string of bits that the noise generator would produce. I was able to use that list as a reference while reverse-engineering the original algorithm.

For example, the following is the first few bytes in DogP’s program: 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3F, 0x3F, 0x3F. See what it is? It’s 8 ups, 7 downs, 1 up, 8 downs, then 3 ups.

Only problem is, that’s something like 50 KB of data encoded in 0x hexadecimal format. That’s big, and is not mathematically defined. That’s where I come in. (-:< To be fair, I had some help. Martin Korth documented the NES’s noise generator, and that gave me a starting point. Virtual Boy’s is not identical, but it’s very similar.

The details of the Virtual Boy’s noise generator are as follows:

* There’s a 15-bit register. The right-most bit is bit 0, and the left-most bit is bit 14.
* All bits in the register are initialized to 1s, presumably when you specify the sequence length.
* At the specified frequency, bit 14 is pulled from the register, inverted (1 becomes 0 and vice/versa), then used as output.
* After the output is determined, two other bits from the register are pulled out, then XOR’d together to create a new input bit.
* The entire register is shifted to the left 1 bit, and the new input bit appears in bit 0.

So which two bits are pulled out and XOR’d together? I’m glad you asked! One of them is always bit 7. The other bit is specified in the VB’s noise control register, which is at address 0x01000554. You can specify one of 8 positions, known to some as “tap locations”:

* 0 = Bit 14. Will produce 32767 bits before repeating.
* 1 = Bit 10. Will produce 1953 bits before repeating.
* 2 = Bit 13. Will produce 254 bits before repeating.
* 3 = Bit 4. Will produce 217 bits before repeating.
* 4 = Bit 8. Will produce 73 bits before repeating.
* 5 = Bit 6. Will produce 63 bits before repeating.
* 6 = Bit 9. Will produce 42 bits before repeating.
* 7 = Bit 11. Will produce 28 bits before repeating.

All of these figures are the same as the ones in DogP’s program. What this means, then, is that we are another step closer to mastering the mysteries of the Virtual Boy! \o/

  • This topic was modified 11 years, 6 months ago by Guy Perfect.
1 Reply

Whoops, got ahead of myself. I’m no longer allowed to go back and edit that post for correction, so I’ll post the correction here.

Bit 14 of the shift register is not used as the output. That was NES that did that. In Virtual Boy, the output bit is the inverse of the result of the XOR operation.

For example, if bit 7 and bit 14 are XORed together and the result is a 0, the output is 1. The 0 is then shifted in on the right.

I apologize for the misinformation. (-:


Write a reply

You must be logged in to reply to this topic.