System clock gaining time under 3.1.4 and >50Hz screenmodes

[robinsonb5]

I have a weird problem with the Minimig FPGA core with the system clock gaining time when the screenmode is anything other than PAL. What's weird is that it only happens under Kickstart 3.1.4.

Using a modified DblNTSC screenmode (which Workbench prefs says is 54Hz), if I run the Date command then run it again exactly a minute later, the Amiga thinks one minute and 5 seconds has passed.
Repeating the experiment in Multiscan Productivity mode (58Hz) the Amiga thinks one minute and 7 seconds has passed.

As I said, this doesn't happen with Kickstart 3.1 - only with Kickstart 3.1.4.

I'm wondering if the OS thinks its running on a model of Amiga which has a power-supply tick, since such a signal can feed the TOD counter of one of the CIAs. (On machines which don't have a power-supply tick - i.e. wedge Amigas, and also Minimig - that TOD counter is driven from VSync instead.)

Has anyone seen this effect on real hardware?

[robinsonb5]

Well I've gained a little more insight into what's going on:
Under Kickstart 3.1.4 the GfxBase->DisplayFlags field has the TODA_SAFE bit set, indicating the 3.1.4 believes there's a power supply tick pulse feeding CIA-A's ToD clock. There isn't - it's fed by VBlank. The same bit doesn't get set under Kickstart 3.1

So it looks like there's some discrepancy between real hardware and Minimig while trips up the PSU tick detection. Does anyone have any idea how 3.1.4 determines the presence of the PSU tick?

[malko]

Maybe Thomas Richter has an idea as one of the man behind 3.1.4.
Does it happen also with AOS 3.1.4.1 ?

[Photon]

It could be a change in detection of hardware registers to set that bit, and of course the MiniMig must implement all hardware registers correctly. E.g. it could be that the code is changed to detect it correctly on real Amigas, but the MiniMig tricks the detection code.

Originally Posted by robinsonb5

Minimig - that TOD counter is driven from VSync instead.

I think this is your problem. WB clock should read TOD.

[robinsonb5]

Originally Posted by malko

Maybe Thomas Richter has an idea as one of the man behind 3.1.4.
Does it happen also with AOS 3.1.4.1 ?

Good thinking, and good question - I will have to check whether the installation I'm tested with is actually 3.1.4 or 3.1.4.1.

Originally Posted by Photon

It could be a change in detection of hardware registers to set that bit, and of course the MiniMig must implement all hardware registers correctly. E.g. it could be that the code is changed to detect it correctly on real Amigas, but the MiniMig tricks the detection code.

Indeed - I'm sure it's a discrepancy in hardware behaviour between real machines and the Minimig. I "just" have to figure out what it is!

I think this is your problem. WB clock should read TOD.

I believe so. As I said, some real Amigas drive that TOD from a power supply tick signal - but not all Amigas have the tick. Those that don't (Wedge Amigas, CDTV and A4000 - and Minimig too) use VSync instead.

I can certainly implement a power_tick signal as a workaround, but I'd still like to understand what's making OS3.1.4 believe Minimig already has one when it doesn't...

[Thomas Richter]

Tick detection hasn't changed between 3.1 and 3.1.4, and 3.1.4 and 3.1.4.1, but the code has been recompiled with a later compiler, so the timing might be slightly different.

So this is what is essentially happening here:
1) The code waits for the active image area, i.e. vpos between 20 and 160.
2) The code turns on genlock (it is part of genlock detection)
3) The code reads vhposr 372 times and keeps the lower 8 bits of it.
4) The code reads vhposr two additional times
5) If the position has changed (i.e. the lower 8 bits read before are different from the lower 8 bits read now), genlock is assumed, and the TODA_SAFE flag is not set.
6) If they are the same, the ciaatod is cleared and ciaa timer is set to the free running mode. The timer values are set to 0xffff
7) As long as the high timer count is still 0xff, check whether the ciaatod low bytes are changing from 0 (i.e. whether the TOD is ticking). If so, set the TODA_SAFE bit.
8) BPLCON0 is cleared.

Thus, to ensure that the TOD is detected, make sure that vhposr does not change under the above conditions, AND make sure that the TOD is ticking. You probably do not evaluate the genlock bits correctly, i.e. if genlock is enabled during the active display area, and no genlock signal is coming in, vhposr should not change.

[robinsonb5]

Originally Posted by Thomas Richter

Tick detection hasn't changed between 3.1 and 3.1.4, and 3.1.4 and 3.1.4.1, but the code has been recompiled with a later compiler, so the timing might be slightly different.

Thanks for the response, and my apologies for not following it up until now.

6) If they are the same, the ciaatod is cleared and ciaa timer is set to the free running mode. The timer values are set to 0xffff
7) As long as the high timer count is still 0xff, check whether the ciaatod low bytes are changing from 0 (i.e. whether the TOD is ticking). If so, set the TODA_SAFE bit.

I think the problem was caused by the change of compiler, which hit a discrepancy in the Minimig CIA implementation.

On KS3.1 when the TOD counter is cleared, I see three consecutive writes, to TOD Hi, Mid and Lo in sequence.
On 3.1.4 I see a write to Hi, a read from Hi, a write to Mid, a read from Mid, then a write to Lo.
I'm guessing this difference is due to the different compilers having different interpretations of something along the lines of "hi=mid=lo=0;"?

According to the HRM's description of the TOD counters, this would leave the read latch active, since there's no read from Lo to clear it; thus the first read after starting the free-running timer will read the counter's old value, not the expected zero.

I suspect real hardware clears the read latch on write accesses to Lo, not just on reads; making Minimig behave this way solves the problem.
[Edit: I don't have real hardware with OS3.1.4 but testing the CIA behaviour on real hardware suggests that my guess about write accesses clearing the latch is wrong - so there's some other discrepancy between real hardware and Minimig causing this. Always assuming that this problem doesn't manifest on real hardware - can anyone confirm that?]