Mac OS 9 Lives

Classic Mac OS Hardware => General Hardware Discussions => Topic started by: MacTron on November 21, 2015, 05:52:43 AM

Title: The 2040 issue.
Post by: MacTron on November 21, 2015, 05:52:43 AM
Apple picked 1/1/1904 as its base, time zero. All time was stored internally relative to that date. But Apple didn’t store it as so many days, months, and years after the base; instead, the Mac tracked seconds since time zero usig a 32 bit number.

The 68k Macintosh will be able to count seconds until 6:28 a.m. on February 6, 2040. Better yet, every Power Macintosh ever built, since they use an even larger number, can count the seconds from time zero until sometime in A.D. 29,940.
However, even the Mac isn’t quite perfect. In older versions of the Mac OS, the Date & Time control panel only lets you set dates from 1/1/1920 through 12/31/2019. In new versions of the Mac OS, the Date & Time control panel lets you set dates from 1/1/1904 through 2/5/2040. 

According Geoff Duncan:
If your computer is running system software released in the last decade System 6.X through Mac OS 8.6 it can handle dates from 30,081 B.C. to A.D. 29,940  :o

http://www.macworld.com/article/1015346/y2k.html

Confusing info, as always ...

But the issue isn't in to the Date & Time control panel IMHO, but into the System, because I have restarted without any extension or control panel and system couldn't pass 6:28:14 a.m. on February 6, 2040 anyway.


Title: Re: The 2040 issue.
Post by: nanopico on November 21, 2015, 06:37:03 AM
According Geoff Duncan:
If your computer is running system software released in the last decade System 6.X through Mac OS 8.6 it can handle dates from 30,081 B.C. to A.D. 29,940  :o

This is really the most confusing part.  This statement is true when you call any of the api functions to convert, manipulate, compare dates that don't involve the system date/time.
Apple used this fact to say that it could handle such a large range and just kind of skipped over the system date/time info.

I know that linux/unix and os x doe the exact same thing for setting the system date.  Only difference is that their zero time (or usually referred to as the epoch) is some where int he 1970's or newer.  Why apple ever chose 1904 is beyond me for their epoch.

Title: Re: The 2040 issue.
Post by: MacTron on November 21, 2015, 06:45:08 AM
I know that linux/unix and os x doe the exact same thing for setting the system date.  Only difference is that their zero time (or usually referred to as the epoch) is some where int he 1970's or newer.

... and they use a signed 32 bits number.

Quote
Why apple ever chose 1904 is beyond me for their epoch.

"... in part because it's mathematically convenient to have a calendar system start on a leap year"

http://lowendmac.com/lab/04/0115.html
Title: Re: The 2040 issue.
Post by: nanopico on November 21, 2015, 07:07:03 AM
Make's sense to pick a leap year, but why not something more realistic like 1972, 1976.  They could have also used 1980, but considering the macintosh project start in 1979 and it in part was influenced/contained some parts of the Lisa which started in 1978 I could see using '76 for the year at least for system time.  As at the time there really was no practical reason to set your system clock to a date less than the current date.

In all seriousness though the whole subject is just fascinating to me really.

To fix it you can do one of two things. (if there are more then awesome.)
Change the epoch it uses to calculate the date. That will buy you 137 years. Trouble with that is than any system calls that do calculations that depend on the epoch date will need to be thoroughly tested for correctness.

The other way is a little trickier.  Add a counter stored on disk in say preference file or something, that counts the number of times the real time clock that provides the 32 bit value for calculating. You would have to detect the difference between a roll over and the pram just resetting, but you could put some rules in that guess at that with fairly descent accuracy.
Then you update/patch all call to get the seconds from epoch to accept a 64 bit unsigned int that would be the current 32 bit int value multiplied by the number of role overs that have occurred.  In theory all other date/time function would remain the same so it wouldn't be as important to test them, but they sure should be.
Title: Re: The 2040 issue.
Post by: MacTron on November 21, 2015, 10:49:22 AM
Change the epoch it uses to calculate the date. That will buy you 137 years. Trouble with that is than any system calls that do calculations that depend on the epoch date will need to be thoroughly tested for correctness.

This method that's what I first thought that can solve the issue... but actually we don't know what kind of side effects can have, and where to find the epoch data to be changed ...

