Another IIci ROM hack

[dougg3]

Dougg3's ROM project was featured today on Hack-a-Day! http://hackaday.com/2011/09/29/booting- ... k+a+Day%29

That's awesome!!!!!!! Thanks for pointing that out!

[Trash80toHP_Mini]

Mazel Tov!

11 Pages, 259 replies & 3,590 views and counting!

[techknight]

I was on there once, building a medium power FM transmitter using hacked parts.

[tt]

I kind of got lost about the microcontroller discussion, but the ATMega328 runs off of 5V. I was thinking goal-wise making a USB programmer with a SIMM slot would be more feasible than in-system flashing the ROM. If there are additional pins that need to be accessed, the programmer board could have jumper wires that are attached to access points on the SIMM and jumpers could be added to the SIMM for shorting or opening traces.

[olePigeon]

When everyone gets their ROMs working, we'll need a thread so everyone can post their screenshots.

Here're the icons I'll be using, plus my boot chime:

Boot Icon:
Floppy Icons: (The crossbones toggle)
Boot Chime: Arrr!

[dougg3]

I was musing about this some more, and while reprogramming the ROMs from inside the Mac *might* be possible, I think initial programming wouldn't be. You can't even address the ROM SIMM unless the jumper is set, but if the jumper is set, you can't boot from a blank ROM, right?

Oops, I didn't notice this in my big reply earlier...

I'm not sure if it's possible at all (I think I like the USB idea more anyway), but I'll have to think. My understanding is that with the ROM select jumper in place, the chip select on the DIPs is pulled low to activate them. When the jumper is out, the chip select on the DIPs is pulled high. The chip select on the SIMM socket is always pulled low. So if you have the SIMM in with the ROM jumper on, it won't work because both the SIMM chips and the DIP chips will have their chip select activated simultaneously.

In fact, I think I found that one of the SIMM socket's address pins is shorted to the DIP ROM's chip select line. I'll look again at that later, because I thought that seemed strange...

I was on there once, building a medium power FM transmitter using hacked parts.

Niiice!

I kind of got lost about the microcontroller discussion, but the ATMega328 runs off of 5V. I was thinking goal-wise making a USB programmer with a SIMM slot would be more feasible than in-system flashing the ROM. If there are additional pins that need to be accessed, the programmer board could have jumper wires that are attached to access points on the SIMM and jumpers could be added to the SIMM for shorting or opening traces.

Yeah, agreed -- the USB would be a lot easier than doing it in-system. Thanks for the note about the ATmega. I'd probably have to combine it with an FTDI chip for USB to UART...

Here're the icons I'll be using, plus my boot chime:

Those are AWESOME!!!

[Trash80toHP_Mini]

Very icons!

Programming over USB 1 sounds awesome, that way any PCI Architecture Mac becomes a ghetto programmer for the ROM SIMM. That fits right in with the PoAMM design aesthetic. I have to wonder if, after the ROM SIMM's initial programming and a successful boot, it'd be possible to read and write to a block of unused memory on the max capacity "ROMs?"

They'd have to be addressed in "ROM expansion mode," but that might be possible . . .

. . . being that there is already provision for doing so in many Mac ROMs & Toolbox Calls for it . . .
. . . the Boot ROM code will have already been copied into memory . . .
. . . you'd need to put a Micro-CPU in between the USB cable and the ROM SIMM . . .
. . . and hack a USB port into the unused portion of one of the Mac's NuBus or PDS card port covers . . .

. . . but it just might be a "limited" workaround for the "impossible" NuBus Architecture USB hack!
. . . if possible, at the very least, it should allow reads and writes to keychain drives and chiplets.

Substitute any header/jumper combos that might be necessary for programming the SIMM with "or gates" that are thrown when USB power is available.
For the base unit that'd be controlled by plugging in your USB cable or for in box USB interface reprogramming mode. In the USB Drive interface mode, the microcontroller would control the read write mode by turning the USB power line on and off for read/write drive access. The Microcontroller might be tripped from the mac end over a Serial Port connection or, better yet, ADB or the (forgot the name) MoBo's inter-chip serial connection.

Dunno . . . just spit ballin' here, but "to dream the impossible dream" has its own rewards!
Thanks for the opportunity to wax Quixotic, Sancho!

[trag]

The x100, x500, Beige G3, Etc. ROM module is .063" thickness. So it's easier to find standard specials, but the four layer thing gets you.

