User avatar

Posted Tue Nov 03, 2020 8:13 pm

I just recently resurrected the Amiga 1000 that's been collecting dust in my back room for the last two decades. It came with a Starboard 2 and multifunction module. I don't recall if it came with any software; if it did then I it must have misplaced it. In any case, I don't have the software for the multifunction module, and unfortunately a search for it turned up nothing. I really only care about the real time clock anyway, so I improvised, and downloaded the SCSI module software instead. I was going on the assumption that both modules probably use the same real time clock chip and the same RTC software as well. It turns out that my assumption was correct.

While looking through the documentation for the "StarTime" software, I found a section that explains that the RTC does not store seconds, and that whenever the software reads from the RTC, it automatically sets the seconds to 30. This means that the Amiga system time can be off by as much as +/- 30 seconds after setting it with the StarTime software. So this got me wondering about what other odd behavior I could find with the Microbotics RTC. For anyone who's interested here's what I found.
  • The seconds counter free runs, and is completely unaffected by anything that happens in the RTC chip. Setting the RTC time does not reset its seconds counter to zero. If you want to synchronize the RTC seconds counter with the actual time, then the only way to do this is to disconnect the battery, and then reconnect it at the precise instant when your reference clock shows zero seconds.
  • The RTC chip does not store, or even count, the year. The StarTime software uses a trick in which it stores the month and year in the RTC alarm registers for reference. Whenever the software reads from the RTC chip, it checks the month stored in the alarm register against the month counter to see if the year needs to be updated. When it detects that the month counter is less than the stored month, it increments the year, and saves it back into the alarm register. A side effect of this trick can be seen if the machine is left powered off for over a year. When this happens, the battery backed month counter will roll over and count up past the stored month. Now when the StarTime software is run, the month counter is greater than (or equal to) the stored month. The software sees no reason to update the year, and the Amiga system time is now set to one year behind the actual date.
  • The alarm register used to store the year is 6 bits wide, and since the software stores the year in BCD, the largest value that this register can hold is 39. This year value represents an offset from the Amiga epoch, Jan 1, 1978, which means that the RTC can only store dates between Jan 1, 1978 and Dec 31, 2017. This is why the StarTime software currently sets the Amiga system time to exactly forty years behind the current date. I've written a small program to address this issue that adds forty years to the Amiga sytem time, and I have it in my Startup-Sequence just after the StarTime command. It works fine, and fortunately I won't have to rewrite it until Jan 1, 2058.
  • The RTC chip is aware of, and can handle the day Feb. 29. However, the chip has no means of automatically handling leap years since is doesn't keep track of the year. The scheme that the StarTime software uses to keep track of the year also makes it impossible to automatically adjust for leap years. And so, the date will have to be manually updated once every four years.
  • The StarTime software does not automatically adjust for daylight saving time, though there's no technical reason that it couldn't.
For those of you interested in reading more about the internal workings of the RTC chip, here's a link to the datasheet. ... CF8573.pdf

Return to “Hardware”