If you know how to use a voltmeter… before taking apart the system, put the batteries in the battery pack and check the voltage across the two pins on the back of the battery pack (should be around 9V if the batteries are good).

If that looks fine, check the voltage across pins 5 and 6 on the controller connector. With the power switch off, it should be 0V… then when you flip the power switch on, it should be approximately the same as the battery voltage you read straight from the battery pack. Depending on the size of your voltmeter probes, you may need to put a wire/paperclip/etc. into the holes of the connector (carefully, you don’t want to damage the contacts)

If those both look fine, then you may need to dig deeper into the system(s).

DogP

Ha… nice! Maybe you could use some flexible material like Ninjaflex to make it more comfortable… or put some foam/cloth around the edge. Nice design either way though.

DogP

TheForce81 wrote:That would mean that not every mainboard is created with the same chips?

Not really… basically, when a chip is first powered on, or reset, some registers are guaranteed to be in a specified state (i.e. the Program Counter will be set to the Reset Vector), while others are simply left untouched. It would take a lot of extra circuitry inside the chips to put every register and memory location into a known state at reset, so those that aren’t important get left in an undefined state, expecting the program to write them. Obviously they’re still 0 or 1, but simply depend on what values the transistors latch to when powered up.

In this case, most systems usually go to 0, but yours apparently usually goes to 1. It could be a sign that your chip is “lower quality” (maybe the chip was poorly fabricated, has excessive leakage, etc)… but it’s certainly not operating outside of specifications. Basically, it’s the same as powering up a RAM chip and reading back the contents before writing anything. The bits aren’t guaranteed to be all 0 or all 1.

DogP

What do you think… look familiar? 😉 So… yes, Bound High never initializes BKCOL. Putting a watch on that location, it’s never accessed, and if I write it once, it persists forever (while other VB ROMs write it during startup).

BKCOL is the “Back Color Palette”… in other words, the color of the background. Any graphics that aren’t defined as a color are transparent… usually the background is black, so whatever is transparent shows up as black. In this case, the background is bright red, so transparent is bright red. I immediately recognized that, since I use BKCOL a LOT when debugging my own programs (it’s a very simple way to output status without having to write much code – just something like VIP_REGS[BKCOL]=3; ).

I don’t think the VB guarantees this register to be 0 at reset, but apparently it usually is on most systems. But, I’d say there’s nothing wrong with your hardware… just that it behaves differently than most. One thing you could try is booting Mario’s Tennis, pull it while the system is still on, pop in Bound High (while still on)… inserting the Flashboy will probably trigger a reset… then see what that looks like. If it doesn’t reset, try turning the power off and on really quickly.

You could probably fix it with a ROM hack, though IMO it’s probably best to add the line into the source and rebuild it (since the ROM came from source anyway).

And now that you bring this up… I’m sure I’ve seen this once or twice myself.

DogP

Attachments:

1. 

   precaution.png
   

2. 

   autopause.png
   

3. 

   jss.png
   

4. 

   title.png
   

5. 

   gameplay.png
   

TheForce81 wrote:
I am pretty sure it isn’t a ROM problem, but just to be thorough I added the ROM like I flashed it on my FB and to be clear, I also used the reproduction cart that was available to buy a while ago and they both suffered the same problem.

Yep… I wasn’t suspecting a ROM problem… but there are a few ROMs out there, and I didn’t want to try chasing memory locations in a ROM that’s different than the one you’re using.

I’d have to look in more detail, but looking at those pictures… the first thing that comes to mind is the BKCOL register being set to 3, rather than 0. It’s possible that there’s something goofy with the way BH handles BKCOL (maybe it never initializes it, or writes to it when it’s not supposed to). I’ll try to look at it more closely later.

DogP

Can you take a picture of the some problem examples, and tell us exactly which BH ROM you’re using (CRC32, or where you got the ROM, etc)? If you post some pics, I’ll try to check those locations in the emulators to look for anything in common.

If I’m understanding it correctly, the game plays fine, the graphics look mostly fine, but some text and things look bad. So, the low level stuff should be fine… the displays, framebuffer, etc.

To me, it sounds like the possible problems are problems reading the graphics from the ROM, problem with the RAM used for the chars/BG maps, or a problem with the VIP or one of its signals (bad address or select line).

The ROM would be easy to check. One possible problem with the ROM could be if BH sets the ROM wait states to 1, which the other games don’t (I don’t know if BH does, and kinda doubt it). But this seems unlikely, as I’d expect more “other” problems than just problems with text.

Chars are stored in the VRM between the framebuffers, so I’d suspect failed VRM last… since the framebuffers seem fine. They are remapped into a different address space, so there could be a problem with that mapping. BG maps are stored in DRAM… my first guess would be that the DRAM is beginning to fail. What looks like a failed component could also be a problem with the VIP or its signals.

