Hmmm... Managed to start Hiren's Boot CD 7.8 with the current version, running PC-Check 5.50 without crashing during boot. The CPU tests verified it as having 'no bugs', but once running all motherboard tests, it seems to hang on the "System Timer" test, passing the "Clock Ticking Check" test then hanging on the "Channel 0 Interval (mS) . " test, saying "Testing"? Why would it hang on such a test?
Edit: Hmmm... It seems to wait for CMOS register A(status register A) bit 7 to set... That's the Time update in progress flag!
Edit: Turns out it was being set when 244us was left until an update starts. But once it triggered(which was done while updating expired only), it would also trigger the time update itself, which immediately would clear said flag, never alowing software to see it!
Edit: Luckily, it's an easy fix! Just check if to set the flag all the time instead of during ticking only. Although it counts 244uS until an update, which happens multiple times per second in UniPCemu. That's 32768 times a second in UniPCemu, thus each 30us?
Edit: Now it's an immediate divide overflow error at that point?
Edit: Just changed the 244uS delay to set the bit for 244uS when updating the current time(and throwing IRQs etc because of updated second causes). It will still immediately update the time registers when this happens, but will just keep the update bit set for 244uS into the next second for software to detect it's ticking.
Would that be enough? What about accurate?
Of course, it will set for 244uS after each time the whole seconds changes, which happens at most 32768 times for each emulated second in CPU emulation time. Each of those ticks will update the time with a new timestamp if not blocked by setting the bit up to stop the clock ticking. When a new timestamp is loaded into the CMOS date/time registers that way(with a different amount of seconds in Unix timestamp), a timer is started for 244uS to set(when the timer starts) and clear the UIP bit(when the timer expires). Of course, it'll happen after the registers are already updated(at the moment it becomes 1, the Y/M/D HH:MM:SS registers(and their related registers, if any) are updated with a new value). The value will become 0 from the 244uS being elapsed in emulated time until the amount of Unix timestamp seconds changes once again, causing it to be set again for another duration etc.
Of course, it's setting and changing in seconds time will depend on the relative speed of the timekeeping. Said timekeeping uses the normal UniPCemu timekeeping at realtime(when setup like that, causing it to update using the system clock(depending on the OS UniPCemu runs on), which might be faster than the emulated system is running at (so at 20% realtime emulation speed(the CPU running at 1/5th of a real one's realtime speed), it'll update 5 times in a emulated second based on CPU cycles and other hardware timing(PIT, sound cards, video cards etc.))) or cycle-accurate(when set to cycle-accurate mode, which causes the timer to run at emulated speed instead, at emulated time intervals(so 1 second emulated = 1 second on the RTC)).