Gameboy Development Forum

Discussion about software development for the old-school Gameboys, ranging from the "Gray brick" to Gameboy Color
(Launched in 2008)

You are not logged in.

Ads

#1 2015-02-17 03:50:30

doragasu
Member
Registered: 2015-02-17
Posts: 56

Yet another MBC5 clone project

I want to develop an MBC5 clone using a small CPLD (a Xilinx XC9536XL). I know this is nothing new, and I saw a pair of projects in this forum doing exactly (or almost exactly) the same. I even found the VHDL code of one of them, but, call me stupid if you will, I want to make my own (one motivation is to learn VHDL, and I think this project is simple enough to be interesting for a VHDL noob).

I have been reading about Gameboy Memory Controllers here and there, and some questions are arising. First of all, what is the exact behaviour of the CS line (cartridge port pin 5)? I have seen here some bus captures made using a logic analyzer, but unfortunately not all the address and data lines are shown. Watching the CS line in these captures doesn't make sense to me. It is active for writes, and for some reads but not for others. Here it is stated that CS line is active for data access (e.g. LD instruction) but not for code fetches. This could be coherent with the captures above, but if this is the case, what is this CS line useful for? Maybe to separate code from data memory (having e.g. overlapping addresses, one used for code and other for data)? Should my MBC5 implementation ignore it?

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?

Last edited by doragasu (2015-02-17 03:52:34)

Offline

 

#2 2015-02-17 06:11:54

nitro2k01
Administrator
Registered: 2008-02-22
Posts: 230

Re: Yet another MBC5 clone project

/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.


Blog: Gameboy Genius
"A journey of a thousand miles begins with one small step"
Old Chinese Proverb

Offline

 

#3 2015-02-17 11:28:44

doragasu
Member
Registered: 2015-02-17
Posts: 56

Re: Yet another MBC5 clone project

Thanks for your help.

Are you sure CS is only active (low) for the 8000~FFFF address range, and that it is also active for instruction fetches? It contradicts what is stated in the two links I referenced in my previous post. Also if CS goes low only for the 8000~FFFF range, it should mimic the behaviour of A15 line... why would the cartridge port have two identical (or almost identical) lines?

Offline

 

#4 2015-02-17 22:56:53

Tauwasser
Member
Registered: 2010-10-23
Posts: 160

Re: Yet another MBC5 clone project

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)

Offline

 

#5 2015-02-18 07:18:45

doragasu
Member
Registered: 2015-02-17
Posts: 56

Re: Yet another MBC5 clone project

THANKS a lot Tauwasser: finally a clear and detailed explanation!

So, if I understood correctly, you suggest I use a 4 MHz or faster clock signal to sample all input lines. Could a simple 4MHz oscillator do the work, or should I better use a PLL (such as CY2305) driven by the clock signal available on pin 2 of the cartridge port (to avoid metastability)?

Also reading in detail your explanation, I suppose (I'm pretty new to programmable logic, so I'll be wrong for sure) what you wrote is the case for FPGAs (that are usually SRAM based), but I'm not sure that is the same for CPLDs. When working with CPLDs, IIRC you do not use LUTs, but actual gates, and you are not forced to use flip flops (in fact, synth/mapping tools state my current --latch based-- design uses no flip-flops). So even though I presume implementing a latch maybe uses a stupid amount of resources (maybe two macrocells to implement a two-nor like structure with cross-feedback loop), I'm not sure the setup/hold timing problems might appear here...

Last edited by doragasu (2015-02-18 07:29:51)

Offline

 

#6 2015-02-18 10:42:17

doragasu
Member
Registered: 2015-02-17
Posts: 56

Re: Yet another MBC5 clone project

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 sad.

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.

Offline

 

#7 2015-02-19 03:24:23

doragasu
Member
Registered: 2015-02-17
Posts: 56

Re: Yet another MBC5 clone project

Another update: I asked at Xilinx forums, and it looks like there are some FPGAs and CPLDs that allow the flip/flops to be configured as transparent latches, so they should have no problem with my current latch-based design, and should not require oversampling the bus. That's great news for me! XC9500XL devices doesn't have this feature, so I'll switch to an XC2C32A CPLD.

Now the only thing I need to clarify is the CS line behaviour. It is critical to know how it behaves, since I will be using level shifters, and I wanted to control the data bus DIR and OE lines using RD and CS signals. If CS is active for each cartridge access, there should be no problem, but if as stated in the links above, CE is not active for instruction fetches, I will have to control DIR/OE lines of the level shifters using other approach (based on the addresses, to set the appropiate direction when reading from 0000~7FFF or A000~BFFF).

Last edited by doragasu (2015-02-19 04:04:50)

Offline

 

