Gameboy Development Forum

/CS is used as chip select for any memory external to the CPU in the 8000-FFFF region, ie both the Gameboy's work RAM, and cartridge SRAM. Your MBC implementation needs to to do additional decoding and should ideally only select external SRAM when /CS = 0, as well as A15:A13 = 101. This has nothing to do with whether the memory position is accessed as code or with a load instruction.

A15 is practically a /CS for ROM, so when A15 = 0, cartridge ROM is selected. It is sufficient for a 32 kiB ROM only cartridge without a MBC to use A15 as a /CS for the ROM cartridge without additional decoding, for example.

doragasu wrote:

Also I have another question regarding latches and CPLDs/FPGAs. I have seen EVERYWHERE that you should not use latches with CPLDs/FPGAs because they are bad and can cause timing problems. But I have searched several books and NOBODY explains exactly why latches are bad, and the implications of using them. Just the usual "Don't use latches" statement, and that's all. I know latches may appear because of bad coding (e.g. not updating a signal in all the branches of an IF/ELSIF/ELSE statement), and of course it makes sense avoiding latches in these cases. But as MBC controllers do not use a clock signal, the rom bank, ram bank and ram enable registers must be implemented using latches. What are the implications of using latches here? Will it work? Will it work but with some glitches? Will it work but too slow to meet timing requirements? Will it make the CPLD/FPGA burn/explode? Will it create a continuum space bubble?

The reason latches are evil lies in the fact how they map to hardware. Using flip flops, you naturally need some kind of clock, but since latches are asynchronous to any clock signal you could ever produce, they would violate hold/setup times of your flip flops. Thus, latches are mapped in such a way that the control signals -- the signals that determine if and when data is latched -- go through a look-up table (LUT) and then on to the clock pin. However, since your control signals might a) also be asynchronous to each other and b) are likely routed with tiny timing differences, the LUT might toggle it's output multiple times in rapid succession. That's a big no-no for clock lines, because it will violate any and all setup/hold time requirements your flip flops have. This can lead to your flip flops settling in the wrong state, i.e. 0 at D, but 1 at Q after the clock line toggled. Even worse: this can lead to meta-stability where a flip flop becomes unstable and does not settle to a valid logic level at all resp. settles very slowly. This will draw a larger-than-usual amount of power, because the transistors the flip flop is made of are acting as resistors and sink/source current.

You can also find this information (and more) when you follow the DRC warnings about gated clocks in your synthesis tools.

Now, will it work? Most likely it will work most of the time, because your control signals are very slow (~1 MHz) and setup/hold times of modern parts are very short.
However, your assertion that MBC registers must be implemented using latches is false. You have to integrate your logic into a synchronous design flow and synchronize your input signals by oversampling them above the Nyquist frequency, i.e. 4 MHz will be plenty for ~1 MHz signals. So input pin --> oversample --> synchronize --> synchronous logic --> register --> output pin.

cYa,

Tauwasser

Last edited by Tauwasser (2015-02-17 23:08:32)

I have been searching PLL chips and unfortunately they either cannot work at 1 MHz (they requiere higher frequencies) or are too expensive, or require special programming hardware (like the CY22801) or are too complex (like 4046/7046 based ones). I'm tempted on trying with ICS501: small, easy to use and not expensive (about 1.5€ on Digikey). Unfortunately minimum operating frequency is 2 MHz .

The other option is to grab a a calculator, a 74HC4046, a divider/counter, some passives, read a ton of documentation and design the PLL myself...

Or I could just use an oscillator, but I'm wondering if I might have problems due to metastability because of the out of sync clocks.

Hi,

I see you have given this some more though Yes, I was talking mostly about FPGAs and newer CPLDs. I wasn't actually aware that the Coolrunner II had transparent latches that could be used that way.

