• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

Another IIci ROM hack

This can only mean one thing...

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

Boot icon:
Mario-Boot.gif.8b56766bbc9c5953a268c89a5c77973d.gif


System icon:
Mario-System.gif.257d224b47ae6388b260f2ced98708cd.gif
(toggles between nothing and dead mario when looking for system/floppy)

Alternatively, you could use the Dead mario for the Sad Mac. xx( ;)

Icons with masks here.

 
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.

 
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 :-D 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 :I

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...

 
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...

 
-- 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 . . . }:)

 
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... :-/

 
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.)

 
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.

 
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...

 
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!

 
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!

 
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.

 
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....

 
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?

 
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. :-)

 
WOOHOO!!!!!!!!!!!! 12 pages and counting! 275 replies and 5,018 views for a new recruit's introductory post! :approve:

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.
That's the exact config we used back in '89-'90 to feed info to the four 32k SRAM Chips that "emulated" EPROMs on standard $300 font cards.

Modern EEPROMs (?) and such make the hardware just a tad smaller, the input end of our parallel cable to the ROM emulator was an all discrete logic ISA Card, the Proc & Storage was a friggin' PC and its HDD!

Now you could do it on a slightly oversize ROM Card, but to build your own "PC" for inside the Mac with today's technology is just wild and waaayyyyyy over my head!

Just the LED discussion gives me a headache! :I

edit: your base card remains as useful as, and not a lot more expensive than, the cards you have running right now. ;)

The feeder card would be an option to be added at any time and the input cable opens up the "system' to development by the rest of the PoAMM contingent of the 68kMLA! [:D] ]'>

 
I agree that the mosfet is a better choice, it did cross my mind, but I thought people may be more widely familiar with ordinary bjt transistors from science projects and such. Also you have to worry about weird stuff with mosfets, like the gate storing a charge unless you add some megohm resistor to it or something. The example was written with simplicity in mind.

The 10k was a random number, it depends on voltages and the transistor, etc. 100k could have been another example.

If you do want to make an LED show the OE status, let us know and one of us will scribble something out that uses a tiny little mosfet for you. It's much easier to explain with a picture.

 
Ah, thanks for the info you guys. Transistors are confusing (to me!). I think for simplicity I'm going to just keep them lit at all times. I don't know how often the ROM is accessed anyway, so for all I know, the light might barely blip on at all except at power up, which would make the whole thing a waste. Plus, the case is closed, so it's probably not an essential feature.

I'll try to finish the design, post some pics on here, and send out for more PCBs soon. I'll probably do an order of 50 boards this time...I'll also post my FreePCB project file if anyone wants to make or mod their own.

Wish I could make it USB programmable, but I just don't think I can make it fit unless I do something like jt mentioned with cables connecting to a bigger board. An external board with a SIMM socket and USB port may be the way to go. Is there any alternative to SIMM sockets I could use to make contact with the SIMM contacts for programming?

 
Back
Top