30 Sep
2014
30 Sep
'14
3:40 p.m.
The early 20/24 pin PALs had a security fuse to prevent unauthorized
duplication. I worked at Data I/O, the device programmer company, in the
1980s and figured out a way to determine the contents. I did a few
experiments to prove the concept but never created a complete package.
PAL programmers like the Data I/O LogicPak could apply test vectors to a PAL
and check the output state of each pin. For a purely combinatorial device
like a PAL16H8 you just need to apply all possible inputs and read the
outputs. This will create a large truth table in inputs and outputs that can
be minimized with PLD software like ABEL.
Registered devices like PAL 16R8 require the bank of registers to cycle
through all starting points with all inputs. Most of these devices supported
pre-load, the programmer could force the internal registers to a known
state. You could force a desired register state and inputs then apply the
clock. These early registered PALs had a tri-state output buffer controlled
by a dedicated pin so you could always read the register output. Later parts
had the output buffer controlled by an internal logic function.
I am sure that by now someone has developed a high speed tester that applies
every combination of inputs then minimized the output to generate a
programming file.
I have copies of the early DOS based ABEL software; it runs in a DOS box on
Windows 98. I believe that Xilinx now owns the copyright. I have donated
copies of the software and source code to the Computer History Museum.
Michael Holley
30 Sep
30 Sep
3:59 p.m.
Ah, ABEL! They were still teaching it at U-M EECS ca. 2004-2005 in the
introductory digital design course. We must have been one of the last
groups of students to use it. I found it always very easy to work with,
sort of the BASIC of HDLs. Does anything still support it? IIRC ABEL was
removed from Xilinx ISE some time ago.
Interesting post.
Best,
Sean
On Tue, Sep 30, 2014 at 6:40 PM, Michael Holley <swtpc6800 at comcast.net>
wrote:
The early 20/24 pin PALs had a security fuse to
prevent unauthorized
duplication. I worked at Data I/O, the device programmer company, in the
1980s and figured out a way to determine the contents. I did a few
experiments to prove the concept but never created a complete package.
PAL programmers like the Data I/O LogicPak could apply test vectors to a
PAL
and check the output state of each pin. For a purely combinatorial device
like a PAL16H8 you just need to apply all possible inputs and read the
outputs. This will create a large truth table in inputs and outputs that
can
be minimized with PLD software like ABEL.
Registered devices like PAL 16R8 require the bank of registers to cycle
through all starting points with all inputs. Most of these devices
supported
pre-load, the programmer could force the internal registers to a known
state. You could force a desired register state and inputs then apply the
clock. These early registered PALs had a tri-state output buffer controlled
by a dedicated pin so you could always read the register output. Later
parts
had the output buffer controlled by an internal logic function.
I am sure that by now someone has developed a high speed tester that
applies
every combination of inputs then minimized the output to generate a
programming file.
I have copies of the early DOS based ABEL software; it runs in a DOS box on
Windows 98. I believe that Xilinx now owns the copyright. I have donated
copies of the software and source code to the Computer History Museum.
Michael Holley
4:47 p.m.
I have read the pure logic PALs (without registers) by connecting the
address lines from an eprom programmer to the inputs and the data lines to
the outputs. Then read it like an EPROM. From that you can reduce the
logic but that gives you all outputs for all possible input combinations.
-----Original Message-----
From: Sean Caron
Sent: Tuesday, September 30, 2014 3:59 PM
To: General Discussion: On-Topic and Off-Topic Posts ; Sean Caron
Subject: Re: Reading contents of PALS like the 16L8 or 16R8
Ah, ABEL! They were still teaching it at U-M EECS ca. 2004-2005 in the
introductory digital design course. We must have been one of the last
groups of students to use it. I found it always very easy to work with,
sort of the BASIC of HDLs. Does anything still support it? IIRC ABEL was
removed from Xilinx ISE some time ago.
Interesting post.
Best,
Sean
On Tue, Sep 30, 2014 at 6:40 PM, Michael Holley <swtpc6800 at comcast.net>
wrote:
The early 20/24 pin PALs had a security fuse to
prevent unauthorized
duplication. I worked at Data I/O, the device programmer company, in the
1980s and figured out a way to determine the contents. I did a few
experiments to prove the concept but never created a complete package.
PAL programmers like the Data I/O LogicPak could apply test vectors to a
PAL
and check the output state of each pin. For a purely combinatorial device
like a PAL16H8 you just need to apply all possible inputs and read the
outputs. This will create a large truth table in inputs and outputs that
can
be minimized with PLD software like ABEL.
Registered devices like PAL 16R8 require the bank of registers to cycle
through all starting points with all inputs. Most of these devices
supported
pre-load, the programmer could force the internal registers to a known
state. You could force a desired register state and inputs then apply the
clock. These early registered PALs had a tri-state output buffer
controlled
by a dedicated pin so you could always read the register output. Later
parts
had the output buffer controlled by an internal logic function.
I am sure that by now someone has developed a high speed tester that
applies
every combination of inputs then minimized the output to generate a
programming file.
I have copies of the early DOS based ABEL software; it runs in a DOS box
on
Windows 98. I believe that Xilinx now owns the copyright. I have donated
copies of the software and source code to the Computer History Museum.
Michael Holley
6:01 p.m.
David Cooper wrote:
I have read the pure logic PALs (without registers) by connecting the
address lines from an eprom programmer to the inputs and the data lines to
the outputs. Then read it like an EPROM. From that you can reduce the
logic but that gives you all outputs for all possible input combinations.
That doesn't work if there is a latch programmed into the PAL. The
original PC AT, for example, had two PALs (both 16L8, I think, but it
has been a loooong time). The address decoding one could be read just
fine by the method you indicated but the FPU interface one implemented a
latch on one of its outputs. That stumped cloners in Brazil for nearly
three years (in general - my friends at Softec got it in half an hour.
They were good. And I helped a little)..
-- Jecel
5:19 p.m.
ABEL was released in April 1984 and Xilinx stopped shipping it around 2008.
http://www.xilinx.com/support/answers/2951.htm
Michael
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org] On Behalf
Of Sean Caron
Sent: Tuesday, September 30, 2014 3:59 PM
To: General Discussion: On-Topic and Off-Topic Posts; Sean Caron
Subject: Re: Reading contents of PALS like the 16L8 or 16R8
Ah, ABEL! They were still teaching it at U-M EECS ca. 2004-2005 in the introductory
digital design course. We must have been one of the last groups of students to use it. I
found it always very easy to work with, sort of the BASIC of HDLs. Does anything still
support it? IIRC ABEL was removed from Xilinx ISE some time ago.
Interesting post.
Best,
Sean
4:42 p.m.
On 09/30/2014 03:40 PM, Michael Holley wrote:
I have copies of the early DOS based ABEL software; it
runs in a DOS box on
Windows 98. I believe that Xilinx now owns the copyright. I have donated
copies of the software and source code to the Computer History Museum.
Michael, many have done this. Heck, I even did it myself a few years ago:
http://www.vintage-computer.com/vcforum/entry.php?315-Cloning-a-PAL-HAL-%28…
And it was *crude*--just some counters and a mux run by a PC parallel
port--74LS SSI hellbox parts thrown together on a piece of prototyping
board.
I've seen MCU projects that attempt to do likewise.
--Chuck
1 Oct
1 Oct
5:35 a.m.
On Tue, 30 Sep 2014, Michael Holley wrote:
I have copies of the early DOS based ABEL software; it
runs in a DOS box on
Windows 98. I believe that Xilinx now owns the copyright. I have donated
copies of the software and source code to the Computer History Museum.
This is really cool, but will it be available to people? I don't know
about the CHM policies on this kind of thing, but if they're like most
museums, they're essentially a Roach Motel. Things go in and NEVER come
out again. If this is the case, would you consider uploading the
materials to the Internet Archive?
tnx!
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
10:50 a.m.
On 10/1/14 5:35 AM, geneb wrote:
if they're like most museums, they're
essentially a Roach Motel. Things go in
and NEVER come out again.
http://www.computerhistory.org/_static/atchm/early-digital-research-cpm-sou…
You're welcome.
Don't drink the Duell kool-aid
11 a.m.
On Wed, 1 Oct 2014, Al Kossow wrote:
On 10/1/14 5:35 AM, geneb wrote:
Excellent.
if they're like most museums, they're
essentially a Roach Motel. Things go
in
and NEVER come out again.
http://www.computerhistory.org/_static/atchm/early-digital-research-cpm-sou…
You're welcome.
Don't be a dick about it Al. It gets old really quick.
Don't drink the Duell kool-aid
Eh?
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
1:25 p.m.
Don't
drink the Duell kool-aid
Eh?
2:14 p.m.
On Wed, 1 Oct 2014, Tony Duell wrote:
Presuambly referign to my comments that museums _that I have attmpted to
deal with in the UK_ arre close to being black hoels for information.
Now that's unfortunate.
Don't drink the Duell kool-aid
Eh? In another of my interestes, the US group has put all
their applicable
documentaion on the web for free downlaodd by anyone. In the UK, the
copyrigth owner has issisted that (a) You ahve to be a member of the UK
group (thiois does not bother me), (b) a dowload limit of 10 documents
_per week_ (and foten each page of a scheamtic it a separate docuement)
and (c) the docuemants are heavily 'watermarked' often so that conenctor
pin nuumbers or component values cannot be read. Oh well...
Yeah, I'd be uploading that stuff to the IA as fast as I could download
it. :)
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
3:16 p.m.
Tony,
Whilst I have some issues with www.mosi.org.uk the access to the Documents
and artefacts held on site but not on display is pretty good.
http://www.mosi.org.uk/collections.aspx
you can even arrange to loan items for talks and presentations :-
http://www.mosi.org.uk/collections/using-the-collections/loans-from-the-coll
ection.aspx
When I spoke to the Head of Collections he said it would be good if more
people came in because that helps to justify the service.
Dave
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of Tony Duell
Sent: 01 October 2014 21:26
To: cctalk at classiccmp.org
Subject: Re: Reading contents of PALS like the 16L8 or 16R8
Presuambly referign to my comments that museums _that I have attmpted
to deal with in the UK_ arre close to being black hoels for information.
Museums overhere seem to take copyright a lot more seriously than those in
the States and will not make software/manuals avaialble. Nor wil lthey
alow
Don't
drink the Duell kool-aid
Eh? J-Random-Public to look at said manuals
In another of my interestes, the US group has put all their applicable
documentaion on the web for free downlaodd by anyone. In the UK, the
copyrigth owner has issisted that (a) You ahve to be a member of the UK
group (thiois does not bother me), (b) a dowload limit of 10 documents
_per
week_ (and foten each page of a scheamtic it a
separate docuement) and (c)
the docuemants are heavily 'watermarked' often so that conenctor pin
nuumbers or component values cannot be read. Oh well...
-tony
11 a.m.
On Oct 1, 2014, at 8:35 AM, geneb <geneb at deltasoft.com> wrote:
On Tue, 30 Sep 2014, Michael Holley wrote:
Um, Al is generally pretty good at making sure things see the light of day
(and/or a nice fat pipe). There's this thing called "Bitsavers", you
see...
- Dave
I have copies of the early DOS based ABEL
software; it runs in a DOS box on
Windows 98. I believe that Xilinx now owns the copyright. I have donated
copies of the software and source code to the Computer History Museum.
This is really cool, but will it be available to people? I don't know about
the CHM policies on this kind of thing, but if they're like most museums, they're
essentially a Roach Motel. Things go in and NEVER come out again. If this is the case,
would you consider uploading the materials to the Internet Archive?
12:21 p.m.
On Wed, 1 Oct 2014, David Riley wrote:
On Oct 1, 2014, at 8:35 AM, geneb <geneb at
deltasoft.com> wrote:
I wasn't making the assumption that just because CHM got something,
bitsavers got it as well. It's nice to see that is apparently how it
works.
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
On Tue, 30 Sep 2014, Michael Holley wrote:
Um, Al is generally pretty good at making sure things see the light of day
(and/or a nice fat pipe). There's this thing called "Bitsavers", you
see...
I have copies of the early DOS based ABEL
software; it runs in a DOS box on
Windows 98. I believe that Xilinx now owns the copyright. I have donated
copies of the software and source code to the Computer History Museum.
This is really cool, but will it be available to people? I don't know about
the CHM policies on this kind of thing, but if they're like most museums, they're
essentially a Roach Motel. Things go in and NEVER come out again. If this is the case,
would you consider uploading the materials to the Internet Archive?
12:52 p.m.
The early 20/24 pin PALs had a security fuse to prevent unauthorized
duplication. I worked at Data I/O, the device programmer company, in the
1980s and figured out a way to determine the contents. I did a few
experiments to prove the concept but never created a complete package.
PAL programmers like the Data I/O LogicPak could apply test vectors to a PAL
and check the output state of each pin. For a purely combinatorial device
like a PAL16H8 you just need to apply all possible inputs and read the
outputs. This will create a large truth table in inputs and outputs that can
be minimized with PLD software like ABEL.
Registered devices like PAL 16R8 require the bank of registers to cycle
through all starting points with all inputs. Most of these devices supported
pre-load, the programmer could force the internal registers to a known
state. You could force a desired register state and inputs then apply the
clock. These early registered PALs had a tri-state output buffer controlled
by a dedicated pin so you could always read the register output. Later parts
had the output buffer controlled by an internal logic function.
The problem comes when you have a 16H8 or 16L8 which contains sequential
logic (the feedback terms allow this). AFAIK there is no 'preload'
funciton for these devices, so you can't force all the inputs to the
logic array.
-tony
2:10 p.m.
On 10/01/2014 12:52 PM, Tony Duell wrote:
The problem comes when you have a 16H8 or 16L8 which
contains sequential
logic (the feedback terms allow this). AFAIK there is no 'preload'
funciton for these devices, so you can't force all the inputs to the
logic array.
Exactly--the idea is that these clocked devices can (and usually do)
have a memory. On a simple unclocked combinatorial PLD, you can safely
say that for any input or combination of inputs, there is a given
output. Repeat the input values as many times as you want, it always
comes out the same way.
With a PLD with a latch in it, a given output state can not only depend
on the input state, but also any state "memorized" by the device--and
there can be many of those, each dependent on any previous state and the
current set of inputs. All of the sudden, "exhaustive" begins taking
on an exponential character.
One problem that I ran into early on was determining which lines were
inputs and which were outputs, as well as which were tri-state and under
what conditions. Certain lines are always inputs and certain lines are
always outputs, so that gives a starting point.
By feeding lines through resistors and "pushing" those (with logic 1's
and 0's) and observing the behavior of the pins to see which lines were
always high-impedance for all input values and which lines were
high-impedance only for certain sets of inputs, it's possible to make a
determination. This does complicate the process somewhat, but not
tremendously. Obviously, it helps if you know what's connected to the
PAL, but that's not always the case.
--Chuck
12:56 p.m.
Somethign that I forgoet to mention. The truth table, even for a
combinatorial device, might not let you recreate the original fuse map.
The reason is that it was not uncommon to program additional terms which
apperar to be redundant, but which actually prevent glitches when the
inputs chang (if you think fo the karnaugh map, the 'extra terms' link
adjacent regions together, preventing the possible glitch when you hop
from one region to another).
Missing those out is nasty. You end up with a PAL that works on paper
(and which tests right at low speeds), but which can cause the circuit to
fail in 'intereting' ways.
-tony
2:54 p.m.
On 10/1/2014 1:56 PM, Tony Duell wrote:
Somethign that I forgoet to mention. The truth table,
even for a
combinatorial device, might not let you recreate the original fuse map.
The reason is that it was not uncommon to program additional terms which
apperar to be redundant, but which actually prevent glitches when the
inputs chang (if you think fo the karnaugh map, the 'extra terms' link
adjacent regions together, preventing the possible glitch when you hop
from one region to another).
Missing those out is nasty. You end up with a PAL that works on paper
(and which tests right at low speeds), but which can cause the circuit to
fail in 'intereting' ways.
That was covered in the PAL BOOKS.
Q.D = Q & Din
+ Strobe & Din
+ !Strobe & Q
-tony
Ben.
3506
days inactive
3507
days old
17 comments
11 participants
participants (11)
-
aek＠bitsavers.org -
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
dave.g4ugm＠gmail.com -
fraveydank＠gmail.com -
geneb＠deltasoft.com -
jecel＠merlintec.com -
scaron＠umich.edu -
swtpc6800＠comcast.net -
trs80＠marmotking.com