I think I confused you into thinking that your main clock should run at 4 MHz? That's not the case. You should merely sample at 4 MHz. What this boils down to is having some system frequency, e.g. 100 MHz, and a counter that divides that frequency, e.g. 25. You then count from 0 to 24, 0 to 24 etc. and every time you hit 24, you sample your asynchronous signal and shift all the data one place further.

Remember that frequency is proportional to power dissipation. So you should probably not clock your Virtex 7 FPGA at 1 GHz for this . This is also where the DataGate and ClockGating of the Coolrunner II family come in handy. I also strongly encourage you to convert your design to be synchronous. All Xilinx tools use a synchronous design approach. For CPLDs, the mapping is probably easier, since they're way smaller than FPGAs, so timing closure is easier. But I've seen Xilinx tools produce wonky results with asynchronous paths way too often!

#CS behavior should be:

On for A000-FDFF, off for the rest of the time.

You don't see VRAM accesses on the main bus, because VRAM has its own address/data busses along the necessary control lines. A14 and #CS are connected to WRAM (CS and #CS respectively), which is why E000-FDFF is an alias for C000-DFFF. Jeff Frohwein's schematic says A13, but that's wrong.

The simplest approach is to decode the upper address bits along with the control signals to determine the if level shifters should be tri-stated or not. You can often use #RD for DIR for many level shifters. If you select a part with a different polarity, just decode that as well.

So

A15 A14 A13 #CS #RD #WE | #OE  DIR
------------------------+---------
 0   -   -   -   0   1  |  0    0  -- ROM Read
 0   -   -   -   1   0  |  0    1  -- MBC Write
 0   -   -   -   1   1  |  1    -  -- ROM Idle
 1   0   0   -   -   -  |  1    -  -- Unused
 1   0   1   0   0   1  |  0    0  -- SRAM Read
 1   0   1   0   1   0  |  0    1  -- SRAM Write
 1   0   1   -   1   1  |  1    -  -- SRAM Idle
 1   1   -   -   -   -  |  1    -  -- WRAM Any

You might even leave #CS out of this and just decode by address. There are some Chinese pirate carts that do that apparently

cYa,

Tauwasser

Last edited by Tauwasser (2015-02-22 16:42:57)

doragasu wrote:

Edit2: Re-reading your post, it looks like it's not possible to use cart #CS to drive level shifter #OE, I'll have to generate it using the CPLD.

Correct. However, you should have some pins to spare for that...

doragasu wrote:

Edit: another thing I've been thinking about, is if I should drive the RESET line in the cart. I do not know how much time I have for the CPLD/Flash to initialize before the gameboy starts requesting data from the cart.

You need to have 1.8V and 3.3V anyway. You should be fine using a power monitor or power good signal from your LDO. These are open drain most of the time and tolerant up to VIN. That should buy you enough time until the CoolRunner II is configured. Family Datasheet says roughly 50us, vs. several ms that power monitors or power good pins can usually be configured.

You should also use #RESET to reset your MBC, so the registers start in a default state (some games expect that).

doragasu wrote:

I can't see the benefits of converting my current design to synchronous.

There's a reason "Use strict synchronous design" is mentioned in hardware and software practices in Bulletproof CPLD Design Practices. You're right though that it would possibly use more power.

doragasu wrote:

I have placed a monolithic oscillator attached to GTS2 just in case I finally need to go synchronous (or just want to try).

You probably mean GCK2? GTS is Global Tristate Enable. Take special note of the VCC, VREF and VCCint pins as well as decoupling. You could also think about connecting the cart edge clock to one of the GCK pins as well.

doragasu wrote:

I would like that the only signal I'll generate, besides the ones present on a original MBC5 chip, is the write enable signal for the Flash chip (to be able to program the cart by plugging it to a custom programmer).

It's funny you should mention that. The original development cartridges all use AIN as #WP of flash chips and use it to gate the #WE from MBC5-D to flash.

cYa,

Tauwasser

How do you plan to safely switch battery backup power? Or will the SRAM continuously run from a battery?

