Amiga hardware info, help and support with a focus (but not limited to) North American NTSC experiences. Open to all.
User avatar
EzdineG
Springfield, MO

by EzdineG posted Tue Jul 31, 2018 9:01 am

joethezombie wrote:Please be aware, i am making a lot of worst-case assumptions here. It is entirely possible the PALs are not protected, or are simple in nature. My advice would be to decode the PALs firstly, burn new copies, and try them in The Rejuvinator to test function before spending a lot of effort elsewhere.

Damn good bit of advice there. Thanks for sharing your experiences, Joe!
User avatar
intric8
Seattle, WA, USA

by intric8 posted Tue Jul 31, 2018 9:03 am

Hi Joe,

Man - thanks for your comments. Those are pure gold. I did have a discussion with Greg Tibbs about the PALs in June. We were also concerned they might be read protected. Here's what he said:

Greg Tibbs:
I think my old programmer, now long gone, could clone a pal of the same type. In those days, each PAL had so much minimal gates and you programmed paths to the output pins via fuses to logic gates and then route to a pin. My guess is that any other chip that does not mimic the PAL internal organization will not be an easy task without decoding the logic. You could put the PAL on a breadboard and, knowing what were input pins and output pins, statically set the inputs high and low and monitor the output pins and then figure out what gates were used for each pin. I wish I still had documentation for you, but I don’t.

I don’t think I read protected them… I don’t remember the capability to do that. I just remember that they were write once devices. I went through a lot of chips to get the pals that went production. I was one gate short in covering the powerup glitch that randomly falsely triggered the write line to the real time clock at power up and down.

The code I used was a special syntax like assembly code that was specific to the software that compiled the output and created the file for the programmer.
User avatar
joethezombie

by joethezombie posted Tue Jul 31, 2018 10:01 am

Well that is certainly a most promising conversation with Greg! It very much implies that he didn’t use any complex registered equations or memory functions if he speculates you could decode the equations on a breadboard. Great news! My friends in arcade repair have created a special board based on Charles MacDonald’s work on PAL decoding. It’s connected to an arduino which forcably persuades the logic out of the chip by trying every combination, but it can only work on simple mode equations. So there does exist tools to help in this endevour.

The special assembly code like syntax he used is CUPL, that when compiled gives a JEDEC fuse map that the programmer uses to burn a new chip. If you are successful in directly reading the PALs (ie. they’re not protected), then you won’t have to worry about that language. If the equations must be re-created manually, then you will. It’s not a fun language.
User avatar
dalek

by dalek posted Wed Aug 01, 2018 12:10 am

Pretty sure it's the R8's and V8's that have both modes. The data sheet I checked for the PAL16L8 had combinatorial outputs only.

Once again archive.org has our backs.

EDIT: also found this up to date site and PCB design.
User avatar
joethezombie

by joethezombie posted Wed Aug 01, 2018 7:30 am

Hi dalek,

Believe me, I am more intimate with the data sheets for these PLDs than I ever wanted to be. The data sheet also specifies that the protection fuse is only specified for the R series, but I can tell you with absolute certainty that the L series also have this capability.

The function of the L series that causes problems reading back the equations is it's three-state output. As I said prior, the L series has a rudimentary support for registered mode functions. In the case of PowerCache, an equation was assigned to a pin that the output was turned off. This causes that pin to "float", and give variable results on the exterior pin when reading. The result of that equation was then fed internally to another function, which the output was enabled or disabled by yet a third input. This means, the value of the output could be high, low, or line, depending on the results of two other equations involving 5 inputs.

The work that you linked to is that done by Charles MacDonald I spoke of earlier. I built up one of his 27C020 EPROM adapters, and although it worked brilliantly on several practice PALs, it did not work for the PowerCache. The tri-state outputs would cause variable readouts, meaning each read would be different, and cause garbage equations when run through the analysis software.

Also note, Charles' adapter can only work on PAL16, the 20 pin PALs. The Rejuvenator has two 24 pin PALs, so it could not be used for those ICs.

I didn't really want to get so technical here, I just wanted to share this information and my experiences as they pertain to this project, so someone wouldn't have to re-discover the issues I had. They may not even exist in this project. But it is certainly going to be either the simplest or the most difficult portion of the project. I sincerely wish for the prior, and that the PALs are just placed in a programmer and read out with no issue, because that would be just tremendous! At least, it's going to be super easy to try it!
User avatar
intric8
Seattle, WA, USA

by intric8 posted Wed Aug 01, 2018 8:56 am

@joe, layman question here.

