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.
Home
FLEX Plus 10
Contact
Site map