Yes, supply of costly parts is a problem. However, once you're in the process
of designing a device, it's not helpful to be constrained by what you have or
what you can easily get. In the '80's, there wasn't anything, TTL-wise, that
was particularly hard to get, so you designed with the stuff as though you had
it all at your disposal. Occasionally there would be shortages, with long
lead-times, that fouled up delivery schedules and manufacturing. In '80 and
'81, ISTR that 74LS38 and LS245 were in such demand that it didn't matter what
you did, you were going to be impacted by the shortages. I designed the NS
DP8304 in place of the '245 on one of my WW cards for the S-100 for just that
reason. The end-user could install the DP8304 or an i8287 if he needed that
buffer.
Last month, I had to build a programmer for a microcontroller. It required
only three components other than the MCU. There was an oscillator, a MAX232A,
and a 74HCT125. I had no trouble getting a suitable oscillator, and I
generally have a few MAX232's around. It took weeks to find the HCT125,
though, given that I didn't want to pay $10 for shipping of a $.25 part. In
the meantime, I'd built the thing with a GAL16V8. Overkill, well, true, but I
didn't have to deal with the widespread search.
Aside from the pinout, there's little you can't build in a 16V8 that would
otherwise fit in a 20-pin packaged TTL part, and you don't have to search.
The 16V8 cost around $0.60 last time I bought 'em, and is one of those parts
for which the programming spec was published back in '85 or so. If you use a
handful of gates and a decoder, you could just as easily use a 16V8 if it has
enough outputs. Then, if you want to change the address of a given device,
you just reprogram the part. That's always appealed to me.
If you look at some of the popular SBC's of the late '70's and early '80's,
you'll see that their decoding was based not so much on any orderly process of
organization, but on what they could do with the mix of gates with which
they'd arrived at a certain point. Now, it's a small thing, perhaps, but if
you can define the addresses of your devices based on what you need rather
than on what you can easily decode, I'd say that's an advantage.
The Ampro Little Board, which works quite well in spite of what they did, BTW,
is based on the notion that you are never going to expand it in any way. It's
a reasonable assumption for a small SBC, but if you've ever attempted to add
an HDC you quickly run into the fact that they ambiguously decoded several of
their devices, and you have to be very sure of where you tread in the I/O
space. It's not a big problem, since most folks wouldn't want to expand a
circuit like that, but a PAL or two, had they been inexpensive and popular
when the first Little Board was developed, would have taken care of that.
It goes without saying, howver, that given that you can program a decoder into
your PAL, you can decide where the I/O devices live and let the software
generation begin on the first day, once you've postulated the device
addresses, thereby shortening your time to market. Then, if software
discovers some advantage in changing the device addresses, it can be done
without any impact on parts count or device selection. It certainly doesn't
work that way if you're designing with TTL, for which an inventory has to be
established and maintained. Those "bean-counters" go nuts if you tell 'em you
want to use a 7432 where you previously had a 7402, paticularly if you need to
add rather than replace the part, and the guys doing the PCB layout won't be
happy if you decide you want to use an otherwise unused inverter in U106
between gates in U12 and U15.
These are small advantages, taken by themselves, but they clearly paint a
picture of how programmable logic got to be so popular.
As for prototyping quantities of Xilinx FPGA's, I doubt you'll find a TTL
vendor as willing to give you samples as the Xilinx people are. This wasn't
always the case, but if there's any chance you'll produce something that
results in some business for them, or if there's any likelihood you'll publish
an article based on some research you're doing, that might help promote some
feature of their devices in an interesting way, they'll give you the device
you need, and all the help you want, as well. Of course, they won't provide
you development code to run on your PDP-5.
Dick
----- Original Message -----
From: "Tony Duell" <ard_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Monday, April 15, 2002 7:56 PM
Subject: Re: TTL computing
> >
> > True enough, but the concept was cooked up by someone in their back room
or
>
> Fr the nth time, the same _ideas_ can be used with TTL, PALs, FPGAs, etc.
> So if somebody does manage to come up with a real advance in processor
> architecture, it won't matter if they happened to have worked it out
> using a board of TTL chips...
>
> > lab back in the days when TTL was still leading edge technology, and
nowadays,
> > the most common remark about TTL is preceded by "where can I get a ..."
>
> Odd. I was in 3 electronic component shops in London today. All 3 had at
> least some TTL chips in stock (one had a pretty good selection, the other
> 2 had at least gates and D-types). None of them had any programmable
> devices other than EPROMs. No PALs, no GALs, no PLDs
>
> When I was using Xilinx FPGAs in my job, one of the most common problems
> was finding somebosdy who would sell you prototyping quanitites ('No, I
> don't want to buy a tube of 15 of the PGA parts. Not at over 200 quid
each!')
>
> -tony
>
>
Received on Tue Apr 16 2002 - 09:46:02 BST