Original Post

Hello all. I’m trying to find out if it is possible to somehow hack into the VB’s video outputs (for each display) and reencode them to put them on a tv. I have done some electronics work, and built an encoder device for converting arcade video into ntsc/pal signal. Has anyone tried anything with hacking the VB display? ANY IDEAS? I can’t find anything online anywhere about this. What I would do is reroute the display signal from each display thru a circuit that would recolor it (one blue, one red) and then bring those two carriers back together for the final image signal. I am excited to find out what if anything has ever been tried. Thanks in advance for the input. I KNOW this is possible. Just maybe not easy… πŸ™

13 Replies

I too have thought of the idea of outputting a VBs display to a monitor, but like most of my stuff I haven’t gotten around to actually doing anything about it.

I was also considering using red/blue (or similar), or maybe even LCD shutter glasses.
The problem would be determining the VB LCD protocol. For that I would need some kind of DSO or data logger.
Your best bet would be to somehow store the image, then retransmit it at the correct display rate. VB is 50.2Hz, which makes it pretty much useful for PAL. NTSC would be too fast for it and you would get display flickering I imagine.

I’ve also just thought that RGBS SCART would be perfect for it. It needs no newline/screen commands used in the NTSC/PAL standards, just R, G, B and sync signals.

Anyway, enough rambling. Hope some of that helps. πŸ™‚

RGB+Sync is all my NTSC/PAL encoder circuit needs to generate a valid signal. The fully-produced circuit can be made for around $50 too. Its the same kind of circuit used in a JAMMA ‘Supergun’/’Supernova’ type device for arcade games. If we can somehow acquire some semblence of an R+sync…hmmm…that’s interesting…because I can feed a signal speecifically to any color I want to…so I *could* send the signal from one display to the encoder’s R circuit, and the signal from the second display to the encoder’s B circuit! Problem solved!! The Red and BLue can be created and linked by this one circuit!! I was really crunchin on how that could be feasibly done…now…all we need is the signal, REGARDLESS of it’s frequency, my circuit will correct it to NTSC/PAL. Wow, I am excited that others have thought about the prospect of this.

Hey, am I mistaken or weren’t there some actual units made that had a single-screen kiosk like arrangement, like maybe they were used at E3 or Spaceworld? I remember seeing a stand that had a VB, and a display so that the observers could see what was going on! I know this can be done!! I remember seeing it!

What an awesome thing it would be to be able to finally play/watch VB on a big screen…no more neckaches! Wow.

Anybody else out there that can help? I know we can do this!

There were units made called Video Boys. They were used by Nintendo/third parties to display the image (as PAL) on a TV screen.
They are very rare, and even if we can find someone with one, I doubt they’ll be willing to crack it open so we can see how it ticks. πŸ™

Only way seems to be either to get hold of a DSO, or make one yourself and see what line is what.

A. The VB doesn’t generate an analog signal like a TV, arcade, etc.

B. The thing you saw was called the “Video Boy VUE” and it’s basically a VB with a different video chip that does put out an analog (PAL, anaglyph) video signal. There was also an add-on board for the VUE debugger that displayed like this.

C. The signal it does generate would be a lot harder to convert than you may realize…

I won’t try to explain the VB’s display system in detail here, especially since I’m quite tired… But, as a summary:

It’s scanned the other way: the screen is made up of columns, instead of rows (“lines”) like the vast majority of raster displays.

It’s digital, with a combintation serial/parallel interface. The pixel brightness is varied by PWM; pulse-width modulation. Also, since the mirror’s velocity is a sine function, the relative width for a given brightness varies from the center to the edges.

The hardware (the vibrating mirror) is actually the “master” to which the display is synchronized, again, unlike most other displays. It’s analogous to the vertical sync pulse being generated by the vertical coil driver in a PC monitor, instead of by the video-card.

If you still want to give it a try, I (or other members; DogP probably being the most knowledgable in this area) can give you more details.


I knew it would be hard…maybe not THIS hard…but I’m open to ideas. I do want to pursue this, but I’m by no means an electronics engineer or rocket scientist.

I would suggest learning about CPLD’s, PAL’s and FPGA’s, because it’s going to take either a custom chip or a big PCB full of off-the-shelf ones to do this.

I would suggest using a microcontroller, but, if there is one with enough inputs and speed for this, it’s likely going to be quite expensive.

Then, to learn how the video system works, take apart a VB and hook up a ‘scope/analyzer/what-have-you and take a look.

I really wish I had the money, equipment, and time to do this myself. But, if you can make them for a reasonable price, I’ll gladly let you do the work πŸ˜‰

Good luck!

I read on one site something about other people trying to address this display issue, and one thing proposed was to create a ‘terminal cart’ that would itself capture and provide a bitmapped version of the displays. Perhaps it could be done like the Game Genies of old, having the actual game plug thru this cart?

