Gameboy Development Forum

I don't have time for a complete review of your changes right now. Some things that come to mind right now:

1. I like the boxes for C11, C12, D1.
2. Consider moving R8 to above right of D1, might make routing signals easier.
3. You're routing too close to the mounting hole. Most fab houses have strict rules about signal lines near PCB edges (including holes). For instance, seeed studio has 0.4mm min distance, itead has 0.3mm. They will definitely tell you they cannot guarantee the innermost tracks around the smaller hole. I didn't say anything about the tracks near the bigger hole, because they look like they might just be in tolerance, but you should probably double check and move the data line a bit up anyway.
4. PCBs are 0.8mm thick, IIRC. I measured it once and found it was one of the standard thicknesses.
5. Honestly, I think you shouldn't go too custom on the JTAG connector. It's a pain for anybody using the thing. At work, we use Hirose LX60. They're a bit pricey if you buy just two or three, but we found they were the flattest connectors that were readily available male and female. Of course, that was like five years ago. Something more cost-effective might have emerged. The simplest solution would still be a 90° 2.54mm header out to the top.

cYa,

Tauwasser

Now I have two questions about the RAM.

The chip I decided to use is a CY62128EV30LL [PDF datasheet]. I think I made a mistake and when the console is powered off, both #CE1 and CE2 are left floating. But I suppose this is undesired, right? Would it be enough adding a pull-down just on CE2? Or do I need to drive both pins? In case I have to drive both, I suppose I should add another pull-down to #CE1 (because a pull-up on this pin would waste additional current when battery powered), right?

