We're using cookies to ensure you get the best experience on our website. More info
Understood
@dogpRegistered July 25, 2003Active 7 years, 4 months ago
1,461 Replies made

i assume it is not possible to stream roms from the pc? like using it to transfer binaries to the vb out of ultra edit for testing during game development? for this purpose, this would even be faster way than the flashboy.

I’ve considered that… but you definitely couldn’t stream the ROM in real time. If the program was small enough you could load it into WRAM, but that’d be limited to 64KB minus the size needed for variables and stuff. I do have a lot of SRAM chips, so I’ve thought about making an SRAM only cart that could be loaded over the link cable, but I’m not sure that it’s worth the hassle when loading a flash cart doesn’t take that much time, and usually the emulator is sufficient.

As for the PC-link cable, I would like to try out that OpenGL – Virtual Boy thing. And a doom version whichs connects to a vr32.de server would be awesome too 😉

I hope Alberto is able to get the OpenGL driver working for his Virtual-E project… that’d be really cool! I do agree about an online FPS… that’d be sweet to have an online deathmatch on the VB 😎 . Next time I order parts I’ll have to get another USB module so I can modify one of my link games to link over USB, and make a PC app that’ll pipe the data over the internet. Then it’ll be up to someone to make an FPS 😉 .

Would it also be possible to use it to stream the video ram to the PC to use the PC as a VB display (reverse Virtual-E project )
That would eliminate the need of a TV-out adapter 😀

STFU! 😛 Heh, no… you couldn’t really stream the video RAM to the PC, for several reasons… one is that you wouldn’t be able to have the game running, so you could stream a single screenshot one at a time, but it wouldn’t really be playable while streaming. Also, you’d have to modify every ROM that you wanted to output over the link port… and the speed couldn’t do full framebuffers at anywhere near the full frame rate (without very good compression, which would take a lot of processing power, which would slow down transferring data).

DogP

I haven’t gotten a chance to try it out, but what exactly does it do? Does it convert graphics to a header file (like the Map Constructor in VIDE)?

DogP

The VB could definitely do a raycasting engine… Wolfenstein style w/ no problem, Doom should be doable… I don’t know about a voxel engine… I’ve never seen source code for one, so I dunno what’s really involved. I wouldn’t think it’d look very good w/ only 4 shades anyway though.

DogP

One more thing that’d be nice is the ability to import an image larger than 512×512. We can do larger by combining BGMaps, but doing it manually is kinda a pain (need to remap the BGMap to point to correct places in the charsegs, unless you want to waste multiple charsegs)… and inefficient since there could be duplicate chars across multiple images.

DogP

Well IIRC Doom uses a normal Raycaster engine, similar to Wolfenstein 3D and others… so by performing a raycast for each eye (from each eye’s position), that’d give you a true 3D Doom.

DogP

Jorgeche: Why did you comment out the setcoltable code in the crt0.s? I was messing w/ interrupts a little bit tonight and your crt0 works in the emulator, but when I ran it on hardware, the columns were all messed up. Did you disable it because you set up the column table elsewhere in your code? Anyway, I uncommented that code out and rebuilt it and it works great for me, so thanks!

DogP

It sounds like you’re trying to use the latest gccVB version… I believe that document was written up for using it with the older version. The older version is easier to set up since you don’t need to install Cygwin and compile the compiler. The old version you can just unzip and start using.

DogP

Oh… one other thing I just ran across… it’d be nice to be able to import another image file and merge into a previous one. Right now I have to copy/paste all my graphics into a single BMP, then convert all at once… which is kind of annoying when I just want to add a few graphics to something I did a long time ago.

DogP

I’d like an adjustable threshold for the map constructor… basically if I input a BMP w/ 4 colors, I’d like those 4 colors to be black through bright red (either automatically or manually selecting the threshold), instead of having to adjust the colors in the original BMP until it detects the 4 colors like I want.

I’ll try to think of other stuff, but that’s one I’ve run into a few times.

DogP

Heh, well don’t count me out for entering… but don’t expect anything exciting from me :-P.

DogP

If you go back into the elevator and go down, you can go to the previous level… to go to the one before that, go backwards through the level to the other elevator… and so on.

DogP

Sparkfun has some cheap chargers: http://www.sparkfun.com/commerce/categories.php?cPath=53_54 … the cheaper one uses a MAX1555, and I know Maxim is good about free samples. I believe they’ll only do one cell each, so you’d need to charge each cell seperately, or use two chargers.

DogP

blcklblskt wrote:

NamelessPlayer wrote:
Speaking of battery packs, I wonder if someone can create a lithium-ion battery pack with substantially increased battery life over the 6xAA version and also has a jack for the AC adapter for charging. Best of both worlds!

