It is currently Mon Oct 23, 2017 1:58 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 35 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Sun Nov 04, 2012 1:13 am 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 759
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 :P 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?


Image



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?


Top
 Profile  
 
PostPosted: Sun Nov 04, 2012 1:26 am 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 759
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...


Top
 Profile  
 
PostPosted: Sun Nov 04, 2012 1:43 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
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...

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Sat Nov 10, 2012 5:03 pm 
Offline
User avatar

Joined: Sat Nov 10, 2012 4:44 pm
Posts: 7
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.


Top
 Profile  
 
PostPosted: Sat Nov 10, 2012 6:59 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 759
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.


Top
 Profile  
 
PostPosted: Sat Nov 10, 2012 11:40 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 759
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

:P


Top
 Profile  
 
PostPosted: Sun Nov 11, 2012 2:50 am 
Offline
User avatar

Joined: Sat Nov 10, 2012 4:44 pm
Posts: 7
Hahaha! yes, there's light at the end of the tunnel! :lol: 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! :oops: 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 :P


Top
 Profile  
 
PostPosted: Sun Nov 11, 2012 6:18 am 
Offline

Joined: Mon Oct 22, 2012 6:38 am
Posts: 20
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.


Top
 Profile  
 
PostPosted: Sun Nov 11, 2012 10:22 am 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 759
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 :P). 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?


Top
 Profile  
 
PostPosted: Sun Nov 11, 2012 12:00 pm 
Offline
User avatar

Joined: Sat Nov 10, 2012 4:44 pm
Posts: 7
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 :P
I was too optimistic looking at the simulation so I thought I could program the chips off-board and then solder them :)

Image


Top
 Profile  
 
PostPosted: Sun Nov 11, 2012 7:10 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 759
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.


Top
 Profile  
 
PostPosted: Mon Nov 12, 2012 12:26 am 
Offline
User avatar

Joined: Sat Nov 10, 2012 4:44 pm
Posts: 7
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.


Top
 Profile  
 
PostPosted: Wed Nov 14, 2012 4:22 pm 
Offline
User avatar

Joined: Sat Nov 10, 2012 4:44 pm
Posts: 7
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)


Top
 Profile  
 
PostPosted: Wed Nov 14, 2012 7:46 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 759
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.


Top
 Profile  
 
PostPosted: Thu Nov 15, 2012 1:46 pm 
Offline
User avatar

Joined: Sat Nov 10, 2012 4:44 pm
Posts: 7
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... :D


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 35 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Yahoo [Bot] and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group