Jump to content
Sign in to follow this  
Big Bird

IIcx Time Problem

Recommended Posts

I'm in the process of setting up a Mac IIcx as a LocalTalk Bridge/IP Gateway, but it has a really strange problem. It will retain a time that you set in the Date & Time control panel, but no matter what you do, it will not KEEP time. That is, once you "set" the time, it doesn't count seconds up. The same time just stays there. Unlike the symptoms of a dead PRAM battery, the IIcx retains the exact time that you set it to, down to the second, and does not reset the time or date to 1904/1956/whenever. Could it still be a PRAM battery that's keeping it from counting time?

 

It has a fresh install of System 7.5.5 on a known good hard drive, RAM, video card, and network card. MODE32 is installed. There's nothing in the machine I can figure out that could be causing this. I've tried zapping the PRAM, of course, as well as trashing preferences, although that doesn't make sense with the fresh system install anyway. Pulling the hard drive, network card, RAM, and video card from the IIcx and dropping them into a IIci (and the HD into an LC III) fails to replicate the problem; both Macs count time as normal.

 

Has anyone seen anything like this before? Any ideas on what it might be? At this point, I'm down to a logic board or component-level issue, but I don't have another IIcx to test that theory easily, not to mention would sort of rather it be something else.

 

Thanks for the help,

Cody

Share this post


Link to post
Share on other sites

I've heard a PRAM battery doesn't have to be completely dead to cause problems. I'm not sure as to the truth of it, though. It wouldn't hurt to put a new one in and see what happens.

Share this post


Link to post
Share on other sites
...seen anything like this before? Any ideas on what it might be? At this point, I'm down to a logic board or component-level issue, ...

Umm, no, yes, and agree. Sounds like a hardware problem to me also. An easy second step while you are experimenting with the battery is to do a topside visual board inspection around the battery, crystal, 8 pin RTC chip if you have one right next to the crystal, looking for capacitor wet residue, corrosion, foreign matter shorting out the crystal, oscillator or the one second interrupt to the VIA interface chip. By the way, that RTC is where the PRAM lives also, so if it remembers mouse settings and other stuff maybe the chip is powered and backed up okay but the oscillator is not going, stopping time as it were. I think the VIA externally serial clocks the PRAM data in and out. If you have Guide to the Macintosh Family Hardware, Second Ed, see p144. I can walk you thru the pinouts if need be.

Share this post


Link to post
Share on other sites

Thanks for the responses. As it turns out, disabling MODE32 causes the Mac to count seconds, but VERY slowly . . . about 3 seconds to every 1 second ratio. This seems to put an entirely new twist on it.

 

A visual inspection reveals no obvious damage or corrosion to the board level components around the battery. I did manage to dig up another IIcx, and I transplanted everything but the board into that machine. It has the same symptoms: time failing to count with MODE32 enabled, counting a second about every 3 seconds with MODE32 disabled.

 

I can't help but think this is unrelated to MODE32, as I and probably many of us have used it successfully on other machines, but for some reason, these two IIcxes seem to be stuck in a time warp whenever they address more than 8 MB of RAM. But I don't know what might be the actual cause of the change in symptoms upon disabling the extension.

Share this post


Link to post
Share on other sites

Simms loaded in full groups of four?

Any unusual extensions or control panels that might warrant a run with Conflict Catcher?

If interrupts were coming in fast and furious, maybe the time ones lose out?

Most curious...

Share this post


Link to post
Share on other sites
I transplanted everything but the board into that machine. It has the same symptoms: time failing to count with MODE32 enabled, counting a second about every 3 seconds with MODE32 disabled.

 

Did "everything" include the pram battery? Either way, if you have a voltmeter, measure the battery voltage in operation. If it reads ok (say, 85% of nominal or better), then you can rule out the battery as the source of trouble.

Share this post


Link to post
Share on other sites

Yes, the PRAM battery was included in the swap, but I had already replaced it with a new one in the original IIcx. I don't think the battery is the problem.

 

And yes, SIMMs are loaded in full groups of 4 matched sets -- 4 x 4 MB and 4 x 1 MB. If I remember correctly, it was only the Mac II that couldn't handle SIMMs >1 MB in the first four slots.

 

I like your fast and furious interrupts theory. In fact, I think it may be right on. But the vexing part is my inability to ascertain the source of these mythical interrupts. I know there's no unusual extension or control panel causing the problem because the problem is exhibited under a fresh 7.5.3 install.

 

