Hi All!
I’m Pete. I’m admittedly programming illiterate (though I know some theoretical computing!), so please excuse my layman’s post. I really applaud you all and admire your dedication to making some really cool projects for an underrated system.
I own a few Virtual Boys and have worked as a stereoscopic technician for films/TV, etc. So I am very stereoscopically literate.
Anywho, I was wondering if anyone knew how possible it would be to modify the Virtual Boy hardware to accept a live signal – down-res’d to the VB’s native resolution. Essentially making the VB a monitor.
This is essentially for a wild idea/project I had in mind. So if anyone wants to know more I would love to pick your brain for a bit.
We can discuss here, or if you want to email me, feel free to do so at peter@coolfossa.com
Or if you are an NYC local, I’ll gladly take you out for a coffee and chat some VirtualBoy!!! π
Thanks All!
I’m not an expert on the hardware, but it’d definitely be a nontrivial effort at best. Each VB display is actually a single column of 224 pixels, reflected off a mirror that is oscillated back and forth to produce the full image you see when looking into the unit. The mirror servos are driven by custom Nintendo chips so you would basically have to recreate that hardware from scratch.
Doing it in software might be more feasible if you wrote a video player for the VB that looks for video information in cartridge RAM. A lightweight codec like Cinepak might work for this purpose. But even then you’d have to mod the cartridge to allow for an external hookup and possibly a buffer, and that would also be an involved effort.
Thanks for the reply!
Yep – I know this one is certainly going to be a challenge, but the harder the better! π
I wouldn’t need to alter the mirror system/servos, I don’t think. I would just need my signal to match the refresh of the strip of LEDs in the chip.
And yep, I figure I would have to find a way to hardline out from the board itself. Unless there is some way to signal into a modded cartridge (a la FlashBoy USB). But like you said, the buffer time would probably be problematic π
Welcome, Pete!
blitter pretty much covered the bases, but there are a few existing projects that you might be able to glean some info from:
First up, on the “send image data to an unmodified VB” side, there’s the “VeGL” project. This is a custom library running on a PC which is used to render stereoscopic graphics in a familiar, OpenGL-like way. The results are sent to the VB via its 2-player link port, which is connected to the PCs LPT port (remember those? ;-))
Second (and third?) are a pair of hardware projects (here and here) with the exact opposite aim: getting the video generated by the VB into a format displayable on a TV or VGA monitor. Should be lots of goodies to be had there.
Finally, Sprite(TM) recently posted this article about driving strings of RGB LEDs using the LCD header of a single-board computer (running Linux). Something similar might be a good way of generating a VB-like video signal.
Keep us informed on this. I, for one, would be very interested in seeing what you come up with! I have the mechanical parts (lenses, mirrors, servos, etc.) from a dismantled VB that I’ve been trying to find a use for (although I’m leaning toward a laser vector display…). I would be especially interested in the possibility of using it to display more than four shades of red (or, ideally, in some other color).
I’d say you’re almost certainly going to need dedicated hardware to drive the VB display with full resolution at full frame rate (running it over the link with compression works for special cases, but not the general case). The bandwidth needed for full resolution @ 50hz is about 2MB/sec.
If it were up to me, I’d do it with a USB interface to a cart, where you transfer the pixel data from a PC to the VB, and let the VB write it to the framebuffers (code running on the VB). Even that may be a little bit difficult to do, since the maximum bandwidth to the VRAM from software is ~10MB/sec, which doesn’t include fetching the data from the USB interface. You’d certainly want a tight assembly loop running in cache. One of the simplest circuits that I can think of that’d would work is an FT2232H in asynchronous FIFO mode. But that’s only 8-bits wide, so you’d be fetching twice as often as would be ideal. Having a FIFO in front of that to pull in data to be read out 16-bits wide would help, at the cost of more complexity. Overclocking the VB could help. Otherwise, limiting your requirements could also help (run at half the resolution, 25hz, etc.)
The other option of driving the displays directly is much more difficult (IMO) because you need to recreate the hardware to interface with the displays, you need exact timing, and don’t forget about correcting for angular velocity (typically corrected by the column table). You’d almost certainly be using an FPGA to recreate what the VB hardware already does for you. The advantage of it would be that you could set your own horizontal resolution (not fixed at 384), and could adjust the brightness on the fly whenever you want.
DogP
Has somebody ever tried to do some sort of camera like the Gameboy Camera? Maybe there is a way to even use 2 GB Cams and hack something togehter?
Thanks for all the responses, guys.
A lot of good stuff here.
I think a good starting point is getting more familiar with the VB, it’s guts, and how it functions (circuit-wise).
I just bought 5 of them for a steal (most “broken” or with display problems, but we all can fix that). So I’ll have some units to spare/practice on.
In the meantime, if anyone has any good recommendations for literature (textbooks, websites, etc) that can give me a good grounding on some practical programming or circuitry that I’ll be likely to encounter – feel free to share! π I learn pretty quick and am not afraid to be confused!
I’ll also be crossing my fingers that another batch of flashboys will be whipped up sometime soon! π
-Pete