• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Getting rid of the 'Your clock is not set to the correct time' alert dialog after System 7 boots

dougg3

Well-known member
I have a video of it showing up on my Macintosh TV which I believe was running 7.6 at the time:


I'm also pretty sure it would still come up after I installed its original 7.1, but I don't have video proof. But I just did some digging and found the dialog inside of System Enabler 404, which goes with the Macintosh TV. See DITL resource -16502. It's also in System Enabler 403 which was the enabler for the Performa/LC 520/550, and System Enabler 401 for the Color Classic. So maybe in System 7.1 it only showed up on a few specific Mac models that had enablers?

The same DITL also shows up in my System 7.5.5 system file that I installed in Basilisk II, so at least we know the message is lurking there in the background on machines after 7.1. I wonder how it decides whether or not to show it. The message doesn't pop up on my IIci running 7.5.3. Maybe there's code that only shows it on specific models? This might be an interesting, yet obscure, mystery to solve with some disassembly...
 

dougg3

Well-known member
I agree, trying to delete the DITL and corresponding ALRT resource might be a first good step to try, although it's probably going to depend on how robust the code is that tries to display it. If that doesn't work, we could locate the spot in the code that displays the dialog and patch it out to a NOP or something.

I'm going to nerd out about this a bit. I spent a little bit of time in the Macintosh TV's system enabler and I believe I found the spot that finally asks to display the dialog. It looks like it's sending a command to the Egret to decide whether to show it.

1700677624736.png

I believe that based on the leaked ROM source defines, $110 represents
Code:
(pseudopkt<<8)+(RdBattery<<0)
. The comment in the leaked source about RdBattery says "Sense if battery was changed". So at least in the Mac TV, it's not actually looking at the date. It's asking the Egret if it detected the battery was changed. I think @joshc is right about the detection not being a comparison of the date/time...
 

LaPorta

Well-known member
How intriguing…how would the EGRET detect that, if it doesn’t have anything to compare with? How can you “detect” a loss of voltage if you don’t have voltage running anything?
 

dougg3

Well-known member
How intriguing…how would the EGRET detect that, if it doesn’t have anything to compare with? How can you “detect” a loss of voltage if you don’t have voltage running anything?

This is just a guess, but if I were tasked with implementing something like that in a microcontroller, I would probably go for something super simple like: when the EGRET first powers on, it knows "hey, nobody has set the date on me yet so the battery must have been changed" so it sets a flag in its SRAM. And then as soon as you set the date (or something like that) it clears the flag in SRAM. The flag would stay cleared until the next time the EGRET had to power on again. Since the EGRET stays powered as long as +5V trickle is present or the PRAM battery is still working, basically every time EGRET has to power up from scratch, it knows that the PRAM contents have been lost.
 

joshc

Well-known member
I can confirm I have been seeing the alert dialog on a Colour Classic running 7.1 with System Enabler 401. Had no idea this was a system specific/System Enabler thing, I always thought it was a 'standard' part of System 7.

Haven't had time yet to try any other tricks. I was starting to wonder if PRAM Auto-Restore would solve the problem actually.
 

dougg3

Well-known member
It seems like it might be worth a shot! For the sake of completeness, it looks like the LC 575/475 and 660av/840av enablers also include this alert dialog.

I don't want to derail the thread, but I thought I would mention an unrelated tidbit I discovered while looking through these enablers. They also include the dialog that pops up when you press the power key on the keyboard, asking if you're sure you want to shut down. I want to say that on my IIci, the keyboard power key didn't work for shutting it down in versions prior to System 7.5. That makes complete sense if the keyboard power key shutdown functionality was also provided by enablers in 7.1...
 

Arbee

Well-known member
Mac TV is Cuda rather than Egret, but that's not super important here. Let's allow everyone to figure this out.
 

Attachments

  • Cuda_Firmware_ERS_v0.02_199012.pdf
    1,021 KB · Views: 19
  • Cuda.src.txt
    282 KB · Views: 22

dougg3

Well-known member
Wow, this is pretty amazing to be able to look at, Arbee! Thanks! Also, thanks for correcting me on the Cuda/Egret distinction. You're absolutely right, I was calling it Egret because the trap is named _EgretDispatch and I wasn't thinking.

Looking at the Cuda source code shared above, it appears that my guess about how battery change detection works was pretty much correct. I just had the polarity of the flag backwards. Bit 4 of the SysFlag variable is called Battery. When the Cuda powers on (meaning, a PRAM battery gets inserted or the computer gets plugged into AC power), it zeros out the RAM in PowerUpMgr -- this includes the SysFlag variable. So the flag starts out at 0.

pBatterySense is the relevant handler for the command I showed above in my disassembly. If the Battery flag is 0, it returns a response indicating the Mac OS should show the "Your clock is not set to the correct time" messsage. If the flag is 1, the message won't appear.

The only way to set the flag to 1, and thus tell the Mac OS to stop showing the message at startup, is to write to the real-time clock. That's taken care of in the pWrRtc handler. As soon as that handler runs, the flag is 1 and the message will no longer pop up.

Edit: A fun tidbit from that ERS document: it refers to the LC as the Macintosh ][LC in two places. Interesting...
 
Last edited:
Top