Difference in RTC behavior between open_agb_firm and mGBA

[geoku]

Hello!

When I start a new save in Pokemon Ruby/Sapphire in open_agb_firm and then load it into PkHex, it shows the "Initial Time" of 1 day. Which apparently means open_agb_firm thinks it's been 1 day since 2000.01.01 when the save was started, despite my 3DS's clock (the internal RTC, not the system offset), is set to the current date.

On the other hand, when I start a new save in mGBA, it has the "Initial Time" of 9326 days, which is the amount of days passed since 2000.01.01 to the current date.

So this makes me wonder which behavior is correct. Does the RTC on an actual cartridge start as soon as there's battery power, even if the game is not inserted, starts ticking time from 2000.01.01 onward, and then writes the amount of days since the battery insertion as the "Initial Time" when the new game is finally started? Which seems to be the mGBA behavior.

I've read in another issue (#82 (comment)) that open_agb_firm forces RTC to correspond to current date and time set on the console, but doesn't the behavior described above contradict it? The save started in open_agb_firm thinks it started 1 day after 2000.01.01, not 9326 days, which would be correct for today's date.

This creates issues when transferring saves between open_agb_firm and mGBA (for Pokemon trading purposes). When the save from open_agb_firm is loaded in mGBA, its "Time Elapsed" immediately gets overwritten to 9325 days, which makes the in-game clock wrong and I'm not sure what additional issues it might cause.

Strangely enough, the other way around is different: if the save is created in mGBA and then loaded in open_agb_firm, everything SEEMS to be fine, although I'm not sure as I didn't do much testing.

Can someone please help me undestand what's going on here?

[ajinn122]

Curious about this as well, as I went down this rabbit hole after trying to export and import sav files to and from oaf and mGBA. I think its mainly because oaf doesn't save the RTC data in its sav file (maybe it does if you override the saveType to the ones that end in "rtc" have not tested yet though), and mGBA adds the RTC data its sav files at the very end.
oaf seems to load sav files with the extra RTC data bytes as well as the normal ones so thats probably why the other way works without issue. As for cartridge behavior this answers your question about what happens to the RTC (it resets to 2000/1/1 00:00:00 when you start a new game).

[geoku]

So does that mean that open_agb_firm actually reads and writes the RTC footer in the .sav if it's present (when made by mGBA for example), just doesn't append it itself if the .sav is initially created in open_agb_firm?
UPD: No, it doesn't write to the footer, I've just tested this.

And as for cartridge behavior, that comment says it retains old RTC values if you simply start a new game, and only resets everything if you specifically perform the Select+Up+B combo.
I'm wondering about a theoretical situation where I bought a cartridge on release, and never touched it until today. If we assume that the battery didn't run out after all this time, and I unsealed the cartridge and started the game today (normally, without the reset combo), what would the "Initial Time" value in the save be? Will it be 1 day or something close to 9000? Was the RTC ticking in the sealed cartridge this whole time?

[ajinn122]

Yea tested it too rn and it doesn't.

For the second question, I'm not 100% sure, and I don't think anyone can actually test it but I am pretty sure it would still be ticking because the rtc is its own clock circuit with a battery. So the theoretical unsealed cartridge would have an RTC that's running probably from the moment the battery was connected at the factory, and if you just start a new game from there today, its initial time would be something close to 9000. But if you reset the game and then start a new one, it would be 0.

[geoku]

I think I've finally figured out what causes the Pokemon saves created in open_agb_firm to have the Initial Time of 1 day.

As it turns out, when you first boot a ROM that doesn't yet have a .sav in open_agb_firm, the RTC is set to start at 2000.01.01 for that first boot only. For any subsequent boots though (when the .sav file is already present), RTC is immediately forced to the current date set on the console.

To confirm this you can do the following:

