Macintosh IIcx slow chimes of death; diagnostic return code 0000FFFF0001.

[Boctor]

I recently got a scrap Mac IIcx, mostly to get its case for a different project, but still tried to clean and recap the board to see if it could boot. I did not attempt to power this logic board at all until the recap and washing/drying were all done, in case stray goo fried anything. The battery was on the verge of leaking, with a brown spot forming on the edge and terminal, which I quickly neutralized and cleaned off before disposing of it. All of the caps are on and have the expected continuity, with C4 and C11 notably tripping my multimeter's continuity tester, but the pads for these were making it beep already, so I know they are not solder bridged. I lifted and resoldered them to be extra certain of this before powering on. Some of the legs on the ICs in the power circuit are dull-looking, as are the ROM legs, and the rear ports are superficially pretty corroded/rusted. However, I did not see any green on any ICs.

After a final clean of the board, a rinse in isopropyl, and a long dry, followed by checking all the connections again, I powered it on using a known good PicoPSU with a ten pin adapter. As soon as I threw the switch on the PicoPSU, I got immediate slow chimes of death. I was doing the first test without RAM, so I expected the normal chimes and knew something was up. I put in four known good 1MB SIMMs and got the same issue. I do not have a NuBus video card on hand nor a PRAM battery, but from what I've seen searching here, neither of these should be necessary to get a normal chime(?) Checking the diagnostic mode over a null modem showed return code 0000FFFF0001. I see that the '01' status is a "ROM checksum error," according to this archive of the only informational page I've seen for the diag mode. However, I'm unsure how much of this applies or is reliable. I cannot find any obvious continuity problems with the four ROM ICs. I also put in a spare SE/30 ROM SIMM and the result did not change, so I'm curious if this could be a less obvious issue such as a bus transceiver.

Does anyone more familiar with the IIcx have an idea what could be wrong, or any similar experiences? I'll attach some hi-res photos, but note that the few dubious looking traces on here all beeped out fine when I checked, unless there are even more that I've missed. This machine looks like it sat unused for decades, so I have no idea about its history, why it was partially gutted, or whether the logic board was working at all when the last owner stored it. Compared to the dusty, dead spider-covered state it was in when I got it, it at least looks close to working, though that obviously doesn't count for much when a mystery component is probably fried.

Edit: I did check the ROM socket with the frequency tester on my multimeter, and saw various, stable frequencies from each pin. None appeared to be dead/disconnected.

 

[zigzagjoe]

If it is throwing a rom checksum error, simplest possible explanation would be a bad ROM IC if continuity seems good. Other causes are possible too, but this one is easy to test as you could drop a module in the ROM socket (and remove the onboard ROM jumper) and see if that makes it able to get further.

 

[volvo242gt]

The IIcx I had in 2013 acted the same way when it was booted on the internal ROM. Had a IIfx module and tried that. It booted without issues. Might be worth trying a IIfx ROM SIMM or a ROMinator II in there.

 

[SuperSVGA]

If switching to another known good ROM set doesn't work then it's probably an addressing issue. You're clearly getting far enough into the ROM for it to run tests, meaning all four ROMs are are working up to that point, but perhaps because of the address line issue the rest of the ROM space is unreachable.

You can try running a test on the individual ROMs just to rule that out:

*A
*4
*T000400010000
*R

This will return which of the four ROMs it thinks has failed.

 

[Boctor]

If switching to another known good ROM set doesn't work then it's probably an addressing issue. You're clearly getting far enough into the ROM for it to run tests, meaning all four ROMs are are working up to that point, but perhaps because of the address line issue the rest of the ROM space is unreachable.

You can try running a test on the individual ROMs just to rule that out:

*A
*4
*T000400010000
*R

This will return which of the four ROMs it thinks has failed.

Thanks for the working example, it looks like it may have produced useful output.
From picocom's output on my PC (top line's obviously from the terminal itself and not the IIcx):
*** local echo: yes *** *A*A *4*4 *T000400010000*T *R000000020000*R

I've never gone beyond checking for signs of life or the initial return status before, so I'm still trying to figure out what this value could mean.
Out of curiosity, I ran a couple other critical tests. The data bus test (01) returns R121515280000 and the address line test (03) returns R50F040000000.

 

[SuperSVGA]

