>This looks like it could be quite helpful in demysifying a decoder.
>However, not all devices have negative-going enables and it leaves a gap
>there. In a PAL it would be just as easy to use to create a decoder that
>uses positive enables, e.g. as found on 6821's and the like. This isn't
>common but I've run into it just in the last couple of weeks.
Thanks, the next edition of "part A" will note that if the PAL output
is the other polarity, you want to invert it before using it to gate
the oscillator.
>On most of the "old" bipolar PALs, pin 11 was used as the global output
>enable, since most of the 16 and 20 input 20 and 24-pin PALs were capable of
>generating tristate outputs on every macrocell. The easy way to test for
>these is to use a weak pullup, driven by a single driver, together with an
>equally weak pull-down resistor array. This can be the same one if your
>resistor is on the order of 20K. When your device-under-test is disabled,
>it should follow the signal driving the resistors. Monitoring this requires
>you use no TTL in the monitoring circuit, since its inputs source current
>and will drive up an output.
Tri-stated outputs will be covered in an addendum at some point. I think
I've been pretty plain that *my* first priority was reverse-engineering
some address decoder PAL's, so I didn't have to worry about this the first
time around.
>One other thing that could stand to be circumvented is that the 'LS93 is a
>ripple counter which, with PAL speeds as high as they are, could generate
>internal glitches long enough set or clear a latch (normally implemented as
>a combinatorial loop in an 'L8 or the like).
True. I've noticed no such ripple glitches in my breadboarded circuits with 5
LS93's, but I'm certain you're right and that at the nanosecond level that
they're there.
>That might warrant the use of a synchronous counter at least in newly built
>devices. For a synchronous counter I like the 'LS590 because it's an 8-bit
>counter and has an extra internal register to which the count can be
Good recommendation, but the LS590 isn't quite as available as the 74LS93.
Ready availability of parts is vital to the "stone knives and bearskins"
mindset I'm adopting here.
>Also, for newly built devices, it's about as easy as anything to use a CMOS
>Schmidt trigger, e.g. 74HC132 as an oscillator. You need merely put about a
>1 MEG pot in feedback across the device, with inputs tied together to form
>an inverter, and hang a capacitor, say, 0.01 or 0.1, or whatever else is
>handy, and then tweak he pot to set the frequency. That way you don't have
>to admit you have used a 555.
Again in my neck of the woods 555's are more available, certainly there
are lots of other ways to make clock pulses too.
Many of the deglitching concerns of yours will be addressed with Part B,
which discusses a simple computer interface for scanning. The computer
simply waits a few hundred nanoseconds while between sending a clock pulse and
looking at the PAL output.
--
Tim Shoppa Email: shoppa_at_trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
Received on Fri Mar 03 2000 - 15:33:16 GMT