(Of course, it’ll probably never happen, given how everyone outside of this forum seems to hate it with a passion.)

DogP created a rechargeable battery pack on http://projectvb.vze.com/, but there is no jack to recharge it. Great idea though, I would definately make/buy one.

There is a jack to recharge it… check the last pic: http://www.virtual-boy.org/projectvb/projects/RechargePack.htm . The system isn’t really portable though, so there’s rarely a need to have batteries… there’s pretty much always an outlet nearby.

DogP

Heh, once again… I think about stopping for the night, but instead I keep going. It displays the VB to the monitor now, although I need to add a little bit of hardware to allow more shades on the VGA, so that’ll have to wait ;-). It looks pretty good though, with the exception of it being only 2 shades.

DogP

Woot! I spent a little time tonight writing a VGA driver and it works (at both 50Hz and 100Hz) :-). I haven’t gotten the VB actually displaying to the VGA, since I need to mux a bunch of signals so I can toggle between VGA and TV instead of only being able to use one or the other on an FPGA load, but there’s not a lot involved in reading from memory and outputting it to the monitor.

DogP

Argh… I have a few screenshots of when I beat it somewhere around here… can’t find them though 🙁 . Anyway, the game is beaten when you get 999,990 (I think, or maybe it’s 999,999) points. Basically, the enemies all walk across the screen holding white flags saying “we give up” or something like that. It’s not an amazing ending, but better than a lot of games :-P.

DogP

Here you go… quick hacked together brightness demo. The column table thing doesn’t seem to do anything, but I haven’t looked into it at all, so it could just be a stupid mistake on addressing or something, or I may not be understanding how it works (maybe needs LOCK first?).

Of course you can see the brightness change, but with it just incrementing by 1, multiple brightness changes aren’t totally apparent across a single frame. The specific part to look at is if you stop it during a BRT sweep, there’s a spot where a single BRT value has multiple levels, depending where on the screen it is. That’s what I had seen in the past. I didn’t check what the values are, but it’s not all 0xFF’s.

If you add a trigger to wait until the start of a display cycle before changing BRT values, and change the values by larger amounts, you could probably tell that there were more brightnesses across a single frame.

Anyway, the controls are:
Start: sets all BRT vals to 0xFF
Select: seta all BRT vals to default
Left Trigger: sweep BRT vals down
Right Trigger: sweep BRT vals up
A: Stop
B: mess w/ column table (doesn’t seem to do anyting)

DogP

Attachments:

I’ve had quite a few brightness variations in a single frame before… I don’t remember exactly how I did it, but IIRC I ran across it accidentally (maybe setting the BRT regs too high?)… I just looked through a bunch of files, but I couldn’t find it.

Assuming you know that it’d be a little bit of work to deal with it, and you know that you still can really only have 4 shades, just that the 4 shades can vary across the screen, there’s a few things you should be able to do to purposefully control it. One way would be by adjusting the values in the column table (I believe the upper 8 bits of each hword is what you’d want to change). This would increase or decrease the brightness of all shades, so it probably wouldn’t be extremely useful except for special effects IMO.

You should also be able to adjust the BRT regs while the display is active. This would take a little bit more work because you’d need to keep track of where in the display scan you are, but this would allow you to individually change the brightness for each BRT shade for each column. So you could have BRTA and BRTB constant, and just change the additional BRTC component, or if you wanted to get really complex, you could change them all. The best way would probably be to have a seperate lookup table that you create for the columns when you create whatever graphics you’re wanting, and then at every new column, set the BRT regs to the desired values.

I don’t know the best way to tell which column is being drawn though. There is SBHIT, which could tell you when SBCMP = SBCOUNT, but I think that’s for framebuffer control, not screen control. You can tell when the display starts, so if you have a good timer you could check the time to determine when to change, but that’d be pretty tough since the column lengths adjust because the mirror sweep isn’t linear (which is why the column table is there). I’d guess there’s some way to tell where in the sweep you are if you’re clever enough or look hard enough.

Anyway, I hope some of this helps… I could probably throw something together one of these days that would show this, but it shouldn’t be too complex to at least see the concept.

DogP

KR155E wrote:
will you implement vga output? then first mentioned problem would disappear, those would work everywhere in the world, and probably the picture is even better?

Yeah, I’m gonna add VGA output… I don’t anticipate many problems with that since it’s a much simpler standard than NTSC. The reason I like NTSC is that video game systems are typically played on TVs… VGA monitors are typically used for computers, and plugging into one is usually more of a hassle than plugging into a TV, and most people would prefer to look at their TV. It’s more of a centerpiece of a room, and I’m not really imagining the TV adapter being used by the primary player (unless the display cables are flaky… heh) as much as by others watching someone while they’re playing in the VB (or for taking video captures).