So, to sum up: the problem occurs under a fresh install on two different IIcxes. The problem does not occur when the exact same drive is dropped into a IIci or LC III. This seems to eliminate a software problem, unless I'm missing something. Then, a fresh PRAM battery is being used with RAM that is confirmed good in a IIci and neither IIcx motherboard shows signs of physical corrosion or damage. This seems to decry the hardware issue. I'm at a bit of a loss here . . . :-/

Share this post


Link to post
Share on other sites

Big Bird, have you tried a different clock for that computer? Like, say, Superclock? Because I was thinking it could be the software for the clock in System 7.x. If not, do a really thorough search online regarding your problem to see if anyone in the past (outside 68kMLA) has had the same.

 

73s 8)

Share this post


Link to post
Share on other sites
...to ascertain the source of these mythical interrupts...

I'm having trouble imagining memory misbehavior that would not eventually cause a bomb. But I am beginning to wonder about the video card, network card, keyboard and mouse that were presumably common to the tests. Does the mouse point/track smoothly, and does running keycaps from the apple menu show any stuck repeating keys? If there is any choice of video resolution, does changing it change the time loss rate? Booting without the network card, does the problem remain? "Borrowing" another keyboard, mouse, video card and some other memory, and/or trying less memory are other possibilities.

Share this post


Link to post
Share on other sites

phreakout:

Doesn't SuperClock just display the System 7 clock's time on the menubar? I've never actually used it because I've never actually cared about the time on the menubar, but that would be my guess. But not only that, since this machine is running as a server, it needs to have accurate time. The system time is the time that really matters, since it provides the foundation for time/date stamping and because applications just do API calls (I'm showing my Windows background; I don't know what this is called on the classic Mac OS) to the OS for the time.

 

 

wally:

This is exactly why I posted this on here. The keyboard, mouse, and video card were definitely common to both of the IIcx trials. I knew I'd forgotten something that should be obvious. I mean, it "shouldn't" be the problem since all have worked with other Macs, but you never really know until you try it and I'm grasping at straws here. I really wanted to use the IIcx for this project (don't ask me why, I'm not sure I could tell you exactly ;)), but I may have to end up switching machines. I'll swap the devices from another functional setup to try it tomorrow and post back. Thanks for the suggestions!

Share this post


Link to post
Share on other sites

So, back in town and on a bizarre sleep schedule from time zone changes, I was finally able to work on the Mac again.

 

I tried a new keyboard, mouse, and video card from another working Mac setup, and the time problem continues. I replaced all the RAM with 1 MB SIMMs from a IIci, but no dice. I put in a new hard drive pulled from a IIci and tried booting with extensions on, then off, and both times, nothing. I can't seem to find anything that makes either of these IIcxes count time properly. I don't know if it's "good" news, but all of these attempts cause it to count 1 second for every 3 actual seconds, rather than hold time at a complete standstill.

 

Two different IIcxes now have:

  • • confirmed good keyboard, mouse, and video card
    • fresh install of System 7.5.3 or installs of 7.1/7.5.5 on drives pulled from working Macs
    • new PRAM battery
    • RAM pulled from another working Mac
    • floppy drive disconnected
    • network card removed

What am I missing now? Any more suggestions before I have to pitch these machines back into storage? Anyone have a really cheap Quadra 700 for sale? :-/

Share this post


Link to post
Share on other sites

Wait, you're saying you have *two* IIcx's doing this crap? Seeing as how you did everything else, it does seem to be a component level problem, but on two different machines? Hmmmm.....

 

I've run OS 7.5.x on a IIcx without problem, and I see that you've also tried 7.1, which I know runs fine too, but perhaps create a System 6 boot disk, unplug the hard drive, and see what happens?

Share this post


Link to post
Share on other sites

And if nothing works, would you be willing to part with one of the IIcx's? I'm desperately trying to get my dead one to work. Hook a fellow Longhorn up! :)

Share this post


Link to post
Share on other sites

Were different power supplies tried? Or the original one moved to the second machine for testing? I'm thinking about /pfw power fail interrupts that when handled see power as ok again, but that monopolize interrupt handling time...these could be faulty /pfw signals from one bad supply, or good ones from two different good supplies that happen by their design not to be able to handle spike or dropout electrical noise unique to your lab...

 

Is there an unusual lab electromagnetic environment that could cause the normally 32768 Hz crystal oscillator to run in sync with some slower external humungous field instead? Like an NMR or MRI setup?

Share this post


Link to post
Share on other sites

