Jump to content
IGNORED

Y2K bug and Atari software 2021


Recommended Posts

So is anyone else having much trouble with this?

 

Every machine I have has an RTC in it (Mega ST4, Mega STe, STacy, Falcon, etc)

 

However, while the Control panel shows the correct date and time, software doesn't

always want to seem to "grab" that.

 

Biggest example for me is BBS Express! ST. It shows the correct time and month but

the year is completely screwed up. It first started showing this problem when the year

rolled over from 1999 to 2000. Instead of showing "00" for the date it showed something

odd like ":0" (example). Each year since it's changed to something else.

 

For example, right now it's showing the date as "03/28/<1".

 

So to compensate, I simply updated all my scripts to remove any specifics regarding the

date, just using time and month and that worked out mostly okay. My scripts that do the

backups weekly and monthly are fine.

 

However, I'd just like to fix this for the sake of the caller records. Eventually, DarkForce is

going to hit the 1000 user limit. In the past, every 2-3 years, I'd use it's software to delete

anyone who hadn't called in that length of time. That won't work now though.

 

If I enter "delete from 01/01/15" as another example, it brings up every record.

 

As far as it goes, I can simply do a hand (manual) deletion of older records, but that would

be very tedious. SysOps have better things to do. :)

 

Anyway, any thoughts or suggestions appreciated.

 

Link to comment
Share on other sites

This with year 2K (in)compliance was present even by later computers and SW.

I was writing about how in TOS 1.xx they lowered year span from 100 years (what IKBD chip can with 2 BCD digits) to only 20 years - 1980-1999, by unnecessary starting year number by 80 instead 0, for IKBD chip only, then just could add that 1980 to what is read from it, so it would be fine until 2079 . Don't know how it goes exactly with Ricoh chip in Mega ST and other where it is built in or added. Probably good for some decades yet.

Then, usual SW is not ready for it, and that stays for my Copyacc program too. In big % of cases there is only 2 digit for year, what starts with 19, so people can type in year faster - 2 instead 4 keyboard presses ?

We can fix it in TOS, but that's not enough. All problematic SW need fix too - and that can be not simple. As we see, only 2 variable digits are provided for year, so changes in code are not enough. Changing screen/dialog layout is necessary, and that can be really hard, especially without sources of code.

 

Now, I'm thinking why this save on digits was so spread ?  People was too optimistic, watched too much Sci-Fi, and expected that in 2000 we all will travel for weekend to Mars. OK, those with not so good job only to Moon, and will have supersmart, supersmall computers which will think instead us, doing almost everything possible.  And most funny is that actually we are now somewhere there - at least in adverts ?

 

 

  • Like 1
  • Haha 1
Link to comment
Share on other sites

My STE shows 2021 as 2028 using the RTC built into the UltraSatan. I’m running the Clock control panel and have it request that I update the time and date at boot. I just need to tab to the date, type “1” and hit return. This corrects the time for TOS. My TOS version is 1.06. Haven’t got around to installing the new chips.

 

Edit: it’s more complex than above. If I run Sysinfo it shows the correct date. If I quit and run Sysinfo or check the control panel again the date is back to 2028. No idea what’s going on...

Edited by mdivancic
Link to comment
Share on other sites

On 3/29/2021 at 12:53 PM, 1200XL M.U.L.E. said:

For the few times I needed a date I would enter the year as “21” and I’m sure my ST thinks that means 1921. That’s ok because I don’t really care in my case if I end up with the incorrect day of the week. 

 

This works as far as the machine goes. I did put "21" in on my Mega ST, Mega STe, STacy, Falcon, etc,...

 

The Control panel accepts this just fine. However, the *software* involved does NOT accept "21". In my

case, BBS Express! ST shows "<1".

 

Is that a bit more clear? Thanks.

 

Link to comment
Share on other sites

I tried UltraSatan with my Mega STE and TOS 2.06 and 1.62 (fixed for MSTE) - really never used it for clock setting before. And it works fine, without control panel. Once set time it was correct in file stamps, which I created.  I turned it for  couple minutes (while changed TOS ROMs) and it kept time - despite no battery for Ricoh chip. And I did not run US_GETCL.PRG . Maybe some capacitor kept power for that short time for Ricoh chip.

