Gameboy Development Forum

WeaselBomb wrote:

I'm not sure why the copper pour doesn't connect to that pin automatically.

There is a minimum width setting that likely prevents it.

WeaselBomb wrote:

Is the ground plane even necessary as long as the crystal is properly isolated?

It helps, because it provides a defined reference voltage around the crystal and is supposed to shield it from noise. There are also minimal leakage currents along the surface of a PCB, which the ground will "catch".
More optimal would be if this ground were separate from the overall ground and only connected in one point to the ground of the MachXO, which in turn would only be connected in one point to the cartridge ground and so on.

WeaselBomb wrote:

So I should be trying to get a layout like this? I hadn't considered running the guard ring between 2 of the RTC pins. Thanks for that link, this is a gold mine of information. My last flashcart was off by about 15 minutes after a year of runtime, so it would be nice to get a handle on this topic.

A guard ring will likely not fit between the pins. I think their pitch is 0.5mm and your minimal trace width is currently 0.2mm and could go down to ~0.15mm when using cheap PCB processes, so your options are limited there.
Instead of using a guard ring, I would connect the grounds in one point to keep high-frequency noise close to the respective IC. It's never going to be optimal, nevertheless that step alone will improve the design. It's kind of a compromise between star routing and multi-point connections.

It's somewhat unfortunate how cut up the lower part of the back of the PCB is, because all the return currents will have to go around the cut or jump through multiple vias.
You should also replicate the little VBAT rectangle on the top directly like that on the bottom or the second via becomes kind of useless (as all the current has to go across the annular ring of the first via).

Last edited by Tauwasser (2020-01-03 16:14:07)

Hi WeaselBomb,

I took your Dip file and made some crude changes to illustrate what I meant by the 3V3 and 5V0 cutting through the board. Basically, I moved both of them to the top layer, since the ground plane is broken there already and there isn't really any need to have these traces on the bottom to begin with. You should add more vias to the ground plane in some places, but I use the freeware version of DipTrace and it complains that there are already 300 pins

You can probably do better, especially since I had trouble adjusting the trace widths for the individual segments. I tried to different styles of arcs around the center hole, but placing them at the exact radius by hand would have taken more time Obviously, if you can make them go around nice and easy with the same radius from the hole that'd look better and avoid the angles.

Last edited by Tauwasser (2020-01-03 22:17:46)

It's looking good You might want to move the power traces closer together and add more vias to the middle gnd polygon as that's your main ground for decoupling the 5V0 side of the level shifters.

I prototyped the edit for X1 I suggested using keepout lines. I'm not 100% happy as tweaking the polygons using the keepout lines was somewhat tedious.



The idea is that the polygons on the front and back surround the X1 pads and the point of connection is on the GND pin on the top. The polygon on the bottom could probably go a bit lower.
Since the GND island south of the GND pin is the main GND connection, I added two move vias there just to be safe.

Oh yeah, I set the main GND poly to 0.3mm line width and line spacing down from 0.635mm. That really helped with getting the poly to connect on the sides.

Last edited by Tauwasser (2020-01-04 13:02:58)

WeaselBomb wrote:

I adjusted the power rails and added some vias, so I think it's well-grounded now?

Yeah, it's better now. Did you make the new vias square or is that just an artifact?

WeaselBomb wrote:

If we need more room on the left side, I'm thinking the FPGA could maybe be shifted slightly to the right to free up some space?

Yeah, I thought about that as well, but I did not want to unnecessarily create additional work. If push came to shove, that would have been an option.

WeaselBomb wrote:

Is the copper pour for vBatt necessary? The datasheet says it will only draw 1 micro-amp at most from the battery, which sounds like it only needs a small trace. I added the copper pour without much reasoning aside from the fact that it's a power rail.

No, it's more of an more area = less resistance thing, I suppose. But for your purposes it really comes down to a style choice.

Ok, boards are in and soldered! A little plastic tab on the cartridge shell is colliding with the right-most capacitor, so I've adjusted the PCB file to compensate.

