What causes SE/30 simultaneously to have the clock run extremely fast and the mouse not to respond?

[s_pupp]

This is a question regarding past experiences — none of my current SE/30’s exhibit this behavior.

Back around 1990, the SE/30 I used in the chemistry lab in college developed this problem. The mouse responded slowly and erratically enough to be useless, and the clock advanced very, very fast. The IT dept just replaced the logic board.

In 2010, one of my SE/30’s developed the same problem. Because two of the three SE/30’s I’d had contact with did this, I assumed it was a common problem, but haven’t seen it reported anywhere. Is it an RTC chip issue? If so, why is the mouse affected?

 

[joshc]

The mouse speed setting is stored in PRAM. That PRAM is part of the RTC.

The RTC contains a 4-byte counter incremented once each second. Each time the counter is incremented, the RTC sends an interrupt request signal to the VIA and (if this interrupt is enabled), the VIA sends an interrupt to the main processor. The RTC also contains 256 bytes of RAM (20 bytes in the Macintosh 512K and Macintosh 128K, 128 bytes in the Macintosh Portable), called parameter RAM, that is powered by a battery when the Macintosh is turned off (because system RAM in the Macintosh Portable is never switched off, a separate battery is not needed for the RTC in the Macintosh Portable). Parameter RAM contains important data that needs to be preserved even when the system power is not available. The Macintosh Operating System maintains in low memory a copy of parameter RAM that you can access.

The above information is from:

Guide to the Macintosh family hardware : Apple Computer, Inc : Free Download, Borrow, and Streaming : Internet Archive

Apple Guide to the Macintosh Family Hardware, Second Edition, from Apple Computer. For Macintosh Plus, Macintosh SE, Macintosh SE/30, Macintosh Portable,...

archive.org

So it's possible your RTC chip has somehow gone bad? Either that, or something else is affecting it.

 

[Phipli]

This could be caused by an excessive number of interrupts being triggered. If there was noise on the RTC crystal that somehow was making it run fast, the 1 second interrupt would be being triggered way more frequently, and could have been using up loads of processor time.

Every time the 1 second interrupt is triggered, the computer stops what it is doing to service the interrupt - i.e. run a little bit of code, before returning. If it is triggering at 60 interrupts per seconds, it's doing this 59 times more than it should be in every second...

How fast was the clock running? Minute for every second? Or faster?

 

[joshc]

That's what I was half-thinking, but I wasn't confident enough to put that in writing... what could cause that noise?

 

[Phipli]

That's what I was half-thinking, but I wasn't confident enough to put that in writing... what could cause that noise?

I've only seen clocks fail dead or drift a little, don't know if they could fail massively faster, but perhaps a failed gate in a logic chip self oscillating could do it? Even if not directly connected, high frequency can leach into neighbouring traces, and the raw clock signal is fairly weak. You usually buffer them (but sometimes this isn't needed with an MCU, and I think it is like this with the RTC in the SE/30).

 

[Phipli]

It could also be a cut trace between the RTC and VIA, because a floating via input could be rapidly self triggering.

Long and short, my debug process would be, check 32.768khz crystal, check area for damage and bad logic chips, verify continuity between RTC and crystal and RTC and VIA. Check VIA and RTC power... Replace RTC... Replace VIA.

 

[David Cook]

It could also be a cut trace between the RTC and VIA, because a floating via input could be rapidly self triggering.

Long and short, my debug process would be, check 32.768khz crystal, check area for damage and bad logic chips, verify continuity between RTC and crystal and RTC and VIA. Check VIA and RTC power... Replace RTC... Replace VIA.

I second this approach. Highly likely a bad crystal. I have had two IIsi computers where this was a similar problem. In my case, a plain mouse sorta worked but the Turbo Mouse would not.

That being said, the SE/30 doesn't use a consolidated combo ADB+clock chip exactly like the IIsi. However, if UK4 (RTC) is triggering too often due to a bad crystal, perhaps it is overwhelming UK12 (65C22 VIA1) which also talks to UL11 (ADB).

 

[s_pupp]

How fast was the clock running? Minute for every second? Or faster?

If I recall correctly, it was several minutes for every second.

This has all been very helpful info, and helps to clear up a mystery that has been in the back of my mind for decades.

 

[Phipli]

If I recall correctly, it was several minutes for every second.

This has all been very helpful info, and helps to clear up a mystery that has been in the back of my mind for decades.

Yeah, so in that case it was running a short little bit of code hundreds of times every second.