Winuae 4.10 clock drift

[Phantasm]

Since I've upgraded to winuae 4.10 my setup seems to suffer quite significant clock drift. I haven't had time to do much investigation so far but my setup was always fine with previous versions. I'm emulating a 4000 and the tod clock source is set to 50hz clock not vsync. I leave my system running winuae 24/7 as I'm running a bbs so clock sync is quite important.

I've switched back to the previous version for now but I will attempt to do further testing to see if I can figure out anything.

[Toni Wilen]

It was supposedly fixed in last few 4.10 betas. Attach your config, please.

[Phantasm]

config file attached as requested

[Toni Wilen]

Can't see anything obviously wrong. Does the clock run too slow or too fast and how much is the drift for example after 10 minutes?
EDIT: and is the drift same if you select 60Hz PSU tick compared to 50Hz PSU tick?

[Phantasm]

i may have jumped the gun as i am now not able to recreate it.


I will continue trying and let you know.

[Toni Wilen]

Clock drift can still happen if emulator gets slowed down too much for any reason.

[Phantasm]

Originally Posted by Toni Wilen

Clock drift can still happen if emulator gets slowed down too much for any reason.

There is definitely something a bit weird going on. I left it running overnight and this morning I checked and it had lost around 8 hours (still showing around 17:00 from yesterday).


When I clicked on the window to activate the clock started updating quickly as if it was trying to catch up but when it hit 00:00 it briefly updated to the next day and then reset back to the day before and its just cycling round and round now.


It seems to run fine when i'm sitting watching it (no drift happens after 1 hour or more) then when its been left it seems to act strangely.

Video clip..

https://tempclip.com/en/3tljcpbOUOkomWa/watch

[Phantasm]

I grabbed the WinUAE source code from github and after quite a bit of trial and error over the last few days I've managed to figure out whats going on here.


Its not a clock drift issue as such - its related to the TOD clock sync code.


In the versions from this commit onwards https://github.com/tonioni/WinUAE/co...53a2ac9703735e where the CIA TOD code was refactored the tod clock sync goes wrong after around running for roughly 12 hours or so.

so in the do_tod_hack code one line was changed to facilitate the refactoring

static void do_tod_hack(int dotod)
{

...

    if (docount) {
        cia[0].tod++;
        cia[0].tod &= 0x00ffffff;
        tod_hack_tod_last = cia[0].tod;
        - ciaa_checkalarm(false);   //this line changed from this
        + cia_checkalarm(false, false, 0);   // to this
    }

and the ciaa_checkalarm function was refactored from this

static void ciaa_checkalarm(bool inc)
{
    struct CIA *c = &cia[0];

    if (checkalarm(c->tod, c->alarm, inc, 0)) {
#if CIAA_DEBUG_IRQ
        write_log(_T("CIAA tod %08x %08x\n"), c->tod, c->alarm);
#endif
        CIA_sync_interrupt(0, ICR_ALARM);
    }
}

to this

static bool cia_checkalarm(bool inc, bool irq, int num)
{
    struct CIA *c = &cia[num];

    // hack: do not trigger alarm interrupt if KS code and both
    // tod and alarm == 0. This incorrectly triggers on non-cycle exact
    // modes. Real hardware value written to ciabtod by KS is always
    // at least 1 or larger due to bus cycle delays when reading
    // old value.
#if 1
    if (num) {
        if (!currprefs.cpu_compatible && (munge24(m68k_getpc()) & 0xFFF80000) != 0xF80000) {
            if (c->tod == 0 && c->alarm == 0)
                return false;
        }
    }
#endif
    if (checkalarm(c->tod, c->alarm, inc)) {
#if CIAB_DEBUG_IRQ
        write_log(_T("CIAB tod %08x %08x\n"), c->tod, c->alarm);
#endif
        if (irq) {
            CIA_sync_interrupt(num, ICR_ALARM);
        }
        return true;
    }
    return false;
 }

in the earlier code ciaa_checkalarm the CIA_sync_interrupt(0, ICR_ALARM); call was always executed and in the new version it is only executed when the bool irq parameter is true. In the new do_tod_hack code the parameter is passed in as false.


changing the new code to read cia_checkalarm(false, true, 0); resolves the problem and allows the time to work correctly and restores the code to working the same way it was working previous to the commit.


In order more easily see this issue in effect I was able to run the do_tod_hack at a higher rate by focing this code to execute every time (by setting docount=1 just prior to the code block)



if (docount) {
cia[0].tod++;
cia[0].tod &= 0x00ffffff;
tod_hack_tod_last = cia[0].tod;
cia_checkalarm(false, false, 0);
}


here is a video clip of the clock looping around using the above hack to speed up the process..


https://tempclip.com/52x9NkfQG6nmfgw/watch



Hope this all makes sense.

[Toni Wilen]

Fix looks correct, thanks.