The Realtime Clock is fully implemented. However, it works slightly different than the real one.

The UIP bit is never seen as set. This is due to the fact that the time registers are double buffered. The clock updates a set of time registers. But the system reads a different set of time registers. 

The READ time registers are updated when the REGISTER A is read, or when the REGISTER B is read. This should work, since it is a requirement that after a Update Interrupt, you MUST read the Register B to see which interrupt occured. And when polling, you MUST read the Register A to see if the UIP bit is set or not. 

So, since Register A or Register B must be read before reading the time registers, that is when the time registers are updated with the Current contents of the update time registers. And, since no OS update of the registers can occur until an OS release occurs, this works.

Software, will NEVER see the UIP bit set. Software will never see a power failure. 

BUG in Versados 4.3---- there's an error in the read clock routine, that thwarts the above... the read clock fails to read the register containing the UIP bit due to a programmer error. So, added code to fix this for V 4.3. The registers are also double buffered when the HOURS register is read. 

IF the registry key "General\VdosVersion"  does not exist, then the default is =1027(&H403). If the key exists, then whatever is there is used as VDOS VERSION... Only 1027 (&h403) matters. If the version is &h403 then the registers are also double buffered when HOURS is read. This fixes the 4.3 clock read so it works. Since the key does NOT exist, the bug fix is there for all versions of VDOS, but OK since they all read the HOURS register first. 

Periodic Interrupts also have time base restrictions. The  Visual Basic timer event, uses a ONE MS resolution, so, it is impossible to set a periodic interrupt less than 1 MS. All RATEs below 1 MS are set to 1MS. 

Also, currently, the periodic interrupts above 1MS are set to integers of 1MS resolution. 

The Windows OS uses the old IBM PC's Timer, (not the high res timer) so, all periodic events are multiples of 55ms.

SO, even though periods as low as 1 ms can be requested, the real system timer can only generate periodic events at 55ms intervals. Use HOT PATCHes to make Vdos use 55ms instead of 15.625ms.

The ability to set time relies on the system time format. It must be US.(intend to fix this)

The Time is preset to have an Offset of -28 years (in 2018 it is 1990). This places the clock's time prior to Y2K. It also makes day of week and leap years work properly until 2028. Since VersaDOS and CPM 68k are NOT Y2K compliant, it is best to not set the time beyond 1999. Setting the time (in the emulator) will change the time Offset. The system clock is unaffected. So, when you boot Versados, use a date 28 years in the past.

NOTE - Versados dates are Y2K compliant as 16 bit binary numbers (number of days since 1980..good for ~89 years ), however the code to input dates is NOT Y2K compliant.

Due to emulator/OS problems, the time as kept by VersaDOS is not reliable. During times when the GUI get control the periodic interrupts are lost.  So the periodic timer is loosing interrupt events. 

Versados does not examine the real time clock to get the time. It keeps track of how many periodic interrupts have occured and adds the Time to a counter of milliseconds since midnight. The periodic timer should be generating an interrupt each 15.625 MS but the minimum resolution is 55 MS, so even though versados thinks it is being interrupted every 15.625ms, it is really being interrupted every 55ms. This causes the system to incorrectly keep time. Even if the HOT patch is applied to change the tally to 55 instead of 15.625, the system time is still unreliable, due to the fact that the host OS does not allow the emulator to run when doing its own house keeping. Interrupts are lost.
