ATF750C support

[ole00]

I'm working on supporting ATF750C which was researched and implemented by Michael D. (@nospam2000) in his Afterburner fork. The plan is to refactor his code and merge it to the latest Afterburner version. Ideally it should support the old Afterburner design as well (low priority on that). I would like to simplify his new upload code a bit and remove the partial/segmented uploads. That added a lot of complexity which I think can be avoided. The reason for partial/segmented uploads was the size of ATF750C fuse map being too large to fit into 2kB of SRAM on Arduino UNO. My plan is to support the bigger UNO devices (UNO r4), MEGA and possibly Leonardo (2.5kB of SRAM) fully and also to support the small UNO devices (2kB of SRAM) partially by using a sparse fuse map. The sparse fuse map would not keep the fusemap bytes (actually 16bit shorts) in SRAM where all bits are 0. The implementation of sparse fusemap should be relatively simple, but does not guarantee that very complex fusemaps/projects would fit. I did a check of WinCUPL sample projects targeting ATF750C and all of the available samples should fit into the sparse fuse map. The sample fusemap sizes are as follows:

CNT10.PLD - 6560 bits (820 active bytes)
EX375.PLD - 8192 bits (1024 active bytes)
MTRAFS_C.PLD - 4032 bits (504 active bytes)
GCOUNT_0.PLD- 7264 bits (908 active bytes)
t885.PLD - 6112 bits (764 active bytes)

So, the sparse fusemap array could have a space for ~1300 bytes of active fuse bits and an index area of 128 bytes. The idea of a sparse fusemap is that the whole fusemap is divided to blocks of 16 bits. In total it would be 1024 blocks to cover 16384 fusemap bits. There would be an index array of 128 bytes holding a single bit for each block (128 * 8 is 1024). If the index bit is 0 then it means the block contains all zeros and no data is saved in fusemap. If the index bit is 1 then it means the block has some non-zero bits which are stored in the fusemap array. The drawbacks of a sparse fusemap is that (obviously) may not fit all fuses in certain complex PLD designs. Another drawback is that random writes to sparse fusemap require a lot of data shuffling. Since the reads and writes to the fusemap are mostly sequential I hope that it will not cause performance issues.

The current status is:

• detection of UNO r4, MEGA and Leonardo boards works
• pinmuxing and VPP setup works
• PES can be read and identified as ATF750C
• sparse fusemap works

UPDATE 1: Another solution for supporting bigger fusemaps on UNO (without resorting to sparse fuse-map) is to add an optional SPI RAM IC on the Afterburner board. That would increase the cost a bit (IC + 2 Mosfets + a decoupling cap) by ~ 3$, and the soldering complexity (it is a SOIC IC, so SMD soldering).

UPDATE 2: sparse fusemap implemented and tested on ATF22V10C. Speed difference (compared to direct fusemap access) seems to be minimal (reading fusemap is roughly ~ 1 sec slower on Arduino UNO when reading fusemap with 400 active bytes).

UPDATE 3: reading writing erasing and verification of fuses works on Arduino UNO. I tested the functionality of programmed ATF750 with simple PLD equations. So far it seems to work. The new code is available for testing in the following branch "ole-20231208-atf750-wip". Make sure to compile both the sketch and the PC app before testing.

UPDATE4: the latest WIP branch is this one: "ole-20240204-atf750-wip2". It is rebased on top of master and contains a bugfix that enabled sparse fuse map on other devices (only ATF750 should use it).

UPDATE5: the support for ATF750C has been merged to master branch. See version 0.5.7.

[rhgndf]

I obtained an ATF750C but it got really warm during programming and I couldn't read the PES of it at all, maybe it is broken.

Not sure if it works, but if there was a way to reduce the serial buffers through defines from 64 down to 16, it could possibly free up a bit more memory here: https://github.com/arduino/ArduinoCore-avr/blob/master/cores/arduino/HardwareSerial.h
I think platform.io has a way to include global defines in projects, not aware of this feature in the arduino IDE though.

[ole00]

The memory should not be a big issue - especially not in your case as you use Arduino Mega. For Uno, I use sparse fusemap buffers which work fine as well. If you'd like to experiment I can create and push a WIP branch for ATF750C to github. The branch can read PES and has a basic support (unfinished) for reading fuses. Let me know.

[ole00]

I've pushed a WIP (work in progress) branch named 'ole-20231208-atf750-wip', at least PES reading should work.

[nospam2000]

remove the partial/segmented uploads. That added a lot of complexity which I think can be avoided.

That's true, but this enables to program even larger devices like ATF2500 although I have no clue what programming protocol they use.

[ole00]

@nospam2000 ATF2500 and large fusemap: true, there are several options when you need large fusemap:

