Feed on
Posts
Comments

From the last part, we switched to the CH340G USB to serial converter which gave our read speeds a bit of a boost, we looked at reading the GBA ROM, SRAM reading/writing and how to automatically determine ROM/SRAM sizes. In this part, we’ll cover EEPROM read/write, Flash writing and determining EEPROM size and checking if we have SRAM or Flash.

I was previously looking at the ATmega32A which I’ve received and was able to switch to, it has just enough pins, with 2 pins to spare, one will be an LED pin and the other will detect the 5V/3.3V switch so we know whether we’ll be interfacing with the GB or GBA.

On to the EEPROM, I found the GBATek page which gives a explanation on how to address the EEPROM and what to do when reading/writing so it’s a good and simple resource to use though I wanted to see for myself how the GBA interfaced with EEPROM with any timings I need to consider. I broke out the logic analyser on the Fila Decathlon game which uses a 4Kbit EEPROM.

Writing to EEPROM

Thankfully the game allows you to save to the EEPROM after the first event so I was on my way. For a write, we can see that CS goes low, RD goes high, WR is the clock line as we drive the EEPROM serially, AD0 is the data and A23 goes high. If we were to read from the EEPROM, the RD pin would be the clock and the WR pin would be high.

Just to see what an expanded view looks like, the GBA seems to wait 6ms before writing again, around the standard waiting time for an EEPROM write.

Let’s go through how we address and write data to the EEPROM in finer detail by reference of the GBATek information. First we send a write request (10), then the 6 bit address in this example the address is 1 and the first data byte. We continue to send another 7 bytes and end the write request with an end bit as 0 (not shown). The clock frequency is 600ns, not a problem for us.

A 4Kbit EEPROM has 64 addresses (where the 6 bit address comes from) with 64 bit data each and a 64Kbit EEPROM has 1024 addresses (10 bit, although it seems we need to write 14 bits instead) with 64 bit data. After going through a few of these writes with the logic analyser I could see the address bits increment and eventually saw the name I’d chosen in game.

Reading the EEPROM

Now we can look at reading from the EEPROM, we see it’s accessed in two steps (A23 goes high), firstly we send the address we wish to read and then read out the 64 bits.

This time we start of with a read request (11), the address we wish to read (1) and the stop bit which should be 0 but I actually found that sometimes the stop bit was 1, in my example above.

We have to ignore the first 4 bits and then we have the 64 bits of data. We now understand how the EEPROM works, now we have to replicate the reading, writing and addressing in our code.

As both writing and setting the address for a read both use the same start (RD/WR bits, 6 or 14 address bits), I decided to combine these starts into one function. We first check if it’s a 4Kbit or 64Kbit EEPROM and set the appropriate bits, then we loop through those bits keeping in mind the clock frequency of 600ns, 2 nops for the high/low clock does the trick and then we send a stop bit only if we are reading (we assume the next function called will do the rest). We don’t need to worry about setting the A23 line high or low as gba_eeprom_mode function sets all pins high for us and gba_mode will be called later to set them all low (not shown).

If we were reading, here’s how it would all look. After setting the address, we ignore the first 4 bits and then loop the 64 bits, after each 8 bits are read place that byte on the array.

Writing is almost the same except that we just send 64 bits of data and then send the stop bit, I followed the advice and set the stop bit to 0. For the PC interface side, it’s similar to reading/writing to the SRAM methods except that we send the EEPROM size at the start and then send or request 8 bytes at a time. After a few tests, everything is working well.

Determine EEPROM Size

We need a way to find out whether an EEPROM is present on the cartridge and if that EEPROM is 4Kbit or 64Kbit. After some tests, if you try to read out an EEPROM from a cartridge that doesn’t have one, it will return 0x00 or 0xFF, so that’s easy, plus I don’t think there would be any carts that woudl have SRAM with an EEPROM, wouldn’t make much sense but you never know. Also it turns out that if you address a 4Kbit EEPROM as a 64Kbit, it repeats the same 8 bytes (64 bits) over and over again.

So what we’ll do is read the first 8 bytes, store that, then read the rest of the 4Kbit EEPROM size (0x200), check for how many 0x00 or 0xFF we find and also how many repeated bytes we find. If the count of 0x00 / 0xFF is more than 512 then we have no EEPROM, otherwise if the repeated count is more than 300 then we have a 4Kbit EEPROM (sometimes it doesn’t give us a perfect 512 result so I made it a bit lenient).

 

Writing to Flash

