Help Understanding RTC

[YoshiMoshi]

So I noticed that games with RTC (such as Pokemon), the RTC IC (S3511 - 8pin RTC with 3-wire serial bus) is connected to the GPIO pins of the ROM chip.

Does anyone know, are the GPIO pins set as input only? Meaning it can only read the data on the RTC IC? Is it able to write to it?

As far as I know, for pokemon it detects how much time has passed by comparing the data stored in the S3511 chip with the the data stored on the FRAM for the game save. It then compares the two to see how much time has passed.

I believe there are homebrew programs that changes the date. But as far as I know that's within the game save only and not on the S3511 chip?

What exactly is the chip that stores the ROM? I thought it was just flash memory. But it appears to be flash memory device that is capable of three wire SPI to write a portion of memory to the flash to read RTC, and also has a parallel interface to read the data stored on it. Is there a similar device that is commercially available?

 

[FAST6191]

I doubt you will get much in the way of hard answers -- most emulators have done it years ago, most hackers don't touch it (outside of megaman 4.5, possibly Solar Boy Django and maybe a handful of pokemon types there are very few that have had to touch it, and I have never seen a writeup), most flash cart devs will consider it proprietary (though I guess you could look at EZFlash's github https://github.com/ez-flash . There have been some problems with various ROM hacks and EZFlash gear so might be some threads there), I have never heard of one failing before other than batteries and year related stuff (which was possibly flash cart related), no homebrew flash cart or similar really ever needed to handle it/was built to handle it (granted save support is beyond most homebrew flash cart designs) and that is pretty much it.

To that end if it is not on/derivable from
http://problemkaputt.de/gbatek.htm#gbacartrealtimeclockrtc (though I do note it says the DS stuff is very similar so might find something there) and https://web.archive.org/web/20160121120549/http://reinerziegler.de/GBA/gba.htm you are going to be on your own most likely.

 

[YoshiMoshi]

I doubt you will get much in the way of hard answers -- most emulators have done it years ago, most hackers don't touch it (outside of megaman 4.5, possibly Solar Boy Django and maybe a handful of pokemon types there are very few that have had to touch it, and I have never seen a writeup), most flash cart devs will consider it proprietary (though I guess you could look at EZFlash's github https://github.com/ez-flash . There have been some problems with various ROM hacks and EZFlash gear so might be some threads there), I have never heard of one failing before other than batteries and year related stuff (which was possibly flash cart related), no homebrew flash cart or similar really ever needed to handle it/was built to handle it (granted save support is beyond most homebrew flash cart designs) and that is pretty much it.

To that end if it is not on/derivable from
http://problemkaputt.de/gbatek.htm#gbacartrealtimeclockrtc (though I do note it says the DS stuff is very similar so might find something there) and https://web.archive.org/web/20160121120549/http://reinerziegler.de/GBA/gba.htm you are going to be on your own most likely.

Hey thanks. I've read those sites, they are very helpful.

I'm just trying to understand conceptually what is going on. It's clear to me that the chip that holds the ROM contains a section that is truly ROM, and a SPI interface, and perhaps some RAM. It would seem that data from the SPI can be stored in RAM within the chip.

Basically I've never heard of a ROM chip that you can generate it's own 3 wire SPI signals??

Sounds to me like this ROM chip is more of like a microcontroller?

I don't know, I'm just saying it doesn't make sense to me that this thing is a ROM chip that comes with the game only on it. That the player can't write data to. That's clearly not the case with the RTC 3 wire SPI signals going to it only. So it's just very confusing. Who knows, it's all speculation. It just amazes me that 20 years later some of this is still unknown.

I also find it interesting, you can write data to the ROM chip of commercial cartridges via the SPI interface (at least a very small portion of the ROM chip)! Seems like a potential area for a exploit, but without the datasheet, who knows.

Do you know if the datasheet has leaked for the ROM chip? I can't find it.

 

[FAST6191]