It might be possible to do one in two layers, but it would be tough, and since the thing operates faster, I'm not sure if it would work.

Doug, PM me when/if you get to the point where you need chips for the next batch and we'll work something convenient out. It looks like you're paying about $1.70+ per chip, and I'd be happy with $1 each. Also, we can do something along the lines of selling you the amount you think you will need, and then if you don't use them all, you can return the unused portion for a refund. I won't be any worse off than if they stayed in the box to begin with, other than digging them out and then putting them back.

[olePigeon]

Instead of building a new SIMM, would it be easier to just make a new little board with a SIMM socket and USB? That way you wouldn't have to fiddle with the SIMM itself. And perhaps put multiple SIMM sockets on it for various models and a toggle switch. That way you can keep the SIMM simple, and have maybe 3 or 4 sockets on a separate board so you can program a Mac II, IIsi, 6100/7100, and 9700.

[olePigeon]

Dougg3's ROM project was featured today on Hack-a-Day! http://hackaday.com/2011/09/29/booting- ... k+a+Day%29

This can only mean one thing...

...changing the IIci's icons to match the boot chime!

Boot icon:
System icon: (toggles between nothing and dead mario when looking for system/floppy)

Alternatively, you could use the Dead mario for the Sad Mac.

Icons with masks here.

[techknight]

Didnt i discuss that earlier? using an ATmega AVR as a ROM MMU for programming the flash ROM while on board.

The toolbox may provision in circuit programming of the ROM, but easier to use an MCU, and multiplexer switches such as 4053 or 4619. There are other types of setups too.

This way, you can break ROM away from the system address bus so the AVR can flash the ROM over USB or maybe via the mac, however you wanted to do it.

but so the system doesnt crash out when programming, you can eihter derive the MCU from standby power, or when you break ROM away, it switches in RAM in place of ROM, and a copy of ROM is sitting in RAM while things are flashed.

Once its done, have it toggle the system RESET bus line. and itll reboot the machine You could always have ROM copy its contents into shadow RAM, while holding RESET low so the system cannot start until the copy is finished.

[dougg3]

The x100, x500, Beige G3, Etc. ROM module is .063" thickness.

Ahhh...well that's good that it's the .063" size at least.

Doug, PM me when/if you get to the point where you need chips for the next batch and we'll work something convenient out.

Awesome! I definitely will be in touch with you when the time comes. Thanks!

Instead of building a new SIMM, would it be easier to just make a new little board with a SIMM socket and USB? That way you wouldn't have to fiddle with the SIMM itself.

If I can't find room for the programming circuitry on the SIMM, this is probably what I'll have to do. It would help keep the SIMM simple for sure. The problem is that I can't find 64-pin SIMM sockets for sale. Digi-Key says to call them to find more info. Maybe I'll do that, but my guess is that they are long gone. BTW, those Mario icons are amazing I'll stick them in!

Didnt i discuss that earlier? using an ATmega AVR as a ROM MMU for programming the flash ROM while on board.

Yeah, now that I think about it you did mention the AVRs. It really wasn't that long ago, but it feels like forever ago. Sorry

To be honest I haven't really put much thought into programming it while the Mac is running. I think it would probably be easier to just assume that the Mac is turned off while programming. In fact I have no problem with assuming the SIMM is out of the socket while programming it too...otherwise I'm fearing the circuitry that has to go on the SIMM is just going to get way too complex. Like you said, I'd have to use something to isolate the ROMs from the system bus at the very least...

[olePigeon]

The problem is that I can't find 64-pin SIMM sockets for sale.

I can check my local parts store, they might have some 64-pin SIMM sockets.

[dougg3]

I would be very interested in hearing if they have any. I just looked again and realized it's DigiKey in Canada that has a "Call us" listing for the 64-pin SIMM socket. But DigiKey US doesn't even have a listing for the part. The more I look at this, it's seeming like it'll be pretty tough to put all the programming circuitry on the SIMM without increasing the board size or adding more layers. An external programmer board feels kind of like a bad compromise, but it may have to suffice...*if* I can find sockets!

The parts for the rest of the Rev 1 SIMMs should arrive today. I also got some solder paste and a smaller iron tip, so I'll be experimenting a little bit to see if I can solder those sockets in without removing the bottom plastic.

