We're using cookies to ensure you get the best experience on our website. More info
Understood
1,430 Replies made

I have a similar story. I work for a company that remanufactures electronics for the agricultural and earth-moving equipment industries (things like dashboard displays and engine/transmission controllers). When asked during my interview about experience that would make me a better candidate for the job, I mentioned repairing VB displays to make them better than they were originally engineered. I don’t know how influential it was in getting me the job, but most of the interviewers did want me to go into quite a bit of detail about the process.

It’s a great job, too. I’ve been there less than a year and I’ve already gotten a promotion, two raises, and three bonuses, not to mention the many benefits and perks.

Has either of these VBs ever been carelessly disassembled? I once received a VB for repair that had obviously been opened. One of the displays only had one screw holding it in. When I powered it up to test the completed displays, the mirrors made a similar loud buzzing noise. Upon further investigation, I found the missing screw… it was stuck to the magnet of one of the galvos!

Moral of the story: check your galvo magnets for debris.

brunorog wrote:
– The “purpose” of using an original cartridge is just to use the original connectors?

That is correct.

– The only reason to keep the original board of the cartridge is because that we need the “circuit” that talks to the cartridge pins? (this doubt is actually based on above topic).

You don’t actually have to use the PCB from the cartridge, unless it has SRAM you’d like to use for the games that can save your progress. However, if you don’t have a PCB to replace it with, it will be difficult to keep the two sets of pins from touching each other.

– Is it possible to build an “ugly” VB “cartridge”, just using the EPROM to connect to the VB hardware, without too much electronic procedures? without the cartridge and it’s pins.. I mean…any way to connect the EPROM (after loaded with a valid VB ROM) directly into the videogame?

You might find it very difficult to fit the parts and all the necessary wires inside the VB itself. It would also make it impossible to use a standard cartridge, unless you include some kind of switch to disable the internal ROMs.

Finally, you have the problem of the solderable pins on the VB’s cartridge connector being a few mms away from a metal shield and facing the wrong direction, which will make it very difficult to route the wires. You could remove the cartridge connector itself from the mainboard to use its vias, but at that point you’re definitely doing more work than just making a cartridge out of an old Mario’s Tennis (or whatever).

If you don’t want to hand wire the dozens of connections needed, you should learn to use a PCB layout program (such as Eagle or KiCAD), and have some cheap boards made by one of the online board houses (e.g. OSH Park). Or, if you have access to a laser cutter, you can make your own PCBs with blank copper-clad board, “rattle-can” spray paint, vinegar, salt, and over-the-counter 3% Hydrogen Peroxide.

Let us know what you come up with.

FWIW, my guess is that the CoB (“blob”) was just a blinker circuit for a standard LED (possibly blinking in a special pattern instead of just a steady rhythm), and the large number of batteries was just to increase runtime so it wouldn’t have to be switched on/off all the time (since it was part of a fixed display stand, rather than being worn on one’s person).

Just my two cents…

That’s a nice bit of reverse-engineering, Guy!

I wish I had more time to play around with your VSU tool; it looks pretty handy for experimentation.

speedyink wrote:
Runnerpack offers this service for North America.

Sorry, speedyink (and CJZEPP), I can’t spare the time to do these repairs anymore. I’ve been planning to post an announcement to this effect, but I haven’t gotten around to it, so I guess this is it 😛

I could be wrong, but I think HP Lovethrash said he was doing them.

Credit where it’s due: I didn’t really work on this at all, much less for three years… All I did was consult with the author about how to implement some stereo display modes and make a few other miscellaneous suggestions.

It is a very well-made piece of software, though. I’m no artist, but it seems well worth the shallow learning curve if you want to do good pixel art quickly and efficiently (especially in 3D).

In case anyone needs them, the label dimensions are about 2-1/16″ x 1-11/16″ or 53 x 43mm.

DogP wrote:
That sounds really cool… just curious about a couple things. Is this something for a casual user, or is it really aimed at the “professional” (i.e. is it quick and easy to learn, will it help the average VB homebrew programmer, etc)? In the free version, is there anything critical missing for us VB’ers?

Like most things, it does have a bit of a learning curve, but not too bad if you’ve used many paint programs. It will take you a while to master the more advanced tools, but the 3D tools are all fairly straightforward.

BTW, I found a list of things you can only do in the paid version.

What is the “process” to go from drawing to displaying on the VB? Currently, my process is draw (or steal) bmps, convert to 4 colors, then convert to chars and BG maps. Does this program really just accelerate the drawing of animation frames, or are there other optimizations like reducing the number of unique chars, dithering, etc?

It is designed from the ground up to support drawing with limited numbers of colors, so the color reduction process is unnecessary. It can save all of the standard raster formats, so it should work with any existing VB conversion tool. It has tile mapping features, but it doesn’t write BGMap data directly. It does have a plugin system, which includes file I/O, but I haven’t explored its full capabilities.

The online help has a good section on using tile maps.

Is this program widely used for actual retro game programming (homebrew communities like us), or just “retro” style flash games and stuff. Obviously there are a lot of differences between making something look retro on brand new hardware with practically no limitations, rather than on the old hardware which actually has limitations which forced it to look like that.

