Being not good at soldering and all, i was wondering if someone is ready to sell me a homemade flashcart or throught a trade of items, there are some homebrews that I would like to try on the real console…
A long while back there was talk of making flashcarts, but like a lot of things in the VB community as of late, this never happened.
It should be possible to make easily reproducible flashcarts as long as someone can make the circuit design, and purchase and solder the chip(s).
One problem may be getting hold of enough VB carts to salvage for cart connector and case.
…But like most things, we just don’t seem to have the time to do such things anymore… 🙁
Hmmmm…. Well I’d personally be willing to buy some virtual league baseball carts and donate them to this little project 🙂
I’d really like to get this thing off the ground. We have two experienced game makers expressing interest in making homebrew vb games so this is an ideal opportunity for us. I’m willing to help in any way I can. If we need more people to learn programming I’d be more than willing to do that.
Making a 1MB cart should be easy enough, as it only requires 2x512K chips. The problem arises when you try to make 2MB or cart with SRAM.
Another problem may be the chips themselves. Last I heard they were no longer being produced, and our usual source for them (DogP) seems to have dissappeared from IRC.
Personally I want to make a 2MB cart with SRAM, to be able to run both PD and commercial ROMs, but before that it probably is best I attempt something a little easier.
I have a lot of this (cart and programmer) fleshed out in my mind, but just haven’t had any time to go any further.
Another problem may be my original idea for a programmer involved a LPT-based unit, but most OSs (and even some PCs) nowadays don’t seem to support it anymore. I may have to do some research on a USB based unit. This would end up being faster, but would also end up a lot dearer than the other method.
Another idea of mine was to make an in-console programmable cart using the VB link port, but I never did figure out an easy method of switching the hardware from read to write and vice versa…
Hey Lameboy,
I’ve been really interested in a flashcart for some time now and since you can’t just buy one for vb the only alternative is to make one witch is a pain, but the idea is so hard to let go. However were all very busy with our real lives and do not have much time for projects such as this it’s practically impossible for one person to research, design and build a flashcart effectively. Would you be interested in a collaborative project? I’m really fond of the idea of a flash cart that is written by a pc via the USB port, I think it would be the most effective way to do it. I have some experience soldering, working on PC’s and Laptop hardware, limited programming experience and own precision tooling. I think I could build a flashcart that works with a USB port with some research into it and some help as I’ve never taken on a technical project with such depth. If we were going to do something with the USB Port we would need drivers for it to work with windows witch I can’t write because I’ve never written one. Anyway,before I delve deeper into the idea would you be interested? I’ve got a couple of ideas as starting points to the flash cart hardware that could make it easy to build. Let me know. Later.
I may be interested in that idea. I have a few weeks holidays coming up soon, but I doubt I’ll use it on this. If anything I’m more likely to get stuck in and hopefully get my site back up.
The chips I use are AMD (AM) 29F040 PLCC-32. You may want to find a spec sheet on it for pinouts. PLCC seem to be the smallest 512K 5V flashchips that are still a solderable size. Most chips >512K are something rediculously tiny like TSOP and such. They measure about 21x25mm.
I doubt you have one, but you have a VB screwdriver/tool (either ‘official’ or a screwdriver or biro hack), you can open a VB cart and take a look at the PCB in there. Carts like Mario’s Tennis (non-SRAM) are actually tiny compared to the potential size in there. This would allow more than 2xPLCC chips, but the probelm is working the PCB track into that size, not to mention any additional flash/SRAM chips.
Another problem with a non-inconsole method is finding a cart socket to plug the flashcart into in order to flash it. This is another reason I want to make an inconsole model.
Finally, Lupin over at http://pokeme.shizzle.it/ has made a USB-capable Pokemon Mini programmer using USB consisting of an Atmel AVR (microcontroller). I’ve been in contact with him for ages, but haven’t gootten any real details from him about his software for it.
As for my in-console idea, I figured out you can actually upload code to RAM and execute it from there. I also decided that I could tie the flash /WE (write) pin to the (unused) pin used by the VB for expansion (for stuff such as DSP, which never happened). This would mean when you access EXP area it would in fact be using ROM area but with the WE pin active. One potential problem with that may be the code needed by the flash chip to erase and write might need the WE pin active for the entire duration of the special code sent to it (for the write to work), whereas this would in fact drop the pin back to low after each byte of the code is sent. As I don’t have a flashcart obviously I never got to test this fact.
I also decided on a barebones bootloader code that would be injected into each ROM upon write, which would do a minimalistic check of the link port to see if it was active, then begin transfer of the boot/flash ROM code over link port to RAM where it would be executed. This would mean only the most basic of code would need to be injected into the ROM, reducing the risk of lack of spare ROM space.
As for my LPT-based programmer idea, it would be reasonably easy as it could use a counter IC to increment the address lines of the cart, and control the cart WE/CE/OE/data pins and addr clock increment/reset pins via LPT. As it is already 5V there wouldn’t be any need for voltage conversion. One possible problem is that LPT data lines are 8 bits wide, and the VB is 16 wide, which would mean some way of buffering the 2 lots of 8.
…And of course the whole programmer cart socket again. Only source for those things seems to be a (hopefully) dead VB.
well, it just so happens I purchased a spare VB on ebay a couple of weeks ago witch has the infamous eye problem. So it has to be opened up anyway. I wanted to make a custom head mount shell for it with the guts but have always been interested in a flashcart. I bought some perfboard, 40 pin IC sockets (probably won’t work though, just got excited when I saw a 40 pin socket.), new solder tips, solder and spool wire today at radioshack, . Not to mention I have the busted VB and an unattractive teleroboxer cart. I’m almost ready to go I have to see if I can get my hands on some chips then some sockets and a compatible eeprom programmer, oh and I’ll have to make a gamebit with my dremel so I have to buy some new bits for that. But we can definitely get away with the classic eeprom cart. Although taking one of those usb media card reader/writers and crossing it over with a cart would be cool. a lot more BS though.
For the easiest method of EEPROM programming I would suggest actually buying a chip programmer such as those available from Willem. Making a programmer from scratch would probably be a bit too hard.
This reply was modified 17 years, 10 months ago by lameboyadvance.
So, I to have been working on an in console flash cart for ever. But alass I get 3/4 of the way through the design and run out of time. Lameboy has it right. You need a flash cart that is programed form code loaded in to ram by a boot loader that connects to the pc via the link cable. We know how to do everything but do an in game flash of the rom cart. I think if you put some flipflops at a specific address in expantion ram you could initiate the activation of /WE by writing to a specific address. Unfortionently the flash requires several writes to program a single byte, the question is, will noise on the buss mess everything up? The answer is write a program an try it =0)
I would love to colaborate with someone on this. let me know if yo uare interested.
If you’ve actually got some of this past the design phase I’d love to help.
As I said before I was originally thinking of using the CS and Exp(ansion) select lines in order to activate the flash /WE line. Problem is its been so long since I looked at this I’ve long forgotten what line activates when.
Last I remember I (think I) figured out one of the lines would need to be inversed for everything (ROM, SRAM/EEPROM and /WE) to operate happily, but as its just been too long, don’t take my word on that.
I just reread the 29F040 flash spec sheet recently and the whole rewrite sequence. It says it needs 6 codes to complete a sector/whole erase, and 4 to program a byte. Any idea if you can erase byte by byte?
Also, any idea if the erase/program sequence only needs /WE active during each command (with breaks in between)? The reason is that if you were to tie /WE to EXP it would go low (or high or whatever) after each byte is sent.
I’d be happy to write something to test erasing/programming. It’s been ages since I’ve done anything VB, and I have a few weeks of holidays coming up.
About the bootloader, In order to keep it as small as possible I was thinking of doing the following:
* absolute minimal code necessary to activate VB
* check to see if COMCNT line is high (this would be pulled high by programmer)
* if line low, continue to ROM boot address (actual address would be moved somewhere else in ROM to accommodate bootrom address)
* if high, set xfer clock to external, prepare for link communication (can’t remember exact method atm)
* set addr pointer to 0 (or somewhere)
* continuously poll (can’t remember addr name – bit that tells you transfer complete). If (xfer contents register) is not zero, copy contents of register to pointer, inc pointer by 1. If it is zero, reset pointer to initial location and execute RAM code.
In order to reduce code, an acknowledgement is not included, but may be needed
This code would allow you you posibly load a secondary loader into RAM, which would then do more in-depth communication and checking.
My hope is to keep it as small as possible in order to reduce the risk of running out of free ROM space. I was thinking of possibly using that null area within the header to store the original ROM boot location, in order to identify if the ROM has in fact been changed (AFAIK all ROMs+tools have that area as null).
…Thats all I can think of atm. I’ll try and look for my old notes on the select/enable lines.
the 29f040 cannot be erased bytewise, i think they can be erased sector-wise tho.
this means most likely you should stick to y µC solution if you want to make your cart compatible to the original games…
🙂 Don’t have much time to explain ATM, but: http://dogp.home.comcast.net/VirtualBoy/CartPCBs/cartpcb.htm . Works great… I’m not sure how many will be available, but of course dev’rs get dibs over someone just too cheap to buy Space Squash and Insmouse 😉 .
Working on programming in circuit over the link port.
No idea yet… I’ve gotta take care of a few people first, then I’ll see how many are left. I’m not really sure about programming though… I figure the link port would be great, but then we’d need to make a link port connector 😛 . No problem for me with my RJ45 connector, but I don’t think everyone wants to mod their VB.
Right now it’s easiest for me to just pop the chips out, burn, and replace… but I’m sure everyone else wouldn’t want to buy an EPROM programmer to go with their cart 😉 .
Any ideas on just how we can make a cheap link port connector? I know about the SNES/N64/GC AV cable hack, but thats just too much mess & trouble for what its worth. I tink I remember RunnerPack saying something about a 5.25″ floppy connector, but I’ll have to confirm that. That, and those things are hard to come by nowadays.
And about a bootloader, any ideas of your own? I quickly dropped the idea of an internal bootrom on the cart as it would take up space, but that only leaves injecting the loader into each ROM as its copied.
Not sure about the link port connector… I figure it’s gonna have to be a custom molded thing… for the bootloader I was thinking throw a really small piece into the unused interrupt vectors that just copies from the link port directly into memory, probably controlled by COMCNT. When COMCNT changes, stop copying and jump to where you copied the program to.
I’m just worried about which vectors we can use that aren’t used by any game, or make it change depending on the game… and if it fails, then the cart is dead 🙁 . Of course we should be able to use the game info section, but that may not be enough I was also thinking about using seperate boot chips, then swap them to flash the game… that way you don’t worry about killing your cart, but then you’ve got a socket and need to swap chips. It would be a lot easier though 😉 .
lol, your loader sounds exactly like mine, even my original ‘squeeze it into empty interrupt space’ idea. 😛
Only thing different is stopping COMCNT to signify end of transmission. That would allow some code to be dropped from the loader (albeit a few instructions), but would introduce a COMCNT poll upon each byte received.
As for the free space idea, I guess the program responsible for flashing the ROM would need to search through each interrupt and figure out which aren’t used. If all are used, hope that nothing else is using the area between the ROM header and interrupts.
…And on the 5 1/4″ FDD connector idea, any idea what its called? I’ve tried Googling for it, but all I’ve found out is the 3 1/2″ connector is an IDC-34 pin.
I have a ton of old FDD cables at home, but I’d still love to be able to find one I can cut down and solder on to a PCB, which if done right could house the USB microcontroller(s) and a USB socket for a PC cable to plug into. Unfortunately the cables aren’t PCB mounted. so even if I did use them I’d still have the FDD cable running to a board, instead of it fitting neatly underneath the VB/linkport.
…And as for the code, you never know – there may even be enough room to allow for a micro controller->VB->PC relay code allowing the VB controller to be used as a USB gamepad. 😉
Heh… I’ve already got a VB controller that I’m using as a USB gamepad: http://retrousb.com/virtualboy.html … it’s really sweet, I just wish I had more time to program so I could use it more 😛 .
