Another IIci ROM hack

[PowerPup]

Well, they weren't the original Mac II... What were they... Let's see...

http://68kmla.org/forums/viewtopic.php?f=4&t=11884#p118515

I also have some Mac IIs. 3 ci 2 cx and a vx. I haven't tested any of them yet to see which ones still work.

I'm pretty sure they all had come from the local elementary school, when they were clearing out the basement/storage.

Oh well. Maybe I'll get lucky and find one someday in the wild. I should ask if he kept any of the motherboards. (What didn't sell he parted out the Hard drives and motherboards. I sold all the hard drives on the forums here a while back.)

 

[dougg3]

Ohhh, that would have been awesome to snatch up one of those machines :-(

Well, in the future I'm going to be looking at similar hacks for other expandable Macs, so maybe in time another one of your Macs will be hackable with a custom ROM DIMM!

I just remembered to look up that resource I was talking about that I found in the System file (System 7.5.5). I saw that the ASC Sound Manager component referenced this "STR " resource (-16583).

Apple Sound Chip hardware specific support. Controls the hardware interrupt and calls up the sound component chain to get audio data for the ASC. Jim Reekes calls this the spatula.

(There are several other resources for other sound chips that also have the "Jim Reekes calls this the spatula" quote)

There are other similarly interesting ones, like -16580:

This is the glue between the sound component chain and the sound manager. It gets more audio data when more is requested. Jim Reekes calls this the fridge.

-16579:

Utility audio data converter, goes forwards, backwards, changes 8 bit data into 16, 16 into 8, offset binary into twos compliment, twos into offset, it slices, it dices.

I always get a kick out of finding stuff like that.

Here are a few more:

In the middle of the data fork of the System file from 7.5.5:

Help! Help! He's STILL being held prisoner in a system software factory!

(and then many names of people and stuff)

At the end of the data fork of the System file from 7.5.5:

Will the last person to leave please turn off the lights?

 

[Bunsen]

and ROM Disk driver.

*cough* SD card?

As long as a microcontroller/FPGA or something could translate between ROM requests and SD card accesses, but the fast timing there would probably cause problems. / I'm suspecting that the image of what's stored on the SD card would have to be loaded into RAM that's connected to the IIci's SIMM pins

It was mostly the fact of an existing driver to treat ROM space as a read-only Mac drive that I wanted to point and wave at

The SD card thing was purely an afterthought, an example of a possible way of getting data into the ROM space from another machine, rather than a concrete suggestion. There may well be other storage formats which would be easier to address. Obviously bit/byte-addressable flash ROM or RAM being the easiest from the host Mac's point of view - and having a serial port (via the programming board) to squirt data into kind of makes it redundant anyway.

If we can get a blank, formatted, read-only Mac drive to appear in that space, well - the contents are at the whim of anyone with a programming board } (Though that does bring up the question of how one wrangles that drivespace from the other, programming-host-machine, end.)

My thoughts are that this is the right direction to head in - simple as possible ROM board, for all users; optional separate programming board for experimenters. And that looks like where things are heading, so yey |)

it would be easier if I use a 5V serial port instead of 3.3V. Is that going to cause a problem? I think a lot of those types of cables are designed for 3.3V

Just checking - you're talking about TTL serial here? IIRC, RS232/Mac serial is 12V, and anyone coming from that end is going to need a level & protocol transceiver anyway, either on or attached to the board.

How about pads on the programming board for an optional level shifter - either jumper/solder-bridge past it direct to the pinout, if you want to use 5V TTL; mount a 5V/3.3V level shifter if you're using 3.3V; or mount a RS232 transceiver if that's your need.

 

[Trash80toHP_Mini]

Here's where I chime in again about my ancient ROM Emulator Project!

ThirdGen "ROM" SIMM:

__Replace ROMs on SIMM with battery backed up SRAM addressable from the Mac.

__Add MicroController to program "SRAM/ROMs" upper ROM expansion memory space on the fly, right under the nose of the OS.

