Timing

I may have found a very serious bug with the Dreamcast’s real-time clock. It will reset itself after a while. By a while, I mean 29 days, 59 minutes, and between 40-50 seconds.

This came about during implementing an NTP client. I thought that the problem was calculating the time, but it was due to setting it too far into the future or past. I’ve only been focusing on the future time, so I’m not certain what the limit is for rolling back.

Which has now led me down this path of reverse-engineering the BootROM. Not something I don’t enjoy, but I’d rather not have it take up my time right now. I’m thinking that since you can obviously set the time via the BootROM menu, there must be something different with the way that the time is set.

I spent a good few hours looking at the RTC built into the CPU, which was silly because the AICA controls this. You just write a 1 to 0xA0710008 to enable writing, and set the 0xA0710000 to the high word, and 0xA0710004 to the low word of the seconds to pass through. For whatever reason, either using syRtcSetDate or manually setting the time results in the clock appearing to be considered reset by the BootROM. If I just relaunch the debugger, the time is still maintained.

Looking at the BootROM dump in Ghidra, I’ve found where this is being called and can set a breakpoint to verify that when the time is confirmed it gets hit. So far, I haven’t found much to work with. Hopefully it’s not something that will take weeks to figure out. If it takes more than a week, I’m going to move on for now until I can get back to investigating what’s going on with it.

After this, I think I have to start with action mapping and GUI stuff on the game. I’ll get back to shadows one day.