The next disaster is that my combination of hardware/software doesn't seem to support the flash chip I chose (S29GL064S70TFI040). It's one of those 16-bit parts that can be run in 8-bit mode

For software, I am using your gbcflsh program. For hardware, I am using the J. Rodrigo cart flasher. I also have BennVenn's flasher, but so far, none of these have been able to read/write the flash chip correctly.

I finally noticed that there is a fork of that GBCartFlasher repo that claims to support mx29lv parts, which appears to have identical pinouts to my own chip. I guess if I can compile that and program the Atmega 8515 on my flasher, then it might work? The README says that it only works with 12 MHz crystals, but that shouldn't be too hard to change back to 6 MHz, right? Worst case, maybe I could desolder the old crystal and drop a 12 Mhz on there.

Unless there is another branch I should be looking at? Right now I'm leaning towards editing the fork that supports mx29lv, but I'm very open to suggestions.

Unfortunately, J. Rodrigo didn't include pins to program the Atmega. Guess I will have to solder some in.
Also, I have 3 programmers (Microchip, Lattice, and Xilinx) that I have used to program CPLDs/FPGAs, but I don't think any of them are compatible with the Atmega. Guess it's time to cave and get an AVRISP.

Last edited by WeaselBomb (2020-02-13 19:02:23)

Programmer just arrived this morning. I was impatient, so I got an Atmel-ICE from Amazon.

Tauwasser wrote:

Don't switch crystals just yet. Depending on the Atmega8515 part (ATmega8515L or ATmega8515) it might not be compatible with a 12 MHz crystal.
Wenting only changed the baud rate prescaler registers, see commit f560c36. Just change them back.

Thank you, that would have taken me forever to find. I've set them back to their previous values.

Tauwasser wrote:

Pretty much, yes. One needs to shift the patterns by 1 bit to the left and extend it (so copy bit 1 over to bit -1 if you will). From a casual look at commit 4357c3f, the mx29lv branch seems like an exact fit. Too bad Wenting didn't shift the patterns for ALG16 as well

Ok, I see where he shifted the patterns in BYTE_PROGRAM, CHIP_ERASE, PRODUCT_ID_ENTRY, PRODUCT_ID_EXIT.
So, I also need to shift the ALG16 patterns? So, for example, shifting the CHIP_ERASE array would result in:

old: 0x55, 0x55, 0xaa, 0x2a, 0xaa, 0x55, 0x55, 0x55, 0x80, 0x55, 0x55, 0xaa, 0x2a, 0xaa, 0x55, 0x55, 0x55, 0x10,
new: 0xaa, 0xaa, 0xaa, 0x54, 0x54, 0x55, 0xaa, 0xaa, 0x80, 0xaa, 0xaa, 0xaa, 0x54, 0x54, 0x55, 0xaa, 0xaa, 0x10,

For whatever reason, I still can't seem to read my S29GL064. I'll spend some time checking the wiring on my breadboard, I'm a bit stumped at the moment. Right now, I'm just trying to read/write Tetris, so I can exclude the FPGA for now.

I have the #BYTE pin connected to ground, which should leave the device locked to 8-bit mode.
To ensure I'm not crazy, the address bus should be connected to the flash like:
Cart A0 => Flash A-1
Cart A1 => Flash A0
...
Cart A14 => Flash A13
Cart A15 => Flash #CE

Last edited by WeaselBomb (2020-02-15 15:08:04)

Tauwasser wrote:

Do you read anything off the flash chip and it's just not the data you expect (manufacturer etc.) or do you only read 0xFF?

Manufacturer ID and Device ID are both returned as 0x90.
It appears to be reading something, just the wrong data is returned. To test DIR polarity, I switched DIR from using /WR to /RD and caused it to read 0xFF, so I changed it back to /WR.

Tauwasser wrote:

only the #WR method always uses ALG12

