Programming (non-JTAG) MAX7000 devices

[migry]

https://archive.org/details/1999-altera-max-plus-ii-93

OK thank you for the pointer. I was surprised to find the software here!
I installed on an old Vista machine without any hassle. After some playing I found that the Verilog compiler was not licensed, so I tried an example from the AHDL examples. This compiled and I was able to generate a sample POF.

EPM7032AELC44 - data length = 1901 (compiled using Quartus II 13.0)
EPM7032BTC44 - data length = 1945 (compiled using Quartus II 13.0)
EPM7032SLC44 - data length = 1892  (compiled using Quartus II 13.0)
RPM7032LC44 - data length 1846 (compiled using Max+Plus 9.3)

[Beta_vulgaris]

After some playing I found that the Verilog compiler was not licensed ...

Please apply the cpt.dll patch (made by myself) for licensing and Windows 10 compatibility.

[pityokas]

When I first started this project (a year or two ago) I was hoping that someone who had access to genuine programmer hardware would be able to make traces of the pins, in order to allow the programming protocol top be reverse engineered.

For that somebody must have:
1.A programmer
2.adaptor
3.PLD
4.Logic analyser
5.Will to do
6.Read EEVBlog
Long list, and AND condition not OR 

datastream of SCOA is 0146-8AAB-F533-6083-3643
The 80 bits for each SCO shifted out is unscrambled using an algorithm based around sets of 5 bits.

More detail how is unscrambled?

[jdgabbard]

I do not frequent the forum super often, but I thought I could contribute to this thread.  I have laid out the EPM7064-PL84 adapter as the schematic shows on the Benoit website.  There are actually two pages that deal with this adapter, one with better pictures of a prototype version.  However, I do not have a EPM71064 to try this adapter with my ALL-07 programmer.  I can say however, that at least as far as the ICs I have, the EPM7128 does not seem to work with the adapter.  Which would reinforce the idea from previous comments that the pinouts are not the same.  That page is here:  http://matthieu.benoit.free.fr/hilosystem_all-11P2_universal_programmer.htm

That said, I'd be interested in helping with any testing I could do with the ALL-07.  Not exactly an ALL-03, but it is close.

I will say that the ATF1508 schematic works with the ALL-07 and I'm able to program ATF1508s just fine once the POFs have been converted to JEDECs with Atmel's tool.  It would be nice to get these EPM7128 CPLDs working though...  But being from Aliexpress, it's hard to say if they're actually 7128s, or something else that's been rebadged...

[migry]

For that somebody must have:
1.A programmer
2.adaptor
3.PLD
4.Logic analyser
5.Will to do
6.Read EEVBlog
Long list, and AND condition not OR 

Ha ha  Reminds me of the Drake equation. It's supposed to predict the chance of other lifeforms in the Universe, but physicists can't agree on the numbers that get put into the formula. Of course the arrogant physicists completely ignore the personal testimonies of those people who claim to have had encounters with aliens, which of course would make the chance '1' and the formula would then be a waste of time :-).

I suspect this thread is most likely found through googling of MAX7000 or EPM7032, even though that is likely a rather low probability event.

>> datastream of SCOA is 0146-8AAB-F533-6083-3643
More detail how is unscrambled?

So the (machine) code algorithm to do the descrambling is not clear to me, since the code looks like spaghetti However as previously described, it uses a table and essentially takes the 5 (16 bit) words read out on SCO and simply re-arranges all 80 bits into 10 bytes. In other words 80 bits in (5 x 16) to 80 bits out (10 x 8 ). The table is 80 bytes long. The table contains the number 0 to 79 once each.

The table starts 0,5,10,15,20,etc... So bit 0 of the 80 bit input is extracted and then put into the output 80 bit array. The bit 5 of the 80 bit input is extracted and then put into the output 80 bit array, then bit 15, etc.. Once it has done bit 75, the sequence changes to 1,6,11,16 and these bits are extracted from the 80 bit input array and put into the output array. TO help clarify, if you count the number of bits set to '1' in the 80 bit input array, there will be the same number of bits set to '1' in the output array. The order that the bits are deposited in the output array is confusing.

