• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

Mac IIci ROM Hack Setup

Dennis Nedry

Well-known member
Well, I started out with a Mac IIci with the ROMs removed and PLCC sockets in their place and for a long time I was waiting for a deal on a ROM programmer. I finally got one. When it came, I spent a day looking for my flash ROM chips and could not find them. So in frustration and haste, I quickly ordered some more and they arrived today. These are each 4 Mbit, totaling 2 MByte ROM storage. Unfortunately, they have a 50us access time and because the IIci is 25MHz, it requires a 40us access time. Needless to say, I programmed the ROMs with the original IIci ROM code and it didn't work.

vent.gif


I will NOT transfer my PLCC sockets to another Mac (i.e. Mac IIsi). That is not possible. So my options include:

Find the missing ROMs

Wait for a good deal on some faster ones on eBay

underclock the IIci from 25MHz to 20MHz

xx(

I may have to wait for the old ROMs to turn up. But progress has been made nevertheless. I know there are at least a few of you who are interested in this project so here's your status update.

;)

 

trag

Well-known member
If you meant nanoseconds (ns) instead of microseconds (us) then, while your math is correct, the IIci does not require 40ns ROMs. It must have some wait states built into the memory access system.

When Gamba and I built a IIci ROM module we used either 90ns or 120ns chips. I can't remember which.

Forty or fifty nanosecond should be much more than fast enough. In fact, on the PCI PowerMacs 120ns Flash works while the Beige G3 needs 90ns. But none of these even more modern machines need 40 - 50ns memory for the ROMs.

So, I think your chips should work.

I can think of two possible issues you could be having. One of them is unlikely, as I don't think you'd made that kind of oversight, but just for completeness....

1) The pin out of the PLCC32 chips changed significantly between the 512Kb capacity and the 1Mb capacity. If your adapters are wired for the 512Kb capacity, they will not work with the larger capacity chips. I built my programmer adapters for 512Kb and below PLCC32, and 1Mb and above PLCC32 and they had to be wired to the DIP very differently.

So check your adapter's wiring if you didn't that into account when you bought the adapters.

2) Some (many?) of the later Flash chips have a Reset_ pin which must be tied high in order to read the chip. Check the datasheet for the flash you are trying to use. I know that a bunch of the Atmel chips have this. It's one of the big pains of dropping later Flash chips in place of ROM chips. You end up running wire wrap from the Vcc pin to the RESET pin.

 

Dennis Nedry

Well-known member
Ahhhh! I always get my micros and nanos goofed up! You are right, they are 55 NANO-second read access time, which is actually faster than the ones I lost. Hmmm...

I built the sockets with AT29C020 ROMs in mind and these are AT49F040 ROMs. Comparing datasheets, I see the only difference is A18 on pin 1 which is NC on the older ROMs. I originally added address bus wires for A17 and A18 just in case I ever got these 4Mbit chips, so I think that's okay.

So these ROMs I'm working with have the following pins:

A0:A18 (Address pins)

D0:D7 (Data I/O pins)

VCC (+5V)

GND (0V)

/WE (Write Enable) = 1

/OE (Output Enable) = 0

/CE (Chip Enable) = 0

I will check logic levels on /WE and /OE. /CE should be okay because the Mac will need to control that to multiplex other devices, i.e. RAM, NuBus, etc. Whatever shares the same data pathways. I'll keep you posted.

 

trag

Well-known member
I built the sockets with AT29C020 ROMs in mind and these are AT49F040 ROMs.
Ah, okay, that ditches both of my initial ideas. I thought the 49F040 would have a reset pin, but it doesn't. The 49F001 does. The 49f010 does not. I guess if Atmel made an AT49F004 it would have a reset pin.

So, my last thought...did you tie the WE_ pins high on the adapter? I don't think that the logic board will supply a high signal to the WE_ pins because it doesn't expect a ROM to have them.

Jeff

P.S. Oh, and an "Is it plugged in" kind of idea. Do you have the W1 jumper set for motherboard ROM operation and not for ROM socket operation?

 

Dennis Nedry

Well-known member
I tried the jumper both ways, no go.

