Small update:
in src/falcon/nvram.c, where the TT/Falcon clock is handled, the code
also ignores the setting of Binary/BCD and 12hr/24hr mode. For the TT
clock, these are contained in the register 11 (bit 1 == 1 for 24hr, bit
2 == 1 for binary format).
There is also another bug there: The year offset is hardcoded at 68.
However, it depends on the TOS version loaded. TOS versions <= 3.05
(including EmuTOS) used an offset of 70. This leads to the year being 2
years in the future when you run older TOS versions.
Thorsten Otto <halgara@xxxxxxxx> schrieb am 10:17 Donnerstag,
17.September 2015:
Hi,
while looking at the code, i just noticed some quirks in the emulation
of the MSTE clock (fffc20-fffc3f, in src/rtc.c).
First off, reading/writing to the minutes registers use some backup
variables named fake_am/fake_amz when rtc_bank!=0. These are a bit
mis-named, since the minutes registers have nothing to do with 12hr/24hr
mode. The values accessed when rtc_bank==1 are the alarm settings.
Secondly, the mc146818 also has alarm registers for seconds & hours,
although i'm not entirely sure wether they are implemented on real
hardware. Existing TOS versions seem to only access the minutes.
Whats more serious though is that reading/writing to fffc35 affects the
12hr/24hr mode when rtc_bank!=0. This register is not handled at all,
and should also affect what reading/writing the hour registers return.
From what i've seen, bit0==1 in that address selects 24hr mode (initial
value after reset), otherwise 12hr mode. At least EmuTOS and linux-68k
would expect that address to return 1, otherwise they interpret the hour
to be in 12hr format.
What i could not figure out is where the BCD/BIN bit could be
read/written (the MSTE chip is the same as that in the TT, but the I/O
mapping is rather different).
Another thing that i'm not entirely sure about is, that all values read
from bank0 seem to have the high nibble set to 0xf on real hardware.
This is done in some, but not all cases.
Greetings,
Thorsten