Another IIci ROM hack

[bigmessowires]

Doh! You're definitely facing some circuit board voodoo, and scope measurements are probably the best thing to help diagnose it further. But taking my best guess based on what you've described, this sounds like a voltage sag problem to me, and not RFI. It's quite likely that those EEPROM chips suck down a fair amount of current when you perform a write to them. If that's the case, here a few other things you could check:

Do all the EEPROM chips have decoupling capacitors too?
Is the 10uF capacitor pretty close (in terms of trace length) to the AVR and the EEPROM chips?
Your board doesn't have a voltage regulator, does it? I think it wouldn't need one, but if it does, what's its current rating?
As a test, could you try modifying your code to program the ROMs in round-robin fashion, instead of all at the same time, and see if the brownout detector still kicks in? Or insert a short delay after each byte programmed?

EDIT: 28.

[dougg3]

I can't program to each chip individually - it's all or none. Well, unless I screw up the unlock sequence on the other chips. But it's not just writing that screws it up -- trying to read the manufacturer/product ID from the chips causes it too. I can, however, pull out some of the chips. In fact, I did that the other day and it made the problem go away, if I remember right. I'll have to play with delays and removing chips.

All the Flash chips have decoupling capacitors on the SIMM. The 10 uF capacitor is really close to the USB port and not too far from the AVR itself. No voltage regulator -- just takes the +5V directly from the USB port. A picture is worth a million words, so here's what I have:

The decoupling caps are circled in green and are 0.1uF. (the capacitor near the USB port in the pic above is not a decoupling cap -- it's a 1uF cap for the USB (3.3V?) regulator built into the AVR connected to the UCAP pin)

The cap in the pic above is the 10 uF capacitor I've been talking about.

Here are the decoupling caps on the SIMM for the flash chips. The PLCC sockets are on the other side.

[Dennis Nedry]

Hmm It seems that you have plenty of caps where you need them. Here's a thought.

Your SPI I/O expanders are bi-directional and you switch direction for reading and writing data to/from the ROM chips, is this correct? And then you do some corresponding direction change to the ROMs too? Well, maybe there are delays involved in switching direction beyond what you had considered, and at some point in the process, the ROMs and I/O expanders end up being outputs at the same time for a moment. This could basically be a short circuit, which could defeat your caps.

Some chips offer a quasi-bi-directional option, that's a weaker output that can be safely driven high or low. You could check to see if you have that option anywhere and use it instead of output direction to see if the problem disappears.

[dougg3]

Whoa ---- Dennis Nedry, I think you nailed it!!! You are a genius!

I forgot that I had been playing around with some of my read/write cycle routines around the time this problem happened -- I had done a bunch of manipulation of the control lines in my bigger routines for writing to and identifying the chip, but then I realized I was repeating a bunch of code so I made a ReadCycle() and WriteCycle() routine. In the process of converting my code, I got the ordering of some of the operations mixed up (I had it correct before that change).

I just looked at my code:

Code: Select all

uint32_t ExternalMem_ReadCycle(uint32_t address)
{
   ExternalMem_Deassert(SIMM_WE);
   ExternalMem_Assert(SIMM_CS | SIMM_OE);
   ExternalMem_SetDataAsInput();
   ExternalMem_SetAddress(address);
   uint32_t tmp = ExternalMem_ReadData();
   ExternalMem_Deassert(SIMM_OE);
   return tmp;
}

See anything wrong with this? I'm asserting CS and OE, which will cause the Flash chips to output data on the data lines, and *then* setting the data pins as inputs on the microcontroller and SPI. If this function is called after a write cycle, the data lines on the microcontroller and SPI expander chip will already be outputs because that's how they were left by the write cycle routine, so the AVR's 16 data pins, the SPI expander's 16 data pins, and the flash chips' 32 data pins will all be outputs momentarily until I can get the SPI command to the expander chips to tell them to become inputs (and then I change the microcontroller's 16 pins to inputs directly after that). That's a relatively long time because of the serial communications!

The correct code is:

Code: Select all

uint32_t ExternalMem_ReadCycle(uint32_t address)
{
   ExternalMem_Deassert(SIMM_WE);
   ExternalMem_SetDataAsInput();
   ExternalMem_Assert(SIMM_CS | SIMM_OE);
   ExternalMem_SetAddress(address);
   uint32_t tmp = ExternalMem_ReadData();
   ExternalMem_Deassert(SIMM_OE);
   return tmp;
}

Which ensures that the data lines are set as inputs on the microcontroller and SPI expander before allowing the flash chips to output any data. I made that change, and no more brownouts at 4.3V! It was a SOFTWARE bug all along!

THANK YOU THANK YOU THANK YOU, Dennis Nedry! That was the problem. I'm still going to look at it on a scope to see what everything looks like, though With AND without the bug so I can see what was going on!

[ojfd]

The cap in the pic above is the 10 uF capacitor I've been talking about.

dougg3,
are you sure it is 10uF (microfarad) and not 10nF (0..01uF = 10 nanofarad) cap? I've never seen ceramic capacitor of 10uF of that small size.

EDIT - if it is indeed 10uF, do you have the data sheet? I am curious which manufacturer managed to squeeze 10uF in that package.

[dougg3]

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/170783 ... bb106.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%20She ... 20code.pdf

EDIT: No, that was crap. Here's the datasheet:

http://www.yageo.com/documents/recent/U ... -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

[ojfd]

Hmmm, indeed, 10uF...

I just noticed the tolerance on it kind of sucks (-20% to +80% -- that's bad, right?)

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.

[dougg3]

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

[ojfd]

OK -- I'll play with that when I'm around a scope to see what kind of difference it makes

Yes, scope is your best friend.

If I stuck with the small ceramic, maybe something like this (X7R) would work better?

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.

Maybe I should try to stick with NP0 for everything...

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.

[olePigeon]

THANK YOU THANK YOU THANK YOU, Dennis Nedry! That was the problem. I'm still going to look at it on a scope to see what everything looks like, though With AND without the bug so I can see what was going on!

I don't understand a single that that went on, but... huzzah!

[techknight]

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.

[dougg3]

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.

[techknight]

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.

[Trash80toHP_Mini]

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!

[dougg3]

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!

[bbraun]

Exciting! Sounds like it's getting close!

[Trash80toHP_Mini]

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

[dougg3]

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.

[Trash80toHP_Mini]

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!

[dougg3]

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!

[Trash80toHP_Mini]

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.

[dougg3]

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!

[olePigeon]

Can't wait.

[bbraun]

Same here! I look forward to that programmer and everything that enables.

[dougg3]

Got a lot of cleanup work done on the SIMM programming firmware/software this weekend. I wrote the PC controlling software for it using Qt, which allows me to use one codebase to compile an app for Windows, Linux, and OS X. It's working pretty well in Windows right now, but not yet tested in Linux or Mac OS X (hopefully soon--I anticipate it will need some fixes before it works on all three platforms flawlessly). There are still some issues to work out, but I'm getting close to having the SIMM programmer board ready to go.

I've uploaded all of the bootloader, firmware, and PC controlling software code to a Google Code project for everyone to peek at:
http://code.google.com/p/mac-rom-simm-programmer/

It's getting exciting!