Do you have a can of freeze spray? If so, try freezing some of the components and see if the problem changes. If not, one thing you can try is putting the whole VB in the freezer, and see if it plays any differently immediately after removing it (be careful of condensation if moving it from the freezer to hot moist air).

DogP

None for sale yet, though the project is definitely not forgotten.

DogP

Yeah… I’ve been wanting to use those for quite a while (the GreenPAK4 recently came out… the others have been out for a while). Like you, I was REALLY excited about them when I saw them, but I STILL haven’t come up with a good use (I’ve tried to find a use for them at work so I could get paid to play with them too 😉 ).

I’ve put them in the “solution without a problem” bin for me… they’re probably useful for something, but nothing has hit me yet. The best thing I’ve come up with is for making a Sega Master System 3D glasses circuit: http://www.smspower.org/forums/14635-SegaCardFor3DGlassesCircuit . Have you thought of any good uses?

I like that they can run at 5V, though I really wish they could do level translation. If they could be a level translator, and perform all those cool functions, I’d have a lot of uses (it’s not clear from the datasheet, but the inputs may be 5V tolerant when run at lower voltages). The internal oscillator is also a very nice feature (one of my favorite features of the small Lattice FPGAs). And though the parts are cheap, I don’t like that they’re OTP. I’m sure I’d go through a bunch trying to get it just right.

I have been tempted to order one of their dev kits to play around with since they’re only ~$60, but figured I’d wait for a project that needed one, rather than just picking up yet another toy that I don’t need. 😉

DogP

RunnerPack wrote:
somewhere between 6 and 15 volts (lower is better)

Just curious… where did you get 15V as an upper limit? The bottom of the VB system specifies 6V to 13V. Also, it has a switching regulator, so the efficiency will be relatively flat across the input voltage (i.e. you need about twice the current at 6V than you do at 12V).

And while the current requirements depend on what is shown on the screen, the volume of the audio, etc… on the Galactic Pinball title screen, I just measured approximately 250mA @ 6V and 130mA @ 12V. So you can probably get away with a much smaller adapter than the SNES one (10V 850mA).

DogP

Yep… that’s the explanation I’ve always heard as well.

DogP

Just out of curiosity… are there any developers out there that’d even consider this? $50K is a lot of money for a small group to raise (I doubt we could find 50 people to give $1000, or 100 to give $500, or any combination to add up to $50K), but assuming that we could do it… that’s not much to live off of, assuming that there’s more than one person involved in this.

I mean… maybe some of you hate your job, are currently between jobs, still in college, or just so well off that you don’t need your job… but I can’t imagine even considering leaving my job to do this. It’d be a fun and interesting experience for sure, but surely there are MUCH better ways to make a living.

DogP

It would depend on the game, but if it was a game that interested me, I could see throwing $100 in. Of course I’d pay more to get a CIB game.

DogP

While the cartridge was expensive, I don’t think it was excessive… and I think the price was very fair considering that it was a full release that required a more expensive cartridge, and supported the developer. Even if the ROM was released, it’d only be playable in an emulator until someone made a larger flash cart… so those that purchased carts still get the benefit.

I wouldn’t feel bad if the developer decided to release the ROM, but I also respect their wishes. If they really wanted the ROM out there, I’m sure they could release it. But I wouldn’t dump and release the ROM if they didn’t want it out there.

While you could argue that the game isn’t really theirs… it’s much more theirs than mine, and for one, clearly the developer is good at this, and I hope they make more games. If they’re selling cartridges to make money, and only sell a few before the ROM gets out there, then they’re probably gonna be discouraged from doing it again. And who knows… maybe they’re redoing the characters, graphics, sounds, etc. and planning a full release. Putting this ROM out there might affect the release of that.

I wouldn’t be surprised if others don’t feel the same way as I do though, since it was sorta a commercial release… and, well… the commercial ROMs are out there.

And before anyone asks… no, I haven’t dumped it.

DogP