1. Start a fresh Ruby/Sapphire save in open_agb_firm (make sure there's no prior .sav file)
2. Save immediately after setting the in-game clock.
3. Exit open_agb_firm.
4. Start open_agb_firm again, start the game, load your save and immedately save again.

You'll see that the resulting save has the Initial Time of 1 day, and the Time Elapsed will show 9000-something days (whatever represents the current date). This proves that on the first boot, when the save was created, the RTC was at 2000.01.01, but on subsequent boot it got forced to the current day.

I have no idea what reasoning was behind this decision, or if it's intended at all. This way all save games will immediately have a ton of in-game days passed (25+ years at this point), which will be weird when talking to some NPCs who report how many days/weeks you have played for. It would be as if you started a new game, saved in the very beginning, and then forgot about your cartridge only to pick it up again and resume playing after 25+ years.

mGBA's approach seems to be the correct one. It sets the RTC to the current date even on the first boot (without .sav file), saves the current date as the Initial Time, which makes the game count days from that point on, so it'll always reflect the correct amount of days since you started your save.

The way around all this weirdness is simply to start fresh saves in mGBA, save once after setting the in-game clock, then transfer the save to open_agb_firm. And then you're good, the time will always be the same both on mGBA and open_agb_firm.

UPD:

Just thought of an even easier way of starting a fresh save with the correct Initial Time on open_agb_firm itself:

1. When starting afresh in open_agb_firm (no prior .sav file), save BEFORE first setting the in-game clock
2. Exit open_agb_firm, launch it again, start your game and load your save, then set the in-game clock and continue.

Due to this being the second boot of the game with a save file already present, RTC won't be at 2000.01.01, it'll already be at the current date when you set your clock, so your Initial Time will correspond to the current date, and the time will be the same both in open_agb_firm and mGBA when you transfer your save back and forth. Hope this will help someone.

[ajinn122]

I guess for compatibility's sake it's still better to start your save file in mGBA for the footer, then move it oaf as it just ignores the extra bytes.

Update:
Actually, if you use the method to set the correct time in the oaf save and then load that into mgba and save again, it adds the rtc footer that should be accurate because it will initialize its rtc simulation from the current system time and have accurate intitial_time from the .sav file itself.

[geoku]

Yeah, I meant to reply it's not necessary to start in mGBA before you updated your comment.
Because mGBA will add the correct footer later regardless. So starting in open_agb_firm using the method I described in my previous comment is just as good and more convenient as you don't have to fiddle with transfering the save just to start.

I'd say the footer doesn't play any role in our case at all. The time should always be correct even if you cut the footer off altogether every time when transfering the save.

I don't know much about this, but from what I gather, the footer is probably just needed for devices that don't have consistent internal clock. So the footer tells them what to set their RTC to when starting the game, so that it can keep progressing from where it left off. In our case, just having the same system time on 3DS and PC is sufficient for consistency between mGBA and open_agb_firm.

[ChildOfDreams]

Having done testing w.r.t. this issue myself, the issue isn't linked to not having a .sav file; doing the Select-Up-B combo and starting a new game after, even if you reset beforehand, will have the initial RTC value be set to 0 (unless you save-reboot and then set the clock, as documented).

OAF is correctly setting the RTC value to the 3DS' RTC, but Pokémon seems to reset the RTC when a fresh New Game is started and then does not read the RTC again until the game is restarted, because the assumption was that the RTC would be 0 at that point (even though it isn't on OAF). It'll only read the clock 'correctly' once the game is started again, hence the jump if you set the clock on the first start.

A more accurate RTC implementation would require OAF to start from 0 for each game individually and then track the time difference when the game starts each time, most likely.

[geoku]

In my understanding, resetting the save with Select+Up+B isn't the same as just starting a new game on a brand new cartridge. Resetting does indeed reset the RTC to 0. But on a cartridge that never had a save, RTC is probably ticking since the battery was connected at the factory (let's assume the battery didn't run out), and when we start the first save file on such cartridge, it just uses the current RTC value as Initial Time without resetting it.

But if I'm wrong, and Pokemon does indeed reset the RTC on creating the FIRST save as you describe, this begs the question why does it behave differently on mGBA. There it always writes the current system date as the Initial Time in the save.

[ChildOfDreams]

PKHeX has special handling for emulators that store RTC in the footer like mGBA does.

https://github.com/kwsch/PKHeX/blob/master/PKHeX.Core/Saves/Util/Recognition/SaveHandlerFooterRTC.cs

So the data shows up as you expect in PKHeX + mGBA since they support each other, but aren't representative of how an actual cartridge works.

[geoku]

I cut off the footer manually in a hex editor for testing, fresh saves from mGBA always have the current date as Initial Time regardless of footer.