Re: [hatari-devel] MSTE clock emulation

[ Thread Index | Date Index | More Archives ]

Le 17/09/2015 14:55, Thorsten Otto a écrit :
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.


thanks for pointing these.

from what I see, code in rtc.c is rather old, I guess it was added just to perform the minimal job and make tos happy.

Is there a program you know that doesn't work because of this ?

I haven't checked the schematic, but is the RTC supposed to trigger an IRQ in the ST when an alarm is reached ? This doesn't seem to be connected to the MFP.

Since mega st and falcon/tt share the same MC146818, some code could certainly be shared instead of having 2 version in rtc.c and nvram.c

If someone feels like doing it, else let's add it to the todo list, but it won't be a top priority :)


Thorsten Otto <halgara@xxxxxxxx> schrieb am 10:17 Donnerstag,
17.September 2015:


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.


Mail converted by MHonArc 2.6.19+