OS9 L1 - Y2K

Some info on using Dragon/CoCo OS9 L1 in the 21st century.

OS9 (6809) Level 1 - Dragon/Coco

Issue

The OS9 kernel (modules os9p1 & os9p2) has no time or date functions built in. However, it does provide user configurable date & time 'stubs' which are implemented via the clock module:

System Calls: os9f$SetTime & os9f$GetTime
INPUT:        X = Address of time packet
OUTPUT:       Time is date set

Packet structure is as follows:
  0 : Year
  1 : Month
  2 : Day
  3 : Hours
  4 : Minutes
  5 : Seconds

The packet is 6 bytes wide and as such operates with 2 digit date codes. How these are interpreted when the year code is '00' is software dependent and generally the standard os9 utilities such as 'dir' don't make any assumptions about the leading two digits so for most part the 2 digit format is all that is displayed.

Non Y2K Compliant commandsThese are some common commands available under Dragon OS9 Level 1, V2.00 (Eurohard):

Date, assumes year is always 19xx, so 2000 is displayed as 1900.

mm (mailmerge, part of the Stylograph Word processing package), when the DATE variable is used with no options ie. date displayed in the form 'July 4, 1776', the year 2000 is translated into '190' ie. '5 January, 190'

Most other commands just display the 2 digit form ie. 05/01/00 which is acceptable. I didn't find anything which attempted to display the day of the week.

Clock module, Y2K roll over

The clock module shipped with Dragon OS9 does not handle the roll over to 2000, the year is deemed to be '100'. It can be manually reset to 00 if required. It will also not handle the leap year issue, mostly because year 00 is assumed to be 1900 which was not a leap year (2000 is).

Status

OS9 appears to be happily functioning okay this millennium, my RTC rolled over successfully, as I mentioned most date related functions only display the 2-digit format anyway. Most annoying is the 'date' (and the extended date display from 'mailmerge') function which insists it's 1900. I downloaded some Y2k 'fixed' modules from RTSI which do appear to work, however they represent '2000' by storing a value of '100' in the 'Year' field of the OS9 time packet. Whilst my RTC appears to store it okay, the data sheet does give a range 0-99 so it's not liable to be happy with it long term, plus of course short forms tend to be displaying nn/mm/100 so it's not an entire success. For the time being, I think it's worth putting up with it 'as is'. Might pursue it some point.

JRB, Feb 2000