__Use expansion board with the MicrocController/Medi adapter/transltor to hold I/O adapter and Storage media.

__Divide Expansion Memory Space into two Blocks to be loaded in sequence.

Mac "driver" hits first Block for "VM" data.

SRAM/ROM's Microcontroller tells partner which Pages to load sequentially into the two Blocks for a "expansion" memory access > one Block

SRAM & USB(?) speeds hoodwink the Mac driver's Block Banging into thinking it's addressing a HUGE VMspace . . .

. . . Drivers would be tweaked versions of RAMDisk+ and the like . . . :approve:

. . . other end of SRAM/ROM hack is WAAAYYYYYYYY over my pay grade . . . :I

 

[dougg3]

Good news -- I just went back to removing the bottoms of the sockets and doing the soldering the "normal" way. Unfortunately sometimes the socket bottoms come out intact, and sometimes they are destroyed. So sorry, it's just not viable to put them back in afterward But the GOOD news is my SIMM worked on the FIRST try with NO shorts at all. So basically it's 300 times easier to assemble the board when you cut the bottom of the socket out. I'll keep doing it that way since it's more reliable, at least until I can try to bake the boards with some reflow soldering.

It was mostly the fact of an existing driver to treat ROM space as a read-only Mac drive that I wanted to point and wave at The SD card thing was purely an afterthought.

Gotcha...yeah, we'll have to look at the Mac Classic and see how it does it. It would be GREAT if the driver could just be snatched from the Classic ROM...

Just checking - you're talking about TTL serial here? / How about pads on the programming board for an optional level shifter / mount a 5V/3.3V level shifter if you're using 3.3V; or mount a RS232 transceiver if that's your need.

Yeah, sorry -- I meant 5V TTL, just the raw signal coming from the microcontroller's UART before being fed into any level shifters or whatever. I could definitely add pads for the level shifter and/or transceiver. I guess this is where I was looking at just doing USB because otherwise there are tons of various options that people might want and USB makes it nice and simple. But I can also see where diehard people might want to hook it up directly to a Mac serial port, or someone might already have a USB to serial adapter and don't want to pay out the nose for an FTDI chip added to the board. I'll see if I can give it options to work with RS232, USB, 5V TTL, or 3V TTL, with only the stuff populated for what each person wants, or something along those lines.

Here's where I chime in again about my ancient ROM Emulator Project!

Whew...I'm trying to follow it all, but basically you're saying use the upper unused ROM space as a way of reading from other media like an SD card or USB flash drive or whatever, by addressing a microcontroller connected to the SRAM chips on the special ROM SIMM, through an expansion board? (Presumably a PDS/NuBus card, otherwise it would take SCSI or serial or something to gain write access) And then once you've told the microcontroller what data to load, you access that loaded data (which is now in the SRAM chips) through the ROM space? My first thought is if you need the expansion board in place anyway, why not just leave the ROM alone and do it all through the expansion board? Just brainstorming...

 

[dougg3]

And now that I'm no longer fighting this beast, here's a picture of it in action.

I actually ended up taking the same picture at different exposures and used some HDR magic to try to make the individual LEDs visible...it's not perfect but it looks closer to reality than any of the individual pictures!

 

[olePigeon]

8-o ;D

 

[bigmessowires]

Nice work Doug!

If I can offer a suggestion from the peanut gallery: keep it simple with the programmer board, and leave it up to the individual what to put in the ROM. If someone can find a way to hack in a ROM-disk using portions of the Mac Classic ROM driver, awesome! But I don't think that will really change your hardware. For the programmer, have you done a rough estimate of home much the programming board might cost? If it's a significant fraction of the cost of an EPROM programmer, then it may make more economic sense for people to buy the EPROM programmer instead of a single-purpose SIMM programmer. Of course there are other non-financial reasons to build a programmer board, like the intellectual challenge and satisfaction of a home-built tool. None of my projects have ever made economic sense, but my wife keeps telling me they should.

 