Next test should be with machine without Ricoh chip, since then time goes to IKBD chip, and there is not smart code for that in TOS (as explained) . But I have only  Mega ST alive now.

 

Anyway, diverse SW is main problem here, and that's old problem, now over 2 decades.

Link to comment
Share on other sites

Right. BBS Express! ST was released into the public domain quite some time back

by Rich Sanchez and is no longer supported. Unfortunately, that's the case with

too many software titles.

 

I can work around the problem. As mentioned, I've done that ever since 2000, and

honestly, I would have been a little surprised if an easy fix would have been posted.

 

But...the Atari community is the *best* place, IMHO, to reach out for help so I thought

I'd give it a shot.  :)

 

Thanks everyone.

 

Link to comment
Share on other sites

Darklord, did this year error only start happening once 2021 came?  My Atari ST's RTC wouldn't let me enter a year past a certain date (this was two decades ago so I don't remember exactly what year but it was some time between 1999-2001) so I set it to 11:59pm on December 31st and let it roll over naturally and then I just kept increasing the month and day until I got it to the correct year.  If 2020 shows properly, what happens when you set it to New Year's Eve and let it roll over?

 

I no longer have to worry about the internal clock, my TT now grabs the time and date from the WIFI upon bootup thanks to the internal CosmosEx.

Link to comment
Share on other sites

13 hours ago, MasterMotorola said:

Darklord, did this year error only start happening once 2021 came?  My Atari ST's RTC wouldn't let me enter a year past a certain date (this was two decades ago so I don't remember exactly what year but it was some time between 1999-2001) so I set it to 11:59pm on December 31st and let it roll over naturally and then I just kept increasing the month and day until I got it to the correct year.  If 2020 shows properly, what happens when you set it to New Year's Eve and let it roll over?

 

I no longer have to worry about the internal clock, my TT now grabs the time and date from the WIFI upon bootup thanks to the internal CosmosEx.

No - the error with the BBS software started after 2000 - the year display is all wrong.  The 1st digit is incorrect.  The cause of the issue is evident when looking at an ASCII chart.  It went from 9 to : (for 2000) then ;(for 2010) then <(for 2020).  Makes sense because in ASCII, 9 is $39, : is $3A, ; is $3B, and < id $3C.  In 2030, BBS Express will display =.

Link to comment
Share on other sites

We can blame SW authors that they did not think enough ahead, and wrote code what was limited only up to end of 1999.

But why they should do it better, when OS - TOS was nothing better.

Here is example:

TOSno2Kc.thumb.png.dd39c73f5c85e9c4b3332f06614dc015.png

This screenshot was made with Steem 3.2 and H: as so called GEMDOS emulated logical drive - what means that filesystem functions are emulated by emulator, and some DIR on host OS (Windows here) is assigned as logical drive H: here. And of course it handles well years at 2000 - host OS and emulator.  I just created 2 directories NEWFOLD  - in A: , and in shown subdir on  H:  . Date stamp is OK in H: . Not OK on A: , since it was created  fully via TOS. And may guess which TOS version is it by date shown - yes, it is 1.04 , and when TOS reads for him invalid date from RTC (Ricoh) and KBD chip will just set TOS creation date as current time. Invalid is above year 1999, under 1980 . So, only 20 years span. Even they did not expect that some people will use it in 21st C. Probably thought that will use  some 64-bit super Atari with GB of RAM, CD recorder, 800 MHz CPU and even 4 ciphers assigned for current year !

Link to comment
Share on other sites

On 3/30/2021 at 11:07 PM, MasterMotorola said:

Darklord, did this year error only start happening once 2021 came?  My Atari ST's RTC wouldn't let me enter a year past a certain date (this was two decades ago so I don't remember exactly what year but it was some time between 1999-2001) so I set it to 11:59pm on December 31st and let it roll over naturally and then I just kept increasing the month and day until I got it to the correct year.  If 2020 shows properly, what happens when you set it to New Year's Eve and let it roll over?

 

I no longer have to worry about the internal clock, my TT now grabs the time and date from the WIFI upon bootup thanks to the internal CosmosEx.

 

Oh no, this started just as soon as 1999 rolled over to 2000...

 

(Keep in mind, I'm not talking about my Mega ST4 doing this.

It's the software...)

 

Since then, BBS Express! ST interprets the date like this:

 

2000 - :0
2001 - :1
2002 - :2
2003 - :3
2004 - :4
2005 - :5
2006 - :6
2007 - :7
2008 - :8
2009 - :9

 

2010 - ;0
2011 - ;1
2012 - ;2
2013 - ;3
2014 - ;4
2015 - ;5
2016 - ;6
2017 - ;7
2018 - ;8
2019 - ;9

 

2020 - <0
2021 - <1

 

Link to comment
Share on other sites

13 hours ago, Stephen said:

No - the error with the BBS software started after 2000 - the year display is all wrong.  The 1st digit is incorrect.  The cause of the issue is evident when looking at an ASCII chart.  It went from 9 to : (for 2000) then ;(for 2010) then <(for 2020).  Makes sense because in ASCII, 9 is $39, : is $3A, ; is $3B, and < id $3C.  In 2030, BBS Express will display =.

 

Stephen's got it.   :)

 

Link to comment
Share on other sites

  • 2 years later...
On 3/30/2021 at 6:58 PM, DarkLord said:

The Control panel accepts this just fine. However, the *software* involved does NOT accept "21". In my

case, BBS Express! ST shows "<1".

Sounds familiar. Do you know the programming language for BBS Express? I use HiSoft Basic a lot which has exactly the same problem with the DATE$ function. For instance, today is 12-27-20<3. As a workaround I use a Gemdos call to get the date which works fine.

Link to comment
Share on other sites

4 hours ago, robv said:

Sounds familiar. Do you know the programming language for BBS Express? I use HiSoft Basic a lot which has exactly the same problem with the DATE$ function. For instance, today is 12-27-20<3. As a workaround I use a Gemdos call to get the date which works fine.

 

Well, it is BBS Express! ST v1.98a, now released into the public domain (but not the source!).

 

From the manual (PDF):

 

"Express was originally written in OSS ICD Pascal by Keith Ledbetter in 1986 and released in 1987. Since that time it has been marketed by ICD Inc., T2 Ltd. and since July 1991 C&R Systems."

 

 

Link to comment
Share on other sites

13 hours ago, DarkLord said:

Well, it is BBS Express! ST v1.98a, now released into the public domain (but not the source!).

No source - it seems you will have to stick with your fix then. As I understand, you need to apply it every decade?
The solution I use in my programs (using Gemdos to get the date) is only slightly better. Just checked, it will work until 2099. Should we prepare the next generations of ST users for the Y2K100 bug? 😉

 

When I got my ST nobody told me the software would only work for just over a century. 😂

  • Like 1
  • Haha 1
Link to comment
Share on other sites

23 hours ago, DarkLord said:

"Express was originally written in OSS ICD Pascal by Keith Ledbetter in 1986 and released in 1987. Since that time it has been marketed by ICD Inc., T2 Ltd. and since July 1991 C&R Systems."

I find this very intriguing. I have Personal Pascal 2.02 (1987) published by OSS&CCD (?). I wrote a little prg that prints the date; nothing wrong: today is 12282023. They must have used a different version for BBS Express. What intrigues me the most is that HiSoft Basic 2.1 (1993) gives exactly the same error that you describe, but only when you use the BASIC statement DATE$ instead of the equivalent Gemdos call. For the decades, it takes the ASCII codes after "9" and goes on from there. 2000 is 20:0, 2010 is 20;0 and 2020 is 20<0. This only happens after 1999, I can't remember anything weird when 1989 turned into 1990. AFAIK, OSS Pascal was US based and HiSoft was based in the UK. Perhaps somehow the same guy did the coding?

All I can think of is that nobody thought the software would last more than a few years and didn't give a damn. Just like the Rolling Stones thought the band would only last a few years when they started in 1962. 😀

Link to comment
Share on other sites

On 12/28/2023 at 4:03 AM, robv said:

No source - it seems you will have to stick with your fix then. As I understand, you need to apply it every decade?
The solution I use in my programs (using Gemdos to get the date) is only slightly better. Just checked, it will work until 2099. Should we prepare the next generations of ST users for the Y2K100 bug? 😉

 

When I got my ST nobody told me the software would only work for just over a century. 😂

 

Why, the nerve - I'd tell them I want my money back...!  :)

 

  • Haha 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...