In order to try to understand this algorithm more clearly, I have installed Ghidra. This tool, written and released by the NSA (of all organisations!) onto GitHub, reads in an executable and generates C source code. Of course the C needs some help to become more readable and the end user has to give the functions and variables meaningful names. I am still struggling to get it to work properly. Some things are intuitive and some things are less than obvious. Documentation is not greatly helpful. YouTube videos have been helpful, but none of them deal with old style DOS executables, such as the ALL03 programs. Nevertheless it did a great job untangling the spaghetti of the loops inside loops of the bit re-arranger code, but I still don't understand the shifting and masking.

[migry]

I do not frequent the forum super often, but I thought I could contribute to this thread.  I have laid out the EPM7064-PL84 adapter as the schematic shows on the Benoit website.  There are actually two pages that deal with this adapter, one with better pictures of a prototype version.  However, I do not have a EPM71064 to try this adapter with my ALL-07 programmer.  I can say however, that at least as far as the ICs I have, the EPM7128 does not seem to work with the adapter.  Which would reinforce the idea from previous comments that the pinouts are not the same.  That page is here:  http://matthieu.benoit.free.fr/hilosystem_all-11P2_universal_programmer.htm

That said, I'd be interested in helping with any testing I could do with the ALL-07.  Not exactly an ALL-03, but it is close.

I will say that the ATF1508 schematic works with the ALL-07 and I'm able to program ATF1508s just fine once the POFs have been converted to JEDECs with Atmel's tool.  It would be nice to get these EPM7128 CPLDs working though...  But being from Aliexpress, it's hard to say if they're actually 7128s, or something else that's been rebadged...

Well hello @jdgabbard, welcome to the thread!

The information on the "benoit" website has been invaluable, particularly for me, the complete reverse engineering of the ALL03 schematics, both programmer and ISA card.

I am focusing on the EPM7032, which is the simpler device, as it has less pins to control. It has two SCO output pins. From my limited work looking at the ALL03 7064/096/128 programming software, these 3 devices are all slightly different, and have more SCO output pins, as well as other (unknown) differences.

[Beta_vulgaris]

The information on the "benoit" website has been invaluable, particularly for me, the complete reverse engineering of the ALL03 schematics, both programmer and ISA card.

My rectangular diagram is also based on Benoit's website. The inner ring is CROSS ANNOTATED FROM EPM7064S, so I was wrong.

[migry]

OK I did some work to better understand the unscramble algorithm.

Each bit in the 80 bit input string is translated to a different bit position in the output string. The attached log shows the mapping.
Input words and output bytes have to be ordered correctly to get the correct result.

[Beta_vulgaris]

The inner ring is CROSS ANNOTATED FROM EPM7064S, so I was wrong.

https://www.mqp.com/ad359.htm

[Beta_vulgaris]

Altera Classic devices, PROGRAMMING Pin-outs for reference.

Updated: EP1800, from http://www.emulation.com/pdf/m1965.pdf.

[migry]

I have returned to experimenting with the EPM7032V (3.3V) device from which I could read the device ID (using my Arduino MEGA 2560 + DACs setup).

FYI on this device, VCC is 3.3V . If the Vpp (Vpg) pin is raised above 5.5V, then the pins are put in test mode and the device ID can be read. This voltage is likely much too small to work for programming, but gives an insight into how the device works.

From the pin names in test/programming mode, we can see 7 address bits. Each address selects a small block of 160 bits (20 bytes) of EEPROM. Not all 128 blocks physically exist.

I have a sequence which steps through blocks 0 to 87 and reads back the contents. Another check confirms if all bits are '1' (i.e. erased). These are the 20 byte blocks, there are another 25 or so blocks which are smaller (purpose is unknown). The erase state is all ones.

I have tried to write data to a selected block. I quickly found that it is scrambled, possibly using the same algorithm as the device ID. I am now writing all zeroes. It sort of works. Some blocks become all zeroes, but some still have some bits set. I need to experiment with different levels of Vpp and NTPW pulse lengths.

I also tried to re-create the erase waveforms. For normal block access, the pattern of "00001" repeated has to be shifted in on SDINA and SDINB (as previously described). My guess is that this pattern is decoded to enable reading or writing. For erase a different bit pattern is needed, one which is derived from the device ID. So I tried running the erase sequence and looked at the blocks which I had set to zeroes. Nothing changed. I then tried repeating the command, eventually coding a loop. After about 30 or so iterations, all bits were reset back to all ones! I think that this should only take one pulse of NTPW and not 30, however it is a start.

