It could be something as simple as dust or smoke on the lenses. I assume you could tell if it was on the outside, but if it’s on the inside, you can check once you have it open. Of course, if it’s gotten inside, it’s also probably on the mirrors and optical lenses, which will also need (careful! ;-)) cleaning.

There’s a small chance it could be the power supply not providing enough current to the LED arrays. I’m not sure how likely this is, though, since the supply is also running decoding circuitry in the arrays, and if that’s working fine, the LEDs should be normally lit. This could also be an FFC (flat flexible cable) problem, like the glitchy display syndrome, but if both eyes are affected equally, it’s more likely something on the mainboard, like an aging capacitor.

I can’t think of anything else it could be, but I hope it’s something easily reversible.

I think the black t-molding looks better, but it’s still a great idea well executed.

dentaku wrote:
Thanks, will try cleaning it.

Anyone has a picture of how the medallion looks like?

Here’s the thread about Hedgetrimmer’s homemade medallion:

http://www.planetvb.com/modules/newbb/viewtopic.php?topic_id=3639&forum=

About the controller: if it resets when you move it, it could also be a broken wire in the cable. Once you eliminate all other possibilities, open the pad and test it with an ohmmeter or continuity tester. Fixing it might be a lot of work, but if you end up replacing it with another pad, you could make it into a USB pad 😉

Vaughanabe13 wrote:
At this point I don’t know if it’s worth all the work I will still have to put into the project. This place is practically dead these days anyway and with the 3DS out and the Flashboy Plus (which didn’t exist when I started the project) I don’t really see much of a reason for this product to exist anymore.

It would be a shame not to finish it, considering how much has been done. At the very least you should open-source it so other interested parties can finish it. You could even put an official Open Source Hardware (OSHW) logo (see attachment) on it 😉

I would love to take the SRAM part, get rid of the SD card, maybe use a simpler microcontroller, and end up with a simple USB ROM emulator cart that can be written really quickly. It could even turn the VB on and off if you powered the VB through the cart port. It would be great for rapid testing during development.

Attachments:

1. 

   openhardwarelogo.png
   

MineStorm’s right; it would be fairly easy to print one/have one printed, but if you use a home printer like a makerbot or reprap, you’d have to get rid of the pivot posts and use a metal pin or machine screw(s) in their stead.

Excellent modeling work, as usual, Hedgetrimmer! I can picture a few different ways to machine it, but it’ll take at least two CNC passes (and maybe a custom work holder) and probably some manual drilling steps. Can you post an STL (preferably ascii)?

Your intended order is fine with me; keep ’em coming! 😀

I can’t really help you find a replacement, but I wanted to mention that I also bought a used stand with this problem. You say the VB can still be used with it like this? I assumed it wouldn’t hold, so I’ve never tried it (I already had a working stand, but it has since fallen victim to the other, more common breakage).

Maybe Hedgetrimmer (and/or I) could work on an aftermarket replacement…

VirtualJockey wrote:

RunnerPack wrote:
Your palette is a little off at the top end, too. You should make sure there’s no green or blue at all. I fixed it and also scaled/cropped it to actual VB screen dimensions. See the difference between the brightest red in mine and the kind of purplish pink in yours? It might not be detectable on your monitor, depending on your settings, but I saw it immediately (y’know, after I got done saying “awww, cute widdle puppy” ;-)).

Thanks. You are correct, I haven’t calibrated my monitor since I had to replace the mainboard. My colors were off a bit (my red must be too high, and blue too low on my monitor) and I didn’t even touch the contrast (fail on my part).

Thanks again. looks much more like VB than mine.
Pic saved, and I will cherish it. :thumpup:

You’re very welcome; I’m glad you like it. 😀

It would probably look even better if you started over with the original image. You could probably get a better “VB-sized” section cropped out, and it would eliminate the artifacts created when I scaled down your already-dithered image.

Of course, best of all would be if you had a stereoscopic image of this or some other cute dog…

Your palette is a little off at the top end, too. You should make sure there’s no green or blue at all. I fixed it and also scaled/cropped it to actual VB screen dimensions. See the difference between the brightest red in mine and the kind of purplish pink in yours? It might not be detectable on your monitor, depending on your settings, but I saw it immediately (y’know, after I got done saying “awww, cute widdle puppy” ;-)).

Attachments:

1. 

   vbpuppy.png
   

Lester Knight wrote:
I wanted to ask about the UPC code, is it real? if i were to scan it would it report back “planetvb.com” or something?

http://www.planetvb.com/modules/news/article.php?storyid=307#comment545

Hey, that is great news, Rex! Way to go, VJ! :thumpup:

VirtualJockey wrote:
There comes a point in time when oxidation attacks all non-optical gaming consoles.

Actually, I’ve experienced the deterioration of the aluminized surface of CDs, too, so oxidation is really a problem for all systems (and pretty much any physical thing, including biological).

Now I wonder if there are any hard-core collectors that keep their stuff in a nitrogen-filled vault 😛

Salient quote: Matthew 6:19-20

Ryphecha, developer of Mednafen, mentioned on IRC that a patch blitter submitted to fix a Mednafen bug he found during development of this library has been incorporated into the current WIP. Due to the recent login problem, it couldn’t be posted, so I am doing so now.

Here is a link to version 0.9.17.1 WIP:

