• 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.

SetDate CDEV and Clones = shenanigans

jessenator

Well-known member
I know, we have probably 4 to 5 disparate threads regarding the 2020+ year issue with System 7, but I'm more interested to see if anyone has issues with their clone/MacOS Compatible machines. Thought about making this a thread in PCI PowerMac forum, but it's more software and might extend to NuBus clones, IDK...

I'm unable to use SetDate—bbraun's nice CDEV for enabling years up to 2040—on any of my clones. Works a treat on my SE/30 and Quadra 700, but I get strange errors trying to set them on my other Mac/Clone hardware.

Notably my 4400 and StarMax machines refuse to work. It's interesting though, because up until now they would just lock up when you entered the date and clicked the button (similar with my Power Computing machines as well*), but having just refreshed my 3xAAA holder PRAM battery on my StarMax 5000/225 I decided to give it another go. This time, it just shut the computer down—not a dialog box, not a system freeze, not a reboot, just ...off.

Anyone else with clones experience anything similar?

*my PowerTower (Catalyst/7200/8200 architecture derivative) would close the CDEV, not change the date and give me an error I can't recall when I tried clicking on any menu, eventually needing a forced reboot.

 

Crutch

Well-known member
That’s very weird, since all that cdev does is call the Toolbox trap _SetDateTime (after a little string processing).  I would be interested in knowing what could possibly cause that to break on a clone.  The Mac ToolBox, which should be running unmodified on the clones, supports dates up to 2040 inherently.

First of course, run your clone with extensions off and see if SetDate works normally — maybe something else is breaking it?  (Despite being a cdev, SetDate doesn’t do anything at INIT time so you can turn extensions off and it should still work normally ... there is in fact no real reason it’s a cdev at all instead of just a tiny utility application)

If you want to explore this, I would suggest installing Macsbug.  Open up the SetDate cdev normally.  Then drop into Macsbug by hitting the interrupt switch or pressing Cmd-Power.  Type “ATB _SetDateTime [Enter] G [Enter]”.  This will cause Macsbug to activate any time anyone calls _SetDateTime.  Then click the “Set” button.

If the third line from the bottom looks like “*_SetDateTime”, it means the cdev got all the way to right before calling _SetDateTime and is fine so far.  In that case, hit “T [Enter]” to step over that trap call and it would be interesting to see what happens next, maybe share a photo of the resulting Macsbug screen if you want (i.e., does it crash inside that trap call, or somewhere after)?

If you DON’T see “*_SetDateTime”, then the SetDate cdev is crashing somewhere before it actually tries to set the date ... i.e. it’s doing something else unrelated that your clones don’t like.  That would imply the clones support a 2020+ date just fine, as they should really.

 

jessenator

Well-known member
If you want to explore this, I would suggest installing Macsbug.
I'll give this a shot. It looks like v6.6.3 is the only PPC version (that I've found anyway…). Thanks for the detailed instructions, as well. I'll definitely try the extensions off method first.

Edit: I just tried extensions off and opening it up—it's no longer just shutting down the system, but nothing appears to happen, then after a few seconds the mouse freezes :/

I'll try MacsBug next.

 
Last edited by a moderator:

jessenator

Well-known member
Alright, here's what I got—sorry for phone photos, but I'd rather it be this than me not transcribing it properly:
VpD3mqd.jpg


Ignore the time I tried to use "exit" as a command… and trying to do the actual escape shell "ES" command got me:
Kq22PGu.jpg


Trying again to escape shell closed MacsBug and froze my cursor, but maybe it was already there…

 

jessenator

Well-known member
So just for kicks and talking over this on IRC, I tried it again…

J3fUqpJ.jpg


Different error this time?

I attempted to Step Over with the "T" command and got this:
ALkcEzl.jpg


Tried again to step over and then got this—which I'm assuming is bottom level failure causing a system crash?:
xoXSHEn.jpg


 

jessenator