Unless it was in the gigaleak most people were more concerned with finding protocol compatible things (gbatek again has some things http://www.brolinembedded.se/projects/flashcart/ and that reinerziegler.de/GBA/gba.htm site), and I doubt the initial SDK leaks would have had any RTC stuff.

I have never bothered to properly investigate the RTC using game carts at PCB level really -- most things anybody cares about is replacing the battery powering it and hacking the ROMs that use it to not use it or work better with a flash cart, maybe a hack to adjust time within game (or open up the existing time set for any time they like). As 99% of RTC complaints are pokemon related and most people that spend any time on hacking/flash cart help/emulation help sections come to detest pokemon (myself not being immune, though aided by the games being unchanging for decades) then... yeah.

Most normal game carts are a chip for the ROM and a SRAM/FeRAM, EEPROM or flash chip for saves depending upon what the game uses (if it uses one at all). Some of the more recent repro/fake games then soldering a little adapter board on top, and some of those also doing odd things with ROM and save handling (almost incorporating the save into the ROM space but different matter there).
I was generally under the impression that the save stuff used a common chip to chip protocol (presumably SPI) to speak to other things. On the DS for the pokewalker games then the SPI was used again to select either the IR communications or save chip that 99% of everything else used, making dumping saves a bit tricky until that was cracked or you did a manual bypass/select so I guessed something similar would happen for the GBA for anything in the annoying extras world ( https://gbatemp.net/threads/buying-a-gba-flash-cart-in-2013.341203/page-18#post-4756995 , though I think the https://mgba.io/2015/10/20/dumping-the-undumped/ did another twist).

As far as exploits then the GBA has long been a solved problem. I guess you could launch something from the save or some other few bytes of accessible memory, or maybe use it for one of those fun "let's program a demo inside another game" things people have taken to doing this last few years.

 

[arrrk]

My understanding, which definitely could be wrong, is there is is an address space reserved in the ROM for GPIO (80000C4h), so if that address is accessed, the ROM data pins are set to zero and some (4 to be exact) GBA cart data pins can pass through to a GPIO device (RTC, solar sensor, rumble, etc.). I imagine this also somehow raises the chip select pin on those IO devices, and the select is disabled otherwise, which would stop the other data from messing with it. I think a big piece to the puzzle would be finding out exactly where the RTC chip select pin is tied to on the cart, so if you found that out you could probably piece together the rest.

This is just what I gathered from reading the chip datasheet and GBATEK, you can take a look and see for yourself (I would post the links but I have not reached sufficient status here lol)

A google of "s3511 rtc datasheet" should get you the first document, and the section "GBA Cart I/O Port (GPIO)" in GBATEK will get you to the other information.

 

[YoshiMoshi]

So let me see if I got this correct.

Address locations below are for the ROM chip, and not the whole entire memory map of the GBA

Address C8 is typically filled with all zeros.
Address C4 and C6 are normally read from the ROM chip.

If I attempt to write to the ROM chip a value of 0000000000000111 to address C8
C6 and C4 are no longer read from the ROM chip

Address C6 is the data direction register (DDR) I write what I want in last four bits to set the direction of the GPIO pins?

Address C4 is the data of those GPIO pins?

if(C8 = 0000000000000000){
Read data from C4 and C6 from ROM chip
}
if(C8 = 0000000000000111){
Read data from C4 based on the value stored in C6
}

 

[Deleted member 579049]

I believe there are homebrew programs that changes the date. But as far as I know that's within the game save only and not on the S3511 chip?

rtcread reads/writes to the actual rtc of the cartridge, if that's what you're thinking about? irrespective of which cart is inserted, if there is rtc on the cart it will read/write to it.

It works to adjust the rtc date/time on everdrive, too.

 

[Coto]

GPIO = General Purpose IO, which should tell itself what it does. Basically a programmable IO port that glues to different components and rely on CS signals, to read RTC, or Flash. So yeah, they share the same wire.

Do note GPIO, albeit simpler, would be an inhouse version of a SPI or even I2C bus implementation, whose implementations are meant to connect peripherals as well, but the busses implement standards to read/write to master and slave units and handle them independently.

in GBA, the Flash + RTC GPIO register is meant to expose the same GBA IO port to different circuitry mapped on the cartdrige.

 

[YoshiMoshi]

Right I understand. You have to bit bang three wire SPI over the three GPIO pins.
I'm just trying to understand if I have the right interface to the ROM chip?
If I want to read GPIO Pin 0

I do this
C8 = 0000000000000001 //set Pin 0 to R/W
C6 = 0000000000000001 // Set Pin 0 to Read
I then read the data at C4?

 

[Coto]

Right I understand. You have to bit bang three wire SPI over the three GPIO pins.
I'm just trying to understand if I have the right interface to the ROM chip?
If I want to read GPIO Pin 0

I do this
C8 = 0000000000000001 //set Pin 0 to R/W
C6 = 0000000000000001 // Set Pin 0 to Read
I then read the data at C4?

https://problemkaputt.de/gbatek.htm#gbacartrealtimeclockrtc

https://problemkaputt.de/gbatek.htm#gbacartioportgpio

(you can thank nocash, lol)


edit:
(actual bit stream where you write/read the data between GBA CPU and RTC)

80000C4h - I/O Port Data (selectable W or R/W)
bit0-3 Data Bits 0..3 (0=Low, 1=High)
bit4-15 not used (0)

----------------------------------------------------------------------------------------------------------------------------------------------------------------------
(0 means RTC reads back to GBA CPU, 1 means GBA CPU writes to RTC)

80000C6h - I/O Port Direction (for above Data Port) (selectable W or R/W)
bit0-3 Direction for Data Port Bits 0..3 (0=In, 1=Out)
bit4-15 not used (0)

----------------------------------------------------------------------------------------------------------------------------------------------------------------------
(0 means GBA CPU doesn't care about contents, and force writes of whatever data was in 0x080000C4, if 0x080000C6 was 1)
(1 means both GBA CPU and RTC read and write the same bits of whatever data was in 0x080000C4, synchronously).
Careful about 1 here, because RTC will destroy/write a response to a command/whatever at 0x080000c4 if you issued a command from GBA CPU correctly through the same (C4) port

80000C8h - I/O Port Control (selectable W or R/W)
bit0 Register 80000C4h..80000C8h Control (0=Write-Only, 1=Read/Write)
bit1-15 not used (0)
In write-only mode, reads return 00h (or possible other data, if the rom contains non-zero data at that location).

 

[arrrk]

From the perspective of the GBA, if you write to address

Right I understand. You have to bit bang three wire SPI over the three GPIO pins.
I'm just trying to understand if I have the right interface to the ROM chip?
If I want to read GPIO Pin 0

I do this
C8 = 0000000000000001 //set Pin 0 to R/W
C6 = 0000000000000001 // Set Pin 0 to Read
I then read the data at C4?

Not exactly, I think you have to set the direction for all four GPIO pins (well, three for RTC) with C6. So to read that seiko RTC chip, you would write:
C6 = 0000000000000101 (pins 1 and 3 (CS and SCK) out and pin 2 (SIO) in)
To write, you would do all three high:
C6 = 0000000000000111

Then bit bang the serial data on C4.

Edit:
I think I see what you are saying. To just read one pin, yes, sort of, except 1 is write and 0 is read. However, that won't do you much good because you need to operate all three pins at the same time to get the serial data through, so you set the direction for all three then do your write/read.

Edit 2:
Ok and one more thing, C8 is just one bit, for the whole GPIO, not for each pin. I think in practice you just set it to 1 if you are using GPIO and 0 otherwise.

 

[YoshiMoshi]

So what's the need for three chips on flash cartridges that don't support RTC or light sensor or gyroscope etc?

I know one chip is the ROM, and other is a method to save data.
In order to RTC etc, you need a third chip, because flash memory devices don't have a GPIO interface

Yet I see bootleg cartridges from china, or flash cartridges that don't support RTC etc have 3 chips on them. What is the purpose of the third chip that is not flash storage to store the game, or flash storage to save the game, what is the function of the third chip in these cases?

Originally I thought it was so you could latch some of the address lines, because the GBA combines some of the data and address lines on the same contact on the cartridge hearder.

But looking at the datasheets for most flash memory devices that can be used to store ROMs, this logic of latching the address lines is built into the chip. Most flash memory devices with a parallel interface seem to latch the address lines for you automatically with logic built right into the chip.

 

[Coto]

So what's the need for three chips on flash cartridges that don't support RTC or light sensor or gyroscope etc?

I know one chip is the ROM, and other is a method to save data.
In order to RTC etc, you need a third chip, because flash memory devices don't have a GPIO interface

Yet I see bootleg cartridges from china, or flash cartridges that don't support RTC etc have 3 chips on them. What is the purpose of the third chip that is not flash storage to store the game, or flash storage to save the game, what is the function of the third chip in these cases?

Originally I thought it was so you could latch some of the address lines, because the GBA combines some of the data and address lines on the same contact on the cartridge hearder.

But looking at the datasheets for most flash memory devices that can be used to store ROMs, this logic of latching the address lines is built into the chip. Most flash memory devices with a parallel interface seem to latch the address lines for you automatically with logic built right into the chip.

You won't find anything related to CS, SCLK or whatever Nintendo used in GBA, in usual Flash documentation, because, like I said earlier, the implementation of a CS (Chip Select) pin can tristate power to either the Flash or the onboard mapped peripheral. That's the Nintendo magic for you, they use custom protocols to design their hardware and software. If you look carefully on the datalines, they designed the GPIO on top of whatever target chip design, and the goal of the GPIO is to provide a programmable interface for custom hardware to a GBA IO address hiding behind the usual chip design.

And you're talking about bootlegs now, that's a completely different matter anyway. The third chip on them is usually an ASIC for mapping the GBA bitbanging protocol to a custom IO mapping scheme. So the third chip acts as a "translator" between these two.

 

[YoshiMoshi]

You won't find anything related to CS, SCLK or whatever Nintendo used in GBA, in usual Flash documentation, because, like I said earlier, the implementation of a CS (Chip Select) pin can tristate power to either the Flash or the onboard mapped peripheral. That's the Nintendo magic for you, they use custom protocols to design their hardware and software. If you look carefully on the datalines, they designed the GPIO on top of whatever target chip design, and the goal of the GPIO is to provide a programmable interface for custom hardware to a GBA IO address hiding behind the usual chip design.

And you're talking about bootlegs now, that's a completely different matter anyway. The third chip on them is usually an ASIC for mapping the GBA bitbanging protocol to a custom IO mapping scheme. So the third chip acts as a "translator" between these two.

Hey thanks I really appreciate it!

I always thought that pin 5 on the cartridge CS (chip select) was used to select what chip to read/write data to. I always figured it was something like 3.3 V is for the ROM chip and 0 V was for the save game data chip (EEPROM, Flash, SRAM, FRAM). Is this wrong?

I see that your saying that the CS pin on the cartridge header can tristate power to the ROM chip or the GPIO device (like RTC chip). I'm not sure what exactly what you mean by this? I thought that the RTC chip was just simply connected to 3 GPIO pins on the ROM chip for bit banging three wire SPI, a pin for power, a pin for ground, two pins connected to the oscillating crystal, an INT pin that gets connected to pin 43 on the ROM chip which is an inverted signal of the IRQ signal on the cartridge header.

So I'm not sure how the CS pin on the cartridge header interfaces with the RTC chip?

Could you please explain how it does?

I'm trying to learn here, and it's great that you stuff. It seems to be not to common to know how it works.

I've checked the schematic of the AGB-E05-01 board (used for PKMN games with RTC) and Pin 2 on the cartridge header (the clock pin) is not connected to anything.

 

[Coto]

So I'm not sure how the CS pin on the cartridge header interfaces with the RTC chip?

Could you please explain how it does?

I'm trying to learn here, and it's great that you stuff. It seems to be not to common to know how it works.

I've checked the schematic of the AGB-E05-01 board (used for PKMN games with RTC) and Pin 2 on the cartridge header (the clock pin) is not connected to anything.

I suggest you read a GBA CPU implementation in verilog and how it works, because it runs on the wire level. There you should get all your answers.

I see that your saying that the CS pin on the cartridge header can tristate power to the ROM chip or the GPIO device (like RTC chip). I'm not sure what exactly what you mean by this? I thought that the RTC chip was just simply connected to 3 GPIO pins on the ROM chip for bit banging three wire SPI, a pin for power, a pin for ground, two pins connected to the oscillating crystal, an INT pin that gets connected to pin 43 on the ROM chip which is an inverted signal of the IRQ signal on the cartridge header.
View attachment 293601

(thanks nocash again, lol)

Pinouts - CPU - Signal Summary

Advance Gameboy CPU Signal Summary
Cart Bus: D0-D7, A0-A15, /CS, /RD, /WR (different usage in GBA/DMG mode)
WRAM Bus: WA0-WA16, WD0-WD15, /WLB, /WUB, /WWE, /WOE (used in GBA mode only)
LCD Bus : LDR1-5, LDG1-5, LDB1-5, DCK, LP, PS, SPL, CLS, SPS, MOD, REVC
Joypad: TP0-3 (Buttons), TP4-7 (Directions), TP8-9 (L/R-Buttons, via R43/R44)
Serial Link: SC, SD (aka P14?), SI, SO - Audio: SO1-2, Vin
Other: CK1-2, PHI, IN35, VCNT5, /FIQ (via CL1 to VDD3), /RESET (IN), /RES (OUT)
Supply: VDD35, VDD3, VDD2, GND (some are probably undoc inputs)

Anyway, the GPIO on the GBA is custom, the AGB CPU has an address decoder in the CPU itself. That's where all the magic happens. The above Signal Summary is the address decoding wired to each GBA CPU pin, and where it targets to. In this case, we refer to the "Cart Bus" data lines.

Cart Bus + GPIO scheme:
Ports C4, C6, C8 through the address decoder, change the data lines between ROM and onboard GPIO (D0-D7) on the GBA cartridge. So what you should be reading, is not the FlashROM docs, but how the FlashROM is wired to GPIO.
2 wires are important here (IIRC it was A14-A15) connected to GBA Cartridge, one being the Flash ROM and the other a GENERAL PURPOSE pin. 2 wires make up for: 0 = FlashROM (ROM mapped to AGB) / GPIO0, 1 = FlashROM (ROM mapped to AGB) / GPIO 1, 2 = FlashROM (ROM mapped to AGB) / GPIO 2, 3 = FlashROM (ROM mapped to AGB) / GPIO 3.

That's why you get setups like this:

Connection Examples

GPIO | Boktai | Wario Bit Pin | RTC SOL | GYR RBL -----------+---------+--------- 0 ROM.1 | SCK CLK | RES - 1 ROM.2 | SIO RST | CLK - 2 ROM.21 | CS - | DTA - 3 ROM.22 | - FLG | - MOT -----------+---------+--------- IRQ ROM.43 | IRQ - | - -

And then each GP Pin is connected to RTC, gyroscope, whatever. And I meant by tristate power, because the AGB address decoder is a tri-state inverter. An inverter can tristate power from a data line. Case use would be accessing the FlashROM from the AGB CPU, otherwise you'd need the FlashROM circuitry to eat absurd ammounts of battery life unnecessarily.

TLDR: GPIO is parallel to FlashROM by having different data lines, but get's mapped to the same GBA io port through the address decoder.

 

[YoshiMoshi]

I suggest you read a GBA CPU implementation in verilog and how it works, because it runs on the wire level. There you should get all your answers.




(thanks nocash again, lol)


Anyway, the GPIO on the GBA is custom, the AGB CPU has an address decoder in the CPU itself. That's where all the magic happens. The above Signal Summary is the address decoding wired to each GBA CPU pin, and where it targets to. In this case, we refer to the "Cart Bus" data lines.

Cart Bus + GPIO scheme:
Ports C4, C6, C8 through the address decoder, change the data lines between ROM and onboard GPIO (D0-D7) on the GBA cartridge. So what you should be reading, is not the FlashROM docs, but how the FlashROM is wired to GPIO.
2 wires are important here (IIRC it was A14-A15) connected to GBA Cartridge, one being the Flash ROM and the other a GENERAL PURPOSE pin. 2 wires make up for: 0 = FlashROM (ROM mapped to AGB) / GPIO0, 1 = FlashROM (ROM mapped to AGB) / GPIO 1, 2 = FlashROM (ROM mapped to AGB) / GPIO 2, 3 = FlashROM (ROM mapped to AGB) / GPIO 3.

That's why you get setups like this:


And then each GP Pin is connected to RTC, gyroscope, whatever. And I meant by tristate power, because the AGB address decoder is a tri-state inverter. An inverter can tristate power from a data line. Case use would be accessing the FlashROM from the AGB CPU, otherwise you'd need the FlashROM circuitry to eat absurd ammounts of battery life unnecessarily.

TLDR: GPIO is parallel to FlashROM by having different data lines, but get's mapped to the same GBA io port through the address decoder.

Hey thanks so much! It's nice to find someone that has this knowledge that seems so rare. I hope to learn as much as I can!

Is there a verilog implementation of the game boy advance? All I could "find" was the original game boy and not the game boy advance.

I think I got the wire configuration from the CPU to Cart Bus to ROM Chip to RTC Chip down:

ROM Address C8h & AGB CPU GPIO Enable/Disable Register
GBA Address: 80000C8h
ROM Address: C8h = 11001000b
MX23L6407-12C ROM Chip Pins: 14, 17, 28 @ 3.3 V remainder address lines @ GND
Cart Bus Pins: 9 [AD3], 12 [AD6], 13 [AD7] @ 3.3 V remainder address lines @ GND
CPU AGB Pins: 30, 27, 26 @ 3.3 V remainder of cart bus address lines @ GND

ROM Address C6h & AGB CPU Data Direction Register
GBA Address: 800006h
ROM Address: C6h = 11000110b
MX23L6407-12C ROM Chip Pins: 11, 12, 17, Pin 28 @ 3.3 V remainder address lines @ GND
Cart Bus Pins: 7 [AD1], 8 [AD2], 12 [AD6], 13 [AD7] @ 3.3 V remainder address lines @ GND
CPU AGB Pins: 32, 31, 27, 26 @ 3.3 V remainder of cart bus address lines @ GND

ROM Address C4h & CPU GPIO Data Register
GBA Address 80000C4h
ROM Address C4h = 11000100b
MX23L6407-12C ROM Chip Pins: 12, 17, 28 @ 3.3 V remainder of address lines @ GND
Cart Bus Pins: 8 [AD2], 12 [AD6], 13 [AD7] @ 3.3 V remainder address lines @ GND
CPU AGB Pins: 31, 27, 26 @ 3.3 V remainder of cart bus address lines @ GND

RTC 341055 to ROM Chip Interface
3 Wire SPI is used over GPIO pins, so bit banging is being used
341055 Pin 1 [INT] = MX23L6407-12C ROM Chip Pin 44 [IRQ]
341055 Pin 5 [CS] = MX23L6407-12C ROM Chip Pin 21 [CS]
341055 Pin 6 [SCK] = MX23L6407-12C ROM Chip Pin 1 [SCK]
341055 Pin 7 [SIO] = MX23L6407-12C ROM Chip Pin 2 [SIO]

I can't find any datasheet what so ever on the ROM chip, MX23L6407-12C. Even when I look at the manufacturers website, they don't have anything listed for this part, but for similar ones that aren't used in Nintendo carts. I can't find any documentation on the ROM chip to GPIO interface. Which I suspect is in the datasheet.

Were I'm struggling to understand is this:

• Addresses C4, C6 and C8 have data stored on the ROM that is read from
• Addresses C4, C6 and C8 are ALSO used for GPIO data
• There appears to be some custom logic that is within the ROM Chip to switch between ROM data and GPIO data
  • The RTC chip is connected to the ROM chip ONLY, so the switching logic MUST be in the ROM chip
• What is the logic that causes this switch to occur?

This I really don't understand. I can't wrap my brain around it. It seems to
I think it's this but I'm not entirely sure.
I think the key lies in address C8.
It would seem that you write the data 0000000000001111 at address C8 to switch from ROM data to GPIO data on all 4 GPIO pins.
You then write 0000000000000000 at address C8 to switch back to ROM data

Interesting, that I did not know! The GPIO data is on the same lines as the 8 bit data for SRAM, Cart Bus Pins 22 [D0] through Pin 27 [D7]? Is this right? This doesn't seem to match up with GBATEK which has the GPIO data as 16 bits and not 8 bits.

Although this begs the question, why are the 8 bits of data for flash storage to save games connected to both the ROM Chip that stores the actual game AND the flash chip to save games? I would expect no interaction between the two chips. Btu something is clearly going on here.