That battery icon does mean the batteries are low, but low batteries aren’t the cause of the display problem… although I guess it’s possible that with weak batteries the problem could be worse. There’s no need to rush into fixing the problem since I’ve never seen it actually damage anything, but of course it’s pretty annoying, so you’ll probably want to fix it if the problem continues.
Heh, well if you come across a Dragon Hopper ROM, send it to me and I’ll gladly build you a cart dedicated to it ;-). Basically, you just need to replace the 29F040 flash chips with 27C080 EPROMs. The EPROMs are OTP, which is why you don’t want to normally use them, but if you want a cart dedicated to a single game, it works fine.
The answer to both of your questions is… it depends :-P. Mario’s Tennis, Mario Clash, Galactic Pinball, Teleroboxer, and Wario Land are all completely identical between the US and JP versions (they’re the same ROM). I’m guessing that’s why most of the games have the warning screen in both English and Japanese.
Panic Bomber, Vertical Force, Jack Bros, Baseball, Red Alarm, and Golf are different ROMs, although they have varying amounts of Japanese. This is going from memory, so it may not be 100% accurate, but JP Panic Bomber has a lot of Japanese, as does Jack Bros, but you can figure the game out without the text, and if you really want to know what it says, look at the screens in the US version in an emulator, or the US manual. I believe Vertical Force is pretty much all English (the JP version was one of the first games I owned and I don’t remember having any problems), and Baseball is pretty much all English, except the names are in Japanese, and I think things like Out, Safe, Ball, Strike, etc are in Japanese. I believe the only difference in the Japanese Red Alarm is the warning screen is only in Japanese, the rest of the game is in English. I know Golf has a Japanese menu, but you can compare it to the English menu to figure out what you’re doing… and it’s a golf game, so it shouldn’t be hard to figure out how to play.
For the JP only games, V-Tetris is in English (and V-Tetris is a completely different game than the US 3D Tetris). Space Squash has a lot of Japanese dialog and stuff, but the game is simple enough to figure out. Insmouse is mostly in English, and easy to figure out how to play. Fishing is mostly in Japanese, and can be difficult to figure out what you’re supposed to be doing (since you’re supposed to be doing some sort of tournament), but there’s a translation of the menus at the bottom of this page: http://www.virtual-boy.org/translations.htm .
For the 4 rare games (Virtual Lab, Space Invaders, SD Gundam, and Virtual Bowling), they’re all pretty much in English.
1) There are some homebrew games made, but none that have been officially released on carts. So far, all homebrew carts have been made using old cases and edge connectors, although new PCBs have been made.
2) None of the protos have been dumped and publicly released.
4) I don’t know of any place that actually sells the sleeves (I assume you mean the black plastic caps), but there are plenty of cheap common games out there that you could buy just for the cap… of course to save on shipping, it’s probably best to just order one from someone who you’re already buying a game you actually want from (or maybe ask them if they have any extra caps that they’d sell for an extra $1 or something).
The braid will suck up the excess solder, but of course it won’t suck all the solder off the joints. The idea is that there will still be enough solder to connect the component to the PCB, but not enough that it’ll cause a short between the pins.
If you do a search on youtube there’s plenty of tutorials, but Sparkfun has some good ones, like: http://www.youtube.com/watch?v=9PRKJXJrnvo . Rather than just using flux, they show all of theirs with desoldering braid, which has flux in it, but also sucks up excess solder.
Well… you can’t just put a glob of solder on the whole thing, each pin needs to be soldered individually with no shorts, but you can use whatever method you like to solder it. I typically just use a lot of flux, which keeps the solder flowing rather than globbing up, then take the iron and solder from the cable to the PCB pulling towards me in a single smooth motion. It’ll usually solder a couple pins at a time, so just do this all the way across. If the solder starts to glob up, just use more flux.
Of course you do have to be decent at soldering, and have a clean fine tip iron (set to a fairly low temperature), but the method isn’t much different than soldering surface mount chips, so you should do a search on surface mount soldering and do some practice on that before attempting this.
The number in the bottom right corner displays the number of frames per second. You can enable/disable cache (around the Affine loop), and increase/decrease the ROM wait state in the pause menu. Press start to bring up the pause menu, then:
press on the right d-pad-
up to set 1 wait state
down to set 2 wait state
right to enable cache
left to disable cache
At startup it’s set to the best performance (1 wait state + cache enabled).
You can see at the best performance, it’s does about 218 FPS. It drops to about 203 with 2 wait states + cache, and to about 136 with no cache and 1 wait state. It then drops to about 114 with no cache and 2 wait states.
So, you can see that proper use of cache makes a HUGE difference (~60%, and I don’t know for sure that I’m using it optimally either). 1 wait state does help, but of course it helps more in places where cache isn’t being used since executing from cache (which has no wait states) cuts down on the number of ROM accesses (~7% improvement with cache, ~19% improvement without).
But, I guess the lesson here is that making two simple changes increased the performance of my app by about 91%… so if you’re running out of computing power (or want more room to grow), maybe this will help.
I assume you mean the screws for the cart? It’s the 3.8mm, which I believe the GB/SNES carts use… the VB system case uses the 4.5mm, but you need to modify the bit since the bits won’t reach the deepest ones.
I’m not sure what the actual part number on the battery is, since it’s not marked on the visible side… but do you have a cart with a dead battery or are you just curious? It’s the kind with the tabs that are soldered to the cart, so you’d need to make sure you get that kind (since I don’t think you’ll be able to fit a battery holder inside the cart case). If your battery is dead, just desolder the old battery and look at the part number… or measure the size and compare it to others… it just needs to be 3V.
Yeah, some caches are for data, others are for instructions (they’re typically seperate caches)… the VB only has an instruction cache.
dasi: Copying to VRAM isn’t a very good measure of performance because the VIP has more wait states (IIRC some depend on what it’s doing). I don’t have my documentation with me right now, but I believe it’s variable between 2 and 5 waits. A better measure would be copying to WRAM, which has a fixed wait of 1. A 20% performance boost does sound reasonable though (theoretically, it should be 33% faster).
Oh… wow, so it really made a big improvement for you (no need to do any real measurements, I was just looking for an estimate).
For cache, it sounds like you’re not using it to it’s full potential… you want to make sure you enable it around things that have a high loop count (same code over and over). Using it around loops that call other functions is fine too (see note below), since the compiler doesn’t know about the cache… it’s just telling the hardware to store any instructions that goes through the CPU in cache in case it comes up again, which will then be pulled from cache (no wait states) vs being pulled from RAM or ROM (which both now have 1 wait state). Note that the VB only has an instruction cache (instructions executed) and not a data cache (data read/written).
I enable cache around my affine loop in Mario Kart, and I saw a huge improvement… but I have a loop that runs through 174 times, recalculating basically the same thing every time, except using the loop count to “tilt” the view.
The VB cache is “direct mapped”, which basically means it acts as a hash. For this reason, you’ll likely get the best performance if all the code is close together (since it’s likely to be sequential), and definitely the best if it’s all within 1KB of memory, since any time bits 9 to 3 in the address are the same, you’ll be hitting the same block in cache… and if it’s not the same actual address as the last time those bits were hit, it’ll need to replace that block with the new data. (ie 0x07000000 collides with 0x05000000, as well as 0x07000400, etc). So, if you have 0x300 bytes of code, plus a 0x100 byte function called from that code… if they’re consecutive in memory, it’ll work the best since they’re unlikely to collide, but if they’re seperated, there’s a good chance that they won’t be aligned to 1K relative to each other, which will cause a cache miss inside the loop. Of course it’s worse if you’ve got more segmentation than that, like a 0x100 byte loop calling 16 0x30 byte functions… there’s definitely a good chance that there’ll be some collisions there.
You also can hurt performance by enabling cache when you shouldn’t be using it, since there is a penalty for cache misses. As you can guess, random jumping around would be a very bad use of the cache. If you have several places that cache would be beneficial, you can also save/restore the cache… although it’s hard to think of a practical reason to do this (since it’ll recreate the cache on it’s own)… maybe restore the cache during a wait to prevent the initial cache misses later? The cache does remain valid while it’s disabled, so it’s important not to keep it enabled longer than it needs to be, or the “good” instructions will get overwritten (and you’ll have cache misses on useless instructions), and the next time in the loop it’ll need to rebuild the entire cache.
I don’t think Reality Boy emulates the cache, but I’ve been thinking about adding it, just so I could profile my use of the cache.
Great! I’m glad it helped! And yeah… I talked to Richard today about the Flashboy and he said he used 70ns chips, so 1 wait state should be safe to use w/ the Flashboy. Do you have any guess on how much speed increase you’re seeing? Is it close to 1/20th like I’m seeing, or more, or less? I don’t have many games/apps that aren’t speed throttled, so it’s hard for me to get a good estimate on what can typically be expected. And do you enable cache around your heavy computational loops?
It’s address 0x02000024, bit 1… assuming you have it in your libgccvb, it should be HW_REGS[WCR]=1 (the default of 0 is 2 wait states).
Just to be complete, all bits are unused except the lowest 2 bits… the lowest bit is the ROM wait state, the second lowest is the expansion area wait state, so if anyone uses that in the future, you can set that with HW_REGS[WCR]=2 (and then of course be careful to | and &~ to not affect the other bit if you just want to change one or the other).
I just wanted to update a couple things in this post… first, I was talking to RunnerPack in IRC the other day and he checked out the disassembly of the latest gccvb using floating point numbers, and it does use the proper CPU floating point instructions for the math as well as for converting to/from ints. Looking at the v810 datasheet, the instruction to convert back and forth can take between 5 and 16 cycles, so if you’re gonna use floats, you should stay with it until you no longer need it (don’t convert back and forth every time). Floating point add/sub is slow though (9 to 28 cycles), so try to limit doing those, and use as many mul/div instructions while you’re in floating point, since they’re comparable to fixed point mul/div (8 to 44 compared to 13 or 38 in fixed point)… mul and div are usually where you want floating point anyway, since it gives you a large range to work with. Floating point is still slow, so I’d recommend using fixed point if possible though.
Also, I wanted to clarify something I stated in one of the earlier posts about the sign bit… in C, right shifting an unsigned number will do a logical right shift (not sign extending), but right shifting a signed number should do an arithmetic right shift (sign extending). You do need to be aware that right shifting a negative number won’t be identical to dividing by 2 though, since it “rounds” the opposite way than division. -4/2=-2, -4>>1=-2… but -5/2=-2, -4>>1=-3… which may not be a big deal for a video game… except that it also means that -1/2=0, -1>>1=-1 (it never goes to 0).
I don’t know that the competition necessarily did a whole lot for the VB’s future (I guess maybe some new tools will be helpful), but it made some of us stop being lazy and actually make something worthy of showing off ;-). Hopefully some of these games will be completed, and maybe we can finally see some games that really push the hardware to the limits. If we’re lucky, maybe it’ll encourage some others to join in and make some games as well.
Either way, it’s been a lot of fun, and it was really cool to see all those new entries roll in on the same day.
This is pretty cool… I assume the MIDI is limited to a maximum of 5 channels? To do music in my games I converted MIDIs and MODs before putting them into my program, but of course I’m doing one VB channel per MIDI/MOD channel, which limits us to 5 standard channels.
How do you plan on doing the instruments? Are you just gonna approximate the waveform, or do you plan on adding support for enveloping to get a fade, and some other effects to get some instruments that are more than just a tone?
BTW, is your Zelda game in progress, and you just didn’t have a release worthy game, or is it still in the early stages? I’m really looking forward to seeing a VB Zelda game one of these days.
Just battery life… people will complain that they’re getting very little play time on rechargable batteries, and it’s very possible that the low battery light will come on in just a few minutes.
