I too can confirm that the green 3M ZIFs are poor quality. One came fitted to my programmer, and I have to do the scrape trick too, a lot of the time. I thought that was an isolated incident. I might consider retrofitting a better one now that I know it isn't, because it's a decent programmer, otherwise.

On the other hand, the Aries socket I bought for my previous prototype has served me very well. No failures there, but that's soldered down. I intend to recover it later; that thing was expensive.

Not sure if it helps but I've been using an Aries Eject-a-dip for my ROMs which is a bit cheaper than their ZIF sockets.

Haven't had any problems for the last couple of years with these, It also does a good job of holding the DIP plug in for my rom emulator


http://au.element14.com/aries/28-c182-1 ... ject-a-dip

Yep! I'm familiar with that part. Unfortunately, it hogs quite a bit of space on the board, as clearance has to be provided for the ejection levers. It won't fit on any of my POC designs.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Perhaps you can exploit the third dimension using stacking headers or similar.

In essence, that is what I am doing now. The ROM socket I use is one with machine-tooled pins, which allows me to plug the ZIF socket into it—the ZIF socket has 18 mill pins. I suppose when I design POC V3 I could open up some space around the ROM socket and use the Aries Eject-A-DIP. At the rate I've been going lately, I might never get past POC V2.1.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I have had some luck with using the $1 (or so) cheap 3M knock-offs in prototypes. For the price they usually work long enough to get things working, then I don't mind tossing them when I'm done.

I also found a stash of these on eBay a few years back. I only have about 8 left and don't know where to get more of them, but they are fabulous for EPROMS and endure countless insertions without failing or harming the chip. They are marked only with a stylized Robinson Nugent "RN" - no part number.

_________________
Bill

The old ZIF socket did have an intermittent on one pin, but replacing it with a brand new socket didn't cure the problem. The random crashes are being caused by something else.

After I had replaced the ZIF socket, I discovered I hadn't fixed anything, which sent me into a period of deep thought about what might be going on. Visions of obscure timing issues, excessive bus loading, a flaky 65C816, etc., were dancing in my head. So what I did was remove the ZIF socket, plug the ROM directly into its socket and powered up. Much to my amazement, the unit WOULD NOT RUN, even though it had run before in this configuration. At this point is was clear that there was a hardware issue lurking within.

The next step was to removed the Ø2 oscillator and substitute a much slower one, taking the unit's Ø2 rate from 12.5 MHz down to 4 MHz. Now the unit would boot and /IRQ and RDY activity were back to normal. Reinstalling the faster oscillator would result in the unit booting but then crashing. So it now appeared to be clock speed related.

At this point, I'm stuck in trying to troubleshoot the unit, as none of the parts I used should have any problems with high clock rates. The slowest item is the 55ns EPROM, which I also used in POC V1.1, which can boot at 15 MHz without the SCSI host adapter in place. Grrrrr!

P.S. The thought just occurred to me that this could be a problem being caused by signal voltage levels. I may have a basic design problem related to TTL vs. CMOS voltage differences.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

That's hard to hear BDD. I mean, the initial thought that it was the socket (of all things), was frustrating enough. Having it lead you down on a wild goose chase, that's even worse.

Hope that you can figure it out.

Overshoots / undershoots / line reflections ?

As you say the components are quick enough for 15 MHz, the logic works as it should, and problems appears with shorter cycle times. As you said the random crashes were still present with the new socket but the system didn't run without the socket it looks as if the sockets impedance/capacitance has a "beneficial" effect.

I think you need to pick up the scope to look how the signals look with/without socket. And on both ends of the bus as well. May be the signals getting worse elsewhere. (I haven't tracked this thread backwards - was it a 4 layer board?)

If it is voltage related you may lower VDD perhaps using one or two diodes. But then 15 MHz might not work just because the voltage is too low and the components getting slower.

I went back about something like 10 pages in this and did not see anything about thermal testing. Perhaps this random crashing problem is related to a physical flaw - either in one of the chips or in the copper on the board. I've had more than a few 'bad' chips in my life that seem to work 99.9999% of the time, then for whatever reason (usually heat, but sometimes cold or mechanical vibration) just malfunction long enough to derail everything. The same can be said for PCBs - microscopic cracks in traces, bad vias, traces with impurities that act like resistors and even bad trough-hole plating (similar to the bad via). I have seen all of this stuff more than once. If you've not already done it, it might not be a bad idea to put in a few laps around the board with a hot-air gun and a can of freeze spray. Even tapping things with the handle of a screwdriver.

_________________
Bill

Yep! Went through all that. I can't seem to be able to provoke anything by using mechanical or thermal "prods."

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

BDD,

in another thread you mentioned that perhaps the output voltage ratings of a CPLD or GAL may cause trouble when a 65Cxxx is the receiver. This would to some extend explain the behavior your POC V2.x shows. Have you considered to replace the CPLD with a piggyback board containing the same CPLD plus AC(T) type buffers for those signals that goes to the CPU?

Or, alternatively (and as an experiment) try adding some stiff (1K or less) pullup resistors on CPLD signals that go to the CPU.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I have thought of trying what you suggest. The mechanical interface would be interesting, as the CPLD is in a PLCC44 package and is socketed. I'd need an adapter that could be plugged into the socket to bring out the pin matrix so it can be soldered to the piggyback board. Dunno if such a gadget exists.

Things would be slightly complicated by the fact that the four data bus connections to the CPLD are bi-directional. So I'd have to use a bus transceiver, e.g., a 74ACT245, for that part of the circuit. The remaining connections (outputs) could go through a 74ACT541 or similar. These devices would add a small amount of prop delay—under 10ns, but that shouldn't be of any consequence.


I've though of that as well. I think I could get away with around 560 ohms, which would require the CPLD to sink about 9mA. It would be a challenge for me to get those resistors in place—I only have clear vision in one eye. GaBuZoMeu's suggestion would be a little easier in terms of assembly, if not in design.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

As an afterthought: Does the CPLD drive the CPU clock input? Assuming the CPLD offers selectable slew rates per pin, and if you haven't already done so, maybe you should try selecting the "fast" setting for the CPLD pin that drives the '816 clock input. I know this won't result in a higher VOH but it might reduce the time spent in transit between the "not zero anymore" voltage and the "kinda sorta one now" voltage. Worth a shot, maybe -- I'm just throwing the idea out there. (The pullup could be used in conjunction with this.)

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html