The current version of the "design expert" software from Lattice, which acquired
the PLD business form AMD, which, decades ago, acquired MMI, which made these
parts, probably, is freeware, and is quite capable of translating any set of
logic equiations into a jedec file suitable for programming a 16V8, which is an
adequate substitute for and superset of any of the 16Lx and 16Rx parts of
yesteryear. It will reduce the equations, though I have doubts about taking
truth table input. Of course, ATMEL distributes a free verison of ABEL that may
well take truth table input and produce a JEDEC file, which the LATTICE software
will then disassemble into something it can decipher into a 16V8.
Where there's a will, there's mourners ...
Dick
----- Original Message -----
From: "Tony Duell" <ard_at_p850ug1.demon.co.uk>
To: <classiccmp_at_classiccmp.org>
Sent: Thursday, November 22, 2001 1:17 PM
Subject: Re: I'm guessing you have solved this problem...
> > > > Just how fast do these devices have to be, and how deep are they? I've
got
> > some
> > >
> > > 10's of ns at worst. And typically 256*4 bits or so.
> > >
> > So those would be 82S129's or the like? There are some such devices that
still
>
> That sort of thing, yes...
>
> > show up in popular surplus supplies.
>
> Exactly. Of course you want to be sure that any you buy surplus have
> never been programmed. There is no way to erase these devices. Ditto for
> PALs, of course.
>
> > > Well, if you want to take a dump of the PROM, work out the logic
> > > equations from it, then fit them into a PAL, and get it working, good
> > > luck :-)
> > >
> > The PROM is listed as a truth-table, right? The only ABEL version I used
simply
>
> Basically, yes. It's a bitwise dump of the PROM, not always formatted in
> the obvious way (the microcode PROMs have the dump displayed as the
> values in particular fields, which may be 1 bit long, 2 bits long, 3 bits
> long, etc). You'd have to turn that into a pure binary dump.
>
> > took a truth table as input. That wouldn't take much processing. >
>
> If the logic will fit into a PAL and if you have suitable software.
>
> > > Yes, some PROMs were used as logic functions rather than (say) microcode
> > > store. But it's not that easy to replace them with PALs (it's possible in
> > > some cases to fit the logic into a small-ish PAL). It's a lot easier to
> > > use a PROM/EPROM device.
> > >
> > If one doesn't have a suitable bit of software, that Quine-McLuskey (?)
method
>
> Which is, of course, how most PAL compilers do logic optimisation.
>
> > that I learned about in college some 30+ years back (and promptly forgot)
can be
> > automated easily enough to produce reduced equations. Reducing the prom
listing
> > to a set of equations by isolating each bit in the output word and OR'ing
the
> > locations at which those bits are true is one reasonably way to do the job.
I
> > know of no PAL generation software that doesn't automatically reduce the
> > equations for you.
>
> Some of the free stuff doesn't. I have a freeware (I think, it came from
> National Semiconductors via Elektor as part of the software for their GAL
> programmer project) GAL compiler that does no optimistations at all. It's
> simple-minded, but at least it never does something that you don't expect!
>
> >
> > PROMs are programmable-OR-fixed-AND devices, while PALs are programmable
> > AND-fixed-OR devices. The process of generating them is, therefore
different,
>
> Of course...
>
> > for a given logic function, but, expanded and re-reduced, the result should
be
> > the same. Of course a registered PROM is needed to produced registered
outputs.
>
> Yes, but we are replacing PROMs with PALs, not the reverse. There are
> registers PROMs (82S114 and 82S115 spring to mind), but they weren't used
> in the 11/45 CPU. In any case, registered PALs are easy enough to find.
>
> > I'd say a 16L8 would do for most PROM-based applications. A 16L8 is capable
of
> > generating any logic function of 16 inputs. A 256x4 or 32x8 PROM has less
logic
>
> Absolute rubbish. There are plenty of 16 input, 1 output, functions that
> will not fit into a 16L8. The obvious way to see that is that to specify
> an arbitrary 16 input function takes 64K bits (there are 2^16 lines in
> the truth table, you need one bit to specify the output for each one).
> The programming data for a 16L8 is much less than 64K bits (I seem to
> remember it's around 3K). Therefore there are functions you can't stick
> into the 16L8.
>
> As a trivial example, suppose have 16 inputs (allowing 2 outputs). And
> that we're already using one of the outputs for a function we can fit.
> Then the following function will not fit in a 16L8 AFAIK :
>
> Output = (I0 + I1 + I2 + I3 + I4 + I5 + I6 + I7 + I8 + I9 + I10 + I11 + I12)/
>
> The final / is there because the OR matrix in a 16L8 is really a NOR
> matrix. That expression needs 13 inputs to the OR matrix, IIRC there are
> something like 7 or 8. Demorgan doesn't help because you can't invert the
> whole exprrssion in a 16L8. Even with a 16V8, where you can invert the
> whole thing and turn it into an AND expression that will fit, it's not
> hard to think up expressions that can't be simplified into < 8 terms ORed
> together.
>
> Expressions with multiple XOR terms are notoriously difficult to fit into
> most PALs. You run out of OR terms very quickly. There were some special
> PALs (16X4?) with XOR gates in them to get round this problem, but they
> are not common, they're hard to find blanks for now, and most GALs can't
> be configured to replace them.
>
>
> > than that in it.
>
>
> Not so. A 256*4 PROM effectively has some 256 input OR gates in it. These
> do not exist in PALs.
>
> -tony
>
>
Received on Thu Nov 22 2001 - 19:57:32 GMT