Deep IIci rejuvenation, possible ROM select problem

[Dennis Nedry]

I decided to work on my old Mac IIci today. It was stored outside in the weather for several years before I got it. The ports on the back are a bit rusty and there are signs of capacitor leakage. The Mac does not make any sound or attempt to boot. The power supply does come on however.

So I thoroughly washed the logic board and I discovered a deep scratch across some traces in the very center of the board, near where the screw goes through that holds the plastic floppy/HD chassis. Upon testing, indeed, several of these traces have been severed. These traces connect the large chip labeled "RBV" to the four 74F245s that appear to swap the ROM based on the ROM Select jumper. But I'm not too sure on that.

After a great deal of very diligent work, I have reconnected each trace at each end where the scratch had gone through, including some that tested good. I re-tested at the end for any short circuits between them an all appears well.

I plugged it in, like a kid on christmas expecting something extraordinary, and again NOTHING. So I decided to whip in a Mac IIfx ROM SIMM, remove the jumper, and see what happens. Interestingly, it made a startup sound, followed immediately by a crash sound, no time in between. This verifies some of the hardware including the processor and sound circuits and tempts us because we see a sliver of life peeking out at us.

Hooking the Mac to a monitor reveals no video. (Drat, no sad mac error code.) Removing all RAM results in a silent crash immediately after the startup sound, evidenced by the interrupt button not causing a crash sound. The ROM select jumper makes no difference, it behaves identically in any situation I could conjure, with and without that jumper in place.

So what do I do now?! The board is freshly cleaned but it still has the old caps. There aren't really any caps that are obviously involved in selecting which ROM to use, which appears to be somewhat of an important clue. Any ideas are welcome.

 

[Mars478]

I say cap swaps. Or another set of RAM? Something is surely dead.

 

[Osgeld]

how dirty are the sockets

 

[Dennis Nedry]

I have some known-good RAM I could try. Good idea. The caps are suspect. There was certainly some goo before I cleaned the board. Everything on the board is very clean, including the sockets; only the ports on the back are bit rusty. I really should order a whole bunch of tantalum caps; I have countless Macs that need to be recapped.

 

[trag]

I plugged it in, like a kid on christmas expecting something extraordinary, and again NOTHING. So I decided to whip in a Mac IIfx ROM SIMM, remove the jumper, and see what happens. Interestingly, it made a startup sound, followed immediately by a crash sound, no time in between. This verifies some of the hardware including the processor and sound circuits and tempts us because we see a sliver of life peeking out at us.
The ROM select jumper makes no difference, it behaves identically in any situation I could conjure, with and without that jumper in place.

The ROM chips on the motherboard have Chip Enable pins which must be tied low in order for the chips to work. I'm pretty sure that's all that jumper does. It ties the Chip Enable pins to ground. If you explore the chip enable pins on the ROM chips with an ohmmeter you'll probably find that they're connected to the 5V supply by about 3 - 5 Kohms and also to one pin of that jumper either directly or through a very low value resistor. The other pin of the jumper is probably connected to ground.

So, without a jumper, the Chip Enable pins are tied weakly high. With the jumper the ground connection overwhelms the weak 5V connection.

I can't remember if the IIci uses a 28 pin or 32 pin ROM. If 28 pin, then pin 20 on the ROM is CE. If 32 pin, then pin 22 on the ROM is CE. Orient the chip with the notch at the top. Looking down from above, pin 1 is the upper left pin. Count to the bottom (pin 14 or 16), then start counting up from the bottom on the other side. The top right pin is either pin 28 or pin 32.

So, given the symptoms you're experiencing, I would guess that there's still a munged connection somewhere. It might not be in the scratch on the board. It could be that leaking capacitor juice ate through a via or solder connection which is stopping the on-board ROM from operating properly.

 

[Dennis Nedry]

