Thread

Deep IIci rejuvenation, possible ROM select problem

Deep IIci rejuvenation, possible ROM select problem Hardware 33 posts Jan 21, 2010 — Jan 6, 2011

#1 Thu, 21 Jan 2010 - 11:33

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.

#2 Thu, 21 Jan 2010 - 15:32

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

#3 Thu, 21 Jan 2010 - 15:35

how dirty are the sockets

#4 Thu, 21 Jan 2010 - 20:03

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.

#5 Fri, 22 Jan 2010 - 17:49

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.

#6 Sat, 23 Jan 2010 - 02:53

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.

#7 Thu, 4 Feb 2010 - 16:34

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.

#8 Thu, 4 Feb 2010 - 21:38

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.

#9 Fri, 5 Feb 2010 - 02:50

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.

#10 Fri, 5 Feb 2010 - 15:52

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.

#11 Sat, 6 Feb 2010 - 00:11

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.

#12 Sun, 28 Feb 2010 - 00:54

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.

#13 Sun, 28 Feb 2010 - 03:46

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

Code:

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.

#14 Sun, 28 Feb 2010 - 08:19

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!

#15 Mon, 1 Mar 2010 - 17:41

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.

#16 Mon, 1 Mar 2010 - 17:48

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?

#17 Mon, 1 Mar 2010 - 19:47

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.

#18 Mon, 1 Mar 2010 - 22:05

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.

#19 Mon, 1 Mar 2010 - 23:49

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.

#20 Wed, 3 Mar 2010 - 04:47

Datasheet for the M5M27C101JK is here:

http://www.io.com/~trag/DataSheet

I thought I had it on my archive drive. I have a last modified date of 2003 on it. I think we're covering some of the same ground which Gamba and I covered back in 2003 when we worked on the IIci ROM together. New ground too, since your ideas for modifying the ROM are very cool.

The SIMMs are .050 or perhaps .047" thick, while today's boards are typically .063". I have a design for a ROM module already drawn, I think. It might still need some work. I was planning to use Toner Transfer Paper to resist and etch the boards myself, but events intervened.

Oh, I remember, I drew a nice design with four PLCC parts on the same side of the board and realized that they'd be too close together for convenient hand soldering. Two need to go on each side of the board to leave space in between for manuevering a soldering tip. Or, alternatively, one can plan to solder them in an oven.

#21 Wed, 3 Mar 2010 - 08:00

Oh, I remember, I drew a nice design with four PLCC parts on the same side of the board and realized that they'd be too close together for convenient hand soldering. Two need to go on each side of the board to leave space in between for manuevering a soldering tip. Or, alternatively, one can plan to solder them in an oven.

Thanks for the datasheet.

Did you consider soldering PLCC sockets instead of soldering the ROMs directly? You can get them so that you solder from inside the socket area. Then afterwards you just push a ROM into each one.

#22 Thu, 4 Mar 2010 - 03:14

Datasheet for the M5M27C101JK is here:http://www.io.com/~trag/DataSheet

I thought I had it on my archive drive. I have a last modified date of 2003 on it. I think we're covering some of the same ground which Gamba and I covered back in 2003 when we worked on the IIci ROM together. New ground too, since your ideas for modifying the ROM are very cool.

I saw in an older thread that you worked with Gamba on the IIfx also. Back around that same time period, I was trying to figure out a way to address more RAM per slot on the IIfx MoBo. After Dr. Bob went bonkers about how horrific a certain pizzabox memory hack was in terms of noise and timing, I figured out another possible, hopefully far less objectionable, approach.

IIRC the IIfx RAM is multiplexed and there are, for the vast majority of these machines, unused parity checking lines. My notion was that these lines could be rework jumpered/hijacked at the memory controller or CPU, becoming additional lines for addressing much more memory on an entirely new RAM card design. I know Gamba had a IIfx RAM SIMM layout for the maximum "normally" addressable memory ceiling. However, I was thinking it might be possible to add a few more bits of addressing through a parity line rework/hijack hack. I don't recall much offhand about the IIfx memory mapping, but the additional memory should, at the very least, be addressable as a RAMdisk, configured as Virtual Memory, and accessed at the same speed as normal system memory.

It's been a long time since I've toyed with the idea, so I thought I'd bounce it off you before hittin' the books again. }

