IIci gives sad chimes with SE/30 ROM, silence with ROMinator and onboard ROM

[jckarter]

Hi everyone! I've been trying to bring a IIci back to life that had pretty severe battery and cap damage. It looks like this computer had been stored vertically, but with the battery end high, so battery juice dripped downward through all of the ROMs and SIMM slots. I managed to do all the usual recapping, replace the rusted-out 50MHz crystal and battery holder, get the old SIMM slots desoldered, and cleaned up the crud on the board underneath. Continuity still looks good from the RAM eyelets to the rest of the board. As a checkpoint before soldering in new SIMM sockets, I wanted to see whether I could get the sad Mac chimes, which AIUI should still happen even with no RAM installed. I powered up the board and got silence, and I chalked that up to the ROMs being dead from the battery damage. Sure enough, I grabbed an SE/30 ROM SIMM I had lying around, installed it, pulled off the ROM select jumper, and I got the chimes like expected. So I installed new SIMM sockets in Bank A, threw in some SIMMs and a ROMinator, and…got silence again. But sure enough, when I put the SE/30 ROM in, I get the sad Mac chimes as I did before (which, from reading other threads, sounds like it's expected trying to boot an SE/30 ROM on a IIci, whether there's RAM installed or not).

Now there was a fair amount of corroded solder pads all over the board from the caps in addition to the battery damage, so there could well be other damaged ICs on the board. The fact that the SE/30 ROM is able to give chimes suggests that the CPU and ROM data paths are good, so I'm curious what's different between the SE/30 and IIci ROMs that could cause the latter to fail before it gets to the chimes, to hopefully narrow down where I need to look. AIUI, the IIci ROM and the ROMinator are based on a "universal" ROM with setup code for a bunch of different Macintosh models, so it must need to do some sort of detection to determine which code path to use.

 

[Phipli]

so I'm curious what's different between the SE/30 and IIci ROMs that could cause the latter to fail before it gets to the chimes,

ROMs check the machines identity and the SE/30 predates the IIci, so it doesn't know what the IIci is.

 

[joshc]

Can we see some photos of the logicboard, front and back please?

 

[bigmessowires]

The ROM-inator is modified Macintosh IIsi ROM. I couldn't tell you why it and the IIci ROM are silent while the SE/30 ROM gives chimes of death, sorry. It may just be the luck of how data is organized in ROM versus which address lines on your logic board are broken.

 

[jckarter]

Can we see some photos of the logicboard, front and back please?

Sure! Here’s how it looks right now. From where it started, I’ve so far replaced all the electrolytic caps, the 50MHz oscillator, the battery holder, the two diodes and 32.768khz crystal for the pram, and the bank A SIMM slots. One of the vias for the last Bank B slot was unfortunately just a little too rusted and broke off while I was desoldering the old SIMM slots, so pin 28 there will definitely need a bodge, but otherwise the other RAM pins all buzzed out OK after all the surgery. I haven’t gone too far yet in buzzing out the rest of the board. The battery acid weakened the solder mask pretty badly, and some chunks flaked off the larger ground planes. It's definitely possible some traces got eaten somewhere too, though I haven't been able to eyeball any yet.

I did manage to track down a disassembly of the IIsi ROM, and looking through the GetHardwareInfo implementation, it doesn’t look like there’s any backstop to halt the machine or make a sound if detection fails. So it makes sense that it would quietly loop forever if there isn’t enough working hardware to be detected correctly. At a high level it looks like it probes the VIA a bit to figure out whether the machine is GLUE or MDU based, then checks the base addresses for various devices like the RBV, SCC, and so on from the matching machine descriptor to make sure there’s a match. The pins on the VIA itself don’t look too bad on this board, but it is pretty close to a big cluster of electrolytic caps, and those logic chips nearby were pretty blue with corrosion when I started. I might start poking around up there.

 

[joshc]

Quite a few bad/damaged traces there that might need to be looked at. Not sure where these go but worth checking them

 

[jckarter]

