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 12:29 PM
Subject: Re: TTL computing
> > > Are you saying that a program in a mask programmed ROM is not firmware?
> > > Because everybody else that I know would call it that.
> > >
> > There are many who would disagree with them, Tony. One characteristic
common
>
> We are going to have to disagree on this point. Maybe it's a UK .vs. US
> thing, but over here, the term 'firmware' would include data stored in
> masked ROMs.
>
> > > And where do you put core memory? Or core-on-a-rope? :-)
> > >
> > I do believe the obsolescence of core and plated-wire memory predates
EPROMS
> > and certainly EEPROMS, but although cores and PW were capable of
persisting
>
> What's that got to do with anything? Whether or not something is
> 'firmware', or 'microdode', or... should not depend on the exact memory
> technology used to store it.
>
It's got little to do with anything except the historical development of the
sematics of the terms we've been kicking around. History, and
implementations, do have effect on how the nomenclature develops.
>
> > from one power cycle to another, there were other issues with it. As for
> > where to put it, if you don't need the stuff, I'd put it in the junk bin I
>
> OK, 'how do you catagorise it'.... (Did you really not understand my
> original comment?)
>
> > keep in a remote corner of the basement. That's where my core boards are.
>
> Odd... Mine are in working computers and calculators...
>
Yes, but you collect such things and I don't.
>
> > You need to consider moving forward into the '80's, Tony, since PROMs with
>
> Why? I just need to solve the problem. And the fact that the best
> solution for a particular problem (or a point under discussion) was
> developed more than 20 years ago is not a reason to ignore it. (Well, not
> unless you're an idiot who believes in the rubbish put out by marektroids!)
>
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.
>
> > external registers and feedback went out when PALs came down to <$8 each.
For
>
> 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).
>
A PAL can generate any combinatorial function of its inputs. A prom can do
that too, but the PAL does it with fewer fuses.
>
> > performance reasons, (the PROMs back then being slower than PALs, and
costing
> > nearly as much) building a small state machine using discrete proms,
> > registers, and steering logic was pretty inefficient and, frankly, quite
>
> For small state machines, sure. But not all state machines (and not even
> all state machines that I've designed) are 'small'.
>
> In ant case, the size of the state machine, and the way it's implemented
> (PROM, PAL, etc) shouldn't make any difference to whether or not it _is_
> a state machine,...
>
> > As you undoubtedly can see, how you view the world greatly influences how
you
> > define the terms you use. If you don't see the difference between state
> > machines and microcode, it's because you don't think of them as blocks in
an
> > executive summary. I'm convinced that the shape and size of components is
>
> Correct. I have little use for 'executive summaries'. I have slightly
> more use for true (and accurate) block diagrams, and a lot of use for
> complete schematics...
>
Before people draw those schematics, they first manipulate the concepts on a
big dry-mark-board (whiteboard), waving their arms and arguing vehemently that
their take is the one. Once the blocks have been mapped into the
requirements, low-level design meetings are held where they do the same thing,
only at more detail. That's where the block that later becomes a PLD is born.
Block 6B divides the clock by 1-1/2 to generate the clock you need and then
propagates the appropriately divided output to block 5D which demodulates the
data and passes it to the framing logic in block 2G. Three different guys
design those blocks, and they're later implemented in separate PALs, or in a
single PLD.
>
> > heavily influenced by the ways in which they're incorporated in designs.
One
> > thing that makes one see state machines differently than microcode is that
> > microcode normally took up several PROMs, while a state machine normally
lives
> > in a single PAL. Clearly, if you view things from a perspective of the
'70's
>
> 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,
since it's more efficient and cheaper to have 100 GALs costing well under a
dollar and not having to track stock and worry availability. For simple
logic, I always have some 22V10's, 20RA10's, 16V8's and a few 20V8's around
just for the case where I need some function I don't have in TTL. I don't
usually buy the TTL any longer unless it's for a repair. I do scrap old
hardware and save the parts, since that saves me driving around. I do have a
tester, after all.
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
equivalent logic in a PAL or larger PLD. In fact, you can also put several in
one device. They're still state machines. I suppose you can still buy
counters like the '269 or the '393, but they're no longer the most efficient
or most effective way to build things. I bought a couple of 74F269 counters
last week, for a board someone else designed. I learned that it would have
saved me money to program a 22V10 for that function, since the 22V10 costs
less. It was for someone else, so I bought the parts, since he also paid for
the parts, but I'd have built my own part and made the hack just to save the
time and air pollution. It would have saved me time, as it took half a day to
find the parts. I can whip up a synchronous counter with synchronous preset
and clear in about 15 minutes, and that's from memory. It's even quicker than
that, because I have 'em in a library. What's more, if I need to change the
polarity of the load strobe or the clear, it's done with a stroke. If it's
got to divide by 3, yet produce symetrical output, I can do that ... I can't
buy it, though.
I know that wooden ships were a beautiful and quiet solution to the problem of
how to get from England to Central America, but there are lots of them on the
bottom of the ocean, and I'd rather take my chances with a 747. Does that
mean that flying is better than sailing, well, maybe not, but it is the method
of choice, for most of us, nowadays. If I have two weeks and a lot of budget,
I like cruising, but if I have to be at a meeting tomorrow, and don't want to
put on ten pounds, then I fly.
>
Received on Fri Apr 12 2002 - 20:05:22 BST