Well-known member
Made a custom Extensions Manager set with JUST MacsBug enabled, and it gave me the same error (as the 1st attempt) on my 3rd attempt, BUT NOW it's giving me another new error than before on this 4th attempt:
 

Bus Error at FFC3CE7A _CommToolboxDispatch+0152A
while reading byte from 9E599E9A in Supervisor data space
_________________________________________________________
_CommToolboxDispatch
+0152A FFC3CE7A *MOVEA.L A3,A2
+0152C FFC3CE7C SUBA.L $000C(A4),A2
+01530 FFC3CE80 MOVEQ #$00,D0




attempting to step over or exit shell eventually got me back to the "Bowells" problem.

This might be a case where a more informed person would need my hardware in front of them… IDK.

 

Dog Cow

Well-known member
It's 32-bit dirty. It crashes my SE/30 running 7.5.3 when in 32-bit mode. I have to switch to 24-bit addressing, restart, then SetDate will work. It's definitely a slap job.

 

Fizzbinn

Well-known member
For what it’s worth I just tested SetDate on my 4400 with no issues. It’s my newest addition so I hadn’t had reason to yet since the regular Date & Time control panel NTP update had previous set the clock correctly. It’s running 9.1, has a working clock battery.

Are there multiple SetDate revisions? Get Info on the copy I ran says version 1.0 copyright 2011. 

 
Last edited by a moderator:

jessenator

Well-known member
 It’s running 9.1
Well, 9 doesn't have this issue, thankfully  :/  During brief flirtations with 9 on all of my clones, it had no problems setting the year to 2020. Not sure about 8.0-8.6—I was told once but have since forgotten. Specifically 7.6.1 (and lower) Date & Time will not set the year to 2020—the roll over from 2019 goes to 1920.

I am using the latest version of the CDEV from bbraun's site, which has a rev date of 2012 in the readme.

 

johnklos

Well-known member
I had issues with SetDate, too, on a Quadra 610. I noticed that when the date was wildly off, it would crash the system. When the date was close, it would work sometimes. Haven't found a definitive pattern.

 

jessenator

Well-known member
When the date was close, it would work sometimes.
I wondered about that very thing. No luck for me, unfortunately :/  

One other thing, I tried just opening MacsBug without doing anything, and EscapeShell just leads to a crash... I wonder if the LPX-40(50?) Tanzania II with its 50 MHz bus is causing issues.

I want to put the StarMax away and get the 4400 out and see with this fresh (3xAAA) PRAM battery and a fresh system install will let it work.

 

jessenator

Well-known member
Holy stupid...

After attempting it on the a fresh 7.5.3 install from the restore disc of the 4400, I was greeted with a similar type of error. Boo hoo.

Then I had a dumb hunch to try: because the common thread among some of the traps was  "_DateToSeconds" why not just simplify it by just setting the time to 00:00:00 on October 29, 2020—eliminate the extra conversion of seconds entirely. I had also set the date in Date & Time to 2018 before starting up with no extensions, save MacsBug, enabled

And it set the date to October 30, 2020...! No crashing, it just worked!

Then I got cocky and tried to open Date & Time (not touching the date at all) to adjust the time and its reset to 1920...

I can't get it to go back to 2020 using the same techniques. With macsbug only (no extensions) it now crashes... BLARG.

 
Last edited by a moderator:

Crutch

Well-known member
It's 32-bit dirty. It crashes my SE/30 running 7.5.3 when in 32-bit mode. I have to switch to 24-bit addressing, restart, then SetDate will work. It's definitely a slap job.


FWIW I run it on my SE/30 running 7.5.5 in 32-bit mode and have never seen it crash.  I just tried it again to make sure.

I am running SetDate 1.0, ©2011.

I agree with you though, all these bus errors and random weirdness feels like 32-bit dirtiness.  Odd though that @jessenator is getting crashes just running Macbug then doing an ES without doing anything else?

