6502.org

Btw. In my case my programmed GAL is working as expected. I cant say anything about 22v... parts but for 20v8b the failing bit seems just the verify operation.

Maybe you can test if your part is correctly programmed by using a simple design.

Well, I tried it out this morning, hoping that maybe the reading back/verify portion of the programmer was just crapping out. No such luck... It's just not working past the 32nd. I have been debating wether to get the Genius programmer, another £30-£40 and the wait for the slow boat from China, but in the end as I wanted a 65SPI anyway, Daryl has kindly agreed to burn A GAL for me. This means I can get the "mother board" PCB going now, and get the Genius at a later date.

I had *exactly* the same issue with my Signstek TL866CS and trying to program Lattic GAL22V10Bs.
Proramming seemed to work, verification always failed. Reading back the programmed data always showed some mismatch. Sometimes, the programmed devices did what they were supposed to do, but not reliably. So something was wrong.

No matter what voltage, whether encryption was "Encrypt ch" on or not, I always failed programming them with the TL866CS.

I then upgraded to MiniPro v6.60 and also the firmware was updated.

After that, I was still *not* able to programme the GAL22V10Bs, but programming GAL22B10Ds works like a charm now, and even verification succeeds! If I disable "Encrypt ch", I can also read back the exact same bytes.

So, I don't know if it is solely due to the software update, but the current version is for sure able to program Lattice GALV22V10D without any problems, with successful verification.

welcome, lambdamikel, and thanks for sharing your experience.

Just curious -- did you end up here as the result of a web search regarding the TL866CS? Or perhaps you're a 6502/65816 fan, and that is what brought you to our forum.

If you have 65xx-related projects we'd be glad to hear about them. Also notice our sister forum at anycpu.org which, as you may guess, has a more general scope.

-- Jeff

Thanks, Jeff!
yes, exactly, this is how I found it.

However, I also have a lot of retro 6502 computers, so I definitely should be here for that reason too

Best,
Michael

I'm having the same problem here
i got 6 gal22v10d chips and for now i need 2 working but only one programs successfully
i have version v6.60
could the chips be broken ?
but then again they all fail on 0x32 so i believe that's unlikely

Welcome, C32_. I'm not a GAL guy and at the moment I'm drawing a blank about the phrase, "fail on 0x32." But I can easily imagine a case where something external is wrong, for example the wrong programmer or the wrong firmware, and in such a case all your chips would fail to respond whether they were defective or not. IOW I don't see how failing on 0x32 provides any conclusive evidence about the chips being damaged or not.
Alright, this is different -- this seems like much more meaningful evidence. If all six of your gal22v10d chips are outwardly identical (same manufacturer, speed rating etc) but only one of them programs successfully then it sounds very much as if the other five are fried. If I'm missing something I hope someone else can shed more light on the subject.

The failing on 0x32 probably means that it's programmed it, and has attempted to verify it, and the verify failed at location 0x32($32).
My EEPROMs do something like this a lot of the time, which is irritating, because they're $12 a pop if I remember correctly.

I mean it fails to verify on address 0x32 (the programmer says Addr 000032 but i assume it's hex)
I got 5 from one seller and the other one from another seller on ebay and the working one is from the 5 chips. The one I bought fails on the same address as the other 4. I don't think it's likely that they all broke on the same address.
Maybe the whole chip is damaged though, and the reason it fails at exactly 0x32 is due to something with the chip's architecture

Have you tried to erased them and verify they are blank before you tried to program them?

yes

Hi

I recently (a couple of years ago) had a similar problem with an old Signetics N82S100 PLA, and with some effort found out that you require an older programmer in order to program this.

I don't know whether this applies for your problem, but my solution was to buy an old BP programmer (BP microsystems) which supported both PLA/PLD and EPROMS. The reason for buying BP was that they are still in existence and that you can also download an (almost) updated software that runs under some older version of windows. I found an Win95 portable in the attic that I use for this (it needs to have a parallel port).

The model I bought: CP-1128

They are not so easy to find, but once in a while they pop up on ebay. There might be other models that also support PLDs, but you will have to do some searching.

i just got some new gal22v10d and programmed one in 10V no encryption and it works great
i'm afraid the old ones are fried from the default programming voltage of the software.
i could have also got broken chips in the first place idk
i have only tested one though out of the 5 i got but i think the rest will work as well
i'm just happy that i have some more working ones to work with

EDIT: all of them worked like that

I know this thread is very old but since I run in the same trouble, I'm going to leave here some info about why this issue happens and how I solved, just in case anybody would need.

I had the same problem with all of my GAL20V8B:

most of the times I got a protection error, something like chip damaged, overcurrent protection etc.
Verifying the written chip, I always got "Programming stopped! Verify Error! Addr:000040 Buff_val:0 IC_val:1"

At first I thought it was a fake chip issue (30 ICs all bad!!!), so I bought more ICs from another source, same thing. But then I discovered what caused the issues, so here there are my two cents:

WRITING ERRORS:
The TL866a / MiniPro programmer is using 16 Vpp. I found that you can program the chip with 14 Vpp (13.5 Vpp seems to work well too).

VERIFIYING ERRORS:
It writes and verifies the chip correctly; however if you try to make a further verification, it fails. And if you try to read the chip content, you get all "1".
This is because there's an option on the MiniPro software called "encrypt ch" (selected by default) that prevents from further reading (in order to protect copyrighted code inside the chip from 3rd parts reading).
So you can simply uncheck that option, and you can read the chip content again.

This is based on my personal tests, not on my inexistent knowledge on GAL chips, so please forgive me if I'm wrong.