On Fri, Jun 13, 2008 at 03:18:07PM +0100, David Pitt wrote: > VRPC uses the SyncClock module to keep itself in step with the Windows > clock, which it does every five seconds.
Interesting. I wonder what RTCAdjust does in that case. > The module makes calls to SWI "IIC_Control". On a real RISC OS machine such > calls are the the hardware clock. I would think an emulator would need to do > some emulating to redirect IIC calls to Windows, or Linux. > > !Sick on RPCemu seems to think it has found a clock, but does it mean it :- > > Real time clock: Philips PCF8583 > I?C address: &A0 > Reference clock: 32.768 kHz (configured) IIC_Control accesses the PCF8583 clock chip (which also holds the CMOS RAM). For RISC OS to be able to read the time at all the chip must be emulated (at least in part), so RPCEmu already supports it. What I'm confused about is where RPCEmu actually reads the system time to provide the RTC values. cmostick() is the only place I can see that reads the system time, and that's in a big #if defined WIN32 || defined _WIN32 || defined _WIN32 block. So (question for Tom) how do other platforms read the time? I'm sure there's something whoppingly obvious here but I can't see it :) Thinking about it, if it was simply a case of a read of the relevant clock chip register causing a read from the system time, that would be OK and SyncClock (or a clone) should work on RPCEmu too. Tom, on Windows why does RPCEmu have cmostick() called every millisecond to update the CMOS time rather than just calling gettimeofday() as and when required. Does it upset something else? Theo _______________________________________________ Rpcemu mailing list [email protected] http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
