On Fri, Jun 13, 2008 at 11:43:11AM +0200, Steffen Huber wrote: > Fact #1: during startup, RISC OS asks via IIC its hardware realtime > clock for the date and time and takes a soft copy of it. SWIs in RISC OS > which deal with asking for date and time always work on the soft copy. > > Fact #2: after startup, the soft copy is incremented by a Timer (I think it > is Timer 0, but I'm not sure). The hardware realtime clock is not used > anymore (only if the time is set, the hardware clock is also adjusted).
Yup, that's right. In fact it's how most OSs do it - but some Linuxes writes back the soft-copy of the RTC to the hardware clock (especially if the soft copy has been adjusted by NTP etc). Talking to hardware devices is too slow to be done frequently, which is why it keeps a soft copy. You're right in that it's IOC/IOMD Timer 0 - I once fiddled with the reload value of the timer to make my system 'hundreds of times faster'. All it did was make the system time increase at a very rapid speed :) > So RPCemu should - if it detects a "restart from hibernate" (don't even > know if this is easily possible...) - probably sync the PC clock with the > RISC OS clock again. Then, everything should work fine. In RISC OS there's the RTCAdjust module which will try to keep the soft-copy in line with the hardware copy. The reason is to ensure applications aren't confused. Imagine if you discover the hardware clock is running a minute behind the soft clock - for apps time would either go backwards or stand still. RTCAdjust smooths the transition so time is still increasing but at a slower rate. FWIW the same problem happens on Virtual Risc PC. What might be easier than trying to detect a 'restart from hibernate' (which is different for every platform) is to periodically write the correct system time values into the emulated CMOS 'registers' ready for RTCAdjust to pick up. If you repeat this on the basis of 'if over a minute of real time has elapsed since the previous time we did it' then it should pick up hibernation periods longer than a minute, and also correct any drift due to RPCEmu's emulated IOMD Timer 0 being slightly out. It might require a bit of re-engineering of RTCAdjust - I don't know if it can cope with multi-day delays. But if necessary someone could ask ROOL to release the sources to it if it isn't already. Theo _______________________________________________ Rpcemu mailing list [email protected] http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
