1 Oct
2014
1 Oct
'14
12:06 a.m.
Hi all
Interesting.
I've been doing something similar as an on-and-off project since 2011
(more off than on). Wrote some code to apply vectors on my Expro,
read the output, didn't know about Minilog (thanks, Chuck), wrote
some really clunky code to do something similar.
I'm working on the MAC PALs which is kind of redundant since I have
Jecel's work archived.
My thinking is that a PAL with 8 registers has at maximum 256 states.
Therefore I should be able to apply a vector, clock the PAL 256
times, and that would give me all the states. Repeat for the other
1023 or whatever vectors.
But I recently got back into brewing beer so there's not much
happening on the PAL reverse engineering front.
W
1 Oct
1 Oct
2:06 a.m.
On Wed, Oct 1, 2014 at 1:06 AM, Wouter de Waal <wrm at dw.co.za> wrote:
My thinking is that a PAL with 8 registers has at
maximum 256 states.
If it has 8 registers and no additional combinatorial feedback. That's true for
a PAL16R8, IIRC.
Therefore I should be able to apply a vector, clock
the PAL 256 times, and
that would give me all the states.
That doesn't follow logically.
A state diagram of the 256 states will probably have multi-way branches
and mulitple loops, such that there is no 256-step circuit of all 256 states.
If the PAL has some combinatorial feedback, then some state transistions
may occur independent of the pin used to clock the registers.
Even in the absence of combinatorial feedback, there may be states that
are not reachable except on initial power-up or by violation of register
setup time. In a proper design, all illegal states would eventually transition
to legal states, possibly by some combination of inputs specifically
designated for initialization, or simply by careful planning (e.g., the way the
illegal states of a 74160 decade counter all will eventually count to a legal
state, even without the use of the reset input).
To duplicate the PAL properly, even the behavior of illegal states has to
be duplicated, unless you know that there is a reset sequence that will
be used in the target system.
Some programmable logic devices have test mode functionality to force
the registers into a known state. The earliest PALs don't have this as
a documented feature, so they probably don't have it at all.
2:11 a.m.
There are places you can find that will decap with acid and then photograph
for a pretty reasonable rate. On a HAL like the Mac you can just visually
look at the fuse map. Places in China might be cheaper. I think Henry
might have had a place in China do the whole thing for him on a project
once.
I tried decapping one with some nitric acid from a medical supply place,
but it wasn't fuming and the water oxidized the chip. Better just to pay...
I haven't talked to Henry since I found out my dad got ALS. I'm trying to
get back into things, but I'm spending most of my time inventing tools for
him to enjoy life better. : (
On Tue, Sep 30, 2014 at 11:06 PM, Wouter de Waal <wrm at dw.co.za> wrote:
Hi all
Cloning-a-PAL-HAL-%28Part-2%29&goto=prev
Interesting.
I've been doing something similar as an on-and-off project since 2011
(more off than on). Wrote some code to apply vectors on my Expro, read the
output, didn't know about Minilog (thanks, Chuck), wrote some really clunky
code to do something similar.
I'm working on the MAC PALs which is kind of redundant since I have
Jecel's work archived.
My thinking is that a PAL with 8 registers has at maximum 256 states.
Therefore I should be able to apply a vector, clock the PAL 256 times, and
that would give me all the states. Repeat for the other 1023 or whatever
vectors.
But I recently got back into brewing beer so there's not much happening on
the PAL reverse engineering front.
W
12:59 p.m.
On Wed, Oct 1, 2014 at 3:11 AM, Grant Stockly <grant at stockly.com> wrote:
There are places you can find that will decap with
acid and then photograph
for a pretty reasonable rate. On a HAL like the Mac you can just visually
look at the fuse map.
That works with fusible-link PALs also. It doesn't work with floating gate
parts (EPROM/EEPROM/flash).
6:37 p.m.
Wouter de Waal wrote:
I'm working on the MAC PALs which is kind of
redundant since I have
Jecel's work archived.
The "Turbo Mac" work I did for brazillian cloner Unitron back in 1987
was a clean room design based on public sources (essentially the January
1984 issue of Byte Magazine and volume III of Inside Macintosh), as
described in:
http://merlintec.com/lsi/mac512.html
For those who just prefer the overview: the 512K Mac ("Fat Mac") used
faster memory chips than the original 128K Macs, but Apple didn't take
advantage of that. Doing so only required changing the PAL configuration
while keeping the board exactly the same, so there was no extra cost for
this small increase in performance. After I did the job, I turned all
material I had over to Unitron. Slightly more than a decade later, I
found out I had some scratch documents from the project that had been
forgotten in a briefcase. Though my contractual obligation was to either
destroy this material or also turn it over to Unitron, I figured that
they no longer cared as they had exited the computer business in 1988 or
1989. So I kept it around in the interest of preserving history.
Around 2006 someone was trying to reverse engineer the Mac PALs. I made
what material I had available at:
http://merlintec.com/download/
(files with "unitron" in their names) and someone else mentioned that
they had the original equations from being an Apple service
representative at the time. He posted the original sources online and I
skimmed over them but did not save a copy. It was the first time I had
seen the Apple design and found it a bit messier than I expected.
Some important points about the material I published: these are very
early sketches and when these equations were configured into a
prototype's GALs by accident the machine did not turn on at all (the
analog board didn't generate the needed supply voltages). This was fixed
by reconfiguring them with the latest equations. I do not remember what
changed between the non working and working versions, but it was
something obvious because I was able to tell which were which with just
a quick glance. Of course, since I did the work then I could do it again
but I don't see the point. The key idea is the change in the memory
cycle and this material shows this clearly enough.
The second point is that since my work was not based on Burrell Smith's
you will miss lots of interesting details about the original Mac if you
just look at my project.
-- Jecel
3503
days inactive
3504
days old
4 comments
4 participants
participants (4)
-
grant＠stockly.com -
jecel＠merlintec.com -
spacewar＠gmail.com -
wrm＠dW.co.za