Current inexpensive programmer for 22V10's 16V8's?

[HHaase]

Can anyone recommend from the current crop of programmers an inexpensive option for handling current generation ATMEL 22V10's and 16V8's? 
Most of the info I'm digging up via google is for older, or far too broad (expensive) options.   I don't need to program PIC's, AVR's or much of anything else.
Already have a GQ-4x for handling EPROMS and the few other things I currently need to program.

But what I do need is something that is USB / WIN10 compatible,  not overly expensive,  that can handle Atmel's 5v SPLD's and CPLD's

Any suggestions?

-Hans

[nctnico]

I bought the TL866 minipro for programming GALs but I have not tried it yet.
Dave did a review a long time ago: https://www.eevblog.com/forum/blog/eevblog-411-minipro-tl866-universal-programmer-review/

[HHaase]

Looks like it lists the ATF16V8,   which means it 'can' program GAL's,   but I don't see anything else listed from Atmel.

Perhaps I'll download the current software set at see if anything else has been added.

-Hans

[Bruce Abbott]

The TL866 cannot program ATMEL 22V10's. That's why I built my own programmer for them.

I now have a Stager VS4800 which does program the ATMEL 22V10, and also seems to be more reliable. VS4000 is the 40 pin version, which sells for ~$70 on eBay.

The only thing I don't like about the VS4800 is that chips must be placed upside down in the ZIF socket, and the instructions for where to insert them are ambiguous. I use the unit inverted (so pin 1 is at the top) and labeled it to remind me to put the chip in the 'bottom' end of the socket (closest to the top of the unit). Occasionally it reports a bad connection, which can be fixed by moving the chip in the socket to clean any oxidized pins.
   
   
 

[HHaase]

Bruce,  good to know,  I'll have to dig further into your post there to check out your options.

Looks like there may be another option, kinda, in the cheapie programmer world.
The G540 lists a lot of 22V10, 20V8, 16V8 part numbers, including the ATMEL pieces I'm looking at.
Should be plenty for me for now since I'm just getting started.  Though I am always a bit hesitant when I see super-cheap stuff in this market.
They tend to over-promise and under-deliver.   Doesn't handle their ATF15XXX series,  but Atmel does offer a dev kit that can handle those if I need the extra size of the PLC44's.

[westfw]

The TL866 cannot program ATMEL 22V10's.

Can't?  Or just doesn't have it in their vendor/chip table of supported devices?  How different IS one vendors' 22v10 from another, WRT programming, anyway?

[netdudeuk]

The TL866 cannot program ATMEL 22V10's.

Can't?  Or just doesn't have it in their vendor/chip table of supported devices?  How different IS one vendors' 22v10 from another, WRT programming, anyway?

Have a look on the main TL866 thread. There's mention of GAL22V10s on there. Mine used to do them ok but a software update broke things. I bought a G540 to do subsequent ones.

[Bruce Abbott]

The TL866 cannot program ATMEL 22V10's.

Can't?  Or just doesn't have it in their vendor/chip table of supported devices?  How different IS one vendors' 22v10 from another, WRT programming, anyway?

It does other 22V10's but Atmels are different. I have done a bit of research on this. Their programming algorithms are super secret and AFAIK have never been released to the general public.  A Russian guy modified Galblast to do Atmels, so I had a go at hacking into the executable to see what he did. However the file is packed in an old format that modern disassemblers won't touch, and I have better things to do with my time.  Since then I found a post (in Russian!) that explained the changes required, but I have a proper programmer now so...

For anyone who's interested, here's a translation of the post:-

Special thanks to Vladimir Misyachnomu ("Misyachniy Vladimir") for their valuable advice.
Galblast 1.6 after rework is now sews ATF22V10B.
By adding a delay after installation SDIN, I lost ATF22V10B :-)

It turned out as an interesting detail: this delay should be proportional to the pulse time
programming -STB, and also depends on the programming voltage. So I have tested the
following combinations for which the chip was successfully written:

12V: Delay programming pulse (pulse)

7.5V: Delay programming pulse (pulse)

Further delay is only needed when writing to chip reading also works successfully
and without (pulse = 0 ;-))

Changes in Galblast 1.6:
It was:
static void SendBit (int bit)
{
SetSDIN (bit);
SetSCLK (1);
SetSCLK (0);
}
It was:
static void SendBit (int bit)
{
SetSDIN (bit);
if ((gal == ATF22V10) && writeorerase)
Delay ((pulse = 1)? 3: 1 pulse * 2+);
SetSCLK (1);
SetSCLK (0);
}
Now it works, and on simplified scheme. Power (7.5..12) v served at once (simultaneously)
on EDIT and 7805, c last 5v at Vcc PLD.

I corrected the program. It was and remains. I just handled the firmware and change the
order of bits in the address for firmware Galblast with ATF. I'll try a program from AGK,
recheck and publish files by stitching ATF Galblast.

 

[netdudeuk]

The TL866 cannot program ATMEL 22V10's.

Can't?  Or just doesn't have it in their vendor/chip table of supported devices?  How different IS one vendors' 22v10 from another, WRT programming, anyway?

It does other 22V10's but Atmels are different.

Beware.  As I mentioned above, there are issues with some 22V10s.  Start at post #675.

https://www.eevblog.com/forum/blog/eevblog-411-minipro-tl866-universal-programmer-review/675/

Mine have the Lattice logo on them but they came from China so who knows what they are.

[Bruce Abbott]

The TL866 cannot program ATMEL 22V10's.

Beware.  As I mentioned above, there are issues with some 22V10s.  Start at post #675.

I didn't read the whole thread, but right off the bat I see that he had 'Encrypt ch' enabled. This will cause verify to fail.