#8 2015-02-20 21:39:49

Tauwasser
Member
Registered: 2010-10-23
Posts: 160

Re: Yet another MBC5 clone project

Hi,

I see you have given this some more though big_smile 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 wink. 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

Code:

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 tongue

cYa,

Tauwasser

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

Offline

 

#9 2015-02-21 15:45:34

doragasu
Member
Registered: 2015-02-17
Posts: 56

Re: Yet another MBC5 clone project

Again, thanks a lot for the detailed response! Now even including truth tables! smile

I can't see the benefits of converting my current design to synchronous. It would be more complex and I suppose it would drain more power. Anyway, in the schematic I'm currently drawing, I have placed a monolithic oscillator attached to GTS2 just in case I finally need to go synchronous (or just want to try).

I'm also drawing some SMT jumpers, to be able to control OE in the data level shifters either using CS cart signal or a CPLD signal. I'd like to generate as few signals as possible, just to keep it simple. If possible, 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).

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.

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.

Last edited by doragasu (2015-02-21 16:42:26)

Offline

 

#10 2015-02-22 01:59:23

Tauwasser
Member
Registered: 2010-10-23
Posts: 160

Re: Yet another MBC5 clone project

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

Offline

 

#11 2015-02-22 06:18:40

doragasu
Member
Registered: 2015-02-17
Posts: 56

Re: Yet another MBC5 clone project

Tauwasser wrote:

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

In  fact, I'm out of pins... The CPLD I'm using right now has 33 GPIO pins, and I'm monitoring:
- 4 cart addresses
- 8 cart data
- Cart #Reset, #CS, #WR, CLK
- Oscillator CLK

That's 17 lines. I'm also generating the following signals:
- 9 ROM addresses
- 4 SRAM addresses
- RAM #CS
- Flash #WR
- Level shifters #OE

That's 33 lines total... no more room to connect the usual LEDs for special effects wink (unless I share the lines I hope I don't have to use (the two clock lines, basically).

Tauwasser wrote:

You should be fine using a power monitor or power good signal from your LDO

Unfortunately, the LDO I was planning to use (TC1185-1.8/3.3) doesn't have power good outputs. Time to search for another one.

Tauwasser wrote:

You probably mean GCK2?

Yes, my mistake. I choose GCK2, because it's the only global clock input that can use the CoolClock feature.

Tauwasser wrote:

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.

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 wink

Last edited by doragasu (2015-02-22 06:31:01)

Offline

 

#12 2015-02-22 17:24:16

Tauwasser
Member
Registered: 2010-10-23
Posts: 160

Re: Yet another MBC5 clone project

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 wink

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)

Offline

 

#13 2015-02-23 04:12:08

doragasu
Member
Registered: 2015-02-17
Posts: 56

Re: Yet another MBC5 clone project

The idea of sharing the 4 pins used to address SRAM bank with ROM bank lines is great!, I just copied MBC5 pinout and didn't bother about thinking if I could optimize the design.

About flashing the thing, I was planning that once you enter "Flash mode", all MBC functionality is disabled until reset, excepting ROM bank select. Also in "Flash mode" ROM bank select register is moved above 7FFF. But I had not time to code this yet. Maybe I should follow your suggestion and use cart pin 31 to make things simple (and save another CPLD GPIO).

Edit: About the battery issue, I was planning to use two diodes (and two capacitors) to automatically switch SRAM power line to "the power source with higher voltage". Also as the SRAM chip has two chip enable signals (#CE1 and CE2, both must be active for the chip to be selected), I was connecting CE2 to the 3.3 V power, for the SRAM to be deselected (and go low power) when power is removed.

Last edited by doragasu (2015-02-23 04:19:31)

Offline

 

#14 2015-02-23 19:06:04

Tauwasser
Member
Registered: 2010-10-23
Posts: 160

Re: Yet another MBC5 clone project

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 wink

cYa,

Tauwasser

Offline

 

#15 2015-02-24 03:23:36

doragasu
Member
Registered: 2015-02-17
Posts: 56

Re: Yet another MBC5 clone project

Tauwasser wrote:

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...

I'll use schottky diodes, namely a RB715Z (two schottky diodes with common cathode in a SOT23 package). I will have to re-read my notes about diodes, because I cannot remember about the inrush current problem you mention.

Tauwasser wrote:

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 wink

Again, nice suggestion, but I'm sorry, I'll use a separate connector. Again, to keep things simple. 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).

Last edited by doragasu (2015-02-24 03:24:05)

Offline

 

#16 2015-02-24 17:22:43

Tauwasser
Member
Registered: 2010-10-23
Posts: 160

Re: Yet another MBC5 clone project

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

Offline

 

#17 2015-02-25 16:15:26

