FLEX Dates and Times

This page provides a detailed analysis of the past and present state of dates and times as used in the TSC 6809 FLEX (and similar SK*DOS) operating systems.

For dates, this is especially in regard to dates after 1999, since TSC designed the 8-bit Year field to only hold the lower 2 digits of a year. (You can read another brief analysis of Y2K and FLEX dates here.)

Time-of-day was/is usually not implemented in most FLEX systems, because TSC did not include a time field in FLEX directory entries, and because many/most FLEX systems did/do not have either a timer or a real-time-clock (RTC) to supply current time information.

FLEX Date

There are three main methods currently being used to encode values in the 8-bit Year field (at $CC10) in the FLEX System Date:

• only lower 2 digits of year entered at FLEX date prompt, stored as an unsigned 8-bit binary value:
  • 75..99 = 1975..1999  (offset from 1900)
  • 00..74 = 2000..2074  (offset from 2000)
  • one variation uses 77..99 and 00..76
  • advantages: no change required to FLEX date prompt, no changes needed to programs that only display a 2-digit year, supports dates to 2074
  • disadvantages: discontinuity, so doesn't sort properly, only supports dates to 2074, some unmodified programs incorrectly display values of 00..74 as 1900..1974 instead of 2000..2074
  • I will be using this date format on the ST-2900, at least for now, mainly because I am currently using Flexemu and its related dsktool and FLEXplorer tools to do all my software development for FLEX, and this method is the only date format Flexemu supports
• all 4 digits of year entered at FLEX date prompt, converted to an unsigned 16-bit value, but only the lower 8 bits stored in the Year field:
  • $B7..$CF / 183..207 = 1975..1999  (offset from 1792)
  • $D0..$FF / 208..255 = 2000..2047  (offset from 1792)
  • $00..$B6 /   0..182 = 2048..2230  (offset from 2048)
  • advantages: no change required to FLEX date prompt, supports dates to 2230
  • disadvantages: discontinuity, so doesn't sort properly, requires changes to all programs that display a date, dates of 2048+ unfortunately use the same values as dates of 2000+ in the first method
• all 4 digits of year entered at FLEX date prompt, but converted into and stored as an unsigned 8-bit binary offset from 1900:
  • 0..255 = 1900..2155  (offset from 1900)
  • advantages: no discontinuity, so sorts properly as-is, supports dates to 2155, encoding for 1975..1999 is identical to first method
  • disadvantages: requires changes to FLEX date prompt, requires changes to all programs that display a date
  • this method is used by NitrOS-9, refer to pp.60,62 in the Technical Reference Manual (1.1 MB)
  • I wish that TSC had implemented this method in the very beginning, or at least that the entire FLEX user community had selected to use only this method for years 2000+, but they didn't

Various combinations of 2 of these 3 methods are also possible:

• first method used for 1975..1999, third used for 2000..2155: no discontinuity
• first method used for 1975..2074, third used for 2075..2155: two discontinuities
• first method used for 1975..1999, second used for 2000..2122: two discontinuities

There might also be other date formats that I don't know about -- please contact me if you know of one.

However, the problem is that not everyone is using the same method. It is possible for programs that display or process dates to detect which method was used, but only for 1977..2047. This is because many encoded values outside of this date range can represent different years in different encoding methods. I created a preliminary version of a chart that shows this -- the boxes that are coloured yellow or red contain values that can be interpreted more than one way, so are ambiguous.

Another problem is that TSC's COPY program does not preserve the original date of file creation, but assigns the current date to the copy. This makes it almost impossible to determine if two copies of a file are the same, except by comparing them byte-for-byte, or calculating a checksum or CRC on both, then comparing these. Many years ago Bruno Puglia and Leo Taylor wrote an improved COPY program that does preserve file creation dates (and times), and also has many other useful features.

FLEX Time

Even though TSC didn't provide any field(s) in FLEX directory entries to store the time of file creation, several methods have been used, or are being proposed, to store this time. All of them use one or both of the bytes in a directory entry (at offsets $0C and $14) that are shown as "reserved for future system use" in the TSC FLEX Advanced Programmer's Manual:

• SK*DOS (and STAR-DOS):
  • time is stored in the second spare byte of the directory entry, and uses an unsigned 8-bit binary number to represent tenths of an hour since midnight: 0 = 0.0 = 00:00 to 239 = 23.9 = 23:54
  • advantages: uses only one byte, implemented almost 40 years ago
  • disadvantages: resolution is only 6 minutes, doesn't distinguish between "no time entered" and "the first 6 minutes after midnight"
  • SK*DOS provides the INTIME hook in the operating system that can be used by the TIMEADD overlay to install a clock routine (supporting several kinds of clock chips, at several I/O addresses)
  • one variation uses 240 to represent midnight instead of 0, to allow distinguishing between 0 = "no time entered" and 240 = "midnight"
  • another variation is to store a sequence number instead of an actual time, for those users whose system doesn't have a clock chip; the sequence number starts at 1 when the system is booted, and increments by 1 each time a new file is written; but with the number only using 8 bits, it might roll over to 0 if you write lots of files between system boots
  • STAR-DOS and SK*DOS were written by Peter A. Stark of Star-K Software Systems Corp.; SK*DOS is mostly compatible with FLEX
• Flexemu:
  • the hours (0..23) value is stored in the first spare byte, the minutes (0..59) value is stored in the second spare byte
  • advantages: simple, no encoding required
  • disadvantages: resolution is only 1 minute, uses both spare bytes, doesn't distinguish between "no time entered" and "the first minute after midnight" -- on the ST-2900 it will be handled by writing 00:01 for either 00:00 or 00:01
  • Flexemu is software by Wolfgang Schwotzer that emulates a 6809 running FLEX on Eltec Eurocom II V7 hardware;
    starting with v3.10 (May 2022) it supports file creation times -- but it wasn't fully implemented, so I added code to make it fully functional -- contact me if you would like to obtain my changes
  • I will be using this time format on the ST-2900, at least for now, mainly because I am currently using Flexemu to do all my software development for FLEX, and this is the only time format Flexemu (and its related dsktool and FLEXplorer tools) support
• MS-DOS/FAT:
  • a proposal has been floated to store FLEX file creation times using the MS-DOS/FAT file format, which is an unsigned 16-bit binary value divided into three bitfields, with the LSB stored in the first spare byte, and the MSB stored in the second spare byte:
    • 15..11: hours (0..23)
    • 10..5:  minutes (0..59)
    •  4..0:  seconds/2 (0..29 = 0..58)
  • advantages: resolution is 2 seconds (the best possible in 16 bits)
  • disadvantages: more complicated encoding and decoding, uses both spare bytes, does not distinguish between "no time entered" and "the first two seconds after midnight"
  • a variation, for those users whose system doesn't have a clock chip, is to have the user manually set the system time, even though it won't be automatically updated; each time the user runs the TIME ++ command it will increment the time by 2 seconds; files created soon after the system time was set would get times close to the actual time, while files created much later would have incorrect time, but still different, and in chronological sequence

There might also be other time formats that I don't know about -- please contact me if you know of one.

Almost all of the disk images I have seen have both of those "reserved" directory entry bytes set to $00 for all files. However, some SK*DOS disks do have a time entered for some files. I have heard that at least one system used one of those bytes for another purpose, but haven't seen an example yet.

Again, the problem is that not everyone is, or will be, using the same time encoding method. A few of the 65536 bit combinations are unique to one of these encoding methods, so the required decoding can be correctly determined. But most bit combinations are valid in two of the methods, and many even in all three (or five when including the sequence number variations), making it impossible to know for sure how to correctly decode them.

I have written a new DIR program that allows selecting which decoding methods to use for the file dates and times, or to show the actual raw binary values instead. It will also indicate if any value is incorrect for the currently selected decoding methods, or if the year value is ambiguous. Note that if both reserved bytes in a directory entry are $00, DIR will not display any time for that file, except in raw mode, as it assumes none was entered, even though that might not be the case, just that the encoding used values of $00/$00 to represent time at, or shortly after, midnight. (What, some programmers actually work on their computers after midnight?!)

I haven't yet verified whether the COPY program by Bruno Puglia and Leo Taylor preserves both of the "spare" bytes, or only the second one.

Fortunately, file time is most important for your own disks used on your own computer(s), where you have control over which date and time format to use, and where you might create several versions of a file on the same day. When disk images are given out to other people, or received from them, the file time is less important than the file date.

If you see anything on this page that needs to be corrected, or have additional information that I should include, or have any other comments, please let me know. I hope some of you found this page useful.

"FLEX" was a trademark of Technical System Consultants (TSC).
"SK*DOS" is a registered trademark of Star-K Software Systems Corp.
"MS-DOS" is a trademark of Microsoft Corp.

Use the Reload/Refresh button in your web browser (or Ctrl+F5 or Shift+Reload) to ensure you get the latest version of this page.
Last revised 2023-Jul-09 15:36 PDT.
Copyright 2022-2023 David C. Wiens.