[dougg3]

Thanks! I totally agree with what you're saying -- get the board done and then worry about all the cool applications for it. That's exactly what I plan to do, for sure. I have done a rough guess-timate a few pages back:

So the AVR costs $4.38, the FT232RL costs $4.50, and I'm not sure what the 64-pin SIMM sockets would cost (do you know the cost of the ones you found, olePigeon?). If we can't use SIMM sockets, the socket for the Samtec header costs $3.27 and I need two per board, so that's another $6.54. Brings the total to around $15. Plus there will be miscellaneous capacitors, resistors, crystals, USB port, etc. that will add to the cost. So we're probably looking in the range of $30-35 or so for the assembled SIMM programmer board...hopefully that's not too astronomical of a price!

It's starting to approach the $40-ish price of an EEPROM programmer, but there are advantages:

1. the PLCC sockets are no longer absolutely necessary, and even if they are still there you aren't constantly removing them (lowers the price of the SIMM if not there, and makes it more reliable -- PLCC sockets are terrible and flimsy and the chip's contacts get worse and worse the more you remove/reinsert them, even with the nice extractor tool)
   
2. All 4 chips are programmed simultaneously so it's 4X faster to flash (assuming I can match the performance of my EEPROM programmer)
   
3. The cheap EEPROM programmers require a Windows PC with a built-in or PCI/PCI Express parallel port (USB adapters don't work), and this would work with anything that you can get serial into (either with a serial port or USB), whether Mac, Linux, Windows, or whatever else OS we can dream up

Either way, I'm still making the board just for the intellectual satisfaction as you said I don't even care if I make money or break even, it's just a fun thing to work on in my spare time. There's not a huge market for this product anyway (I've only sold 3 SIMMs). But yeah, now that I've gotten the hang of designing circuit boards, I want to prove to myself that I can learn how to make one with a microcontroller on it. I'm going to use EAGLE for this one, and it has taken me a while to get comfortable with it, but I'm getting there.

 

[Trash80toHP_Mini]

Here's where I chime in again about my ancient ROM Emulator Project!

Whew...I'm trying to follow it all, but basically you're saying use the upper unused ROM space as a way of reading from other media like an SD card or USB flash drive or whatever, by addressing a microcontroller connected to the SRAM chips on the special ROM SIMM, through an expansion board? (Presumably a PDS/NuBus card, otherwise it would take SCSI or serial or something to gain write access) And then once you've told the microcontroller what data to load, you access that loaded data (which is now in the SRAM chips) through the ROM space? My first thought is if you need the expansion board in place anyway, why not just leave the ROM alone and do it all through the expansion board? Just brainstorming...

The lower portion of the single (battery backed up) SRAM IC (or a standard SRAM Card in a socket on the "ROM SIMM" Card) emulates the four ROM ICs on your Revs 1 & 2 ROM SIMMs.

This leaves plenty of PCB real estate on the Gen3 "ROM SIMM" for the loading/address transmitting microcontroller and a micro USB(?) port/interface for comms with programmer/expansion card.

This stand alone card with a more capable microcontroller/translation circuitry, etc. will just need a power takeoff from the FDD Cable or a splitter for the HDD power cable.

This "expansion" card would have a micro USB port for communicating with the "ROM SIMM's" microcontroller and another micro USB(?) port for the cable to a single, female USB(?) panel mount socket to be placed in any appropriate space so that you can plug a USB(?) keychain/thumb drive into the Mac.

Does this make any more sense to you? :?:

I'm guessing the least common denominator would be USB1, but maybe the microcontrollers can do USB2 by now? :?:

I'm just spitballin' here too! : We used an entire PC with a custom parallel interface card/cable combo to program the SRAM on our "Font Emulator" from files stored on the PC's HDD.

 

[dougg3]

Ah, OK! For read-only USB access. I see where you're going, and that would be possible. I think I would probably use something other than USB between the SIMM and the extra board in that case just because USB can be kind of complicated to set up, and doesn't really seem ideal for communication between two microcontrollers. Actually, it might even be possible just to put the USB directly onto the SIMM and call it good. Who knows...

More brainstorming about the programmer board that I'm planning on making:

Originally I was thinking AVR, but now I'm thinking maybe a 5V Cortex-M3 would work well, especially one with built-in USB. Then I could avoid the FTDI chip and get both USB and serial both for free...although the USB becomes a bit more complicated because I would have to provide a USB stack and appropriate code to use it as a USB CDC device (which is probably available online). In particular, this chip looks very interesting.

 

[bigmessowires]

I recently wrote a "getting started" review for the Cortex M3, if it's of any help to you: http://www.bigmessowires.com/2011/10/27/cortex-m3-for-dummies-stm32-discovery-board/

You probably know this already, but if you want to stick with AVRs, there are also AVRs with built-in USB: everything in the AT90USBxxx series, as well as the newer -u suffix ATmegas like ATmega32u4. LUFA seems to be the most popular software library for USB for those AVRs. It comes with example code for all the different USB class devices including CDC I think. I've been looking into this a bit myself recently, since I'm considering adding USB support to an existing AVR-based project.

 

[dougg3]

Thanks -- I've actually been using the Cortex-M3 for quite a while now. I've mostly been experimenting with the NXP chips. I'm a big fan of the Cortex-M3 architecture, and I think it's starting to make it easier for hobbyists to get into the ARM arena. I have an IDE set up with Eclipse, CodeSourcery Lite, and OpenOCD for JTAG -- it works pretty well. I see you did a Newark product review--cool! They asked me to do one too and I did the Freescale KwikStik, which is a Cortex-M4 board.

I didn't think about using an AVR that has USB built-in, so thanks for that info! Unfortunately I did a quick search and the main problem I'm running into is finding an AVR with both USB and enough pins. From what I can tell I will need at least 54 total pins available for connection to the EEPROM chips (8 data pins per chip = 32, plus 22 of the 24 remaining pins that are shared among all 4 chips [ground and VCC are the two exceptions that I don't need to access]). It looks like some of the AVR32s might fit the needs, but none of the suppliers seem to have them in stock--and they have minimum quantities in the 100s. Ugh...so I may end up sticking with the Cortex-M3. We'll see...I know serial GPIO expander chips exist, but I would really prefer not to use them because the total cost of them would add up and I like the simplicity of just using a single microcontroller.

Thanks for the info on the USB software libraries. I knew they existed but didn't really know where to start with them. Hopefully I can find one that works on the Cortex-M3 I'm looking at, because I'd rather not code my own from scratch

 

[dougg3]

Ya know, I was thinking, I may be able to get away without having a ton of pins.

I could program one chip at a time (which would be slower), but it could allow me to use a cheaper microcontroller by connecting all the chips' data lines together on the programmer board and controlling which chip I'm addressing using the CE# pin. So in terms of GPIO, I would need:

19 address pins

8 data pins

1 OE# pin

1 WE# pin

4 CE# pins

-----------------

= 33 pins

(plus serial/USB pins) which will be easier to find. Looks like the AT90USB646 is a good fit.

The disadvantage of this approach (aside from slower programming) is I lose the ability to pinpoint exactly which chip a data line short belongs to, but it's no worse than how the address pins are set up right now. But the advantage is I would be able to stick with AVR, which will probably be more hobbyist-friendly than a Fujitsu industrial-targeted chip. With my limited board design experience I feel I'll have a better chance of succeeding if I use an AVR. That may just be what I'll go with.

 

[Trash80toHP_Mini]

I've had this on back-burner for a while, "one at a time" was one question, multiplexing the address lines to do sections of each set of four was another question I had about methods to reduce the pincount.

 

[dougg3]

Doh! I didn't think that through correctly. The chip select lines on all 4 chips are already tied together on the SIMM itself. There's no way to get around that. I can't control them individually. I have to program all four chips simultaneously because of the way the SIMM is set up. I knew there was a reason I didn't think of that earlier...

I'm thinking I should still go the route of the AT90USB646. I can add a serial I/O expander, my choice of SPI or I2C, to do the data lines or the address lines (or both -- and I may be able to get to the point where I can use a smaller AT90USB chip too).

The Microchip MCP23017 (I2C) or MCP23S17 (SPI) both look promising (they do 16 bits each, so I'd need 2 of them).

Actually, here's my idea now:

I can use 3 MCP23017/MCP23S17 chips to handle all 32 data pins and 16 of the 19 address pins. The other 3 address pins, CE, WE, and OE are connected directly to the MCU. Plus I have to use 2 pins for I2C or 3-4 pins for SPI. Then another 2 pins for serial communication for people who don't want to use USB. That only requires 10 to 12 I/O pins on the MCU itself! I could move down to the AT90USB162, but it only has 512 bytes of RAM, so probably not. Anyway, if I use 3 I/O expanders, it looks like once I go into bulk deals of 10 microcontrollers at a time and 25+ I/O expanders at a time, I'm in the $8.84 range for the microcontroller/IO expander combination. Maybe less if I only need 2 I/O expanders (I can just hook all the address pins up to the MCU). Anyway, It's looking good!

 

[Dennis Nedry]

From my experience, the serial bit rate will be the limiting factor. A Megabyte may take minutes even at 115200 bps, and ordinary serial comm doesn't get a whole lot faster than that. At the typical 9600 bps, this bloats to almost 15 minutes with a binary connection. Using an ascii connection probably doubles these times.

A USB or ethernet connection may provide luxurious speeds. You can get these interfaces built-into microcontrollers. Some clever ethernet action could get you access to the microcontroller from the Mac itself!

 

[Bunsen]

A quick note on "house style" at the MLA:

Please don't quote the post directly above yours, if that's what you're responding to - just reply. We can all read down the page.

If you need to quote something from further back, please edit it down to what's relevant to your reply.

Thankyou.

 

[Bunsen]

or ethernet / built-into microcontrollers. / could get you access to the microcontroller from the Mac itself!

Intriguing.

dougg3- re your thoughts about the cost of this dedicated programmer vs a generic EPROM programmer: as you already have a design for a SIMM with PLCC sockets, users could always buy one of those as well - and use it as a generic EPROMmer, no?

 

[dougg3]

From my experience, the serial bit rate will be the limiting factor.

Yeah, that's very true and I forgot about this. All the more reason to stick with USB, that's why I'm liking the AT90USB series. I'll still leave serial as an option just in case though. I know there are MCUs out there that do Ethernet too, but I feel like that might get kind of confusing to set up because it would probably have to talk on IP with a specific IP address and all that stuff.

I was thinking maybe it could appear as a USB mass storage device that you drag the .bin file to, that way no drivers or extra software would be necessary at all (as long as your OS supports reading/writing FAT32). But that may be too complicated in which case I would make an app that would talk to it as a USB serial device (which I think would not be limited to 115.2kbps).

as you already have a design for a SIMM with PLCC sockets, users could always buy one of those as well - and use it as a generic EPROMmer, no?

Hope this is appropriate for quoting -- even though you're the post directly above mine, I'm trying to differentiate between my response to Dennis Nedry and my response to you.

You are absolutely correct! And not only would it be a generic EPROMmer, but it would be a generic EPROM burner that could do 4 chips at once. The chips I'm using supposedly support some JEDEC standard command sets, so it's possible that other chips would use the same "unlock" sequence for writing. It looks like you write to a few standard locations to unlock the chip for writing/erasing. I may have to add instructions to the firmware for talking to the different types of chips out there, but yeah, it should work that way, as long as it's a chip that can be programmed with only +5V applied to it and it uses the same standard JEDEC pinout.

That's a good argument for sticking with the sockets on my SIMM boards!