So, how's the weather over there? My Mom took a trip to the northern reaches
and Isles a few years ago and IIRC, none of her pictures had blue sky or
shadows in them. She and my second-cousin, who lives in Munich, wanted to do
that again, since the springtime was apparently of interest to them.
see below, plz.
Dick
----- Original Message -----
From: "Tony Duell" <ard_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Friday, April 12, 2002 7:43 PM
Subject: Re: TTL computing
> > I hope you're not suggesting that devices that use core memories are in
any
> > way BETTER than more modern machines that use semiconductor memory.
>
> Well, considering core memory is radiation hard and non-volatile, I would
> think it could be considered to be better than semiconductor RAM for some
> applications. It's also got a much longer lifetime (when was the last
> time you had a core plane (not the drivers) fail?)
>
It really doesn't matter which part of the core memory subsystem fails, does
it?
BTW, I've never had a memory failure on a PC. I've had numerous ones in
varous older commercial systems, but never a hard failure in a PC memory
subsystem that I can recall. I've had rotating memory troubles on occasion,
but not on machines that are kept running.
Considering that any one of my PC's has more RAM in it than all the core-based
machines I've seen in my 30+ years in the field combined, I'd say that's a
decent outcome.
>
> > > A PROM contains more 'bits' than a PAL. In particular, a PROM can
compute
> > > any combinatorial function of its address inputs, a PAL cannot (think of
> > > a 16C2. 16 inputs, effectively 1 bit output. A PROM like that would
> > > contain 64K bits of storage, but there are many fewer fuses in the PAL).
> > >
>
Actually, I think they still used core memories when they dropped the 16C2.
The 16C2 is optimized for decoding, though, isn't it?
>
> > A PAL can generate any combinatorial function of its inputs. A prom can
do
>
> Sorry, but absolute rubbish (well, I'll qualifiy that. Given a large
> enough OR matrix, it's possible, but all real PALs have a very restricted
> OR matrix).
>
Nevertheless, while they have a fixed OR matrix, they have a very flexibly
programmable AND array, which allows you to express any logic function of the
number of inputs you have in SOP form. Keep in mind that you can use multiple
macrocells to create ridiculously complex functions. I've not run into a
function I couldn't express in a 42VA12. Product term depletion is quite well
avoided there. If I were to find one, I'd try an ICT 7024. Those are both
24-pin devices
>
> > that too, but the PAL does it with fewer fuses.
>
> And that should tell you something is 'wrong'.
>
> Let's consider a single-output combinatorial function of <n> inputs.
> There are 2^(2^n) possible functions (including ones that ignore some or
> all of the inputs).
>
You're running down an unimplementable path again, Tony. You can't implement
all those functions in a comparable ROM either. For starters, though, let's
postulate that you've got, at most, 22 inputs. (a 24-pin device with Vcc and
Gnd). Each pin you use as output, of course, has feedback, but it's not an
input. Nevertheless, that means 44 signals to the AND array, since each input
is in true and complement form.
Quite obviously, you can AND whatever combination of these that you want, and
use up to 8 of these sum terms in, say, a 22V10. Since a ROM doesn't share
inputs and outputs, you'd be dealing with a larger package, but, since you've
only got 8, 10, or maybe even 12 outputs, there's a limit on what you can
derive from that number of inputs. PALs have the same technological
restrictions as PROMs, so whatever size of fuse array you can generate in a
PAL, you can also have in a PROM, and vice-versa. Now, I won't say it's
impossible to run out of product terms in a PAL, I've never run out when I was
willing to use another macrocell's SOP, thereby sacrificing the output pin.
>
> This is easy to see. Think of writing out the complete truth table of the
> function. It's got 2^n lines (one for each of the possible combinations
> of the inputs). In each line we have to pick the output bit, either 0 or 1.
>
Truth tables are an unwieldy way to create/analyze PALs, though they were once
popular. When you do use a truth table, you don't need to include all the
inputs. You only need the ones involved in your particular logic function.
Boolean equations are an easier way to deal with the SOP formatted logic
functions. That way, you can easily apply Quine-McLuskey or Karnaugh map
techniques to reduce your logic. The software tools are what makes these
devices so handy. They do the reductions, and configuration for you quite
painlessly.
Remember you've got 8 or 10, or even 12 outputs on a small PLD. The really
small PALs have only 8 product terms per sum, and, in fact, the 20RA10 has
only four per register, with the others used for control of the register and
output buffer. Of course if you run out, you can sacrifice an output in order
to use its SOP in your required logic function.
In a somewhat larger PAL, say a 42VA12, (sadly, no longer in production) you
still have 22 possible inputs, in addition to which you have the outputs of 12
registers, which can be buried, (two always are, as there are only 10 output
pins) and all the inputs to the AND array are available in either true or
complement form. The AOI gate has 64 product terms, and the macrocell has a
register, an output enable, a product term clock (each FF can be operated
asynchronously if you like), a direct set, a direct reset, a polarity term,
and an output enable. You can, of course, bypass the register altogether and
simply use the buffered SOP output. You can, if you choose, selectively
tristate an output under some conditions, using the feedback path as an input
from the external environment.
I've never even seen a PROM that allows you bitwise control of the output
enable, let alone one that allows you to use output bits, bitwise depending on
conditions as inputs. As a consequence your range of inputs is smaller with
a PROM of a given size than with a PAL.
>
> Now if you claim you've got a circuit that will let me create any n-input
> combinatorial function with fewer than 2^(2^n) programming bits, then I
> have to say you are mistaken. There must be some functions you can't
> implement.
>
the possible fuse arrays are about the same size, regardless of whether you
have a PROM or a PAL. How they're implemented differs somewhat, in how
they're applied, however. Because the OR array is fixed, fewer bits are
programmable, but then, if you use a PROM to generate random logic, there are
lots of redundant bits. The PAL, with its fixed OR array, won't let you
generate a lookup table. If you need a lookup table, you'd use a PROM. OTOH,
if you need a decoder, that's straightforward enough using a single output.
>
> So I say again. Consider the 16C2. It has 16 inputs and 1 output (yes, 2
> output _pins_, but one is always the inverse of the other). Does it have
> 65536 programming fuses? No! It has many fewer. Therefore there are 16
> input functions you can't fit into a 16C2.
>
Well, you've picked a long-obsolete device type, Tony, but if you consider
what it was intended to do, I think you'll find it can detect and signal any
unique combination of the 16 inputs. The 'C' means it's a comparator. Have
a look at a more general-purpose device, e.g. a 22V10. It has some macrocells
where you might run out of product terms, but that's seldom a problem when you
consider what sorts of things you might want to do with the device. The two
innermost macrocells have 16 product terms, while the two on the outside have
only 8. The ones in between fall in between, with 10, 12, and 14. ( I think
that's right. I haven't looked at a sheet in about a decade.) This means you
might have to arrange your outputs so they correspond with macrocells having
the appropriate number of product terms.
>
> > > Sorry, I cannot accept that a 'state machine normally lives in a single
> > > PAL'. Not as I consider things like synchronous counters ('163, etc) to
> > > be state machines (if they're _not_ state machines, then what the heck
> > > are they?)
> > >
> > They're state machines, but nobody uses them except for repair parts
nowadays,
>
> Oh for %deity's sake. Will you please try to understand the difference
> between the following :
>
> The parts _you_ choose to design with [PALs, GALs, PLDs]
> The parts others choose to design with (for whatever reasons) [Just about
> anything]
> The parts that have been used in the past [Ditto]
> Parts that could theoretically be created [e.g. a PAL with a large enough OR
> matrix to implement any function, and which will have as many programming
> bits as a PROM]
> Theoretical concepts [PDAs, Turing machines]
>
Yes, except that the last two are really not germane to the topic which was
semantic. I don't disagree with you except in the sense that you continue to
mix theoretical concepts with "real-world" ones.
>
> Otherwise there's no point in talking to you.
>
> You may not want to use the '163 any more.
I use 'em if (a) I've got 'em, (b) there's room for 'em, (c) they're adequate
to the task, (d) they can still be gotten readily for a repair. In part,
that's why I take apart old computers that have socketed DIP's in 'em.
Sometimes I use a torch and remove parts I know I may want.
> Others may (particularly for
> 1-off designs, it takes a lot less time to solder in a 16 pin chip than
> to program a PAL). But whether or not you want to use it, it exists. It
> certainly _has_ been used in the past. And it's still a state machine.
>
Well, I seldom have a "1-off" application that has a PCB laid out for a '163,
since a PAL can contain more logic at less cost. That wasn't always the case,
but 22V10's take up less space than two 16-pin DIP's, yet can provide
precisely the same logic as two '163's, and, in fact, improve on them in that
it can provide a synchronous carry.
>
> > Well, there are state machines that you can buy, e.g. the 4017, or the
74161,
> > or the 74193, all counters of one sort or another. You can also put the
>
> Actually, by the normal definition of state machine in electronics, a
> ripple counter is not a state machine...
>
A ripple counter's an ASYNCRHONOUS state machine, methinks, though those are
considered bad form, but all the counters above are synchronous. The '161
and '193, like the '163, have ripple-carry, though the '193 gates the carry
with the low phase of the clock. That makes the thing capable of dividing by
1, which the others can't reasonably do. The 4017 is a Johnson counter, which
is synchronous also, though this one's decoded.
Received on Sat Apr 13 2002 - 03:56:12 BST