[abyrvalg]

A bit more from disasm:

Code: [Select]

<<< Program row >>>
set address pins to address
shift the data out on SDINA+SDINB
TM=SBI=1
NTPW=0
delay(Tpg)
NTPW=1
TM=SBI=0


Code: [Select]

<<< Erase >>>
check ID

read row 7C to temp buf

TM=1
BE=BEM=1
NTPW=0
delay(Tbe)
NTPW=1
BE=BEM=0
TM=0

program row 7C from temp buf

read and verify row 7C

row 74 is security fuse (zeroes activate it)

Reprogramming the 7C row after erase looks interesting - erase destroys device ID ??

[abyrvalg]

Studied a bit more: the bit shuffling from POF to raw data and back looks more complicated than hw access. Perhaps it would be easier to just build a DOSBox to run on some board like Raspberry and map programmer pin accesses to GPIO pins?

[migry]

Reprogramming the 7C row after erase looks interesting - erase destroys device ID ??

Yes I agree. After further experimentation, I discovered that I had erased not only the data blocks of the EPM7032V, but also block 0x7C - which contains the device ID. So my previous assumption that this block was protected, was incorrect. I was not able to restore it 

I have attached waveforms taken from emulation of the sequence generated by the ALL03 programmer EPM7032 A70X.EXE file. ALL03 register writes were captured and turned into Verilog code, then simulated as a testbench. The capture comes from the waveform display of the Verilog simulation, courtesy of "ModelSim". NOTE: that timings are not accurate. in that every register write simulates as one cycle. I did extend the two cycles where the NTPW programming pulse is taken low. As @abyrvalg has pointed out the values for Tpg (programming pulse width) and Tbe (bulk erase) are extracted from the block 0x7C and then a table look up is used to convert to milliseconds. TBH I assume that most other timings are not critical, except the width of NTPW.

You will notice that there are three "block read" sequences. They all read the same block address 0x7C, which would appear to be reserved for an ASCII "device ID" code.

1) The first "block read" reads the current "device ID". The data has to be unscrambled in order to retrieve the device ID (ALTERA92). I posted the algorithm in an earlier post. If a valid "device ID" is not found the software bails out with an error.

2) The second "block read" of the same address simply reads the current "device ID", unscrambles it and saves it.

3) The first red oval shows the ERASE signalling. The width of NTPW is important. All EEPROM data is erased, including block 0x7C, and we can assume security fuse settings too.

4) The next sequence is where the old device ID is loaded into the device ready to be re-programmed into block 0x7C. NOTE: the ALL03 will refuse to program any device which does not have a valid "device ID", so this step is very important. Note that the data on SDINA is loaded "in the clear" that is the sequence is ASCII (ALTERA92), for those of you who enjoy decoding serial data bitstreams 

5) The second oval shows the PROGRAM signalling. Again the width of NTPW is important and is not the same as for bulk erase. The data previously shifted in on SDINA and SDINB is programmed into the block selected by address "A".

6) The final "block read" sequence is likely to be for confirmation that block 0x7C was successfully programmed.

[migry]

Studied a bit more: the bit shuffling from POF to raw data and back looks more complicated than hw access. Perhaps it would be easier to just build a DOSBox to run on some board like Raspberry and map programmer pin accesses to GPIO pins?

Yes I have looked at this too, and confirm your findings. There are multiple tables in the initialised data segment which maps from POF bit position to bit position in the SDIN 80 bit programming data stream.

I had hoped that it might be simpler  , but it's quite complicated. Also the 7032 (5V) and 7032V (3.3V) have different tables.

In an earlier post I did mention that I had considered adding code to the DOSBOX-X emulation, to drive external hardware, but on a modern PC I don't see a simple way to do this. Possibly converting ALL03 register writes to serial data and using a USB to serial hardware device is one way to get "physical" data, but then I need to capture the data, process it, before applying to the hardware. I haven't ruled this out. In the past I've found that accessing hardware is never simple, apart from back in the days of the 8088 when it was all simple I/O writes or BIOS calls. It depends on the libraries, and I haven't investigated how this could be done in DOSBOX-X. All I can say is that when I have looked at Unix type libraries and seen IOCTL code, it sent a shiver down my back.

[abyrvalg]

