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.