Logic Board reworking: A Tale of Two IIcx
- Thread starter Addicted
- Start date
Not really sure of how to debug a PSU, but I have it 'exploded' for probing. Makes me nervous to have it there, guts open to any accidental contact! I've done all the basics I know to do: continuity testing, reflow, check for shorts. It does provide a clean 5.199V on the trickle rail. I recapped it months ago.
It was doing the relay click-loop until it failed, probably a big clue. Something was out of spec, and it finally failed completely?
Idea #1 today is to pull the relay (after I unplug the PSU for an hour or so) and test its coil and points. And maybe the relay coil has a snubber or diode - built in or on board - that's shorted out. No idea.
Idea #2 is to re-confirm that the logic board is raising #PFW (easily done), but the logic board boots with a different PSU - so that's likely OK.
The large daughtercard in the PSU is beyond my pay grade, sad to confess.
It was doing the relay click-loop until it failed, probably a big clue. Something was out of spec, and it finally failed completely?
Idea #1 today is to pull the relay (after I unplug the PSU for an hour or so) and test its coil and points. And maybe the relay coil has a snubber or diode - built in or on board - that's shorted out. No idea.
Idea #2 is to re-confirm that the logic board is raising #PFW (easily done), but the logic board boots with a different PSU - so that's likely OK.
The large daughtercard in the PSU is beyond my pay grade, sad to confess.
Relay is good. Oh, well.
Skipped lunch, extracted and took photos of the daughter card. It has pencil markings on it indicating the values of a few caps and resistors, on the right hand side of the photo. Either they were written by the assembly engineer, or I am not the first to open this PSU. The black/white pair near the ASTEC logo are to the thermostat. The ICs are (clearly) an LM393 and a 3842N PWM generator. Identifying the transistors is next on my list, although the SMDs may not be 100% identifable.
Skipped lunch, extracted and took photos of the daughter card. It has pencil markings on it indicating the values of a few caps and resistors, on the right hand side of the photo. Either they were written by the assembly engineer, or I am not the first to open this PSU. The black/white pair near the ASTEC logo are to the thermostat. The ICs are (clearly) an LM393 and a 3842N PWM generator. Identifying the transistors is next on my list, although the SMDs may not be 100% identifable.
OK, it's the PSU. It's driving 13.5V onto the #PFW line, with or without a logic board.
I replaced a triac and two power FETs in the PSU before I knew #PFW was over-voltage, because I was in there and had the exact replacements already on hand. It was a simple swap and I hope I did not introduce this with them. Removing and replacing the daughter card was still good to ensure clean solder joints and unbroken pads, but still.. fogged up the debug with unnecessary changes.
Nice to have a lead; perhaps I can trace this back into the PSU somehow.
I replaced a triac and two power FETs in the PSU before I knew #PFW was over-voltage, because I was in there and had the exact replacements already on hand. It was a simple swap and I hope I did not introduce this with them. Removing and replacing the daughter card was still good to ensure clean solder joints and unbroken pads, but still.. fogged up the debug with unnecessary changes.
Nice to have a lead; perhaps I can trace this back into the PSU somehow.
The saga continues 
The first unit remains absolutely stable.
The second unit has two issues.
First and foremost, the PSU remains dead. I recapped it a while ago. I overhauled it including down to the daughter boards and found possibly cracked high-wattage resistors and a very discolored Zener, and replaced other identifiable parts while there. But I have no experience in power supplies, so this was hit or miss, and came out miss. The PFW line still has about 13V on it. With no evident shorts anywhere, and my recap parts all in the right polarization, I can't imagine where this bleed is happening.
The second problem has slightly improved. The system sad chimes before it inits video if I boot with the onboard ROMs. If I boot with the CayMac ROM SIMM, the system runs almost perfectly. When running MacTest IIcx V2.0, it used to bomb as soon as it tried to play the Standard A-chord. After more cleaning and resoldering around the ASC (UF14 and UF15 might have been cap-corroded just a bit), it now just never finishes that test and never plays the chord. The cursor remains responsive, but clicks on Pause or Stop do nothing. But no Bomb.
I have had that copy of MacTest do other weird things; it may be corrupted. I am having trouble finding a different download of it or any more advanced Apple-produced IIcx diagnostics.. I keep finding bad StuffIts, etc.
Next time I get this out, I want to totally clear my tiny bench and use a good Mac to host AppleCAT on the sad IIcx. Perhaps it can turn up some details.
The first unit remains absolutely stable.
The second unit has two issues.
First and foremost, the PSU remains dead. I recapped it a while ago. I overhauled it including down to the daughter boards and found possibly cracked high-wattage resistors and a very discolored Zener, and replaced other identifiable parts while there. But I have no experience in power supplies, so this was hit or miss, and came out miss. The PFW line still has about 13V on it. With no evident shorts anywhere, and my recap parts all in the right polarization, I can't imagine where this bleed is happening.
The second problem has slightly improved. The system sad chimes before it inits video if I boot with the onboard ROMs. If I boot with the CayMac ROM SIMM, the system runs almost perfectly. When running MacTest IIcx V2.0, it used to bomb as soon as it tried to play the Standard A-chord. After more cleaning and resoldering around the ASC (UF14 and UF15 might have been cap-corroded just a bit), it now just never finishes that test and never plays the chord. The cursor remains responsive, but clicks on Pause or Stop do nothing. But no Bomb.
I have had that copy of MacTest do other weird things; it may be corrupted. I am having trouble finding a different download of it or any more advanced Apple-produced IIcx diagnostics.. I keep finding bad StuffIts, etc.
Next time I get this out, I want to totally clear my tiny bench and use a good Mac to host AppleCAT on the sad IIcx. Perhaps it can turn up some details.
Using knowledge gained from other IIcx restores on this site and with links provided by @SuperSVGA , progress was made on the remaining sad-chime IIcx.
For other novices such as myself, the Test Manager is a serial debugging tool in the ROM code. A thorough guide to it can be found here - be sure to read all the sheets.
The IIcx I am restoring currently sad-chimes immediately at boot, but will boot with a ROMinator SIMM. Even then, it eventually seizes up after a little while.
Using Test Manager commands, it appears to be a ROM checksum failure. While I had the logic board on the bench, I issued a few more commands to verify that the 4MB of RAM I have in Bank A looks good, since I had to replace the banking gates. Starting right after a cold-boot sad chime, first the ROM smoking gun:
Then the RAM validations:
I may not be interpreting the *T0004 test correctly. The return code here may indicate which ROM lanes failed or (more likely) it may just be the ROM size. But the result code upon entry was 0x0000FFFF followed by 0x0001: ROM Checksum Error.
I've already re-soldered the ROMs, but I'll check the traces to the CPU again.
I hope to find (or blast my own) Apple-bit-loyal ROMs to replace any failing ones; hopefully only one is bad. After that, the only mystery remaining is why the system locks up after a little runtime. (And, it still needs a power supply.)
For other novices such as myself, the Test Manager is a serial debugging tool in the ROM code. A thorough guide to it can be found here - be sure to read all the sheets.
The IIcx I am restoring currently sad-chimes immediately at boot, but will boot with a ROMinator SIMM. Even then, it eventually seizes up after a little while.
Using Test Manager commands, it appears to be a ROM checksum failure. While I had the logic board on the bench, I issued a few more commands to verify that the 4MB of RAM I have in Bank A looks good, since I had to replace the banking gates. Starting right after a cold-boot sad chime, first the ROM smoking gun:
Code:
*A
*E
0000FFFF0001*R
000400010001*T
000000080000*RThen the RAM validations:
Code:
*4
00000000*0
003FFFFC*1
000200010001*T
000000000000*R
000000010001*T
004000000000*R
*4
00000000*0
003FFFFC*1
000300010001*T
000000000000*RI may not be interpreting the *T0004 test correctly. The return code here may indicate which ROM lanes failed or (more likely) it may just be the ROM size. But the result code upon entry was 0x0000FFFF followed by 0x0001: ROM Checksum Error.
I've already re-soldered the ROMs, but I'll check the traces to the CPU again.
I hope to find (or blast my own) Apple-bit-loyal ROMs to replace any failing ones; hopefully only one is bad. After that, the only mystery remaining is why the system locks up after a little runtime. (And, it still needs a power supply.)
Last edited:
After more study of the existing posts, I think the ROM Checksum Test (*T0004...) '8' is telling me that the LL ROM did not match its checksum. I like the ROMinator I have, but aim to have as authentic an antique as possible. So off to investigate a replacement EEPROM and conjure up an ad-hoc programmer for it while I wait. I'll run the same test on the other IIcx first to be sure I have a valid source for the bits, but that Mac boots effortlessly and is very stable, so the validation is mostly a formality.
I declared defeat on the ASTEC power supply, which after rework is still driving 13V or so on the PFW signal line. Double double checked that I have the connector orientation correct and that I am not measuring the 12V output by mistake
Found a replacement online; awaiting delivery.
I declared defeat on the ASTEC power supply, which after rework is still driving 13V or so on the PFW signal line. Double double checked that I have the connector orientation correct and that I am not measuring the 12V output by mistake
Found a replacement online; awaiting delivery.The second IIcx now happy-chimes with no ROMinator.
I dumped my ROMs with Test Manager and compared them to a reference ROM file, and sure enough, 64 words had the highest-addressed byte corrupted. The low nibble was always the cause.
I live a short drive/medium walk from Jameco Electronics (*), and they had 27C512 70ns EEPROMs in stock. I bought four, and since only UV-eraseables were in stock at less than 120ns access time, I bought sockets.. cuz, seemed contrary to solder-in a reprogrammable part.
A quick Python script to pull the correct lane out of the Archive.org ROM file for the IIcx, flash the chip, and done! Happy chime with 8MB spread 4/4 across both banks.
In days past, that IIcx was still locking up after some use, but did not try to reproduce that and called it a day after getting my happy chime. Ended my Tuesday on a high note (pun intended). Debug that another day. I suspect it's something to do with audio out, as it will cruise right along until I trigger an alert or ask the diags to test sound.
(*) I think it was 1979. I saw an ad from Jameco Electronics in the back of BYTE Magazine, and with the money I had saved working at a theme park that summer I sent a money order to Jameco to buy eight 450ns dynamic RAMs to bring my Apple ][ (S/N 11444) up to a whopping 32KB.
I dumped my ROMs with Test Manager and compared them to a reference ROM file, and sure enough, 64 words had the highest-addressed byte corrupted. The low nibble was always the cause.
I live a short drive/medium walk from Jameco Electronics (*), and they had 27C512 70ns EEPROMs in stock. I bought four, and since only UV-eraseables were in stock at less than 120ns access time, I bought sockets.. cuz, seemed contrary to solder-in a reprogrammable part.
A quick Python script to pull the correct lane out of the Archive.org ROM file for the IIcx, flash the chip, and done! Happy chime with 8MB spread 4/4 across both banks.
In days past, that IIcx was still locking up after some use, but did not try to reproduce that and called it a day after getting my happy chime. Ended my Tuesday on a high note (pun intended). Debug that another day. I suspect it's something to do with audio out, as it will cruise right along until I trigger an alert or ask the diags to test sound.
(*) I think it was 1979. I saw an ad from Jameco Electronics in the back of BYTE Magazine, and with the money I had saved working at a theme park that summer I sent a money order to Jameco to buy eight 450ns dynamic RAMs to bring my Apple ][ (S/N 11444) up to a whopping 32KB.
Last edited:
@Callan - for a while, I lived four blocks from a Fry's Electronics. In the 90s and early 2000s, they still sold - retail - everything from 7400-series chips to CPUs, oscilloscopes and static RAMs. They folded a few years ago, sad to say. The real loss out here was when WeirdStuff Warehouse closed. It was a huge old shed stuffed with SIlicon Graphics, Apple, Sun, all manners of legacy hardware, some working, some not, for next to nothing. You could find basically anything there.
And the saga .. CONCLUDES 
The second IIcx was up and running and playing sounds for about thirty minutes just now. It's late so, I'll do a more proper burn-in tomorrow.
What changed?
I was almost asleep when I had a vague memory that if I boot through a ROMinator II into System 7.1 or later, I needed to patch the Gestalts, something like that.
But I never, ever got around to that.
And now that I had discovered and replaced my corrupted on-board ROM, I could boot without my ROMinator II, and without those patches.
So I tried. Booted into System 7.5.3 on an external SCSI with the RasterOps video card, VM and Mode32 .. and played Maelstrom for a few minutes. Total time warp back to wasting time in college...
The sound was scratchy, but I already know that the speaker's pigtail contacts are green and need to be replaced.
Then ran the full Speedometer benchmark with the RasterOps 8L set at millions of colors.
Set up PRAM, chose a desktop pattern, SetDate into 2025
etc
Then poked around in the Sound Control Panel, trying to force the hangs I saw before. They didn't happen.
Then confirmed soft PSU power control by using the Apple Menu •Shut Down option, which worked.
I think I can look forward tomorrow to putting this IIcx logic board back into its chassis with its hard disk scaffold and floppy drive - and finally put the lid back on the chassis. Just need that replacement PSU to arrive and it'll be real.. after a year of occasional restoration work.
This forum, its participants, Macintosh Garden, the Macintosh Repository, TinkerDifferent, so many thanks I need to hand out. Cheers!
The second IIcx was up and running and playing sounds for about thirty minutes just now. It's late so, I'll do a more proper burn-in tomorrow.
What changed?
I was almost asleep when I had a vague memory that if I boot through a ROMinator II into System 7.1 or later, I needed to patch the Gestalts, something like that.
But I never, ever got around to that.
And now that I had discovered and replaced my corrupted on-board ROM, I could boot without my ROMinator II, and without those patches.
So I tried. Booted into System 7.5.3 on an external SCSI with the RasterOps video card, VM and Mode32 .. and played Maelstrom for a few minutes. Total time warp back to wasting time in college...
The sound was scratchy, but I already know that the speaker's pigtail contacts are green and need to be replaced.
Then ran the full Speedometer benchmark with the RasterOps 8L set at millions of colors.
Set up PRAM, chose a desktop pattern, SetDate into 2025
etcThen poked around in the Sound Control Panel, trying to force the hangs I saw before. They didn't happen.
Then confirmed soft PSU power control by using the Apple Menu •Shut Down option, which worked.
I think I can look forward tomorrow to putting this IIcx logic board back into its chassis with its hard disk scaffold and floppy drive - and finally put the lid back on the chassis. Just need that replacement PSU to arrive and it'll be real.. after a year of occasional restoration work.
This forum, its participants, Macintosh Garden, the Macintosh Repository, TinkerDifferent, so many thanks I need to hand out. Cheers!
Last edited:
Boctor
Well-known member
That's an encouraging find with the ROM itself actually being dodgy, well done! Did you need any special tools such as a hot air preheater, to coax the DIP out of the board? I'm interested in getting the same socket and a ROM/programmer from a supplier in the future, for a IIcx whose onboard ROMs fail the same critical test (Returns a '2' where yours had an '8'. This supposedly means the second chip, MH, has a bad checksum.)
Slight tangent, but the mention of Fry's brought back sad memories of my final visit. The staff were instructed to tell customers asking about the empty shelves that they were "changing suppliers," without further elaboration.
Slight tangent, but the mention of Fry's brought back sad memories of my final visit. The staff were instructed to tell customers asking about the empty shelves that they were "changing suppliers," without further elaboration.
Fry's was legendary back on the pre-1994 Internet, and it lived up to the hype when I actually got to go to one in early 2003 (the San Diego Mission Valley location). MicroCenter is the closest thing to it that exists now, but they don't carry loose chips or anything like that.
I'm a little surprised the ROM itself was bad rather than a solder joint or something, but these machines are certainly at the age where anything can happen.
I'm a little surprised the ROM itself was bad rather than a solder joint or something, but these machines are certainly at the age where anything can happen.
@Boctor - I evacuated the solder from 26 of 28 pads by applying a little flux, heating the joint, and wicking the easy parts away, then repeating where needed using a simple thumb-pumped solder sucker instead of wick. The last pins, Ground and Vcc, had too much copper nearby and resisted several repeats, and I direly wanted to avoid lifting the pads and traces. I sighed and sacrificed the old chip -- clipped those pins from above, then tweezed them out while heating the pad from below.
It would have been nice to keep the intact chip around like a little paperweight to remind me of this adventure - I think this is the first time I've seen a mask ROM incontrovertibly be the problem.
I feel so lucky that none of the corrupted bytes ruined the Test Manager code, which was the major catalyst in helping me find the matter with this board. I'll tidy up the diffs I made (add the addresses/offsets for reference) and post them here later today, purely for the curious. Those with disassembly listings might want to know what toolbox etc. routines were corrupted.
While on the way to Jameco to pick up the EEPROMs, I thought about what I might need to build my own flash burner. In the interest of time, I just got a cheap ready-made one while there. I have needed one for a while, and will get the value out of it.
It would have been nice to keep the intact chip around like a little paperweight to remind me of this adventure - I think this is the first time I've seen a mask ROM incontrovertibly be the problem.
I feel so lucky that none of the corrupted bytes ruined the Test Manager code, which was the major catalyst in helping me find the matter with this board. I'll tidy up the diffs I made (add the addresses/offsets for reference) and post them here later today, purely for the curious. Those with disassembly listings might want to know what toolbox etc. routines were corrupted.
While on the way to Jameco to pick up the EEPROMs, I thought about what I might need to build my own flash burner. In the interest of time, I just got a cheap ready-made one while there. I have needed one for a while, and will get the value out of it.
Last edited:
Corrections to my sleepy-eyed success post:
The patches I mentioned are necessary only for System 7.5 and beyond, I think. I recalled it incorrectly as System 7.1 and beyond last night.
My RasterOps 8L doesn't do Millions of colors. I did expand its VRAM to the max, but without the ROM from a 24L that only enables a larger, virtual, pannable screen in 256 colors. I got confused because Speedometer produced a 16-bit benchmark result, somehow.
The patches I mentioned are necessary only for System 7.5 and beyond, I think. I recalled it incorrectly as System 7.1 and beyond last night.
My RasterOps 8L doesn't do Millions of colors. I did expand its VRAM to the max, but without the ROM from a 24L that only enables a larger, virtual, pannable screen in 256 colors. I got confused because Speedometer produced a 16-bit benchmark result, somehow.
FWIW, the comparison of the factory ROM contents versus what my ROMs had.
You can see that with only two exceptions, they happen on 0x__700 and 0x__F00 boundaries; each fault persists for eight bytes. Possibly the 27C512 page (row) size.
They always happen in the right-most byte, which is the IIcx's LL ROM. Errored bits flip both ways, not always to one or always to zero. It's as if the ROM has changed the low nybble to be 0x6 in those ranges.
The error-free word at offset 0x035710 is curious. The correct LL byte there is 0xC6, and so the theorized error did no harm. That coupled with the first two isolated errors may shine some light on the fault for those savvy with the EEPROM internal buffering and layout.
You can see that with only two exceptions, they happen on 0x__700 and 0x__F00 boundaries; each fault persists for eight bytes. Possibly the 27C512 page (row) size.
They always happen in the right-most byte, which is the IIcx's LL ROM. Errored bits flip both ways, not always to one or always to zero. It's as if the ROM has changed the low nybble to be 0x6 in those ranges.
The error-free word at offset 0x035710 is curious. The correct LL byte there is 0xC6, and so the theorized error did no harm. That coupled with the first two isolated errors may shine some light on the fault for those savvy with the EEPROM internal buffering and layout.
Code:
OFFSET CORRECT FAULTED (XOR)
H M M L H M M L H M M L
H H L L H H L L H H L L
------------------------------------
007B48: B2680006 B2680002 00000004
-
024468: 16505C4F 16505C4D 00000002
-
034700: 036D0374 036D0376 00000002
034704: 037A0384 037A0386 00000002
034708: 038D0391 038D0396 00000007
03470C: 0398039D 03980396 0000000B
034710: 03A203A4 03A203A6 00000002
034714: 03A603AB 03A603A6 0000000D
034718: 03B203B7 03B203B6 00000001
03471C: 03C403CE 03C403C6 00000008
-
034F00: 00180000 00180006 00000006
034F04: 00000180 00000186 00000006
034F08: 00000000 00000006 00000006
034F0C: 00000000 00000006 00000006
034F10: 00038000 00038006 00000006
034F14: 00000000 00000006 00000006
034F18: 00000000 00000006 00000006
034F1C: 00000000 00000006 00000006
-
035700: 0079AB2C 0079AB26 0000000A
035704: 032B3424 032B3426 00000002
035708: 24DA0019 24DA0016 0000000F
03570C: 83300000 83300006 00000006
- ;; Curious
035714: 2CC0169E 2CC01696 00000008
035718: D9800003 D9800006 00000005
03571C: 30010C00 30010C06 00000006
-
035F00: 01070104 01070106 00000002
035F04: 01070108 01070106 0000000E
035F08: 02080108 02080106 0000000E
035F0C: 01080108 01080106 0000000E
035F10: 01080108 01080106 0000000E
035F14: 01080108 01080106 0000000E
035F18: 01080104 01080106 00000002
-
036700: 00000000 00000006 00000006
036704: 00000000 00000006 00000006
036708: 00000000 00000006 00000006
03670C: 00000000 00000006 00000006
036710: 00000000 00000006 00000006
036714: 00000000 00000006 00000006
036718: 00000000 00000006 00000006
03671C: 00000000 00000006 00000006
-
036F00: 0F0000FF 0F0000F6 00000009
036F04: F0FFFFF0 F0FFFFF6 00000006
036F08: FFFFF000 FFFFF006 00000006
036F0C: FF0F00F0 FF0F00F6 00000006
036F10: FF00FF00 FF00FF06 00000006
036F14: F0000000 F0000006 00000006
036F18: 000000FF 000000F6 00000009
036F1C: FFF0F00F FFF0F006 00000009
-
037700: 015F0163 015F0166 00000005
037704: 0168016F 01680164 0000000B
037708: 01740178 01740176 0000000E
03770C: 017C017F 017C0176 00000009
037710: 01800183 01800186 00000005
037714: 01880188 01880186 0000000E
037718: 018D0192 018D0196 00000004
03771C: 0197019B 01970196 0000000D
-
037F00: 00000000 00000006 00000006
037F04: 00000000 00000006 00000006
037F08: 00000000 00000006 00000006
037F0C: 00000000 00000006 00000006
037F10: 00000000 00000006 00000006
037F14: 00000000 00000006 00000006
037F18: 00000000 00000006 00000006
037F1C: 00000000 00000006 00000006
Last edited:
Boctor
Well-known member
Thanks, I may stick with using the ROM SIMM slot for the time being, knowing that. After my fight with the axials, I think further through-hole on the IIcx will require some more practice. Even with a desoldering gun, I was pretty much scorching the pads around those holes before their contents would fully melt, so those power/ground planes in the middle layers must be seriously beefy.
Similar threads