Quite a few bad/damaged traces there that might need to be looked at. Not sure where these go but worth checking them

View attachment 63687

Good eye! Thanks for the tip. I traced those out and they look OK; the outer three go to the speaker, which I know works, and I got continuity between eyelets on either end of that inner trace.

I buzzed out the VIA and iffy-looking RTC and both look OK. I also checked the UB13/UD13/UE13 logic ICs which had been hit pretty bad with cap juice. UB13 and UD13 look OK, but UE13 was missing a few connections that Bomarc’s schematic says should be there, so it might be dead. From the schematic, it looks like its primary role is the signal path for the power button, which might explain why the computer turns itself on intermittently when the power supply is plugged in, but doesn’t seem like it would prevent booting. I’ll keep poking around.

 

[jmacz]

Doesn’t the ROMinator disable the memory check at startup? I thought that was one of the benefits, to skip the memory check so large memory systems boot faster. Would that explain the possible lack of bad chimes on boot? My guess is the onboard ROM is shot. @Phipli mentioned the SE/30 ROM might not recognize your IIci. And the ROMinator is skipping the memory check and maybe your system is dying on the memory? I know you mentioned you buzzed it out but maybe there’s still something wrong there.

Another thought … I had a similar issue where during the repair of my bombe IIci, I was also getting lack of good chime, and just a gray screen. I had an out of issues in the corner with the sound chips. UB2, UB3, UA4, UA5, UC4, UC5 for me had trace issues, lifted legs, cap goo corrosion. I had to thoroughly clean and resolder each pin on all those chips.

I had found this note from Bolle mentioning the Sony sound chips UB2/UB3 participating playing a role in the system properly coming out of reset.

Post in thread 'IIci with potentially dead 50MHz oscillator.'
https://68kmla.org/bb/index.php?thr...ially-dead-50mhz-oscillator.34985/post-378106

Looking at your picture there is still some green funk in that quadrant of the board so you might check those sound chips there?

 

[jckarter]

Good point. If the ROMinator doesn't even check for the complete lack of RAM, then it could well be that I'm seeing broken on-board ROMs, fundamental incompatibility with the SE/30 ROM, and RAM issues with the ROMinator. I spent some time last night trying to clean up and reflow the joints on UB3 since it looked pretty grody, but that didn't seem to help much. The fact that the SE/30 ROM is able to chime seems to suggest that the ROM SIMM, CPU, MDU, and sound chips have to be working to some degree.

Even though I haven't made much progress on boot, I did have a few other small victories: I thought the reset line may have been broken, since the reset button wasn't doing anything, but it turned out that the button itself was just oxidized inside. Shooting deoxit into the button and pressing it a bunch of times seemed to clear it up for now, but I should probably replace the buttons since the NMI button seems to be shot completely. I also finally got the onboard video to show the gray screen on my Dell 2001FP by fiddling with the DIP switches on my VGA adapter. In case anyone else runs into this problem, the magic switch setting that worked for me was 145, or 640x480 66Hz with composite sync. I have to set the IIci aside for a week or so before I can look at it again, so maybe I'll order some replacements for the various 74* ICs so I can try swapping them out when I get back. Maybe I should chop off the onboard ROM chips, at least so I can clean up any dried up battery gunk underneath them.

 

[bigmessowires]

If the ROMinator doesn't even check for the complete lack of RAM

Yes, the RAM test is disabled to speed up booting. If you have a SIMM programmer, you could reprogram a stock IIci ROM and see if it helps with your troubleshooting. Your conclusions so far sound pretty reasonable to me. I think I have a 512 KB programmable ROM SIMM around here somewhere that's pretty useless to me, I could put the stock IIci ROM on it if you think it would help you.

I also finally got the onboard video to show the gray screen on my Dell 2001FP by fiddling with the DIP switches on my VGA adapter. In case anyone else runs into this problem, the magic switch setting that worked for me was 145, or 640x480 66Hz with composite sync.