Is there any risk of harming the original PALs by trying to read them?

In other words, let's say the code transfer fails with new chips. Will the original PALs be safe to reinstall to the vintage Rejuvenator and still be OK for use? I'd hate to trash the original chips in the process.
User avatar
intric8
Seattle, WA, USA

by intric8 posted Wed Aug 01, 2018 11:11 am

Good news - I got my own Rejuvenator installed and working.

This was a hurdle to overcome in order for the project to proceed. So relieved (and it is so cool!).
User avatar
joethezombie

by joethezombie posted Wed Aug 01, 2018 11:47 am

Ha ha! Absolutely amazing. Congratulations!


intric8 wrote:Is there any risk of harming the original PALs by trying to read them?

In other words, let's say the code transfer fails with new chips. Will the original PALs be safe to reinstall to the vintage Rejuvenator and still be OK for use? I'd hate to trash the original chips in the process.


Let me preface by saying I am, by far, NOT an expert on this topic; just sharing my personal experiences in decoding a single unit. My project showed that there was no risk. I attempted read, failed, and repeated dozens and dozens of times, and it still works today. Want a longer answer?

Everything has risk. Just pulling the PALs from their sockets has a small amount of risk. Luckily, yours are actually in sockets. Mine was soldered to the board, so you're already in a better position than I. That's good. :)

The individual handling the process needs follow good grounding techniques. I mean, we don't want to be cleaning the legs of the PAL on a cat or something. Also, the programmer needs to be set correctly for the chip. You wouldn't want to apply too high of voltage, or voltage to the wrong pins because the programmer was set for an incorrect part. By the same token, orientation in the programmer is very important. These are elementary precautions, but good to be aware.

Since I had never tried reading a PAL before, I firstly needed a programmer. I settled on the TL866CS, which reportedly has pretty decent PLD support, and there is a whole thread about it on the eevblog. More research detailed that although PAL16L8 isn't listed specifically as one of the "supported chips", the newer(-ish) GAL replacements are read/write compatible. (GAL16V8 and GAL20V8)

So, I tried reading several "expendable" PALs off of a Macintosh SE/30 motherboard. I also ordered some GAL16V8s from eBay and practiced reading, writing, and verifying before trying it all out on my prized possession. I read the PAL16L8 from the Mac, wrote it to a GAL16V8, verified it with the programmer, and popped it into the Mac. It worked! It was happy days until I finally got the courage to try and read the PowerCache chip. This when I found out about the protection fuse... (BOO!)

After reading the chip, the software will show a screen of the contents. If it is filled with all ones, then the protection fuse is blown, and you have a long road ahead. If you have a smattering of 1s and 0s, then you are golden. Save the array as a JEDEC file. You can now burn this to a new GAL16V8 (or GAL20V8 for the bigger guys) and use that part in place of the original.

Like I said, the PowerCache PAL was protected-- every read attempt provided an array of solid 1s. I was very sad. But I can tell you after trying to read it dozens of times in two different programmers, it still worked. Even after trying it in Charles' adapter many more times, it still worked. And even after clipping 16 leads from my logic analyzer to the pins many times over several months, it still works. I will say they're pretty damn hardy.
User avatar
mr.t.guru

by mr.t.guru posted Tue Aug 07, 2018 7:34 am

Just checked the video, the guy seems to be copying the board the hard way. It would have been easier to scan the PCB, import the bitmap and then simply trace the lines like Chucky did for the A3640/A3660 project on A1k.org (and subsequently for the A1200 PCB project currently underway). The HARD part is getting the internal layers. I can copy a 2 layer board in a week or two, maybe less. 4 layers is tough especially if there are traces. if they only used the internal layers for power and ground then it won't be so hard.
Even so you'd want to fix any issues and make some design changes if there are things in the design that are not well done, like placement of parts, or parts that are difficult to get now, replacing them with better parts or placing them so the thing is easy to build rather than difficult. One example would be using GALs instead of PALs because GALs are EEPROM-based and can be re-programmed. PALs are a write-once device (termed OTP for One Time Programmable) so a mistake in the programming code/fusemap will result in a wasted part, whereas a GAL can simply be erased and re-programmed. An existing PAL fusemap needs to be converted for use with a GAL device but it's not a difficult thing to do.
User avatar
Zippy Zapp
CA, USA

by Zippy Zapp posted Tue Aug 07, 2018 9:47 am

Great Demo, thanks for this. I never really heard of this product back in the day so it was nice to get a glimpse.

Who is online

Users browsing this forum: No registered users and 2 guests