AFAICT, it’s been used for games on “retro” systems back when they were “modern” (it seems to have Game Boy specific support, for example) as well as modern games by companies like WayForward and Ubisoft.

I’ll be able to post more about it after I get a copy of the latest build and have a chance to play around with it. And, hopefully, some of the more experienced artists on the forum will give it a try and post their thoughts, as well.

Lester Knight wrote:
the difference is that the push for VR headsets and games specifically designed for VR hasn’t been as popular as it is right now. if it is going to happen, this seems like this would be the gaming generation to make it possible.

Not to contradict you, Lester, but I think the popularity is finally there because the technology is finally there to make it commercially viable. We are now at a point where the tech is able to pull VR off in a comfortable, affordable, and approachable way. That’s why I think it will actually take off this time. It still might end up being somewhat of a niche market for a while, but so were mobile phones for quite a long time, so…

To drift even further off-topic… I can’t wait until someone writes a “Virtuality” emulator for whatever Rift-clone I end up getting 😉 I never got to try it back in the day, and then they all but disappeared. Now that there are a few in private hands, my dream of experiencing Atari Jaguar-level graphics in VR form is still alive! 😛

Ditto on what L_E_T said, plus it’s great to see the source and check out the VBJaEngine syntax ahead of time. Loving the parallax scrolling, BTW. It really shows how much a stereoscopic display can add to a game’s visual design.

The animation of the character is great, too. The only thing I’d add is the torso bobbing up and down a bit while walking.

You need a 5V regulator, but the stock regulator also produces a POR (power-on reset) signal that must be emulated for the VB to boot. Also, if you use a switching or LDO regulator, and keep the input voltage low, you should be fine with no heatsink.

Although I have yet to try it myself, I want to add my own to the chorus of well-deserved thanks. It’s hard for me to even find time to play games, and you guys are spending your own to make them accessible to those of us unable to read Japanese!

Tauwasser wrote:

RunnerPack wrote:For IR, the transmitter just needs a transistor to blink one or more LEDs at the right rate. Actually, I would use two set up like an AND gate. One input would be the 38KHz (or whatever) carrier generated by one microcontroller pin, and the other would be the actual data coming from another pin.

The receiver is even easier, since you can just use one of those IR receivers they put in consumer electronics (which can be had for pennies or even free if you can scrounge) to demodulate the IR back into a stream of data.

No matter what medium you use, this sounds like a very fun project!

Well, and you need analog filters, probably simulate them, and you have the usual IR problems, i.e. lost button presses, noisy environment, other IR sources screwing you, etc.

I’m not saying it’s impossible, but it’s definitely more involved, because you need to know your stuff, the various encoding schemes etc.

Actually, the IR filter is a commodity part, as I mentioned. You just get one of these (or, like I said, scavenge one out of an old DVD player, etc.) and whatever binary signal your 38KHz-modulated IR LED is blinking out will show up on the output pin (although usually inverted, as these are almost always open-collector). It’s simple ASK, just like those 433MHz radio modules, but without all the FCC nonsense.

Yes, you do need some kind of protocol to carry the actual button data, but there are plenty to choose from, or you can make up your own (which is part of the “fun” I mentioned, because I’m an engineering nerd :-P) It’s not even hard to incorporate error-detection/-correction to mitigate the problems you mentioned. Reed–Solomon would be a good choice, for example.

HP Lovethrash wrote:
Oh and RunnerPack, are you sure IR wireless for Virtual Boy is a good idea? Look at all the complaining people already do with “What? It only has red LEDs??”…next thing you know, they’ll be saying “These guys only made infrared wireless?? Why couldn’t they just make it infra-full color?”

LOL!

On the subject of Bluetooth, I found this. It is a BT SoC, like Tauwasser mentioned. I don’t think it can do host mode, but the auction listing claims you can connect two of these modules directly in some kind of “Ad-hoc” mode.

The best part is, being an SoC, it has a microcontroller on-board, plus plenty of I/O lines. If it can be reprogrammed, it could be all you need for both ends of a wireless controller solution.

I haven’t yet found a description of how to replace the default firmware – or even a confirmation or denial that it can be replaced – but it only makes sense that it can be. For one, the auction mentions how much Flash it has on-board (1MB, which is far more than you’d need for a wireless controller). Worst-case scenario: you have to add a $2 ATtiny to each one.

I did find out that the HC-06 module is slave-only, whereas the HC-05 can be master or slave, so be careful which module you get. Also, be sure you don’t get this, as it’s only a carrier board containing no actual radio circuitry.

BTW, another option would be to go WiFi using an ESP8266 module. I know for a fact that the processor can be reprogrammed on those. The 80/160MHz 32-bit processor on-board is waaaay more power than you need, but it’s so cheap, there’s no real reason not to.

I think Tauwasser’s idea to use the ISM-band radio modules makes the most sense for use on an actual SNES (or VB). AFAIK, there are no cheap BT host modules you can use for the receiving end. BT would be good if you want to play an emulator on a PC or smartphone with an original (but wireless) controller, though.