If you haven't seen my never-ending thread "Mac to VGA Monitor Adapter Struggles", it's about this exactly. The IIci and IIsi output composite sync for this video mode, while most other Macs have separate H and V sync signals. I'm trying to design a VGA adapter with an integrated sync splitter.

 

[jckarter]

Just to experiment, I tried putting a few sets of RAM SIMMs into Bank A since I had those soldered up. Unfortunately I didn't have any sets that are definitely known good. I had a couple sets that came with my SE/30 before I upgraded it, but they might be too slow for the IIci since the SE/30 only needs 120ns but the IIci wants at least 80ns. I also have the two sets that this IIci came with, but all of the SIMMs got some amount of battery goo on them, and the ones nearest the battery had their contacts eaten clean off. I tried the set that was further away from the battery originally. Unfortunately none of the sets made any difference. I had only buzzed out the SIMMs to their resistor pack pins, though, so I should check for continuity all the way to the MDU in case there's trace damage on that end, or some of the resistors inside the packs got eaten away.

 

[jckarter]

Yes, the RAM test is disabled to speed up booting. If you have a SIMM programmer, you could reprogram a stock IIci ROM and see if it helps with your troubleshooting. Your conclusions so far sound pretty reasonable to me. I think I have a 512 KB programmable ROM SIMM around here somewhere that's pretty useless to me, I could put the stock IIci ROM on it if you think it would help you.

I appreciate the offer! Let me see how far I can get double-checking the SIMM slots and replacing the logic ICs first.

 

[jckarter]

I had some time again to look at my IIci board again. I rechecked the continuity from the RAM SIMMs to the F245s, the CPU, and the MDU and so far the traces in that region still all look fine. I did manage to find a broken trace in the startup circuit: pins 3 and 4 on UE13 are supposed to be connected, but the connection from pin 4 was broken. I replaced it with a fresh 74HC132 and bridged pins 3 and 4, and that did stop the computer from turning itself on shortly after supplying power to the power supply, so that’s small progress.

I also started poking around with a scope, checking for clocks, and I noticed that the 40MHz crystal at Y7 wasn’t oscillating; although it looked OK from the top, sure enough when I tried to desolder it, one of the pins was rusted and crumbled away, and there was still battery goo underneath. I cleaned that up and put in a fresh crystal; that still didn’t help the computer boot, but hopefully I’ll be closer to having working NuBus slots once I do get the rest of the machine going.

 

[bigmessowires]

If the ROMinator doesn't even check for the complete lack of RAM, then it could well be that I'm seeing broken on-board ROMs, fundamental incompatibility with the SE/30 ROM, and RAM issues with the ROMinator.

You're getting chimes of death with an SE/30 ROM SIMM, so you know that the SIMM slot works at least that much. You might have a broken on-board ROM - can't rule that out yet. But with the ROM-inator, if you had RAM problems but everything else was OK then I think you would hear chimes of death. So maybe your theory is right that it's failing on hardware detection and then looping forever. A stock IIci ROM in the ROM SIMM slot might help.

Another possibility is that some of the higher order address lines to the ROM SIMM socket are broken. And those higher addresses aren't needed in order to get the SE/30 ROM to the point where it plays chimes of death, but they're causing the ROM-inator to fail. You might try testing continuity between the ROM SIMM socket higher address lines and the CPU or other chips where those same lines appear.

Regarding RAM, I think you should hear chimes of death even if no RAM is installed.

 

[jckarter]

The onboard ROMs were definitely toast—I snipped them out and a bunch of the pins were just rust and crumbled away when I went to cut them. The SIMM slot however seems to be OK; the address lines all look good going to the CPU, and I didn't pick up any shorts across the lines. If it is failing in hardware detection, from my understanding of the ROM code, that suggests a problem with the VIA. It looks like the hardware detection routine determines which decoder (GLUE or MDU) to use based on where in address space it's able to probe the VIA, and then some of the IO lines to match the specific model. The VIA on this board visually looks fine, with none of the legs visibly tarnished, but it's still in the neighborhood of the big cluster of electrolytics that also ate the startup circuit ICs so there could definitely be other problems in that area.

 