You don't need an x86 machine to run DOSBox. What I'm suggesting is to build a Raspberry Pi version, where you would be able to manipulate GPIOs relatively easily (i.e. using this https://abyz.me.uk/rpi/pigpio/cif.html)

[migry]

A quick update.

I spent a few hours playing with my Arduino based "programmer".

I worked with the EPM7032V, the 3.3V device from which I had been able to unload the device ID. I have had some success writing zeroes to blocks 0,1 and 2, but other blocks remained stubbornly all ones (blank). I was able to erase the device only after multiple attempts to do the erase sequence. During this session I was unable to erase. I started to look at the signals using my Rigol scope. Many signals did not look clean, and Vcc was particularly "nasty". This could be explained by the use of a breadboard and longish connection wires, coupled with a less than perfect ground for the Vss pins. I am driving inputs using the output from the 5V Arduino Mega 2560. Since this is a CMOS device the outputs swing more or less rail to rail (0 -> 5V). Although I was driving the 7032V inputs via 1k resistors, I did not see the inputs clamping to a little over Vcc. This might also have contributed to the flaky behaviour. So I am giving up on this until I get a new breakout PCB made (my first was a bust). BTW when I erased this device, block 0x7C was also erased to all ones, and I was unable to re-program it. I will re-visit when I have the new PCB and I will use proper level translator ICs (74LVC8T245).

Note: many devices have clamping diodes on the input and output pins, possibly there for ESD reasons to catch spikes. With care you can drive 3.3V inputs (which have clamps) from a 5V driver, as long as you limit the current using a resistor. The RC network of resistor and input capacitance will impact slew rate, but for many inputs this is not an issue.

So I swapped over to one of the 5V devices. Vcc in the Arduino sketch was changed to 5V. I ran the code not really expecting it to work, but blow me down, I saw the device ID of ALTERA92 appear. I have no idea why it is now working. The operation of programming was more robust in that it took only one try to program a block and any block I chose appeared to program to zeroes. I tried erase. It didn't work, so I re-tried. This time it worked and what's more the block 0x7C was programmed correctly, but with the wrong device ID, since the sketch still contained the ALTERA93 device ID for the 3.3V device. TBH I'm a little surprised that not only is it working, but it seems much much less flaky.

[abyrvalg]

Great! So the last missing piece is POF to raw shift data conversion. One idea: you can turn your DOSBox-based emulator into converter: track the SDINx shifting, output the last shifted data together with an address when you see an NTPW pulse with SBI=1, capture entire POF this way, then send it block by block to Arduino by some other way (not from DOSBox C code, i.e. via terminal or Python script or whatever), implementing shifting and NTPW pulsing in the Arduino.

Upd: found a general (nothing device-specific there) POF format description: http://ftp.dataio.com/main/manuals/unifam/translation%20formats.pdf (page 10)

[migry]

Upd: found a general (nothing device-specific there) POF format description: http://ftp.dataio.com/main/manuals/unifam/translation%20formats.pdf (page 10)

Yep. I found this a few weeks ago. I made a post on 21st Aug with an attachment of Perl code (I had to give it the .BAS extension in order to upload) to decode Altera POF. This document was a very helpful reference.

The format is actually very simple, it's just repeated blocks of: tag (16 bits); length (32 bits); block of "length" bytes. Some of the blocks of bytes are in simple ASCII format. The largest block with tag 17 (0x11) is the one which contains the data to be programmed. I am pretty sure that the first 'n' bytes (n=12?) of this data block are a (sub)header and do not form part of the data to be programmed. The tags for the ASCII part of the POF can vary in length. In a different posting I looked at the length of the program data tag block and noted that the length differed depending on which version of the EPM7032 you were compiling for. This unfortunately confirmed that I could not used Quartus V13 on my PC to compile Verilog for the MAX7000 devices which triggered the whole project.

When the ALL03 EXE loads any POF, it relocates the data block into a fixed location in memory, and modifies the ASCII data on these type of tags, such that the binary program block is always found at a fixed address in the buffer. This is helpful when looking at CPU trace files, as the reads from this data section can be more easily filtered. Using trace files of CPU operations gives one possible way to determine the mapping, however the trace files get pretty big quickly (Gb++). It may be possible to hack the code to only write out reads/writes in a particular range, or this might even be already supported, IDK. Data reads from the buffer to form the 2 x 80 bit serial stream for SDINA and SDINB are not consecutive.

[abyrvalg]

A script simulating raw to POF conversion as done by AMAX70.exe during read (all those bit tables are ripped from exe).
The output is not a full POF, just the data block as seen by exe. The programming function appears to be doing a reverse mapping using same tables.
A "row" in script's terminology is a full content of a single address (all SDINx-SDOUTx chains together, 2x80 bits), while a "plane" is an array connected to a single SDIN-SDOUT.

[abyrvalg]

Updated version, working both ways

[migry]

A script simulating raw to POF conversion as done by AMAX70.exe during read (all those bit tables are ripped from exe).
The output is not a full POF, just the data block as seen by exe. The programming function appears to be doing a reverse mapping using same tables.
A "row" in script's terminology is a full content of a single address (all SDINx-SDOUTx chains together, 2x80 bits), while a "plane" is an array connected to a single SDIN-SDOUT.

Yep, great work  I recognise the various tables, but had never got to the point of trying to convert them back as C structs (which Ghidra can do).

From a pervious posting (of mine)

Code: [Select]

EPM7032LC44 - data length 1846 (compiled using Max+Plus 9.3)
From your extracted tables

Code: [Select]

EPM7032 = Device("EPM7032", "ALTERA92", [b]14672[/b], 2, 8, BlockTable7032)

14672 / 8 => 1834   

1834 + 12 => 1846 , where 12 are the header bytes of the POF data section. These differ very slightly for different devices. Ties in nicely.

My best guess (based on disasembly)

Code: [Select]

Block(88, 1, 7040, 0, 80, BitTable0),

Each table entry controls the POF to SDINA/B mapping for a block of EEPROM addresses. There are 8 sections (as I call them) or table entries if you prefer. If you examine the blank check waveforms closely you can see "changes". The first 88 blocks are 80 bits on both SDINA and SDINB, but the later sections only program 16 or 8 bits, so appear shortened in the waveform trace.

first column = number of EEPROM blocks (different addresses)  in this section
second column = not sure, but I see you call it plane
third colum =some kind of bit offset into the POF, I see you call it plane_start_bit
fourth column = address of first EEPROM block in this section
fifth column = number of serial bits on SDINA (and B) for each block (80, 16 or 8 )
sixth column = pointer to bit translation/mapping table.

BlockTablePlaneA =bit translation/mapping for data to be shifted in on SDINA
BlockTablePlaneB = ditto ... SDINB

Code: [Select]

Block(88, 0, 0, 0, 80, BitTable0),
The first section (as I called it) starts with address 0x00 and goes to address 87 (0x57). There are 80 bits shifted in on SDINA. Mapping table is BitTable0.
Since the 7032 has 32 macrocells, we might guess that two EEPROM blocks (160 bits) are allocated per macrocell (but this is just a guess).
From the 1993 databook "MAX7000 EPLDs contain from 32 to 256 macrocells that are combined into groups called Logic Array Blocks (LABs).".

Code: [Select]

Block(12, 0, 0, 0x62, 16, BitTable62),
The second block is special in that the start address is 0x62, but the sequence of addresses is not sequential but a secondary table is used (Block62AddrTable). There are 12 blocks in this section and only 16 bits are shifted in on SDINA.

Thank you, there are some very interesting insights from your Python code which I hadn't yet figured out from the disassembly.

[abyrvalg]

Check the __init__ method definition of class Block (and other classes), I gave names to all those numbers already

[migry]

Check the __init__ method definition of class Block (and other classes), I gave names to all those numbers already

Yes, thank you, I did note your variable names.

I am now converting the Python to C, to allow me to print some debugging information, which I can then compare with the instruction trace.

[abyrvalg]

BTW, the programming function in exe builds a used bits mask together with pof to raw bit transfer - another buffer of the same full row size is filled with 0s initially, then bits are set to 1 in same positions where pof bits are being transferred into row write buffer. They use it during verification after each row write: read back a row without converting it back to pof and compare with write buffer, using a mask. So it looks like unused bits could have some unpredictable values (i.e. those remaining 64 bits in rows declared with only 16 used bits).

Just a thought: depending on your relationship with Python, perhaps you don’t need to convert that code to C at all. It is extremely easy to talk to serial ports from Python (search for “pyserial” examples, or I could provide some), you could just transfer the “cooked” row data to/from your Arduino right from read_row/write_row Python functions, staying in a comfort of desktop environment.