Since it's returning 2 that means it's the second ROM (I think that would be MH, I can't remember) that failed checksum and the others all tested fine.

 

[Boctor]

Since it's returning 2 that means it's the second ROM (I think that would be MH, I can't remember) that failed checksum and the others all tested fine.

I looked at the traces a bit more, comparing them to hi-res scans and the PCB layout for the reloaded PCB on github, and didn't see anything. I think regarding which ROM/address is bad, you're probably right, assuming the return value itself is correct. I put the SE/30 ROM in again, took off the jumper so it'd use the slot instead of the four chips, and got a happy chime with 4x1MB in bank A. I'm hoping this implies a simple ROM chip is bad and not any lines. I then added 4x1MB more to bank B and got a happy chime once more. I am unsure why having only B filled with the SE/30 ROM last night gave death chimes, but if I had to guess, I either configured it wrong or didn't scrub the slots with enough alcohol before. (Not the first time that contact issues have given me a scare. I once had the PDS on my SE/30 go haywire and produce a stutter-looping, "stuck" death chime until I reseated the card!)

No more unwanted surprises at this time, but I've yet to test video or actually booting into Mac OS, as the NuBus video card I bid on won't show up for a week or so more. In the meantime, thanks to everyone so much for the troubleshooting suggestions and guidance up to this point. Even with simple things, getting a sanity check from experienced people is priceless. I guess I'll search for a ROMinator and keep my fingers crossed. Worst case scenario, even if this IIcx suddenly turned into a pile of ash, my SE/30 can use the ROMinator and my IIsi can use the video card.

As an aside, is it possible that the built-in ROM was always wonky on this board? For a long time, people had been saying that IIsi's with bad ROMs would have the jumper set (works inverse on there I think) and a SIMM inserted to their slots at the factory, rather than using up more time reworking. Were the other Macs with soldered+slot ROMs like the IIcx and IIci treated similarly?

 

[Boctor]

This is kind of an odd question, but is NuChip support dependent on special code that's absent from the stock SE/30 ROM? If so, then I imagine I'll need to order a ROMinator or similar, before trying any NuBus cards. For that matter, I wonder how much of the IIsi's NuBus awareness is in the ROM, and how much (if any) lives on that optional PDS->NuBus riser card.

 

[Addicted]

I would have to let more knowledgeable restorers comment to be sure, but I think the IIcx requires memory in Bank A or the memory sizing and bank configuration will fail. I know nothing of the SE/30, however, and maybe its bank detection code is compatible with the hardware on the IIcx and frees it of that constraint?

I have brought one IIcx back from the bad chime by desoldering and re-soldering the ROM pins. I am a novice in electronics, but if I understand, what passes a DC continuity check might not be reliable at tens of megahertz. For RAM, I also reflowed all the pins on the banking logic UH1 - UJ3 plus UG7. I did a lot of other reflowing in general (the entire CPU, the entire FPU, the Nubus socket pins) so, this is not necessarily what solved my problem.

@SuperSVGA -- may I ask where I can learn about those test commands? Are they MACSbug or ROM monitor commands? Etc. I have a IIcx that is (almost) stable on ROMinator but sad chimes on the board's ROM, and such commands might be the clue I need.

 

[Boctor]

I would have to let more knowledgeable restorers comment to be sure, but I think the IIcx requires memory in Bank A or the memory sizing and bank configuration will fail. I know nothing of the SE/30, however, and maybe its bank detection code is compatible with the hardware on the IIcx and frees it of that constraint?

I moved the RAM from bank B to A before getting it to work for the first time, so actually, you're probably right! I'd seen people seemingly boot IIci's with only B filled so I was confused. Furthermore, 24-bit ROMs do slow chimes for a RAM failure, where later 32-bit clean ROMs seem to play it at a normal tempo. The first time I had the SE/30 ROM in and the corresponding jumper properly set to use it, I'd only put 4x1MB in bank B and got the same slow chimes, so I wrongly assumed the failure was the same. As soon as I cleaned the slots and moved everything to bank A with the SE/30 ROM still set, that was when it chimed. I was worried it'd become flaky or bank B might still be bad, but I added four more megs to it and the machine has been starting up reliably every time. I can hear the speaker quietly pop after the power-on RAM test, too. That predictable sound you might notice in the boot process, when the round corner bitmaps and the cursor first appear. I guess the non-audiophile quality of these machines has some practical uses after all.

Last night, I connected my good IIsi Sony PSU, and confirmed that the soft power circuit was working great. I was most worried about that area having bad ICs because of the number/proximity of capacitors. A known good SuperDrive worked with floppies and spat the bad ones out when inserted. I was then able to get the nag/warning beep from an improper shutdown on purpose, to verify booting "to desktop" from BlueSCSI and System 7.5.3, even with no way to connect a monitor. This leaves ADB and NuBus as the final major pieces I can't yet test, until the ROM and video card finally arrive... Unless anybody knows how to make noises with a mouse and keyboard, or make the SE/30 ROM talk to the NuChip/VIA2(?).

 

[SuperSVGA]

@SuperSVGA -- may I ask where I can learn about those test commands? Are they MACSbug or ROM monitor commands? Etc. I have a IIcx that is (almost) stable on ROMinator but sad chimes on the board's ROM, and such commands might be the clue I need.

It's through the serial testing interface that's available in pretty much every single Macintosh with a serial port since the SE. The general method of accessing it is by connecting to the modem port with a serial terminal of some sort (for example a modern computer and a USB to serial adapter), and then you can access it when the machine is crashed to a sad mac. If you're writing a program for it you can also access it with the _TestManager trap.

Once you're in there you have around 7 to 40 built in tests you can run, but you can also directly read/write/execute memory so you can run pretty much anything from there.

 

[zigzagjoe]

This is kind of an odd question, but is NuChip support dependent on special code that's absent from the stock SE/30 ROM? If so, then I imagine I'll need to order a ROMinator or similar, before trying any NuBus cards. For that matter, I wonder how much of the IIsi's NuBus awareness is in the ROM, and how much (if any) lives on that optional PDS->NuBus riser card.

It is transparent from the software perspective. Mac OS doesn't know there's any difference from a Nubus card to a PDS card, or anything about the interface to the Nubus. It just knows to look for ROMs in particular address spaces and certain fixed assumptions about those address ranges, but in the early (discrete GAL or NuChip) implementations there aren't any actual registers that the ROM tweaks on. I suspect the later versions are similar where any advanced nubus features are all handled in the hardware.

So the IIsi card is purely a bus interface adapter with no code.

 

[volvo242gt]

Under System 7.5.1 and newer, you can hit the power key once it boots up. That brings up the shut down/restart dialog box with a beep. Hit return after the beep, and it should shut down.

 

[Boctor]

Under System 7.5.1 and newer, you can hit the power key once it boots up. That brings up the shut down/restart dialog box with a beep. Hit return after the beep, and it should shut down.

Great idea, I'd completely forgotten about that dialog! (I didn't even own a Mac with working soft power until a week ago.) The lock lights work as expected, the beeps and pressing return to use the default/selected dialog option work as expected. Both ADB ports, though the metal shields on them are superficially tarnished, are working just fine! The plugs go in and out just as on my other Macs, and the insides are still in nice shape.

This only leaves NuBus inconclusive, unless there's also a clever way to do a basic test of that. Like I said before, though, stuck with a spare SE/30 ROM for the time being, so I'm not sure how NuBus should behave in the first place, if at all. I hope the relevant chip is at least good. Much easier to bodge wires for a funky line than it is to lift and drag-solder something with so many little legs...

 

[zigzagjoe]

Great idea, I'd completely forgotten about that dialog! (I didn't even own a Mac with working soft power until a week ago.) The lock lights work as expected, the beeps and pressing return to use the default/selected dialog option work as expected. Both ADB ports, though the metal shields on them are superficially tarnished, are working just fine! The plugs go in and out just as on my other Macs, and the insides are still in nice shape.