Quote
The other way is a little trickier.  Add a counter stored on disk in say preference file or something, that counts the number of times the real time clock that provides the 32 bit value for calculating. You would have to detect the difference between a roll over and the pram just resetting, but you could put some rules in that guess at that with fairly descent accuracy.
Then you update/patch all call to get the seconds from epoch to accept a 64 bit unsigned int that would be the current 32 bit int value multiplied by the number of role overs that have occurred.  In theory all other date/time function would remain the same so it wouldn't be as important to test them, but they sure should be.

Sorry, I don't fully understand this ... may be my low English skills  :'( ...
Title: Re: The 2040 issue.
Post by: IIO on November 21, 2015, 02:46:48 PM
there is one thing which i dont understand.

when you turn internet time sync on, swatch internet time is not received as a stupid 32 bit number of seconds (what a weird idea!) but as 1/1000 day.
so with a 1/1000 day clock you can express many thousands of years with a 32 bit float.

so i believe that it should be possible to get the right day and hour in 2041, too.

i am just not sure about minutes i.e. if the internal clock will be able to run when it is "full" and can count no more. (if that is what happens, one could on the one hand set the year value 100 years back so that the clock runs again - but that means otoh you are no longer able to update with internet time - until you hack either the internet time sync extension or the date and time cdev.)
Title: Re: The 2040 issue.
Post by: nanopico on November 21, 2015, 07:35:35 PM
there is one thing which i dont understand.

when you turn internet time sync on, swatch internet time is not received as a stupid 32 bit number of seconds (what a weird idea!) but as 1/1000 day.
so with a 1/1000 day clock you can express many thousands of years with a 32 bit float.

so i believe that it should be possible to get the right day and hour in 2041, too.

i am just not sure about minutes i.e. if the internal clock will be able to run when it is "full" and can count no more. (if that is what happens, one could on the one hand set the year value 100 years back so that the clock runs again - but that means otoh you are no longer able to update with internet time - until you hack either the internet time sync extension or the date and time cdev.)

Generally a hardware real time clock that reports an unsigned integer of any kind will just loop. It just keeps counting and incrementing it's value.  When it's full it overflows back to 0 and just keeps going.
For the network time protocol that is used, it is a 64 bit number.  One part is for the seconds and one is for fractions of a second (so that you can have synchronization between two devices that is very accurate).  NTP also has a limit of of 137 years, but it's epoch is actually 1900, so if your using network time with a mac you'll actually start to have issues in 2036.

Change the epoch it uses to calculate the date. That will buy you 137 years. Trouble with that is than any system calls that do calculations that depend on the epoch date will need to be thoroughly tested for correctness.

This method that's what I first thought that can solve the issue... but actually we don't know what kind of side effects can have, and where to find the epoch data to be changed ...

The side effects of any change are unknown and would require extensive testing.
Finding the epoch is time consuming, but not all that difficult.  I belive that while I was reading Inside Macintosh, it stated that the Operating system queries the real time clock once per second and updates the system date time.  You can poke through the assembly code (thus the time consuming part) until you find that query and then look at the code around it to find the data section it compares the query results to, then epoch found.
I think the Date Time control panel set the real time clock as well.  When you set a date in the control panel it calculates the number of seconds from the epoch and tells the real time clock to start counting from that number.  So the control panel would also have info about where the epoch is stored. Who knows how many places it's located at though.


Quote
The other way is a little trickier.  Add a counter stored on disk in say preference file or something, that counts the number of times the real time clock that provides the 32 bit value for calculating. You would have to detect the difference between a roll over and the pram just resetting, but you could put some rules in that guess at that with fairly descent accuracy.
Then you update/patch all call to get the seconds from epoch to accept a 64 bit unsigned int that would be the current 32 bit int value multiplied by the number of role overs that have occurred.  In theory all other date/time function would remain the same so it wouldn't be as important to test them, but they sure should be.

Sorry, I don't fully understand this ... may be my low English skills  :'( ...

Yeah I just re-read that too.  It doesn't make a whole lot of sense.  Let me try again.
Update the Date Time calculations to check the RTC and a value stored on disc.  This value would be the number of times the RTC has overflowed.  (so it reached it's end and started at zero).  Multiple the two numbers together, calculate the date based on that new number and bam, you actually won't really ever have to worry about the date time ever running out.

Title: Re: The 2040 issue.
Post by: IIO on November 23, 2015, 07:06:41 AM
NTP also has a limit of of 137 years, but it's epoch is actually 1900, so if your using network time with a mac you'll actually start to have issues in 2036.

oh right, MacOS 8 were using NTP, sorry, i thought we are talking about swatch beats.

there might be two different methods how other applications are getting time from the system, it could be the actual 32 it value - then we have a problem - or it could be something like YYYY:MM:HH:MM:SS:Z, where only two bytes would be enough to last until the year of 9999.
Title: Re: The 2040 issue.
Post by: nanopico on November 23, 2015, 07:15:36 AM
In NTP 4 it has been proposed to move to 128 bit (64 for the seconds since epoch and 64 for the fraction of the second your in.
There is Also support for Era and Era offset which would help define the epoch and define how many times the time stamp has rolled over so you really won't ever have an issue with dates again.  But that version isn't finalized yet.  Implementing it in OS 9 for network time would help, and what ever code is used for network time could be patched into the system for when your not on network time.
Title: Re: The 2040 issue.
Post by: nanopico on December 12, 2015, 08:06:24 PM
Here's one thing OS 9 has over os x.   The epoch for OS X is in 1902 instead of 1904.  So the clock in OS X will run out in 2037. 
I find this amusing.
Title: Re: The 2040 issue.
Post by: nanopico on December 16, 2015, 06:36:44 AM
A patch for the year 2040 issue will be sort of interesting as files have their modified and creation dates stored as the 32bit unsigned int returned by the real time clock.  The dates you see displayed are calculated when you view them.
So any implementation will have to account for that, but I have some ideas on how to handle it. 

Also this would probably affect any software that has a timed demo period (like 30 days or what not), but at this point I don't think I even care about that as most of that software has already been cracked and there really isn't much new stuff out there if any doing this sort of thing in OS 9.
Title: Re: The 2040 issue.
Post by: Texas_RangerAT on July 15, 2016, 04:31:47 PM
Are you sure the epoch is 1904 for all macs and OS versions? I'm asking because I know there are Mac models that will reset the date to 1956 rather than 1904 if the PRAM battery is flat! Might even be all PPCs, I'd have to check that starting with a 7100 and maybe throw in a late 68k machine (Performa 630) just for fun if the 7100 already goes to 1956.
Title: Re: The 2040 issue.
Post by: nanopico on July 16, 2016, 06:02:29 AM
The OS uses the 1904 date.  As the ROM is a big part of it, it is possible that some ROM's don't reset to that date, but the date is still calculated off the 1904 date.  All your created/modified dates on files are based on that date, all code fragments in resources have a creation time stamp based on that date, everything is based around that date. It is not a hardware limitation as there are many ways to work around it, but as it's embedded in pretty much everything, a solution to the entire system is complex so as not to break existing functionality/programs that rely on that.
Title: Re: The 2040 issue.
Post by: Texas_RangerAT on July 18, 2016, 06:30:26 AM
OK, that makes sense!

Some newer computers even go to 1970 when the battery dies, pity the OS doesn't recognise that - if it did I suppose fixing the issue would be much easier.
Title: Re: The 2040 issue.
Post by: nanopico on September 22, 2016, 09:09:55 AM
Just wanted to update this a bit.  (Some of this has been said, but I'm thinking out loud and getting it all together).

So the year 1904 was chosen not only because it is a leap year and it's easier to calculate the date when the epoch starts on a leap year, but also because the max value of an unsigned int used as the number of seconds since 1904-1-1 at midnight  will sit in a date range where a leap year will occur every four years so the algorithm is very small and easy to calculate the date.  This was extremely important on the first Mac since all sort of stuff was placed in the ROM. 
The whole thing was kept for two reasons. One - backwards compatibility. Two - It worked so don't change it. 

After looking at some thing related to files/disk/volumes/partitions I realized that changing the epoch will also require changes to the code to calculate the date, though if the epoch is set to 1959-10-1 at midnight we can easily get to 2099 without changing the algorithm. The device manager and file managers will have to be updated to not freak out when they encounter strange dates.

Disks and volumes both contain fields in their header for the date of last backup.  Most backup programs utilize this. Depending on how they use this value, then they will become unreliable and things will not get backed up properly.

Files contain a creation and modification date.  This will no longer be accurate on non-patched systems, which again can cause issues with some programs that check that information.

AFP would need to be updated as well for network shares. 

All in all there will be a lot of areas to patch and compensate for.  It will be a massive undertaking, most of which will be in testing and verification of applications.

So having said that, I will not be attempting any patching to fix this issue at this time.  I may re-look at it in the future (before 2040), but for now don't count on any fix from me. Maybe someone else will want to take a stab at it.

Title: Re: The 2040 issue.
Post by: darthnVader on April 29, 2018, 05:55:26 AM
Not sure what event 1904 represents, Apple is funny, when you think about it, the Apple with a bite taken out of it, is, of course, a reference to the fruit of the tree of knowledge.( Even tho that was a fig, it's most commonly depicted as an Apple ).


So 1904, must hold some deeper meaning, but I have no clue what that would be.

Title: Re: The 2040 issue.
Post by: IIO on April 29, 2018, 06:22:37 AM
beside the unknown origin there is another weird bit. the mac does not start counting the date from 0 but only from 1, so it does not know about the 1.january.

that is a common problem for excel users, who always have to decide if they want to use the 1.1.1900 or the 2.1.1904 as reference - or convert between them.
Title: Re: The 2040 issue.
Post by: OS923 on June 25, 2018, 04:25:07 AM
On https://68kmla.org/forums/index.php?/topic/28814-writing-a-system-extension/ they wrote:

Quote
Since my last post I've also put some thought into it, I hate the idea of screwing up the timestamps on everything so I was actually leaning toward reusing some of the dates prior to 1984 since it's impossible for any timestamps to actually occur before the mac itself.
 
The Gregorian Calendar repeats itself every 28 years, so it might be easiest to simply set the clock back to the earliest compatible calendar year prior to 1984, and then hack the display routines to add however many years to the system year to make it display the current year whenever it encounters a date that occurs before 1984.
 
Depending on if it's possible to override system routines with an extension, I believe the routines in question would be DateToSeconds() and SecondsToDate()
That's the correct approach.

They replied:
Quote
Attemting to change the interpretation of timestamps is going to be an extremely painful exercise. You can patch the system software, but then there will be piles of applications that decide to handle dates and times themselves. Either fully or partially and in all combinations. It will be a complete disaster.
The date time toolbox calls are very old. I think that most programmers know those calls and would find it silly to do their own calculation if they store their date and time as UInt32.

Patching DateToSeconds and SecondsToDate is the solution.

Has anyone ever seen source code of a working extension that patches DateToSeconds and/or SecondsToDate? The old names are Date2Secs and Secs2Date. They are 68K one word inlines, TB calls, not OS calls.
Title: Re: The 2040 issue.
Post by: IIO on June 25, 2018, 06:30:05 AM
that is what i also would suspect; if you actually hack everything system time - but not how it is displayed, it will cause trouble for 500 apps. but if you hack both the system time and also how it is displayed, it will cause trouble for 500 other apps.
the only thing what is easy is to set internet sychronisation to off by default and remove the ioption to turn it on again from the controlpanel. everything else is a mess.

Title: Re: The 2040 issue.
Post by: OS923 on June 27, 2018, 02:52:26 AM
Well, as a matter of fact, I've done it already on Sunday. I've set my clock beyond 2040 and I patched DateToSeconds and SecondsToDate. There's was one extension that couldn't take it (Energy Saver) and then when the desktop appeared Finder crashed. But it's a start.

So now I want to see how other people patch DateToSeconds and SecondsToDate and then maybe I'll see my mistake.
Title: Re: The 2040 issue.
Post by: OS923 on July 23, 2018, 02:20:05 AM
Solved.
Title: Re: The 2040 issue.
Post by: MacTron on July 23, 2018, 07:11:35 AM
Solved.
Great!
Can you please share the extension that fix this issue , attaching it to a post?
Title: Re: The 2040 issue.
Post by: DieHard on July 23, 2018, 11:38:03 AM
If will be available on a board here soon, for now, here is the link:

Pass: macos9lives
https://files.secureserver.net/0fUL0ehuuGJGbe
Title: Re: The 2040 issue.
Post by: part12studios on February 01, 2020, 08:59:49 AM
if the computer is offline we could just set the date to whatever right?  i mean i'll be amazed if any of these machine are still working in 20 years..  though not impossible..  if capacitors are changed and such its possible.  the oldest piece of music gear I have is my Akai S612 from 1984 and it's still in great shape and as far as i know it hasn't been serviced yet..  probably something i'll look into in this decade with various gear..   i had the caps changed on my Zoom 9030 (known issue they used bad caps) and my Amiga 1200 also got new caps 1991 era computer.. it was having power up issues.. but once caps were changed it powered up perfectly each time.  I sold that one but the one I still have got the same treatment but it hadn't shown signs of trouble yet. 
Title: Re: The 2040 issue.
Post by: IIO on February 02, 2020, 12:49:01 PM
one of the main problems with a wrong fake date is copy protection schemes. another is that you eventually at least want to have the time right, which is only possible via internet, which would also attempt to the date.

for now just trust OS923 that it is almost solved.
Title: Re: The 2040 issue.
Post by: Protools5LEGuy on February 03, 2020, 05:13:15 AM
Let´s see what linux folks had made to solve 2038 year bug on 32 bits systems

https://lkml.org/lkml/2020/1/29/355?anz=web (https://lkml.org/lkml/2020/1/29/355?anz=web)

Title: Re: The 2040 issue.
Post by: Protools5LEGuy on February 03, 2020, 05:14:06 AM
https://www.softzone.es/noticias/open-source/linux-56-efecto-2038/ (https://www.softzone.es/noticias/open-source/linux-56-efecto-2038/)
Title: Re: The 2040 issue.
Post by: Protools5LEGuy on May 02, 2020, 04:34:00 AM
http://basalgangster.macgui.com/RetroMacComputing/The_Long_View/Entries/2020/4/5_Macintosh_Y2020.html (http://basalgangster.macgui.com/RetroMacComputing/The_Long_View/Entries/2020/4/5_Macintosh_Y2020.html)

2020 issue on Mac OS 0.97 to Mac OS 8 solved

Quote
System version 9.x.

   System 9.0 was released in October, 1999, almost 9 months after the SuperBowl advertisement in which Apple bragged about being immune to things like the Y2k bug. Maybe at some time in the interim, somebody at Apple recognized the dishonesty in that commercial. Maybe not. For whatever reason, in System 9, the flags passed to ToggleDate by the ClockCDEF were altered in just the way we altered them above. System 9 is already patched. You can set the date however you like, within the limits of the Macintosh system clock. We are good to go till 2040.


Title: Re: The 2040 issue.
Post by: IIO on May 02, 2020, 07:58:00 PM

a guy in the fb group did the 2020 of 8.5 / 8.6 .

you´d basically patch the system file to match the OS9 version of it at a specific point.

System // data fork
change 3C608800 3863007E to 3C608000 3863007E

(scroll down)

http://basalgangster.macgui.com/RetroMacComputing/The_Long_View/Entries/2020/4/5_Macintosh_Y2020.html?fbclid=IwAR2WqSTAJi4b1R39fhC2uJMNlI65eEfoyk7Yc6wnTMNCrCoTQSoO2soP89I
Title: Re: The 2040 issue.
Post by: teroyk on August 28, 2020, 07:04:20 AM
Date and Time API Preliminary Documentation For Mac OS 9:
http://mirror.macintosharchive.org/gsehi.com/computing/software/macos/Media/PDF/TradMacDoc/ApplePublishingSistem/Programming/1999/Draft/Date_and_time.pdf

so Apple solved problem this way in 1999.
Title: Re: The 2040 issue.
Post by: bfcastello on May 08, 2022, 02:55:59 PM
Hi ppl

How to fix it for OS 9? Is there even a fix for that?
Title: Re: The 2040 issue.
Post by: bfcastello on November 13, 2022, 05:04:21 PM
Hi ppl

How to fix it for OS 9? Is there even a fix for that?

Hello? I know we're good to go on OS 9 till 2040, but can't we extend it a bit more on OS 9.2.2? even Windows 3.11 can go to something like 2090 :P
Title: Re: The 2040 issue.
Post by: smilesdavis on November 13, 2022, 05:15:43 PM
https://web.archive.org/web/20220311161607/http://mirror.macintosharchive.org/gsehi.com/computing/software/macos/Media/PDF/TradMacDoc/ApplePublishingSistem/Programming/1999/Draft/Date_and_time.pdf

love my 3.11 rig. dreaming of finding a Asus P5A. but im loving my P55T2P4.
Title: Re: The 2040 issue.
Post by: bfcastello on November 20, 2022, 11:42:20 AM

a guy in the fb group did the 2020 of 8.5 / 8.6 .

you´d basically patch the system file to match the OS9 version of it at a specific point.

System // data fork
change 3C608800 3863007E to 3C608000 3863007E

(scroll down)

http://basalgangster.macgui.com/RetroMacComputing/The_Long_View/Entries/2020/4/5_Macintosh_Y2020.html?fbclid=IwAR2WqSTAJi4b1R39fhC2uJMNlI65eEfoyk7Yc6wnTMNCrCoTQSoO2soP89I

Now we just need the same kind of sorcery to make OS 9 go beyond 2040 :P
Title: Re: The 2040 issue.
Post by: smilesdavis on November 20, 2022, 12:21:25 PM
by then its all emulation
Title: Re: The 2040 issue.
Post by: Roman323 on January 22, 2023, 08:06:15 PM

a guy in the fb group did the 2020 of 8.5 / 8.6 .

you´d basically patch the system file to match the OS9 version of it at a specific point.

System // data fork
change 3C608800 3863007E to 3C608000 3863007E

(scroll down)

http://basalgangster.macgui.com/RetroMacComputing/The_Long_View/Entries/2020/4/5_Macintosh_Y2020.html?fbclid=IwAR2WqSTAJi4b1R39fhC2uJMNlI65eEfoyk7Yc6wnTMNCrCoTQSoO2soP89I

Now we just need the same kind of sorcery to make OS 9 go beyond 2040 :P

Who knows if we will be around in 2040 ? I know I will be 30 years older and probably not around anymore to even see if Mac OS 9 will still be around. I suppose if someone can get the Classic MAC OS source code, its possible to change the date.
Title: Re: The 2040 issue.
Post by: IIO on January 23, 2023, 08:09:58 AM
Who knows if we will be around in 2040 ? I know I will be 30 years older


some would say it is 17 years.

the last 17 years went by quite fast, and i am afraid the next 17 will, too.

in 17 years we can break up all hacking groups and ask chatGTP´s grandchildren how to fix the 2040 date issue without the need of a forth decompiler, and we will hopefully also have 3D printers who can repair broken PSUs on the fly.
Title: Re: The 2040 issue.
Post by: DieHard on January 23, 2023, 08:24:08 AM
Quote
in 17 years we can break up all hacking groups and ask chatGTP´s grandchildren how to fix the 2040 date issue without the need of a forth decompiler

Yep... this is not far from the truth.  There are many programmers saving countless hours getting chatGTP to spitout code, and I think that is great... but when you ask it to write a rock song about "hot" women it gives you the lecture not to objectify women, so in 2040, there will be no sexy models, no anger, no inequality, no passion, and no need to write about anything.   What a fucking disaster... that they create an awesome AI as a tool, only to fuck it up with social justice.  It's just a matter of time that they prosecute people based on asking inappropriate questions.
Title: Re: The 2040 issue.
Post by: IIO on January 23, 2023, 08:45:19 AM
there will be two internets, one which only allows porn, racist comments and patriotic country music and one which forbids it. then you can choose between plague and cholera.

but did you know that 3 days ago (19.01.2023) was the day when marty mcfly and doc brown landed in the future in "back into the future?" it was a lie: there are no floating penny boards! :(
Title: Re: The 2040 issue.
Post by: AssortedSordid on April 03, 2023, 09:21:16 PM
Quote
in 17 years we can break up all hacking groups and ask chatGTP´s grandchildren how to fix the 2040 date issue without the need of a forth decompiler

Yep... this is not far from the truth.  There are many programmers saving countless hours getting chatGTP to spitout code, and I think that is great... but when you ask it to write a rock song about "hot" women it gives you the lecture not to objectify women, so in 2040, there will be no sexy models, no anger, no inequality, no passion, and no need to write about anything.   What a fucking disaster... that they create an awesome AI as a tool, only to fuck it up with social justice.  It's just a matter of time that they prosecute people based on asking inappropriate questions.

That’s why I like these old machines so much; not only the nostalgia but there’s no modern bullshit, only good times. Well, when your machine wants to play along, that is  :P