Thread
Another IIci ROM hack
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.
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.
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
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
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.
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.
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.
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!
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!
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!
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!
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.
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.
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?
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).
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!
*twiddles thumbs anxiously*
So, uh, any way us simpletons could get a new SIMM before the Thanksgiving holiday?
So, uh, any way us simpletons could get a new SIMM before the Thanksgiving holiday?
Oh I'm sorry! Of course. Anybody who is interested in a rev 2 SIMM, shoot me a PM. The cost will be $29 including priority mail shipping to the US (I'm using their flat rate boxes which are about $5). So the SIMM is $24 and shipping is a little over $5, but I'm rounding to $24+$5=$29 and calling it good. The cost includes 4 empty chips.
You will need an EEPROM burner to burn the chips until I make a programmer board, but to my knowledge this SIMM should be completely compatible with it when I have it ready.
Also to my knowledge this SIMM should work in any II series Mac with a 64-pin SIMM socket and the SE/30.
You will need an EEPROM burner to burn the chips until I make a programmer board, but to my knowledge this SIMM should be completely compatible with it when I have it ready.
Also to my knowledge this SIMM should work in any II series Mac with a 64-pin SIMM socket and the SE/30.
PM sent! 
Would you also sell unassembled boards? I could use the practice 
(Though isn't that how some of those NXP boards work?)
Or indeed any time when the last "concept" discussed in the previous post is not what you're responding to.
Basically, if reading straight through wouldn't make sense as a flow of conversation, and a word or two in your own post isn't enough to clarify
I was wondering about that too - but would it have to? As long as the board and the programming host can ID each other by MAC, all they'd have to exchange is raw ethernet packets, no?
Except the ROMs themselves aren't FAT, are they? How would that work then - drop the file to FAT storage on the programmer board, then the micro shifts it into the ROMs? Sounds convenient to the user, but inconvenient to you, and more complex and expensive for the board. The micro would have to read FAT, for starters.
(Though isn't that how some of those NXP boards work?)
Definitely sounds the simplest. Shirley there must be free/open source software around that could be used, adapted, or adapted to?
Well, it's 4 unnecessary parts (and points of failure) for most users - but the pads are still there on the layout, correct? So if anyone wants the socketed version, they can be simply be added?
Entirely appropriate, for just that reason
Or indeed any time when the last "concept" discussed in the previous post is not what you're responding to.Basically, if reading straight through wouldn't make sense as a flow of conversation, and a word or two in your own post isn't enough to clarify
Right -- the chips aren't FAT, so I would have to simulate the FAT filesystem. Whenever a file was written to the board, it would take the contents of it and write it directly to the chips. It may be kind of crazy to do, but I know the mbed LPC1768 board does that -- although it uses a custom chip to get it done. I like the USB-serial idea too, but the FAT idea is also intriguing. We'll see...
Yes, I will definitely make it a build-to-order option for whether someone wants a socket or not.
As for unassembled boards, sure! Do you want a kit with all the parts you need, or just the bare board? I would be happy to sell the bare board for $5 plus shipping, or a kit including sockets, capacitors, LEDs, a resistor, and 4 blank EEPROMs for $16 plus shipping.
If you want your own parts, you need four surface mount PLCC32 sockets, four 1206 0.1uF capacitors (5V or higher, I used 10V), and two 0805 LEDs and an 0805 resistor, with appropriate values considering a 5V source and the specs of the LEDs. I used two LEDs that have a 1.8V forward voltage drop each (Digi-Key part number 160-1421-1-ND), expecting 20 mA of current, and a 75 ohm 1/8 watt resistor, which will match with those voltage drops to give the LEDs about 19 mA of current.
Yes, I will definitely make it a build-to-order option for whether someone wants a socket or not.
As for unassembled boards, sure! Do you want a kit with all the parts you need, or just the bare board? I would be happy to sell the bare board for $5 plus shipping, or a kit including sockets, capacitors, LEDs, a resistor, and 4 blank EEPROMs for $16 plus shipping.
If you want your own parts, you need four surface mount PLCC32 sockets, four 1206 0.1uF capacitors (5V or higher, I used 10V), and two 0805 LEDs and an 0805 resistor, with appropriate values considering a 5V source and the specs of the LEDs. I used two LEDs that have a 1.8V forward voltage drop each (Digi-Key part number 160-1421-1-ND), expecting 20 mA of current, and a 75 ohm 1/8 watt resistor, which will match with those voltage drops to give the LEDs about 19 mA of current.
Yup! if any thread needs to be kept in context, it's this 17 Page Development MONSTER! [] ]'>
] ]'>
Shouldn't this thread be stickied? :approve:
Well, I'd like dougg3's opinion on that, but I'd say not - this being the whole process of development from go to woah here. Perhaps dougg3, you'd prefer to make a separate thread to announce sales of the final version, when you feel ready?
I've hardly ever failed to see this thread in the active topics window, it doesn't even NEED to be stickied!
B's been stickyin' generally useful info, I'd say this is more of a hacks-n-development project thread, not a general use info thread . . .
. . . awesome as it is! :approve:
B's been stickyin' generally useful info, I'd say this is more of a hacks-n-development project thread, not a general use info thread . . .
. . . awesome as it is! :approve:
Now prepare for sheer awesomeness! 
:lol:
It's my SIMM with custom boot chime and icons! Stay for the end of the video for the coolest Missing System icon ever!
Thanks dougg3! Coolest thing ever! Arrrrrr! :approve:
:lol: It's my SIMM with custom boot chime and icons! Stay for the end of the video for the coolest Missing System icon ever!
Thanks dougg3! Coolest thing ever! Arrrrrr! :approve:
lol! "Arrr!" Sounds like the Mac is upset for being woke up. 
Awesome graphics olePigeon!
Great work dougg3, you should get a "Macbel" prize or something!
Awesome graphics olePigeon!
Great work dougg3, you should get a "Macbel" prize or something!
Thanks guys! Definitely cool artwork/sounds olePigeon
I agree that this thread probably doesn't need to be sticky'd, it stays active on its own
I was wondering at what point a new thread is appropriate. It is becoming a bit of a mess to follow everything! I'm planning on having a programmer board ready in the future, I'm thinking I will do a trading post thread once I have that ready (although I'm tempted to do it now...)
The title of this thread isn't very descriptive of what's going on in it entirely my fault! Haha
I agree that this thread probably doesn't need to be sticky'd, it stays active on its own
I was wondering at what point a new thread is appropriate. It is becoming a bit of a mess to follow everything! I'm planning on having a programmer board ready in the future, I'm thinking I will do a trading post thread once I have that ready (although I'm tempted to do it now...)
The title of this thread isn't very descriptive of what's going on in it
entirely my fault! Haha
< mod mode >
The title is VERY descriptive of the first chapter!
)
How about a directory edited into the first page linking to the rest of the chapters? :?:
off the top of my head:
__IIci ROM Hacking adventure
__ASC tomfoolery
__Reverse engineering the 68k ROM SIMM
__Rev0 ROM SIMM Development
__Trials and tribulations of Rev0 ROM SIMM DeGubbing process
__Rev1 ROM SIMM . . .
__ditto 2 lines above . . .
__Programmer Board R&D
__etc.
"Figure" index (per Apple's DevNote Model) with links to any posts with those (really annoying to myself
) FLASH dependent VideoClips of the ROM Hacks.
Whatchathink?
< /mod mode >
Keep it in a single thread format, with bookmarks on p.1 to entice people into reading through the entire saga, IMHO.
The title is VERY descriptive of the first chapter!
) How about a directory edited into the first page linking to the rest of the chapters? :?:
off the top of my head:
__IIci ROM Hacking adventure
__ASC tomfoolery
__Reverse engineering the 68k ROM SIMM
__Rev0 ROM SIMM Development
__Trials and tribulations of Rev0 ROM SIMM DeGubbing process
__Rev1 ROM SIMM . . .
__ditto 2 lines above . . .
__Programmer Board R&D
__etc.
"Figure" index (per Apple's DevNote Model) with links to any posts with those (really annoying to myself
ROM Hacks.Whatchathink?
< /mod mode >
Keep it in a single thread format, with bookmarks on p.1 to entice people into reading through the entire saga, IMHO.
I object! There must be an entire chapter devoted to the Jolly Roger. )
)
NoPro, put the list of links together to each and every post . . .
. . . IIRC "link to this page" or "copy link location of any given post" will do the trick . . .
. . . post them and yours will be the first linked "chapter" to be posted! (whenever I get around to it editing them into p.1)
. . . IIRC "link to this page" or "copy link location of any given post" will do the trick . . .
. . . post them and yours will be the first linked "chapter" to be posted! (whenever I get around to it editing them into p.1)
I like it! Good idea!
Good idea!
Cool, I may need to have the Chapters Linked to their respective sub-links pposted in a Second Thread that'll look like a post index of your 17 . . . and counting . . . page . . . Introductory Post. The links in that thread will . . .
. . . whatever, I'll figure it out as I go! :
Any suggestions on how to streamline/improve this kind of project would be GREATLY appreciated!
This thread has just GOT to be some kind of freakin' record! [] ]'>
. . . whatever, I'll figure it out as I go! :
Any suggestions on how to streamline/improve this kind of project would be GREATLY appreciated!
This thread has just GOT to be some kind of freakin' record! [
] ]'>
This might need some reorganization/insertion/deletion/renaming but here is what I have after a quick skim of the entire thread (WOW! this thread really has come a long way from my original post about desoldering the DIPs and customizing the blinking question mark floppy disk icons!):
[*]ROM SIMM preliminary discussions and brainstorming
[*]olePigeon's Jolly Roger logo
[*]Arrival, assembly, and troubleshooting of the rev. 1 SIMM PCBs
[*]Brainstorming for programmability without the need for a chip burner and designing rev. 2 with that in mind
[*]tt's SE/30 with Power Mac startup chime
[*]Summary of changes in rev. 2 and later, additional changes
[*]IIci troubleshooting and power supply testing
[*]Back to programmer board R&D (and other expansion brainstorming)
[*]olePigeon's customized ROM
- First post (DIP ROM sockets, custom floppy disk blinking question mark icons)
- ASC tomfoolery
Custom synthesized startup sound (first few notes of Mario tune) and beginning of sampled startup chime adventure
- Sampled startup chime (newer Mac startup sounds)
[*]ROM SIMM preliminary discussions and brainstorming
- Reverse-engineering Apple ROM SIMMs
- trag's SIMM design
- tt's IIsi ROM SIMM X-ray image
- Initial order of ROM SIMM rev. 1
[*]olePigeon's Jolly Roger logo
[*]Arrival, assembly, and troubleshooting of the rev. 1 SIMM PCBs
[*]Brainstorming for programmability without the need for a chip burner and designing rev. 2 with that in mind
[*]tt's SE/30 with Power Mac startup chime
[*]Summary of changes in rev. 2 and later, additional changes
[*]IIci troubleshooting and power supply testing
[*]Back to programmer board R&D (and other expansion brainstorming)
[*]olePigeon's customized ROM
Looks fine to me. If you like, I'll add it to the top of the thread.
I would be thrilled if you would do that!
Back to the programmer board, I've started playing around with making a schematic for it. Looks like I can get away with using the AT90USB646 and one MCP23S17 I/O expander. That still leaves me with pins available for serial communication and a couple extra free pins, I'm thinking for status LEDs or something. I ordered some breadboardable DIP samples from Microchip of the MCP23S17 so I can see if it fits my needs.
Unfortunately, EAGLE light edition can't make a board big enough for the SIMM socket to fit (and the license doesn't let me make things I sell anyway--it's only for personal hobbyist projects). So I will have to switch back to FreePCB or KiCad or another alternative to create the board. For a project like this, laying out the board without a schematic (like I did with the SIMM) would be a nightmare so just doing the whole thing in FreePCB is not an option.
Back to the programmer board, I've started playing around with making a schematic for it. Looks like I can get away with using the AT90USB646 and one MCP23S17 I/O expander. That still leaves me with pins available for serial communication and a couple extra free pins, I'm thinking for status LEDs or something. I ordered some breadboardable DIP samples from Microchip of the MCP23S17 so I can see if it fits my needs.
Unfortunately, EAGLE light edition can't make a board big enough for the SIMM socket to fit (and the license doesn't let me make things I sell anyway--it's only for personal hobbyist projects). So I will have to switch back to FreePCB or KiCad or another alternative to create the board. For a project like this, laying out the board without a schematic (like I did with the SIMM) would be a nightmare so just doing the whole thing in FreePCB is not an option.
You can remove the non-commercial restriction from Eagle Light by purchasing a $49 license. It still has the same board size restriction, though: http://www.cadsoftusa.com/shop/pricing/?language=en
There's also a $125 Eagle Hobbyist version, which has double the board size limit, but it's restricted to non-commercial use.
Beyond that, Eagle gets expensive pretty quickly if you're paying for it from your own pocket.
Among cheap/free Eagle alternatives, KiCad seems to have by far the most community support. I get comments on my blog every few days from people telling me what a dope I am for not using KiCad.
There's also a $125 Eagle Hobbyist version, which has double the board size limit, but it's restricted to non-commercial use.
Beyond that, Eagle gets expensive pretty quickly if you're paying for it from your own pocket.
Among cheap/free Eagle alternatives, KiCad seems to have by far the most community support. I get comments on my blog every few days from people telling me what a dope I am for not using KiCad.