#23 Thu, 4 Mar 2010 - 20:10

I saw in an older thread that you worked with Gamba on the IIfx also.

All I recall is discussing the IIfx ROM with him. It's possible I've forgotten, but as I recall most of Gamba's and my interaction was either regarding the Micron Exceed video card for the SE/30 or the ROM modules for the Mac II family.

IIRC the IIfx RAM is multiplexed and there are, for the vast majority of these machines, unused parity checking lines.

There are unused parity lines but other than meaning there are pins in the socket which aren't used, I don't think they provide anything. I guess there are probably traces to them from somewhere, since parity was an option on the IIfx. That might make some kind of hacking easier. But compared to the rest of the task, it wouldn't be much of an easing.

I'm not sure what you mean by multiplexed. The writes to the IIfx RAM are buffered. In practice this means that the data bus has a set of latches between the data bus and IIfx RAM Write pins. And yes, the Data-Read and Data-Write pins are separate on the IIfx RAM. That's what makes the stuff a pain, but it also improves performance.

In practice, on other computers, the CPU would put the write data out on the data bus, along with an address on the address bus and Write Enable active, and the memory controller would translate the address lines into something that the RAM understand and eventually the RAM copies the data from teh data bus. Meanwhile, no other activity takes place on the data bus.

On a IIfx, the CPU puts the write data on the data bus, along with an address on the address bus and Write Enable active and the memory controller signals the Write Latches to latch the data bus. The address is copied into registers in the memory controller and the memory controller tells the CPU that the operation is finished and the CPU goes on its way and the data bus is available for use for other things. Meanwhile the memory controller translates the address and write request into commands for the RAM (Row address followed by column address, etc) and the RAM copies the write data from the latches, which form their own little data cul 'de sac, invisible to the rest of the machine.

This scheme means that IIfx memory absolutely must have separate pins for data read and data write or data out and data in. If you just tie them together, the data being held in the write latches will trample on the entire data bus while the rest of the machine may be trying to use it. And data on the data bus will trample on the RAM data-in while it's still completing the buffered write operation.

So there's no converting conventional 30 pin or 72 pin SIMMs into IIfx memory. Not saying that was your plan, but pointing out it won't work.

My notion was that these lines could be rework jumpered/hijacked at the memory controller or CPU, becoming additional lines for addressing much more memory on an entirely new RAM card design.

The memory controller only understands how to translate addresses intended for RAM into, at most, 12 row address and 12 column addresses. The memory controller chip just doesn't have any way to translate more addresses than that.

Now, I guess you could build some SIMMs with additional upper address bits. Then the memory controlller would do the normal row and column translation of the lower bits and your extra logic would supply the upper address bit as a bank select, chip select, or just an additional address bit. But to do that you'd need access to the higher address bus lines (probably available around the memory controller) and you'd need to modify the ROM code so that the machine knows how to detect and report larger RAM capacities. I think that there's 1 GB of address space allocated to RAM in the IIfx memory map, but the ROM code (probably) doesn't know to look for more than 128 MB when it does its start up memory test.

You'd also need some scheme to provide refresh support to those upper tiers of memory and that would probably require a PLD all its own.

I know Gamba had a IIfx RAM SIMM layout for the maximum "normally" addressable memory ceiling. However, I was thinking it might be possible to add a few more bits of addressing through a parity line rework/hijack hack. I don't recall much offhand about the IIfx memory mapping, but the additional memory should, at the very least, be addressable as a RAMdisk, configured as Virtual Memory, and accessed at the same speed as normal system memory.

I don't remember Gamba having such a design, but that doesn't mean much given my leaky memory and it's irrelevant. Yes, if you could add some higher memory address bits to the SIMMs and memory to go with them, and change the ROM code so it will be detected, and solve the refresh problem, then it could probably either be added to addressable RAM or used as a RAM disk.

Any of those options is going to require non-trivial hacking of the code that controls the low level hardware. I'm sure it's doable. I just think you should realize that there's a substantial learning/mystery/probably-undocumented-code-modifying to be done to make it work.

#24 Wed, 24 Mar 2010 - 03:29

UPDATE

I have acquired some PLCC-32 to DIP-32 adapters and installed them in place of the onboard ROMs of this Mac IIci.

