.VBOY File Format – Nintendo Virtual Boy ROM

Introduction

A .vboy file is a copy of the ROM in a cartridge for the Nintendo Virtual Boy (1995), a table-top stereoscopic console with a 20 MHz NEC V810 (NVC) processor. There is no magic number and nothing is added by the dumping tool. The ROM is a power of two in size (up to 16 MiB), and the CPU sees its last byte at the top of the address space, 0xFFFFFFFF (also 0x07FFFFFF: the console ignores the top five address bits). The data the CPU needs when it starts therefore sits at the end of the file, at the same CPU address whatever the size: the game header 0x220 bytes before the end, the interrupt and exception vectors 0x200 bytes before it, and the reset vector, a jump, in the last 16 bytes at 0xFFFFFFF0.

Everything before the header is the program and its data, loaded at 0xFFFFFFFF + 1 - size, and mirrored through the 16 MiB window 0x07000000–0x07FFFFFF.

Recognising a ROM

Because there is no signature, the explorer decides by the extension and, where the extension is shared, by the structure:

• .vboy is unambiguous: any file of at least 0x220 bytes that is not plain text is shown as a Virtual Boy ROM, with its problems marked (a size that is not a power of two, a title that is not text, a reset vector that is not a jump).
• .vb is also the extension of Visual Basic source. A .vb file is taken for a ROM only when its structure says so: a power-of-two size from 16 KiB to 16 MiB, a title of printable ASCII or JIS bytes in the header at the end minus 0x220, and a reset vector at the end minus 16 that is a JR into the ROM (or a MOVHI/MOVEA sequence with a JMP). Visual Basic text, an empty file or random bytes are refused. The registry row lists the Visual Basic entry first.
• .bin is never claimed.

What the viewer shows

• The header fields (title, reserved bytes, maker code, game code, version), with the title’s bytes checked for text.
• The vector table: all 32 slots of 16 bytes at the end minus 0x200, the thirteen defined vectors labelled (VEC_GAMEPAD … VEC_RESET) with the first instruction of each and, for a JR, where it goes; unused slots are marked.
• The memory map, the hardware control registers (SDLR, TCR …), the VIP registers (INTPND, DPCTRL …) and the layout of the video RAM.
• The whole ROM disassembled with the NEC V810 decoder, an instruction at every even offset, with the entry (where the reset vector goes) marked START, the vector slots and the jump targets from the vectors labelled, and a load or store whose base register was just set by a MOVHI/MOVEA pair (the usual way to reach 0x02000010) given the register’s name.
• Options: the CPU address of the first byte (by default the ROM ends at 0xFFFFFFFF), ROM mirroring, the entry point, and the decoder’s four (mnemonic case, register names, condition names, pseudo-instructions).

How this was checked

• Built ROMs. Byte arrays with a header, vectors and a few instructions cover every branch of the header and vector reader, the options, the damaged cases and the acceptance rules (test-vb-built.mjs), and fifteen .vb and .vboy cases go through the real engine, with Visual Basic source (including a real file of another program), text, empty and random files as negatives (test-registry-damaged.mjs).
• The site’s Virtual Boy core. The compact core of the emulators.org Virtual Boy page loads each built ROM: its reset address, the ROM mirrored through the 0x07000000 window, the header and vector bytes at the addresses we give, and the reset jump landing where we say, agree for four sizes (1 KiB to 1 MiB).
• The demo ROM. The only real Virtual Boy program on this machine is that page’s 1 KiB demo; it parses, and its code decodes to what its assembler source says.

Not described

Known, not yet covered

• The VIP and VSU: the frame buffers, characters, background maps, worlds, objects and palettes, and the sound waveforms and channels are not decoded (later work).
• Save RAM on the cartridge and the link cable are not described.
• The exact register assignments and the meaning of every hardware register: the names are listed and the meanings are brief.

Unknown

• No retail ROM and no real .vb or .vboy file was found on this machine: every .vb found is Visual Basic source. The viewer was tested on built ROMs and the 1 KiB demo, which has no header (its title bytes are zero) and is below the 16 KiB the strict .vb test needs.
• The header and vector layout follows the brief for this work, taken from the Planet Virtual Boy documents and the Sacred Tech Scroll, which could not be read here, and the emulators.org core. The title’s character set (ASCII or JIS) and the maker-code conventions are not confirmed against a retail ROM.
• Whether every game’s reset vector is a JR: the strict .vb test accepts a JR or a MOVHI … JMP sequence only; a ROM that starts another way is still shown when named .vboy.
• The viewer follows no jumps (every even offset is decoded) and does not separate code from data. It was not run in a browser by its author.

Links