How do you want to program the flash? You need to keep in mind that you likely still need to be able to address the ROM bank register in order to flash it. So you can't just use a magic number to "unlock" flash we#, because then your writes to the MBC will go straight to the flash as well. That's why Nintendo used an additional line. One possibility would be to make writes to flash using #CS and #WE asserted in 0x0000-0x7FFF go to flash after flash writes were unlocked, say using 0xA5 => 0x6000-0x7FFF or something.

Keep in mind that this will necessitate writing your own flashing firmware. Open Source solutions (GB Cart Flasher) support #AIN and #WE going directly to flash out of the box.

Now on to your main problem. You want to give the RAM and ROM address lines dedicated pins, which reduces your pin count by 4. You don't need to do that. Instead, multiplex the lower address pins. Even if you use one FF/Latch in a macro cell, you can still use its pin as an input pin!

I quickly made a design to check it out. Basically, you use 28 pins + 2 clock pins (GCK2 for OSC, GCK0 or GCK1 for GEC Pin 2 maybe) and thus have 3 pins to spare of the 33 user I/Os total on TQFP-44. On the plus side, you'd still have 17 registers.

doragasu wrote:

Yes, that's a possibility that crossed my mind, but you never know, in the future I might add a DSP and a DAC to create the coolest audio effects ever heard on a gameboy

You mean: on the old mono GameBoy.

As a side note: Now I notice why you're so hesitant to make a synchronous design. It would really require a bigger part and you seem set on the XC2C32A? I don't blame you.

cYa,

Tauwasser

Last edited by Tauwasser (2015-02-22 17:24:39)

You should probably look into a MAX16024 or similar device. They also happen to have a power monitor integrated and do the battery switchover for you. Battery switchover is somewhat tricky, because you have to know a lot about your diodes and probably simulate the circuit. If your SRAM loses power for even a slight moment, your savegame might be ruined.

Diodes take a while to fully open and then to close again. And then there's the problem of inrush current. Basically, I have the same circuit here on an unlicensed Sachen cartridge and it eats CR2032s for breakfast... They don't have a series resistor, so that might contribute to the power drain. However, a savegame barely lasts on these lol...

Also, you can do whatever you like for your flash mode. You just want to make sure that SRAM is locked during flashing. The Nintendo carts don't automatically lock, they just prevent you from writing to the SRAM lock register.

Will you have a separate connector for JTAG, or will you multiplex these onto the cartridge edge and have an enable switch? Kinda getting excited here

cYa,

Tauwasser

doragasu wrote:

I will have to re-read my notes about diodes, because I cannot remember about the inrush current problem you mention.

Inrush isn't specific to diodes. Rather, it refers to the fact that when an unpowered circuit is connected, all the capacitors have to be charged for the first time. This creates a high current that is sometimes higher than the static current of the circuit.

The problem with switching VCC and VBAT stems from the fact that you have capacitors before and behind the VCC diode. This will artificially widen the time your VCC diode stays open until the point where it closes, the decoupling cap supplies the SRAM and the VBAT diode is open. Because you have a slight voltage drop on on the SRAM side, you might experience a higher-than-usual current transient.
Or so I'm thinking. It depends on the switching characteristics of the diodes, the capacitors and the SRAM, which is why I'd spice it to make sure I don't lose my savegame. Although you should probably be fine.

doragasu wrote:

Again, nice suggestion, but I'm sorry, I'll use a separate connector. Again, to keep things simple.

I wasn't so much suggesting it as just wanting to know your plans. I find designing PCBs immensely exciting and kinda liberating.

doragasu wrote:

To power the cart and reset the console, I've selected a LP3996SD-1833. I have connected the EN2 pin to the 1.8V output, so the 1.8V rail starts first (3.3V rail is enabled once 1.8V one is over 0.9V).

That seems like a good plan. Power Sequencing does not matter for Coolrunner II, but VCCINT before VCCO is a good idea. Be sure to read up on VCCAUX, maybe you can save some power by only selectively connecting it?

cYa,

Tauwasser

