I had a few questions on how the data on the cartridge is stored. I am sure the info is somewhere, but when I searched I didn’t really see a good explanation, just “use this program”

1) By inspecting some ROM files, it seems to me that the first thing the Virtual Boy would do is go to address 0xFFFEF0 and read whatever is at that location. Then after that, it seems like it would loop back to 0x000000. Are these assumptions correct?

2) What is the significance of the information at 0xFFFEF0 other than the name of the game? Could you put anything in that space, or does each game have something significant it needs in that space in order for the game to work?

3) Any checksums or anything else tricky to watch out for?

Thanks!

mbuchman wrote:
1) By inspecting some ROM files, it seems to me that the first thing the Virtual Boy would do is go to address 0xFFFEF0 and read whatever is at that location. Then after that, it seems like it would loop back to 0x000000. Are these assumptions correct?

The Wiki has everything known about the ROM header, although it’s not really explained in plain English:

http://www.vr32.de/modules/dokuwiki/doku.php?id=info_at_the_end_of_the_rom

As you can see, the last few bytes of the ROM are dedicated to a number of “vectors”. These are tiny chunks of code used to handle hardware interrupts.

One of the interrupts is called “Reset”, although it’s also the last thing the VB does before the cartridge software gets control. The code here jumps to the start of the game/whatever (which is indeed usually somewhere near the beginning of the ROM, though not necessarily 0x0000 0000).

2) What is the significance of the information at 0xFFFEF0 other than the name of the game? Could you put anything in that space, or does each game have something significant it needs in that space in order for the game to work?

Actually, the cart name is from 0x07FF FDE0 to 0x07FF FDF3 and since every byte in that range has to have a value, it’s usually padded with zeros (according to C string conventions) though it can also be spaces or anything else.

It is not used by any VB software, to my knowledge, including the boot up sequence (I don’t think the VB has firmware of any kind, it’s just the CPU “pulling its own straps”, as it were).

Even if it’s all zeros, 0xFF’s, or whatever, the VB should still boot. For that matter, I don’t think anything in the header except the reset vector needs to be anything in particular (as long as the various interrupts remain disabled).

3) Any checksums or anything else tricky to watch out for?

Nope.

Thanks!

My pleasure 😀

Ah, thanks for that link! That should be quite handy.

As for the address values, I am a bit confused. Wouldn’t you have to divide the address you see in a hex editor in half? A hex editor shows everything addressed as bytes, but the VB cartridge has everything addressed as words. Am I missing something?

I will have to poke around the VB Dev wiki, but I’m pretty sure my questions were answered (for now at least)

Thanks for the response!

The VB (v810 CPU) addresses everything in bytes as well (address-wise), although it uses a 16-bit wide bus to the cartridge, which just means that the lowest address line to the ROM on the cart (A0) is actually A1 from the CPU. Addressing a byte (with a byte-read, or unaligned hword/word read) just tells the CPU internally whether to take the high or low byte, but all the addresses are still addressed byte-wise.

DogP