19 February 2021, 00:32 | #1 |
Registered User
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 1,153
|
System clock gaining time under 3.1.4 and >50Hz screenmodes
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? |
19 February 2021, 12:38 | #2 |
Registered User
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 1,153
|
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? |
19 February 2021, 13:16 | #3 |
Ex nihilo nihil
Join Date: Oct 2017
Location: CH
Posts: 4,884
|
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 ? |
19 February 2021, 14:40 | #4 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,604
|
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.
I think this is your problem. WB clock should read TOD. |
19 February 2021, 15:11 | #5 | |||
Registered User
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 1,153
|
Quote:
Quote:
Quote:
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... |
|||
20 February 2021, 12:39 | #6 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,233
|
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. |
08 March 2021, 20:12 | #7 | ||
Registered User
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 1,153
|
Quote:
Quote:
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?] Last edited by robinsonb5; 09 March 2021 at 12:11. |
||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
WANTED - A1000 Real time clock "A-time" | loggio | MarketPlace | 0 | 21 August 2020 04:40 |
non-system startup code time/clock problem | modrobert | Coders. Asm / Hardware | 89 | 14 December 2018 15:37 |
time clock prob a2000 | source | Hardware mods | 11 | 07 August 2011 13:16 |
A1200 Real Time Clock | Eclipse | support.Hardware | 4 | 22 March 2011 02:18 |
App to update Amiga System time from web time?? | DDNI | request.Apps | 2 | 31 December 2007 07:21 |
|
|