I attached my PLCC adapters pin-for-pin to the old DIP sockets except for the 2 extra address pins. So I let the /WE pin alone... After testing, I notice that /WE is held LOW so I bet that's the problem. (either that or high impedance, only tested voltage to ground) Out of curiosity, I placed very small strips of tape over the /WE pins on the chance that high impedance input on /WE = logic high. No-go again.

/CE and /OE are not constant so I think we're safe to assume they're being controlled. I don't have a scope set up at the moment so I can't see the actual levels. I'll look into separating the /WE and giving it a +5V... It's fairly daunting.

 

trag

Well-known member
Is the WE_ pin for the DIP holes connected to anything on the logic board? If not, it would be easiest to tie the WE_ pin to 5V on the back of the logic board at the DIP through hole pin.

Of course, if that WE_ pin is connected to WE_ on the RAM, for instance, then that would be a *bad* idea.

 

Dennis Nedry

Well-known member
I tested with an ohm meter on 2 Meg setting from each /WE pin to GND and 5V on the hard drive power connector. Infinite resistance. Yay! That makes things easy.

So I proceeded to blob solder from VCC to /WE (right beside each other). High logic is now properly held on /WE, I tested each inside each PLCC socket with reference to ground and they all held 5V. This is definitely progress.

Unfortunately there must be multiple problems because it still doesn't work. No chime. Inserting a IIfx ROM simm and removing the jumper (i.e. disable new ROMs and use ROM simm instead) still chimes as normal.

Here was the burning procedure:

  • obtain known-good IIci 368cadfe ROM image
  • split to 4 files, HH, MH, ML, LL by reading bytes of the original ROM in sequence HH, MH, ML, LL, HH, MH, ML, LL, HH, MH, ML, LL, etc.
  • sequence is repeated 4 times to fill the ROM (in case the extra address bits are not working properly)
  • erase each ROM, burn, verify, write on it, pop it into the IIci
  • turn on IIci with grand hopes and dreams
  • life drains from facial expression


Any other ideas? :beige:

 

Dennis Nedry

Well-known member
I noticed in the spec sheet that these are actually 90ns, not 50 or whatever I said. The bullet points up on top are a little misleading. That should not be an issue anyway though. I'm starting to think about incompatible logic levels. Maybe this is CMOS and it expects TTL or something. I was pretty sure that the old and the new are both CMOS though. I really believe that all pins are connected properly now too, and the ROMs verified after burn. I will be double-checking all 128 connections at some point. It is unlikely that there is a short because the ROM simm works fine. If address or data lines were shorted together, that would prevent the simm from working too.

So I guess I'll check continuity of address lines between the 4 sockets and the simm slot, then each data line to the simm slot. And finally troubleshoot /OE and /CE. The original ROM chips WERE working when I cut them off though.

Does anyone else want to have a look at the spec sheet and see if the boot block or lockout mode could be interfering? I can't completely rule that one out.

http://www.raphnet.net/electronique/genesis_cart/doc0998.pdf

 

trag

Well-known member
Does your chip programmer generate a checksum for the buffer and/or chip contents (the two would match after programming or reading a chip)?

I don't know if this helps, as I'm not sure all programmers would generate the checksum the same way, but here is what I have for the Iici ROM contents:

The chip which ends in

733 has checksum 00AD 3AFF

734 has checksum 009A 605C

735 has checksum 00AD DD89

736 has checksum 009A D2EE

I can probably send you the files if I can figure out how to get them from the old Win98 PC I'm using with my programmer to my Mac.

You might also check continuity from the top of the chip pins to the logic board. I have found that some of the PLCC32 sockets are very unreliable as far as getting a good connection. Sometimes one must push the chip in only part way instead of seating it all the way at the bottom of the socket.

 

Dennis Nedry

Well-known member
some of the PLCC32 sockets are very unreliable / Sometimes one must push the chip in only part way
I tried this and it WORKS. The PLCC sockets are sketchy. You are exactly right. The IIci chimes with the ROM I burned now without any SIMM inserted. OH MAN this is going to be fun!

:b&w: :beige: :)

}:)

 

trag

Well-known member
Excellent. All those hours I spent banging my head against a wall had more use than just the time I tried to get *my* sockets working.

Please keep us updated on what fun you have.

 
Top