Also, something that has been running amuck thru my mind is whether anything can be gained by examining carefully the coding that the emulation programmers have employed to display this video. I mean, it’s working for them right? They obviously had to handle this same problem of generating a viable display from a series of LED blink patterns.

Anyway, is it possible that it would be greatly more feasable to do this via a plug-thru cartridge instead of directly modifying the VB? I am interested in this prospect, but concerned that nobody has done it…so there must be a reason that it can’t possibly work… πŸ™‚

Well, the emu’s work because they don’t even use the “LED blink patterns” in the first place. They operate on a higher level where the “BGMaps” (backgrounds) “OBjs” (sprites) etc. are. They actually emulate the VIP; the chip that draws the “Worlds” and generates those LED signals.

I don’t see a way of using a pass-through cart, unless it also emulates the VIP, and patches the cart’s ROM to write to it instead of the VIP’s registers/memory. It would be possible, but probably not easier than replacing the “scanner” (the collective name for the LED arrays+mirrors+lenses) with a video converter. But, maybe a PC could emulate the VIP (since there are many versions of that same code, already) and the cart would do the patching thing, and send the data to the PC for rendering. (Through the expansion area of the cart’s address space.)

Basically, all you have to do is make (for each eye) a buffer that can hold one frame of data, something to convert the data and fill said buffer, and another thing to scan the buffer and produce a signal in the desired output format. I would go with VGA. The vast majority of monitors (including arcade ones) and projectors should be able to handle 384×224. Or, the circuit could paint a black border around it to make it 640×480. Also, like you said before, you could just hook the left one to the red signal, and the right one to one or both of the other two and have instant anaglyph.

I’m trying to figure out how to make a distinction of what data belongs where in the buffer, so as not to start late and end up drawing at the start of the output what is actually in the middle of the display image or something along that line. Do we know if there is any actual sync signal? I know you said that the “vibrating mirror” is master, so it has to somehow know when to be in a certain position, right? I’m just trying to get a grasp of what horrors lie ahead. I have to assume that for there to be a constant viewable display produced by the VB, it needs a means of syncing itself accurately and with precision. Something has to feed the mirror array…

I’m either gonna know a whole lot more about electronics when I get done with this, or I’m gonna be a card-carrying VB hater… πŸ˜‰

I suppose if all else fails, just replace the existing LEDs with waaaay brighter ones and replace the eye pieces with powerful (red/blue tinted)magnifying lenses…then just play the vb in a dark room and it’ll project onto a wall…acquiring accurate convergence may be a problem…but hey, since I’m joking about this vb-projector idea anyway….

I’m trying to figure out how to make a distinction of what data belongs where in the buffer, so as not to start late and end up drawing at the start of the output what is actually in the middle of the display image or something along that line. Do we know if there is any actual sync signal? I know you said that the “vibrating mirror” is master, so it has to somehow know when to be in a certain position, right?

Actually, the servo just vibrates the mirrors back and forth at a rate determined (I think) by a crystal in the VB. There is an optical interrupter (LED pointing at a phototransistor) that senses when a flag, attached to the mirrors, is in a certain spot. This signal goes back to the VIP which then knows when to start changing the LEDs.

There’s also a syncronization system used to communicate with the LED arrays, themselves. The arrays aren’t just a bank of LEDs with a common cathode, or something. That would take too many wires. Instead, the LEDs are divided into groups and attached to the (latched) parallel outputs of a set of shift registers. Each of the SR’s has an input, but they all share a clock (and latch strobe.) And, actually, there is the equivalent of a common cathode…

FWIW, I hope you learn electronics instead of hating the VB…

Your projector idea is great (I’ve thought of it myself) but you’d have to emulate the above-mentioned chip. (Which wouldn’t really be that hard…) As for convergence: just use tri-color LEDs (or fiber-optics to mix two regular ones) and bounce the two images off of one mirror.

Actualy it would be trivial to remove the optics in front of the display and replace them with a magnifying glass. Than if you placed a fiew mirrors strategicaly in front of the display you could project the image back to the user at a much larger dimention. Go look at some older arcade cabinents for more on this idea.

It might be posible as well to feed a small amount of voltage to the LED array to increase the overall brightness of the display (like 0.5v to 0.8v) but your not going to make a 10′ projection with the VB displays.

You could also get two B&W cameras (cheap and really sensitive to red) point them into the VB (or rig up special, modified optics) and project their images through colored or polarized lenses.

But, now we’re getting pretty far off-topic πŸ˜‰

Yeah, I’ll hold out for a pure, beautiful, ultra-crisp SVideo-outputted version. Now I need a spare vb to disembowel and some “electronics for dummies” books… πŸ˜›


Write a reply

You must be logged in to reply to this topic.