-
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
- Thread starter dougg3
- Start date
My boss said the same thing when I showed him, but I'm pretty sure it's 10 uF. It's a bit taller than the other 0805 capacitors I use on the board:
http://parts.digikey.com/1/parts/1707835-cap-ceramic-10uf-10v-y5v-0805-cc0805zky5v6bb106.html
I just noticed the tolerance on it kind of sucks (-20% to +80% -- that's bad, right?), so I might be better off switching to a bigger size in my next revision...
Here's the datasheet:
http://media.digikey.com/pdf/Data%20Sheets/Yageo%20PDFs/MLCC%20ordering%20code.pdf
EDIT: No, that was crap. Here's the datasheet:
http://www.yageo.com/documents/recent/UPY-GPHC_Y5V_6.3V-to-50V_5.pdf
CC0805ZKY5V6BB106 decodes to:
MLCC, 0805 size, -20%/+80% tolerance, 7" plastic packing, Y5V code, 10V, Ni-Barrier, Base Metal Electrodes, and I guess the spec sheet doesn't say what 106 means, but it's fairly obvious what it means since 104 = 0.1uF and 105 = 1 uF
http://parts.digikey.com/1/parts/1707835-cap-ceramic-10uf-10v-y5v-0805-cc0805zky5v6bb106.html
I just noticed the tolerance on it kind of sucks (-20% to +80% -- that's bad, right?), so I might be better off switching to a bigger size in my next revision...
Here's the datasheet:
http://media.digikey.com/pdf/Data%20Sheets/Yageo%20PDFs/MLCC%20ordering%20code.pdf
EDIT: No, that was crap. Here's the datasheet:
http://www.yageo.com/documents/recent/UPY-GPHC_Y5V_6.3V-to-50V_5.pdf
CC0805ZKY5V6BB106 decodes to:
MLCC, 0805 size, -20%/+80% tolerance, 7" plastic packing, Y5V code, 10V, Ni-Barrier, Base Metal Electrodes, and I guess the spec sheet doesn't say what 106 means, but it's fairly obvious what it means since 104 = 0.1uF and 105 = 1 uF
Hmmm, indeed, 10uF...
http://www.johansondielectrics.com/technical-notes/product-training/basics-of-ceramic-chip-capacitors.html
Try to solder some regular radial 10uF paralel to your ceramic cap and see what happens.
Not necesserily. It's theY5V material that's not so stellar.
http://www.johansondielectrics.com/technical-notes/product-training/basics-of-ceramic-chip-capacitors.html
Try to solder some regular radial 10uF paralel to your ceramic cap and see what happens.
OK -- I'll play with that when I'm around a scope to see what kind of difference it makes It will be interesting to see if my bad code works better if I have a larger 10 uF electrolytic there instead.
If I stuck with the small ceramic, maybe something like this (X7R) would work better?
http://search.digikey.com/us/en/products/LMK212B7106KG-TD/587-2668-1-ND/2417255
Thanks for the link -- that's interesting that the lower quality ceramics will age over time but it's curable by heating them to 125 degrees Celsius. Looks like even the X7R would suffer from that phenomenon too. Maybe I should try to stick with NP0 for everything...
It will be interesting to see if my bad code works better if I have a larger 10 uF electrolytic there instead.If I stuck with the small ceramic, maybe something like this (X7R) would work better?
http://search.digikey.com/us/en/products/LMK212B7106KG-TD/587-2668-1-ND/2417255
Thanks for the link -- that's interesting that the lower quality ceramics will age over time but it's curable by heating them to 125 degrees Celsius. Looks like even the X7R would suffer from that phenomenon too. Maybe I should try to stick with NP0 for everything...
Yes, scope is your best friend.
Yes, they're better, but not cheap, as you can see. For $0.55 per unit one can get some pretty decent low esr electrolytic, I think.
That would be overkill for your project. X7R is standart for general purpose +Vcc decoupling these days, besides, NP0 caps will be much larger for given package sizeand I'm not sure one can get 10uF in NP0.
i know exactly what your saying doug3. propogation delay can be your worst enemy in those cases. if your switch your inputs and outputs around, any bit of propogation delay at all could result in an output driving an output condition creating a "glitch". its known as shootthrough if i remember correctly.
shootthrough is especially important if your building a motor driver or switching power supply circuit. both top and bottom transistors cannot be on at the same time. In your case, the shootthrough wasnt caused by the same circuit, it was caused by a low-side driver being turned on at the same time a high side driver was turned on in a separate, but connected circuit as both circuits were set as output at that point in time. Causes shoothrough. Even though this timeframe could only be 100nanoseconds before one side of the circuit finally switches to an input, still 100nanoseconds is 100nanoseconds that they both remain outputs, which is 100nanoseconds of a possible shootthrough event.
shootthrough is especially important if your building a motor driver or switching power supply circuit. both top and bottom transistors cannot be on at the same time. In your case, the shootthrough wasnt caused by the same circuit, it was caused by a low-side driver being turned on at the same time a high side driver was turned on in a separate, but connected circuit as both circuits were set as output at that point in time. Causes shoothrough. Even though this timeframe could only be 100nanoseconds before one side of the circuit finally switches to an input, still 100nanoseconds is 100nanoseconds that they both remain outputs, which is 100nanoseconds of a possible shootthrough event.
Ah, ok! Well, in this case, it was in the range of more than 4 microseconds because of the time it takes to finish sending the serial commands to the expander chip. I had to send 4 bytes to the SPI chip at 8 MHz, plus I had to modify two 8-bit registers in the microcontroller. 4 bytes [32 bits] at 8 MHz is 4 microseconds, and then writing the registers to change the other two...so it was a very significant amount of time
I'll chalk it up to coding too late at night |)
I am really curious to try doing it as a parallel bus in a future revision (much later down the road, don't worry!) and ditch the SPI. I'm happy with the SPI but I think there are possibilities for future major speed increases, even if I do lose some electrical testing capabilities. I know everyone says I shouldn't go crazy over-engineering it, but I really do think it would be fun just as a learning experience I could keep an older board revision for testing SIMMs, but this newer revision would be great for raw performance. I know there's some combination of latches or something like that that could do it easily, allowing me to share my 16 data lines as a single 32-bit data bus.
I'll chalk it up to coding too late at night |)
I am really curious to try doing it as a parallel bus in a future revision (much later down the road, don't worry!) and ditch the SPI. I'm happy with the SPI but I think there are possibilities for future major speed increases, even if I do lose some electrical testing capabilities. I know everyone says I shouldn't go crazy over-engineering it, but I really do think it would be fun just as a learning experience
I could keep an older board revision for testing SIMMs, but this newer revision would be great for raw performance. I know there's some combination of latches or something like that that could do it easily, allowing me to share my 16 data lines as a single 32-bit data bus.
who cares if you over-engineer it? its your masterpeice, and as long as it works all is dandy
I over-engineer things all the time. For example, an MP3 player that has 2 CPUs, a VFD display, and high voltage boost converters/anode drivers. Talk about over-engineering, but hey its fun.
I also under-engineer things, like building an entire full size electronic outdoor scoreboard using sheet metal and vinyl covered pegboard, also without using a single capacitor. and it WORKED. lol.
I over-engineer things all the time. For example, an MP3 player that has 2 CPUs, a VFD display, and high voltage boost converters/anode drivers. Talk about over-engineering, but hey its fun.
I also under-engineer things, like building an entire full size electronic outdoor scoreboard using sheet metal and vinyl covered pegboard, also without using a single capacitor. and it WORKED. lol.
I "overengineered" the sign structures we built for almost 30 years. The only time one "failed" was during a hurricane, the center joint sections of the sandwich structure the sign riggers didn't tie together gave way. Luckily the single one of the four 5' x 16' panels that flew loose didn't even hit anything . . .
. . . but we bought our own crane truck after that. [}] ]'>
Moral of story:
Murphy is alive and well and lurking around every corner, do what you need to do to keep him napping, but don't worry so much about speed. This is a hobbyist project tool, the important part is that it works, makes the SIMMs more reliable over time, simplifies their build/testing processes and saves time overall in programming all four ROMs in situ . . . and has an expansion slot for additional ROM tomfoolery, so speed isn't even a serious consideration . . .
. . . anything under five minutes is friggin' gravy! Whatcha' want, DQ? Egg in your beer? [
] ]'>
Go Dawg, GO!
)
. . . but we bought our own crane truck after that. [}
] ]'>Moral of story:
Murphy is alive and well and lurking around every corner, do what you need to do to keep him napping, but don't worry so much about speed. This is a hobbyist project tool, the important part is that it works, makes the SIMMs more reliable over time, simplifies their build/testing processes and saves time overall in programming all four ROMs in situ . . . and has an expansion slot for additional ROM tomfoolery, so speed isn't even a serious consideration . . .
. . . anything under five minutes is friggin' gravy! Whatcha' want, DQ? Egg in your beer? [
] ]'>Go Dawg, GO!
) All right...I have something working! Writing the code (basically a big state machine) for the communication protocol on both ends is so boring...it's not difficult at all, just tedious.
I don't have any verification going on yet. The protocol is basically this: my GUI app asks the programmer if it can program, gets an OK response, then it sends 1 KB. Next it waits to hear a reply from the programmer on how that went, and repeats that process until it's done writing the data. I had to break it down into something about that size because the AVR only has 4 KB of RAM
It takes just under 2 minutes to do a complete write that way. I'm thinking performance could be improved by allowing the next 1 KB chunk to be sent while the first one is still being written to the SIMM, but at this point I just want to get the entire feature set up and running.
Anyway, I wrote my long Mario startup chime to a SIMM, stuck it in there...and it didn't work at first. Turns out I had the order of the chips reversed in my code. ;-) I think I got confused because the 68030 is big-endian and the code generated for the AVR is little-endian. (I don't think the AVR has an endianness because it's 8-bit, but the compiler does everything as little-endian). After fixing that, it works great!
I don't have any verification going on yet. The protocol is basically this: my GUI app asks the programmer if it can program, gets an OK response, then it sends 1 KB. Next it waits to hear a reply from the programmer on how that went, and repeats that process until it's done writing the data. I had to break it down into something about that size because the AVR only has 4 KB of RAM
It takes just under 2 minutes to do a complete write that way. I'm thinking performance could be improved by allowing the next 1 KB chunk to be sent while the first one is still being written to the SIMM, but at this point I just want to get the entire feature set up and running.
Anyway, I wrote my long Mario startup chime to a SIMM, stuck it in there...and it didn't work at first. Turns out I had the order of the chips reversed in my code. ;-) I think I got confused because the 68030 is big-endian and the code generated for the AVR is little-endian. (I don't think the AVR has an endianness because it's 8-bit, but the compiler does everything as little-endian). After fixing that, it works great!
This is the first time I've had to go to the hacks forum to find this thread . . .
*********B*U*M*P*********
. . . whatever, I hope you're enjoying this joyous season ans not stressing over this project, DQ! That goes for the rest of you tech troops too! [
] ]'>
I was thinking about ways to program the larger ROMs for the DIMM Modules in my PowerMacs, especially my PEx and came up with a wild notion . . .
Back in the day, we used four 32k SRAM ICs to emulate the 32k and 64k EPROM ICs on out target cards. Huge advances have been made in memory of every kind in the intervening 22 years.
I'm most impressed with the SD and, especially, the tiny MicroSD Chiplets so . . .
Why not create a daughtercard for the problematic PowerMac ROM DIMM that addresses a Chiplet as the four ROM ICs on the 81/110 DIMMs I've been collecting for surgery?
In 1989, the SRAM was so much faster than the target ROMs that there was no problem with speed in the emulation process. The same ought to be the case for whatever circuitry would be necessary for the Memory I/O conversion to emulate the PowerMac ROM ICs using SD/MicroSD as a non-volatile substitute.
Dunno, just thought I'd throw that notion to the WarDawgs of the 68kMLA Tech Contingent for consideration . . .
. . . or ridicule . . . :?:
*********B*U*M*P*********
. . . whatever, I hope you're enjoying this joyous season ans not stressing over this project, DQ! That goes for the rest of you tech troops too! [
] ]'>I was thinking about ways to program the larger ROMs for the DIMM Modules in my PowerMacs, especially my PEx and came up with a wild notion . . .
Back in the day, we used four 32k SRAM ICs to emulate the 32k and 64k EPROM ICs on out target cards. Huge advances have been made in memory of every kind in the intervening 22 years.
I'm most impressed with the SD and, especially, the tiny MicroSD Chiplets so . . .
Why not create a daughtercard for the problematic PowerMac ROM DIMM that addresses a Chiplet as the four ROM ICs on the 81/110 DIMMs I've been collecting for surgery?
In 1989, the SRAM was so much faster than the target ROMs that there was no problem with speed in the emulation process. The same ought to be the case for whatever circuitry would be necessary for the Memory I/O conversion to emulate the PowerMac ROM ICs using SD/MicroSD as a non-volatile substitute.
Dunno, just thought I'd throw that notion to the WarDawgs of the 68kMLA Tech Contingent for consideration . . .
. . . or ridicule . . . :?:
It's been a while Yeah, I've just been taking it easy during the holidays! (Also, it doesn't help that the NBA season is back in full force distracting me with games spaced really close together now after the lockout...)
The latest update is really just that I've started making a bootloader and I think I have a pretty good solution to make the SIMM programmer unbrickable. When you first power up the board, it *always* goes into the bootloader and waits for a command -- either to re-flash the firmware or to "boot" the firmware. Normally the first command sent to it would be to boot into the firmware, and then it would accept commands for programming the SIMM.
If bad firmware somehow gets flashed that prevents the board from working, it's OK because the next time power is cycled, it's waiting in the (totally untouched) bootloader for commands, and it can be sent the "re-flash firmware" command instead of the "boot" command to replace the bad firmware. I'm just trying to make it so you cannot screw up the board no matter what you do (short of physically damaging it).
I could have also put a button on the board you hold down when you plug it in to force it into the bootloader, but I used every single GPIO pin for something on this board, and I didn't want to mess around with reusing one of the pins as a bootloader entry pin. This strategy of always entering the bootloader should work fine for a simple device that doesn't have any time sensitivity for booting up.
As for your ROM DIMM idea, I think it could be done -- load the contents of the SD card into RAM chips which then act as ROMs. I'm pretty sure the SD card is too slow to directly be the ROM, but loading the SD card's contents into RAM would work. I like it! It would be a lot simpler (I think) than making a ROM DIMM + ROM DIMM programmer board. The tough part I can think of off the top of my head would be loading the SD card contents into the RAM chips at power-up so that they are ready by the time the CPU needs to read the first instruction. We wouldn't have a lot of time to get everything loaded.
Yeah, I've just been taking it easy during the holidays! (Also, it doesn't help that the NBA season is back in full force distracting me with games spaced really close together now after the lockout...)The latest update is really just that I've started making a bootloader and I think I have a pretty good solution to make the SIMM programmer unbrickable. When you first power up the board, it *always* goes into the bootloader and waits for a command -- either to re-flash the firmware or to "boot" the firmware. Normally the first command sent to it would be to boot into the firmware, and then it would accept commands for programming the SIMM.
If bad firmware somehow gets flashed that prevents the board from working, it's OK because the next time power is cycled, it's waiting in the (totally untouched) bootloader for commands, and it can be sent the "re-flash firmware" command instead of the "boot" command to replace the bad firmware. I'm just trying to make it so you cannot screw up the board no matter what you do (short of physically damaging it).
I could have also put a button on the board you hold down when you plug it in to force it into the bootloader, but I used every single GPIO pin for something on this board, and I didn't want to mess around with reusing one of the pins as a bootloader entry pin. This strategy of always entering the bootloader should work fine for a simple device that doesn't have any time sensitivity for booting up.
As for your ROM DIMM idea, I think it could be done -- load the contents of the SD card into RAM chips which then act as ROMs. I'm pretty sure the SD card is too slow to directly be the ROM, but loading the SD card's contents into RAM would work. I like it! It would be a lot simpler (I think) than making a ROM DIMM + ROM DIMM programmer board. The tough part I can think of off the top of my head would be loading the SD card contents into the RAM chips at power-up so that they are ready by the time the CPU needs to read the first instruction. We wouldn't have a lot of time to get everything loaded.
Welcome back from R&R, trooper. I"m glad you've got something to do in between programming sessions (interminable commercial breaks) for relaxation! [)] ]'>
Rats! I was hoping the chiplets have come far enough long in terms of response time to act as ROMs. That way I could do the PCB, now it sounds like a micro-controller will be necessary and that requirement puts the project way over my head. [
] ]'>
Is there some other kind of non-volatile memory slottage thingamahoozie available?
If not, battery backup for SRAM on the daughtercard will make it a real ROM emulator, just like the old days! [}] ]'>
Since you like the idea, at least I can get a start on the project. Depopulating a DIMM and turning it into a machine pin porky-pine for a wire wrap proto-emulator setup will do! [] ]'>
)] ]'>Rats! I was hoping the chiplets have come far enough long in terms of response time to act as ROMs. That way I could do the PCB, now it sounds like a micro-controller will be necessary and that requirement puts the project way over my head. [
] ]'>Is there some other kind of non-volatile memory slottage thingamahoozie available?
If not, battery backup for SRAM on the daughtercard will make it a real ROM emulator, just like the old days! [}
] ]'>Since you like the idea, at least I can get a start on the project. Depopulating a DIMM and turning it into a machine pin porky-pine for a wire wrap proto-emulator setup will do! [
] ]'>Well, other than just the speed issue, SD cards use more of a serial communication scheme. It looks like you can get 4 bits at a time out of it for maximum performance, but even if the SD card access time was fast enough to get the data out in time to directly be the ROM, you'd still need something like a microcontroller to send the SD card commands and translate the resulting chunks of 4-bit data into 32-bit parallel data for the ROM emulation. So I guess my point is that either way we would need something like an MCU
I know there are chips out there (non-volatile SRAM) that are essentially RAM on top of Flash that automatically save the RAM contents to flash when power is removed (and load the RAM from the flash when power is applied), but they are very expensive, so that's probably not an option. I hate to put a battery in anything, but we may not have a choice...
PCB design for something like that is going to get tougher. I seem to recall someone saying that it's probably going to take a 4-layer board to do DIMM stuff...it's probably somewhere in this monster of a thread!
I know there are chips out there (non-volatile SRAM) that are essentially RAM on top of Flash that automatically save the RAM contents to flash when power is removed (and load the RAM from the flash when power is applied), but they are very expensive, so that's probably not an option. I hate to put a battery in anything, but we may not have a choice...
PCB design for something like that is going to get tougher. I seem to recall someone saying that it's probably going to take a 4-layer board to do DIMM stuff...it's probably somewhere in this monster of a thread!
That'd be to do a replacement DIMM, I'm talking about a KlugeCard that would socket onto the pads of depopulated stock DIMMs. Hence the soldering of machine pins (cones down) to all necessary signal pads on the DonorDIMM. There'd be matching machine pin sockets pointing down from the ProtoKluge.
Battery backup ought to be very simple, they did it on exceedingly small (compared to my four chip beast) ROM emulators back in the early nineties. IIRC, SRAM retains info until it's powered back on, which flushes it out. Battery backup avoids that, a few one way diodes and you're (hopefully) good to go using the Macs power when it's available. But a button cell ought to be good as the ONLY Power Source for the SRAM for quite some time.
Dunno . . . it's a great day for impossible dreamin' about the coming year's projects.
Battery backup ought to be very simple, they did it on exceedingly small (compared to my four chip beast) ROM emulators back in the early nineties. IIRC, SRAM retains info until it's powered back on, which flushes it out. Battery backup avoids that, a few one way diodes and you're (hopefully) good to go using the Macs power when it's available. But a button cell ought to be good as the ONLY Power Source for the SRAM for quite some time.
Dunno . . . it's a great day for impossible dreamin' about the coming year's projects.
Wow...it's been forever since I've posted here! I honestly have not touched this project since I last posted. I think my hobbyist side goes into hibernation during the winter months |) Don't worry, I haven't forgotten about the project and still intend on finishing it soon.
I finally got around to working on the SIMM programmer today. I've got it mostly working aside from a few bugs. The UI is not very elegant but works. I really just want it to the point where it reliably reads from and writes to the SIMM over USB and can accept firmware upgrades over USB. Once it's at that point, the user interface prettification. detailed error checking, RS-232, etc. can be added in later. I'm pretty close to having the basic feature set done now. Just have a few kinks to work out. Stay tuned for more soon!
Meanwhile, I have a lot of sweet hack projects to catch up on in this forum now!
I finally got around to working on the SIMM programmer today. I've got it mostly working aside from a few bugs. The UI is not very elegant but works. I really just want it to the point where it reliably reads from and writes to the SIMM over USB and can accept firmware upgrades over USB. Once it's at that point, the user interface prettification. detailed error checking, RS-232, etc. can be added in later. I'm pretty close to having the basic feature set done now. Just have a few kinks to work out. Stay tuned for more soon!
Meanwhile, I have a lot of sweet hack projects to catch up on in this forum now!
