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 buffered set of time registers. 

The REAL time registers are updated when the REGISTER A is read, or when the REGISTER C is read. This should work, since it is a requirement that after a Update Interrupt, you MUST read the Register C 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 C must be read before reading the time registers, that is when the buffered 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, except for first run.

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. To make this work you MUST use Debug Command Version to set Version to 43.

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. 

The debugger's Version command can be used to set vdos Version, which also creaates the key.

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 file 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, and no century byte is kept in the clock.

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.

When incrementing, if a register contains a value greater than defined max or less than defined minimun then the register it set to minimum or 0. IF the regisster contains invalid digits, then no increment occurs. All invalid BCD is converted to 0 binary.

Beginning with 1.0.12 you can specify which century (19 ro 20) to use in the 1468hc18's set time routines. Currently all software (vdos) that uses the clock do NOT support century 20. There is no century register in the clock. For the emulator's time routines to support centuries other than 19, you must change the software (versados) to support. Typically a byte is kept in the CMOS to indicate what century. Now the Day of week is independent of the system time and can be set to any number between 1 and 7, and is incremented independently. It will be set accoring to system day of week(plus offset) at startup. Else it is only set when the clock registers are written.

The set time routines are only used at startup to generate initial register contents from the system date plus the internal date time offset (-28 years by default) and Each time the clocks registers are written, a new offset is calculated. If there's an error (due to system date format problems or invalid BCD) the offset is set to -28 years and new time is system time -28. Invalid BCD is forced to 0. Invalid BCD is not incremented. Putting invalid BCD into registers will be messed up. But the emulator should not crash.

For instance. when you start the emulator, the clock registers are set according to system time, applying the saved offset, and using the century option. Then, when you run Vdos and input date and time, the registers are set by vdos, a new offset is calculated and will be saved at termination. The new time offset is calculated by subtracting the real date from the register calculated date which is calculated using the registers and the century otpion. 

Note... the time displayed in the status bar of the screen form, is not from the clock registers. It is calculated from the system date plus the offset. The registers will not be correct due to periodic timer restrictions (55 instead of 15 MS and lost interrupts).

note... eventually the softawre (vdos) must be fixed to be 2000 compliant. A century byte must be added to the CMOS. In 2028 things will fail if not fixed. Best to always set time to a date before 2000 until fixed. Until the software is fixed, you should NOT use century=20. Century option MUST match software's century.  Vdos date conversion routines require dates > 1980 and <2000.