Mine have the Lattice logo on them but they came from China so who knows what they are.

That could be a problem, but even with genuine chips it can be tricky. I have several GALs which were pulled from surplus equipment that I know are fine, but the TL866 thinks they need a different programming voltage than what the datasheet says. I also have a bunch of remarked GALs from China, and they all identify correctly (apart from the voltage issue) and work perfectly.

There are many variations between GALs of the same type (even from the same manufacturer) that may or may not be an issue. Atmel GALs must be conditioned before first use by writing a blank pattern to them several times, or they will fail. The ATF22V10B has 5828 fuses, but the ATF22V10B(UES) has 5892 fuses.


   

[HHaase]

Glad I asked the way I did, specifying the ATMEL parts, and really appreciate all the info coming in.    For all the things I can find on the 'net on technical stuff,  everything I see regarding SPLD's and CPLD's is very dated info,  much of it assuming you understand big chunks of prior knowledge.   

But man can it be a struggle to get started.   

[Bruce Abbott]

The ATFblast program seems to work, but I wasn't happy with using a closed-source hack. So a few days ago I decided to get serious about studying GAL programming algorithms, hoping to figure out how to modify GALblast to work with the ATF16V8B and ATF22V10B. Turns out that the problem with ATF chips is not that they have different programming algorithms, but two issues inside GALBlast itself:-

1. GALblast  examines bits in the PES (programmers electronic signature) to determine the vendor, chip type, programming voltage and pulse period. But ATF chips don't have this information in the PES, they just a have a text string representing the part number. So GALblast tries to interpret the bits in the text and screws up, setting programming parameters that don't work. 

The solution to this problem was simple; just tell GALblast to ignore the PES when an ATF chip is selected, and hard code in the correct parameters.

2. Now when GALblast tries to program an ATF chip it mostly works, but some of the bits are corrupted. In particular, the first  '1' bit that follows a '0' bit tends to get written as '0'. The author of ATFblast says the fix was to add a delay of ~20ms before clocking each bit into the fuse row buffer. But with 132 fuse bits per row and 44 rows the delays add up to a very long programming time, much longer than other programmers need. Something isn't right about this 'fix'.

Why is such a long delay time necessary for each bit? Theoretically the chip shouldn't start writing until all the bits in the row have been received and STROBE is pulsed. But what if it did? GALblast sets the P/V- (program / not verify) pin high for the whole time the chip is being programmed. Perhaps ATF chips need to be in verify mode until the row buffer is filled? So I changed the code to set P/V- high just before pulsing STROBE, and lowering it immediately afterwards. Success! I can now program an ATF22V10B perfectly in a few seconds.
     
I still have to test my modified GALblast code with the ATF16V8B and other standard GALs. Once this is done and I have proved that they can all be programmed reliably, I will release the source code.

Next step is to get it working with the ATF22V10C (which has a slightly different programming algorithm). Then I will try making a programmer that works via USB/serial, for use with modern PC's that don't have a parallel port. I am thinking a $3 Arduino Pro Nano clone might do it.

[Bruce Abbott]

Although the ATF22V10B was programming correctly, a couple of bits in the UES (User electronic signature) seemed to be stuck high on read. This also occured with ATFblast. UES contents have no affect on logical operation so I could have ignored it, but I wanted to know why it was happening. So I built a simple parallel port logic analyzer (Elmuesoft 17 Channel Logic Analyzer) to monitor my VS4800 while it was programming GALs. This revealed some interesting things:-

1. The 'stuck' bits do exist, but are not part of the UES. The UES fuse line has a total og 132 bits. On a normal GAL22V10 the first 64 bits are the UES, and the rest are blank. In the ATF22V10 it's the other way around -  the last 64 bits are the UES.     

2. On the ATF22V10C, data is not transferred on clock rising edges as suggested elsewhere, but on falling edges just like other GALs. However only 5 clocks are used to transfer the 6 address bits at the end of each row, the last bit being input directly without being clocked in.  If you try to clock in 6 bits then it 'works' with rising edges because the last rising edge doesn't do anything, but data may be corrupted if falling edges occur at the wrong time. 

3. The VS4800 always writes a blank user signature even when a 'UES' chip is selected. It also disables the power-down feature when programming the ATF22V10CQZ, even when enabled in the JEDEC file (probably a good thing since power-down, which is enabled by default, makes pin 4 unavailable for logic input).
     
4. Delays of several milliseconds between most operations are not necessary. Programming any GAL should only take a few seconds at most.

5. My theory that (on the 22V10) P/V- should be set high only when pulsing /STB is confirmed.
     
With my current code I have successfully programmed an ATF16V8B, ATF22V10B and ATF22V10CQZ, and read various GAL16V8s and 22V210s. I have yet to confirm that standard GALs can still be programmed (maybe I have somehow broken that code) but since the original GALBlast already does them I am not overly concerned. I have also simplified the hardware a bit by removing the pull-down resistors and changing the ATF's programming voltage from 11V to 12V.

The attached zip file includes preliminary source code and executable for my version of 'ATFBlast'.  As well as ATF chips it should also do the GAL16V8, GAL20V8, and GAL22V10. I removed some less popular GALs that were cluttering up the menu.
 
Next I want to port my code to an MCU so it can be used on modern PCs that don't have a parallel port. Thinking of modifying this project which uses an Atmega644 (but probably only needs an Atmega328).
 

[Joe1000]

Hi Bruce

I did a test today using an atmel atf16v8 with atf blaster minimum hardware and your atfblast sw modified.. it works
but using the verification tab , the message was.. failed

I am sending two attachments:
The Hex7Seg.jed is a test file downloaded from internet.. and the result.jed is the jedec saved after writing it on ATF16V8

Do you have some idea about how to fix it?
(For example:  L2048 11111110* seems too short..is it normal?)

Thank you very much!

[Bruce Abbott]

Your main fuse plot (fuse numbers 0-2047, 2048-2055,  2120-2127, 2192 and 2193) and UES (2056-2119) appear to have been programmed correctly. The line that looks 'too short' is actually OK (trailing '0's do not have to be shown because that is the default value). 

The PES (programmer electronic signature) is blank (all FF), whereas it should be something like  31 42 38 56 36 31 46 31 ('1F16V8B1' in reverse). This suggests that it has been erased, or that the programmer is not able to read it. However the PES is only provided to tell the programmer what chip it is programming. It doesn't affect device operation and is not normally programmed or verified.   

Most of the Config fuses between 2125 and 2191 are reading '0' when they should be '1'. This is probably the cause of the verify error. I am not sure what these fuses do (product term disable?) so I can't say whether they are important or not.

According to the documentation provided with some programmers, Atmel SPLDs need to be programmed and erased at least twice to 'condition' them, and may fail to verify until this is done. If your chip is new then programming and erasing it several times might fix the  problem. If not then just test it for functionality and if it works don't worry about the verify error.

[Joe1000]

I will test the  'condition' programming and post the results soon

 

[Bruce Abbott]

Attached is version 0.3 of ATFBLAST. This fixes some minor bugs and improves detection of different GALs. With this version I have successfully programed the following chips:-

National GAL16V8
Lattice GAL16V8A, GAL16V8B, GAL16V8D
Lattice GAL22V10B
Atmel ATF16V8BQL, ATF22V10B, ATF22V10CQZ

More chips may join this list after I get them from eBay. 

I have also made some progress on the AVR-based GAL programmer (code written, need to breadboard the circuit and test/debug).
   

[hlavac]

Any progress? I would like to build one

[SiliconWizard]

I bought the TL866 minipro for programming GALs but I have not tried it yet.

I have one and used it successfully to program GAL, EEPROM and FLASH chips. Very handy and cost-effective.

The only GAL chips that I programmed with it were Lattice GAL16V8D and that worked very well. Apparently, it won't work with ATMEL GALs for some reason?

[Bruce Abbott]

Any progress? I would like to build one

ATFblast is (hopefully) complete. I just received some GAL20V8's to test, so I will soon find out if it works with them.

I have built prototype hardware for the AVR GAL programmer, and am now debugging the firmware. I refactored the code and expanded it to support ATF16V8 and other GALs, and also added back in some features from GALblast that the author of Burnit had removed. This has taken a bit longer than I expected.

The ATmega328 only has 2K RAM so all static data is placed in ROM, and the (up to 5896 bit) fusemap is stored as individual bits in an array of 737 Bytes (unlike GALblast which uses 1 byte per fuse bit. Oh the joys of PC programming, where RAM is plentiful so you can afford to waste it!). This would be no problem in assembler, but C doesn't support bit arrays directly and AVR GCC has some issues with arrays in ROM. It took me 3 days to figure out why the config array wasn't working. Turns out that just declaring the array as PROGMEM wasn't enough, I also had to access the array elements with pgm_read_word(). If I didn't the compiler generated no warnings, but read from the wrong address!

         

[lazarusr]

I have built prototype hardware for the AVR GAL programmer, and am now debugging the firmware. I refactored the code and expanded it to support ATF16V8 and other GALs, and also added back in some features from GALblast that the author of Burnit had removed. This has taken a bit longer than I expected.

The ATmega328 only has 2K RAM so all static data is placed in ROM, and the (up to 5896 bit) fusemap is stored as individual bits in an array of 737 Bytes (unlike GALblast which uses 1 byte per fuse bit. Oh the joys of PC programming, where RAM is plentiful so you can afford to waste it!). This would be no problem in assembler, but C doesn't support bit arrays directly and AVR GCC has some issues with arrays in ROM. It took me 3 days to figure out why the config array wasn't working. Turns out that just declaring the array as PROGMEM wasn't enough, I also had to access the array elements with pgm_read_word(). If I didn't the compiler generated no warnings, but read from the wrong address!

Hi Bruce, Any further updates on this project? I think there would be a fair bit of interest in this.

[westfw]

C doesn't support bit arrays directly

It should be pretty easy to write "wrapper" functions  to access a bit array.C++ has http://www.cplusplus.com/reference/bitset/bitset/ (I have no idea if it works on AVR.  It's and existence proof that it COULD be implemented.)

and AVR GCC has some issues with arrays in ROM. It took me 3 days to figure out why the config array wasn't working. Turns out that just declaring the array as PROGMEM wasn't enough, I also had to access the array elements with pgm_read_word().

Ah; you should have read one of the tutorials...Actually, current avr-gcc has a "__flash" named address space ( https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html ) that would behave the way you'd want it to.

[Bruce Abbott]

C doesn't support bit arrays directly

It should be pretty easy to write "wrapper" functions  to access a bit array.

That's what I did.

Actually, current avr-gcc has a "__flash" named address space ( https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html ) that would behave the way you'd want it to.

