68kMLA Classic Interface

This is a version of the 68kMLA forums for viewing on your favorite old mac. Visitors on modern platforms may prefer the main site.

Click here to select a new forum.
PowerBook 180C jumping Clock and strange PCB modifications
Posted by: Campus90SE on 2026-09-27 05:54:44 I recently bought a PB180C, with already recapped screen. After some time I noticed that I can't set the time and date correctly, its jumping from one date and time to another by random. If I open the Clock app I can see it's changing all the time every 1 to 2 seconds. I replaced and loaded the Backup Battery on the interconnect board already and all other setting stay saved after disconnecting the power cord and removing the Battery. I thought maybe a connection between the boards is not ok, and took a closer look. And then I have found some not very professional looking soldering work on the Motherboard, a obviously not properly replaced fuse and a strange green wire on the back of the PCB 😳 Has anybody seen something like that? What has been done here? What is the green wire for and what has been repaired (or tried to do so)?
Posted by: A24A on 2026-09-27 17:31:17 Yes, obviously someone has simply bridged a faulty F1 fuse with a wire. Not a good idea. Suggest that you look for a Littelfuse fast-acting 5 A replacement. Green jumper wires are not always a sign of amateur work. They could also be the result of late-stage design changes at the factory.
Posted by: croissantking on 2026-09-27 17:38:14 The clock advancing in ‘fast forward’ mode is normal behaviour - I have seen it on every PB165 and 180 I’ve owned. The solution is to open the Date and Time control panel under System 7.1 (and System 7.1 only) which runs some kind of initialisation routine on launch and gets the clock running properly again. To be clear, you don't even need to set the time: you just need to launch the control panel. It will continue to behave correctly until you disconnect the PRAM battery (so basically if you open the laptop), after which point you’ll have to repeat the exercise. It’s fortunate you’ve replaced the PRAM battery since otherwise the clock would not stay initialised for very long at all. Thinking about it further, I wonder if the Date and Time cdev is simply setting one or more bits in PRAM that somehow influences the RTC. It would be interesting to clear PRAM, then compare its contents before and after running the cdev.
Posted by: rnb on 2026-09-28 07:29:23 Yeah I have a bootable 7.1 floppy that I use on my 180 with 7.5.5 installed whenever the clock gets jumpy. No need to install anything, just needs to get to a 7.1 version of the control panel.
Posted by: croissantking on 2026-09-28 07:46:57 And just in case anyone thought opening the 7.1 Date and Time cdev under 7.5 would be a clever shortcut, it doesn’t work 😛
Posted by: Campus90SE on 2026-09-28 10:17:27 Ok, thanks a lot, that really worked 😃 I have saved PRAM before and after and will try to compare it tomorrow. @croissantking Yes, of course that was my first thought 😂 I also have a PB165 where the clock problem did not appear, maybe it has to do with the board revisions. The PB180 has a 820-0354-03 Board.
Posted by: Campus90SE on 2026-09-28 10:18:50 Yes, obviously someone has simply bridged a faulty F1 fuse with a wire. Not a good idea. Suggest that you look for a Littelfuse fast-acting 5 A replacement. Green jumper wires are not always a sign of amateur work. They could also be the result of late-stage design changes at the factory. I ordered a new fuse and will replace it asap it arrives.
Posted by: Campus90SE on 2026-09-29 08:33:03 Comparing the PRAM files does not brighten things up, in the 'before' file there were even some Application Names, don't know why. I saved the PRAM with TechTool before repairing. After 'repairing' the clock with the 7.1 floppy I started again with System 7.5.3. Restoring the PRAM with TechTool from the old saved settings does not bring back the clock problem, so it seems it's not the content of the PRAM that causes it.
Posted by: croissantking on 2026-09-29 08:35:57 Comparing the PRAM files does not brighten things up, in the 'before' file there were even some Application Names, don't know why. I saved the PRAM with TechTool before repairing. After 'repairing' the clock with the 7.1 floppy I started again with System 7.5.3. Restoring the PRAM with TechTool from the old saved settings does not bring back the clock problem, so it seems it's not the content of the PRAM that causes it. That's very interesting. What kind of state, other than PRAM, could the battery be holding?
Posted by: Campus90SE on 2026-09-29 09:08:36 Also when the clock had the Problem, Apple Personal Diagnostics reported a logic board problem. After repairing with the System 7.1 floppy that is also gone, all ckecks ok. With the faulty clock also a PRAM Reset did not lead to a Date of 1904 like usual, it was still in the 2000th. Really strange. But I‘m quite happy it can be fixed and it‘s not a permanent Problem ☺️
Posted by: croissantking on 2026-09-29 09:12:10 Also when the clock had the Problem, Apple Personal Diagnostics reported a logic board problem. After repairing with the System 7.1 floppy that is also gone, all ckecks ok. With the faulty clock also a PRAM Reset did not lead to a Date of 1904 like usual, it was still in the 2000th. Really strange. But I‘m quite happy it can be fixed and it‘s not a permanent Problem ☺️ Snooper fails the RTC test as well when it's in this state. Under System 7.5 with the clock in the menubar, if you hit caps lock repeatedly (so that the menubar updates) you can see the clock is just running really fast as opposed to changing to random values. The next thing to do would be to try and disassemble the code that 7.1's Date and Time control panel is executing when it's launched. May be worth looking through the SuperMarioProj source code as well! Ultimately it would be nice to create an extension that checks if the RTC has been initialized correctly on each boot, and executes some code if not.
1