things might have been handled differently.

These compoents were on the shelf, still in the antistatic rails, with the invoice wrapped around the rails and held in place with a rubber band. If the rubber band hadn't broken on its own, presumably because of aging/oxidation, I might never have noticed that I had these parts.

If I had purchased them last month and found a significant portion of them not to be functional, I'd have proceeded differently. However, I ordered these in '86-'87 and simply put them on the shelf. I got them out a month or two ago because I thought they'd prove useful. They were not, as I plugged 'em into a prototype, the mainstay of my work, and found they behaved oddly.

I've concluded that they were yet another example of the reason that I don't trust distributors. They were likely rejected (they all bore the same lot number) because they exhibited a specific fault, though that was unknown to me. They are therefore suspect, at least in my view, and, since I'm going to use modern drop-in replacements rather than these old parts, which I intended to use as replacements.

There is a gotcha, there, though, as the reset problem that you've encountered repeatedly really never appeared until the modern flash-based parts came on the scene, though I'm not sure the cause was the flash or some other design change. The reset IC's came on the scene at about that same time.

A drop-in replacement obviously has to work reliably with the same RC reset circuit with which the original part worked. If modern FLASH-based parts don't work that way, it will be interesting figuring out how to replace the old NMOS MCU's when a need for a one-clocker or four-clocker arises in order to increase performance. The old-style RC circuit tolerates the bidirectional RESET that some parts provide. The MAX1232, for example, doesnt.

I had to get those parts out of here before they found their way into a situation wherein they could appear to work properly, but, ultimately, prove that they didn't.

If I'd had a thorough mechanism at the time I obtained these parts, I'd have known at the time that they were flawed, and would have returned them, as someone else apparently did. However, having found the flaws 20 years after the fact, I had little choice other than, simply, to protect myself from those flaws. I'd already wasted a couple of weeks of my spare time trying to figure out what was going on.

I know this reset issue is one you (Jan) have looked at in great detail, and I'd be interested in what sort of percentages you're able to verify as working properly when a "standard" RC reset doesn't work properly. Which parts have you studied in this regard, and what were the results?

Additionally, I'd be interested in knowing how, exactly, you'd go about testing a reset scheme, and how many reset iterations you perceive as a satisfactory test.

Once I mentioned the test-vector approach to testing these goodies, it occurred to me that it would be easily accomplished with any of a number of FPGA or even CPLD boards plus a buffered ZIF socket. All that remains, I guess, is to develop the code that actually does the test. No external memory is required, since all that's needed is to sample the signals to the external memory and feed the test-vector data at the appropriate times. The programmable logic will do the comparison and make the information available to the host PC. All that has to happen is that someone writes the code to communicate with the test logic. A simple sequencer can perform the actual transfers and comparisons, as well as the status checking.

I'll see whether I have a suitable board available and see, also, what it would take to make such a thing work.

RE