Re: Y2K Prodos or GS/OS Patch

[mfumu@alphalink.com.au (Bill Robbins)]

In article <20000128025100.16723.00000388@ng-fr1.aol.com>,
supertimer@aol.com (Supertimer) wrote:

>ProDOS is a different story.  I don't know the full story, but I think
>ProDOS 8 sometimes thinks 00 is either NO DATE or that 00 is
>before 99.

I believe that the ProDOS 8 problem is not a new one, not specifically
Y2K. If I remember correctly, it has to be patched every few (about six)
years to handle dates properly.  I thought I had instructions for a patch
to do this but I can't seem to find it at the moment....  Nope, just found
it.  Unfortunately, I don't seem to have saved the name of the individual
who made this post, or even whether it came through from Delphi or here. 
Many thanks to that person and please claim credit if you read this.
-----
A post on comp.sys.apple2 reminded me that the year look-up table in
ProDOS 8 expires periodically. Specifically, the look-up table in version
2.0.3 (the last version released by Apple) was only good through 1998.
1999 is here, of course...I don't know if this subject has been brought up
on Delphi, but if you're using a clock card in a IIe, your computer now
thinks it's 1993 again! 
Here's some of the text from a message I posted to comp.sys.apple2 on this
subject: 

ProDOS will need to be updated once every five or six years. Apple
released a version of ProDOS specifically to deal with this problem
happening once before, in 1992. I found a directory on my hard drive that
I'd forgotten about; it had a version "1.9A" of ProDOS that I had hacked
on New Year's '92 to get the clock to work right again (I was running a
BBS on my IIe at the time, so having the right date was important). ProDOS
8 v2.0.1, which fixed the problem, was released on 4 Mar 92 (I don't
recall if there was a v2.0 that was released earlier). 
Since ProDOS was designed with the Thunderclock (a clock card that didn't
keep track of the year at all) in mind, it used a look-up table to
determine the year. I haven't looked at the actual code, but I imagine it
uses the current Julian date mod 7 and the day of the week to index into
the table. I found the table in the then-current version of ProDOS and
changed it to cover a different range of years. 
Here's something I came up with on my own to figure the current year from
the current month, date, and day of the week. First, convert the month and
date to a single number. Add the date to the appropriate number from this
table: 

Jan=0 Jul=181
Feb=31   Aug=212
Mar=59   Sep=243
Apr=90   Oct=273
May=120  Nov=304
Jun=151  Dec=334
Divide this number by 7. Subtract from the remainder the day-of-week
number; the day-of-week number is a simple progression where Sunday is 0,
Monday is 1, and so on up to 6 for Saturday. If the difference is
positive, it's your offset into the look-up table. If it's negative, add 7
and use that as your offset into the look-up table. I'm guessing that the
Thunderclock driver inside ProDOS does something similar; I crunched the
numbers, and they agree with the tables I've found in different ProDOS
versions. 
I diff'd my "v1.9A" and the actual v1.9, which I had backed up on floppy.
The year table was at offset 0x3276-0x327C in both files. v1.9 had a table
to cover 1986 to 1991 (the decimal value of the last two digits of a year
is in each byte...the sequence from v1.8 is 0x5A (90), 0x59 (89), 0x58
(88), 0x58 (88), 0x57 (87), 0x56 (86), 0x5B (91). The revised table I put
together covered 1992 to 1996: 0x60 0x5F 0x5E 0x5D 0x5C 0x5C 0x60. In
v2.0.3 (the last version of ProDOS 8), the table lives at offset
0xF76-0xF7C and covers 1993 to 1998. Leap years appear twice in each
table, which is why they're only good for five or six years each instead
of seven.