25 Jun
2006
25 Jun
'06
5:56 p.m.
what's the most sensible format for backing up PAL chips such that they can be
recreated on a different system to that which they were backed up on?
My standalone EPROM/PAL unit seems to understand the following data formats:
ASCII
binary
motorola s rec
intel std & 8086
elan fuse map
jedec
mos tech
texas tags
tex hex
... some of which are presumably EPROM-only formats (I don't have a manual for
the programmer)
is there some sort of common format/size for PALs too when reading (akin to
always being able to read a 27128 EPROM as a 16KB device regardless of who
actually manufactured it)? I'm concerned that this programmer might be too
old to have data on some of the PAL chips that I want to archive - but if I'm
only interested in archiving them (and so can set the type to something of the
right 'geometry' from a different manufacturer) that's not necessarily that
big a deal.
Advice appreicated :) I'm used to working with EPROMs, but PALs are a total
unknown to me!
cheers
Jules
25 Jun
25 Jun
5:18 p.m.
Jules Richardson wrote:
what's the most sensible format for backing up PAL chips such that
they can be recreated on a different system to that which they were
backed up on?
My standalone EPROM/PAL unit seems to understand the following data
formats:
ASCII
binary
maybe
motorola s rec
usually output from assembler, seldom from palasm or others
intel std & 8086
output from intel targeted tools, doubtful
elan fuse map
jedec
both jdec and fusemaps are likely to be of most use.
mos tech
texas tags
tex hex
Note that with pals, it was actually not just enough to get the fuse
map into the part. once you had that in and perhaps locked, then
you would have no way from the fuse map to infer what the part
should do to indicate the fuse map was going to have a chance
to work. so the palasm had a modeling phase (pardon me if I
use the wrong term, it's been a long time since I did any pal
work), that allowed you to put in various inputs and see that
the part responded correctly.
this was not only useful for the engineer to test the device
that their equations functioned correctly, but that the process
of putting in the fuse map at production time had not damaged
the device.
You wont be able to do anything but copy the fuse map,
which hopefully will allow you to reprogram devices of the
same type.
While you have possible access to a functional device, or
perhaps schematics and the like you might want to be sure
you decompile the pals back to equations so that you could
use an equivalent in a future design.
this is rare to be able to do, but just a thought.
jim
6:53 p.m.
> what's the most sensible format for backing
up PAL chips such that
> they can be recreated on a different system to that which they were
> backed up on?
[...]
jedec
both jdec and fusemaps are likely to be of most use. While you have possible access to a functional device,
or
perhaps schematics and the like you might want to be sure
you decompile the pals back to equations so that you could
use an equivalent in a future design.
It is _very_ easy (given the data sheet on the PAL) to turn a fuse map or
jedec file (which contain the same information) back into the equations.
Of course you won't be able to give the right names to the signals, but
you can produce equations.
Basically, a PAL is a programmable AND matrix followed by a fixed OR
matrix. A (fictional?, but it's close to the 10L8) example might have 10
input pins and 8 output pins. Each output is the logical NOR (OR followed
by inverter) of 8 internal 'product terms'. Each product term is the
logical AND of some of the inputs and their inverses, that 'some' is what
you select when you program the PAL.
There are 2 'fuses' (progammable bits, originally, they really were fuses
that you burnt when you programmed the PAL) associated with each
input/product term combination (so in this example, since we have 10
inputs, and a total of 64 product terms (8 for each of 8 outputs), there
are a total of 64*2*10 = 1280 fuses). The 4 combinations of the fuses
select the following 4 possibilities :
That input is not used in that product term
That input is ANDed into that product term
That input is inverted and ANDed into that product term
That product term is forced to 0 (basically, the input and its inverse
are ANDed into the product term).
So, given the fuse map, you can easily recreate the product terms. Since
you know the fixed part of the chip (The OR matrix, inverters, etc), you
can recreate the equations, albeit in a non-minimised form.
At least free [1] version of PALASM came with a program to do this,
called JED2EQN IIRC. It was supposed to accept a file giving the signal
names for the pins which it would then substitute into the equations, I
could never get this to work. I used to feed the output through sed(1)....
[1] That's free as in beer, alas. It didn't cost anything, but was an
MS-DOS executable only.
-tony
26 Jun
26 Jun
7:21 a.m.
I use a program called jed2ahdl.exe to convert fuse maps ( jedec files) to
equations. It works well and I have used it for years. There is one other
that I use called Opal Jr. If anyone is in need of converting jedecs
contact me offline.
Hutch
ard at p850ug1.demon.co.uk (Tony Duell)
Sent by: cctech-bounces at classiccmp.org
06/25/2006 06:53 PM
Please respond to
"General Discussion: On-Topic Posts Only" <cctech at classiccmp.org>
To
cctalk at classiccmp.org
cc
Subject
Re: backing up PAL chips
The jedec format is the normal one for PALs/GALs. Any reasonable PAL
programmer would be able to make use of that (provided, of course, your
programmer outputs a standard jedec file :-))
> what's the most sensible format for backing
up PAL chips such that
> they can be recreated on a different system to that which they were
> backed up on?
[...]
jedec
both jdec and fusemaps are likely to be of most use. While you have possible access to a functional device,
or
perhaps schematics and the like you might want to be sure
you decompile the pals back to equations so that you could
use an equivalent in a future design.
It is _very_ easy (given the data sheet on the PAL) to turn a fuse map or
jedec file (which contain the same information) back into the equations.
Of course you won't be able to give the right names to the signals, but
you can produce equations.
Basically, a PAL is a programmable AND matrix followed by a fixed OR
matrix. A (fictional?, but it's close to the 10L8) example might have 10
input pins and 8 output pins. Each output is the logical NOR (OR followed
by inverter) of 8 internal 'product terms'. Each product term is the
logical AND of some of the inputs and their inverses, that 'some' is what
you select when you program the PAL.
There are 2 'fuses' (progammable bits, originally, they really were fuses
that you burnt when you programmed the PAL) associated with each
input/product term combination (so in this example, since we have 10
inputs, and a total of 64 product terms (8 for each of 8 outputs), there
are a total of 64*2*10 = 1280 fuses). The 4 combinations of the fuses
select the following 4 possibilities :
That input is not used in that product term
That input is ANDed into that product term
That input is inverted and ANDed into that product term
That product term is forced to 0 (basically, the input and its inverse
are ANDed into the product term).
So, given the fuse map, you can easily recreate the product terms. Since
you know the fixed part of the chip (The OR matrix, inverters, etc), you
can recreate the equations, albeit in a non-minimised form.
At least free [1] version of PALASM came with a program to do this,
called JED2EQN IIRC. It was supposed to accept a file giving the signal
names for the pins which it would then substitute into the equations, I
could never get this to work. I used to feed the output through sed(1)....
[1] That's free as in beer, alas. It didn't cost anything, but was an
MS-DOS executable only.
-tony
25 Jun
25 Jun
5:22 p.m.
Jules Richardson wrote:
what's the most sensible format for backing up PAL
chips such that they
can be recreated on a different system to that which they were backed
up on?
JEDEC fuse map and, if possible, logic equations. Strictly speaking though, a
JEDEC-format fuse map file is enough to copy a PAL. Equations just make it
easier to move to a different chip.
... some of which are presumably EPROM-only formats (I
don't have a
manual for the programmer)
Which programmer are you using? One of the Elan multipurpose programmers?
is there some sort of common format/size for PALs too
when reading (akin
to always being able to read a 27128 EPROM as a 16KB device regardless
of who actually manufactured it)?
Not to my knowledge. You have to get the programming algorithm right otherwise
you'll either blow the chip (literally) or get a garbage readback.
If you've only got one PAL, and it's not registered, map the circuitry so you
know where the inputs and outputs are. Build an adapter that converts a 27xx
EPROM pinout into the PAL pinout - connect the address lines to the inputs and
the data lines to the outputs. Read the chip out like that, and you'll get a
massive truth table of sorts. Take that and convert it back into the
equations, then compile it with OPAL or CUPL and burn a chip from it. Test
your new chip in the target circuit - if everything works, then you're done.
I'm concerned that this programmer
might be too old to have data on some of the PAL chips that I want to
archive - but if I'm only interested in archiving them (and so can set
the type to something of the right 'geometry' from a different
manufacturer) that's not necessarily that big a deal.
I'd be more worried if it was too new. A lot of manufacturers remove old
programming algorithms from their programmer firmware to make space for new
ones...
--
Phil. | Kitsune: Acorn RiscPC SA202 64M+6G ViewFinder
philpem at dsl.pipex.com | Cheetah: Athlon64 3200+ A8VDeluxeV2 512M+100G
http://www.philpem.me.uk/ | Tiger: Toshiba SatPro4600 Celeron700 256M+40G
7:01 p.m.
Philip Pemberton wrote:
Ahh, but I mean purely for reading, not programming. This programmer seems to
have a pretty comprehensive number of supported chips, but as it's done by
cartridges and the programmer's old I'm unlikely to be able to find any other
cartridges for it.
I'm mainly interested in backing up PALs to share the data online for others,
so it's less of a concern if my programmer can't actually program them again -
reading them is the important bit!
Well it does a good job of 80's-era EPROMs, at least, so I suspect it's good
for any PALs from that era too. It just won't do 3-rail EPROMs or any form of
EPROM over 1Mbit (which can be problematic for early 90's hardware)
cheers
Jules
Jules Richardson wrote:
bugger - I was afraid someone would say that.
For some reason that's the one format that seems to not work; I can read the
device OK, but as soon as I try and spit jedec format data down the serial
line to the remote machine it gives me 'illegal operation' on the programmer's
LCD display. Other formats *seem* to work, in that I get binary data at the
remote end that is variant in nature.
what's the most sensible format for backing
up PAL chips such that
they can be recreated on a different system to that which they were
backed up on?
JEDEC fuse map , if possible, logic equations. Strictly speaking
though, a JEDEC-format fuse map file is enough to copy a PAL. Equations
just make it easier to move to a different chip.
Yeah, it's an Elan universe 1000 - previous owner never found a manual
anywhere for it, and nor have I :-(
It's possible the jedec prob. above is just user error (or, alternately, that
the programmer is failing to read the chip despite what it says, and when I
dump data down the serial line it's just giving me what happens to be in the
programmer's RAM at the time)
... some of which are presumably EPROM-only
formats (I don't have a
manual for the programmer)
Which programmer are you using? One of the Elan multipurpose programmers? is there some
sort of common format/size for PALs too when reading
(akin to always being able to read a 27128 EPROM as a 16KB device
regardless of who actually manufactured it)?
Not to my knowledge. You have to get the programming algorithm right
otherwise you'll either blow the chip (literally) or get a garbage
readback. I'm
concerned that this programmer
might be too old to have data on some of the PAL chips that I want to
archive - but if I'm only interested in archiving them (and so can set
the type to something of the right 'geometry' from a different
manufacturer) that's not necessarily that big a deal.
I'd be more worried if it was too new. A lot of manufacturers remove old
programming algorithms from their programmer firmware to make space for
new ones... 
5:36 p.m.
Jules Richardson wrote:
what's the most sensible format for backing up PAL chips such that they
can be recreated on a different system to that which they were backed
up on?
My standalone EPROM/PAL unit seems to understand the following data
formats:
ASCII
binary
motorola s rec
intel std & 8086
elan fuse map
jedec
mos tech
texas tags
tex hex
... some of which are presumably EPROM-only formats (I don't have a
manual for the programmer)
is there some sort of common format/size for PALs too when reading (akin
to always being able to read a 27128 EPROM as a 16KB device regardless
of who actually manufactured it)? I'm concerned that this programmer
might be too old to have data on some of the PAL chips that I want to
archive - but if I'm only interested in archiving them (and so can set
the type to something of the right 'geometry' from a different
manufacturer) that's not necessarily that big a deal.
Advice appreicated :) I'm used to working with EPROMs, but PALs are a
total unknown to me!
If you had to pick *one*, I'd go for JEDEC. If the device is
"unlocked", then I would see if you could get a logic compiler
to "decompile" the fusemap for you (so you can choose to implement
it in another device if the device becomes unavailable).
If this is "just" a PAL (small), that's probably do-able.
If it's a bigger FPGA, you're probably best sticking with
whatever tools *that* vendor provided (since you will probably
be stuck with that part, as well!)
6:13 p.m.
Advice
appreicated :) I'm used to working with EPROMs, but PALs are a
total unknown to me!
Keep it all --- I don't think you need more than a floppy
disk at one time
for all the software and data files for the older PAL's.
7:01 p.m.
Advice
appreicated :) I'm used to working with EPROMs, but PALs are a
total unknown to me!
Keep it all --- I don't think you need more than a floppy
disk at one time
for all the software and data files for the older PAL's.
7:13 p.m.
Alexandre Souza wrote:
this is a good question: How to reverse-engineer PALs?
Maybe a simple all-possibilities-generator on all the inputs could lead
me to derive the logical map?
If the device is not registered, then it's purely combinatorial
and you can map all the cumzouta's by stimulating all the gazinta's.
Brute force. But, this can then be algorithmically reduced to a set
of simple equations.
If the device is registered AND THERE IS NO BURIED STATE, it's
a similar process to the above -- except now all of those
registered outputs are also inputs to the array. The added
trick is that you need to keep track of how to *get* to a particular
state in order to have that set of inputs the way you want them
as you probe the array. The easiest way I have found to do
this is to just build a map of each (present state, inputs)
condition and record the observed "next state" that results.
Initialize this to "unknown" for each possible set of state
and inputs. When you find yourself in a state, see which
inputs have not been tried. Try one. Record the result.
Repeat. If you find yourself in a state that is entirely
mapped, pick a set of inputs that will get you to some
OTHER state with some as yet unknown inputs. There are
deterministic algorithms that will tell you if you can get
Advice appreicated :) I'm used to working with
EPROMs, but PALs are a
total unknown to me!
Keep it all --- I don't think you need more than a floppy
disk at one time
for all the software and data files for the older PAL's. from A to B (and how many steps). For small
PAL's/PLA's,
the whole process takes a few seconds on a slow PC :>
(assuming you have direct access to the inputs and outputs
of the device)
6:58 p.m.
is there some sort of common format/size for PALs too
when reading (akin to
always being able to read a 27128 EPROM as a 16KB device regardless of who
actually manufactured it)? I'm concerned that this programmer might be too
NO!. In fact you can ruin the chip by getting the manufacturer wrong!.
There is a big difference between a PAL and an EPROM in this respect.
When an EPROM is used in the normal application circuit, it is read out,
and what you read out is simply the pattern of bits that you programmed
into the device. But when you use a PAL, you don't read out the fuse map
(think about how a PAL is actually constructed).
To read the fuse map out of a PAL, you have to get it into a
program/verify mode. Typically, this involved overvoltaging one or more
of the pins. Needless to say, if you get this wrong (and different
manufacturers did their own thing, many of them refused to document the
method except under an NDA :-(), you will damage the chip.
-tony
6596
days inactive
6597
days old
11 comments
8 participants
participants (8)
-
alexandre-listas＠e-secure.com.br -
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
dgy＠DakotaCom.Net -
julesrichardsonuk＠yahoo.co.uk -
jwstephens＠msm.umr.edu -
philpem＠dsl.pipex.com -
Steven_R_Hutchins＠raytheon.com