This only leaves NuBus inconclusive, unless there's also a clever way to do a basic test of that. Like I said before, though, stuck with a spare SE/30 ROM for the time being, so I'm not sure how NuBus should behave in the first place, if at all. I hope the relevant chip is at least good. Much easier to bodge wires for a funky line than it is to lift and drag-solder something with so many little legs...

SE/30 uses the same ROM as IIcx, and IIx, so Nubus should work just fine. However, no way to test the nubus interface directly (see prior post on NuBus hardware being transparent) so you can only test by using a NuBus card.

 

[Boctor]

SE/30 uses the same ROM as IIcx, and IIx, so Nubus should work just fine. However, no way to test the nubus interface directly (see prior post on NuBus hardware being transparent) so you can only test by using a NuBus card.

You're right! I just plugged my NuBus Asante Ethernet card again, but this time I actually got the TX/RX LED and the auto-sense/media one that turns on when anything is connected. I must've been overthinking about accidentally breaking something last night, and not plugged the card or the RJ45 jack in all the way, whoops! Now I see it intermittently blinking when I have AppleShare enabled on my testing 7.5.3 image.

I guess if these systems all use the same ROM (really useful tidbit, thanks again for confirming this in specific!), I'm really only waiting on that E-Machines video card to test further. Oh, and the requisite 10-dipswitch adapter.

 