PAL isn’t too much different than NTSC, I may be able to make a PAL build, I’d have to see whether I have anything that can display PAL (like a TV input for my PC), and I’d need to be able to generate a color carrier from my existing clock.

RunnerPack wrote:
First of all, great work, DogP! I knew you could and would do it, but that was really fast! :thumpup: 😀

Second, it might be the angle between the camera and the TV, but the aspect ratio looks about right, yet the whole screen is filled… How is this possible with the VB’s 12:7 AR and the TV’s 4:3 AR? Does the picture look “squished” at all? If so, do you plan on adding “letterbox” (or “pillarbox” for 16:9) mode?

I second NamelessPlayer’s request for a cheap single-output device version; but I would prefer VGA for better stereo–both anaglyph and shutter. Also, I don’t care if it’s external and connected to the VB by some kind of umbilicus.

I had another idea, too:
For the shutter and mono modes, you could have some kind of RGB adjustment knobs so a player could tint the screen to match the level/area of the game. Like blue for the Wario swimming levels, green for Mario’s tennis, etc.

This would also be handy for adjusting the anaglyph to reduce cross-talk. BTW, have you tried Green/Magenta anaglyph? I’m still working on getting a better magenta filter, but so far it looks much better than red/blue. When I figure out the magenta, I’ll post some good Roscolux filter numbers to try.

Whew! Long post! 😀

Thanks RP… once I got the TV output portion working correctly on the FPGA, it wasn’t too difficult to emulate the VB displays… I already knew how they worked, and if I couldn’t get a 500,000 gate FPGA to emulate what is basically just a shift register, that’d be pretty sad 😛 .

It really doesn’t look very squished… if you look closely, you can kinda tell that Wario doesn’t look quite as fat as he should, but the ratio is close enough. I don’t have a 16:9 TV, so I doubt I’ll mess with it, but I believe widescreen TVs can stretch the picture to be in “widescreen” mode, so someone could do that if they really wanted. I can’t shrink the vertical size on the regular TV any more than it is because the vertical resolution is fixed, and the only thing I could do is take out pixels to shrink it (like the NES emulators on the GBA), or shrink it to 224 pixels interlaced (would shrink the vertical size in half).

About actually making a final product… I’ve been looking into various ways to connect it. The pitch of the display connector is kinda small, so it may be tough, but I’m thinking of trying a PCB with a bunch of vias in a row (staggered) which I can cut in half and solder to the display connector pattern (like the quicksolder modchips), and then pass that through to the top where I’d resolder the original connector back on. Unfortunately, I doubt there’d be a “cheap” option… I think the parts alone are gonna be at least $50 (and the PCB probably won’t be cheap since it’ll likely be at least 6 layers and fine pitch). If I get VGA working, there’s no reason I couldn’t add it and allow a switch on the fly… it might make sense to have one external connector that everything outputs through (like a VGA connector with a TV dongle that plugs into the same connector).

That’d be cool to allow color adjustment, similar to the super gameboy, but I’m not sure how realistic it would be to add it. To change color on the TV, you need to adjust the phase of the chroma signal. That’s handled digitally, so the adjustment would have to control a signal inside the FPGA. The other problem is that different amplitudes of the luma signal are needed for different colors. Red and Blue both use low amplitudes (like shown here: http://www.tri-sysdesigns.com/Pages/Articles/Black_is_Black/Components/COLOR_BARSv2.gif ), but other colors would require higher amplitudes, and more pins to create the proper voltage. So basically, the user would have to tell the FPGA what color it wanted, and then it’d have to make the proper amplitude and phase shift adjustments… and really, I don’t want to deal with that 😛 . There’d be too many buttons and switches for the user to control, and really just add more complexity than it needs.

I haven’t done green/magenta anaglyph… I don’t even have a good pair of red/blue anaglyph glasses 😉 .

DogP

It runs at full frame rate… the only problem is that the the TV refreshes at 60Hz and the VB refreshes at 50Hz, so of course you get diagonal lines in bright flashes because they’re not in sync. You should be able to perfectly sync it w/ PAL and VGA, and some TVs can handle NTSC at 50Hz, but it’s not noticable at all during normal gameplay, and it’s not a big deal when there’s flashes, so I’m not too worried about it.

The biggest problem is the crappy color bandwidth which only really lets you display ~160 horizontal color pixels, so red/blue doesn’t look very good. It looks really good in B/W w/ the shutter glasses though.

DogP