Very insightful comments trag, thank you. I played a bit with the CE pins before, attempting to make a direct connection to ground which didn't help. I think I'll test the voltage between ground and the CE pins of the onboard ROM chips with and without the jumper installed. If it doesn't produce good clear logic levels, I shall trace around and see why.

An amazing advancement was made on this old IIci today! I plugged it in, with the IIfx ROM and it lit right up, and BOOTED successfully into A/UX, showing 20MB or RAM. I think possibly there was still some moisture somewhere that hadn't quite dried yet from when I washed the board, and this is why it works now. There is hope for this old baby! It definitely needs new caps. It does the "always on" thing, where if you shut down it will reboot after a second or two of being off. So we'll see. I will also inspect more carefully for damaged traces from cap goo.

 

[trag]

Dennis, I think you mentioned in another thread that your IIci is working well now except that you still must have a ROM SIMM installed for it to boot.

If you are up for some tedium, you can figure out where the problem lies pretty easily (but with said tedium).

The signals on the ROM chips are all duplicated in the ROM SIMM socket. So if you get the pinout for the ROM chips (it's identical (except for WE_ and Vpp) to a same capacity Flash or EEPROM chip) you can test continuity on all their pins to the ROM socket. If there's isn't continuity, then that's the trace to follow. The ROM socket pinout is available in "The Guide to the Macintosh Family Hardware", I think. Someone may have put it online by now. You might check Gamba's site.

 

[Dennis Nedry]

Dennis, I think you mentioned in another thread that your IIci is working well now except that you still must have a ROM SIMM installed for it to boot.
If you are up for some tedium, you can figure out where the problem lies pretty easily (but with said tedium).

The signals on the ROM chips are all duplicated in the ROM SIMM socket. So if you get the pinout for the ROM chips (it's identical (except for WE_ and Vpp) to a same capacity Flash or EEPROM chip) you can test continuity on all their pins to the ROM socket. If there's isn't continuity, then that's the trace to follow. The ROM socket pinout is available in "The Guide to the Macintosh Family Hardware", I think. Someone may have put it online by now. You might check Gamba's site.

I've played with this a bit, but it appears that the onboard ROM address/data pins are not directly connected to those pins in the ROM SIMM slot. I can't find any visible or electrical continuity. I suppose I need to inspect the board more closely, but it appears that the onboard ROM is connected through a very large IC and the ROM SIMM has a more direct pathway to the processor. i.e. The ROM slot and RAM slots have pins in common, but the ROM slot and the onboard ROM chips don't appear to be directly connected.

I'll definitely take a closer look as time allows, though. This Mac was exposed to extremely cold temperatures for several winters, so I'm almost wondering if that could have affected the ROMs. Unlikely but maybe something to consider. One single flipped bit could easily cause complete ROM failure.

I noticed that without a SIMM installed, adding/removing the ROM SIMM jumper determines if the screen will be black or if it will be checkerboard. That doesn't really mean anything but it could come up as a clue or lead to theories as I examine this thing more closely. No detail is too fine to be noticed in this matter.

 

[Dennis Nedry]

I've played with this a bit, but it appears that the onboard ROM address/data pins are not directly connected to those pins in the ROM SIMM slot.

WRONG

All of the data bits of the onboard ROMs are indeed directly connected to the ROM SIMM slot. Also to RAM bank B. RAM bank A is also connected, but via 3-state bidirectional buffers. I imagine this is to multiplex the RAM banks.

The address bits, however, are NOT connected directly between any RAM or ROM. The large MDU ("Multiplexer Decoder Unit"?) chip located at UK11, seems to be in charge of address control, pending further investigation.

 

[trag]

All of the data bits of the onboard ROMs are indeed directly connected to the ROM SIMM slot. Also to RAM bank B. RAM bank A is also connected, but via 3-state bidirectional buffers. I imagine this is to multiplex the RAM banks.
The address bits, however, are NOT connected directly between any RAM or ROM. The large MDU ("Multiplexer Decoder Unit"?) chip located at UK11, seems to be in charge of address control, pending further investigation.

Interesting. I guess I only ever checked the data bits, which makes sense. I was determining the order D[0, 7], D[8, 15] etc., of the ROM chips with respect to the ROM SIMM, so I probably only ever traced the data pins.

Thank you for keeping us updated. Very cool stuff.

 

[Dennis Nedry]

I'm sorry, I think my continuity tester was on the fritz. I switched to a different one that has an audible indicator and I found much more connections. All data and address bits are connected directly between the ROM SIMM slot and the onboard ROM. trag, you were right.

I have extensively tested all connections and all connections are continuous between onboard ROM and the ROM SIMM slot, including !CS and selectively !OE, depending on if the jumper is installed or not. There is an ohm or two of resistance when measuring !OE from the SIMM slot to the onboard ROM, so maybe i'll have a second look at that. But really, that's to be expected when going halfway across the board and weaving from side to side like it does.

!OE is always connected to the SIMM slot, but removing the jumper disconnects !OE from onboard ROM. There is no inverting logic involved.

I uploaded my findings to the wiki:

http://68kmla.org/wiki/Macintosh_IIci_RAM_and_ROM_Pathways

Because I've verified every single connection between the ROM SIMM slot and the onboard ROMs, combined with the fact that a ROM SIMM works and the onboard ROM does not, I think the only conclusion to be made at this point is that the onboard ROM itself is the problem.

 

[Dennis Nedry]

UPDATE:

Today I solved the problem with my Mac IIci. It is fully-functional off of Built-In ROM. Address Line 16 was damaged UNDERNEATH the battery holder. A battery had exploded on this logic board at one point, and leaked through, making A16 intermittent. It passed a continuity check earlier, but not enough for the data to get through.

Unfortunately I discovered this after removing the ROMs, after which I removed the battery holder. I soldered the ROMs back on, and it works!

I plan to remove the ROMs again and install DIP-32 to PLCC-32 socket adapters. Then I can freely burn inexpensive flash chips with modded ROM! Endless fun is planned.

It has crossed my mind to expand the 512kiB limit to 1024kiB. I believe that this is as simple as connecting A17 on the new ROMs to pin 42 in the ROM SIMM slot. Does anyone see a reason this wouldn't work? With a 1024kiB limit, I could attempt to burn with a Mac LC II ROM code. IMAGINE a Mac IIci, not only with the newer startup sound, but customizable startup sound! OMG. But we'll have to see if the LCII ROM works first and/or how far off it is.

Anyone have a clue whether the A17 to pin 42 thing is likely to work? It seems logical to me.

 

[trag]

UPDATE:
Today I solved the problem with my Mac IIci. It is fully-functional off of Built-In ROM. Address Line 16 was damaged UNDERNEATH the battery holder. A battery had exploded on this logic board at one point, and leaked through, making A16 intermittent. It passed a continuity check earlier, but not enough for the data to get through.

Anyone have a clue whether the A17 to pin 42 thing is likely to work? It seems logical to me.

That's great that you were able to fix it. Expanding the addressing as you intend should work in principle, but according to "The Guide to the Macintosh Family Hardware" pin 40 in the ROM socket is A17. Of course, if you started counting the address pins at 1 and the socket pins at 0, then we'd still be talking about the same pins, just with different names.

According to TGTTMFH:

ROM SIMM Socket

Pin Number     Signal Name
1                          +5V
2                          A0
3                          A1
4                          A2
5                          A3
6                          A4
7                          A5
8                          A6
9                          A7
10                        GND
11                        ROM CS_ 
12                        ROM OE_
13                        +5
14                         D0
15                         D1
16                         D2
17                         D3
18                         D4
19                         D5
20                         D6
21                         D7
22                         D8
23                         D9
24                         D10
25                         D11
26                         D12
27                         D13
28                         D14
29                         D15
30                         GND
31                         A8
32                         A9
33                         A10
34                         A11
35                         A12
36                         A13
37                         A14
38                         A15
39                         A16
40                         A17
41                         A18
42                         A19
43                         A20
44                         A21
45                         A22
46                         +5V
47                         D16
48                         D17
49                         D18
50                         D19
51                         D20
52                         D21
53                         D22
54                         D23
55                         D24
56                         D25
57                         D26
58                         D27
59                         D28
60                         D29
61                         D30
62                         D31
63                         +5V
64                         GND

I'm finally posting from home, so my books are available.

 

[Dennis Nedry]

With ROM, it skips the "real" A0 and A1. This is because each address on the address bus is sent to all 4 ROM chips. Because there are 4 8-bit ROM chips, each address requested from ROM returns 32 bits. But as we know, each single byte (each 8 bits) has an address, not each 32 bits. So by skipping the first 2 address bits, the physical address sent to the ROM changes each 4 bytes instead of each byte. These missing address bits are probably used elsewhere to grab a specific 8-bit portion of the 32-bit data returned from ROM.

"real" A19, which logically should be A17 to the ROM chips, the one that would let me expand ROM to 1024k, is connected on my IIfx SIMM to /WE (write enable) on each ROM chip. This line must always be active high to enable output from the ROM chips. I guess it's possible you could use it as a third chip select input. All 3 /CS, /OE, and /WE must be low to enable the output of the chip. This is doubtful however because this line is NOT connected to the onboard ROM at all.

Then I took my trusty voltmeter to this pin. ZERO volts. That was unexpected, but it gives me a little more confidence in A19 working with ROM.

I will admit that this confuses me a little. I guess we'll just have to see what happens when I get these parts in. I ordered ROMs that use the extra bit and as such are twice as big, totaling to 1024kB. It won't be for a while, but I'll let you know. A IIci running Mac LC II/III ROM would be quite the conversation piece, even though it doesn't seem too likely. I will give it a shot though!

 

[trag]

With ROM, it skips the "real" A0 and A1. This is because each address on the address bus is sent to all 4 ROM chips. Because there are 4 8-bit ROM chips, each address requested from ROM returns 32 bits. But as we know, each single byte (each 8 bits) has an address, not each 32 bits. So by skipping the first 2 address bits, the physical address sent to the ROM changes each 4 bytes instead of each byte. These missing address bits are probably used elsewhere to grab a specific 8-bit portion of the 32-bit data returned from ROM.
"real" A19, which logically should be A17 to the ROM chips,

Right. My mistake. A0 and A1 are only uaed for bytewise addressing and then only on a couple of earlier machines. With four X8 ROM chips, you've got a 4 byte word and so A0 and A1 are omitted and address lines are tied to the ROM chips starting at A2.

There's actually a note in TGTTMFH about A0 and A1. I should have thought of that but I typed my previous message out in a bit of a hurry.

 

[trag]

the one that would let me expand ROM to 1024k, is connected on my IIfx SIMM to /WE (write enable) on each ROM chip.

That sounds like a hack to allow programming an EEPROM or Flash module in place in the machine. Is your IIfx SIMM built out of ROM chips or EEPROM or Flash chips. Hmmm. Must be one of the latter two, as ROMs don't have WE pins. Even if it's ROM chips, I guess it's possible they designed the circuit board for a proto-type reprogrammable module and then used that same circuit board for some of the production ROM SIMMs.

My guess is that when they want to reprogram the module, they'd write to the ROM SIMM and every address would be the normal address plus the A19 bit, which would give them WE high. Wait, that doesn't make any sense. They'd have to hold A19 low to enable WE. Hmmm. So any time they read from the ROM without asserting A19 the chips would treat the read as a write operation? That's not good. Weird. Maybe there was an inverter on the module?

 

[Dennis Nedry]

That sounds like a hack to allow programming an EEPROM or Flash module in place in the machine. Is your IIfx SIMM built out of ROM chips or EEPROM or Flash chips. Hmmm. Must be one of the latter two, as ROMs don't have WE pins. Even if it's ROM chips, I guess it's possible they designed the circuit board for a proto-type reprogrammable module and then used that same circuit board for some of the production ROM SIMMs.
My guess is that when they want to reprogram the module, they'd write to the ROM SIMM and every address would be the normal address plus the A19 bit, which would give them WE high. Wait, that doesn't make any sense. They'd have to hold A19 low to enable WE. Hmmm. So any time they read from the ROM without asserting A19 the chips would treat the read as a write operation? That's not good. Weird. Maybe there was an inverter on the module?

This is a real quandary.

It could be that on this particular ROM, that pin is different. Gamba's OS 8 on SE/30 page says that these ROMs are based on M5M27C101JK, which he said is EPROM. I'm not seeing a datasheet for that, or any that are similar enough, so just I'm assuming that this pin is a /WE. Most modern 32-pin ROMs have the same pinouts. I guess it's possible that this pin is NOT a /WE. These ROMs are ~20 years old. There is also another pin connected to a +5V supply that usually is NC. MAYBE this is actually /WE. I'm not sure.

I have 12 new Atmel AT29C020 ROMs coming, so whenever I can source some cheap DIP32 to PLCC32 adapters and get them from china, I'll give them a go onboard, with A19 patched in via wires. It'll be a cool experiment! The goal is a sampled startup sound from a Mac IIci.

 

[trag]

ROMs are based on M5M27C101JK, which he said is EPROM. I'm not seeing a datasheet for that, or any that are similar enough, so just I'm assuming that this pin is a /WE. Most modern 32-pin ROMs have the same pinouts. I guess it's possible that this pin is NOT a /WE. These ROMs are ~20 years old. There is also another pin connected to a +5V supply that usually is NC. MAYBE this is actually /WE. I'm not sure.

The pinout for memory chips is a JEDEC standard, but that may have been before the standards. The '27C' series is EPROM for every manufacturer with which I am familiar and the M5M would make it a MItsubishi part number. Up until about seven or eight years ago they had the datasheets up on their website, but they took them down a while back. Sigh. Similarly for Toshiba.

A line tied to 5V would make more sense as the WE pin. I think there was a Vpp pin (special voltage required for programming) on some chips which Apple sometimes tied to an address pin. I'm not sure why they would connect Vpp if they tied WE high though.

I have 12 new Atmel AT29C020 ROMs coming, so whenever I can source some cheap DIP32 to PLCC32 adapters and get them from china, I'll give them a go onboard, with A19 patched in via wires. It'll be a cool experiment! The goal is a sampled startup sound from a Mac IIci.

If you find you need some 040 chips (4 Megabit) let me know. I think I've got a bunch of AT49F040 in the attic. I have some projects in mind for them, but I can certainly spare a handful for interesting ROM module experiments.

 

[Dennis Nedry]

If you find you need some 040 chips (4 Megabit) let me know. I think I've got a bunch of AT49F040 in the attic. I have some projects in mind for them, but I can certainly spare a handful for interesting ROM module experiments.

Yay! I'll experiment with these 020s for a while, but I'll definitely remember your generous offer. For now, it's easiest for me to remove the onboard ROM from a IIci and install DIP to PLCC socket adapters than to actually etch a SIMM. I think eventually, if I get something cool to happen in ROM, I might etch a few and mount PLCC sockets on them, being sure to share a couple with others who are interested. They are an unusual thickness but other than that it should be doable and fairly straightforward.

I suppose if I could find a nicely disassembled and commented Mac Classic ROM, and IIci or IIfx ROM, we could have a stab at conglomerating the bootable ROM disk into the newer ROM. A large enough ROM could probably leverage System 7. Well at least we can dream. It depends how far this Mac ROM hacking OCD will take me.