Original Post

Has anyone thoght about adding two other leds to this to try and get more colors. Its strange to me that a 32bit system ony uses 4 pallets of color. I get that it was rushed in development and they wanted to cut cost, but surely they must have had a way to implement more colors into not only the software but hardware as well. I really want to build a chip that can go into the virtual boy to add more colors by intercepting the data from the games before it goes to the eyes and basically runs an emulator to add more colors to the games along with 3 color leds. has anyone else thought about doing something like this?

11 Replies

The Virtual Image Processor (VIP) in the Virtual Boy is only capable of outputting monochrome images. I doubt the VB hobbyists here will make a color version that can output better graphics, but Nintendo’s own attempt was too expensive in 1995, so they just used red LED’s as they were the cheapest kind, and that disappointed everyone from the beginning.

Its only monochrome because they limited it to 4 pallets of color with it being 32bit it should be in therory able to run 32 pallets of color. After tearing into about +10 of these guys it seems to me they had plans to add more colors. Basically you have a 32bit system running at 4 bits. I really want to make a full color virtual boy if not at least as many colors as the gba playing original gameboy games.

In 1995 it was a matter of availability of other colored LEDs. The VB would have needed to be delayed by a year or two for it, which obviously wasn’t happening with the push to get it out before the n64

You’re not the first person to want a full-color VB, but the only realistic way to do it is through emulation. Even then, it would be shoehorned in, since the original games – and, as has been explained before, the system itself – only produces monochrome images.

You don’t seem to understand what a palette is (or how to spell it), the concept of bit width in a computer system, or how many LEDs are in a VB (224 for each eye, on 1cm-long silicon dies, which also contain demultiplexing and driving circuitry). But I’m looking forward to seeing what you come up with! 👍 Keep us posted!

  • This reply was modified 3 years, 3 months ago by RunnerPack. Reason: I guess the old emoji codes don't work anymore…

Whilst this might divert from the original question for making the virtual boy full color, would it be possible to replace the red led/eyepiece with green led/eyepiece to make the ‘Game Boy’ virtual boy?

  • This reply was modified 3 years, 7 months ago by XKizuha.

I guess so! Remember, the VB suffered from one problem: eyestrain. So it’s probably a good idea to not make the green LED’s too bright then. At least this was the case for mid-90’s technology, can newer LED’s cause less problems?

I think I heard once that red causes less eyestrain than green or blue. Replacing the red LEDs with the white ones that currently exist would probably be cool, if possible. It’s probably possible for the VB software to use more than a 4-color palette, but the output would still be black and 3 shades of red. Having a larger palette does have some interesting potential uses, though, and I’ve been thinking about it. The question is if those uses are worth the big hit to memory.

But a Virtual Boy will never be able to output more than black and 3 shades of red. There is supposed to be some hardware trick you can do to make different columns of pixels have different brightnesses, but that doesn’t seem like it’d have a whole lot of utility. A Virtual Boy Color would effectively be a different system, and would need more memory and probably a slightly faster processor. I would love nothing more than to see something like this happen, but I assume everyone with the skills to make an alternate past-future tech like that is retired, pretty well-off, and would have no desire to work on our pet projects. It’d be like asking someone to make an Atari console after the 7200 but before the Jaguar.

  • This reply was modified 3 years, 5 months ago by Knightcrawler.

I know it’s probably a no, but what if there was an interpreter in the middle?

The argument I keep reading here is, Virtual Boy is only capable of four shades of mono (but in red due to red LED) basically. Well the little handheld that could from 1989 called Game Boy was only capable of four shades of gray basically too. Yet come mid-life of the SNES we got Super Gameboy.

All those pre-existing games could have a color palette swapped in over the top of the original mono output, they were preset or made by the user, and then later games had SGB colors installed minimally and upwards towards the meatier selection that Donkey Kong 94 had.

It makes you wonder, could someone pop something in the middle here, to allow VB, even if it’s not done on a VB itself, to do something similar. For years they’ve had a way to emulate the SGB in a SNES emulator, where you just feed it the GB game and it goes.

As I said in my previous post: “the only realistic way to do it is through emulation”, which is essentially what you’re talking about. The way the SGB worked is by assigning different colors to the four shades in each of the GBs four hardware palettes. The VB has twice as many palettes, plus a way to change the color used to clear the screens before drawing. Since the programmers weren’t constrained as to how to use them, it would be a little more work to map them correctly for each game, and might even require hacking the games to get the best effect, but it could be done. However, it has to be done before everything gets converted to four shades for the displays – which happens inside the video processor – hence why it would have to be done with emulation.

Of course, the OP’s original question was about giving the VB a color display with which to show these new colors, which would be extremely difficult and expensive (unless you simply gutted the VB and crammed some small TFT displays inside).

I like that this topic is being discussed, though. Let’s keep brainstorming!

Here’s my crazy idea:

First, make a display that essentially contains three VB displays, one for each primary color (RGB), but with the light emitters very close together.
Second, figure out how to cram three VBs inside one casing, with two of them somehow slaved to the third.
Third, modify the games to run on the master VB (we’ll call this one “RED”), but send separate graphics to the other two (GREEN, and BLUE) to generate the other two color channels of the display, synchronized with RED’s graphics.
The result: 6-bit RGB video (64 colors; see attachment)

Before building one, it could be emulated to prove the concept. The displays would probably have to be built like my idea from this post: https://www.virtual-boy.com/forums/t/different-vb-display-color/#post-995351


So in this case… a single cartridge slot would send data to all three Virtual Boys simultaneously, and the “Red” Virtual Boy would keep the other units synchronized using a passthrough EXT accessory. Hypothetically the other VB units could be housed in a “console” unit that is tethered to the main “Red” unit. Obviously you would need a new “port” to get the display cables from “Green” and “Blue” to connect to the headset.

Possibly… another solution would be to somehow get a single unit to flip between multiple sets of LEDs. But because the mirror is constantly moving, this switching would need to be done incredibly quickly, or you’d have the colors smeared from one pixel to the next… I wonder if the VB is capable of incredibly-fast timing like that.

The other two VBs wouldn’t have a direct connection to the cart. They’d likely just have a small boot ROM that listens for commands over a shared communications channel (probably with a higher bandwidth than the link port, like a shared address in the Ext. area of the bus). They’d be synchronized by all running from the same crystal oscillator (which DogP already laid the groundwork for many years ago).

I don’t think it’s possible to squeeze enough performance out of one VB to time-multiplex the color signals, though (but I’d love to be proven wrong!)


Write a reply

You must be logged in to reply to this topic.