1. use ATF1502 which should be programmable via JTAG and is way cheaper than ATF2500. Of course, that does not work if you need to repair existing retro electronics and no source code of the PLD exists (ie. only JED file is available).
2. use Uno R4 or Arduino Mega which have more SRAM
3. possibly add an optional SPI RAM into Afterburner HW design (I think we might be short of one GPIO pin on UNO - maybe a pin could be spared? Or use Arduino Mini which has extra 2 pins compared to Uno)
4. use the partial/segmented upload solution you developed. GALMate also uses similar approach.

EDIT: SPI RAM like 23LC512 from Microchip could in theory support single data line for input and output, so no extra Arduino pin would be needed (the Data Output - SO - is normally in high impedance mode, not interfering with the data input. A clock signal could be delayed to accommodate the transition between data Input and Output ) . For Chip Select pin of the SPI RAM (RAM_CS), I would use few mosfets to combine POT_CS and SHR_CS (NAND gate) into the RAM_CS

[rhgndf]

One could probably convert the jed to a list of equations in verilog that could then be reprogrammed, but knowing which bit corresponds to which fuse might be a problem.

As for the lack of storage, storing part of the fuse map in flash or EEPROM may work, but the limited write cycles may be a problem.

There may be some i2c ram chips that can save pins as compared to spi like:
PCF8570P, looks obsolete
47C04, has both DIP and SMD variants

[ole00]

decompiling JED: MAME emulator has a tool that can decompile some binary fuses into equations. The tool name is 'jedutil'. See here: https://www.jammarcade.net/how-to-use-jedutil/

EEPROM: I thought about it as well, but dismissed it because the space is not big enough (on UNO) to fit let's say 2KBytes of fuses.

I2C RAM: that might be an option as well, I could possibly repurpose the SPI bus (Clock and data) that is now used to control the shift register and digi pot, dynamically into I2C bus and back to SPI. I'm not quite sure whether the I2C pull-ups (on clock and data) would interfere with SPI bus, probably not.
EDIT: Yes, 47C04 or 47C16 looks like a good candidate - it is even cheaper than SPI RAM and would not need extra mosfets for CS line.
EDIT2: Actually, 47C16 is 16 kBits (2kbytes) which is a bit small for bigger fusemaps. In theory 2 or more could be used as the IC can be configured with different addresses on the same bus, but then the price advantage disappears (also requires more PCB space).

[rhgndf]

There might be a few more unconnected pins in the 74HC595 to use as the SPI RAM CS pin. I don't think it will need to be toggled that frequently so the speed shouldn't matter that much.

For the external ram, what if the code used it as an expansion ram? Half of the fusemap could be stored in the arduino ram while the other half could be stored in external ram. That way it could store a larger fusemap.

[rhgndf]

@ole00 I have tried your branch. One minor bug: the max amount of fuses needs to be set correctly in the PC program or else it segfaults.

Also, it seems like ATF750C is quite fragile, I somehow fried one quite quickly when using the program. I still have another one that still works after doing a lot of testing.

[ole00]

Thanks for testing. I've progressed with my branch considerably. I can now read write and verify the GAL chip. However I have not tested the GAL functionality itself. I'll update the branch soon.

[ole00]

@nospam2000: I'm getting close to merge the work you've done to support ATF750C to master branch. I'd like you to put your name on the credit list on the README.md because I think it was a major effort to figure out the programming support for ATF750C.
My question is: are you OK if I use your full name (as found in your git commits) in the README.md as the person behind the ATF750C implementation? Or would you prefer another option? If so, let me know.

[nospam2000]

Thanks, that would be great! Full name is good, just obfuscate the email a bit, e.g. don't use '@' but e.g. '(a)'

[ole00]

OK. thanks. Don't worry, I won't put your email in the README, but I'll link your forked repo as a reference.

[ole00]

@rhgndf : I've updated the ATF750C WIP branch, please pull the changes and re-try. It should now support read write verify without issues when using ATF750C. Also recompile the PC app as it needs bigger buffers. Thanks.

[ole00]

@rhgndf : So far I had no issues with the ATF750C fragility. Perhaps your early tests used 12V VPP and not 10.5V VPP as that seems to be the voltage Atmel GAL chips require?

[ole00]

@rhgndf : I fixed few more issues with my port of ATF750C. Please pull the wip branch and recompile both Arduino sketch and the PC app. I tested a simple design compiled by WinCupl on actual device and it works!

[ole00]

I've done some experiments with serial RAM 23LC1024 and it works well with just a single data pin (for input and output). The Spi RAM Chip select was combined from the SHR_CS and POT_CS, so far no big issue was found. The small issue is that the bitbanging the serial data takes significant amount of processing time,. Reading/writing a single byte takes ~ 500 to 620uS (16 bit addressing on 23LC512 and 24 bit addressing on 128kbyte RAM chip) . It might be further optimised on AVR arduinos by directly using the registers to toggle the GPIO pins. Here is my experimental board which may turn official at some point if a GAL chip with big fuse map is needed...

BTW, the board has an option for discrete VPP booster. Depicted is MIC2619 with over voltage protection, but others like TPS61040, or MIC2250 should work as well (no OVP though). The option to use MT3608 module instead of discrete components still exists.