RP: I think I pulled the image from Nintendo Power (like these: http://www.planetvb.com/modules/articles/?s004044001 ). It’s been a LONG time since I’ve been through the NPs, but they might have that logo larger somewhere else in the magazine, or maybe a higher resolution scan of one of them would be easier to work with.

DogP

speedyink wrote:
…That’s actually really awesome. Well done! I love the foam eye piece, looks legit!

Heh, thanks!

KR155E wrote:
Haha, awesome! Too bad you had to throw it together quickly, otherwise you probably would have also ported Mednafen to Android for the full VB2 package. 😉

Man, I can’t wait for the Oculus Rift consumer version! Dev Kit 1 was pretty much a disappointment but current versions are said to blow everything else out of the water.

Yeah… unfortunately I don’t really have any Android development experience… but I’ve been seriously considering getting into it so I can program stuff for the Gear VR. I’d love to see a VB emulator on there.

I agree about DK1. I’ve played it a few times, but have always been very underwhelmed. The tracking was good, but the resolution just seemed way too low. When I saw that they got the resultion to ~1280×1440 on the Gear VR, I knew I had to try it out. It’s REALLY good. I assume this screen is what will end up on the CV1. I’ll probably end up grabbing the CV1 when it comes out, though I don’t have much of a PC gaming setup, so the portable cell phone driven system is a big plus for me.

The 3D rendering on the phone is still a bit lacking… most rendered things look like PC games from 10 years ago (good, but not ultra-realistic). I’d imagine that having the latest PC doing the rendering would be a huge improvement in realism (but then you’re tethered to your desk). Maybe I’d need a laptop in a backpack, driving a CV1. 🙂

retronintendonerd wrote:
I love this! Where can I get a Virtual Girl version? lol

That’d be awesome! It looks like you can get a pink protective skin for the system: http://www.skinomi.com/samsung-gear-vr.html , and then do a custom skin like some of the ones Marvel did:

DogP

Ah… yeah, if a cold boot gets farther than a warm boot, then a can of freeze spray (or even being very careful with a damp napkin and ice cube) could probably find the the problem component. But yeah, unless you’ve got a donor board, and the skills/tools to swap the components, it’s sorta moot.

Though really, if you’re able to solder VB displays, I’d guess that you could swap these chips. The nice thing is that the NVC and VRM are both on the top, so you wouldn’t even need to pull the motherboard from the system. Normally I’d use hot air for something like this… but with all the plastic in close proximity, I’d probably use Chip Quik. It’s just a matter of melting/globbing it on the chips, pulling them, using desoldering braid to remove the Chip Quik, and resoldering the chips.

I’d be glad to do it, but it’s probably not worth shipping all the way here to fix a couple systems… it’s probably more worthwhile to just keep them for spare parts.

DogP

The only problem I’ve personally seen on a motherboard has been a blown voltage regulator.

The video one should be easy to track down, but assuming there’s no physical short, then it’s probably a bad VPU or video RAM. You could easily write a program to test the video RAM contents, but it could just be that the outputs to the display are shorted (also easily checked). But either way, component replacement is probably the only fix (IIRC, the VRM chip actually drives the display data lines, so if I was just gonna try swapping chips, that’d be my first guess).

I’m a bit surprised that the other would work long enough to boot, and then lock up. Does resetting make it get to the same spot again, or does it need a “cool off” period? I’d verify that the regulator is outputting a clean +5V, though I doubt that’s the problem (I ran a whole VB at 3.3V, and IIRC the only complaint was from the displays). You could also verify that the clock looks good, but it seems unlikely that the crystal would start up fine, and then fail. Again, you could write a simple test app… maybe you could determine that it only locks up when accessing a certain RAM area, or executing at a certain address. You could also probe the address lines and see where it’s trying to execute (whether it’s just off in the weeds, or maybe something is constantly interrupting). My first guess would be a bad NVC though.

DogP

I still use a flip phone (“use” in the loosest sense… I spend about 100 minutes a month on it, with no text/data). So… I won’t be playing the game, but if it flows with the rest of the game, and the 3D view would be a worthwhile power-up, then I don’t see why not add it.

Maybe only a portion of your players will get the reference, but it’s kinda cool when you’re watching or playing something, and there’s some obscure reference that you pick up on, that most people wouldn’t catch. So, people besides us crazy VB fans may enjoy it as well.

DogP

I’d love to have a PVB meetup there… I go to that show every year, and should be there again this year (probably just for Saturday though).

DogP

Tauwasser wrote:

DogP wrote:
The VB already talks the same protocol as the SNES, so there’s no need for another MCU. […] If you pulled apart the SNES pad, you might be able to fix it by jumpering some wires…

Well, I’d imagine the different inputs doing different kinds of debouncing, maybe even different hold states (i.e. report pressing start only once, while D-PAD is reported continuously etc.)

So I’d say it’s a pretty big jump from “might be hot-wirable” to “no MCU required”. An MCU will definitely work. Also, you could do cool settings like “mirror right D-PAD onto left D-PAD”, have the battery monitoring right etc.

Yeah, you certainly COULD use an MCU… I was just saying that it’s not at all necessary. With no MCU it definitely will work, just with no A/B… and there are plenty of fairly simple workarounds to get A/B working. The OP was already overwhelmed by simply cutting and splicing wires like the adapters that RunnerPack and I have made… I don’t see a need to confuse things by adding an MCU and writing code to get just a bit more functionality (like those programmable controllers that always seemed like a great idea when you bought them, but never ended up using any of the extra functionality). I used an MCU to control a VB with a Playstation 2 controller and Wii nunchuk… but obviously those require translation, since their protocols are completely different, unlike the SNES.

From a quick image search… it looks like OEM SNES controllers have a V520B IC… I’m not sure if it’s actually only 12-bits, or if just has the other pins unused. It’s a 20 pin chip, like the BU3613F, so you may even be able to swap the BU3613F directly over from your donor VB controller, if you can’t use the stock V520B.

DogP