Several power supplies were swapped in and out, and since I'm doing this in a bedroom not in one of the chemistry labs at the university, I don't think there's any strange EMI. The date doesn't matter. All Macs have full support for the Y2K rollover up until the year 2019; it just sees the "7" or "07" as the year 2007. Plus, I always configure to show four-digit years, so that shouldn't be a problem. But I've sure tried it with the number of times I've reset the PRAM.

 

Strangely enough, when I boot into System 6.0.5, the time starts working. Then, rebooting the machine into System 7 or off of any hard drive I've tried in the machine, the time continues to work.

 

So I guess it's fixed? I'm not sure how or what I did. Although I'm worried it's going to stop working again after I leave it off for a while. I'm always apprehensive whenever I fix a machine without knowing what I did to fix it.

Share this post


Link to post
Share on other sites
The date doesn't matter. All Macs have full support for the Y2K rollover up until the year 2019.

 

Acknowledged, but until I've seen it I'm cautious...

Share this post


Link to post
Share on other sites

Its definately true...i've experimented with my older Macs, and they have no problems recognising any time between 1920 and 2019. The only thing is that after 2019, all our old Macs will roll back over to 1920. :(

Share this post


Link to post
Share on other sites
Its definately true...i've experimented with my older Macs, and they have no problems recognising any time between 1920 and 2019. The only thing is that after 2019, all our old Macs will roll back over to 1920. :(

 

Isn't that based on the operating system? My understanding is from this rather confusing Apple tech article:

All Mac OS date and time utilities have correctly handled all issues related to the year 2000 since the introduction of the

Macintosh. The original date and time utilities, introduced with the original Macintosh 128K in 1984, used a 32-bit value

to store seconds, starting at 12: 00: 00 a.m., January 1, 1904. Since Apple used a 32-bit value to store seconds, this

means that the last date represented in this 32-bit value is 6: 28: 15 a.m. on February 6, 2040. The current date and

time utilities, documented in Inside Macintosh: Operating System Utilities , use a 64-bit signed value. This covers dates

from 30081 B.C. to 29940 A.D. For further reference, see Inside Macintosh: Operating System Utilities , Chapter 4, or

its predecessor, Inside Macintosh Volume II .

 

The Date & Time control panel constrains user entry to dates between January 1, 1920 and December 31, 2019. This

feature was added for compatibility with the original Macintosh System 6 General control panel, which limited dates so

there would be no ambiguity about a 2-digit year (which was all that was normally displayed on a US system). The Date &

Time control panel uses the Script Manager function ToggleDate. ToggleDate was enhanced in 1989 to have an

option that limited dates to the 1920-2019 range so that it could be used by the General control panel and other control

panels that wanted to have a date widget that operated in the same way. You can set a date beyond 2019, up to the year

2040, by using the Macintosh Toolbox call SetDateTime().

 

That all Macs since the 128K have the capability of running the date up to 6: 28: 15 a.m. on February 6, 2040. The caveat is that from System 6.0.3, the control panel limited the maximum date to December 31, 2019 (with an option to extend to 2040). That persisted until an update to System 8 extending the maximum date to to 29940 A.D.

 

Doesn't this mean that Macs running System 1.0 through 6.0.2 will have a maximum date of 2040? Is it possible to confirm? Under System 3.2 setting the clock ahead to 20 does not guarantee it is not 1920.

 

I wouldn't have thought it before, but if not, that means the 68K Macs only have about 10 years of useful life left. I would feel much better about it if I knew the useful end date would last at least as long as I do.

Share this post


Link to post
Share on other sites

I had the same/similar experience in a IIcx, which had been upgraded from 7.0 to 7.1 to 7.5 with all the in-betweens. SuperClock had not been discarded in the process, and, putatively, was slugging it out with whatever Apple changed it into when they acquired the rights to include it in their own System. Deletion of SuperClock fixed the problem.

 

de

Share this post


Link to post
Share on other sites

Silly of me, but I didn't mention another clock-problem-inducer: a screen-saver with its own incorporated clock, as is the case with Møire. Disabling the display by Møire of time in the menu-bar removes another source of possible contention.

 

de

Share this post


Link to post
Share on other sites
I wouldn't have thought it before, but if not, that means the 68K Macs only have about 10 years of useful life left.

Um...

 

Old Macs are still useful even if the date/time is not set correctly. Heck, I removed all the batteries form my old Macs. I do whatever trick is necessary to get them to boot, and don't even bother setting the date/time.

 

Worst-case, you can just set the date 100 years behind the current year. Everything should still be fine if you just remember and take note of it.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×