Unfortunately there was a SHORT in one of the adapters that I didn't notice until after installation. I discovered this with a continuity tester after the Mac failed to chime from the ROM SIMM slot. A6 was shorted to A15. My solution was ingenious. I did not have to remove the adapters, which would have been almost impossible.

I have a current-controlled voltage source. I set it to 1 volt, turned the current down a ways and applied the voltage across A6 to A15 of each adapter. I also attached a voltmeter across these two at the same time. Since the traces have resistance, I knew the one with the LOWEST voltage reading would be the one with the short circuit.

Once I knew that, I had a look at the 5th adapter I ordered and determined the exact spot the short had to be. I crafted a tool out of a piece of 14-gauge steel wire and filed a rasp into the end. With this tool, I was able to reach under the adapter and scrape back and forth to remove the solder that was bridging the two address lines.

MORALS OF THE STORY:

Test parts before installing

REALLY test parts that you ordered on eBay from China

So now it works again off of the IIfx ROM SIMM after I removed that short. I tested continuity of each address and data pin from the SIMM slot to the onboard ROM and Found one open circuit. I must have cracked or lifted a trace, so I found another point nearby and added a short 1" jumper. In theory this should be fully-functional now.

I also connected two additional address bits from the ROM SIMM slot to the appropriate pins on the adapters. This is on the bottom of the board (not seen in picture). The AT29C020 chips I have will use one additional address bit, for a total of 1 MByte ROM, with easy expansion to 2 MByte ROM by substituting 040 ROM chips.

All I have to do next is get access to a ROM burner!! First I want to try the normal IIci ROM just to verify that it's working and that I split the ROM up correctly amongst the 4 chips, etc. Then I'll be moving on to Mac LC II ROM. We'll see what happens! I've never heard of anyone trying a 1 MByte ROM in a Mac IIci.

#25 Wed, 24 Mar 2010 - 06:50

For those 68k diehards that see this and think that I've sacrificed the authenticity of this logic board by removing the original PROMs and installing newfangled socketed PLCC Flash ROMs, I have a few reasons that I don't feel too bad about it.

This logic board was damaged by scrapes and battery leakage, so there is already extensive trace repair. Notice the missing battery holder in the picture.
This is 1 of 3 IIci's that I have.
Doing something new and interesting with an old Mac is worth it.
I want to hear a 68040-style startup sound out of this IIci.
I want to hear a CUSTOM sampled startup sound out of this IIci!
I want a Mac with ROM that can easily be modified for any number of projects.
I didn't make that checksum program for just verifying ROM dumps.

#26 Thu, 1 Apr 2010 - 23:46

Dennis, I think it looks great! That's a nice mod. Useful too, if you start modifying the ROM code.

Are you thinking about doing any disassembly? I ran across mention of a disassembler in the MacTech archives and checked and it is still sold. Later, independently, Henry mentioned that it is pretty much the best disassembler for the Mac. Now, I can't remember it's name of course, but I'm sure the info is retrievalbe when needed.

#27 Fri, 2 Apr 2010 - 02:55

Yes, I would like to do some disassembly but I don't have the proper tools right now. I would appreciate if you could point me toward this software you mentioned if you can remember more about it.

Currently I'm using FDisasm, but that only works well with very old 68000 and 68020 ROMs. I can't work too well with IIci or IIfx code. There are several that they have taken the time to comment up and these work VERY well, but disassembling different ones is very painful.

#28 Fri, 2 Apr 2010 - 03:38

MacNosy.

#29 Fri, 2 Apr 2010 - 16:51

http://www.jasik.com/index.html

MacNosy is actually still sold. I thought it was not so expensive, but it is $225.

However, given that it has been around since either 1984 or 1986, I can't remember which date was on the MacTech article, it might be useful to email the author and tell him what you want it for and see if he has a cheaper, earlier version available. We're not disassembling G3s and G4s here.

#30 Sat, 3 Apr 2010 - 00:13

Thanks for the info. My Mac projects will have to be on hold for a bit as I approach graduation in mid May. I am very busy with that and preparing to find a job, plus the 6 classes I'm in. But I will definitely use this stuff, especially when my Mac collection is where I can get to it properly.

There are lots of fun projects in the future with this cool stuff.