Gameboy Development Forum

WeaselBomb · 2018-03-06 12:36:40

I have been developing a 2 MB flash cart using an authentic MBC3 chip that uses an FM18W08 FRAM chip instead of the usual SRAM. I believe it is nearly done, I can program/erase/dump my ROM, but I am experiencing some issues with my FRAM, which I believe are probably timing related.

This FRAM requires a "falling edge" of #CE to latch new addresses, and I'm not sure how to accomplish this. The #RAMCS signal coming from the MBC3 doesn't seem to provide the proper strobing for this chip, but I can't say for sure without a logic analyzer of some sort.

See, in MBC3 cartridges, the #CS signal of the cart slot does not connect to MBC, as it does with MBC5 carts. I know FM18W08 works in an MBC5 cartridge, so I figured I would use the #CS signal and connect it directly to my FRAM #CE. Comparing the timing of my FRAM to the following diagram made this seem like a plausible solution:

According to this image, #CS should rise and fall for every read and write, perfect for latching addresses in my FRAM. However this still does not work, and on booting my Gameboy, the logo displays, but then the screen just alternates between two states: all pixels on, and all pixels off (not sure if this is important).

My final questions are:
-Is this mod possible?
-Is this FRAM chip compatible without introducing any more extra parts not already in my cartridge? (ROM, RAM, MBC, Backup power chip)
-Can the #CS signal actually be used for strobing #CE on my FRAM, or am I just doing it wrong?

Any help would be GREATLY appreciated, I'm about to lose the last of my marbles.

Here is my latest prototype:

Last edited by WeaselBomb (2018-03-06 12:44:00)

gekkio · 2018-03-06 13:04:11

The problem with using #CS like that is the fact that you're sharing the bus with the work RAM, and the CPU puts #CS low when accessing it too. In fact, in at least 1st gen CPUs any access in the 0xA000-0xFDFF range will toggle #CS low.
You need some extra logic to make sure your chip is active only in the external RAM address range. For example, an OR gate connected to A14 and #CS could give you a better chip select signal.

For some more timing diagrams, look at the end of my reference document: https://gekkio.fi/files/gb-docs/gbctr.pdf

Edit: Forgot to mention that the data in my document is only verified on 1st gen GB CPU chips (DMG, SGB). Also, at least OAM DMA uses slightly different bus timing and IIRC CGB and later models had some difference in general timing as well. So there's actually quite many different timings that you'd need to support to be fully compatible.

Last edited by gekkio (2018-03-06 13:12:21)

WeaselBomb · 2018-03-06 14:49:16

Thank you, I'll start reading that later today.

Wait a minute. Is that how the MBC3 decides to toggle #RAMCS? I just remembered it has inputs for A13,A14, and A15. If it gated the three of those, wouldn't that determine the output of #RAMCS? I want to say A15:A13 would have to equal 101 for #RAMCS to be low?

If that is the case, I'm still left with the issue of toggling #CE for every RAM read and write. Normally, it is ok for #CE to stay low for consecutive reads/writes, but this FRAM requires falling edge for each new address access.

That means, maybe I could gate #RAMCS and #CS? If they are both low, then assert #CE low? The #CS signal would supply the falling edges I need because it goes high for every read and write?

Edit: After using a pair of diodes to OR those signals, it appears to be working. Will take more testing to know for sure.

Last edited by WeaselBomb (2018-03-06 17:48:38)

gekkio · 2018-03-06 17:49:51

Yeah, at least on 1st gen CPUs, #CS is pulsed every time the CPU does a read or write from 0xA000-0xFDFF. However, I just confirmed that this doesn't apply to OAM DMA, which simply increments the address and never pulses any control signals.
It's probably a rare thing, but some games (IIRC for example SML2) use a part of the cartridge save RAM as generic work RAM, so in these kind of games your flash cart would mess up the sprites if the game attempted OAM DMA from that address range.
For full compatibility you'd probably have to involve the PHI (aka cartridge CLK) pin to get the pulsing you need. A 3-input OR with A14, CS, and PHI could maybe work as a chip select...

WeaselBomb · 2018-03-06 19:22:04

Yes, adding the CLK signal seemed to do the trick for SML2. Just using RAMCS and CS seemed to work for my other games, but I would like that more complete compatibility. Thanks so much for all your advice, it really helps.

WeaselBomb · 2018-03-12 17:00:56

I have a new question: are there any special considerations I should take into account for the Gameboy Advance? My cartridge is now running smoothly on both DMG and Color systems. I have been playing around with Pokemon Prism (a rom hack of Pokemon Crystal), and the save file is not detected. The game also crashes after the first battle. It runs fine on my DMG and Color, however. I could reach out to the devs, but I'm afraid there will never be a response. Was wondering if you had any more useful insight.

ArnyLogan · 2018-08-17 13:14:05

Hi...i am a new user here. In my case i did a few tests with the Akuma demo trying pull-up and pull-down on the MISO pin. It doesn't help, only changes the behavior slightly. I also noticed it isn't necessary to touch any pin of the SPI RAM, just hovering a finger right above the chip causes distortions, and touching the SPI lines on the AVR's side has no effect touching reset has which is next to the SPI pins.

pcb printing and assembly

Last edited by ArnyLogan (2019-06-12 17:07:57)

Gameboy Development Forum

Ads

#1 2018-03-06 12:36:40

MBC3 Flash Cart with FRAM

#2 2018-03-06 13:04:11

Re: MBC3 Flash Cart with FRAM

#3 2018-03-06 14:49:16

Re: MBC3 Flash Cart with FRAM

#4 2018-03-06 17:49:51

Re: MBC3 Flash Cart with FRAM

#5 2018-03-06 19:22:04

Re: MBC3 Flash Cart with FRAM

#6 2018-03-12 17:00:56

Re: MBC3 Flash Cart with FRAM

#7 2018-08-17 13:14:05

Re: MBC3 Flash Cart with FRAM

Board footer