And now, for something completely different, the usual PCB design capture:

Should've shared a schematic as well, really.

I: Layer shenanigans. You can easily route most of this stuff on BOT, cross over just once. This goes for the power track on the left as well.
II: Too close to edge for comfort. I don't immediately see a reason why the switchover stuff cannot be on the right side under the battery.
III: Should use a couple of vias like under the CPLD.
IV: Depending on cartridge housing, there's another plastic stub here, so a hole's missing.
V: Some higher-density/different manufacturers' parts have additional address lines and/or #WP write protect here. Best to connect to GND.
VI: I don't like your Pin1 markers for the simple fact that cheap houses don't do silkscreen as well as slim lines sometimes vanishing. Heck, I've had my name vanish with some Chinese fab... A smear on the silkscreen and half the name was gone
VII: Diodes need polarity indicators
VIII: Positive BAT terminal. You might want to include a series resistance just in case here anyway. Populate with 0R or solder bridge if you don't need it, but should definitely include it.
IX: Pull the via out a little, so it's not under the pad.

Some things depend on whether you cover most of the via with solder mask or not, but for instance SRAM top right pin is very close to unrelated via. Depending on part, your level shifter U3 might need the unused B side ports also connected to ground.

You might want ground plane around your clock line for coupling. At 1.6mm, you don't really have coupling from the other plane. Also, you cross over the clock signal from the other side.

Flash might need external pull-up on #WE depending on part. EDIT: Just noticed, but, err, you might want to move the JTAG header to the right side under the battery so it doesn't prevent the cartridge from being inserted into a Game Boy, or do you plan on soldering some wires anyway?

doragasu wrote:

It's now time to figure out how to program the thing. As I have wired pin 31 to the flash chip #WE, GB Cart Flasher shown here should work, right?

Depends on the flashing algorithm for unlocking. It supports two algorithms (12bit and 16bit, I think?). Anyway, I do have C source code files (which I created myself from the assembly source), which I'll upload some time soonish anyway, so you might as well check them out. So yes, the flasher will work. You might want to look into a more condensed SMD design, like the V6 from David Pello, see http://wiki.ladecadence.net/doku.php?id=programador, which includes the ISP header the the older design is so blatantly missing (the debug design had it, as can be seen on dev pictures, but they took it out before release -_-").

cYa,

Tauwasser

Last edited by Tauwasser (2015-03-10 20:56:48)

doragasu wrote:

I: I may route some of them on the bottom layer, but I was trying to avoid cutting the bottom ground plane on some zones (specially on the zone of the power line on the left).

That should be fine. I'd rather not have a million vias on my signal lines instead.

doragasu wrote:

IV: Do you know exactly where should I put this hole? I hope it is small, that zone is a bit crowded.

Yes.

doragasu wrote:

About level shifter, I have connected to ground unused pins only on one side, because level shifter has push-pull outputs and those lines are always used on the same direction.

Well, it wasn't immediately obvious if the level shifter had two ports or just one. If it's two, then yes, you don't need to connect the other side for unidirectional shifting.

doragasu wrote:

I was thinking if there is maybe a more suitable connector, test point or something that would allow to program the CPLD and then put the PCB inside the cart case without problems.

Well, you can always got for those cell phone connectors. Personally, I'd try to put them to the side or the very top at least. Of course, you can always stuff six wire wrap cables in there and connect them to a header that dangles outside.

doragasu wrote:

Another question about the programmer... Is there an alternative to sacrificing a gameboy to reuse its cart connector? I searched Digikey and Mouser for 1.5mm pitch connectors and found none .

I did not find one. However, I recently learned that NDS Slot2 connectors will work. These are like 3 USD per connector: http://www.dx.com/p/repair-parts-replac … lite-37787

cYa,

Tauwasser

Made some of the easier changes suggested by Tauwasser. Also placed the second mounting hole (but have not moved the tracks yet):



Accommodating the second mounting hole will be painful. I'll have to move U4 and re-route a lot...