It’s hard to imagine making something so simple 32-bit dirty without really trying.  I mean, all it actually does it call GetDItem, GetIText and SetDateTime.

 
Last edited by a moderator:

Crutch

Well-known member
Yeah 32-bit dirty seems likeliest explanation.  The first Macsbug screen grab above shows it’s trying to read a byte from what’s probably an offset to A2, which is an address starting with “9E...”.  That’s not a valid 32-bit pointer unless @jessenator is running over 2G of RAM or the Memory Manager is doing some fancy things with virtual memory or something else more modern than my Mac OS knowledge, which is possible. :)   Try running in 24-bit mode on some flavor of System 7?  (Again though, this isn’t necessary for me, so it’s odd.)

 
Last edited by a moderator:

jessenator

Well-known member
I just realized how many grammatical fumbles were in my last post—damn :lol:

It's funny you mention VM, @Crutch because I wondered if the problem would be solved by turning it on, as I had hitherto had it off and as little extra going on. I did give it one go with double-ish the physical RAM (the physical ceiling on these LPX-40 boards is 160 MB because, "don't $*#@ with me, Tony Motorola," said Apple when they were co-designing it (probably…). But no inroads there, unfortunately.

Can you get 24-bit addressing on 7.5.3—or PPC even? Is there a secret menu option in Memory? That's the minimum system for these oddballs, though it'd be quite interesting if I could force 7.1.2 or 7.5 using the system enabler…Now I'm curious what would happen using the Apple Legacy Recovery disc and choosing an older OS. It probably won't work. Or wait, is that advice for Dog Cow?  :lol:
 

I am running SetDate 1.0, ©2011.


Odd though that @jessenator is getting crashes just running Macbug then doing an ES without doing anything else?
Could you plop that version up on vTools perhaps?

I'm starting to notice little things about 7.6.1 that the 4400 et al. do not like: I'm getting sound errors, strange graphic artefacts—just random crap. However, I still get this when just entering then exiting MacsBug's shell on a vanilla install of 7.5.3 so…
 

Illegal Instruction at 06C61506
_________________________________________
No procedure name
06C61506 *CMP2.B -(A0),D0




Also, just for kicks, I just tried to use SetDate to 0 out the time, I mean, not even changing the year and I get that same _DateToSeconds+01752 error :lol: I'm so glad this is a hobby and not necessary, day-to-day mission-critical.

Edit: here's a kicker for you: I tried to RS from the shell and I get back: Bus Error…PowerPC unmapped memory blah blah ***MacsBug caused the exception***

 
Last edited by a moderator:

Dog Cow

Well-known member
I agree with you though, all these bus errors and random weirdness feels like 32-bit dirtiness.  Odd though that @jessenator is getting crashes just running Macbug then doing an ES without doing anything else?

It’s hard to imagine making something so simple 32-bit dirty without really trying.  I mean, all it actually does it call GetDItem, GetIText and SetDateTime.
I've written "24-bit dirty" code by mistake, just using a .W length instruction instead of a .L length. It's insidious because the code will work just fine on some models of Mac, or in some common scenario, but then it crashes on another machine. It's due to the layout of the system heap or application heap, or what version of Memory Manager you have.

In the case of SetDate, it could be a compiler bug, who knows? I was meaning to inspect the code and debug it last evening. Maybe I'll do it this weekend.

 
Last edited by a moderator:

jessenator

Well-known member
Okay, one more stupid thing I tried… that seems to have worked in 7.5.3:

  1. Zapped the PRAM several times (my clock was still set… weird)
  2. I disabled MacsBug
  3. Set the clock to 24 hr in Date & Time panel
  4. I saw an option in the Memory panel "Modern Memory Manager" and turned it to off (I'd forgotten that existed… thought, 'why not?')
  5. Rebooted, opened SetDate: set the time first, no crash. Set the date???!?!?!?! NO CRASH.



Well okay, I'll take that and run. I'll see how long it holds out. Even turned MMM back on and it's still humming.

 
Last edited by a moderator:
Top