[Boctor]

The video card is working great. Stereo sound and music work, as does networking. I haven't had it crash or behave strangely at all, except when I run Apple Personal Diagnostics. The "logic board components" test fails after a long time for no apparent reason, and gives me no useful details in the report. I am not sure if the E-Machines Futura SX card or something about my configuration is causing this, or if running it under System 6.0.8 can make things erratic. CPU/FPU/RAM/PRAM/SCSI/RTC tests all pass in Snooper 2.0. What does APD test about the IIcx that's different? Surely it can't be the ROM again, if those are selected with a physical jumper. Unless me using a ROM plucked from my SE/30 is somehow tripping it up? I've seen reports that putting a PurpleROM in a IIx does the same thing, but if the SE/30, IIx, and IIcx all use the same ROM, byte for byte, I'm not sure exactly what's happening here, and might need clarification from an expert. Only APD complains, no other tests do this.

Normally when I've had misbehaving logic boards, the issues have always been something like the Sony sound chips having bad traces, and things would crash or show bus errors when they normally shouldn't. I'm unsure what, if anything, is going on here.

Edit: Since I do not see this mentioned when the card itself is being discussed, some limitation of System 6 prevents the Futura SX from going over 8-bit color in 640x480, and over 4-bit color in 1024x768. Boot into System 7, however, and it will work as expected.

 

[Boctor]

Sorry for the double posts, I'm still trying to figure out why APD's Logic Board components test is failing. It's not my memory, extensions, or system software, all of which I've ruled out. I've also verified that the IIx family ROM always has the checksum $97221136 so it's not that either. I've still had zero bomb errors or unexplained crashes/freezes of any kind.

The only thing that sticks out to me is that it's taking an unusually long time to finish this test on the IIcx. It feels like a full minute at least, before seemingly timing out. On my IIsi and SE/30, the LB components test finishes in a couple of seconds. Has anyone seen this symptom before? It seems like it's a telltale sign of something.

MacTest Pro does not stall or time out at all and passes its "Logic Board Components Test" with flying colors. What gives?

 

[Boctor]

Invisible to the eye without a big lens, but one of the traces that was hardly rotten looking was bad. The break must've been hidden under an oscillator, which I was afraid to bend too far. It was the exact same fault as what was already found in this thread! Same legs on both Y4 and the RTC chip, so the 1hz clock source was all fouled up. After soldering a carefully-sized bodge wire across the underside of the logic board and cleaning up, all APD tests now pass with their expected timings.

I still wish that Personal Diagnostics had said, "Real time clock test failed," or something specific enough to be useful. MacTest Pro didn't even care, and Snooper even said the RTC was fine, though it seemed to be mostly storing/retrieving dates and not checking for seconds elapsing.

 

[Boctor]

Final(?) update, and hopefully with enough time in between for replying to myself not to be spammy. I finally bit the bullet and bought a universal ROM flasher/programmer, so after coming a long way, my IIcx has closure!

The flashing software was featureful enough to load the second bytes out of every four (DWORD) of the deinterleaved stock ROM file, and I burned this onto an AT27C512R. For fun and for education, I also did the obligatory diff between the bad chip and the good ROM, and they indeed differed. Big thanks again for pointing me straight at this component, as those diag ROM return codes make my head spin. I've got three more sockets on hand now, just in case the mask ROM curse claims another.

I wish accelerators for this thing were easier to come by. I know the SE/30 and IIx Socket Booster would work perfectly and is well worth its cost, both for supporting its creator and the nice performance gain, but I don't want to destructively mod the plastic drive carrier to fit it. Still, adding a proper CPU socket to this machine was an exercise in frustration, so it would be nice to exploit it one day.