@mbuchman:

Good job on the buttons. I’m curious, though: why did you cast new buttons and dye them? Couldn’t you just dye the original buttons/dpads?

Also, my brother and I are planning to make some “Foosball” players and we need some material ideas. We can make masters and molds, but what type(s)/brand(s) of resin, etc. did you use, and what kind of prices are we looking at?

@Hedgetrimmer:

LOOOOOVE the pad half model! Are you doing the inside and outside of each half, or just the outer shell?

I hate to say it, but the controller is one of my least-favorite parts of the VB. The d-pads are too small and have sharp corners, and the shape is just completely wrong for my hands (I have largish hands with rather long fingers, but the pads still seem way too far apart). I’ve been trying to come up with a “mutated” SNES pad (best pad evar!) with dual d-pads and symmetrical Sel/Start/A/B button groups. So, if you ever model an SNES pad, make sure and send me a copy 😀

Thanks, Hedgetrimmer.

http://www.vr32.de/modules/newbb/viewtopic.php?topic_id=3158&forum=4

I know it’s not the shade itself, but I had this lying around on my HDD and it’s vaguely relevant, so I figured I’d post it…

If you set it to 76.2 dpi (30 pixels/cm) you can print it out full size. I’ve known people to make these out of cardboard (there may still be a post here about it…).

Attachments:

1. 

   eyeshade.png
   

@Johnny

I would not suggest using VB dev’ing as your first introduction to programming. Find a good beginner’s C tutorial or maybe a tutorial on the basics of programming itself. I would start making simple command-line programs and such until you feel comfortable with concepts like variables, functions, loops, and conditionals.

Then, when you can read and understand C code, get familiar with the VB’s internals and the code in the “standard” (and I use the term loosely) VB library, and look at some of the example code out there.

Also, when you do start a VB project, make sure and post questions here (or even if you need help on a command-line “Hello World” or something, of course that would go in “Off-topic” ;-))

@ V.Chris

It’s definitely coming along. I’m glad you’re still working on it.

Did he give you the tracking number, or just send you updates on its location via email?

Because, if you had the number, and it was a scam, wouldn’t the USPS have to be in on it?

Thanks, Dan!

I was thinking you might be able to use a modified version of the algorithm for the water in your Zelda game, but I kinda like the minimalistic water effects in the Zelda series…

I think it would work best (turned 45 degrees and with perspective applied) in a Wario World-esque, fixed-perspective, side-scrolling, 3D platformer or a River City Ransom/TMNT-style beat-’em-up (I’ve always thought the VB really needed examples of both genres).

I’m not saying that you should work on these kinds of games, I’m just putting ideas out there 😀

KR155E, my man! Thanks for the kind words (not to mention the front page headline :-o)!

Well, I knew it wouldn’t be quite right on hardware, but I let someone test it on their Flash Boy and he didn’t report it as being that bad… (I really need to fix my flash cart so I can tweak my code and try out the other cool home-brew out there.)

Have you tried both ROMs in the archive? I thought they each used different timing settings (It’s using vbWaitFrame :/ I know…) but they seem to be about the same in my (sloooooow) Reality Boy, so I don’t know…

Also, sorry about making you reverse-engineer the button map. I don’t know where my head was when I was writing the readme 😛

Wow, thanks! That’s high praise indeed, coming from the master of VB dev and being compared to the master(s) of SNES dev! 😀

It’s definitely a good start :thumpup: (I like the heading names :-)) and I hope you keep working on it.

It could use some formatting/style (like bold headings) which I assume is forthcoming. Also, why is the example code an image? Maybe a “pre” tag is in order? There is also a tiny typo:

“…make a folder called ggcvb and put it in your c drive…”

Now, about the content itself:

I know about your BASIC background, but you probably shouldn’t be advocating using labels and “goto” for C programs (I haven’t even used those much in my BASIC programs). The following would be much better:

vbDisplayOn();
vbDisplayShow();

while (1) {
    // Infinite loop to prevent reboot
}

Maybe with an explanation as to why not putting one’s game code inside an infinite loop results in a reboot.

At the very least, vbDisplayOn() and vbDisplayShow() shouldn’t be inside the loop…

When you polish this up some more, you should think about adding this to the Wiki.

Keep up the good work!

EDIT: I started writing my post before mbuchman posted his, but I agree with pretty much all of what he said 😀

Pretty good video. Some kind of voice-over would have been nice, and it might have been a little closer to the action (although, if your camera can’t focus that close, that’s fine). I like the close-up, too. If that’s the same camera that took the video, that’s the viewpoint I would have used.

Also, I saw some flux bubbling there; did you apply that before the video, or was it just the core of the solder? I pre-fluxed, but it kind of made a mess (I don’t have any no-clean flux or flux cleaner).

Your method uses a bit too much solder and braid for my tastes… I just tinned the tip of my iron really well and kind of gently scraped at the cable coating, and it worked fine (you have to scrape away from the cable like you did with the braid, though–learned that one the hard way! 😛 ). I didn’t even have any bridges that I couldn’t remove with a clean iron. I did kind of go overboard and probably took off too much of the cable, but I wanted a good connection and I reinforced the joint, anyway.

Once again, good job on the video.

Good idea for a thread, Chrisse! 😀

What about the two-character manufacturer codes?

I think I always put “AB” in my demos, so I would like to “claim” that one, if you’re going to keep track of them.

Also, I noticed you used “VB2D” for your BLOX 2 demo, even though it supports languages besides “Deutsch”.

Maybe “M” should be used for the last letter, or perhaps a digit specifying the number of languages supported.

Just a thought…

Yikes! That really does look like a blow-torch hole! Makes you wonder what goes through someone’s head as they decide to do stuff like that…

