I've been playing around with the idea of building a GB flash cart for awhile, and figured I'd combine a few of the interesting cart mods I've found online, namely
nonvolatile saves and a
clone MBC5 synthesized on a CPLD all onto one cart. Eventually, I'd also like to work out a flash ROM solution using an in-production part (preferably something larger than
512KByte...), but that's a low priority for the moment. I'm doing the MBC5 clone myself from scratch since it seems xzakox never open sourced his project like he said he would (though Google seems to have managed to find at least 2 different revisions of his VHDL posted to pastebin, but I have no idea how complete those versions were, they at least make good references). Would anyone be interested in such a cart? Perhaps as an LSDJ cart, for instance (I'd require proof of donation, but I could pre-load it)? I know flash carts tend to be frowned upon, but it isn't like the SNES with ripoff repros grabbing huge prices on Ebay, and there are legitimate uses, such as LSDJ, so I figure it's worth at least asking...
I have an initial board laid out, currently using a donor MBC5, but once I work out the Verilog simulations to my satisfaction, I'll do another layout with the CPLD instead.
Do you mean something like that?
http://derpcart.com/it has a non-volatile memory and usb connection. It is sold for 100$ and it is out of stock everywhere.
So if you could mass-produce your cart with non-volatile save, CPLD (i assume with low power usage) and a practical way to flash roms preferably usb, you would sell a lot.
But if you have the knowledge, you can go for a SD cart based flash cart. As far as i know there is nothing on the market for gb/gbc with mini/micro SD. This would fetch quite good money and it would interest not only LSDJ people also the gb retrogamers. I would be interested in such a solution with SD cart.
There will most likely be several iterations of this cart project. The first step would be the one I have above, using a donor MBC5, an AM29F032-B Flash ROM, and an F-RAM nonvolatile save chip. The next step will feature an MBC5 clone in a CPLD (I will be using the same Xilinx CPLD as the project I linked above, it seems to be the best option for the features needed and the price). Once that is done, I will most likely try to make the transition to 3.3v logic for all of the parts. The F-RAM chip I'm using is already compatible with 3.3v, and there is a 3.3v version of the CPLD I'll be using available as well, so the whole point in moving to 3.3v would be to use a 3.3v Flash ROM, so I can use in-production parts rather than relying on obsolete 29F* chips. Also, once I've migrated to 3.3v parts, that opens up the realm of 64/128Mbit ROMs and 1/2/4Mbit F-RAM for multi-bank carts. I don't really plan to add USB, but my plan is to be compatible with
Reiner Ziegler's USB programmer, as well as the rival-corp cart dumper (which I can't seem to get a link for, as the site's server seems to be down). SD is even trickier. The biggest problem is the lack of space inside a gameboy cart. It would have to be MicroSD due to physical constraints, and I don't know if I feel like going that route anyway.
Interesting project you've got here. I've always been curious about the gameboy mappers and dev/flash cart possibilities. I was surprised to see that the MBC5 was planned to fit in such a small CPLD (36macrocells). Did a little research and looks like it is a fairly simple mapper when compared to NES mappers I've replicated on the same series of CPLDs.
Having done similar development with the NES I've got a few questions/food for thought for you. Take it or leave it.
Is there a good reason to start by desoldering and using an original MBC5? I don't see how this is really very helpful towards the end goal. Seems like a headache to desolder/resolder and in the end you've only proved you can make a PCB and solder components. If those are skills you're looking to acquire I guess this step makes a little more sense. But if that's the case I can't imagine the fine pitch MBC5 being a very good first timer's exercise. Soldering new components is drastically eaiser than desoldering and resoldering used ones.
Being pretty familiar with that CPLD I can say you're pretty safe with just routing pins to available I/O on the CPLD based on the datasheet. The JTAG pins can only be used for programming, so route those to a ISP connector don't send any signals to these pins. The Global pins can be used a general I/O, the only thing you might have is a clock signal (not familiar with the pinout/signals myself). You can assign all the signals to the proper pins once you've got the HDL written for the MBC.
Anyways all I'm trying to say is it seems like you'd be better off using the xilinx CPLD for the first rev and perhaps just shoot for the simipler mappers and work up to the MBC5. This is really where you'll pick up the needed knowledge to complete the project IMO.
Do you have goals for power consumption? I've found these CPLDs aren't the most power efficient. It depends on a lot of factors but based on my experience I'd guess you can expect around 20mW. Shouldn't be too bad I guess, but it's probably 2-5 times what the original MBC5 consumed if I were to take a SWAG.
If you've got any specific questions about the CPLD/xilinx webpack feel free to ask. Would you be willing to post/share the VHDL files? I'd be interested in taking a peek out of curiosity.
Good luck!
Honestly, the first revision is mostly just to get *something* working as well as to test any pc-side software I may write to talk to the cart. That way, I can guarantee that any issues aren't due to my Verilog. Also, I'd like to just have a working cart with minimal effort, since I don't currently own one. I'd like to have a working cart *now* so I don't have to wait until I get one working. Desoldering is easy, but I'm not looking to go out and buy a bunch of donor carts just to rip out the MBC's and then resell them, so I can almost certainly say I won't sell any carts with donor MBC5's. So yes, the first rev I'll be looking to sell will be one with a PLD MBC. Do you have any suggestions for alternative PLD's with better power consumption ratings? I'm considering the XC9536XL once I move to 3.3v logic, but I'm not sure if the XC*XL line has better power consumption than the XC* line. I've looked into Altera's offerings, and I didn't find anything that seemed convincingly better. About the closest I found was a MAX7000 series that was available in a QFP44 package, but it was twice as expensive as the Xilinx chip. If you have any suggestions, I'd be happy to look in to them, but the other guy I saw working on this using the same Xilinx PLD seemed to think the power consumption wasn't that high.
Can't you do the same thing by putting flash on a MBC5 board with less effort? You're already hacking up the one game... One interesting thought I had would be to layout the board for the MBC5 but then put though holes surrounding the MBC5 so that you could put the CPLD on a breakout/surf board and keep everything the same and pull out the MBC and drop in the CPLD. I only bring it up because it's a pain to have to have PCBs manufactured for each step along the development process.
You won't really find any other CPLDs near that price range. 20mW probably isn't that bad in actual use. I don't know what kind of power the GB consumes, but if you figured that out you could determine the actual comparative effect if the cart consumed 20-30mW more than original carts. Even if you lost 1 hour out of 8-10hrs of battery life I don't think it'd be a deal breaker. Just make sure you've got it in low power mode, you can verify that in the fitting reports after synthesizing. You could even do your own test with a dummy resistive load while playing your gameboy and determine how good/bad the consumption is assuming the CPLD will consume 20-30mW.
I'm also confused about the 3.3v conversion issue... With the GB @ 5V (I assume for the brick, and the GBC is 2.7-3.3v?), either way if you've got 5V tolerant parts (which this CPLD is) and the GB's Vih is presumably well below Voh of your CPLD and memory. So I don't see where the actual 'conversion' would be, it's inherently 3.3v logic once you move away from original GB cart parts, Right?
infiniteneslives wrote:
With the GB @ 5V (I assume for the brick, and the GBC is 2.7-3.3v?)
Tangenting: no, everything until the GBA micro had a boost converter to run the cartridge at 5V. I suppose old ROMs weren't specified to work below 4.5V or whatever.
Dwedit was clued in years ago that in the game boy micro, they still had the GBZ80, and had only removed the alternate power supply. But this is all irrelevant to your point.
Yeah, lidnariq got to it before I did, but all of the chips on the GB(C) cart run at 5v logic, not 3.3v. The GBC may run on 2xAA batteries, which is a 3v power supply, but it internally boosts that up to 5v which it runs off of. The fact that it runs off of 2xAA batteries was just nice for the size of the handheld, everything still runs off the same voltage (up until the GBA, which IS 3.3v, and it has a switch to switch to 5v when you insert a GB(C) game). This is not just the voltage supply value, it also affects what voltages drive the logic to each and every I/O pin on each and every chip on the board. The reason that I want to transition to 3.3v logic is that 5v Flash ROMs are all obsolete above 512KByte (Except Micron *supposedly* still manufactures 1Mbyte and 2Mbyte chips, but I can't find them available at ANY of their licensed distributors). Current production Flash ROMs have all moved to 3.3v. This is also true of the higher density F-RAM, though 5v chips are available up to 32Kbyte, which is the same size as a single SRAM bank on Zelda DX (which, AFAIK is the largest RAM size used, but I have done VERY little research into it, so correct me if I'm wrong...). I've checked, and 3.3v Flash ROMs are NOT 5v tolerant, so I actually do need to add level shifting on the logic pins in order to use a 3.3v Flash ROM on the GB. So, if I'm going to have to level-shift all of the logic going in to the Flash ROM, it would actually just be easier to level shift the entire cartridge and use 3.3v parts for everything. That would make board tracing much easier, and open the door to larger-density F-RAM if I felt so inclined. The biggest benefit, however, is like I said, the ability to use current-gen, in-production Flash ROM chips. Not only is this just smarter, it's cheaper, and it opens the door for larger ROM chips as well as RAM chips, meaning potentially multi-bank carts. USB would be nice, and that Drag-N-Derp cart is a pretty sweet design, but I don't know if I really want to go that route. Of course, I say that now and may eventually eat my words, but if I did go that route, I would start by designing a separate USB programmer, THEN attempting to miniaturize it and pack it into the cart, so I DEFINITELY won't go straight for an on-cart USB solution.
infiniteneslives wrote:
Can't you do the same thing by putting flash on a MBC5 board with less effort? You're already hacking up the one game...
No, I only have TSOP Flash ROMs, which are 0.5mm pitch. You really can't hand-wire them. I could solder it to a breakout board to get solder pads at a reasonable pitch for wires, but at that point I might as well just make a full PCB... I actually enjoy designing PCB's. They aren't really that much of a hassle, plus it just looks awesome to have a professional end product rather than a wiring ratsnest.
infiniteneslives wrote:
One interesting thought I had would be to layout the board for the MBC5 but then put though holes surrounding the MBC5 so that you could put the CPLD on a breakout/surf board and keep everything the same and pull out the MBC and drop in the CPLD. I only bring it up because it's a pain to have to have PCBs manufactured for each step along the development process.
Anything through-hole would be too thick to fit in the cart. Also, you can't have anything on the back side of the board or it doesn't fit right, which includes through-hole pins sticking through. And like I said, PCB's really aren't nearly as much of a pain as you think. The only annoying part is turnaround time. I already have the layout (posted above), so the work is done. Why not get boards made after putting the effort in to get this far?
infiniteneslives wrote:
Just make sure you've got it in low power mode, you can verify that in the fitting reports after synthesizing.
Yeah, I'll definitely be asking around on the Xilinx forums for best practices on power saving once I get that far.
infiniteneslives wrote:
I'm also confused about the 3.3v conversion issue... With the GB @ 5V (I assume for the brick, and the GBC is 2.7-3.3v?), either way if you've got 5V tolerant parts (which this CPLD is) and the GB's Vih is presumably well below Voh of your CPLD and memory. So I don't see where the actual 'conversion' would be, it's inherently 3.3v logic once you move away from original GB cart parts, Right?
The XC9536 is 5V tolerant, as is the F-RAM I'll be using, but 3.3v Flash ROMs are not, and there are no 5v Flash ROMs in production anymore (at least nothing large enough to be useful here). So I can either rely on obsolete parts or do the work to do it right and get it working with newer ROMs, which I really would like to do, especially considering how much the price of AM29F032's can fluctuate... and even at their best they're still dang expensive compared to, say an M29W320.
Another thing about switching to 3.3v, I just looked at the datasheets a bit more and once I switch to 3.3v, I will also almost certainly be switching from the XC9536 to the XC9536XL, which should cut power consumption by up to 40% over the XC9536, so that'll be nice...
I got the PLD's in today, and I noticed when I compared the footprints between the PLD and the MBC5, and I realized that the PLD is larger than the MBC5 by a large enough margin that the 2 footprints can sit one on top of the other without the pads overlapping. It will take some re-tracing, but this way I can eliminate the need for an extra PCB run, as I can develop both my first and second iterations on the same PCB layout. Here's what it looks like without rerouting any of the traces (so there are pads overlapping existing traces, but you can see the outlines will work out, once I've retraced everything going in to the MBC5). I haven't added the JTAG header yet, but that will go on here as well.
Looking good, I like the idea of em on top of eachother's foot print!
Here are some 5v 1Mbyte:
http://www.digikey.com/product-detail/e ... ND/2744704I guess you do have to level shift for the 2MB or more... My guess is you'd have to get those parts directly through micron assuming they are even still in production. The good news is you're going down on MOST pins. So you could just use voltage dividers for all the memory address lines. No need to shift mapper inputs. So it sound's like you'd only need a single level shifter for the data bus.
Keep in mind for testing and such you could probably run those non-5v tolerant parts at 5V inputs and keep the 3.3V supply. It'll put added stress on the part and not a good idea for the long term. But you could get by short term probably for development and testing.
Why not just use the XC9636XL off the bat with your 5V cart? Your 5V memory will still see 3.3V as a logic '1'.
I want to use all 5v parts until I am satisfied with the MBC5 clone. Level shifting, whether by resistors or actual level shifter IC's, is just added complexity which I would rather not have in my first iteration. I have no problem designing and ordering PCB's between iterations, so I'd rather develop a solid design that I reasonably think will work, then go from there. Understand that this is my first from-scratch, non-academic PLD project, so I want to start with a design that I can be almost completely certain will work as I implement and test my MBC5 clone. That in and of itself is quite an undertaking for me (though I have enough experience that I feel I can say it is not outside my abilities), and I want to start with a really solid circuit design, even if that means that this first run of PCB's really isn't all that interesting. So you might think of this first board as simply a test board for my PLD synthesis testing, before I go on to build my final project around the PLD once the MBC5 clone is fully vetted. At least with this design, I have the freedom to switch between the MBC5 and the CPLD on the same PCB, but I don't want to use an XL on this board, because although the I/O's are 5v tolerant, Vcc is not (absolute max 4.0v on Vcc). The final goal is to use only 3v parts on the cart itself. From what I understand, the MBC5 supports up to 64Mbit ROM and 1Mbit RAM, so that's probably the sizes I'll go with once I make the switch to 3v, as I know I can obtain in-production parts in those capacities with 3v logic. I may consider "cheating" with resistors on the input pins and only properly shifting the I/O's (which should just be the data bus), but I'll have to run it by my ESET professors and see what they have to say about that idea. I'd trust their experience more than my own conjecture, and although it may "just work" there may be unintended consequences that I'm currently unaware of, so I really want to check out the pros and cons of each method first. All the more reason to hold off on a 3v version for now.
infiniteneslives wrote:
The good news is you're going down on MOST pins. So you could just use voltage dividers for all the memory address lines.
I'd be worried about PCB space for that—for 20 lines, fitting 40 resistors larger than 0201s would be hard (and soldering 0201s would be a bear). Resistor networks would work, but they don't seem to sell any that are the right topology for this out of the box.
sorry i wasnt trying to convince you to go all 3.3V in my last post. Realizing 5V 2MB flash isn't really an option I agree your best bet is to stay 5V on the first iteration.
I was just saying adding a 3.3V regulator and the XL is effectively staying 5V on the cart, only the mappers outputs are 3.3V which 5V parts don't care about. But there isn't much difference between the XL and non-XL so it doesn't really matter much I guess. The non-XL parts are disappearing/discontinued so I just kinda ignore the fact they exist, but if you've got some go for it
lidnariq wrote:
infiniteneslives wrote:
The good news is you're going down on MOST pins. So you could just use voltage dividers for all the memory address lines.
I'd be worried about PCB space for that—for 20 lines, fitting 40 resistors larger than 0201s would be hard (and soldering 0201s would be a bear). Resistor networks would work, but they don't seem to sell any that are the right topology for this out of the box.
You'll fit resistors in the layout better than level shifters I'd imagine... I was suggesting it because of that fact. You could use normal resistor networks in pairs for each line. One set could have common ground and the other full parallel. Perhaps they wouldn't be much benefit though, I agree they would be a PITA for assembly...
The chips have their own internal resistance, so I wouldn't necessarily need 2 resistors per data line. I should just be able to measure the resistance on the chips and add a single resistor per input accordingly. However, for that, I may have to actually build the other cart PCB I was considering to just break out the GB cart to an IDC header so I can connect the cart to a breadboard and test it out. That would also give me the opportunity to do some current measurements. And I just got my hands on 4 of the non-XL PLD's, so that part is taken care of. I didn't realize that the non-XL versions were discontinued... one more reason to go with the XL in the final design
Anyway, I finally got the dual footprint traced (it was pretty tight, but I did manage it), added dedicated decoupling caps for each chip, and added the JTAG header. I'm pretty sure this makes the first PCB ready to order, but I'm going to sit on it for a day or two to see if I missed anything obvious (like last night when I thought it was done, but I'd left the JTAG header off entirely >.<). I couldn't find any standard pinout for a 6-pin JTAG header, so I went with the first one I could find. If there's an official 6-pin pinout, could somebody point me at it so I can set mine up right?
Also, could somebody take a look at
my schematic here and confirm everything's connected correctly? I'm trusting the MBC5 docs I've found online, as well as my interpretation of the pinout, so if somebody else could give it a once-over to confirm I haven't done anything totally stupid, that would be appreciated... In particular, my !ROMWE connection. I believe the way I have it connected is fairly standard for a lot of flash carts (connecting it to the otherwise unused pin #31), though I think maybe some flash carts just connect the ROM !WE signal to the cart !WE pin? Can anybody comment on the two connection configurations and which I should use and why?
Acually, I just found a couple of really stupid errors in my schematic now that I've looked at it
Where do ROM A12/A13 and RAM A12 connect? Do they just connect directly to the cart edge address lines? As it stands, it looks like I made a typo in the signal names, since they're not currently connected to anything >.< So yeah, if anyone else could take a look at the schematic in the link I posted above, it would be nice to have another pair of eyes look it over, since it's entirely possible there are other errors just as stupid...
qwertymodo wrote:
The chips have their own internal resistance, so I wouldn't necessarily need 2 resistors per data line. I should just be able to measure the resistance on the chips and add a single resistor per input accordingly.
That resistance is going to be pretty high, and the current draw on those input is going to be next to nothing. So you'd end up calculating some 1M+ ohm resistances and I wouldn't try sending your signals through that large of a resistance...
I really don't know enough about GB carts to provide any backup here. I would have a suggestion/advice though. Pull out a MBC5 game and your multimeter and draw out the schematic for yourself of the original cart. If you don't actually have a known good schematic for the original cart and are just assuming things based on the pinout docs I'd guess you've got a recipe for disaster... But as long as it's an easy fix by cutting traces and re-routing a few signals it won't be a show stopper for the prototype.
You're bound to have minor mistakes that aren't really a big deal for prototypes. Things that would be deal breakers are the entire chip being off by one signal on the MBC5, or inverting the pinout or something major like that. Also it's a good idea to print out your board on paper. Cut it out and place it in your case. If you've got components place them down on the paper and make sure you've got the right footprint. I've had problems where datasheets lied to me on the width of a chip before...
Hello!!! I was searching information on the MBC5 as I wanted to start working again on my MBC5 project and found this post, so here I am.
First, I never opensourced my design cause I never managed to make it work. It seems that my VHDL design is broken, I don't know where, I tried lots of things, and tested it with real games, custom ASM tests, simulations, etc, but I never found the problem. I designed a custom cart based on the flashcarts I already did using the original MBC5, so perhaps I have bugs also there.
qwertymodo, you're doing a great work with that dual mbc5/cpld cart, if you want I can try to help. I have already experience manufacturing flashcarts for the gameboy and also programming for it, I have lots of stuff here, flash and ram chips, my usb programmer, etc, etc.
Your cart looks amazing, The only thing I'd change (for a first revisiion before jumping to 3.3V logic as you say) will be using a 1mbit RAM instead the 256K one. I did that for my mbc5 flashcart so people can use lsdj, etc.
So, I'll wait for your answer, I'm really excited on the possibility of having a partner on this project
David.
The 1Mbit SRAM will have to wait for the 3.3v version, since 1MBit F-RAM only comes in 3.3v. Perhaps with your experience, you could elaborate on the different connection schemes for the ROM /WE signal. From what I understand, many carts connect that signal to the unused pin 31 on the cart edge. What about just hooking it up to the cart /WE? Games shouldn't pull /WE low when accessing ROM banks, so is there any issue doing so? I'm thinking that the way to handle the "MBC3 mode" is to monitor writes to the ROM header address and set a register in the PLD based on the cart type value in the header, which would then drive the if(!MBC5) logic, so understanding how to drive the ROM writes is an important part of that. The hope is that I can basically just monitor a ROM write (i.e. when you are flashing a new ROM) in order to detect when you're running a non-MBC5 game.
Also, I should just mention, reading that thread on the chipmusic forums felt exactly like this:
http://xkcd.com/979/Having you show up here in my thread momentarily gave me a surge of hope, until I read that you never got it to work... now this:
http://cdn.memegenerator.net/instances/ ... 523912.jpg
Hahaha! yes, there's light at the end of the tunnel!
Don't worry, it was my first project using programmable logic, so I was learning from scratch, and I was also looking at the mbc5 as a black box. Now I have a logic analyzer (the OpenBench Logic Sniffer), so it can be very handy to look at the timing of the original MBC5.
The SRAM, ok, my bad, I was overlooking the fact you don't have a battery on the cart!
so, you are using fram. I also looked at frams, but some years ago there were very expensive, and as you said, I couldn't find 1mbit ones at 5V, but it'll be great not having to use a battery and the protection IC. Perhaps we can make two versions, using a smaller 3V battery (to save space) with the SRAMs i'm using right now (very low power) and the one with fram (that can be used with *almost* all the original games).
About the /WR. I connected the /WR directly to the flash chip. Flash ICs have a nice protection schema, you need to send some unlock codes to the chip to write a byte or erase a block, so it's very unlikely than that unlock codes happen by accident. This way also has a nice side-effect, you can flash the chip from the gameboy itself. I tested this with some assembly code I wrote, and it works, you have to copy the write routine to ram, because when you write to the flash you can not read from it, and then jump to ram and execute the write routine, sending the unlock codes to erase a block (using the mbc5 to point to that block) and writing there what you need for long term storage.
Perhaps homebrew folks find this interesting
Mmmm, so what was the problem with the MBC3? IIRC, reading from the RTC registers would return nothing, and selecting them would select unused RAM banks, I'm wrong? Or you're planning on implementing the RTC? That will be great, but then you'll need a battery
Drag'n'derp has 1 Mbit FRAM if i am not wrong. and i could get no info about it being 3.3 volt. though it is expensive.
I'm already going to be building 2 different versions, one 5v and one 3.3v. Honestly, the 3.3v one is what I will consider the finished product, since I don't want my final design to rely on obsolete AM29F032's. Switching to 3.3v will allow me to use current, in-production, 3.3v Flash ROMs, which also opens the door for 64Mbit ROMs. It also allows the 1Mbit FRAM. The 5v design is really just an intermediate step for testing my MBC5 clone. I don't see the point in making a 3rd version with SRAM, other than cost, which isn't a compelling reason for me. If you want a cheaper SRAM design, you can just take my MBC clone and make your own (assuming my project doesn't end like yours
). As for the problems with MBC3, basically, the MBC5 is *almost* completely backwards compatible with the previous MBC's, but not quite. The minor differences are the reason for the issues discussed and being patched in
this thread. If you read the last page of that thread, you'll see my questions regarding this project and that should explain to you what I mean when I say I want to properly emulate the MBC1/2/3 for non-MBC5 games, in order to handle those issues in the PLD, rather than patching the games like they're doing there. Can you elaborate on what isn't working with your design? You posted screenshots showing that you at least had a game running, so where did it fail?
Of course, I was not telling you to share your project, If I'm right it looks that you plan on opensource the project, so if you are, perhaps I can set up a git repo and share what I have right now, hardware and software side, and we can start working together. I never planned on making a real commercial product, just an opensource cart (like my previous one with the real MBC5), and perhaps just sell some of them at the forums, but as I say, as an opensource project. Ok, so, what's your plan on emulating the other MBCs? It's difficult to know using just the MBC's writes when a game wants MBC1,2,3 or what. The easiest way to tell is reading the cart header, but for doing that you'll need more logic, a microcontroller for example, to read that header and tell the CPLD what to be (using for example two lines to configure it as MBC1, 2, 3, or 5)
As for my MBC5 implementation, I don't know, it looks like a timing issue. I used the xilinx simulation to look at the output of my MBC5 clone, and it does what it's supposed to do, banck swithcing, sram activation, etc, but then on the real cart, it works badly. The first tests were made using a homebrew game (the one in the screenshots), and it worked, but then with commercial games like mario or zelda, it doesn't. Then I tried using my own tests written in assembler, and I started to see some weird things. With the real MBC5 these tests work perfect, but in my MBC they do weird stuff, it looks like a timing problem, it's hard to explain. Perhaps I can show you the code of the test and shot a video with the real and my mbc5 so you can see what it does.
Also, if you want, I can send you one of my mbc5 carts and usb programmer, and also one of the carts I already manufactured using the CPLD, but they have a big problem, they don't have the JTAG pins accesible, so I have to solder wires to the CPLD to program them
I was too optimistic looking at the simulation so I thought I could program the chips off-board and then solder them
I think that my plans at this point are to open-source the MBC code, and then keep the cart designs to myself. Honestly, there is already sufficient information out there to put one together... I'm willing to share my work to emulate the chip, since that will provide an alternative to donor carts (though I don't know of anywhere to get cart shells manufactured, so unless I figure that out, I suppose donors are still a necessary evil...). I'd be glad for your assistance, and if you'd be willing to send me one of your carts, that would be amazing. I'm perfectly capable of doing the manual soldering necessary to add the JTAG header, so that's not an issue. Do you happen to have any timing measurements from the actual MBC5 to test against? If your functional simulations worked fine but failed on the hardware, then 99% certainty either you have bad hardware or bad timing, and I'd be willing to bet you're right on it being the latter.
As far as my idea for setting the compatibility mode, I think now that it won't work. The original idea was that since the compatibility mode was determined by the ROM, it wouldn't change unless you flashed a new ROM, so when you access Bank 0 in write mode, wait until you go to write the cart type byte and set the compatibility in the PLD's nonvolatile memory accordingly. I wasn't thinking of the fact that none of the lower address lines attach to the MBC, so I have no way of knowing which byte in the bank I'm accessing. So, I'll have to figure something else out. Getting MBC5 mode working right will keep me busy for awhile anyway.
Ok, it's done then, along this week, I'll be uploading my MBC5 code to a git repo (well I have two branches, one in VHDL and one using the schematic design in xilinx ISE), so you can see it, and if you send me a PM with your address, i'll send you the carts and the programmer. I have little spare time from mon to fri, but I'll try to get the solder ready and measure some timings from the real MBC5.
I'll also try another thing. I have a working model of the ROM swithing part of the MBC1 in ttl logic (74xx based for a small game series we produced some time ago) so I'll try this with the xilinx schematic editor (that has 74xx models) to see if the cart it's ok.
Ok lots of work to do! let's start.
Wow, wow, as I told you I wanted to try with the MBC1 rom mapper design I did using 74xxx chips some time ago, I implemented that in the xilinx ise schematic and it worked, so I started to grow it up adding ram banking, all the mbc5 rom banks, etc... and after lots of tests and CPLD program/erase cycles, It's seems to work! I have just played super mario bros deluxe dx on my CPLD cart, went through several leves, saved the game, turned the GB off, on again, loaded the saved game... it works!
I'm uploading right now Zelda DX to my cart to make another test...
EDIT: It works!!! zelda dx tested.
Ok, I'll be sharing the design as soon as I test it a little more, I'll also try to take the current design and translate it to VHDL now that I know what I was doing bad in my previous designs. And I'll also make a better version of the cart using newer components and a smaller battery.
qwertymodo I'll send you the cart/programmer so you can work on your FRAM version, no worries
People, can you tell me difficult games to try on the cart? (difficult as in heavy mbc5 use, lots of banking, use of save ram, etc)
That's awesome to hear!
For MBC stress testing, you might try some GBC games, especially larger ones. The other thing to take into account is how MBC1/2/3 games run on your MBC5 emulation. Chances are, you'll run into the same bugs listed in the thread I linked a few posts back. So once you get MBC5 worked out, you might look into that issue and how to address it.
Now I also have a VHDL implementation that works, I've been playing Zelda DX for 30 minutes, saving and loading the game, perfect. Another step, let's see...
Has any additional progress been made on your MBC5 clone xzakox?
I got bored the other night and randomly found the GBC cart that I'd ripped the MBC5 off of and decided to do a full continuity trace so I could actually get around to finishing my cart, and here's the result. Nothing too special just yet, MBC5/XC9536 dual footprint, AM29F032B 32Mbit ROM, FM18W08 256Kbit F-RAM, JTAG header, all running at 5V. If this works, I'll get to work on the 3.3V version. I've already selected the parts (XC9536XL CPLD, M29W064 64Mbit ROM, FM28V100 1Mbit F-RAM), so it shouldn't be too difficult...
To dig up an old topic, have either of you guys made any progress on your MBC5 CPLDs? Curious if you guys got your respective projects working and/or if you'd be willing to share the results (and the cpld code maybe?)
BUMP!!!
To Re'Dig same Q here any news luck etc... and does this link and gerber files help at all?
http://wiki.ladecadence.net/doku.php?id=cartucho_flash