Nintendo 64 by Virtual Boy: Episode III
Hey, welcome to episode three of my series on my project Nintendo 64 by Virtual Boy. This project is about modding the Virtual Boy for a video input, and adapting a Nintendo 64 emulator to work with that input! Just in case this turned out to be your first stop in this series, I recommend checking out Episode I and Episode II first, so you have a better idea of what’s going on!
So far, I’ve been working away on bringing this project to life through a process of experimenting and developing a technical design incrementally. Last time I identified my plan to build this project in several revisions, so for now I’m working on Mark I, a prototypical phase of the project to work out the kinks technically speaking, before moving on to more advanced, but somewhat less critical work that the project overall requires.
In any case, at this point in the project, I had started making other considerations for how to really tie the project together, one thing that really came up for me was, well, what about the control system? The immediate concept that came to mind was raphnet’s Virtual Boy to USB, this would (theoretically) allow me to setup the Nintendo 64 emulator with the Virtual Boy controller hassle-free. The emulator I’m using for this project, Project64, comes bundled with an input management plugin called N-Rage, which has some convenient features that would facilitate this usage of a Virtual Boy controller to handle the Nintendo 64 at the software level. The more I thought about it, the more I realized the Virtual Boy controller was pretty well suited to controlling the Nintendo 64. You might be questioning that — and that’s more than a fair knee-jerk reaction but at least hear me out on this.
The Nintendo 64 is infamous for its oddball three-pronged controller and at a first glance the Nintendo 64’s controller appears to have heap more buttons than the Virtual Boy’s. In fact, the Nintendo 64 has 10 buttons, whereas the Virtual Boy only has 6. However, a vast majority of Nintendo 64 games anticipate their player to only have two hands — despite the controller’s design suggesting a possible three. This is the first advantage towards mapping the Nintendo 64’s controls to the Virtual Boy controller: through a toggle I can allow the mapping of the Virtual Boy’s left digital pad and left shoulder button to either the Nintendo 64’s leftmost prong (corresponding to the digital pad and “L” shoulder button) or the center prong (corresponding to the joystick and “Z” “trigger” button).
Based on that mapping you can probably already guess what I’m thinking of doing to fit the remaining 8 Nintendo 64 buttons on to the Virtual Boy (and its remaining 5 buttons). Four of the Nintendo 64 buttons, the “C” buttons are arranged in a directional layout, that is to say there is a configuration of C-Up, C-Right, C-Down, and C-Left buttons, which map nicely to the Virtual Boy controller’s secondary digital pad. This leaves the Nintendo 64’s A, B, and Start buttons which I’ll then map to A, B, and Start on the Virtual Boy, and the R button, which I’ll map to the Virtual Boy’s right shoulder button.
Not only is this layout absurdly intuitive (enough so that it almost feels like you’re using a controller designed for the Nintendo 64) it actually leaves an additional button available on the Virtual Boy’s controller, “Select”, which I can then map to either of the Nintendo 64’s “L” or “Z” buttons depending on which prong of the Nintendo 64 controller is configured to the left-side of the Virtual Boy controller. Of course, all of this ultimately could be configurable on a per-game basis to maximize functionality, but establishing such a comfortable default for the control scheme came naturally enough, and proved to me that this would work well enough as well.
In any case, I began looking into the data available on raphnet.net, and, while doing so, started out drawing some conclusions about where this project was going. Essentially I now wanted a Virtual Boy modified with a specialized VGA video input, the software for my PC to drive that input, hardware to facilitate my PC driving that input, and hardware to connect a Virtual Boy controller to my PC. Now this is really starting to seem like a project! To suit, I’m probably going to need a bigger desk with so much going on.
I wanted to design something that would cohesively house the hardware of this project, and the more I started thinking about it, the more I realized I could do. A single box that would house a VGA port (out to the Virtual Boy), a controller port, and a USB port (connecting the PC) seemed to make the most sense. This box, which would house alongside those ports, the Arduino/Gameduino solution and the circuit for the controller connection would essentially be the hub for this whole project, a sort of adapter for connecting a Virtual Boy with a PC. Overall, my overarching vision for the project now looked something like this:
Now, to call out what of this architecture I currently understand? The Mod Hub (Mark 1) and its operation make perfect sense to me, as do the connections from PC to the Hub, controller to the Hub, and the Hub to the Decoder, however once we reach the decoder, what exactly needs to happen? This is probably the most complicated region of the project’s architecture so I’d like to dedicate a full episode of this series to the dive into it, so for now I’ll procrastinate on that work, and I mean, I have a high-level understanding of what I need to do at the video decoder level: I need to provide a VGA port that accepts a signal and decodes that signal into pixel data for consumption by the Virtual Boy. So, for now at least, it’s probably fine to progress through development of the rest of the project until I at least have the signal that the decoder will accept.
Moving in a totally different direction, I’ve realized that if I set up the software-level of this project such that I can output the emulated Nintendo 64 pixel data to multiple mod “hubs” I could enable a sort of multiplayer where each player has their own modded Virtual Boy displaying the same emulated Nintendo 64! It might be a bit rough visually speaking for split-screen multiplayer, (although I’m going to try it anyways when the time comes) but I think Super Smash Bros. or Mario Party, for example, would probably work quite nicely. Is the image of a bunch of people sitting around hunched over into linked Virtual Boys hilarious? Yes, absolutely, but who hasn’t wanted to share the experience of the onset of a headache with their closest friends? Honestly though, will my friends even play Mario Party on a Virtual Boy with me? In all seriousness, as I do intend to implement this project through incremental builds, I’m probably going to end up with multiple, functional (to different degrees) mod hubs so the likelihood that I’ll end up at least trialing this multiplayer concept is pretty decent. I’m also pretty confident that the Virtual Boy I purchased for parts is going to turn out to be fully repairable, so I’ll likely have three of them to mess around with anyways.
I think I’ll wrap up this episode here, as the multiplayer possibility seems like a pretty high note. Next time, we’re going to take a dive into the deep-end and really start making sense of the video decoder component of this project, how the Virtual Boy itself works, and hopefully even get a preliminary glance into how the Arduino/Gameduino solution is progressing along for the mod hub component! Also, with any luck, I’ll have some more hardware and a better setup for my mod work at my apartment by then too. See you then!
Are you a fan of working with hardware? Like hacking? You should check out some of my other projects I’m documenting here on Medium:
◦ Assembling an Arcade, a project where I’m restoring some arcade machines!
◦ Assembling a Custom Home Theater Receiver, a project where I’m building a monster of a “home theater receiver” out of a variety of interesting parts.