I've been thinking about what it would take to make the SIMM programmable, and I just realized on the SIMM pinout, there's a +5V pin right next to the chip select and output enable pins. Who wants to bet that was originally designed to be the write enable line? I could just remove that pin from being hooked to +5V, and hook it to the write enable pins on the flash chips instead. That way the motherboard would keep it high (no write) when it was plugged in, but if it's outside of the computer, they would be separated. There is still another +5V pin on the other side of the SIMM (also labeled as alternate chip select, but I don't think anything uses it for that), so I would still have enough pins to supply power. I think someone may have suggested this idea already, so thanks for the idea...it's getting hard to keep track of everything

. . . but it just might be a "limited" workaround for the "impossible" NuBus Architecture USB hack!
. . . if possible, at the very least, it should allow reads and writes to keychain drives and chiplets.

Ooops, I missed out on your reply earlier jt! Sorry! I think if we were to look into getting USB storage, it would probably be easier to just start with a NuBus card that we can read and write to, rather than trying to squeeze it into the SIMM which can only be read from (like you pointed out, we'd have to hook it to a serial port or something to talk with it). I really like the idea, though. I think we could do something like what you said -- a microcontroller between the USB and the card to handle all the communication. And of course there would have to be a driver written to talk to it and make it appear as a storage volume on the Mac...

[Trash80toHP_Mini]

-- a microcontroller between the USB and the card to handle all the communication. And of course there would have to be a driver written to talk to it and make it appear as a storage volume on the Mac...

Since toolbox routines exist (?) for doing so, creating a driver for reading the information ought to be eminently do-able.

The MAC ROM SIMM is MEANT to be utilized as expansion for the majority of Macs which have provision for one.

Reprogramming info contained therein on the fly is just a really nasty trick to play on a poor lil' unsuspecting Mac. I'd call it block banging, as opposed to bit banging and it saves a slot, takes care of all your programming hardware on a device that expands your SIMM hack in a significant way.

Machines like the IICI, IIsi, SE/30 etc. are sadly lacking in NuBus slottage soooo . . .

[dougg3]

I see what you're saying that the SIMM socket is meant for expansion, but it's really just designed for ROM expansion. Otherwise they'd have some kind of write functionality available on it. Doesn't mean we can't hack a way to talk to it though through the serial port or whatever, true, true....

That's very true that for "expansion challenged" Macs it would definitely be useful. I didn't think of it like that, but you're right -- if we wanted to do USB to an SE/30 for example, the ROM SIMM socket just might be what we could use to allow it to work. On the other hand once we're hooking into serial ports anyway, is there much benefit to putting it inside the Mac rather than just making it an external box that plugs in?

OK, so the parts arrived and I started putting together another SIMM. I experimented on one with the new sockets and my smaller tip. The new sockets have much more open space so I may not have to remove the bottom plastic plate. The first socket I put in was mangled by my iron and I was having all kinds of trouble getting solder to go from the tip to the pins, despite covering everything with flux beforehand. I think it's because 1) the smaller tip has less surface area for heat transfer and 2) with the bottom plate in place, it's harder to keep a blob of solder on the tip without accidentally touching the upper parts of the socket's contacts. Anyway I'll have to remove that socket with some Chip-Quik or a hot air station or something.

Then I remembered I had just ordered solder paste. I did two more sockets after that with almost NO problem. The solder paste is amazing...it's slightly difficult to control it while I'm squirting it out of the syringe, but it works wonders for soldering. Just stick the paste over the PLCC pads, put the socket over it, heat up each of the socket's pins with the small iron tip, and the solder just flows where it's supposed to go like magic! The only difficult part is aligning the socket because the paste covers up the pads...

[olePigeon]

My parts store has 4 boxes of 64-pin sockets ranging from 45 cents to 95 cents (though I don't know what the differences are between them.)

[techknight]

if you choose to design a circuit to program the SIMM in circuit with the Mac off, make sure the flash IC and AVR MCU can get standby power, OR use a diode circuit off of the USB +5V and the macintosh +5v so it doesnt backfeed, Then you can use the USB port to power the AVR and Flash IC for reprogramming. Once done, the Macs +5v will power everything, but the 2 power supplies dont interfere. Choose your diodes carefully, youll need a shotkey diode because of its low voltage drop. All of these thoughts can be put into a new board revision. You could make an expansion board to plug into the SIMM socket of the mac, and plug your SIMM card into the expansion, the only issue with that is clearence. And i suppose you probably tied the WE pins so they dont activate, in which case youll need to make cuts, or make a new SIMM with an AVR + FT232R or a USB based Mega, or PIC on the backside of the SIMM.

If you use the AVR + FT232R method (easiest/cheapest) it will function as a target only, and give you only a serial port. If you want to use the USB port for other than programming, youll need a MCU that has a USB stack. there are a few USB AVRs that do this, but there are a vast majority more on the PIC line, then you could run a RS232 USB stack. And you could reprogram the AVR and change this stack as necessary, such as a USB Mass Storage Stack instead.

You could ditch the AVR with an AVR32 (more powerful, can run embedded linux/busybox, MIPS core?), and you can add not only USB, but Ethernet/WiFi expansion to it as well, they make stacks/drivers for those ICs, in which case you could tie the AVR/AVR32 to the Mac's System bus, so not only does the AVR32 switch out the ROM to be flashed, But it can have its own addresses on the system bus so you can have mac drivers access the USB/Ethernet or any other setups. And of course, its 32bit. No bottleneck of 8bit setups. Of course i can run on-and-on-and-on all day about different ideas.

I can think of really great ideas too, like a security-app on a phone that uses the accelerometer to detect motion, GPS to identify speed, in which case, driving, to disable text messaging. lol.

[dougg3]

Excellent olePigeon! I'm not really ready to start making anything, but it's good to know that you know a place that has them...that will be very handy. Thanks

Ah ok techknight, I think I understand what you're saying with the diode...so if I'm programming it over USB while it's plugged in, it won't try to power up the Mac's logic board through the USB power, but it will still allow the logic board to power the flash ICs when I'm not programming it. Got it!

Yeah, I definitely understand how I'd need a microcontroller with a USB stack rather than an FTDI chip to do something like mass storage, since the FTDI chip is only a USB to UART chip. Another possibility is one of the many ARM vendors, I've been using various incarnations of the Cortex-M3 (which might be overkill for this project) and it's pretty nifty.

You should take some of your ideas and make them reality!


I removed the bad socket with Chip-Quik and burned my finger in the process (awesome), resoldered a new socket, and I'm having a problem because a bunch of pins next to each other are shorted together. Since there are 4 sockets, I don't know which one it's happening on. I can't see any shorts, but they must be under the sockets. I think it's because I overdid it with the solder paste. I just realized that I can get dispensing needles to put on the syringe to limit the size of the stream that comes out...whoops, I forgot to order one! So this is a warning to future solder pasters...don't overdo it on the solder paste! I'm still not sure what I'll do with the board I messed up. It's probably fixable, but for now I'm going to let it be. I think I'm going to go back to my old strategy of cutting out the bottom plastic for the rest of these ones...

[dougg3]

Built two more SIMMs today. As crazy as it may sound, it's actually *easier* to solder the surface mount socket pins using a bigger iron tip. I'm starting to get the hang of dragging a big blob of solder along the pins to quickly solder many at a time. Works pretty well.

The sockets I'm using now do not seem to fit my PLCC extraction tool. I have to pry one side up using one side of the extraction tool, then pry the other side up to get the chips out. Tyco's official tool they recommend for that socket is just a hook you can stick in to pry one side up. I was hoping it would fit a normal extraction tool, but it doesn't seem that it does. Hopefully that isn't a huge inconvenience for everyone! On the plus side, these new sockets are much easier to push the chips into.

I still have at least 7 or 8 SIMMs available and ready to be built if anyone wants one!

I've also laid out the LEDs on the rev. 2 board. Looks like I can get away with using 2 LEDs in series with a resistor. I'm just going to keep them lit up at all times. I think trying to light up the LED whenever the output enable is active may cause problems because of the LED's voltage drop, so I'll just stick with keeping it lit at all times. Still need to separate the write enable and +5V lines to make it feasible to program the board directly in an external programmer board with a SIMM socket. I'll post a pic of an updated board design and gerbers later!

[Trash80toHP_Mini]

ISTR, that for the Mac Portable, the VERY large ROM Memory Space was meant to store programs and such in non-volatile, solid state memory.

Figuring on that, I don't see why Block-Banging good sized chunks of data from a Micro-Controller to your ROM SIMM and then to the MAC should be a big deal. You could even use cable drivers and a short parallel cable to connect the two PCBs inside the box with the USB port mounted on an empty section of backplane cover plate.

An all discrete gating logic config run over a parallel connection to your "ROMs" keeps the ROM SIMM simple/proc free & small!

[Dennis Nedry]

I think trying to light up the LED whenever the output enable is active may cause problems because of the LED's voltage drop

You can get around this by using a transistor.

Connect + of the LED to +5V, - of the LED through your resistor that you mentioned before to the collector of an NPN transistor. Connect the emitter of the transistor to ground. Then connect the base of the transistor to the output enable through a 10k resistor for example. You are using the transistor as a switch to turn the LED on and off, and you are controlling the switch with very small power from the the output enable.

This takes only two extra parts: a transistor and a resistor.

[techknight]

Then you have to pay attention to fanout. Just have to gauge the base current of the transistor, from the circuits driving it. because if your not careful, the base current would be enough to throw it into overload, burning up the chip that runs the OE line. Of course the posibility of this is extremely remote, but it can happen (experience, blew 74HC595s this way).

Best to use an SMD logic-level FET, its a voltage controlled device, not a current controlled device, so it would lighten the load on the digital circuits tremendously, at the cost of a pull-down resistor. (or pull-up depending on the active state of the OE line). If OE is active low, you'll want a P-Channel FET so the LED only comes on when OE is enabled.

just a tip....

[dougg3]

An all discrete gating logic config run over a parallel connection to your "ROMs" keeps the ROM SIMM simple/proc free & small!

Ooh, that's very true! That way I could make a bigger board that wasn't constrained by the SIMM size. I like it! We could put all kinds of cool stuff into it that way.

Connect + of the LED to +5V, - of the LED through your resistor that you mentioned before to the collector of an NPN transistor. Connect the emitter of the transistor to ground. Then connect the base of the transistor to the output enable through a 10k resistor for example. You are using the transistor as a switch to turn the LED on and off, and you are controlling the switch with very small power from the the output enable.

Ah, I see! That makes perfect sense. Thanks for the info. Just curious, what is the purpose of the 10k resistor, and how did you figure out that it should be around that value? Is it restricting the current that the transistor can draw, similar to how you use a resistor to limit the current an LED can draw?

Then you have to pay attention to fanout. Just have to gauge the base current of the transistor, from the circuits driving it. because if your not careful, the base current would be enough to throw it into overload, burning up the chip that runs the OE line. Of course the posibility of this is extremely remote, but it can happen (experience, blew 74HC595s this way).

Best to use an SMD logic-level FET, its a voltage controlled device, not a current controlled device, so it would lighten the load on the digital circuits tremendously, at the cost of a pull-down resistor. (or pull-up depending on the active state of the OE line). If OE is active low, you'll want a P-Channel FET so the LED only comes on when OE is enabled.

just a tip....

Thanks for this info too! OE is active low, so P-channel it is. Going this route, do I still need the 10k resistor, or when you say it's voltage controlled, does that mean that the 10k resistor isn't necessary any more because the current doesn't matter? Also, where would the pull-up/pull-down resistor need to go? On the base?

[techknight]

MOSFET doesnt have Base Collector Emitter. it has Gate Source Drain.

You would tie the gate into the OE circuit. You would then use a small 1k pullup from Gate to Source. Source tied to 5V. Drain tied to LED anode, LED cathode to ground.

all you need. IF you want to feel safe, you can put a 100ohm resistor between gate and main circuit. But if you use a standard mosfet that has a +/-10v or +/-20v Gate voltage, a resistor is NOT necessary, except a pullup, however the resistor offers some protection in case the MOSFET decides to ever short, it wont hold your OE line, becuase if it shorts, not only would the LED remain lit, but your OE would be forced high through the Gate to Source short, if one occurs. A gate resistor would prevent a hard short, so there is a chance the OE circuit could still pull low.

In a condition without the resistor, and the MOSFET shorts, OE could certainly try to pull low in that situation, but the pulldown transistor would overload and short out. leaving the OE stuck forever because the resistor isnt there to provide ballast from a hard short. So a 100ohm or so gate series resistor would be a good idea in case of a MOSFET short, so it dont blow your OE circuit.

in a 5v circuit tho, its VERY UNLIKELY the mosfet driving the LED could ever short, but given these chinese junk parts of today, you never know.... just design a circuit with that in mind... Dont need a chinese peice of shit taking out a pulldown transistor in a VLSI chip if it ever decides to short If you opt-out on the resistor to favor more transistor saturation, if it shorts, youll know becuase the mac wont startup and the VLSI will get hot fast.