http://forum.fobby.net/index.php?t=msg&goto=2100&#msg_num_9

Yay! It’s finally out of IRC and into the wild 😉

This looks like it has enormous potential for making games look better and/or run faster! I’m sure the “CopyBits” function could be useful in areas besides graphics, too. Everything is really well commented, too, so dig in!

For those who don’t frequent the IRC channel (i.e. lamerz ;-)), blitter helped me alter this so the 8KB (!) table of dither patterns remains in ROM, which saves space in WRAM. If you set the ROM to one wait-state, it shouldn’t be any slower this way (although testing still needs to be done to be sure). The trade off of ROM vs. RAM space (in the original version, the table can be compressed in the ROM) is now up to you!

You’ll find the modified files attached below. BTW, the ROM in the package is compiled with the “Mednafen fix” enabled. See main.c to know what that’s all about 😉

Attachments:

1. ditherrom-20110405.zip

Oops! I forgot to reply! 😉

I haven’t looked at this yet, due to time constraints, but it’s on my todo list. While it sounds a bit limited right now, I can see this becoming a very useful and powerful tool. Thanks for sharing!

DogP wrote:
Cool… that’s great to hear. Is this able to be “packaged up” and distributed, or does it need to be built? I haven’t gotten a chance to mess with it in quite a while, but I don’t think my build worked… or I didn’t have my build scripts and stuff set up properly.

Yeah, there are a number of folders (“bin,” “lib,” etc.) that can all be put in a containing folder, just like the original windows version with the batch files. Although, I think it would be a good idea to include “make” (or another build system), since batch files just don’t cut it. An alternative would be to include a custom IDE, or a “plugin” for, e.g. Visual Studio.

I was chatting with dasi and blitter in IRC, and there seem to be some problems with the included linker script and crt0, so it still needs a bit of work for full functionality, but the main hurdle is behind us.

It’d be really nice to be able to just download a package, plunk it somewhere, add the correct environment variables, then go (maybe even have an installer do it for you). An example or two would be nice as well, to make sure the build works, and for a base to start from.

DogP

I’ve long wanted to learn how to make NSIS installers; this might be my chance 😀 Now accepting submissions/votes for examples to include 😉

DogP wrote:

blitter wrote:
Might want to try removing the “CFLAGS=-Wno-error” from the binutils phase in the GCC 4.4.2 build script,… I think I left that in there from the Mac build– it’s necessary there for some reason.

Thanks… that seemed to fix that problem. I think I got it built, though I haven’t compiled anything with it yet. There were a couple other things I had to do as well. One difference is that it now needs libiconv installed. The other was a strange error in LDFLAGS during build, where it’d complain that LDFLAGS changed while being built, though they were actually the same, just somehow there was an extra space in the string. I ended up manually removing the space in config.cache (in gmp IIRC). There’s probably a better way to do it, but I didn’t feel like digging too much.

Thanks,
DogP

I just built 4.4.2 last night under the version of MSYS/MinGW distributed by the RubyInstaller folks as the “Development Kit” (I needed it for a Ruby thing, and it’s a bit easier to set up than the stock MSYS).

I didn’t have to remove -Wno-error or install libiconv (unless it comes with the devkit; but I’m pretty sure I saw one of the “configure” scripts not finding it, so I dunno). The only problem I had was the LDFLAGS one, and I fixed it by editing the Makefile.in to include $(strip …) around some of the “LDFLAGS=…” lines. I think I know how to fix the problem “correctly”, so I might submit a “patch for the patch” so to speak, someday. The main thing, IMO, is to get a new, state-of-the-art, VB devkit in the hands of the developers, so we can all start that community project on the same page.

BTW, as a test, I successfully built one of my VB projects by only modifying the makefile to point to the new location of the binaries (v810-*). I haven’t compared the machine code output with that produced by the cygwin-hosted 2.95 version I had been using (which was built by dasi, IIRC), but the ROM ran identically in mednafen.

1. SNES
2. Virtual Boy
3. TurboGrafx-16/PC Engine
4. NeoGeo
5. DS (But I’ll probably change this to 3DS if I ever get to play one ;-))

NB: I don’t currently own #3 or #4.

DaVince wrote:
VEGETA, WHAT DOES THE R-ZONE SAY ABOUT HIS POWER LEVEL

IT’S MOST DEFINITELY UNDER NINE THOUSAAAAND

Sorry, I couldn’t resist once I saw that picture. 😛

:thumpup: 😀

As I said on IRC, it is indeed 3.8mm. I’ve found that the cutting type of pliers can usually get the screws out. The pointy ends of the jaws fit in the little notches, and you can turn the screw if you’re careful.

However, you might have further difficulties once you get it open. I don’t know for sure, but I’m assuming the FB+ uses a button cell with solder tabs welded on, just like the official carts. If this is the case, your “off-the-shelf” cell can’t be used directly, without some kind of mounting that can be soldered to the board. There might be a tutorial online about attaching standard batteries to a game cartridge. I would do a search on “Game Boy battery replacement” and the like. Of course, if yours is the kind with solder tabs, just ignore me 😛

This is an old thread about an old, unofficial version of the ROM. The latest ROM, built from the actual sources with an official compiler, is 100% correct, as far as anyone knows; there should be no more bugs that aren’t part of the code itself (and none have been reported, so far).