Y2K SpartaDOS Pro 3.3a?

[Dopeyman06]

Isn't SpartaDOS Pro 3.3a Y2K compliant?  The date is supposed to be Saturday 05/22/2021.

 

[+Nezgar]

You can try RealDOS & TDLINE2 (which is basically a newer version of SD 3.3), or the TDLINE from CTHTDL.... which I can't find at the moment....

 

Try TDLINE.LZH from http://www.mixinc.net/atari/download_a8/sdcom.htm

 

If you are running with U1MB or SIDE2, you can try this driver for the DS1305, which also calculates the day of week:

 

[flashjazzcat]

The driver does not use the weekday stored on the DS1305. You'll still need a patched TD line as well.

[Dopeyman06]

Apparently I was using the incorrect TDLINE.COM. I now have the correct one.  Also, this is through emulation (Atari800MacX 6.0.0).

 

Thank you guys for the input.

 

[+Nezgar]

12 minutes ago, Dopeyman06 said:

I now have the correct one.

Just for reference, which source yielded the "CTH Y2K" version?

[Dopeyman06]

52 minutes ago, Nezgar said:

Just for reference, which source yielded the "CTH Y2K" version?

I looked through a couple disk images that I had and I found it

[a8isa1]

SJCarden dropped me a note last night in chat (currently at ##atari channel on Freenode but the users are are likely moving 100% to Libera Chat). SJCarden probably intended the  message to be in response to this thread.

 

He said, "Please pas it along that TDline2 will work with sd2.2c,d,m sd3.3a,b,c,d all versions of RealDOS"

 

I'm pretty sure TDLINE2 has a fixed DOW function.   I don't use it myself because my DS1307/DS3231 non-driver conflicts with TDLINE2 and I can't code my way out of a paper bag.

 

-SteveS

[flashjazzcat]

1 hour ago, a8isa1 said:

I'm pretty sure TDLINE2 has a fixed DOW function.

Is that the one that's 7.5K in size?

 

EDIT: Well, after using exceptional Google-fu to find a copy (6.7K in size) and after it spammed the screen upon installation, it appears to work.

 

 

TDLINE2 raises MEMLO by about 750 bytes. I think a lightweight y2k-compliant TDLINE could be useful here, to complement the ULTD.SYS driver.

Edited yesterday at 04:06 PM by flashjazzcat

[itzmike]

Back in the good 'ol days of 19, I posted a fix I'd done to SpartadosX 4.22 to solve the same problem (back in the year 01).

Re-posting my fix even though there are MUCH better patches out there. 

 

I know the newer TDLINE 's from the Sparta update project do work much better. 

That being said, about 20 years ago I patched my TDLINE.com on SDX 4.22 and renamed it TDD.com and it worked fine for years following Y2K .

 

From Comp.Sys.Atari.8bit

Okay ... I want you to go to the archives and find a program called "Bedit.com"
by Bill Aycock I believe.

Next, pull a copy of TD.COM from your SDX cart (type car:td.com >>td.com)

Now, using Bedit, edit your TD.COM.  (R) reads the file into Bedit.

Go to byte 426 using the goto command (G).  This is the start of a 12 byte
table.  Increment the 12 bytes by 1.

e.g 00, 03, 03, 06, 01 becomes 01, 04, 04, 07, 02
the command is, =01 or what ever the required byte is.
 
Write the file to a disk (W) a name other than TD.COM (TDD.COM) .. and load it
insted of TD.COM when you next boot SDX ... you're day of the week is now
correct.

The existing 12 bytes will be:
00 03 03 06 01 04
06 02 05 00 03 05
followed by the days of the week first letter table
SSMTWTF

Hope this helps

[+Stephen]

52 minutes ago, itzmike said:

Back in the good 'ol days of 19, I posted a fix I'd done to SpartadosX 4.22 to solve the same problem (back in the year 01).

Re-posting my fix even though there are MUCH better patches out there.

 

Hope this helps

That's really cool - thanks for sharing.

[+Nezgar]

The perfectionist in me was a little disappointed that even though the date byte can be 0-255 and 99 = 1999, that the "fixed" TDline code didn't take 100 as 2000, but merely started over from 0 again... Technically, the year byte could have differentiated from 1900 all the way to 2155, and the weekday would have continued to calculate correctly, and my BBS wouldn't stop deleting inactive users because their last calls were 100 years in the future... But this way is probably for the best - otherwise all the other software starts showing garbage in the year field... semicolons, etc...