Re: [hatari-devel] MSTE clock emulation

[Thorsten Otto <halgara@xxxxxxxx>]

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

No program that refuses to work, but having the wrong date/time is no good thing either.

>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.

The TT clock is connected to TT-MFP Interrupt 14. The MSTE clock does not seem to be connected. But i don't think it is neccessary to emulate the alarm, neither ARAnyM nor STonX nor any other emulator that i know of does this, and it is always a tedious task to emulate interrupts, especially if they are timer-based. And it will also be hard to find a program that makes use of it, in order to test it.

> 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

The chips are the same, but the way they are accessed is rather different. The TT chip is accessed on only 2 IO-ports, register select and data, while the MSTE has a separate port for every register, some of them even on 2 ports. The nvram code also has to deal with the NVRAM in the clock, while the RAM in the MSTE clock seems to be not accessible.

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

At least the year offset should be fixed. I currently have no confguration where i can boot only EmuTOS and still have a way to check the date since all my drives are gemdos-drives, but i think its not uncommon nowadays to use EmuTOS, and i'm quite sure that the bug will reveal there. Booting TOS 3.01 at least shows that the date is actually off by 2 years.

Nicolas Pomarède <npomarede@xxxxxxxxxxxx> schrieb am 10:44 Freitag, 18.September 2015:

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.
>

Hi

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 :)

Nicolas

>
>
> 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
>
>
>