[bigmessowires]

Did you remember to remove jumper W1 when using the ROM SIMM? I'm still happy to send a 512K SIMM with the stock ROM if you think it might help. I don't know if it behaves any differently than the IIsi ROM with regards to hardware detection. I suppose if it worked far enough to play chimes of death, it wouldn't really tell you anything that you don't already know.

 

[jckarter]

Did you remember to remove jumper W1 when using the ROM SIMM? I'm still happy to send a 512K SIMM with the stock ROM if you think it might help. I don't know if it behaves any differently than the IIsi ROM with regards to hardware detection. I suppose if it worked far enough to play chimes of death, it wouldn't really tell you anything that you don't already know.

Yeah, W1 is open, and it tests open with the multimeter so there isn't any short. I walked through the first stage of ROM startup in the MAME debugger's IIci emulation, and while an instruction is different here and there, the detection routines still look close enough that I was able to follow along in the IIsi disassembly (which the ROMinator is based on AIUI), so I suspect the behavior would be the same with a stock IIci ROM.

 

[jckarter]

I poked around a bit more last night, removing the VIA and checking continuity. There wasn't any goo trapped underneath, and all of the pins appear to be connected appropriately according to the Bomarc schematics, with one minor exception: Bomarc shows pin 23 (IRQ) having a 1K pull-up resistor to 5V, but on my board it measures as only 500 ohms; probably not a big deal. I was curious about how the PA1, PA2, and PA4 pins are wired up; these are the pins that are used to identify the board as a IIci, with PA1 and PA2 expected to be pulled up, and PA4 pulled down on a no-parity board and up on a board with the PGC. Bomarc doesn't show anything for PA1 or PA2, and only shows PA4 being pulled down to ground through a 220 ohm resistor. On the board, the PA1 and PA2 pins go directly to a via underneath the chip, which comes through to the back of the board with no trace on the back layer. Checking continuity from either of these pins to either 5V or ground reads as completely open, so are they simply left floating and pulled up internally by the VIA? If PA4 goes high with a parity generator present, I would also expect there to be a connection to one or more of the PGC's pads, but I couldn't find a connection from PA4 to any pad there that read less than the 220 ohms pulling the pin down. Are there folks here who have reverse-engineered the board any more deeply?

I was able to get another IIci logic board for free from a coworker that looks like it's only got some minor cap damage, so I ordered another set of replacement caps. I'm hoping I can get this new board back into working order with just a recap, and if it works, that will at least let me test some of the hypotheses here about how the stock ROM and/or ROMinator on a good board behave in the absence of any working RAM. Since I have the VIA off the battery-damaged board already, I also ordered a W65C22N6TPLG-14 to try as a replacement. At least externally, nothing appears to be wrong with the original VIA, but I figure it's worth a shot, since it doesn't seem like there would be anything else that would prevent the ROM from failing to get to sad chimes in the disassembly. (There could of course also be some subtler issue with the MDU, select lines, or address lines not showing up with only a continuity checker.)

 

[bigmessowires]

Checking continuity from either of these pins to either 5V or ground reads as completely open, so are they simply left floating and pulled up internally by the VIA?

Take a look at the Port A buffer schematics beginning on page 32 here: https://www.mouser.com/datasheet/2/436/w65c22-1197.pdf

For the W65C22N, it looks like there's a resistor in the high side of the output. So if the chip drives a 1 output it's a "soft 1", and it can be safely pulled low to 0 by external logic. Basically an internal pull-up. So I'd guess what you're seeing there is normal.

 

[jckarter]

I got that other board recapped, and it's in much better shape than the first! I got to do some experiments. With the onboard ROM and no RAM installed, it gives the boot chime followed quickly by the sad arpeggio. With the ROMinator, it gives silence. So that suggests that, if it isn't the VIA on the other board, that there could also be an issue with the RAM, the F245 buffers, or something else along the way.