see below, plz.
Dick
----- Original Message -----
From: "Tony Duell" <ard_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Sunday, April 14, 2002 12:27 PM
Subject: Re: TTL computing
> > > > > Did not the early PAL's burn on PROM programers? (512x8 fuse prom)
> > > > > Sadly this not true today.
> > > > >
> > > > My "early" PALs program on the same programmer that programs my
bipolar
> > PROMs,
> > > > and my current-generation GALs as well.
> > >
> > > Everyone knows you can get 'universal' device programmers that program
> > > PROMs, PALs, GALs, EPROMs, microcontrollers, and so on. The original
> > > question was clearly asking whether early PALs used a similar
programming
> > > algorithm to the bipolar PROMs of the same time period. I don't think
> > > they ever did.
> > >
> > Yes, they did, "burn" in programming circuits similar to what was used to
> > program bipolar PROMs. These were simple circuits pretty completely
specified
> > in the datasheets.
>
> Well, 'programming' a PAL (or a PROM) includes both selecting the fuse
> you want to blow and then blowing it. IIRC (and it's been a long time
> since I looked at this), actually blowing the fuse was _similar_
> (although not identical) for both PROMs and PALs. Selecting the desired
> fuse was pretty different.
>
Back in the '70's, one used a Data I/O Model 29 (?) which was very expensive,
and for which the software updates cost quite a bit. There were, however,
programming circuits/application-notes published by the manufacturers, e.g.
MMI and Signetics, that went into considerable detail about how to program the
parts in question. They emphasized building the circuit in such a way that
you wouldn't damage their part and didn't put as much emphasis on how to
program the part correctly, i.e. how to address the particular fuse you wanted
to program, laving that somewhat murky, but it was there if you wanted it.
>
> I don't know of _any_ PAL that you could simply stick into a programmer
> that had been designed for PROMs only and program it. There were (and
> are) plenty of programmers that do both, and there were programmers that
> took adapter modules for PALs and/or PROMs.
>
> But I still don't know of any PAL where you can take the fuse map (on a
> computer), transform it if necessary and then upload it to a PROM-only
> programmer that you've plugged the PAL into, And expect the PAL to work
> at the end of it.
>
Well, if I had a PROM-only programmer, I'd interpret the designation of
PROM-ONLY as meaning it was a waste of time to try to program a PAL with it.
However, the technique of selecting the fuse was the only real difference,
electrically between the two device types, and that was described in the early
app-notes. Unfortunately, the 1986 databook I have at my feet is not early
enough to include that information. I have a few earlier data books, and
perhaps one of them will go into sufficient detail. The basic strategy was,
however, the same as with a bipolar PROM. Select the fuse word by applying
the appropriate signalling sequence to the device, then sink current through
the appropriate output pin of the device being programmed, with the Vcc supply
elevated to the specified level. IIRC, those voltages weren't much above 5
volts, and were, indeed, below the 7-volt absolute maximum. If you built a
device capable of handling the bipolar devices, you had the basic hardware to
do the PAL job already in place. The driver software had to be built,
however, as did the code for translating the JEDEC file that the software,
e.g. ABEL, PALASM, or CUPL, into the fuse selection/programming algorithm that
would be executed by your programming hardware.
Over the years, the makers of these devices have gotten tight-lipped about the
programming algorithms because the home-built devices, even those built by
knowledgable engineers, caused them such a service headache. If your local
sales rep. saw that you were a serious user of their devices, you could gain
access to that information.
It just happened that in about '85 or so, I was working where I had ready
access to a device programmer that did the job. Later, I had a job that
absolutely mandated I have a "universal" programmer of my own, so I bought
one, and later a second, and this stuff hasn't been an issue for me since
then.
>
> > > > > Old sailing ships used a lot of man-power. While OIL is cheap wind
> > > > > powered modern ships will not be developed.
> > > > >
> > > > Some guys are doing it. The Americas Cup bears witness to that
doesn't
> > it?
> > >
> > > Yes, and by analogy some people are still designing with TTL.
> > >
> > Not for serious work, though. TTL's too slow, uses WAY too much power,
and
>
> Will you please forget the 'serious work'. Will you please accept that
> there are people who design and build electronic circuits for fun. This
> appears to be an alien concept for you.
>
I'll do that when you quit suggesting that the entire industry and its
nomenclature are wrong just because it doesn't suit the dabblers in obsolete
hardware. Things change over time because they are adapted to the needs of
those who use them, and that includes the nomenclature. That applies to the
majority who work in the industry, of which, you, Tony, are clearly not one.
You, and everyone else, certainly have the right to call things whatever you
want. but you should have noticed, by now, that this occasionally leads to
semantic difficulties.
>
> > requires too much board space. While some advances in ship design have
come
> > from the countless millions spent by the yacht-racing community, I doubt
> > anything worthwhile to the electronics industry will come from taking old
>
> Actually, I can see one way that there could be a benefit from using TTL....
>
> The current advances in processor speed have come largely from just
> increasing the clock rate. There haven't been any major changes in CPU
> design to use those clock cylces more efficiently....
>
That's only a small part of the acceleration. The use of multiple piplelines
accounts for much of the performance increase along with increased datapath
width, and other little features. The gradual increase in interest in
parallelism is also going to help quite a bit, so we'll be seeing even more
pipelines in the future.
>
> But somebody stuck with old, slow, TTL, just might hit on some way to get
> more performance out of it (because it's all they've got, and they need
> the performnce). The trick they discover just might also be useful to
> speed up ASICs (or FPGAs, or ...)
>
And just exactly HOW would they extract more performance from it? A new
architecture would require new software, both in development tools and in OS
and as applications. Just verifying that their innovation would take several
hundred lifetimes, and the generation of a full set of software would take
that one individual working alone, until well after the next big-bang.
>
> That's a lot of 'maybes', sure. And I don't think it's likely. But I also
> don't think it's impossible...
>
It's highly unlikely, simply because it's WAY too much work to twiddle the
hard-wiring and WAY too slow to use TTL, and uses WAY too much power so folks
doing serious development, even at the amateur level, use simulators to
evaluate performance of new architectures, and programmable hardware to verify
their findings.
>
That's not to say a person's WRONG in fiddling with discrete logic. It's just
not terribly likely to be of much use. Like masturbation, it's unlikely to
hurt anyone and produces momentary amusement.
>
> > > > One of my friends is building a sailboat in one of his vacant
buildings.
> > He's
> > > > been talking about pouring the keel any day now. I want to see that!
He
> > says
> > > > he wants to sail it around the world. I hope he makes it.
> > >
> > It is a mental masturbation project, though. There's no hope that it will
>
> And that's _exactly_ what building TTL circuits is for some of us. Now
> will you please try to understand this!
>
I've got no problem with that. I do, however, disagree that the industry
nomenclature is misapplied because it COULD or even SHOULD have been used
differently.
I do things that accomplish little more than amuse me for a few weekend
afternoons. I don't pretend that they're going to produce anything, though.
My interest in S-100-based microcomputers certainly hasn't done anything
useful since the day I started using PC's. I haven't simply chucked the S-100
hardware on account of that, however.
Received on Sun Apr 14 2002 - 21:45:30 BST