I followed the instructions at DogP’s site http://projectvb.vze.com/ to construct a flash cart using a Virtual League Baseball cart (it is the cheapest I found :-). I’ve finished it, made sure there are no shorts between the soldered pins and checked every single pin on both plcc32 sockets against the cart’s connector and everything is fine according to the instructions.
Then I divided a teleroboxer rom in two files of 512KB each one, next programmed two Am29F040B flash memories using a willem programmer (and dumped both chips to reconstruct the rom and made sure it was burned correctly… it was).
Finally I put the cart with both chips in the VB., turned it on… and nothing happened!!!
I guess I could have broke some pin connections in the PCB when I removed the original ROM… so I tried to verify the ones that I can see where joined under the mesh of cables and appears to be ok… but maybe this is the problem.
Is there any document showing the entire cart’s pin connections???
Hmm… if you broke traces from the original ROM, that’s no big deal as long as none of them are shorting (since there’s no SRAM on VLB). If you have SRAM, you have to be careful not to break the traces though, since they also go to the SRAM.
Anyway, the thing that I noticed when building them was that when you’re soldering wires on top of each other like that was that a lot of times the wire would get hot and melt through the sheathing and stick two wires together and short. So, you might want to go through them all and make sure none are stuck together. Also, I assume you tied /WE to VCC?
Other than that, check all your connections, and I usually check continuity between each chip on every pin on the chip socket except the 8 data lines. And make sure you have the correct chip in the correct side (or just swap them and try it).
“Hmm… if you broke traces from the original ROM, that’s no big deal as long as none of them are shorting (since there’s no SRAM on VLB). If you have SRAM, you have to be careful not to break the traces though, since they also go to the SRAM”
Thats what I tought, since there is no SRAM as long as there is no short between the lines there shouldn’t be any problem.
“Anyway, the thing that I noticed when building them was that when you’re soldering wires on top of each other like that was that a lot of times the wire would get hot and melt through the sheathing and stick two wires together and short. So, you might want to go through them all and make sure none are stuck together. Also, I assume you tied /WE to VCC?”
I checked each wire’s soldereing not to be in short with lines at left and right side if that is what you mean. I didn’t saw this one: “I assume you tied /WE to VCC?”, I’ll check it tonight.
“Other than that, check all your connections, and I usually check continuity between each chip on every pin on the chip socket except the 8 data lines. And make sure you have the correct chip in the correct side (or just swap them and try it).”
That’s an easy one because I ‘ve already done that.
“Also, you did build it using the Flash info and not the EPROM info, correct? And is this what you’re looking for?”
Sure, I used Am29F040 so i followed the Flash info.
Thanks for the link.
One last question please… what do you mean when you say that the Flash memory should be filled with repeats of the data?… My homebrewn rom has only 128KB… and I am very newbie to this electronic stuff .
There are nice tools by RunnerPack to first pad the rom to 8 MBit, and then split it into even and odd. Attached those. Maybe you did something wrong there?
I used a tool which I can’t remember its name now, that divided the teleroboxer rom into two files of 512KB, and joined them succesfully after dump them from the chips… but I will try these tonight.
Yeah, if you split and merged TB, that’s already the right size for those chips. About the shorted wires, I’m not talking about just the ones next to each other… you can also get other shorts from any wires that cross the wire you’re soldering since the wire heats up, melts the plastic on it’s own wire, and then also melts through the plastic on the wire crossing it. If you just go through all the wires and make sure none are stuck together that should at least rule that out.
Hi guys, thanks for your help! It finally worked! I was using the wrong tools to split the file, now I can play 16 games in the real machine!!! :-)… But lets go back to the problems again (sorry). I will try to do this in order:
1) I have varios versions of my engine, the older were compiled under the gccvb version published here, it outputs a 1024 KB file without doing anything else, so I splited these and booted fine in the VB. But the last versions don’t run at all, the gccvb version I’m using now is the last one published in David Tucker’s site, and it outputs a 128 KB file that runs ok in rboy, after using padvbrom.exe, it has 1024 KB and still runs ok in rboy, but doesn’t in the VB.
2) The engine version that booted fine in the VB has a lot of graphical glitches (it runs smoothly in rboy) and worse, it is very very slow. I thought that my game will run faster in the VB since every commercial rom runs slower in rboy than in the VB, and that it will be flawless in the VB.
3) I tried Krisse’s Blox in the real machine and it runs perfect!… no graphical glitches, no slowdown problems… perfect! Congratulations Krisse!… but what did you do? did you write Blox in assembler? wich gccvb version did you use?.
4) Just if someone didn’t notice but Space Squash fits into a 1 MB cartridge… I tried Waterworld, Nester .Funky’s Bowling too, but they didn’t work.
There’s several things… I’m not sure about why your new version doesn’t work, I’d try compiling it on the old gccvb and see if it still doesn’t work. It may be a memory problem if your program has grown too large, or it may be a compiler problem. In general, emulators are much more forgiving than hardware. The speed issue could be a lot of things… the timing, especially loops that wait by doing nothing, isn’t accurate in the emulators.
About graphical glitches, before writing the world stuff, do a “while (VIP_REGS[XPSTTS] & XPBSYR);” That syncs with the screen write (which isn’t really important in the emulator). Also, don’t do a whole vbSetWorld, just modify what you need to change… it takes a lot longer to rewrite all the world attributes than it does to just change one or two attributes. If you download some of my source from http://www.virtual-boy.org/projectvb/dev/VBProg.htm , you’ll see what I’m talking about.
3) I tried Krisse’s Blox in the real machine and it runs perfect!… no graphical glitches, no slowdown problems… perfect! Congratulations Krisse!… but what did you do? did you write Blox in assembler? wich gccvb version did you use?.
thanks! well, no. it’s just c, and also not very good code… i just started learning c when making the game. but it’s a very simple game, so i didn’t have problems with the speed. i just tweaked the code to fix graphical errors and adjust the speed and tested in the vb very often until the game ran like i wanted. i used the first gccvb version by the way. 🙂
Hi, I used the while statement you pointed DogP and made the glitches dissapear, thanks.I will go back to type some code, make some test and to try to make the engine work in the VB and try to better understand the registry and interrupt harware arquitecture).