doragasu
Member
Registered: 2015-02-17
Posts: 56

Re: Yet another MBC5 clone project

I don't think inrush current has that great effect in this case. SRAM decoupling capacitors are charged (ideally) only once: when you insert/solder the battery. Then they remain charged independently of the main power status. Also, when the gameboy is powered off, SRAM should be sleeping (draining just some microamperes, unless the user is stupid enough to power off while loading or saving a game), so I don't think the decoupling capacitors have trouble keeping the voltage while the diodes are switching.

I wonder if the problem with the cartridge you mentioned eating batteries like candies, might be because of other kind of design flaw (e.g. using only one diode instead of two. If you do this, the battery would power not only the SRAM, also the ROM and anything else on the cart).

I readed the CPLD datasheet and the CoolRunner2 family datasheet, and it's not clear, but it looks like VCCAUX power must be always present. Page 12 of the family datasheet states:

All CoolRunner-II CPLD parts are 1.8V in system program-
mable. This means they derive their programming voltage
and currents from the 1.8V VCC (internal supply voltage)
pins on the part. The VCCIO pins do not participate in this
operation, as they might assume another voltage ranging as
high as 3.3V down to 1.5V (however, all VCCIO, VCCINT,
VCCAUX, and GND pins must be connected for the device to
be programmed, and operate correctly
).

Last edited by doragasu (2015-02-25 16:18:59)

Offline

 

#18 2015-03-09 04:05:54

doragasu
Member
Registered: 2015-02-17
Posts: 56

Re: Yet another MBC5 clone project

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

https://i.imgur.com/rvDr5Uh.png

Offline

 

#19 2015-03-09 08:03:20

doragasu
Member
Registered: 2015-02-17
Posts: 56

Re: Yet another MBC5 clone project

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?

It could be great, because it would save me the precious time needed to write the software for the PC and the microcontroller firmware.

Offline

 

#20 2015-03-10 20:53:09

Tauwasser
Member
Registered: 2010-10-23
Posts: 160

Re: Yet another MBC5 clone project

https://i1290.photobucket.com/albums/b527/tauwasser/rvDr5Uh_zpsveuoqwb0.png

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 tongue
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)

Offline

 

#21 2015-03-11 04:34:20

doragasu
Member
Registered: 2015-02-17
Posts: 56

Re: Yet another MBC5 clone project

As always, great tips. I agree on almost all of them. Some comments and questions:

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).
II: If with the "switchover stuff" you mean the parts used for switching between GB power and battery, D2 is not part of it. D2 is an RGB LED, and I want it as close to the border as possible. Sorry for not posting the schematic...
III: Battery current should be low enough to not need them, but there is plenty space, so I might add the vias anyway.
IV: Do you know exactly where should I put this hole? I hope it is small, that zone is a bit crowded.
VI: I just used existing footprints from KiCad. I might add additional silkscreen to make it clear.
VII: D1 is SOT23, so it doesn't really need a polarity indicator, but you are right with D2.

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.

About the JTAG port, it is something that also troubles me. Moving it up would allow inserting the cart, but would not allow closing the case. 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.

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 sad.

Once more, thanks a lot! This design would have been very different (and worse) without your tips!

PS: I'm extremely busy lately, maybe I'll not have time to spend on this until the middle of the next week.

Last edited by doragasu (2015-03-11 04:58:36)

Offline

 

#22 2015-03-14 09:19:57

Tauwasser
Member
Registered: 2010-10-23
Posts: 160

Re: Yet another MBC5 clone project

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.

https://i1290.photobucket.com/albums/b527/tauwasser/DMGTemplate_zps7bhdqrxy.png

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 sad.

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

Offline

 

#23 2015-03-14 11:33:24

doragasu
Member
Registered: 2015-02-17
Posts: 56

Re: Yet another MBC5 clone project

Yet again, Tauwasser to the rescue!

Thanks for the detailed cart measurements, for the cart connector link, and for the tips! You have saved a Gameboy's Life!!!

Offline

 

#24 2015-03-15 08:50:33

doragasu
Member
Registered: 2015-02-17
Posts: 56

Re: Yet another MBC5 clone project

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

https://i.imgur.com/v0gXlpl.png

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

Offline

 

#25 2015-03-18 10:09:25

doragasu
Member
Registered: 2015-02-17
Posts: 56

Re: Yet another MBC5 clone project

Another iteration: added resistor/solder bridge to the battery, moved a bit U4 and re-routed around the second mounting hole.

https://i.imgur.com/2yRomeA.png

I think the only change still pending before I can call this Rev.A, and jump to the programmer, is moving (and maybe changing) J2 (CPDL JTAG).

Offline

 

Board footer

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson