I am looking for the files needed to program replacement GAL16V8D chips for my MicroDrive. This is the original version - not the Turbo one. There are three GALs on the board. The board does not have any silk screen indications of the what the parts are, so I will call them left, middle and right with left being the one on the left as you are looking at the component side of he board with the edge connector pointing towards you. The last time I powered ny Apple ][ GS on with this card installed, the GAL on the right decided to release its smoke into the wild. And it got VERY hot to the touch. When I removed the chip and put it into the XGecu T56 programmer to read it, the programmer said that pins 1, 2 and 11 where shorted together. If you also have a dump of the 27C512 EPROM, that might also be helpful for verification purposes.
I have a couple of Microdrives. I probably should have imaged the EPROMs a long time ago and compared them.
Unless someone else does I’ll hopefully get that done this weekend. And hopefully the fuses weren’t burned on the GALs.
PLD burning up is 100% caused by a fault in the external circuit... even if the internal programming was corrupted such that the PLD enabled (for example) output drivers on an input pin, the SOA (safe operating area) limits the power consumed.
I would look for the cause of the failure first.
The EPROM file is at
https://drive.google.com/file/d/1-tVt7o4UkctIHGecAKvCoTP_AXp7vpsW/view?usp=drive_link
I checked and both cards have identical ROMs
The jed file is at
https://drive.google.com/file/d/1NcWdHO4VLihyAcWDCCAAQn8OyrAbD3i4/view?usp=drive_link
In post #3, 'robespierre' wrote:
" PLD burning up is 100% caused by a fault in the external circuit... "
Uncle Bernie comments:
Not a sure bet in the general case. I've never seen a bipolar / fuse link PLD with built-in SOA protection circuits, and they can be fried by overloading of output drivers. CMOS PLDs all have latch up issues and the negative voltage undershoot of improperly terminated signal lines carrying fast edged signals can cause latch up. Lattice GALs, in particular, can be blown up easily with hot socketing (or brief power supply dropouts while other ICs still provide signals to them). Despite Lattice did claim - in their first GAL databook - that "GALs will not latch up under any condition". They even had a chapter about how badly these GALs can be abused without blowing up. Turned out to be wishful thinking. In some applications, GALs died like flies. The bold claims disappeared from the databooks. Other than that, GALs are nice devices I like to work with until today ;-)
If the GALs in that card of post #1 really were blown up by latch up, then something might have been amiss with the power supply sequencing or its power up / power down ramps. Lattice GALs used an internal charge pump to bias the substrate to negative voltages. Which improves latch up immunity but this protection needs time to develop the charge. A hot insertion of any card with GALs on it will almost certainly destroy them.
- Uncle Bernie
Hi Uncle Bernie:
I think we are in agreement that a blown GAL points to something wrong with either the design of the card or a power supply problem ("external circuit"). You described the reasons far better than I could.
@Wayne, it may be useful to have all 3 jed files, but how were they derived? These were supposed to be code protected GALs?..
I read it with my SuperPro-610P EPROM Programmer.
I was pretty busy Saturday so I only did what was requested. I’ll do the other two when I have more time. I didn’t have time to burn a copy and try it out. Hopefully it’s good.
If they aren’t copy protected then it works. Last year I was fortunate that out of several GALs, one wasn’t protected and I was able to upgrade several controllers.
I've been sick for a couple of days. I got tired of lying in bed so I thought I'd try making copies of that GAL.
I tried the one I posted and no luck so I tried the one from my other card. While the files were very different, a copy of it didn't work either.
Wayne, the jed file you published here is from an unprotected GAL, haven't looked at the equations, but the problem most likely is elsewhere. You may check the programmed GALs you are using verify/read with the same checksum jed. Keep in mind that a defective GAL sometimes can be programmed and verified properly but still be inoperational in the circuit.
I loaded the file, put the original GAL in the ZIF and then verified it to be sure there wasn’t a file issue. Then I programed a new GAL and verified it. When I put the GAL in my Microdrive it wouldn’t function.
Why had it worked before? Are you sure the chip you are programming is fully functional? What if you try the same procedure with the remaining two GALs?
I guess I wasn’t clear. That was with a different card. Someone needed a copy of that GAL. I had several cards with that version and of them one wasn’t copy protected. I also took that opportunity to update the cards I had with an earlier version of that GAL
Was that different card a Microdrive card?
No, it was an AE Vulcan drive card
This is even more interesting. It has 2 GALs and one PEEL. What upgrade is possible via GAL replacement?
With the Vulcan you can use a limited number of drives and CFs. You can also use CFs by writing an image of a drive onto them in a couple of ways.
With the upgraded GAL I discovered that I was able to write an image onto a multi gb drive using balenaEtcher so that the Vulcan thought it was a 100mb drive. This didn’t work with the earlier GAL.
How can one tell which version of that GAL a given Vulcan card has? I guess only by experimenting if the card accepts a 100MB imaged CF card? Was it by chance not one of the GALs, but the PEEL chip?
The GALs have the version printed on them.
It seems like all of them will work with the imaged CF but not an imaged hard drive.
It’s the GAL at U1, it needs to be HDC3,B.I to work with the imaged hard drive.
The jed is at
https://drive.google.com/file/d/12vkQpQxQdaWtQJ1SAapHp3AuGxHXppJi/view?usp=drive_link
Thank you Wayne. Interesting observation and discovery. As far as I recall I did not experience any problems with real HDDs connected to a Vulcan card many years ago, despite I looked now at one of my cards that I use frequently and it had an old version of GAL. I will do some tests when able. Anyway, it is good to have at least 1/3 of the PLDs' fimware, that one seems to interface directly to IDE interface. Are there any advantages of the Vulcan card over other HD storage solutions? It looks quite fast despite not using DMA.
The Vulcan card worked fine with the supported hard drives. The problem was that there weren’t that many supported drives. Also most of those drives weren’t particularly fast. Still a lot faster than floppies or hard drive emulators that run off the floppy port. The imaged drives are a lot faster. With the 256gb drives I used I’ve wondered if the image is on just a few tracks. For the last month I’ve been using an Inner Drive. I think it’s a little slower than a Vulcan. I imagine it won’t be too long before it’s 8 bit hard drive dies and there’s almost no chance of replacing it.