A console often summarised by its short lifespan and limited colour space. While technically correct, I believe these attributes tend to overlook other surprising properties.
In this article, I invite readers to learn more about its internal features, many of which became predominant in the market only after the Virtual Boy’s discontinuation.
The whole system is a curious piece of engineering. Externally, it resembles a bulky VR headset on a bipod. The player must place their head close to the eyepiece to see the game in action.
Internally, it’s a whole different story (and a very complicated one too). For this reason, I thought it would be better to start by explaining how this console displays images and then go through the internal hardware.
Once you switch the Virtual Boy on, you will start seeing two monochromatic red pictures (one for each eye) through the eyepiece. So far so good? Well, here is the interesting part: This console doesn’t have a screen, so what you see is more of an ‘illusion’ - Let’s dive deeper to know what’s going on.
The topics involved in explaining this (optics, visual phenomenons, etc) may feel difficult at first, but I constructed some interactive animations to make this section little more immersive.
The large volume of this console can be attributed to the Scanner, which fills up a big part of it. The Scanner is the area of the Virtual Boy that displays images. It’s composed of two Display units, each one independently projects a frame (giving a total of two frames, one per eye).
A Display unit is where all the ‘magic’ happens, it’s made of the following components:
Next to the focus slider there is a IPD dial (knob-shaped switch), which adjust the distance between the two Display units. This is done to adapt the displays to the user’s inter-pupil distance.
Now that we have each component identified, let’s take a look how the Virtual Boy manages to show images to our eyes.
If you haven’t noticed before, there isn’t any dot-matrix display to be found, so why are we seeing two-dimensional images from the eyepiece? Similarly to the functioning of a CRT monitor, Display units play with the way we perceive images:
In practice, there are some conditions for all these principles to work:
Contrary to previous video chips modelled after CRT displays (i.e. PPU and VGP), graphics on the Virtual Boy are not rendered on-the-fly. The graphics chip on this console sends the processed frame to a frame-buffer in memory, each column of the frame is then sent to the LED array for display.
Once the Servo board detects it’s time for display, the graphics chip will start sending columns of pixels from the frame-buffer to those 224 vertically-stacked LEDs, one-by-one in a strategically synchronised matter so the LEDs will have shown 384 columns during the display period. Hence, the ‘screen resolution’ of this console is 384x224 pixels.
Moreover, we need to store two frame-buffers since each one will go to a different display unit. The graphics subsystem also employs double-buffering and other quirks (mentioned later in the ‘Graphics’ section). So, for now, just remember how a digital frame is sent to the LEDs.
Consequently of this design, there are going to be periods of:
This cycle is repeated 50 times per second (hence the 50 Hz refresh rate). That means that for every frame, the CPU and GPU would have around 10ms worth of time to update the picture that the user will see. In reality, Nintendo’s engineers implemented something more sophisticated. Again, I’ll try to explain this with more depth in the ‘Graphics’ section. But for now I hoped you got a good understanding of how the Virtual Boy cleverly managed to produce a picture with inexpensive hardware.
This has been a quick explanation of how optics can turn a single vertical line into a picture. If you own or have read about the Virtual Boy before, you may be wondering when the three-dimensional imagery takes place. I just want to make it clear that none of the previous explanation have a connection with that effect. I’m mentioning this because in the past I’ve seen many places arguing that the oscillating mirrors are the cause of the ‘depth perception’, however, with all the information I’ve gathered in this study, I don’t think that claim is accurate.
That being said, I think it’s time we discuss the 3D phenomenon…
During the marketing of the Virtual Boy, there was a lot of fanfare regarding the fact this console could project a ‘3D world’. I’m not referring to images with 3D polygons stamped (like the other 5th gen. consoles), but the actual perception of depth.
In a nutshell, the Virtual Boy relies on Stereoscopic images to carry out that illusion. So this system wasn’t only capable of toying with our vision to project a full image, but it also did it in a way we would think certain drawings are closer/far away from others!
The technique is very simple: Each of the two frames displayed (one on each eye) will have some elements slightly shifted horizontally, so when we try to see them with our two eyes, our brain will think they are nearer than others. This depends on the direction the elements are shifted.
Objects shifted towards the centre of your eyes (moved right on the left frame and moved left on the right frame) will appear closer, objects shifted away from the center of your eyes will appear further away. Finally, objects with no shifting will appear between the two other. This approach is called Stereoscopic parallax.
One of the drawbacks of stereoscopy is eyestrain. This was alleviated by the fact games provided an ‘automatic pause’ system which reminded the user to take breaks every 30 min. Nintendo also wrote down various warning messages in their packaging and documentation to prevent serious conditions. In any case, there’s no way to turn 3D off.
Alrighty, we’re back to actual architecture, let’s see now how games construct the frames and music you see and hear.
The system uses a customised version of the NEC V810 which operates at an amazing 20 MHz (if the SNES ran at an average 1.79 MHz and the GameBoy ran at 4.19 MHz, I can’t wait to see what can you do with this one!). Nintendo refers to it as NVC because the processor shipped with the Virtual Boy is a combination of a V810 core with some additional components (more details soon).
The V810 is part of the V800 CPU family that NEC designed for the embedded market. While this CPU is not as popular as the competition (i.e. MIPS, 6502, Z80) it does bring a lot of cutting-edge functionality, specifically:
This is very impressive for a portable console in 1995. But if it wasn’t enough, Nintendo added extra resources:
All of this seems fine and dandy but it does have a big cost: Six AA batteries. This may explain why companies tend to hold on old tech for portable devices, at least in the 90s.
32-bit addresses look very tempting on paper, but if the system won’t use anywhere near 4 GB of memory locations, then it’s a huge waste of resources. For instance, even though the upper address lines never change, they will still be decoded for every memory read.
So, with good reasons, Nintendo cut down to 27-bit addresses. This means that up to 128 MB of memory can be accessed instead. 32-bit words are still used as pointers but the upper 5 bits are discarded. As a result, some parts of the memory map will be mirrored.
That being said, the memory map layout allows the CPU to access the majority of the components that make up this system. This includes:
This is as far as the CPU goes, now it’s time to see what can you do with it!
Let’s recap the requirements for the proper display of graphics:
Good news is that all of this is accelerated by the Video Image Processor or ‘VIP’, a dedicated chip made by Nintendo. It has some features inherited from the old PPU but I consider it a clean break from its predecessors.
The VIP may seem like another tile engine at first, but it’s much more advanced than that. For starters, it not only process graphics data but it also controls the Scanner.
Moreover, while classic tile engines rendered graphics per scan-line, the VIP relies on a frame-buffer architecture, where the final frame is stored in memory as a bitmap and then sent for display. This is closer to the modus operandi of modern 3D renderers. In fact, the Virtual Boy took a step further by using some sort of page flipping, where two frame-buffers are stored per Display unit and the scanner picks up one while the VIP is writing over the other. All of this helps to prevent image tearing.
Having said that, you can divide the VIP into three main areas:
Overall, the pipeline is very simple:
From the developer side, there are two blocks of memory used by the XP and DP:
Notice that this VRAM is ‘real’ dual-ported DRAM, not just a block of RAM reserved for graphics (which Nintendo also calls ‘VRAM’). Dual-ported DRAM enables two devices to read from it at the same time, which explains why the XP can write over VRAM while the Scanner is reading from it concurrently.
Additionally, Nintendo uses a VRAM chip nowhere to be found in the off-the-shelf catalogue. There isn’t a lot of documentation about it, but from the information described in the patent application, SAM may be stored in a separate area inside this chip. This area is presumably made of SRAM instead and contains extra circuitry to allow the Scanner to pull 16-bits at a time.
Let’s dive deeper and see now how a single frame is drawn on the Pixel Processor. For that, I’ll borrow the assets of ‘Virtual Boy Wario Land’. I strongly recommend reading about a previous tile engine to make explanations easier.
We have previously seen how traditional tile engines build their layers using 8x8 bitmaps. In the case of the Virtual Boy, tiles (originally called ‘Characters’) are stored in VRAM in an area called Pattern table. Each tile declared occupies 2 bytes, so there is enough space for 2048 of them.
In terms of colours, developers can construct eight colour palettes, four for Background graphics and another four for Sprites.
One may wonder what’s the point of colour palettes if the LEDs are monochrome. Well, this enables developers to use different shades of red. These shades are obtained by altering the brightness of the LEDs. The brightness settings are stored in two registers, which then you reference in the palettes to catalogue the different shades. The resulting palette will contain your two custom reds, plus another red automatically calculated from the sum of both, and finally, the ‘transparent’ colour.
The background layer is very simple, pick tiles to form a 512x512 map (64x64 tiles, 4096 tiles in total). Now, it doesn’t end here, because instead of having just a single background layer available… We have 14!
Each individual background layer is called a Segment. A single Segment fits in 8 KB of memory, where each tile reference contains H/V flip attributes and palette index. Each tile reference occupies 2 bytes of memory.
The Pixel Processor also allows to combine different segments to generate a bigger layer, but only a set of combinations are available. The largest mix combines eight segments.
Sprites (or ‘Objects’, as Nintendo call them) are single tiles with independent coordinates, but occupy more memory.
There is a place in DRAM called OAM with 8 KB of memory allocated, here is where sprites are defined. Each sprite definition occupies 8 bytes, so up to 1024 sprites can be declared.
Each sprite have the following properties available:
The layering system may seem simple at first, after all, the VIP provides ‘Background’ layers and a ‘Sprite’ layer. So, what else do we need?
The fact is, to display any of the previous layers mentioned, we have to place them in a ‘bucket’ called Window (also named ‘World’). A Window is the actual plane that will be rendered to the screen, it is filled with layers previously constructed. There are 32 Windows available which will overlap to form the final frame, each Window declaration occupies 32 bytes.
Windows provide different rendering modes. You can grab a Background or Sprite layer and display it as it is. For that, the Window has to be set to Normal mode and Object mode, depending which type of layer you are using. However, you can also take advantage of additional modes which apply extra effects on background layers:
After setting everything up, the Pixel Processor will start rendering the 32 Windows. Once it’s done, the final frame will be placed in the frame-buffer area. This process is repeated for the other Display unit as well.
Since the system employs a double-buffered design, the Display Processor will always fetch the frame-buffer that the Pixel processor is not manipulating, which greatly avoids tearing. On the next active period, the Pixel Processor will overwrite the frame that the DP previously displayed, and so on.
If there isn’t much to render (i.e few Windows are used), there will be long gaps between writing over the frame-buffer and the DP picking it up. This allows the CPU to make extra changes over the frame if it wants. The VIP is also prepared for this: The CPU can set up interrupts to check various states of the VIP, including this case.
On the other side, if there are too many affine Windows to render (for instance) the XP may ‘miss the deadline’ which will cause frame drops. Luckily, there are interrupts available to detect that too. In any case, the official docs provide timings each type of layer can take.
As you can see, there is a lot more technology in this console than meets the eye.
At first, I thought the Game Boy Advance was the first portable console that could reconstruct the acclaimed Mode 7 of the Super Nintendo, almost 11 years later. It turns out it was the Virtual Boy all along, five years later. But even so, we’ve seen before that affine transformations in the Virtual Boy could be applied to each of the 32 layers (although with some limitations).
Furthermore, all these new functions worked alongside the Parallax effects, something that the VIP also took care of.
I wonder what kind of games we would’ve seen if this console had lasted a little bit more, just enough so developers could get more confortable with this hardware.
Another interesting feature was that by allowing the CPU to alter the frame-buffer, it provided developers with the ability to construct their own renderer if the VIP wasn’t enough for them. This is what some games relied on to present their innovative graphics. For instance, ‘Red Alarm’ implemented a scenery constructed with polygons rendered by the CPU.
Unfortunately, fundamental issues like visible surface determination weren’t always addressed properly, I’m not sure if that was due to the limitations of the CPU. In any case, this resulted in a scene turned into a messy mesh instead, which made difficult for the player to distinguish which objects were behind others.
Imagine you grab the GameBoy’s Wave channel, multiply it by five and add a noise channel: That’s pretty much the offering of the Virtual Boy’s sound chip. You can also think of it as a sibling of the PC Engine’s.
In the motherboard there’s another chip called Virtual Sound Unit or ‘VSU’ that provides the sound capabilities. The PSG relies on internal RAM to store five wave tables and a register file to configure each of the six channels available. Registers are 8-bit wide while the internal RAM is connected to a 6-bit data bus (the CPU will still treat 6-bit words as a single byte, but the upper two bits are discarded).
Each wave is made of 32 PCM samples (encoded in 6-bit values). Channels have a panning control setting (with a volume level from 0 to 15 for each left and right) and a 11-bit frequency control.
There’s also a basic envelope control for each channel that makes the volume grow or decay over time. The fifth channel supports more effects, namely a sweeping function to progressively shift the frequency and a modulator to alter the waveform based on some values stored in the internal RAM.
The sixth/last channel can only output noise.
The mixed result is stereo with a resolution of 10-bit and a sampling rate of 41.7 KHz. It’s also worth pointing out that the console has stereo speakers, so you don’t have to wear headphones to be able to enjoy this!
This is in theory a ‘portable’ console, so don’t expect game-changing accessories (pun intended). There’s still some interesting stuff though.
Internally, every component is pretty much directly connected to the CPU, except some areas handled by the VIP exclusively.
Externally, there are two connectors available for accessories:
The controller of the Virtual Boy is very peculiar compared to the rest of the console line. Somewhat similar to the Super Nintendo one, without the ‘X’ & ‘Y’ buttons, a larger handler and an extra D-Pad on the right. On top of all this, you can’t look at it while playing.
Also, because the controller is also supposed to supply power, it comes with a removable battery magazine on the back. The cartridge is called Tap and fits six AA batteries. If users got fed up with looking for batteries after any of the six wears out, they could also to buy a different tap which connects to an external power supply.
In the case of using the latter accessory, playing with everything interconnected with cables may feel like a house of cards (specially if you can’t look at during gameplay) but I guess that’s the price to pay if you don’t want to worry about batteries 🙂.
The V810’s starts execution at address 0xFFFFFFF0H. That means that when the Virtual Boy is switched on, it will look for instructions from that address. That being said, that location is found on the cartridge ROM. This means that the game has the upper hand for the initialisation of the hardware.
Also, there isn’t any BIOS chip to be found on the motherboard, so there won’t be any operating system or any abstraction layer to help simplify operations.
For this reason, Nintendo instructed developers to perform a number of chores to ensure the proper functioning of this console, these include:
One may think that game development would just inherit the same facilities of the Game Boy (that is, stick with assembly), but it turns out Nintendo and NEC invested a lot of new technology to speed up/modernise this area.
Game studios had the option to purchase a development kit from Nintendo which included a fully-equipped debugging station, a toolchain and plenty of documentation.
The hardware kit was called VUE Development System (‘VUE’ was the codename of this console), it was a PC-like tower that contained the Virtual Boy’s internals plus 4 MB of RAM (expandable to 8 MB!). It connected to a headset (with the same shape of the retail Virtual Boy) and a retail controller. To run and debug programs, the dev kit contained an interface board that talked to an IBM PC using SCSI. To use the equipment, you needed an IBM PC/AT (or clone) with an Intel 80386, 2 MB of Memory and MS-DOS installed.
The software kit consisted in a linker, assembler and debugger. At request, Nintendo also offered a C compiler. That means it was no longer needed to write programs directly in assembly! All in all, this setup took 1.5 MB of your precious -and noisy- hard disk.
It’s too bad that this model of development was eventually reverted with the release of the GameBoy Colour. I’m guessing that this was because the Gameboy’s CPU can’t handle ‘unoptimised’ code from a compiler.
Game cartridges are called Game Paks. They have the same name of the GameBoy medium but they are completely different in terms of shape and functionality.
Due to the memory address space, the ROM can be up to 16 MB without a mapper. This applies to external RAM too (up to 16 MB). Just like the Game Boy, they can have battery-packed SRAM. The cartridge is accessed using a 16-bit data bus.
Come to think of it, 16 MB of ROM is quite a lot for the mid-90s. After all, the max size of a GB ROM was 128 KB! (without a mapper). On the other side, let’s not forget this console uses 32-bit addresses, so every pointer is 4 bytes long. This is two times the size of GameBoy’s addresses (2 bytes), so it adds up to the space requirements.
Due to safety concerns, Nintendo ordered developers to include a couple of images to mitigate eyestrain and other conditions that may arise from excessive screen time.
Games have to include a ‘read the instructions’ warning, an alignment guide and an automatic pause dialog.
These screens will appear after the console is switched on. The first one ‘orders’ the user to read the instructions manual before continuing.
The second one was some sort of a ‘test card’ that was used to properly adjust the IPD dial and the focus slider.
The third one asked the user if they would like to be remained to take a break every thirty minutes.
The first and third screen were often customised to fit the game’s theme.
I don’t think Nintendo dictated rules like this anymore until the release of the Wii.
The fact that Nintendo created yet-another variation of the Game Pak allowed them to retain control of distribution. Although, since this console never took off, bootleggers probably didn’t even bother.
Apart from that, there are no copy protection or region-locking mechanism implemented in this console. Games imported from America and Japan will work on either console. Also, assuming someone would be willing to manufacture their own Game Paks, Homebrew is also possible.
The last time I checked, Flash carts were theoretically possible but only two reached commercialisation, the ‘FlashBoy Plus’ and the ‘Hyperflash32’ (I’m not on commission! but I thought it’s worth the mention).
Throughout this series, we’ve seen all kinds of systems, some with limited CPU but impressive synergies, others with questionable hardware but beautifully packaged. This case however, was an interesting proposal: The CPU wasn’t certainly limited and the graphics were up to the task. The sound wasn’t exceptional, yet remained similar to the rest of the portable consoles in the market.
So, why didn’t many children play with it? I’m afraid a marketing study goes beyond the scope of this article. But from the technical side, I think the message just didn’t get through: At the end of the day, nobody cares for affine transformations or a pipelined CPU if you can only see red dots.
I guess that was my main motivation for writing this article, to prove somehow that innovative technology can be everywhere, even where we least expect.
I’d also like to thank the Planet Virtual Boy community for helping me with the study. They are currently working on many projects that give new life to the Virtual Boy, so I recommend checking out their forum for more info.
Finally, this has been the last article of the ‘retro saga’, the next one will return to (relatively) modern renderers, starting with the PSP!
Until next time!
This work is licensed under a Creative Commons Attribution 4.0 International License. You may use it for your work at no cost, even for commercial purposes. But I ask that you reference it properly. Please take a look at the following citation guidelines:
## Academic styles For any referencing style, you can use the following information: - Title of article: Virtual Boy Architecture - A Practical Analysis - Author: Rodrigo Copetti - URL: https://www.copetti.org/writings/consoles/virtual-boy/ - Date of publication: 12 Feb 2021 - Last modified: 21 Jul 2021 For instance, using the IEEE style: R. Copetti, "Virtual Boy Architecture - A Practical Analysis", Copetti.org, 2021. [Online]. Available: https://www.copetti.org/writings/consoles/virtual-boy/. [Accessed: day- month- year]. and Harvard style: Copetti, R., 2021. Virtual Boy Architecture - A Practical Analysis. [online] Copetti.org. Available at: https://www.copetti.org/writings/consoles/virtual-boy/ [Accessed day month year]. ## Use in multimedia (Youtube, etc) I only ask that you include at least the author's name, title of article and URL of article, using any style of choice. You don't have to include all the information in the same place if it's not feasible. For instance, if you use the article's imagery in a Youtube video, you should state either the author's name or URL of article at the bottom of the image, and then include the complete reference in the video description. ## Appreciated additions If your work has been significantly influenced by any of this site's writings, I'd appreciate if you could dedicate an acknowledgement section, just like I do with the people/communities that helped me. This is of course optional and beyond the requirements of the CC license, but I think it's a nice detail that makes us, the random authors on the net, feel part of something bigger.
This article is part of the Architecture of Consoles series. If you found it interesting then please consider donating. Your contribution will be used to fund the purchase of tools and resources that will help me to improve the quality of existing articles and upcoming ones.
Big thanks to the following people for their donation:
- Ben Morris - Colin Szechy - David Portillo - Eric Haskins - Grady Haynes - Izsak Barnette - James Montgomerie - Jan Straßenburg - Jason Strothmann - Josh Enders - Matthew Butch - Olivier Cahagne - Sanqui - Stuart Hicks - Thomas Finch - Thomas Peter Berntsen - eurasianwolf - rocky
Alternatively, you can help out by suggesting changes and/or adding translations.
It's always nice to keep a record of changes.
## 2021-02-12 - Nothing else found, time to ship it! ## 2021-02-11 - Updated front photo. - Thanks @dpt for checking out the draft. - General grammar fix. - Added intro & conclusion. ## 2021-02-09 - Private draft finished. - Thanks @guyperfect and @phire for checking out the draft. - Carlos, we need to get another Virtual Boy to do multiplayer in Mario Tennis!