Files
hpr-knowledge-base/hpr_transcripts/hpr3765.txt

109 lines
8.3 KiB
Plaintext
Raw Normal View History

Episode: 3765
Title: HPR3765: Fixing clock events in GBA pokemon cartridges
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3765/hpr3765.mp3
Transcribed: 2025-10-25 05:08:03
---
This is Hacker Public Radio Episode 3,765 for Friday 6 January 2023.
Today's show is entitled, Fixing Clock Events in GBA Pokémon Cartridges.
It is part of the series' hobby electronics.
It is hosted by Celeste, and is about 14 minutes long.
It carries a clean flag.
The summary is tinkering with the RTC real-time clock hardware on Game Boy Advance Cartridges.
Hello everyone, and welcome to this new episode of My Podcast.
Today we will talk about something I found out, and I've been trying to tinker with in the last days.
It asks Game Boy Advance Cartridges from 2003 and 2005.
Some of these cartridges have an internal battery, because they need to keep track of the time using an RTC real-time clock in the hardware of the cartridge.
And when these battery faints and is exhausted, some problems arise.
So, first let's talk about how the battery has been used in these games.
While in the previous games, from the Game Boy and Game Boy Color, like the Pokémon Gold and Silver and Crystal versions,
the battery was also used to keep the save file, so not only the time,
so when the battery is exhausted, you also lose every single save file you might have.
Which is quite bad, because it was stored in an SRAM memory, which needed energy.
In the next games, they swapped the SRAM for the save file for a flash memory,
so that it could keep the save file even without energy.
But it still had a real time clock inside for the time events.
For example, growing berries and plants or discounts at the stores in the game.
And also, something I need to search a translation for.
Maria.
Maria is the sea.
The tide.
Every six hours.
You have the tide.
Because certain locations of the game could only be accessed within a certain time frame,
or they appear different based on the tide level.
So these games really need a working internal battery to run this internal clock.
When the battery is exhausted, the real time clock returns zero, which means first of January of year 2000.
And it keeps returning zero.
That's fine, it's fainted, it makes sense.
So when the game detects zero, returned by that, by that RTC clock,
it displays a wording message to replace the battery.
You replace the battery using some iron, some soldering, or other methods you can find online,
trying to unclip the battery manually, and fix it there with tape.
There are some methods to do that.
Anyway, you can search that on YouTube.
Anyway, you succeed to replace that battery.
The RTC clock starts to work again.
But hey, the clock starts again from January 1st of 2000.
While your save file, last time stamp that your save files had, displays 2007.
So the game thinks to be in the future, while the clock is 7 years back.
You plant a battery in the ground, in your save file in 2007.
So that it will grow in 12 hours.
But then, in order to be grown, it has to be your current time some save file plus 12 hours.
But your real time clock is still stuck and the January 1st of 2000.
So unless you wait 7 years, you won't see your battery grown.
So we have to find a way to fix that.
And I found two ways online.
I still haven't tried this. I want to try this, but I still need a tool to do that.
So you can theoretically choose two paths.
First, you can revert the time stamp in your save file by editing the save file directly.
So that the game sees January 1st of 2000 as the last scene time stamp.
In this way, the RTC will be in the future compared to the internal save file and the game will be happy.
Another alternative is to move the internal RTC clock in the future, maybe in today's date, so that it's in the future compared to the internal timestamp.
Such error happens because when the game compares the calendar event like the growth of a battery in 2007 with the real time clock, which is close to 0 after you replace the battery,
you will do real time clock minus calendar date, and it will get a negative number which will be clamped to 0.
So it says, hey, 0 time has passed, so the event has not happened.
And the whole game appears as stuck.
There's only one exception to this glitch, which is the tidal control, because I guess they are using some modules operation, because it only keeps track of the hours retarded by the real time clock and not the day.
So that tidal control is not affected by this problem.
I was saying, you can patch it or by rolling back the save file timestamp or by putting your RTC clock in the future.
And you have two tools.
You could use some proper GBA tools, but nowadays it's, for example, in order to directly edit and dump the same file from the Game Boy Advance, but they are quite rare to find.
But there is something we can use, at least that's what I read. I still miss that tool.
You can find a DS flash ROM. DS flash ROMs let you run any game, unfortunately even pirated ones, but it should be fine if you own the copy of the game.
You can run a backup copy legally in most countries, as far as I know.
But you can also run a homebrew and custom tools on a Nintendo DS.
And a Nintendo DS has a secondary slot for old Game Boy Advance games.
The Game Boy Advance slot can be accessed from the Nintendo DS software.
So there are two tools that you will run on your Nintendo DS using a flash ROM to run custom software on the DS.
That will access the save file in the secondary slot of the Game Boy Advance cartridge.
And you can manually change the real time clock internal value.
I would like to add another trivia. There is a glitch related to the real time clock that happens in the Ruby and Sapphire games from 2003.
The game will run normally in the first year. You can see every calendar event working correctly.
But then it will froze for a whole year. Because the real time clock saves the year, the day, the minute, the hour, the second, and everything.
But the internal game only needs a day.
It converts the entire time stamp to a single day variable.
And when the conversion happens, there is a bug in these previous games where the year 2000 and the year 2001 of the real time clock will be collapsed as it were 2000.
So if you plant a berry on 31 December of 2000 in the internal battery, in the internal RTC time stamp, and you wait a few hours to the January 1, 2001, everything will be blocked because the game will think that it's still in the year 2000.
So it rolled back, it thinks to be rolled back about 36-5 days.
And you have to wait another 365 days to be in 20, sorry, 2002.
To unlock that.
And this is one of the very few games of the cartridges games where an official fix has been delivered by the producer.
Unlike many other cartridges games, in many other cartridges games, simply enough, when the bug is discovered, only the newly-productive cartridges will be fixed and passed, but the patch will be not applied to the old ones.
As this was a pretty bad glitch, a patch has been provided, you could connect your Sapphire Ruby game to the next generation games, you give a cable link and a special program inside them.
And what this special program did, it simply to advance the RTC clock.
By 365 days, if you were, so that the game will think to be after 2002, and you will not encounter the year 2000 and year 2001, collecting together and making this glitch happen.
I just pushed the game internal clock forward by one year, and yeah, you did the job.
So I will try these methods, I will post the links to do that in the description.
And I found them on some forums, and they are open-source, and I trust them a bit more to run on my regular hardware.
But I still need to try to, so let me know if you have tried that, or you have some hardware and want to try.
And maybe if I succeed, or if I didn't succeed, I will make another episode explaining what went wrong, what went right.
So it's all for today, and see you in the next episode.
Thank you for listening.
You have been listening to Hacker Public Radio at HackerPublicRadio.org.
Today's show was contributed by a HBR listener like yourself.
If you ever thought of recording podcasts, you click on our contribute link to find out how easy it really is.
Hosting for HBR has been kindly provided by an honesthost.com, the internet archive, and our syncs.net.
Unless otherwise stated, today's show is released under Creative Commons, Attribution, 4.0 International License.