Y2K date fix for 2017?

[Fujiyama]

Which Y2K patch will work properly with 2017 dates?

I found a page called Dallas RTC sync + TOS Y2K fix where I also downloaded Dallas RTC 1.0 from, which should include a Y2K fix valid up to 2030, and according to the readme also works as a Y2K fix even if you don't have a Dallas clock in your ST. It's called DALLRTC.PRG and goes in the AUTO folder, but doesn't appear to work with my MegaSTe (TOS 2.06) -I just created a folder and its date is shown as "47-05-08" (I expected it to show 17-05-08 of course).

As my clock battery has died and I haven't bought a new (expensive) replacement battery (and also haven't decided if I should replace the clock altogether with a button-cell based RTC module to connect to my MonSTer board, or get some other, cheaper type 3.6V battery replacement) I put a program called DATE.PRG in the AUTO folder for now (sorry, can't remember where I downloaded it from) which is to be renamed by adding the year (i.e. DATE2017.PRG), so whenever I boot/reboot I'm asked to enter the current time and date. A nice and quick way to set the time and date if you don't have a battery-backed clock or like me, the battery is dead. But obviously, without a working Y2K fix it doesn't help for anything but the time of day.

Are there other Y2K fixes I could use that actually work?

[troed]

My fix works fine (The DallRTC program). Since it works by winding and rewinding the date with 30 years, you need to first set the date to 1987 _with the fix not loaded_. After that, put the fix in your auto or bootsector - the date will then become +30, that is, 2017.

(This works fine on both my own Mega STE and a friends. For those who have the Dallas RTC and don't use the control panel to set the date you can have the fix loaded when setting the date as well).

I should update that post with the info for non-Dallas use cases.

/Troed

[Fujiyama]

You're right -it works!
For some reason the time changed to 1989, but it might just be that some capacitor inside the ST (partly) kept the time between each power cycle when testing.

So for now, until I get a new battery (or clock module) I've got a time-setter program called TIME22.PRG in the AUTO folder (I don't know if DATE2017.PRG (DATE.PRG) to set the correct time and date was the reason for the above problems) to set the correct time/date, but with 1987 instead of 2017, then manually run DALLRTC.PRG (which will as you say, correct 1987 to 2017).
I also put LEDPANEL.PRG in the AUTO folder and configured it so it'll show the time and date in the upper right hand corner of the screen. Nice!
Things will get a little easier when the clock gets battery-backed up

Yes, please do add the correct procedure to the Readme file. Thanks.

[joska]

Are there other Y2K fixes I could use that actually work?

I've done a binary patch to TOS itself. Tested with 1.04, 1.06 and 2.06 on ST's with and without RTC. With this patch there is no need for any autofolder programs.

I don't remember the details now, but if there's any interest I can have a look at my notes tonight.

[Fujiyama]

Yes, definitely interested!
For TOS 2.06, have you added any other patches as well? Now that my MonSTer is working I'm ready to load TOS into its flash memory.

Troed: silly me... why make it complicated? I just put DALLRTC.PRG in the AUTO folder, so now (using AUTOSORT) I've rearranged it to first run TIME22.PRG followed by DALLRTC.PRG. When I get the clock battery (or new RTC module) I won't need TIME22.PRG.
I also made nice boot-floppy with the same programs with the addition of HDDRIVER.PRG (running first).

[joska]

Yes, definitely interested!

I actually found it in my dropbox

Code: Select all

/*

Y2K-patch for TOS 1.04, 1.06, 1.62 and 2.06
Jo Even Skarstein 2016 ->

Problem:
  GEMDOS and XBIOS epoch is 1980. The year-part in all
  dates is an offset from this.
  XBIOS use the keyboard clock to store date/time between
  reboots. This clock only handles two digit years, and
  TOS store the two least significant digits of the YEAR
  in this clock. Not the offset, but the actual year.
  Since the ST was made in 84/85, they simply added 80
  to the GEMDOS year before passing it to the keyboard.
  This works fine until year 2000. 00+80 is not 2000...
  Likewise when reading from the keyboard, GEMDOS year is
  keyboard year - 80. Does not work well after 2000.
  
  This fix simply removes the 80 offset, so the two least
  significant digits of the GEMDOS year is stored in the
  keyboard. This is good until 2080.
  
  Please note that this problem does not affect machines
  with an RTC, i.e. the Mega ST, Mega STE and Stacy. Applying
  this fix won't hurt, but won't be of any use on either of
  these machines.

*/

See attached archive. It contains two programs. y2ktest.prg sets both XBIOS and GEMDOS time to 1/1-2016 and then reads it back. Run this program without *any* y2k-related patches in your auto-folder. If both XBIOS and GEMDOS time reads back 1/1-2016, then your machine does not have the y2k-problem. If it reads back the wrong year, then run your TOS image through y2kpatch.ttp and flash the resulting "patched.img". Reboot to the patched TOS and run y2ktest.prg again.

Y2KPATCH.zip

This patch was tested on 520STM (no RTC) with 1.04 and 2.06, STE (no RTC) with 1.06, 1.62 and 2.06 and Mega ST (RTC) with 1.04 and 2.06. Please note that when I say "RTC" I mean the stock Atari RTC as used in the Mega, Mega STE and Stacy.

For TOS 2.06, have you added any other patches as well? Now that my MonSTer is working I'm ready to load TOS into its flash memory.

I have an unreleased version of the flash-tool that can do some simple TOS patches when flashing TOS. The Y2K-fix is one of them. It can also replace the boot-logo in 2.06 with a user-defined image (PI3 file).

[joska]

As my clock battery has died and I haven't bought a new (expensive) replacement battery (and also haven't decided if I should replace the clock altogether with a button-cell based RTC module to connect to my MonSTer board, or get some other, cheaper type 3.6V battery replacement) I put a program called DATE.PRG in the AUTO folder for now (sorry, can't remember where I downloaded it from) which is to be renamed by adding the year (i.e. DATE2017.PRG), so whenever I boot/reboot I'm asked to enter the current time and date. A nice and quick way to set the time and date if you don't have a battery-backed clock or like me, the battery is dead. But obviously, without a working Y2K fix it doesn't help for anything but the time of day.

Even with a dead RTC battery your Mega STE should not suffer from the Y2K-problem. The IKBD clock is not used by TOS on the Mega STE. I think it's your time setting tool that fools you here.

[Fujiyama]

Yes, definitely interested!

See attached archive. It contains two programs. y2ktest.prg sets both XBIOS and GEMDOS time to 1/1-2016 and then reads it back. Run this program without *any* y2k-related patches in your auto-folder. If both XBIOS and GEMDOS time reads back 1/1-2016, then your machine does not have the y2k-problem. If it reads back the wrong year, then run your TOS image through y2kpatch.ttp and flash the resulting "patched.img". Reboot to the patched TOS and run y2ktest.prg again.

You're right! With a working Mega STe I tried it there (with no Y2K related software) and both XBIOS and GEMDOS values show the same right after powering up the computer. But If I set the date/time (using the Xcontrol accessory) the first line "Get XBIOS date" differs, showing the actual year/month/day instead of just 2016, 1, 1. If I run "Y2KTEST.PRG" again it's reset to 2016, 1, 1 like the rest.

With the DS3231-based RTC module attached to the MonSTer (its battery is a standard coin cell which is cheaper to replace than the lithium battery of the Mega STe clock) the result is a little different. After powering up the computer all the values of Y2KTEST.PRG are the same (2016, 1, 1) except for the first line which shows:

GET XBIOS DATE: 1980 + >14< = 1994, month = 1, day = 1

But it appears to work fine. I've set the date/time with XCONTROL.ACC, turned off the computer for a while and the time has been shown correctly when powering up again. The date/time stamp of creating some new folders also looks fine.
UPDATE: I had powered turned off for about 5 minutes but when booting up the date had changed to 00-09-95 while the clock had no relation with the current time (it showed 15:11). The clock battery is brand new, so this is strange.
Could it be due to a conflict between the internal Mega STe clock and the RTC module attached to the MonSTer, or more likely something else?
I almost forgot that there's a MonSTer RTC program for setting the date/time, which I didn't try for this. Is this a special time-setter which differs from setting the time with say the Xcontrol accessory as it handles specifically those RTC modules, and no other software should be used for that, or are they all the same?
I'll look further into the pullup resistors discussed in that other thread, though for another RTC module.

When I figure that out, next is getting the STe out and trying out the clock there as well (I have a battery-backed clock board from way back in the early 90s plugged into one of the TOS EPROM sockets, with the TOS chip on top of it). From what I understand things won't go that smoothly there though.

For TOS 2.06, have you added any other patches as well? Now that my MonSTer is working I'm ready to load TOS into its flash memory.

I have an unreleased version of the flash-tool that can do some simple TOS patches when flashing TOS. The Y2K-fix is one of them. It can also replace the boot-logo in 2.06 with a user-defined image (PI3 file).

Will this flash tool be released soon, replacing the existing MonSTer download?
I have yet to try flashing the board with TOS. Currently I'm still using the two EPROMs on the motherboard for TOS (the "FLASHON" jumper on the MonSTer board is in place/enabled).

[tzok]

I've discovered some interesting facts about the IKBD clock while working on my pass-through IKBD clock replacement.
First of all - IKBD uses a proper BCD (de)coding routines, and thus ignores any half-bytes higher than 9. It may be used to set a time only, without altering a date or vice versa - you only need to send 0xAA or 0xFF as a fields you don't want to alter. On the other hand, TOS has a "dumb" BCD (de)coing routines, which do not do any range checking. Atari programmers were clearly aware of that fact, as the Control Panel is smart enough to add 0xA0 (100 in a "dumb" BCD) to years lower than 80. So if you set year 18 it will actually send 0xB8 to IKBD. IKBD obviously will ignore that entry. But the best part is - when you substitute IKBD response with your own, then year 0xB8 is perfectly fine, and TOS correctly translates it to TOS-year 38 (38 years after the 1980) and all date calculation routines work just fine with this!

One drawback is the STe TOS doesn't query IKBD clock after reset. It will actually do it only with STE_FIX.PRG in the AUTO folder. It does work with TOS 1.06 and 1.62 (despite is says that it is not required for this TOS version). Only TOS 2.06 correctly handles IKBD clock without any additional software. On ST TOS STE_FIX doesn't do anything, and I don't know the way to sync TOS clock with IKBD clock on ST machines.

***

Actually I've found a way to sync TOS time with IKBD on ST - old ST Control Panel does that (in contrary to the STe Control Panel and XControl).

[Frank B]

Looks like I'll need to modify the ultrasatan clock save utility to allow dates < 2000. With this and Troed's patch will this fix the time stamp problems on tos 1.x ?

[joska]

I almost forgot that there's a MonSTer RTC program for setting the date/time, which I didn't try for this. Is this a special time-setter which differs from setting the time with say the Xcontrol accessory as it handles specifically those RTC modules, and no other software should be used for that, or are they all the same?

Sorry, I did not see this when you posted it last year...

Yes, with TOS the MonSTEr RTC can *only* be set with the MonSTEr RTC "driver" (run it from the desktop). XBIOS is not patched in any way, so if you try to set the time with other applications/CPX/accessories it will be forgotten when you reboot. I had a binary patch for 2.06 in mind but that is way down on my priority list.

EmuTOS OTOH has full support for the MonSTEr RTC, so no special program/driver is needed in that case.

[Frank B]

This worked for me.
1) Modify the ultrasatan set and get clock to handle dates < 2000.
2) Set the date to 1988
3) Use Troed's RTC Dallas patch.

The computer now has the correct date with TOS 1.6

Prebuilt usatan clock binaries here https://www.dropbox.com/s/h9pfpj00fwa76 ... k.zip?dl=0 along with the source that I modified.

[tzok]

Some time ago I have described, that TOS handles date correctly until year 2027 without ANY modifications. It holds years since 1900 in binary value on 7 bits. I've been interfacing an RTC through IKBD. The stock Atari Control Panel tries to send a year value of $B8 for 2018 (it is 118 in "pseudo" BCD), and also TOS correctly reads such overflown-BCD values from IKBD. Yet original IKBD would ignore any field that is greater than $99 and also would never send such value in response, but that's not a big deal.

***

Actually TOS holds year on 7 bits, but since 1980, not 1900, so the limitation for my RTC is year 2059 (which is 0xF9). I also haven't tried sending 0xFA, 0xFB... but I guess it would work too.