I’m glad those two finally found a home with someone who knows how to take good care of them 😀

I daresay you could probably even fix that torched display cable, if you had some time 😉

Also, I actually did read about the NES reset circuit (and watched the video). I even left a comment (two, actually…) that are still awaiting moderation 😛

Regarding Hack-a-day: have you submitted your reset circuit to their tips line? They would go crazy over it. It’s exactly what they look for in a hack.

Congrats on your Franken-VB! 😉

That is weird that you found two VB’s that had been monkeyed with! Where did you get them?

Out of curiosity, could you take some pictures of the destroyed display cables? Maybe they could be added to a what NOT to do to fix a glitchy display 😉

I really like your blog. It’s well written and I love reading about other people’s hardware hacks (hackaday.com is in my favorites bar 😉 ). I can’t wait for the article about replacing the clone’s CPU/PPU. 😀

mbuchman wrote:
1) By inspecting some ROM files, it seems to me that the first thing the Virtual Boy would do is go to address 0xFFFEF0 and read whatever is at that location. Then after that, it seems like it would loop back to 0x000000. Are these assumptions correct?

The Wiki has everything known about the ROM header, although it’s not really explained in plain English:

http://www.vr32.de/modules/dokuwiki/doku.php?id=info_at_the_end_of_the_rom

As you can see, the last few bytes of the ROM are dedicated to a number of “vectors”. These are tiny chunks of code used to handle hardware interrupts.

One of the interrupts is called “Reset”, although it’s also the last thing the VB does before the cartridge software gets control. The code here jumps to the start of the game/whatever (which is indeed usually somewhere near the beginning of the ROM, though not necessarily 0x0000 0000).

2) What is the significance of the information at 0xFFFEF0 other than the name of the game? Could you put anything in that space, or does each game have something significant it needs in that space in order for the game to work?

Actually, the cart name is from 0x07FF FDE0 to 0x07FF FDF3 and since every byte in that range has to have a value, it’s usually padded with zeros (according to C string conventions) though it can also be spaces or anything else.

It is not used by any VB software, to my knowledge, including the boot up sequence (I don’t think the VB has firmware of any kind, it’s just the CPU “pulling its own straps”, as it were).

Even if it’s all zeros, 0xFF’s, or whatever, the VB should still boot. For that matter, I don’t think anything in the header except the reset vector needs to be anything in particular (as long as the various interrupts remain disabled).

3) Any checksums or anything else tricky to watch out for?

Nope.

Thanks!

My pleasure 😀

There are many reasons you can’t get a perfect image from a composite source (or even SVideo, though it’s much better quality).

For one, the image is RGB in the console, but NTSC uses a whole different color space. It describes colors in terms of their hue (basically the wavelength; think “Roy G. Biv” ;-)), saturation (how “pure” the color is) and brightness. The conversion between color spaces is subject to precision losses both ways.

Also, since the color TV system was tacked on to the existing B&W TV standard, called RS-170, most of the bandwidth of the transmission line (the yellow-ended cable from your console) is devoted to just the brightness. This is why colors can shift and smear while the basic “gray” part of the picture (the brightness) stays the same. SVideo solves this by putting the “luma” (brightness) and “chroma” (color; hue+saturation) on separate (hopefully shielded) wires. Component video is the next step up. It splits the chroma into two separate signals, for a total of three. It has about three times the bandwidth of composite and is about as good as NTSC gets; unless you count the balanced cables they (used to) use in TV stations and the like.

Finally, since all of this image data is represented as a voltage on the aforementioned wire, any electrical noise that changes that voltage affects the image – hence my recommendation to use very short cables.

Before I got a digital camera, I used to use a camcorder and capture card to take photos. If my subject was motionless (e.g. eBay photos) I would capture multiple stills of it and then use software to average them together. Since the image I wanted was the same, but the noise changed each frame, this cleaned up the image quite a bit. I still had to fix the histogram, sharpness, etc., of course, but it was a big boost in quality.

That brings up another thing: don’t hesitate to try post-processing your images. It can be especially effective on the older consoles, since you know what the original should be like (e.g. the NES is limited to 16 colors).

I hope you can get something to fit your needs.

It seems to work fine for me no matter what direction it faces (except that the empty space behind the periscope collides ;-)). What’s wrong?

I haven’t use the Sega glasses, but I have shutter-glasses for my PC. I’ve also played “The 3D Battles of World Runner” for the NES, which uses a similar system for the 3D mode (it alternates the left/right images, but also changes the palette so that the left image is shades of red and the right is shades of blue; for use with anaglyph glasses).

The picture quality is probably not as good, especially if you are sensitive to flickering images (I can’t even stand to look at a 60 Hz computer monitor for very long…) since it basically halves the frame-rate of your TV.

Also, it may not even work if you have your Master System/Mark III hooked up to an LCD or Plasma TV.

To expand a bit on what DogP said:

The VB (like most digital displays) produces grey shades using pulse-width modulation (PWM) which means it turns the LEDs in the arrays on and off, at full brightness, for differing lengths of time. This oscillation can induce spurious currents in nearby wires and, as DogP said, the disconnected rows of pixels will behave differently based on what their neighbors are doing. This is also exacerbated by the fact that the VB uses a synchronous, serial transmission system to shift pixels into the LED arrays.

While it would be difficult (but not impossible) to assign certain colors to specific sprites, we aren’t necessarily restricted to just four colors, either. There are four palettes for BGMaps and another four for Objects, so you could in theory have 25 on-screen colors (every palette has three colors; color 0 is always transparent).

I once had idea that takes this to the next level: use some otherwise unused (or read-only) memory locations in the VB’s memory map to allow homebrew games to assign their own colors for each of the palettes (or maybe even for each individual Character).