For now, I've re-wired the breadboard to use /WR instead of AIN, to guarantee ALG12.

I've grounded /OE for the data bus, so it should always be outputting. I didn't think that would cause any problems here, but I could be wrong.
ROM address lines 15-22 are also grounded.

I was playing around with some of the values in those arrays, I hope I didn't accidentally activate some protection on the chip.

EDIT:
Wait a minute, 0x90 is the last byte of the Auto-Select sequence. Something's fishy here...but I don't know what.
Popped in a fresh chip, getting the same 0x90...it's gotta be some small issue I'm having with the firmware I think.

Last edited by WeaselBomb (2020-02-16 13:12:05)

I had originally grounded the /OE on 74ALVC164245. Now, I'm driving it from the FPGA again, using the equation:

OE <= '0' when (RD = '0' or WR = '0') else '1';

I've actually stripped the circuit down to the bare minimum for debugging, so there's no RAM. The only things connected to the FPGA are RD, WR, and OE (for the 74ALVC). Pins A14:A21 on the flash are grounded, leaving me with A-1:A13. I have swapped AIN for /WR, to force ALG12.

At this point, I can't even erase the flash. The memory changes, but it definitely isn't erased.

I can't find any fault in the firmware, so I guess I've done something stupid here that I'm not seeing. I assume I'm supposed to use Wenting's firmware code as it is, so all I did was revert the pre-scaler registers to work at 6 MHz again. This alone did not seem to work.

Looking at the auto-select sequence in the datasheet, it looks like Wenting has listed the correct addresses (and data values) for x8 mode CHIP_ERASE:

/** ALG12 */
0x0a, 0xaa, 0xaa, 0x05, 0x55, 0x55, 0x0a, 0xaa, 0x80, 0x0a, 0xaa, 0xaa, 0x05, 0x55, 0x55, 0x0a, 0xaa, 0x10

So, I tried left-shifting those address bytes:

0x15, 0x54, 0xaa, 0x0a, 0xaa, 0x55, 0x15, 0x54, 0x80, 0x15, 0x54, 0xaa, 0x0a, 0xaa, 0x55, 0x15, 0x54, 0x10

Next, I tried OR-ing the low address bytes with 0x01:

0x15, 0x55, 0xaa, 0x0a, 0xab, 0x55, 0x15, 0x55, 0x80, 0x15, 0x55, 0xaa, 0x0a, 0xab, 0x55, 0x15, 0x55, 0x10

But, neither of these changes allowed me to erase the flash.
Is it maybe because I'm passing RESET through the voltage translator? I wouldn't think so, the delay is only a few ns.
Is it because the CLKSEL fuses are set incorrectly on the AVR? Right now the fuses are 0xC1 (High), 0x1F (Low), but I think that's correct.

Sorry if I am asking too many stupid questions. Honestly, sometimes I feel like I'm just wasting your time.

Last edited by WeaselBomb (2020-02-16 22:51:02)

Tauwasser wrote:

Just to make sure: we are talking about the signal that goes to U3 pin 25, right? 2OE in the ‎74ALVC164245 datasheet.

Yep, that's the one

No oscilloscope here, maybe I can borrow one from work later. In the meantime, I've tried a few different patterns on the address and data buses (0xFF, 0xAA, 0x55) and every pin has driven as expected, which makes this even more bizarre. I'm getting my 3v3 power from an Arduino Uno, which I thought might be too weak, but it's rated for up to 150 mA, and I should never be drawing over 100. I've verified all parts are receiving proper voltage, and I can't imagine it would dip below threshold during reads/writes?

Tauwasser wrote:

I take it you bought these flash chips from a reputable source that would not sell you fakes or locked chips, right?

Yeah, all parts used here are sourced from DigiKey.

Tauwasser wrote:

Also, you did solder it on correctly, right?

I've actually got two chips that I've tried, one came pre-assembled on a breakout board from Proto-Advantage, and the other I have placed in a 48-TSOP socket. I tested the corner pin (pin 1) to make sure it was inserted correctly, and it checks out.

