[vcf-midatlantic] Mac IIci, dead (PICS!)

Ethan O'Toole telmnstr at 757.org
Fri May 14 15:33:17 UTC 2021

> What I get from this response, is simple. "no activity from data lines on 
> PROM" says the CPU isn't likely running - game over. (I presume he's using an 
> oscilloscope, not a logic probe.)

Yeppers. DSO.

> I'd say follow the reset line to the CPU reset pin (it's a tiny surface-mount 
> package, hard to probe). You can check the data lines on the on-board RAM. 
> Look at the chip enable on the ROM. Things like that. Looking at fundamental 
> signals - reset, chip enables, general data/address line activity - is a good 
> "cold" approach.

That is what I was thinking. I assume it's toggled on startup but I don't 
know. I just know that is a thing on the Atari 800XL I was troubleshooting 

> As for monitoring the video signals: The IIci/cx will "run" without a monitor 
> connected, that's my experience. So, without a Mac monitor, one can simply 
> monitor the video outputs (say some sync line) for general activity. Possibly 
> a good use for a logic probe, or one can make up a R/C circuit on an LED just 
> as a convenient 'dongle'.

I tried a floppy disk thinking that I would see it hit the floppy drive in 
case the sound is bad and I'm not really seeing video. My friend probably 
has a real Mac monitor, he has a lot of classic Mac stuff.

> While it's possible Ethan can get lucky, and find some opens or shorts; I 
> don't know of a clear path to diagnose other Mac problems likely due to 
> corrosion and spread of capacitor-goop. Any physical fault is likely to be 
> unpredictable, arbitrary. There is likely several and not just one. One would 
> have to be very methodical, to track them all down.

On my Yamaha 286 portable, the issue turned out to be the vias not 
conducting. The traces looked fine but the vias had absorbed some funk 
from the leaky caps. There is a decent chance it's the same issue with the 
IIci. But none seem to be that bad. I will have to map out each bad spot 
and try to figure out it's function.

> But who knows? Maybe the ROM has a POST program that goes to HALT if there's 
> any detected faults? I certainly lack complete knowledge on 68K processors 
> and Apple ROMs. In that particular case, one might replace the ROMs with 
> wired-up IC packages with pullup pulldown diodes to simulate a 68K do-nothing 
> instruction. That forces the processor to run the address space. It's an 
> old-school diagnostic.

Over on the Amiga side there is more of a hacker community around the 
systems and there is a Kickstart ROM replacement called the DiagROM. 
DiagROM drops in place and then it spits out of the RS232 port a text log 
as it tests functions on the system. Unfortunately the Mac doesn't have 
this kind of stuff yet, and if it did it's 4 PROM chips that aren't 
socketed versus the single or dual socketed ICs on the Amiga.

> By the way: this is the difference between 1990's computing and pre-1980 
> computing. With 1980 computing, component level repair *is* possible because 
> most 1980 computers were intended for chip-level repair and contain 
> human-sized components of a simpler nature; and have circuits one can isolate 
> and diagnose.

Yea. True. It's possible to home swap these chips though. On the Amiga 600 
that I was trying to repair the RAM and main chips are all SMD. Hot air 
and paste works wonders, and if you can get the right amount of paste 
going it's MUCH quicker to resolder the SMD ICs in! So... don't fear the 

The IIci seems like a relatively basic board. The chips are SMD but it's a 
pretty clean board and not too crazy. The real difficult part is that the 
power supply humps the main board without any real interconnect, so it's 
in the way unless you make an extension cable or take it apart and hang 
the connector out (I haven't done either yet.)

> The Macs, all post 1984, were built by robots, with surface mount, on 
> multilayer PC boards. If they were serviced at the chip level that was done 
> "at the factory" and not by service techs in the field. I've seen no Apple 
> documents on chip-level repairs (but I've not looked hard). But that reminds 
> me ...
> "Sam's Photofacts" were third-party field-service booklets in the era. 
> Checking ... Nope, no Mac IIci or IIcx books, in fact no Mac repair books 
> from Sams at all (samswebsite.com). I'm aware of them for Apple II's and for 
> other consumer computers (C64's and such).

I found the IIci schematics from some 3rd party. Hand drawn, and they're 
on Archive.org for all. So that is a help. That is where I got the info on 
the reset, and the oddity that the reset apparently goes thru pin 6 of 
both audio chips. Maybe to clear DACs or something.

> What remains, are Mac schematics and repair activities established over time 
> by techs; and "how to recap" activities. To be honest, I've not looked deep 
> on the Web, to see how far those resources can take someone for chip-level 
> repair on Macs. (shrug) if Ethan finds resources I'd like to hear about them, 
> as I work with 68K Macs all the time (but not to repair components for 
> reasons cited).

There is love for the Mac stuff but it doesn't seem to be as deep or 
detailed as the Amiga or 8bit stuff.

And of course anything I figure out, I will share! It's my goal to make it 
work again. That is the challenge.

> I hope it's useful to discuss chip-level diagnostics and compare-and-contrast 
> in this list. It may be too much detail or tech for some.
> regards, Herb

No way, this crowd loves that stuff (I predict!)

 		- Ethan

More information about the vcf-midatlantic mailing list