BTW, Tauwasser, why did you ask “why does it have to be RF?”, and then only offer RF-based solutions? I thought you were going to say something about IR, which is what I’d use if I wanted to make a wireless VB controller, since the distance is short and the line-of-sight angles are already sorta restricted.

As with the RF modules, you’ll need a microcontroller to read the buttons on the transmitter side, and one on the receiver side emulating a shift-register. The two can talk via the aforementioned RF modules, IR light, or even sound if you use ultrasonic transducers (but it might interfere with your Power Glove ;-))

For IR, the transmitter just needs a transistor to blink one or more LEDs at the right rate. Actually, I would use two set up like an AND gate. One input would be the 38KHz (or whatever) carrier generated by one microcontroller pin, and the other would be the actual data coming from another pin.

The receiver is even easier, since you can just use one of those IR receivers they put in consumer electronics (which can be had for pennies or even free if you can scrounge) to demodulate the IR back into a stream of data.

No matter what medium you use, this sounds like a very fun project!

  • This reply was modified 9 years, 9 months ago by RunnerPack.
  • This reply was modified 9 years, 9 months ago by RunnerPack.

astro187 wrote:
1.) MOST IMPORTANT QUESTION: What general technique do you use for these tiny wires?

Your technique is okay, but it really helps to have a source of external flux, rather than relying on what’s inside your solder. This goes for 99% of all soldering jobs, so you should definitely invest in some rosin paste (it’s super cheap from the usual online retailers).

Another method would be to tin the wires, then twist them, then just heat them until their respective solder coatings fuse (adding a little solder, if needed).

2.) Which wattage iron should I use?

Generally, lower wattage for smaller masses of copper, but higher wattage just means you have to work faster.

3.) Something seemed to be getting burned in the middle of the wires, well away from the colored insulation. What even was that?

I think they include plastic (nylon?) fibers in the wire to make it stronger. This is another reason tinning each wire end first is a good idea.

4.) Did you guys heatshrink each individual wire, then the cluster, or electrical tape the small wires and heatshrink the cluster, or do something else?

I don’t remember exactly how I did it, but I didn’t heat-shrink the “cluster”, because I put the wire joints inside the shell of the power switch. I also kind of “potted” them with hot glue. Come to think of it, maybe I coated the joints with the glue, too…

I hope that helps.

Lester Knight wrote:
How cool would it be to get a modern 3rd party controller for the VB that included a built in AC adapter?

I have thought of this very thing before. In fact, I’ve come up with not one but two backward-compatible schemes for getting “analog” information into the VB through the existing controller port. My first idea has been on the Wiki for a few years, and I just posted the other one.

Thanks to crowdfunding, 3D printing, cheap low-volume PCB fabrication, falling LiPo battery costs, ubiquitous and easy to use microcontrollers, and the availability of cheap replacement parts for commercial controllers; this is an idea whose time has come.

astro187 wrote:

RunnerPack wrote:
Roli got it right, but here it is in a nut shell:

1. Connect all ground (-) wires together (VB, controller, and AC adapter).
2. Connect the positive wire from your AC adapter to one side of the switch.
3. Connect the other side of the switch to the battery input of the VB (not the +5V wire).
4. Connect all other controller wires to their corresponding wires on the VB (latch, data, etc.)

The reason you’re measuring 14V at the AC adapter is that the adapter is unregulated, and the volt meter doesn’t provide much of a load. You’re seeing what is called the “open circuit” voltage of the adapter. Once it sees a load from the VB, the voltage will be closer to what is printed on the sticker. Even if it did provide 14V under load, the voltage regulator in the VB could handle it.

So that all makes sense and I think that should about take care of it. One small point of clarification. You say to connect all the grounds for the VB, controller, and AC adapter. I presume you then connect those to the ground terminal of the switch?

Thanks for the kind (though a bit profane ;-)) words.

A switch has no “ground terminal” (although sometimes the frame of the switch is grounded for safety). On the switch itself, there are only two terminals which are either connected together or not, depending on the position of the lever/rocker/etc. One is “hot”, and the other is either “hot” or disconnected. Connecting either one to ground would make a dead short, along with some heat, smoke, and possibly fire 😛

Just connect the three ground wires together and insulate the connection so it can’t touch any of the other wires. Insulate the other connections, too, of course.

Roli got it right, but here it is in a nut shell:

1. Connect all ground (-) wires together (VB, controller, and AC adapter).
2. Connect the positive wire from your AC adapter to one side of the switch.
3. Connect the other side of the switch to the battery input of the VB (not the +5V wire).
4. Connect all other controller wires to their corresponding wires on the VB (latch, data, etc.)

The reason you’re measuring 14V at the AC adapter is that the adapter is unregulated, and the volt meter doesn’t provide much of a load. You’re seeing what is called the “open circuit” voltage of the adapter. Once it sees a load from the VB, the voltage will be closer to what is printed on the sticker. Even if it did provide 14V under load, the voltage regulator in the VB could handle it.