I'm so confused, especially since the voltage translators are driving pins correctly. I'm afraid it's going to be a timing issue. I'm still working on it to see what else I can find. At least I'm learning some good C code!

EDIT:
Well, pin 25 on my socket has no connectivity. I took it out of the breadboard and tried for 10 minutes to get a reading on my multimeter, it seems completely disconnected. Time to find my other chip.

Switching to the other flash chip (the one soldered to a breakout board) seemed to work. I can definitely read the manufacturer and device IDs! Erasing also seems to work just fine.
Reading and writing Tetris doesn't completely work yet, though. When I read the data back, most of it matches, but not all.

To enter the auto-select sequence, it has to drive patterns 0x0AAA, 0x0555 on the address bus, and 0xAA, 0x55 on the data bus. To me, that should indicate pins A15 + A11:A0 are driving correctly, and all of the data pins are too? It makes me suspicious of A14:A12...

It sucks that something still doesn't work, but it's good to be back on track.

Last edited by WeaselBomb (2020-02-19 14:59:10)

Ok, so it can read/write Tetris perfectly now, after I added decoupling caps to the voltage translator. I had some spare caps laying around, so I tried some electrolytic 0.47uF caps, which seemed to make it much worse. Then I found some ceramic 22 pF caps, which work perfectly. I have a feeling the material mattered more than the capacitance difference, but that's really just a guess.

I didn't think a lack of decoupling would affect those that badly, but when I take the caps away, it starts missing a few bytes here and there.

I couldn't find a single thing about what size decoupling capacitors to use in the datasheet, unless I'm missing something? I was planning on just defaulting to my usual ceramic 0.1 uF caps, but I would like to be sure they'll work. Might have to do some more research I suppose. I wonder if my current decoupling on the PCB is enough? I kinda just guessed based on what these people did (first, second). It looked like using 1-2 caps per translator would suffice.

Last edited by WeaselBomb (2020-02-20 00:06:31)

gekkio wrote:

What are the equations for the data bus transceiver DIR and OE right now?

Right now I have DIR = WR, OE = !RD or !WR

It has been reading/writing Tetris consistently since decoupling caps were added. Before it worked about 5% of the time, now it hasn't failed 12 times in a row.
When I put it in my Gameboy, it acts like there isn't enough power? The screen dims sometimes, the speaker is noisy, and it resets or goes to a black screen after the Nintendo logo. I'm powering the Gameboy from the DC jack, so it isn't low batteries causing it. The only things the Gameboy is powering right now are the voltage translators, everything else is powered by a dedicated 3v3 power supply.

EDIT:
Now I can't seem to erase or reprogram the flash. The manufacturer ID and Device ID are returning 0xC3 and 0x02, which are bytes 0x00 and 0x02 in the Tetris hexcode. I can still read the flash perfectly, but now I'm afraid I may have locked the chip somehow. It just seems very strange that it can use every address and data line to read Tetris, but it can't seem to read the IDs...and since the socket is no good, I can't pop in a new chip and test it out. Maybe I activated some kind of sector protection?

Last edited by WeaselBomb (2020-02-21 11:07:02)

gekkio wrote:

Right now you're causing problems with the work ram which you're sharing the bus with.

Actually there's no RAM in this circuit, just flash. No MBC, either. The FPGA is only in place to drive /OE on the voltage translator. I'm really just trying to prove this circuit works before adding the other components, so reading/writing/booting a 32 KB game seemed like a good first test.

gekkio wrote:

Next, how are you deriving chip select for the flash and ram? What are the equations?

flash chip select is A15

Now I can't seem to erase the chip at all. Manufacturer ID and Device ID are showing as 0xC3 and 0x02, and looking at the Tetris code, those are the values at addresses 0x00 and 0x02, which is where those IDs are supposed to be read from...I'm wondering if I've done something very wrong here. It's almost like it can't enter AutoSelect mode any more.