I am now compiling with AVR GCC 4.9.2, which uses this syntax. I did have a few problems getting it to work with Atmel Studio 4 (had to replace avr-size.exe with the earlier version. The simulator crashes, but I am now familiar enough with AVR architecture that I don't need it).

Hi Bruce, Any further updates on this project? I think there would be a fair bit of interest in this.

I had to put it on hold while I was working for a company developing a new product. That project is (finally) done now, so I have some free time again!

I have made some progress. The programmer now automatically detects which GAL is plugged in, and reading is working fine. Next step is to try writing. Coding is done but probably full of bugs, so I need to verify correct operation before using live chips. For this test I have set up another PC to act as a dedicated logic analyzer.   

I am also attempting to port the code for my ATFblast (parallel port) programmer to 32 bit Windows, compiled with Borland C++ Builder 6. Got the code to compile without errors, but it crashes when run. Time to experience the 'joy' of debugging in Windows XP!     

[marinovsoft]

Hello, all!
I modified the galblast program for win32. It works on Windows XP/7/8/10, x86 and x64 Windows version supported. You can download from http://marinovsoft.narod.ru/radio/galblast_w32.7z (source code included). The program uses the inpout32 driver from http://www.highrez.co.uk/downloads/inpout32/

[jpham]

Does the Stager vS4800 support that 40 pins atf2500?
if not, what other programmer support that 40 pins atf2500?

[Bruce Abbott]

Does the Stager vS4800 support that 40 pins atf2500?
if not, what other programmer support that 40 pins atf2500?

Sadly, no. One that does is the Phyton ChipProg480 , which costs US$595.

[andi8086]

Hi Bruce,

I wanted to say thank you for the programmer schematics and win 3.1 software I built it this week and everything worked out of the box.
I could program my Lattice 22V10D and 22V10B without any problem. So now you know that the D version also works perfectly.

Especially the D version made problems with the Chinese TL866CS, which always said that bit 32 is wrong and scrambled the whole fuse map...
Some people suggested that the chips might be too old, but since everyone has had the problem with bit 32, this was very unlikely. All chips worked
with your AFTBlaster

And it even works with over a meter cable length... so no need to keep it 4 inch in length...

I started to port the win 3.1 software back to QBasic to work with standard MS-DOS software ^^ . And I definitely will add opto couplers to the schematics
because yesterday, when I plugged in the printer cable  and switched on 12V programming voltage, win 3.1 suddenly went to text mode, which means some driver crashed. Everything is still working but who knows...

[PCB.Wiz]

I'll bump this thread, with this news/link, looks like a new effort, and mentions usb<->parallel dongle operation.

https://github.com/kees1948/perlblast

perlblast
a Perl-Tk implementation of galblast/atfblast that uses the parport device (even via USB!)

'perlblast' is a Perl-Tk implementation of 'galblast' (by Manfred Winterhoff) and 'atfblast' (http://www.bhabbott.net.nz/atfblast.html).

The main drive for 'perlblast' is that it does run on Linux. I tried 'galblast' under Windows XP in a virtual machine but always the parallel port access was troublesome, Some other programs to access the parallel port from a virtual machine worked very well....

I learned and tested also the use via an usb<->parallel dongle, that turned out to function very well too :-)

As the code is now it interfaces to the simplified hardware GAL/ATF Blaster v2.1 as found on http://www.bhabbott.net.nz/atfblast.html

I am working on another hardware project for GAL/ATF programming that can handle various VPP and VCC settings. In that design I took some more measures to block any dangerous voltage from the GAL back to the parport.

[andi8086]

Wow, very cool! Still people around who love Perl instead of Python?

[Giuss]

A software compatible with Windows 10 would bè nice

[technix]

The latest version of TL866II Plus software has added support for ATF22V10.

The guy behind this can add support to a chip if you can send him some samples for him to test on.

[PCB.Wiz]

The latest version of TL866II Plus software has added support for ATF22V10.

The guy behind this can add support to a chip if you can send him some samples for him to test on.

Nice to see an expanding SPLD list there..

This on their website  (http://autoelectric.cn/EN/TL866_main.html)
Version: V8.08 Support:15411--2018.10.30  ADD: ATF16LV8C ATF16LV8CZ ATF16LV8CEXT  SST26VF032B
FIXED: SST26VF064B

Version: V8.07 Support:15401--2018.10.23 ADD: ATF16V8C ATF16V8CZ ATF16V8CEXT ATF22V10C ATF22V10C(UES) ATF22V10CEXT
ATF22V10CQ ATF22V10CQ(UES)  ATF22V10CQZ ATF22V10CQZ(UES) ATF22V10CZ ATF22V10CZ(UES)

Version: V8.05 Support:15360--2018.10.20 ADD: ATF20V8B ATF20V8BL ATF20V8BQ ATF20V8BQL  ATF22V10B ATF22V10BL ATF22V10BQ ATF22V10BQL

[netdudeuk]

And this from a few days ago -

FIXED: GAL22V10B

[Per Hansson]

I have built prototype hardware for the AVR GAL programmer, and am now debugging the firmware. I refactored the code and expanded it to support ATF16V8 and other GALs, and also added back in some features from GALblast that the author of Burnit had removed. This has taken a bit longer than I expected.

The ATmega328 only has 2K RAM so all static data is placed in ROM, and the (up to 5896 bit) fusemap is stored as individual bits in an array of 737 Bytes (unlike GALblast which uses 1 byte per fuse bit. Oh the joys of PC programming, where RAM is plentiful so you can afford to waste it!). This would be no problem in assembler, but C doesn't support bit arrays directly and AVR GCC has some issues with arrays in ROM. It took me 3 days to figure out why the config array wasn't working. Turns out that just declaring the array as PROGMEM wasn't enough, I also had to access the array elements with pgm_read_word(). If I didn't the compiler generated no warnings, but read from the wrong address!

Hi Bruce, Any further updates on this project? I think there would be a fair bit of interest in this.

Seconded, I'd like to try it even if read functionality is all that exists so far

[PCB.Wiz]

The latest version of TL866II Plus software has added support for ATF22V10.

The guy behind this can add support to a chip if you can send him some samples for him to test on.

PLD support is now looking quite good.

Test vectors seems to be missing, so I asked them to add that & I've sent them an example Test Vector file for ATF16V8

They can do IC test on logic, so the building blocks are already there, so PLD test vectors should be possible.

[technix]

The latest version of TL866II Plus software has added support for ATF22V10.

The guy behind this can add support to a chip if you can send him some samples for him to test on.

PLD support is now looking quite good.

Test vectors seems to be missing, so I asked them to add that & I've sent them an example Test Vector file for ATF16V8

They can do IC test on logic, so the building blocks are already there, so PLD test vectors should be possible.

That would be very awesome if doable.

[ebastler]

The latest version of TL866II Plus software has added support for ATF22V10.
The guy behind this can add support to a chip if you can send him some samples for him to test on.

Are you in touch with the manufacturer?
Any chance they could add support for the ATF15xx CPLDs?

(Yes I know, these are old... But they nicely bridge the gap between PLDs and FPGAs. And they are the last parts still in production which have 5V supply versions and PLCC packages. One of their major drawbacks is that the "official", single-purpose USB adapter from Atmel and Kanda seems like the only available tool to program them.)

[PCB.Wiz]

The latest version of TL866II Plus software has added support for ATF22V10.
The guy behind this can add support to a chip if you can send him some samples for him to test on.

Are you in touch with the manufacturer?
Any chance they could add support for the ATF15xx CPLDs?

(Yes I know, these are old... But they nicely bridge the gap between PLDs and FPGAs. And they are the last parts still in production which have 5V supply versions and PLCC packages. One of their major drawbacks is that the "official", single-purpose USB adapter from Atmel and Kanda seems like the only available tool to program them.)

I think the FT2232H can be used for ATF15xx, and there are many boards with FT2232H on them.
eBay/aliexpress have FT2232H boards for sub $15, and I see a LCMXO3LF-6900C-S-EVN is $25.20 on Digikey.
We've used a Lattice CPLD breakout board as a FT2232H carrier, to PGM ATF15xx ( isolate the lattice CPLD first )

I think the Altera Byteblaster is also a menu option on the Atmel ISP SW, so you could also look for those cables.

Of course, it would be great if the TL866II Plus, supported HV Programming of ATF15xx (no lost pins) and also Vector Tested them.

[PCB.Wiz]

That would be very awesome if doable.

An email reply from my follow up yesterday, indicates this is on their 'to do' list, to add to TL866II Plus,  which is good news

[technix]

The latest version of TL866II Plus software has added support for ATF22V10.
The guy behind this can add support to a chip if you can send him some samples for him to test on.

Are you in touch with the manufacturer?
Any chance they could add support for the ATF15xx CPLDs?

(Yes I know, these are old... But they nicely bridge the gap between PLDs and FPGAs. And they are the last parts still in production which have 5V supply versions and PLCC packages. One of their major drawbacks is that the "official", single-purpose USB adapter from Atmel and Kanda seems like the only available tool to program them.)

If you can send a few samples to the author he will be able to implement support using those as test chips.

[Per Hansson]

I want to thank Bruce Abbott for his work on atfblast.
I had a system that had a National Semiconductor GAL16V8 manufactured week 6 1993 let out the magic smoke on Friday before the Christmas holidays.
I built the minimal programmer, with pulldown resistors on the I/O's to support the GAL chip.
I then programmed a Atmel ATF16V8B with a dump pulled from a similar system, but it did not work because of a hardware difference (three mod wires not existing in the schematics I could get for this ancient system).
Finally I got a reply from the manufacturer of said system after the Christmas holidays, lo and behold they had a dump saved with a date code of 1992 and it worked
I was doubtful at first because the code looked very different, but atfblast seemed to handle the extra padding zeroes without complaining at all.
I attached the dump received and how atfblast read it after being programmed to the Atmel chip for the curious.

I did run into an issue though, atfblast 3.1 lists compatibility with: Windows 3.1/95/XP
However it failed to read anything on both a Windows 2000 desktop machine, and also a Thinkpad T40 running Windows XP SP3.
After some Googling I saw that on an older version of Bruce's website there is a file called "ATFBlast_ALL.zip" that contains a user mode program for LPT port access called "UserPort"
This allowed atfblast to work well on the Windows 2000 machine but not the Windows XP machine.
I later found another such program called "AllowIo" it's website is dead but you can also reach it here on archive.org
That program worked fine on the Thinkpad running Windows XP, I have attached the two usermode programs here in case they will be hard to locate in the future.
Note that a few posts back user "marinovsoft" posted a version with proper I/O handling for Windows NT based kernels, however it is the galblast version that lacks support for Atmels GAL chips.
The Perl version linked above by PCB.Wiz is probably useful, but I gave up before I could get Perl-Tk installed in Windows.
It's probably trivial in Linux however but I could not be bothered to boot my Linux machine up to test, mainly because it's physically located in such a way that plugging in the programmer would be difficult

[donotdespisethesnake]

The ATmega328 only has 2K RAM so all static data is placed in ROM, and the (up to 5896 bit) fusemap is stored as individual bits in an array of 737 Bytes (unlike GALblast which uses 1 byte per fuse bit. Oh the joys of PC programming, where RAM is plentiful so you can afford to waste it!). This would be no problem in assembler, but C doesn't support bit arrays directly and AVR GCC has some issues with arrays in ROM. It took me 3 days to figure out why the config array wasn't working. Turns out that just declaring the array as PROGMEM wasn't enough, I also had to access the array elements with pgm_read_word(). If I didn't the compiler generated no warnings, but read from the wrong address!

Did you make any more progress with this USB-Arduino version?

[TomS_]

I got a "TL866II plus" today, and can confirm that it was able to program an Atmel ATF16V8B. I do have some 22V10's as well but havent yet tried these (they are listed as one of the supported parts, however.)

Given it can also program a boat load of other things, it seems like a good option if you need an "all in one" type device, and not overly expensive (£45 or so).

[olin]

I ported Bruce's design to Arduino UNO. Works with linux over serial connection. Schematics, sources and gerbers can be found here:
 
https://github.com/ole00/afterburner/

Thanks to Bruce and Manfred for sharing their findings about GALs.

[johnkenyon]

Does any one know if the programming solutions posted in this thread for Lattice 22V10's will work with some neolithic AMD devices?

I've managed to get hold of some tubes of unused but old AMD PALCE22V10H-25/PC4 devices that I wouldn't mind using to reduce the glue logic chip count on some 8 bit micro projects.

Looking at the AMD datasheet at
https://datasheet.octopart.com/PALCE22V10H25PC4-AMD-datasheet-115211.pdf
and the 1998 Lattice datasheet at
https://www.latticesemi.com/-/media/LatticeSemi/Documents/DataSheets/PAL/PALCE22V10PALCE22V10ZDataSheet.ashx?la=en

the ordering codes are identical, even down to the "blank, /4 and /5" options for the programming designator.

Are these a "drop in the programmer" as well as a "drop in the board" replacement for the Lattice devices?

I don't want to waste money building a programmer if it's unlikely to work.

I've also got some PAL16L8DCJ marked "MMI" which may or may not have been preprogrammed (in which case they are useless).
A little less enthusiastic with these devices given their non-erasable nature - I'd rather cut my teeth on the erasable 22V10s first.

Thanks
 

[olin]

I don't want to waste money building a programmer if it's unlikely to work.

GALBlast states : "It can not be used to program AMD PALC and PALCE, ICT PEEL or Atmel ATF chips."
ATFBlast is based on GALBlast  and added support for Atmel ATF chips.
Afterburner is based on ATFBlast and did not add support for any additional devices.

So I'd guess the chances to programm AMD PALCE on these programmers are slim - only if PALCE chips used the same programming algorithm as Atmel ATF (still some software change might be required).
On the other hand Lattice GALs can be programmed by all above programmers.

[Per Hansson]

What olin writes is true, I have tried it myself and it does not work.
It actually pulls down the voltage of the programmer too.
I remember reading somewhere that on a dedicated programmer the same thing happens:
Overcurrent warnings, so there must be something quite different with them.
Even though they supposedly are electrically the same, really weird...

[olin]

I've updated Afterburner and added support for Win32/Win64 and Osx64. Also released pre-compiled binaries for these.  All located on the github link I wrote in few posts above.

[marinovsoft]

Hello, all!
I modified the atfblast program by Bruce Abbott for win32. It works on Windows XP/7/8/10, x86 and x64 Windows version supported. You can download from https://bitbucket.org/marinovsoft/atfblast (source code included). The program uses the inpout32 driver from http://www.highrez.co.uk/downloads/inpout32/

New vesion of galblast (minor fixes) is here https://bitbucket.org/marinovsoft/galblast

[romhunter]

Hello, I'm trying to build the ATF blaster, one question though. In the schematic 4.7k is used to pull the GPIO to 5V. Is it possible to use 10k instead? Because I've read the page that ATF blaster is based on, it has one section that mention this:

Use 4k7 resistors to connect all VIL pins to the GND pin (we use 4k7 instead of the 10k mentioned in other documents, because some GALs have internal pull-ups of only 50k and illegal input states would occur using 10k resistors). Use 4k7 resistors to connect all other pins (including GND and EDIT) to the VCC pin to prevent open inputs during programming.

[PCB.Wiz]

Hello, I'm trying to build the ATF blaster, one question though. In the schematic 4.7k is used to pull the GPIO to 5V. Is it possible to use 10k instead? Because I've read the page that ATF blaster is based on, it has one section that mention this:

Use 4k7 resistors to connect all VIL pins to the GND pin (we use 4k7 instead of the 10k mentioned in other documents, because some GALs have internal pull-ups of only 50k and illegal input states would occur using 10k resistors). Use 4k7 resistors to connect all other pins (including GND and EDIT) to the VCC pin to prevent open inputs during programming.

That text looks to be talking about pull-downs on VIL pins, presumably there for miss-socket protection. Pull-ups is a different question, and either should be fine.

[MadTux]

Currently fiddling with some Lattice GAL16V8Bs to recreate/verify some cloned PAL16L8 for ancient TIG welder repair/backup.

From my experience, WinCUPL works great with non Atmel GALs.
TL866 is utter garbage for programming GALs, all kind of weird behavior, like inverted outputs and garbled input pins. Nice programmer for EPROMs/EEPROMs though.
Switched over to Topwin Top853 with software 6.x. Works great, so far, Lattice GAL16V8B does what it was programmed for

My messy setup, basically a 20bit 74HC193 counter to get every input state, connected to 2x PAL18L8/GAL16V8, (1x DUT and the other the hopefully correctly cloned device). HP-16500C to capture data and espresso logic minimizer to get logic equations. To check for good clone, I use 7A13 differential amplifier connected to outputs, a line means good clone, any logic signals between pins => bad clone

[ebastler]

My messy setup, basically a 20bit 74HC193 counter to get every input state, connected to 2x PAL18L8/GAL16V8, (1x DUT and the other the hopefully correctly cloned device). HP-16500C to capture data and espresso logic minimizer to get logic equations. To check for good clone, I use 7A13 differential amplifier connected to outputs, a line means good clone, any logic signals between pins => bad clone

Nice test jig, and an impressive bench! 
Can you test for correct tri-state behavior too?

I have only used my TL866 on one GAL design so far, an ATF16V8B in complex mode. (Some registers, some logic outputs, some of them tri-state outputs.) That worked nicely. Maybe I just got lucky?

[MadTux]

Interesting, also have some cheap ATF16V8s from china, but haven't used them so far, because I read everywhere about problems with programming them. So I stuck to the Lattice ones.

Not sure about tri-state output, since I'm mostly about cloning the still good ones in my 2 welders and eventually recreating a probably broken PAL20L8.
I have every input and IO pin connected to 74HC193 counter by 2.2k resistor. If PAL has IO defined as input, I see counter signal. Otherwise 74HC193 signal is overwritten by PAL internal logic.

I like my testbench as well, a result of 15years of TEA 

[PCB.Wiz]

I have only used my TL866 on one GAL design so far, an ATF16V8B in complex mode. (Some registers, some logic outputs, some of them tri-state outputs.) That worked nicely. Maybe I just got lucky?

The ATF16V8x are recently added, so they should also be recently tested

Interesting, also have some cheap ATF16V8s from china, but haven't used them so far, because I read everywhere about problems with programming them. So I stuck to the Lattice ones.

For initial clone testing, it makes sense to minimise variations, but the active production parts, for SPLDs are pretty much only ATMEL, so I would suggest you also check codes on the ATF16V8x, since you have everything there ?

I did ask the TL866 supplier to add Vector Testing, which the better programmers can do, & gave them some example ATF16V8BQL vector files for testing.
It seems you already have your own vector test setup, in a broader sense

[ebastler]

The ATF16V8 are recently added, so they should also be recently tested

I did that GAL project four years ago, so the ATF16V8B has been supported for a while.

[PCB.Wiz]

The ATF16V8 are recently added, so they should also be recently tested

I did that GAL project four years ago, so the ATF16V8B has been supported for a while.

You will be right, I was going by their release notes, which I see cover other ATF16V8x variants.
Version: V8.08 Support:15411--2018.10.30
ADD: ATF16LV8C ATF16LV8CZ ATF16LV8CEXT
Version: V8.07 Support:15401--2018.10.23
ADD: ATF16V8C ATF16V8CZ ATF16V8CEXT
ATF22V10C ATF22V10C(UES) ATF22V10CEXT
ATF22V10CQ ATF22V10CQ(UES)
ATF22V10CQZ ATF22V10CQZ(UES)
ATF22V10CZ ATF22V10CZ(UES)
Version: V8.05 Support:15360--2018.10.20
ADD: ATF20V8B ATF20V8BL ATF20V8BQ ATF20V8BQL
ATF22V10B ATF22V10BL ATF22V10BQ ATF22V10BQL
next step: will add more PLD chips.
FIXED: GAL22V10B M95320W M95128W

Anyway, they seem to be Atmel-PLD active, and should accept any bug feedback.

[nospam2000]

They can do IC test on logic, so the building blocks are already there, so PLD test vectors should be possible.

That would be very awesome if doable.

I started to implement PLD logic test for the TL866II Plus using 'minipro' as base. It can read test vectors from .jed and from .si/.sim files. It is not finished, but you might want to have a look at it.

In the .jed mode 22V10, 16V8 and 20V8 should work, when the test vectors contains all pins in linear order (pin 1,2,3,4,5...).
In the .si/.sim mode at the moment only 22V10 PLDs are supported, because I need a way to pass the GND+VCC pin numbers.

There are three command line switches:

• -T Perform chip logic test
• -U <filename> Test vectors for logic test, can be .DAT, .JED or or .SI (e.g. from WinCUPL; .SI also needs .SIM file)
• -W Increase verbositiy level for chip logic test output, can be given up to 6 times to increase level (e.g. '-W -W')

modified version of minipro: https://gitlab.com/michael.dreher42/minipro/-/tree/logic_test (make sure to fetch the 'logic_test' branch)
gitlab issue where the progress is discussed: https://gitlab.com/DavidGriffith/minipro/-/issues/77

  Michael

[Bud]

Just wanted to share my experience with Bruce's ATFBlast programmer and software he posted earlier

http://www.bhabbott.net.nz/atfblast.html

I built the programmer and it worked on my desktop but ATF chips did not work on my Thinkpad laptop, until I added a buffer (I used a 7407 logic IC) on the ACK line between the PLD output and pin 10 of the parallel port + pullup 4.7K resistor , since 7407 is open collector buffer. Apparently Atmel ATF chips were not able to drive well the output line, though GAL chips worked fine. The buffer fixed that.

In terms of software Bruce's ATFBlast was unstable and flaky on both the laptop and desktop (both WinXP) so I had to abandon that software. Also for some reason it did not detect LPT1, just LPT2 and LPT3 and the port addresses were mixed up. That happened both on the laptop and desktop. What worked perfectly was the software from the user marinovsoft who posted links to it on the previous page of this thread. That worked great and I programmed a few ATFs for a project.  So I can recommend marinovsoft's software for use with Bruce's hardware.

[nospam2000]

Just wanted to share my experience with Bruce's ATFBlast programmer and software he posted earlier
In terms of software Bruce's ATFBlast was unstable and flaky on both the laptop and desktop (both WinXP) so I had to abandon that software.

You might want to have a look at afterburner. It uses an USB connection instead of a parallel port and the time critical part is done by a ATMega MCU, so you can use a recent operating system.

It is based on ATFBlast.

  Michael

[vladutm]

Hello,

last days I started to create this kind of Parallel programmer scheme, starting from atfblast.
In my focus is ATF16V8BQL, I used the Bruce scheme from bhabbot,net.nz. on Win Xp
Currently I'm on status of conditioning with zeros or erasing with ones, but can't programm write with what I want. The single file that is write on the chip si conditio.jed file with zeros.
I also used a buffer for ACK line but didn't change the issue.

I used both applications atfblast and marinovsoft. same behavior.. I will put an oscilloscope on them or use a saleae8 tracer.

Any idea?
I will add some photos from home..

[vladutm]

Hello Bud,

Could you support me with any hints for my last week message? about ATFBlast and LPT + your modifications?

As you will read, I can write only conditio.jed content, it means set all memory to zeros and also Erase all chip memory which means set all memory with ones, any other write than conditio.jed is not accepted..

[vladutm]

Hello,

Solved !!!

Finally I solved the issue... the root cause was to a missing accent to the preparing device for writing... It's saying clear also on http://www.bhabbott.net.nz/atfblast.html on programming procedure on point 6 (6.) to erase the GAL if after reading not all bits are '1'.
Firstly maybe for more of us, erasing means all bits  shall be zeros ('0') because I condtioned with zeros, Erased GAL with ones and after that again conditioned with zeros and tried to write for example all with ones... but not in this PLD case, here Erase GALL means all bits shall be ones ('1'), which also the "Erase GAL" button is doing.

Why I did this mistake?  because ATMEL recommends to condition with zeros twice before programming but nothing about Erasing with ones between conditioning and new programming... 

So be carrefull here...

Second, I think point 6. and recommendation from ATMEL to condition two times with zeros ('0', Conditio.JED) and after that Erase GAL which will put all bits to one ('1', Erase GAL button) ARE A MUST and shoul be underlined on reference and application doc. 

The rest of the circuit and appl from Bruce (bhabbott) and marinovsoft are working fine with and without proposed ACK pin buffer. So both sheme proposed are fine. I tested on Win XP on desktop with integrated LPT port, but will try also on Win7 and Win10 with USB to LPT addapter.

So, in the end, be patient to do an Erase GAL with ones before each new writing process. As I saw it is not accepted to do Erase GAL -> write file_A content-> write file_B content. You have to do Erase GAL -> write file_A -> Erase GAL -> write file_B.

I am aware I wrote so many times same idea but maybe causing I lost so many nights with this programmer until worked fine..

For any questions please Reply.

[vladutm]

Today I did additional tests, reading / writting with ATF16V8BQL chips.

Unfortunatelly I think I found a bug in the applications or in my pcb, I'm not sure. The idea is that I worked with three packages type for the same ATF16V8BQL chip:  ATF16V8BQL-15XU, ATF16V8BQL-15SU and ATF16V8BQL-15JU . For the first two the reading and writting is doing fine, but for the last one, 15JU I saw some bugs on writting or reading, when I write my jed content I saw are wrote additional zeros in random places but somehow repetitive. I will add images later.
More over, I observed if I do many reading consecutive proceses, I can see zeros random in different places each time.

For all of these observations are not the case for 15SU and 15XU, they are working fine.

I tried to check ATMEL documentation to see any possible programming differences with no success until now.

Could somebody support me from applications?

I did teste with same behavior with all ATFBlast3.0, ATFBlast3.1 from Bruce and ATFBlast from marinivsoft.

[PCB.Wiz]

Today I did additional tests, reading / writting with ATF16V8BQL chips.

Unfortunatelly I think I found a bug in the applications or in my pcb, I'm not sure. The idea is that I worked with three packages type for the same ATF16V8BQL chip:  ATF16V8BQL-15XU, ATF16V8BQL-15SU and ATF16V8BQL-15JU . For the first two the reading and writting is doing fine, but for the last one, 15JU I saw some bugs on writting or reading, when I write my jed content I saw are wrote additional zeros in random places but somehow repetitive. I will add images later.
More over, I observed if I do many reading consecutive proceses, I can see zeros random in different places each time.

For all of these observations are not the case for 15SU and 15XU, they are working fine.

I tried to check ATMEL documentation to see any possible programming differences with no success until now.

Could somebody support me from applications?

I did teste with same behavior with all ATFBlast3.0, ATFBlast3.1 from Bruce and ATFBlast from marinivsoft.

The die is exactly the same in all packages, but it may be the PLCC one has longer leads via a socket  adaptor ?

You could try decoupling directly under the PLCC socket, and also try lowering Vcc slightly.
addit:
We have found some PLDs pass programmer vector tests at slightly reduced Vcc, and ATF16V8's seem to vector test ok to below 3V
Vcc during program is trickier, if the shorter leads mentioned below do not fix the issue, you could try lower Vcc during shift operations and restore at the write pulse times.


With longer leads,  moderate series R can also sometimes help improve programming problems.  Typically ~ 100R in series with clocks reduces the ringing, and overshoot can result in extra clocks.

[vladutm]

Thanks for fast answer.

Yes, I'm expecting also to have same die chip content inside and only the packages/pinstypes to be different.

Anyway, I will try to implement what you suggested and come back later.

If you have any other hints, please let me know...

Updated post:
As you can see in my image in the right side are that two PCB that are working fine and in left side is may hand made PCB which has problem..
 In this morning I remembered I had like same issue with SPI in 2013 when I worked on a 3D printer concept design and I did an SD addaptor to arduino SPI from this same Cu green PCB... old times.. I have to contact old company to find that addaptor and see on which pin I accidentally found that a small SMD capacitor to GND I think solved the communication Issue...

[PCB.Wiz]

As you can see in my image in the right side are that two PCB that are working fine and in left side is may hand made PCB which has problem..

Those look like quite long wires for PLD programming.
Can you reduce or eliminate those, so there is less cross talk and bounce ? 


Addit: I see you use ATF16V8BQL, you could also try ATF16V8BQ (if you have them) ?
The BQL parts have a dynamic power wakeup enabled, and that means more Icc variation with the clock.
The benefit is lower static power.