Now it’s time for writing to the flash memory. First thing we need to do is pull up the datasheets (LE39FW512) that are still available and firstly check what pins we need to use. It has CE, OE, WE, the data pins and address pins, similar to SRAM except that in this case OE (output enable) is like RD and WE (write enable) is like WR; they are active low as well as CE.

We also need check the sequence we need to perform, as with flash they seem to take extra pre-cautions so there is almost no way you could re-write the flash by mistake. This particular flash chip is written byte by byte (20uS program time), where as some flash like Atmel ones write 128 bytes at a time. Before we can write a byte we have to either perform a sector erase or chip erase, I’ll go for the sector erase which takes 18ms, each sector is 4Kbytes.

Reading the Software ID (chip ID) will also be useful to know which manufacturer it is but more importantly for us to know if it’s an Atmel chip or not. After reading the software ID, you need another sequence to exit that mode. In order to do any writing, we firstly write to the address 0x5555H with the data 0xAA, set WR and CS2 low, wait a tiny bit and then set WR and CS2 high and continue with the next bus write cycles.

We can simply put this into a function and write to the bus all the times required.

To erase a 4K sector, we follow the write cycles, then left shift the sector number by 12 and the data to write is 0x30.

Software ID works similar except that once the entry write cycles are complete, you read from the address 0 and 1 like you would for SRAM and then perform more write cycles to exit Software ID mode.

As mentioned previously, there is one chip that writes different from the others, the Atmel 512Kbit one (AT29LV512). Instead of erasing a sector and writing the bytes, it takes care of it all for us, we send it the sector address and 128 bytes whilst incrementing the byte address. We have 150uS between each byte sent otherwise it will re-program the bytes that it has so far and blank out the rest, that timing won’t be an issue and the write cycle time is 20ms.

Like the others we write the bus cycles and then send out the 128 bytes, I had to increase the buffer on both ATmega and PC interface to 129 bytes to support this.

We just have one thing left to do which is to support 1Mbit Flash, these have 2 banks as we access it via 16 bit address lines, luckily GBATek had the sequence available as I don’t have a 1Mbit Flash cart handy.

On the PC side when we are re-programming the flash, we loop as many banks required (max 2) and we only want to set the bank once we hit the 2nd bank as the non-1Mbit flash chips may not support the bank change command, for non-Atmel chips we check to see if the current address is a modulus of 4096 and if so, erase the current sector before we write to it, then read 64 bytes from the file as usual; for Atmel chips, we just send it 128 bytes at a time.

Checking to see if we have SRAM or Flash when writing

So we have a little bit of a problem, how do we check to see if we have flash or an SRAM, reading them is the same (apart from if you have a 1Mbit Flash with bank swapping), only writing them is different. If you were to request the Flash Software ID on an SRAM, you would actually be writing to the SRAM with those write cycle data bytes, not good!

The solution I came up with is basic but a destructive one if done incorrectly, we read the first byte of the SRAM/Flash, then write to that same byte with a choice of 2 bytes (just in case, the byte read is the same one will are about to write with) but the way which we write is like we are using SRAM. We read the byte back, if it matches our written byte then we have SRAM, otherwise we have flash.

Determining Flash size

In our check SRAM/Flash size, we previously checked for SRAM/Flash up to 512Kbit as both are read the same way but for testing 1Mbit flash we have to switch banks.

So we can just read the first 64 bytes of bank 0, switch to bank 1 and read 64 bytes again and see if they match (This is untested).

Here’s how the schematic looks, we are almost done. I have the ATmega detect what was the last free pole in the switch, we detect o if CH340G is generating it’s own 3.3V (means it’s 5V Vcc). I don’t have any free pins left for LEDs to show if we are on 3.3V or 5V, I think the easiest solution will be to use an inverter hooked up to the same pole, kind of disappointing that I need that!

Now that we have the switch detect, we can combine the GB/GBA functions into one and query the ATmega to know which one we should use. Download GBxCartRead_v0.3

All that’s left to do now is layout the PCB and it should hopefully all be good!

GBxCartRead – Part 1: Design and Testing Gameboy Carts
GBxCartRead – Part 2: Switching to CH340G, GBA ROM reading, SRAM read/write and determining sizes
GBxCartRead – Part 3: GBA EEPROM Read/Write & Flash Write and Determining Sizes
GBxCart RW v1.0 Released

One Response to “GBxCartRead – Part 3: GBA EEPROM Read/Write & Flash Write and Determining Sizes”

  1. Flavio says:

    Alex,

    Thank you so much for using your time to publish this. Very interesting investigation. I will be looking forward to the availability of the PCB layout.
    Keep the good work!

Leave a Reply