The other question is related to the battery life. Current design uses a CR1220 battery (plus battery holder), and I'm wondering if it will last long enough or I'll have to jump to a CR2032 (without battery holder, I don't think I can make one fit). From the RAM chip datasheet, you can read this:
- Typical standby current: 1 uA.
- Maximum standby current: 4 uA.
- Data retention current: 3 uA (max).
- Automatic CE  power-down current -- CMOS inputs: 1 uA (typ), 4 uA (max).

Now, how should I do the maths? If battery capacity is 35 mA/h, should I pick the typical standby current?:

t(years) = 35/0.001/24/365 = 4.

Or should I add typical standby current to data retention current?:

t(years) 35/(0.001+0.003)/24/365 = 1.

Or should I do anything different?

doragasu wrote:

I think I made a mistake and when the console is powered off, both #CE1 and CE2 are left floating. But I suppose this is undesired, right? Would it be enough adding a pull-down just on CE2?

Yes, add add a PD resistor. Leaving them floating is not an option. You don't need to drive both, however, floating pins mean switching inputs, which in turn means an increased power consumption. However, switching pins are unlikely when you don't have some other resistance pulling it outside of Vil_max or Vih_min. However, it doesn't hurt you to add a 1M to #CE1.

I think you have #CE1 connected to the PLD and CE2 pulled up to VCC? Official carts usually have #CE1 connected to their mapper and CE2 connected to the SRAM backup IC, pulled down when VCC is off and connected to VOUT (VCC or VBAT) when VCC is at ~3.3V (MM1026) or ~3.5V (MM1134).

doragasu wrote:

The other question is related to the battery life. Current design uses a CR1220 battery (plus battery holder), and I'm wondering if it will last long enough or I'll have to jump to a CR2032 (without battery holder, I don't think I can make one fit). From the RAM chip datasheet, you can read this:
- Typical standby current: 1 uA.
- Maximum standby current: 4 uA.
- Data retention current: 3 uA (max).
- Automatic CE  power-down current -- CMOS inputs: 1 uA (typ), 4 uA (max).

Notice how data retention current @ 3µA max is only guaranteed for industrial parts.

Having said that, let's take a look at some random Wario Land game I have here on my desk.

CR1616 battery was produced '97. MBC1 on there says '97, week 44. Save game is still good.

VBAT @ 3.171V, 10k series resistance. 0.2mV drop over resistance. So that's 0.02µA out of my battery that I can measure. One would assume consumption to be higher, i.e. my multimeter shouldn't be at its resolution limit, which it is at tenth of a mV.

Backup IC is BA6129A (MM1026A alternative). It's rated at 0.5µA max Iccb. RAM is BR6265BF-10SL. It's rated 20µA max Isb when CS2 is deassert, #CS1 floating (which is the case on Wario Land's DMG-DECN-10 PCB).

Now, CR1616s have typically 55mAh when using a brand, which Nintendo likely did. I perused an Energizer datasheet and some websites to come to this figure.

55mAh * 1d/24h * 1a/365d = 6.28µAa (micro-ampère years)

So clearly, if these parts had ever hit their max Iccb, resp max Isb, the battery would be long dead by now. When we use the manufacturing information I gave earlier, I'll roughly say it's been 17 years for that battery. So the typical consumption should have been at 6.28µAa / 17a = 0.3µA if the battery was empty now. However, this particular battery is almost brand-new (3.171V). I've seen them go as low as 2.6V and still be operational.

As you can see from my little ballpark calculation there, although the SRAM is rated very poorly in today's terms (20µA), the mean consumption couldn't even have hit 0.3µA, or the battery would be dead.

So I guess the real answer here is: Worst case, your battery lasts a year at typical current consumption and then it's gone. Best case: throw all those values out the window and have it last 10+ years.

doragasu wrote:

One more question... how tall can components be, to fit inside a cart case? I'm browsing CR2032 battery holders, and smaller ones are 4.32 mm or 3.96 mm tall...

On a side note, while the CR1616 might require 0.4mm more radius real-estate, at 1.6cm it's flatter than your CR1220 (1.2cm x 2.0mm). Battery holders are always problematic. 3.96mm strikes me as very flat, considering CR2032s are 3.2mm tall. Don't have a digital gauge here ATM. The Game Boy game case itself seems to be 4.x mm tall, however the top shell is definitely < 4 mm (however, it sits on top of the PCB).

A regular CR2032 is already a tight fit. You could use a CGB shell to make a CR2032 fit, however, that would necessitate a complete redesign of your PCB, as there are two screws on the lower edge.

cYa,

Tauwasser

Looking good so far. You should seriously consider routing some signals under the QFP. That way, the connections aren't as awkward around C16. The routing space is going to be a premium for the the GEC to level shifter part. You used roughly twice as much space before. Did you mean to change top and bottom colors/layers?

cYa,

Tauwasser

Any news on this? Or is it a case of the Real Life?

cYa,

Tauwasser

Routing almost finished, just a bit of cleanup remaining (unless I decide to move the tracks under the battery to the bottom layer):



I'm happy with the redesign, a bigger battery footprint, and I also think routing is a bit better ^_^

Just a quick question... Is there a readily available programmer I can buy for this thing? I'm using pin 31 for the Flash write enable...

Thanks again for the design review, you even bothered redrawing some tracks!

About (I), I wanted to avoid routing the track under the battery. I might try rerouting it without using vias, but it will slightly fall under the CR2032 body.
About (IV): In the screenshot it looks like via is extremely close to the left track, but it is not closer than many other vias (I have double checked). Maybe it is a GerbView rendering problem. The minimum track width is 8 mil, and minimum clearance is also 8 mil. The designs passes DRC checks without a problem.

About the programmer, I have finally decided cloning version 6 of David Pellos's design. I ordered from DX the connector you suggested, and have already received it. As it's from NDS Slot 2, GB(C) cartridges do not directly fit (GBA ones fit perfect). I had to cut two tabs on the sides, and now I can insert GB(C) carts without a problem. David Pello's design does not have labels on the schematic bus lines. Fortunately as the design files can be downloaded, I could open it and check line by line the bus connections. Schematic:



Routing this should be dead easy!

If everything else is set, then you should be good to go I hope the battery stuff works out for you

I suggest you up the ante on crystal though. At 6 MHz, the thing is somewhat slow. It defaults to 187.5kBaud and the software itself has a "Send Data -- Wait for ACK -- ..." style protocol, that doesn't translate well to USB. With a 6 MHz crystal, at 187.5 kBaud, 1 MB takes 328 seconds ~= 5½ Minutes. Shorting some pins on PORTE, the baud rate can be doubled to 375kBaud. I personally set my software to 750kBaud and dumping now takes 82s for 1MB. This only worked on my v2.0u, because FTDI chip and ATmega8515 are clocked using the same crystal.

I suggest you use a ATmega8515 without the L (b/c > 8MHz). Put a crystal footprint on there just in case. Connect one of the CBUS lines to the XIN pin. You can leave the crystal unfitted and program the FTDI to output 12 MHz, which would be 1.5Mbaud, so likely -- it should scale linearly, for me it did -- 1MB @ 41s ~= 25kB/s. You should use another CBUS signal as #SLEEP and connect it to #RESET to ensure the device wakes up in a known state after USB suspend. If you don't want to save a crystal, 16MHz would give you 2Mbaud, so likely 1MB @ ~31s ~=33kB/s.

My testing of my FT232BL on my GBCartFlasher 2.0u suggests that the FTDI driver v2.8.30 never goes into USB Selective Suspend ever (VCP or no VCP). The newer driver v2.12.00 does, when VCP (Virtual COM Port) is unchecked, see AN 107. It doesn't when VCP is checked -- tested myself. So it should be safe to do this, because the dumper tool always uses it as a COM port

EDIT: You might also want to connect PE2 (OC1B) to pin 2 (PHI). It might be useful to you in the long run to be able to produce the 1 MHz clock on that pin.
EDIT2: All speeds above are reading speeds. I didn't measure write times.

cYa,

Tauwasser

Last edited by Tauwasser (2015-04-14 19:49:33)

You'll have to make small edits to the firmware anyway in order to benefit from a higher baud rate. So don't short anything on PORTE. Connect PE2 for future benefits, if you like.

I'll upload the firmware to my github one of these days. The original firmware is just a hex file. I converted that back to C and it compiles to exactly the same hex file, so that's 100% compatible. You should be able to use it with a slight modification to adapt the baud rate and adapt the read/write function to account for the F_CPU difference.

cYa,

Tauwasser

Changed (I), (II) and (III):



I'm impressed you saw (II) just by looking to the image!

doragasu wrote:

If I understood correctly, these are the hardware changes to the programmer you are suggesting, right?:

Correct.

doragasu wrote:

Also added a bridge to the #SLEEP (usb suspend) pin, because I don't think shorting it with the #RESET output of the ISP programmer is a good idea! Maybe I could replace this one with a resistor (e.g. a 1K~10K one).

Forgot about the ISP. Yes, a resistor will work, but you have to take Rpu (Rrst) on #RESET into account. You need to be <(30k..60k)/4, i.e. <7.5k, so 1k, 2k, 4k7 would be good options. 10k won't work reliably (won't reset MPU).

doragasu wrote:

I have no ATMega toolchain installed, in the past I have used some of these chips, but my experience with them is just limited to burning a firmware someone did, using avrdude. A quick search on ArchLinux repos shows avr-gcc (and also avr-gdb) is available. Will this be enough to build the firmware?

I use Windows personally, so for me, AVR Studio works just fine. Although I do use the MHV AVR toolchain. I'm pretty sure as long as you are able to compile something with your native toolchain now, arv-gcc and avr-libc should be all you need. I'll see about getting a Makefile ready.

doragasu wrote:

Offtopic: BTW I have coded for PICs, dsPICs, MSP430, C8051 (Cygnal/Silicon Labs variants), some C5000 and C6000 DSPs and ARM Cortex microcontrollers, but never coded anything for AVR chips. My favorite: TI chips (DSPs and MSP430).

The place where I work at uses mainly AVRs, PICs and MSP430. I've never done anything with PICs. Some PICs got shipped to me by mistake, but I don't own a PICkit so I didn't test them yet. MSP430 is very powerful for signal processing, but I've never worked with one more intimately. So, I kind of grew up on AVRs.

cYa,

Tauwasser