8501 dissection

[ttlworks]

@Ed:
Thanks for the kind words from the "Visual6502 corner", I really appreciate this.
Even if we won't manage to make sense of the NMI situation, at least we now are aware that the 8501 designers
had a creative aproach for "tacking" the unused NMI# pad to a (supposed to be safe) potential.
//Since a glitch at the NMI# pad at the wrong moment could disrupt the RESET sequence of the CPU.
Edit: NMI# riddle solved.

@Frank:
I'd also like to thank you again publicly for providing me those very good polygonized pictures,
I wouldn't be able to do that sort of work without them.
//I'm not good at interpreting the very faint diffusion layer in HMOS-II chips.
I really look forward to our (not so) little next projects... and 6509 is next.

[fhw72]

ttlworks wrote:

@Frank:
I'd also like to thank you again publicly for providing me those very good polygonized pictures,
I wouldn't be able to do that sort of work without them.
//I'm not good at interpreting the very faint diffusion layer in HMOS-II chips.
I really look forward to our (not so) little next projects... and 6509 is next.

I wish I could polygonize them faster...

[BilHerd]

Wow, this took me back.

[Sheep64]

ttlworks on Fri 28 May 2021 wrote:

It looks like the NMI# trace is tacked to the output capacitor of the bias generator
(the side of the capacitor which connects to the two FETs working as diodes)
by using a pullup (pulldown ?) FET, and we have no idea why.

Has NMI been converted into a power glitch detector? Does typical hardware have NMI routine which is consistent with power glitch?

[ttlworks]

Sheep64 wrote:

Has NMI been converted into a power glitch detector?

No, it hasn't.
I figured out later, that it's a trick to bring NMI# to a slightly negative voltage potential,
just to make sure that NMI# can't trigger by accident.

Quote:

Does typical hardware have NMI routine which is consistent with power glitch?

I'm interpreting your question as "is it typical to have a NMI routine triggered by power glitch detection hardware ?"

I have not seen something like that in a 6502 system... yet...
but for old VMEbus 68k machine control hardware it would be normal to have some circuitry which detects power supply failure
and triggers INT7 for saving machine status etc. "to NVRAM or such" in time.

[Dr Jefyll]

ttlworks wrote:

I figured out later, that it's a trick to bring NMI# to a slightly negative voltage potential,
just to make sure that NMI# can't trigger by accident.

Hmm, so why didn't they prevent accidental triggering by simply tying NMI# to Gnd? Perhaps they wanted to be able to intentionally trigger NMI# for factory testing (before the die got encapsulated)... ?

-- Jeff

[ttlworks]

Dr Jefyll wrote:

Perhaps they wanted to be able to intentionally trigger NMI# for factory testing (before the die got encapsulated)... ?

Most certainly yes, but it's an interesting question if the voltage levels for triggering the NMI# pad would be TTL compatible:

There is a lot of trace resistance between the NMI# pad and the inverter which senses NMI#,
and the FET which generates the negative voltage bias on the NMI# trace sits close to said inverter.

[Sheep64]

ttlworks on Thu 24 Mar 2022 wrote:

There is a lot of trace resistance between the NMI# pad and the inverter which senses NMI#

Tying NMI to ground (or power) would leave it inert. That's the obvious thing to do but that's not observed.

If the bias ring has high capacitance and the trace has high resistance then there is a large resistor-capacitor product. In favorable conditions, tying NMI to the bias ring is no different to tying NMI to ground (or a little less). However, this resistor-capacitor network would be relatively stable compared to ground-bounce. In this case, power glitches exceeding a certain speed and magnitude would trigger the unused NMI. Sensitivity could be tuned by varying the length or width of the trace.

One thing we cannot determine from die shots is the stage in the process where someone thought "Hey, if we tie it here, we can re-purpose all of this apparatus rather than wasting it!" Unfortunately, this apparatus remains wasted if all 8501 systems had NMI vector to RTI or routines which detect "spurious" interrupt and exit.

Actually, it might be possible to invoke Dr Jefyll's programmer's panic switch by deliberately invoking a brief power glitch near 8501. Why waste a pin for such functionality?

[ttlworks]

The 8501 has no NMI# pin:
There is no wire bonded to the NMI# pad of the chip.

So we can't just observe what effect a glitch in the power supply might have to the NMI# circuitry of the 8501.

Unfortunately nobody in this forum seems to have an academic degree in semiconductor physics,
so debating about what the designers did there and why, which effect it exactly might have etc.,
only would be speculative without leading us to a useful result.

Would suggest to buy an 8501 for $70 at ebay, then to inject pulses into the power supply and to see what happens.
But I won't do that.


Actually, the purpose of this dissection was to gather enough info about the 8501 innards for building a FPGA based 8501 plug_in replacement,
because it became increasingly difficult to buy (used) 8501 chips as spare parts, and because the ebay prices for said chips went through the roof...

[BigEd]

ttlworks wrote:

Unfortunately nobody in this forum seems to have an academic degree in semiconductor physics,

Ha ha! Might well be true, but as it happens I do have a Masters in VLSI Design, which covered both Computer Science and Electrical Engineering topics. It was a fun-filled intensive 12 month course, but I started it with only a hobbyist knowledge of all these things, so I'd say the textbooks are well work a look by any interested party.

This was one:
Introduction to MOS LSI design
By J. Mavor, Jack Denyer, Mervyn A. Jack, Peter B. Denyer
1983
242 pages
available to borrow online here
https://archive.org/details/introductiontomo0000mavo

and this was another:
Introduction to VLSI Systems
By Carver Mead and Lynn Conway
1980
400 pages approx
and available online at Conway's site here
https://ai.eecs.umich.edu/people/conway ... IText.html