I bought a Xeltek UniPro back in '89. It was a nightmare, and when XELTEK
came out with their SuperPro, they sent me one gratis for all the debugging
I'd done for them on the UniPro. Now, they've discontinued the SUperPro II,
but all the algorithms that work on that model seem to work fine on the
orignal. I think the only difference is that the "II" uses the parallel port
rather than a dedicated card.
Likewise, I have another similar fit-in-the-briefcase type that uses a card in
the PC. It also was maintained at no charge for over a decade. The software
now avaiable, still free, doesn't support this model any longer. <sigh> It's
a good thing ISP parts are taking over the market.
more below ...
Dick
----- Original Message -----
From: "Tony Duell" <ard_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Tuesday, April 16, 2002 6:54 PM
Subject: Re: TTL computing
> >
> > Programmers have been a problem for us, the users, as well as for the PLD
>
> It's a major problem for this user... I really can't keep on updating the
> programmer (or the non-free software to drive it) every few weeks.
>
> As I said, I built the Elektor GAL programmer. A few months after the
> article was publisehd, the GALs it could program were discontinued. There
> was an update (an add-on board and more software) which I built. But now
> the chips that programmer can program are hard to find. I've got a few in
> stock, but I don't like designing round parts that are as hard to find as
> that.
>
> And before you tell me that most TTL parts are also discontinued, yes, I
> know that. But they're also not hard to find.
>
> > Some of the vendors of programmable logic do publish the algorithms for
their
> > ISP programming tools, which you can then implement in your own
>
> I think most manufacturers do publish the actual way to get the bits into
> the chip for ISP chips (particularly RAM-based ones that lose the
> configuration on power-down),
>
> > hardware/software combination. Unfortunately, I've seen no spec's on how
to
> > develop the configuration of the hardware.
>
> No, you're forced to use the manufacturers tools, which are either
> expensive, don't run on the machine I have, or are hard to use (or
> sometimes all 3).
>
> > > The whole point is, that before there were PALs, then all programmers
> > > were PROM (or EPROM) only. But AFAIK no early PALs could be programmed
in
> > > such programmers, you had to buy/build a new one.
> > >
> > EPROMS, for some reason, didn't have these limitations. Programming was
> > simple and the spec's were in many of the databooks.
>
> That's one reason that I think the 'impossible to support' reason for not
> releasing the PLD programming spec is bogus. It shouldn't be any more of
> a problem than releasing the EPROM programming spec.
>
> > > Learn to read, please. I am not disputing it was documented (I have the
> > > original MMI PAL databook and it's in there). I am disputing it's the
> > > same as selected a bit in a normal bipolar PROM.
> > >
> > Which book would that be?
>
> It's something like the 1984 MMI databook.
>
> > >
> > Does it surprise you that the access mode to the fuse array is different?
>
> Not really. It would have been a lot more work to add the logic to turn
> the fuse array into a PROM-like structure just for programming it, I guess.
>
> > > The process of programming a fuse in a bipolar PROM and in a PAL is much
> > > the same. Similary the process of programming a flash cell in a
> > > microcontroller, a flash PROM and a GAL are also much the same as each
> > > other. And yet most (but not all, agreed) microcontroller, flash PROM
and
> > > EPROM manufacturers do document their programming algorithms, but few,
if
> > > any, of the PLD manufacturers do. Why are PLDs the only devices that
> > > cause support problems.
> > >
> > Believe me, I've got no idea, but that business of "support headaches"
comes
> > up every time I broach the subject with the factory applications guys.
They
> > probably feel they've got to protect their technology. One of the
"universal"
>
> Yes, that's more like it. The reason 'support headaches' would appear to
> be bogys. But if they documented the programming specs of their device
> then anyone could figure out how it really worked. Which they may not
want...
>
> > > And to claim that microcode is not a special case of a state machine is
> > > plain wrong!
> > >
> > They'll listen to you when you become part of a market that uses 100K
pieces
>
> I am not interested in people 'listening'. But I will still stick to my
> claim that there's no reasonable definition of 'state machine' that
> excludes the microcode + sequencer.
>
> > > Are you incapable of believing that the multiple pipelines you just
> > > mentioned could not have been built in TTL. Of course they could. OK,
> > > they'd not be as fast as an FPGA or ASIC implementation, but so what.
> > > They would be faster than a traditional processor built in TTL. And that
> > > would be enough to prove that the design worked, and that this was a way
> > > of speeding up other processors.
> > >
> > They WERE built in TTL, back when TTL was the relevant technology and they
had
>
> Fine. So presumably any otehr processor developments _could be built with
> TTL.
>
> > no better options. Even back then, it was more sensible to simulate the
new
> > architecture to see whether it really offered the enhancement it seemed to
>
> Having had so many problems with so-called simulators, I quickly learnt
> that for anyting even mildly unusual, it was quicker to just build the
> darn thing and see what it did.
>
> > > Never underestimate what hobbyists can do. FWIW, plenty of hobbyists
have
> > > designed their own processors and produced at least a monitor program
for
> > > them. And it doesn't take that long.
> > >
> > So what? Every EE student has had to do that in order to get his
sheepskin.
>
> Actually, over here it's very rare to find an EE who's designed a
> processor :-(
>
I didn't say a hobbyis couldn't make any advances. I did say a hobbyist
wasn't likely to make any advances using TTL.
>
> Anyway, you were the one claiming that it was impossible for a hobbyist
> to make any advances. I dispute this. There's no reason at all to believe
> that a serious hobbyist could not come up with a totally new
> architecture, build it (using TTL, FPGAs, or whatever _he_ chooses) and
> write enough software to prove it works and can be useful.
>
> > > Also the power consumption is hardly a problem either. My old 11/45 has
a
> > > 250W PSU for the CPU boards (only). Many PC power supplies can now
exceed
> > > that. 2 or 3 PSUs taken from old PCs will power any TTL-based processor
> > > you're likely to build.
> > >
> > a 9-volt battery is probably capable of powering any CPU I'd be likely to
> > build.
>
> So? Provided we each have a 5V supply capable of supplying the current we
> each need, that's all that matters!
>
Power is a concern. If it's possible to do something with 50 mW, it should be
criminalized to do the same thing with 5 kW.
>
> > >
> > > > doing serious development, even at the amateur level, use simulators
to
> > >
> > > I will use a simulator when somebody makes one that I can trust. Meaning
> > > that it passes all of my little test circuits. Since that's not happened
> > > yet, I don't feel I can trust the results of the simulator.
> > >
> > Well, the industry has relied on them since back when I was in college.
If
> > you don't trust someone else's work, proven over two or three decades of
>
> I've had so many problems caused by trusting others (not just simulators,
> all sorts of things), that I have learnt _never_ to trust anyone if my
> life or reputation depends on it. Check first. Check again.
>
> > constant use by hundreds of thousands of engineers, write one that's
better.
>
> Why bother? It's quicker to just buld the circuit, and at least a
> physical circuit has some relation to the real world.
>
Well, if you think it's easier to build a circuit with 800-1000 components on
the off-chance that you've done everything right, then I congratulate you. I
prefer to use the belt-and-suspenders approach and verify with all the tools
at my disposal.
>
> > >
> > > Even then, there's no reason to believe the traces from the simulator
> > > have any relation to reality unless you've actually verified them
against
> > > a logic analyser.
> > >
> > So do that! I do it from time to time.
>
> It's darn hard to probe the output of an internal logic block on an FPGA
> or a CPLD. Yes you can route internal nodes out to pins (I've done that
> often enough), but if you're not careful, that will change the timing of
> internal signals (as they're all rerouted) and willpossibly remove the
> glitch you're actually looking for.
>
That should be no problem for you, since you don't use those devices, as they
require software you decline to use.
>
> (Oh, and the FPGA simulator I attempted to use was useless for finding
> glitches. It didn't find them where the did exist. It did find them where
> they couldn't exist (like on the outputs of D-types, well away from clock
> edges).
>
> > > Incidentally, a board I am designing at the moment contains a
> > > microcontroller, an 8 bit latch, a 3 to 8 decoder (for which a '138 is
> > > _perfect_ with just the right enables), a 2 input AND, a 2 input NAND
and
> > > an inverter. Will you please tell me why a PLD is superior to a single
> > > 74x00 for those last 3 gates?
> > >
> > It probably isn't, but you could, of course, reduce the entire
combinatorial
> > circuit to a small PLD, but I don't know the details.
>
> It wouldn't help much (and would make the PCB more difficult to route --
> c.f. the earlier comments on those single-gate chips).
>
One could probably use a Xilinx 9536 to replace all the logic, including the
latch. In fact, you could just roll the microcontroller into the programmable
logic, but not with a $5 CPLD. Cygnal is pushing a line of 805x types that
live as hard logic in an FPGA. ATMEL is doing similar stuff as are several
other vendors. Most of these run fast enough to be interesting.
Received on Wed Apr 17 2002 - 01:08:42 BST