FLEX Dates and Times

This page provides a detailed analysis of the past and present state of dates and times as used in the Technical System Consultants (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.


There are two main methods currently being used to encode values in the 8-bit Year field, plus a third possible method. The Year field is present in the FLEX System Date variable (at $CC10), in the File Creation Date in each directory entry (offset 27/$1B in FCB, offset 23/$17 in directory entry), and in the Volume Creation Date in the System Information Record (SIR, sector 00:03, at offset 37/$25). The encoding methods are:

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

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

However, a huge problem is that not everyone is using the same method. It is possible for programs that display or process dates to detect which of the three methods (mentioned above) 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 also has many other useful features.


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 12/$0C and 20/$14) that are shown as "reserved for future system use" in the TSC FLEX Advanced Programmer's Manual:

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 huge 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 six when including all variations), making it impossible to know for sure how to correctly decode them, unless you have documentation accompanying each disk to indicate the encoding used.

Another problem is that most versions of FLEX do not provide any "hook" to easily allow adding code to copy the current time into a file's FCB at file creation time. The new FLEX Plus 10TM version of 6809 FLEX does provide such a hook, that can be used for any of the time formats described above. 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), but its hook only supports using a single byte for the file time.

I have written a new DIR program that allows selecting which decoding methods to use for the 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, my new DIR program 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 at midnight?!)

I plan to also write a program that will convert all dates and times on a disk from one set of encoding methods to another. Of course that will require you to know for sure which encoding methods were used to create that disk, which will often not be the case.

I haven't yet verified whether the COPY program by Bruno Puglia and Leo Taylor preserves both of the "spare" bytes in each directory entry, 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 are 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).
"FLEX Plus 10" is a trademark of David C. Wiens, dba Sardis Technologies.
"SK*DOS" is a registered trademark of Star-K Software Systems Corp.
"MS-DOS" is a trademark of Microsoft Corp.

Last revised 2024-May-01 23:30 PDT.
Copyright 2022- David C. Wiens.

Home   FLEX Plus 10   Contact   Site mapNo JavaScript!