Author Topic: Programming (non-JTAG) MAX7000 devices  (Read 31937 times)

0 Members and 1 Guest are viewing this topic.

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Programming (non-JTAG) MAX7000 devices
« on: September 23, 2020, 08:04:47 pm »
Gutted, hit some key combo and lost all my text!!!!  >:(  >:(  >:(   :palm: Now to start over again.

Quite some time ago just as RoHS was coming into force, some bright spark had the idea to throw out all leaded components from the lab (where I worked at the time) into the skip, where it would go straight to landfill. Sort of ironic really. The whole point of RoHS was to prevent this kind of hazardous waste going to landfill!

Luckily I got wind of this and managed to rescue some rails of ICs before they were thrown away. I also got my hands on a couple of EPROM/PAL programmers and an EPROM eraser.

Recently I have got into retro compuiter projects. I have been playing with different FPGAs. I recently designed some 68000 CPU boards and used GALs for the first time. As mentioned in other threads I used WinCUPL without too much bother, and one of my (rescued) programmers supports GALs.

At that time some of the devices rescued were MAX7000 devices. These are older devices that DO NOT support programming via JTAG. These are 5V devices and it would be really useful to use them in some future projects. I have 8 EPM7128s, and lots of EPM7064 and EPM7032's. See attached picture.

Unfortunately my programmer only supports the JTAG version of these devices, and even then requires an adapter board, which I do not have and cannot find any information about.

Now I am sure some of you will be telling me to sell these devices and buy some JTAG compliant versions and use the Altera Byte Blaster. Good advice, but since these devices were FOC I really would like to use them.

I have searched the internet and cannot find any programming information for these (non-JTAG) devices. I realise it is quite common for manufacturers to keep this information confidential, perhaps they make money by selling the algoritms to programmer manufacturers? I did tweet Intel, but they didn't bite, and I got no reply.

What to do?

I could buy a new programmer, but these cost around $1000, so this is of no interest, not for a few devices....perhaps if I didn't already have a programmer.

I did have a crazy idea, but perhaps someone can suggest a better way...

There is an excellent site http://matthieu.benoit.free.fr/ which has loads of information about various EPROM/FLASH/PAL/GAL/MICRO programmers. There is even a few hints about the pins used for programming the MAX7000 devices.

So if I could run some old Win95 or DOS software for one of these old programmers which supports the non-JTAG MAX7000 devices under Linux Wine (?), then perhaps I could trace the I/O writes to whatever parallel ports and use it to figure out which pins of the programmer are been driven. Forgot to mention that for at least for one programmer there are reverse engineered schematics. Does anyone think that this can be made to work? Can you trace I/O writes in some way using Wine?

Anyway time to post before I accidently delete it again
--migry
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: Programming (non-JTAG) MAX7000 devices
« Reply #1 on: September 24, 2020, 07:23:51 pm »
Now I am sure some of you will be telling me to sell these devices and buy some JTAG compliant versions and use the Altera Byte Blaster. Good advice, but since these devices were FOC I really would like to use them.

I thought the ByteBlaster, ByteBlaster II, and ByteBlaster MV did support all versions of the MAX7000, as well as the even older MAX3000 series.
« Last Edit: September 24, 2020, 07:26:06 pm by BrianHG »
 

Online bingo600

  • Super Contributor
  • ***
  • Posts: 1976
  • Country: dk
Re: Programming (non-JTAG) MAX7000 devices
« Reply #2 on: September 24, 2020, 07:42:14 pm »
Wasn't there something about , if jtag was disabled and protection set on a 7000.
Then you'd need a special (expensive) programmer to reset it.

/Bingo
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #3 on: September 24, 2020, 08:40:59 pm »
I just googled and found an Intel(Altera) document.

https://www.thailand.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_bbii.pdf

In a table of supported devices:-

MAX 7000S devices - 5V (this has a JTAG port)
MAX 7000AE (this has a JTAG port) and MAX 3000A (not familiar with this device) devices - 3.3V

The Byte Blaster has only a few pins so cannot do the "parallel" programming, but it does have enough pins for JTAG connections.

Quote
Wasn't there something about , if jtag was disabled and protection set on a 7000.
Then you'd need a special (expensive) programmer to reset it.

Apparently if some kind a security fuse is programmed on the JTAG devices, then the devices cannot be erased by means of the JTAG connector.

I am looking to build in  some way a cheap version of the "expensive" programmer.

--migry
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 11630
  • Country: us
Re: Programming (non-JTAG) MAX7000 devices
« Reply #4 on: September 24, 2020, 08:42:23 pm »
They support JTAG and could be programmed with the bit blaster, byte blaster and master blaster.

See the following data sheet:
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ds/archives/m7000.pdf

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 11630
  • Country: us
Re: Programming (non-JTAG) MAX7000 devices
« Reply #5 on: September 24, 2020, 08:48:05 pm »
The security bit doesn't prevent reprogramming.  Actually, that's how you clear it.   I started out making my own programmer.  I think they published the design for one of their early programmers.     

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 11630
  • Country: us
Re: Programming (non-JTAG) MAX7000 devices
« Reply #6 on: September 24, 2020, 08:49:53 pm »

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #7 on: September 24, 2020, 10:02:20 pm »
My devices are NOT the "S" (5V) or "AE" (3.3V) types.

My devices are older MAX7000 which do NOT have JTAG.

In front of me I have an EPM7032LC44-10 and a EPM7032VLC44-12 (I think that this is a 3.3V device - but can't recall).

Quote
The security bit doesn't prevent reprogramming.  Actually, that's how you clear it.   I started out making my own programmer.  I think they published the design for one of their early programmers.

While googling I found several postings saying that JTAG parts which had the security bit set could not be re-programmed using JTAG, because the security bit had to be reset using a "parallel" type programmer. I took this are read. In any case my parts are not JTAG so I need to make some kind of parallel programmer.

I discovered that my devices did not have JTAG having built a board and hooked up a USB Blaster clone, and found that it did nothing. The datasheet revealed to my disappointment that my devices did not have JTAG.

You design and references will be helpful for those who already have or who buy the JTAG compatiable MAX7000 devices.

--migry
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 11630
  • Country: us
Re: Programming (non-JTAG) MAX7000 devices
« Reply #8 on: September 24, 2020, 10:22:00 pm »
I'll check my stash of old parts and databooks and get back with you. 

Offline NivagSwerdna

  • Super Contributor
  • ***
  • Posts: 2495
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #9 on: September 24, 2020, 10:54:33 pm »
Not long ago I was planning to use some of these devices and bought an UP2 board and ByteBlaster.  Worked fine.

https://mil.ufl.edu/4712/altera_UP_board_info.html

In the end I don't think I will use this part because all the ones I got from China seem to be fake.   :(
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #10 on: September 24, 2020, 11:30:17 pm »
Not long ago I was planning to use some of these devices and bought an UP2 board and ByteBlaster.  Worked fine.

In the end I don't think I will use this part because all the ones I got from China seem to be fake.    :(

I followed the link and found information about the JTAG programmers, which I am already familiar with. They unfortunately DO NOT program the parts which I have :-(

Are you aware that the MAX7000 devices come in several different flavours?
Some are 5V and some are 3.3V
The newer ones can be programmed over JTAG (a simple industry standard interface and protocol widely used to program and test ICs) using a Byte Blaster.

BTW I use JTAG a lot in my work, so have a deep understanding of this interface and its use.

The older ones CANNOT be programmed using JTAG as the internal circuity does not exist inside the older parts. They require a "parallel" programmer to control a number of pins and a high voltage must be applied to one pin, sort of like an EPROM programmer. From the information I have been able to find it appears that the parts have one or more shift registers and some other miscellaneous pins whose purpose I do not understand. Intel/Altera are keeping this information confidential.

Perhaps you bought the NON JTAG devices, which CANNOT be programmed using the ByteBlaster which you have. Could it be that the devices are not actualy fake, but are simply not the JTAG type? Can you post the full device ID or post a picture of the top of one of your devices? This will allow us to confirm - or not!

--migry
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 11630
  • Country: us
Re: Programming (non-JTAG) MAX7000 devices
« Reply #11 on: September 25, 2020, 01:29:52 am »
This is going way back.   It appears you need the Master Programming Unit PL-MPU with the LP6 ISA card.   I have not seen one of these in many years.   

http://www.ece.ualberta.ca/~elliott/ee552/AlteraDoc/maxplus2_getting_started.pdf

https://www.ebay.com/itm/ALTERA-MPU-MASTER-PROGRAMMING-UNIT-Full-PL-ASAP2-kit-LP6-programming-card/114416535210?hash=item1aa3c1c6aa:g:R5MAAOSwmcJd8Cvp

Offline NivagSwerdna

  • Super Contributor
  • ***
  • Posts: 2495
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #12 on: September 25, 2020, 09:55:34 am »
I'm sure there are many variants... this is the combo that worked for me...

 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #13 on: September 25, 2020, 11:30:54 am »
I'm sure there are many variants... this is the combo that worked for me...


Just to highlight to any readers (and please read the SUBJECT text) that I know that MAX7000  "S" devices CAN be programmed with the USB blaster shown, however MY devices are not the "S" variant and DO NOT HAVE JTAG circuitry.

The device in the picture is marked EPM7128SLC84-S, so it is clearly a "S" device and is therefore capable of being programmed using the USB Blaster clone shown in the picture, because the "S" devices DO have JTAG internal circuitry.

My problem, for which I search a solution, is that I need to program devices which I have, which are NOT "S" devices and cannot be programmed in the way your picture shows.

Neverthess for anyone who has the "S" type parts, you have confirmed that the common and cheap USB Blaster clone can program these (the "S") devices.

--migry
« Last Edit: September 25, 2020, 11:32:48 am by migry »
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 11630
  • Country: us
Re: Programming (non-JTAG) MAX7000 devices
« Reply #14 on: September 25, 2020, 11:44:45 am »
Another option may be a generic programmer.  I have an old EETOOLS programmer that supports both devices.  It requires two adaptors which would cost about $250, if you could find them.  Have you checked to see if any of the new low cost programmers support it? 

Some of the older parts I used also did not use JTAG but rather the passive serial mode, which could still be programmed using their more common programmers. That doesn't help you except that the lack of JTAG isn't really a good indicator, so much at the part numbers.   

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #15 on: September 25, 2020, 11:47:09 am »
This is going way back.   It appears you need the Master Programming Unit PL-MPU with the LP6 ISA card.   I have not seen one of these in many years.   

http://www.ece.ualberta.ca/~elliott/ee552/AlteraDoc/maxplus2_getting_started.pdf

https://www.ebay.com/itm/ALTERA-MPU-MASTER-PROGRAMMING-UNIT-Full-PL-ASAP2-kit-LP6-programming-card/114416535210?hash=item1aa3c1c6aa:g:R5MAAOSwmcJd8Cvp

OK @joeqsmith, thank you for the pointers.

I do have the physical MAX7000 databooks (remember them?), but I do not have the MAX-PLUS II databook, now downloaded from your link to the PDF.

I actually intend to use Quartus to generate the code for the MAX7000 devices (if I can solve the programming problem) using a POF compiled from Verilog.

I was also aware of the old programmer type shown in the Ebay link, however I do not want to spend $2000 to buy an old ISA card. H-ll I don't even have any old ISA motherboards anymore, they were all thrown out long ago (and ironically and nowe worth lots of $$$).

There are still (multi device) programmers which can be bought new and which do support these MAX7000 devices (JTAG and non-JTAG modes of programming), but they cost at least $1000.  As I mentioned, if I didn't already have a flexible EPROM/FLASH/EEPROM/MICRO programmer (FYI - LV48 Speedmaster), then I would have considered buying such an expensive programmer. I have been using the LV48 quite often recently to program EPROMS and GALs. It connects to the parallel port of my old XP machine and the DOS based GUI runs under Win-XP without problems.

--migry
 

Offline NivagSwerdna

  • Super Contributor
  • ***
  • Posts: 2495
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #16 on: September 25, 2020, 01:05:31 pm »
I have 8 EPM7128s
Apologies I read s as S.  8)
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #17 on: September 25, 2020, 01:46:32 pm »
I have 8 EPM7128s
Apologies I read s as S.  8)

Sorry! My bad! The "EPM7218s" was a plural. I didn't even think that this might be mis-read! I should have written "I have 8 EPM7128's".

--migry
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Programming (non-JTAG) MAX7000 devices
« Reply #18 on: September 27, 2020, 09:36:24 am »
Did you find any modern development software for these?  I also have a bunch, as a result of dumpster-diving.(mine were in a proper w-waste bin, at least.)
You can find the old Quartus v9.1 Altera software that is supposedly the last official release that supports these, but ... it look painfully ancient :-(
See also  https://hackaday.com/2016/02/04/a-better-way-to-plug-a-cpld-into-a-breadboard/
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #19 on: September 27, 2020, 01:50:05 pm »
Did you find any modern development software for these?  I also have a bunch, as a result of dumpster-diving.(mine were in a proper w-waste bin, at least.)
You can find the old Quartus v9.1 Altera software that is supposedly the last official release that supports these, but ... it look painfully ancient :-(

Thank you for this information.

I have Quartus 13.0sp1 loaded on my Win10 machine, so I tried to create a simple counter design project. I found that there were several MAX7000 EPM7032 devices which could be selected, but I noted that these were all the JTAG types. I was able to create a POF, but I am now guessing that this POF uses the JTAG serial mode of programming, so will be of no use to me.

So I then tried to find the old Quartus v9.1 on the Intel site. Well guess what - you can select it, but cannot download it. Thanks Intel! Thanks for NOT supporting thje maker community or anyone using old parts!

I tried googling, but I was unable to find an this old version anywhere else.

So @westfw (and any others) do you still have the install .EXE for this old version of Quartus?

--migry
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #20 on: September 27, 2020, 02:16:46 pm »
So I initially mentioned a possible method to find a way to program these old non-JTAG devices.

So I was intrigued by the amazing information on the http://matthieu.benoit.free.fr website.

There is a page dedicated to an old Hi-Lo programmer called the ALL03, which appears to be able to program the  non-JTAG EPM7032 (and similar) devices. It even shows the schematic of the adapter which is needed, but amazingly it gives pin names of what appear to be the programming pins for this device (SDINA, SDOUTA, BE, BEM, SCK, SK, ...etc...). I can find no reference to these names elsewhere. It also shows which ALL03 channels each pin of the EPM7032 connects to. There is also the specific .EXE which is needed to program these devices. It is a very straight forward design of programmer. It needs an ISA card which uses only 2 addresses. Inside the programmer lots of 74LS273 8-bit latches are used to latch the data from the PC ISA card which in turn allow pins to be driven and read back and voltages such as Vcc and Vpp to be connected to appropriate pins. There are 3 DACs which generate 3 sets of high voltages (Vcc, Vpp and other).

So since I had DOSBOX on my PC I tried running the software. It ran! The GUI was the old DOS type character graphics, which to be honest allowed really nice (low res) GUIs to be constructed, thanks to the IBM PC character set.

So I wondered if I could modify DOSBOX to allow me to trace writes to and reads from the two I/O addresses.

To cut a long story short, I downloaded the sources for DOSBOX-X onto my Ubuntu Linux VM, and was able to compile and run DOSBOX-X under Linux with relatively few problems. For other software you download, configure and compile under Linux I have had lots of problems. So kudos to the DOSBOX-X team.

I spent a good part of one day in the src/hardware folder looking at the various I/O devices (mainly sound cards) which arre supported. I started to get an idea of how to intercept I/O writes and reads. I then copied the MPU401.cpp module and hacked it around to give a skeleton to log writes and reads to the two ALL03 ISA card ports. I needed to modify the Makefile and create a .Po file (no idea what this is - I just copied the mpu401.Po file!). Several hours of debugging later... I run the modified DOSBOX-X, fire up the MAX7000 .EXE (A70X.EXE), do some commands and look at the log. First problem was that the software was not seeing the programmer, however it was still apparently writing to the various registers. The programmer implements a PAL to decode the addresses of the various registers, but also contains a 4 bit state machine, the output of which can be read by the software, and this is seen in the logs. So again thanks to the same website, I found the PAL equations and added emulation of the PAL into the software. Finally no more complaints by the programming software. I am now emulating the SAC-201 PC ISA interface card, the various programmer I/O control registers, and the programmer PAL. Apparently the PAL is used to identify the prrogrammer hardware type, but might also have been some crude form of protection.

So now I can run the A70X.EXE software for the MAX7000 and generate a log. Unfortunately the pins used did not match those expected from the EPM7032 adapter pinout. I was aware that this version of software, while allowing different members of the family to be selected, did not have a choice for the EPM7032. More googling later and I found a website suggesting a different .EXE program name. More googling and I could not find it, until I looked in the folder of software downloaded from the above site and I found AMAX70.EXE . I now loaded the DOSBOX-X (with SAC-201 and ALL03 emulation) software and generated some new trace logs. This time the Vcc and Vpp pins mapped perfectly, and I was able to see toggling on the SCK pin and changes on the SDINA and SDINB pins (presumably serial data in). The software then tries to read back a serial value, which of course fails.

I have attached the log file with annotated EPM7032 pins.

More soon...

--migry
« Last Edit: September 27, 2020, 02:20:44 pm by migry »
 
The following users thanked this post: Rasz, Someone

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 823
  • Country: es
Re: Programming (non-JTAG) MAX7000 devices
« Reply #21 on: September 27, 2020, 05:26:27 pm »
What if you “just” route (in software) the pin accesses to some kind of GPIOs attached to a real MAX7k now?
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #22 on: September 27, 2020, 10:14:55 pm »
What if you “just” route (in software) the pin accesses to some kind of GPIOs attached to a real MAX7k now?

Aha! I also had a similar idea. Bear in mind that DOSBOX-X is already emulating not only software but hardware too. having said that it can read joysticks, so has a way to speak to the outside world. Otherwise I don't know how I would get DOSBOX-X to speak to real physical hardware (parallel port?).

For the time being I intend to simply record the stimulus as text (as shown) and then replay on an Arduino. There's stilla long way to go!

--migry
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #23 on: September 28, 2020, 09:15:05 pm »
Just to confirm that I am getting the expected values out of the DOSBOX-X emulator in the log file (as previously attached), I have written an emulator for a simple EPROM device. I chose the AMD Am2716. At (simulated) reset, the contents of the EPROM, defined as a byte array, are all set to 0xFF, i.e. the normal EPROM erased value.

After a few iterations I managed to get it to work.

This time in DOSBOX-X I run the main ALL03 programmer software, ACCESS.EXE (there might be other versions and names). I then select EPROM, then AMD, then Am2716 device, and the software loads and runs another module (called EPP512.EXE) which appears to be the EPROM specific software (just like AMAX70.EXE is the Altera EPM7032 specific module). I examine the buffer (start only) and see all zeroes. I then load the buffer from the emulated 2716. I then check the buffer and see that the values are now all 0xff. I then edit the first 16 bytes to 0x55. I then select program and ... success! What this means is that the value being programmed is used to update the array so when the EPROM is read back it has the new programmed value. I was able to examine the programmer pin log file to confirm what had happened. First good thing is that all the pins which toggle map correctly to the EPROM pins, i.e. pins 9 to 20 of the programmer (which correspond to pins 1 to 12 of the EPROM) are the ones which toggle, and I can see the address count. I note that when programming the whole EPROM is read and only the bytes which are not 0xff, are programmed (I don't know if this check is more intellegent - as long as an EPROM bit needed to be  zero is one, it can be changed, but 0 cannot be changed to a 1). I thought that Vpp was pulsed for each address, but actually it remains high during programming and readback of all locations. From earlier work I know that after applying the programming conditions (CE and OE) the EPROM is read back, and if the wanted value is not found, another attempt is made. Now after only the first attempt, the emulated EPROM has the right value, but interestingly, the programming software gives it one more "write" at the same address (just to be certain that this EPROM address is "firmly" programmed and not just marginal).

--migry
 
The following users thanked this post: Rasz, YetAnotherTechie

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #24 on: September 28, 2020, 09:36:01 pm »
So I have a log of the EPM7032 sequence which the ALL03 programmer applies to the device to confirm its ID, which of course it fails to do.

So I have wired up a perf board with a PLCC44 socket, where each pins comes to a row of 44 turned pin header for connection. I then found a 5V Arduino, a Nano, which has more or less the required number of pins.

Yesterday. I was able to code the data from the previously posted file into the Arduino sketch in order to generate the waveforms that would be applied by the ALL03 programmer. I then hooked all the programming pins (thanks once again to the site http://matthieu.benoit.free.fr/ ) to pins of the Arduino. Turns out that "analogue" pins named A0 to A5 can be used as digital, but not A6 and A7 - guess which pin I used for a critical signal! I was able to confirm that when the Vpp pin was taken over about 11V the chip went into test mode and previously clamped shift in data now had no contention and was the right level. I scoped the 2 suspected shift out pins: SDOUTA and SDOUTB, and they had identical waveforms which were defintely the EPM7032 responding to the stimulus.

Today. I wanted to properly capture the response. I didn't quite have enough pins, so I moved some stuff around. Mistake  :( . When I raised Vpp from 5V to 12V (which was OK yesterday) I was getting current clamping on my PSU, and a burning smell  :-DD . After some messing around the lights (of  the Arduino went out). Oops! Turns out the min hub (to which the Nano was plugged on) no longer was lit. When tested elsewhere the min hub appeared to light up, and the Nano too. The hub connected to the back of my Dell monitor. The EPM7032 was very hot, and clearly I had blown it up. I eventually figured out that you must ONLY connect Vpp when a number of other inputs are grounded, and appear to put the device into a state where Vpp does not destroy the chip, however I am not 100% sure which pins are the critical ones.

So I ripped out all the wires from the Nano to the EPM7032 board connector and started again. After the usual debugging and discovery of swapped wires, I got the same waveforms on SDOUTA and SDOUTB as yesterday. I used my Rigol scope logic analyser to capture the waveforms (attached).

I also confrmed which pins become outputs and which inputs when Vpp puts the EPM7032 into "programming" mode.

NTPW - input
MTIN - input
SCK - input
SDINA - input
BE - input
BEM - input
SS - input
SBI - input
TM - input
A0 to A6 - input
SDINB - input
SK - input

Vpp - needs around 12V to put the device into test mode (but ONLY do this if the other pins have been set!)

SDOUTA - output
SDOUTB - output
SCOA - output
SCOB - output

--migry
 
The following users thanked this post: Rasz

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #25 on: September 28, 2020, 09:45:21 pm »
Question.

Can the JTAG type "S"/"AE" devices (e.g. EPM7032S) be programmed in "parallel" mode, i.e. not using the JTAG? In other words did Altera make the newer "S" devices backwards compatible with the older devices?

Actually it is sort of ironic. To implement JTAG you need quite a few flip-flops (for state machine, instruction register, data registers), however the main EPM7032 device only has 16 macrocells, therefore with only 16 flip-flops (as far as I understand).

@bingo wrote
Quote
Wasn't there something about , if jtag was disabled and protection set on a 7000.
Then you'd need a special (expensive) programmer to reset it.

@joeqsmith wrote
Quote
The security bit doesn't prevent reprogramming.  Actually, that's how you clear it.   I started out making my own programmer.  I think they published the design for one of their early programmers.     

I wonder if someone who knows for sure can confirm that - if the security bit of a "S" type device has been set, can the device be erased by means of JTAG only, or as @bingo beleves, do you need a "parallel" mode type programmer to clear the security bit and erase the device?

--migry
« Last Edit: September 28, 2020, 09:49:16 pm by migry »
 
The following users thanked this post: edevaldo

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 823
  • Country: es
Re: Programming (non-JTAG) MAX7000 devices
« Reply #26 on: September 29, 2020, 04:42:38 pm »
My idea was to make DOSBOX controlling the pins of a real MAX7k. I.e. you connect an Arduino between the PC’s serial port and the MAX, write a sketch that listens to commands like "set pin X to Y state", "get pin X state" and send these commands from DOSBOX’s IO port handler, bridging the programmer exe to your MAX and letting it doing it’s job directly.
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #27 on: September 30, 2020, 01:20:25 am »
My idea was to make DOSBOX controlling the pins of a real MAX7k. I.e. you connect an Arduino between the PC’s serial port and the MAX, write a sketch that listens to commands like "set pin X to Y state", "get pin X state" and send these commands from DOSBOX’s IO port handler, bridging the programmer exe to your MAX and letting it doing it’s job directly.

Hi @abyrvalg, I did understand what you were suggesting, and I did briefly consider this. I was incorrect in my previous reply, in that of course it is possible from the DOSBOX-X (modified) source code to write to real hardware (I just got confused), if I can figure out the correct library calls. Since DOSBOX-X is compiled under Linux with gcc, then I guess it should be possible to write to the serial port. I have an old Maplin kit for a ISA I/O card (un-built) which uses a INS8255. This would have been perfect. No good for my modern PC with PCIe ! Certainly I could devise a protocol and send serial data to a hardware COM port, then use an Arduino to capture this data and re-assemble the parallel packets. The ALL03 programmer is built from 8 bit chunks, so that maps nicely. I would need a couple of DACs for Vcc and Vpp, however I possibly could get away with simply switching these supllies on and off. I do see in the programmer I/O logs that Vpp is ramped slowly up and (later) down again using the DAC. Vcc is simply enabled on or off, having been previously programmed to the right level. The ALL03 can route 3 different high voltage supplies to nearly all pins (they didn't connect to all pins to save some costs I assume). If I use the "serial" Arduino method or the "parallel" stand-alone method, Vcc and Vpp will be handled the same way. The benefit of the way you suggest is that the timing information is at least "maintained" from the original software. With my method of logging I have no idea (currently) how long between writes to the programmer registers, and I think that some "pulses" may have minimum or critial lengths.

--migry
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: Programming (non-JTAG) MAX7000 devices
« Reply #28 on: October 26, 2020, 03:57:56 pm »
Did you get further with your efforts ?
I ask because I have a stack of EPM7128S that have the security fuse programmed.
 

Offline MadTux

  • Frequent Contributor
  • **
  • Posts: 785
Re: Programming (non-JTAG) MAX7000 devices
« Reply #29 on: October 26, 2020, 05:07:43 pm »
Actually it is sort of ironic. To implement JTAG you need quite a few flip-flops (for state machine, instruction register, data registers), however the main EPM7032 device only has 16 macrocells, therefore with only 16 flip-flops (as far as I understand).
As fas as I know, EPM7032 should have 32Flipflops, just like as with XC95xx, xx is the number of flipflops available. 32FFs are very few for anything with clock, the small CPLDs are IMO better suited to replace lots of 74xx AND/OR.... combinatorial logic.

BTW anyone who has downloaded Quartus II 9.0 for linux, before it was taken offline?
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #30 on: October 28, 2020, 04:32:32 pm »
Yes I did make a little more progress, but then decided to move onto something else, as a form of break, but intending to re-visit later. I do have 10 EPM7032S JTAG devices on order from China, and assuming that they are not fake  ;D I will be able to program them using my Altera USB Blaster clone, in order to try various actions on my hardware.

My new hardware now has two DAC channels, one of which is required for Vpp. 12V on this pin puts the device into test mode and reconfigures all the special pins.

My new hardware is based around an Arduino MEGA2560. I have a script, into which I hard code sequences which have been learnt by reverse engineering the DOSBOX + ALL03 programmer hardware and software. The EPM7032 programming software (for the ALL03) gives me traces of certain commands. I see common sequences on groups of pins. Certain commands do not work as the software does not see the expected response from the emulated ALL03 programmer and emulated EPM7032 device. Blank check for example is still reporting a failure even though I applied the waveforms using my hardware to a blank device. Probably my emulated "blank" EPM7032 needs some minor tweaks.

Some commands such as erase seem to have simpler sequences, but need more pins to be toggled.

I finally found the special test pin names for the 44 pins EPM7064. There are more pins used for programming on this device, some with new names as compared to the 44 pin EPM7032. I do not know the pinout of the test pins for the EPM7128. This would need someone with an adapter for the ALL03 programmer to reverse engineer the adapter to 40 pin socket. With this information I could use the MAX7000 version of the ALL03 programmer to work out which waveforms to apply to which pins.

I have added a JPG of the list of test pin names for the EPM7032 and EPM7064.

If I or someone can find the same list for the EPM7128 then I might be able to help (in the longer term).
« Last Edit: October 28, 2020, 04:40:38 pm by migry »
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #31 on: October 28, 2020, 04:38:54 pm »
As fas as I know, EPM7032 should have 32Flipflops, just like as with XC95xx, xx is the number of flipflops available. 32FFs are very few for anything with clock, the small CPLDs are IMO better suited to replace lots of 74xx AND/OR.... combinatorial logic.

My point was that adding the extra circuitry to convert the non-JTAG device to the new JTAG equivalent would add many more extra flops, as compared to the 32 which form the basis of the device as "seen" by the end user.
 
To implement JTAG you need at least 4 flops for the state machine, one for the re-timing of TDO, at least 4 for the instruction register, 32 flops if you implement the Device ID register, plus any addition flops to tie into the old programming circuitry.

From my experiments on the non-JTAG EPM7032 there are at least two shift registers each 10 bits long (so this requires 20 flops). So even in the non-JTAG design there are more "hidden" flops needed for programming, than the 32 which are used by the end user.

[Edit: I originally said 16 user flops and not 32!]
« Last Edit: October 29, 2020, 12:41:33 am by migry »
 

Online bingo600

  • Super Contributor
  • ***
  • Posts: 1976
  • Country: dk
Re: Programming (non-JTAG) MAX7000 devices
« Reply #32 on: October 28, 2020, 05:18:42 pm »
@migry

That is some serious effort, put into reviving some old devices.
I hope you have quite a few.

Interesting read.

Thanx for sharing  :-+

/Bingo
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: Programming (non-JTAG) MAX7000 devices
« Reply #33 on: October 29, 2020, 02:21:50 pm »
Quote
I do have 10 EPM7032S JTAG devices on order from China

Mine also come from China, fuse locked :(, (because I cannot read/program them with a USB Blaster, nothing found on JTAG). Maybe one of the pins is a JTAG enable pin...
Firstly I saw that they came packaged in a reel and I thought maybe they are NOS or so (very naive from my part). After closer inspection... all chips have different date codes !
I also bought several XC9572XL-vq64, those work great though.
« Last Edit: October 29, 2020, 02:24:09 pm by ale500 »
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #34 on: October 29, 2020, 03:03:13 pm »
Mine also come from China, fuse locked :(, (because I cannot read/program them with a USB Blaster, nothing found on JTAG). Maybe one of the pins is a JTAG enable pin...

My limited understanding, with assumptions, is that for the JTAG devices, if you utilise the I/O's shared with the JTAG pins as user I/O, then of course the JTAG has to be disabled using some fuse. These parts cannot therefore be re-programmed using JTAG. If you do not use the JTAG shared I/O as user pins, then the JTAG remains enabled, allowing re-programisation. Perhaps the 12V on the Vpp re-enables the JTAG I/O. This is something which I will investigate in the future.

In IC design, particularly for low pin count chips, where JTAG is used internally for chip scan test, do you dedicate 4 (or 5) pins to JTAG, so making less pins available for user I/O, or do you share pins and add some mechanism (normally a single TEST pin) to enable JTAG and allow chip scan test? Altera have given maximum flexibility here, and we might assume that the fuse to enable/disable JTAG is "new", i.e. it is not on the non-JTAG devices. We can select to use fewer I/O and have JTAG always enabled, or use maximum I/O but lose JTAG programmability once the chip is programmed.

Having ordered cheap parts from China in the past: Flash ROMs and MC68000 DIL and PLCC, I am now aware of the problem of chip recovery and re-marking.

The MC68000 DILs were 8MHz devices, remarked as 16MHz devices. I found out simply by removing the fake marking with IPA, which clearly revealed the original markings.

The MC68000 PLCC did not work at all. Suspiciously they all had the same date-code markings, but the packages all differed slightly with respect to markings on the bottom and dimples. They were obviously remarked, possibly not even MC68000s. I got a full refund from the seller, who I will avoid in future.

Of the 4 Flash ROMs, 2 worked and 2 did not program. All had identical markings and date code, so obviously re-marked, but the markings did not come off with IPA. My programmer essentially rejected the devices saying that the manufacturer ID was not Intel. I wondered whether the 2 devices which did not program were from another manufacturer, but I could not get them to program when I tried to select different chip vendors. I got a refund for the 2 "broken" devices. Whether I can trust the speed rating of the 2 "good" (and remarked) devices is unclear.

Clearly all the above devices were re-claimed and were not NOS.

BTW I have absolutely no issue with chip recovery, but I simply want the sellers to be honest. Some sellers might buy chips from the recovery companies in good faith, and there will be good and bad recovery companies. What really p*****s me off is when the chips are re-marked. What a waste of time. Given the low selling cost of the chips, why bother?

So I will be interested to find out if the EPM7032S devices are genuine parts and if so, are they locked.
 
The following users thanked this post: Rasz

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Programming (non-JTAG) MAX7000 devices
« Reply #35 on: October 30, 2020, 12:50:54 am »
Quote
the extra circuitry to convert the non-JTAG device to the new JTAG equivalent would add many more extra flops
flip-flops in general are not "expensive", and the flipflops to make up the shift registers for basic JTAG access can be especially trivial (and may in fact be very similar to what is already there for the non-JTAG versions.)It's the fully-connected, fully-configurable flip-flops and their associated control logic and routing that make up one of the "Macrocells" that make them costly.(an SRAM is essentially flipflops, and you can get a million of them on a very cheap chip.  REAL old-timers will remember that shift registers were used for microprocessor storage back when SRAM was "too expensive.")

 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #36 on: October 30, 2020, 01:25:49 pm »
My EPM7032S parts arrived. 10 off. All have identical markings on the top, i.e. same date code. However on the bottom almost all parts are different, which absolutely confirms that they are NOT from the same lot, and therefore must have been remarked.  >:(  >:(  >:(

Note: manufacturers use lot numbers and date codes to track "sets" of devices throughout the manufacturing process. Parts marked with the same date code are very likely to have come from the same wafers. They would have gone through assembly as a group and would have been processed by the same machines. I am unfamiliar with the machines which put the die in the plastic packages, but you should expect all devices with the same lot code to have used the same machine and therefore any package markings (top and bottom) and dimples should be identical.


I will now test them to see if they are even EPM7032S devices.
« Last Edit: October 30, 2020, 01:56:21 pm by migry »
 
The following users thanked this post: Rasz

Offline TomS_

  • Frequent Contributor
  • **
  • Posts: 834
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #37 on: October 30, 2020, 09:06:48 pm »
Altera EPM devices and Atmel ATF devices are very similar it seems, so much so that Atmel released a tool to convert Altera .pof files to .jed so you can program a design into one of their own parts.

If you use the JTAG pins as IOs, they can be re-enabled for programming by applying 12V to the OE pin.

Presumably it would be similar on the Altera parts.

How to clear the security bit is still to be discovered.
 

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2616
  • Country: 00
    • My random blog.
Re: Programming (non-JTAG) MAX7000 devices
« Reply #38 on: November 02, 2020, 03:38:25 pm »
This https://hackaday.com/2020/10/16/isastm-runs-vintage-cards-over-usb/ might give you ideas about linking emulator with real world. Manawyrm used PCem and USB CDC-ACM serial connection to STM32. https://www.vogons.org/viewtopic.php?p=902486#p902486
Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #39 on: November 03, 2020, 02:09:29 pm »
Hi @Rasz thanks for the pointer to an interesting read.

I might just re-visit the idea of sending register writes from DosboxX via serial to the Arduino. I think that it might speed things up.

My only concern is that using serial comms under Linux appears to be unnecessarily complicated, what with all these IOCTLs and function calls. On the Arduino (and small development systems) serial comms is a piece of p--s, but under Windows and Linux all the additional wrapping seems to overcomplicate things (IMO). Over the years I've written lots of serial comms code for microcontroller and uPs in machine code, without much of a problem. As soon as I even try to find example code for Windows and Linux I can't find something nice and easy to understand.
 
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #40 on: November 04, 2020, 03:21:47 pm »
Update.

Using my homebrew perf board set-up shown below, I can connect up a cheap Chinese USB Blaster clone to the EPM7032S devices  in PLCC 44 pin.

| was pleasantly surprised to find out that all devices respond to JTAG and are blank. I must admit this was somewhat of a surprise, as I am still in no doubt that all 10 parts have been remarked. Some parts have a lighter colour of plastic and you can see where very black paint has been painted on top.

Next I tried to program a part with a simple 24 bit counter. I was using Quartus 13.1
I had the usual issue that it selects pin assignments for you first time around, and moved them to known adjacent pin positions. The strange this is that I see square waves on some pins, but not the ones which I chose. I have re-compiled several times in case something was out of date. The part programs and verifies correctly. I tried a second part and it behaved in the same way. I see the xtal divided output from the counter, but 1) on the wrong pins 2) lower frequencies on pins which I have not assigned (perhaps this is side effect of using macrocells?).

Now scratching my head.
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #41 on: November 04, 2020, 03:42:06 pm »
Update #2.

Silly me  :palm: . It's all OK!

I changed the "Unused Pins" option in "Device->Device and Pin Settings" from "As output driving and unspecified signal" to "As input tri-stated", and quickly saw that I had wired up the wrong part of the counter, so that I was outputting very low frequency square waves on the pins of interest.  |O

I updated the Verilog code, re-programmed, and the EPM7032S is now working as expected, outputting the correct square waves from dividing the xtal on the expected pins. Brilliant!
 

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2616
  • Country: 00
    • My random blog.
Re: Programming (non-JTAG) MAX7000 devices
« Reply #42 on: November 04, 2020, 05:04:33 pm »
under linux talking serial is just opening file descriptor and writing/reading to it

> cheap Chinese USB Blaster clone

fx2lp
https://www.newioit.com.au/archives/159

https://github.com/Wei1234c/FX2LP
This sems to have already implemented firmware for random GPIO access + glue python code

« Last Edit: November 04, 2020, 06:21:15 pm by Rasz »
Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: Programming (non-JTAG) MAX7000 devices
« Reply #43 on: November 04, 2020, 05:58:42 pm »
Oh, you had more luck than I had :+1:

The ATF parts look similar at least they have the same pinout for the PLCC84 variants.  I found a forum post on the forums.6502.org about applying 12 V to OE1 to enable JTAG, but no docu as of yet. I'll try anyways :).  Thanks for the tip !
 

Offline TomS_

  • Frequent Contributor
  • **
  • Posts: 834
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #44 on: November 05, 2020, 07:56:47 am »
Pinout is also the same for the 44 pin PLCC package too.
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: Programming (non-JTAG) MAX7000 devices
« Reply #45 on: November 05, 2020, 01:15:52 pm »
It seems that I have no luck with this device. (EPM7128SCL84)

1. I apply 12 V at OE1 (Pin 84).
2. Apply 5 V at VCCINT/VCCIOs.
3. Send JTAG command (blank check, verify, program). I see that the clock does not go to 0V (Transitions between 5 V and 4.5 V), as if the chip were driving high on TCK.
  I see No output on TDO.

See trace: CH1 TCK, CH2 : TDI

2nd test:

1. Apply 5 V at VCCINT/VCCIOs.
2. I apply 12 V at OE1 (Pin 84).
3. Send JTAG command (blank check, verify, program). I see that the clock does not go to 0V (Transitions between 5 V and 2.5 V), as if the chip were driving high on TCK.
  I see No output on TDO.

 :(

I tested the GND pins and they seem to be at the right locations: i.e. both internal GNDs are connected as well as the IO GND, so I assume it is a EPM7128.

Something is missing, some other pins may need to be grounded or so.
« Last Edit: November 05, 2020, 01:22:16 pm by ale500 »
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #46 on: November 05, 2020, 01:26:51 pm »
@ale500 - where did you get your devices from?

During my many searches I have seen numerous messages from people wanting to clear the security fuse of the EPM7128S.

On the EPM7032 I apply 12V to the OE pin which is Vpp. I think it's a pretty fair guess that OE on the 7128 will also be Vpp, but... until we get someone who has an adapter for the ALL03 programmer, we can't be 100% sure.

 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: Programming (non-JTAG) MAX7000 devices
« Reply #47 on: November 06, 2020, 05:34:10 am »
I got them from aliexpress: shenzhenYida Store.... I'll try to buy another batch from some other store...

To which OE pin do you apply the 12 V ? OE1 or OE2 the 44 PLCC has both too. And how do you apply it ? could you please describe the sequence of steps ?
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: Programming (non-JTAG) MAX7000 devices
« Reply #48 on: December 10, 2020, 02:58:42 pm »
I got to test all my devices (EMP7128S according to the markings). They fall into two categories: they do not respond to any command, even in "jatg debug mode", and the ones that say something like EMP7128DD_UNKNOWN when the IDCODE iteration test is used. (but nothing else).
They do seem to use the JTAG pins as IOs. That would also prevent JATG from working...
 

Offline CJay

  • Super Contributor
  • ***
  • Posts: 4136
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #49 on: December 10, 2020, 03:41:30 pm »
FWIW, I have a programmer which seems to support these devices but I'd need to hack together an adapter, happy to do so if it's just a wiring job.

If you want to check the supported device list here:
https://www.dataman.com/mwdownloads/download/link/id/6/

I'm happy to erase a few chips if that helps?

 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: Programming (non-JTAG) MAX7000 devices
« Reply #50 on: December 13, 2020, 06:47:03 am »
Thanks for the offer !

I think, "just" knowing how the programming, erase works, or where and how the 12 V are applied may just be enough. Shipping the chips and getting them back would be more expensive than buying a bunch of XC9572xl and making adapters for them. The versions in VQ64 actually work :). The info could help some other folks too. What do you think ?
 

Offline vvervvurm

  • Newbie
  • Posts: 4
  • Country: de
Re: Programming (non-JTAG) MAX7000 devices
« Reply #51 on: December 16, 2020, 10:16:27 pm »
Quote
I wonder if someone who knows for sure can confirm that - if the security bit of a "S" type device has been set, can the device be erased by means of JTAG only, or as @bingo beleves, do you need a "parallel" mode type programmer to clear the security bit and erase the device?

I have salvaged some EPM7064AE devices from old Cisco hardware. Although the security bit was not set - the JTAG was disabled. I could not access them with my USB Blaster. After reading this thread I mustered up the courage to apply 12.25 volts via 2.2k resistor to the OE1n pin (after the normal 3.3 volt VCC). Current draw on that pin was minute ( < 1mA ). Suddenly the JTAG worked and I was able to read and erase the device.

So I would give it a shot. It could also work on 7000S devices I would guess.

I hope this helps. :)
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: Programming (non-JTAG) MAX7000 devices
« Reply #52 on: December 17, 2020, 03:44:45 pm »
@vvervvurm:

Did you keep the 12.5 V during the JTAG transaction or not ?
 

Offline vvervvurm

  • Newbie
  • Posts: 4
  • Country: de
Re: Programming (non-JTAG) MAX7000 devices
« Reply #53 on: December 18, 2020, 11:33:41 am »
yes, VPP stayed on for the whole time ..
(of course after erasing it was not needed any longer as normal JTAG was enabled again)

I have only 2 samples .. so I was not brave enough to set the security flag and try to pull off the same trick again .. and as mentioned my parts are of the AE variety ..
 

Offline vvervvurm

  • Newbie
  • Posts: 4
  • Country: de
Re: Programming (non-JTAG) MAX7000 devices
« Reply #54 on: December 18, 2020, 12:30:15 pm »
@ale500
You might have already seen this topic (near the end of the thread) https://www.eevblog.com/forum/fpga/atmel-atf150x-cpld-and-wincupl/

So I think I was just lucky that my devices had no security bit set. Sorry for getting your hopes up.  :(

edit: The whole "100ms pulse" sounds very much like parallel programming mode as I can't think of a way for a timed pulse in JTAG protocol. (?)
« Last Edit: December 18, 2020, 12:33:03 pm by vvervvurm »
 

Offline Cyberbiotics

  • Newbie
  • Posts: 3
  • Country: es
Re: Programming (non-JTAG) MAX7000 devices
« Reply #55 on: February 24, 2021, 01:00:40 pm »
Hi All! New to the forums.

I purchased 20 EPM7128S MAX7000S devices and most of them didn't respond  to the JTAG commands, I tried the +12V in OE1 method (Pin 84 in PLCC-84) in all of them with no luck. I tried both 1k and 2k7 resistors without voltage drop. Has anyone been able to reset the JTAG fuse in MAX7000S devices this way??

Here you have some pictures of my devices, all of them were sanded with sandpaper and remarked, all of them same datecodes on top but different on the bottom of the IC. Maybe some of them werent MAX7000S devices but MAX7000 devices, which as someone stated before do not have the JTAG circuitry.

Keep an eye for those counterfeits! :palm:


« Last Edit: February 24, 2021, 01:05:32 pm by Cyberbiotics »
 

Offline marcopolo

  • Regular Contributor
  • *
  • Posts: 146
  • Country: fr
    • Retronik
Re: Programming (non-JTAG) MAX7000 devices
« Reply #56 on: February 24, 2021, 01:19:19 pm »
Ebay or Aliexpress?
French Electronic Documentation and Magazines: www.retronik.fr
The 68K Archives: marc.retronik.fr/motorola/68K/68000.html
 

Offline Cyberbiotics

  • Newbie
  • Posts: 3
  • Country: es
Re: Programming (non-JTAG) MAX7000 devices
« Reply #57 on: February 24, 2021, 01:28:54 pm »
Ebay, Polida. Bought new working ICs from him in the past but now they are selling these "fully functional" remarked ICs. I don't understand the reason why someone would erase good chip markings with sandpaper.

I found an interesting vids about detecting counterfeit ICs

https://youtu.be/12u_hBkHB88
https://youtu.be/k72SFBOZ_lw
 

Offline CJay

  • Super Contributor
  • ***
  • Posts: 4136
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #58 on: February 24, 2021, 05:16:25 pm »
Ebay, Polida. Bought new working ICs from him in the past but now they are selling these "fully functional" remarked ICs. I don't understand the reason why someone would erase good chip markings with sandpaper.

I found an interesting vids about detecting counterfeit ICs

https://youtu.be/12u_hBkHB88
https://youtu.be/k72SFBOZ_lw

Polida are bloody awful for fakes, remarked etc. Not only that they get *really* pissy when you leave them a negative pointing it out, I've been banned from buying from them and all their other ebay accounts.
 

Offline marcopolo

  • Regular Contributor
  • *
  • Posts: 146
  • Country: fr
    • Retronik
Re: Programming (non-JTAG) MAX7000 devices
« Reply #59 on: February 24, 2021, 05:30:56 pm »
Polida are bloody awful for fakes, remarked etc.
Like all Chinese sellers  (UTSource included) :(

The only thing to do is to never buy from them.
French Electronic Documentation and Magazines: www.retronik.fr
The 68K Archives: marc.retronik.fr/motorola/68K/68000.html
 

Offline CJay

  • Super Contributor
  • ***
  • Posts: 4136
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #60 on: February 25, 2021, 10:20:07 am »
Polida are bloody awful for fakes, remarked etc.
Like all Chinese sellers  (UTSource included) :(

The only thing to do is to never buy from them.

Easy to say, damned difficult to do because the fake crap turns up everywhere, there's another thread here where I've a suspicion the OP has got a fake RF power transistor that he bought from a local store.

I've been bitten by genuinely UK based sellers who've sold fake parts too.

On balance I've had a more positive than negative experience but it's getting more difficult to avoid.
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: Programming (non-JTAG) MAX7000 devices
« Reply #61 on: February 27, 2021, 05:43:16 pm »
Are you sure your chips are sanded down ? try with nail polish remover (acetone or ethyl acetate). Mine do not seem to be repainted but the 12 V on OE1 didn't help.
Anecdote: I bought 8 27C400, I got 9 repainted TC5742000 (same size 256k x16). Sadly my MiniPro do not want to read them, read ID or anything... Most probably they are burnt somehow.
En otras palabras: nos cagaron :(
 

Offline ceteras

  • Newbie
  • Posts: 8
Re: Programming (non-JTAG) MAX7000 devices
« Reply #62 on: March 11, 2021, 12:55:53 pm »
Regarding 7000S series with JTAG pins used as IO:
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/an/an100.pdf
Page 7, Table 2: Disabling IEEE Std.1149.1 Circuitry in MAX Devices.

Here, in the rightmost column "Enabled for ISP and BST, Disabled During User Mode", we see for MAX 7000S :
Quote
Either:
• Pull the TMS signal high and the TCK signal low
or
• Pull the TMS signal high before pulling the TCK signal high

Am I wrong if I interpret this as a way to re-enable the JTAG if it was disabled by turning off the Enable JTAG BST Support
option in the Quartus II software?

I have one 44pin EPM7064S with disabled JTAG but can't test right now.
Anybody else can give this a try? The pull up should be 4.7K and the pull down 1K.
I'll try it later and come back.
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: Programming (non-JTAG) MAX7000 devices
« Reply #63 on: March 11, 2021, 02:41:47 pm »
Are you sure ? , it looks like that is the way to disable the port. Anyways, the devices I have seem to have the pins repurposed as IOs.
 

Offline Cyberbiotics

  • Newbie
  • Posts: 3
  • Country: es
Re: Programming (non-JTAG) MAX7000 devices
« Reply #64 on: March 11, 2021, 03:08:14 pm »
Yes, it seems that now Polida is selling fakes. They asked me to smash the ICs... I opened a case and was fully refunded.
Trying acetone in them removed a black oily substance that was masking the sandpaper imperfections. The device marking was very well done with laser engraving technique, but as could be expected, all devices had the same datecode. On the backside of the ICs older datecodes could be found
Are you sure your chips are sanded down ? try with nail polish remover (acetone or ethyl acetate). Mine do not seem to be repainted but the 12 V on OE1 didn't help.
Anecdote: I bought 8 27C400, I got 9 repainted TC5742000 (same size 256k x16). Sadly my MiniPro do not want to read them, read ID or anything... Most probably they are burnt somehow.
En otras palabras: nos cagaron :(

I also tried the 12V in OE method, but it didn't work in any case.
 

Offline ceteras

  • Newbie
  • Posts: 8
Re: Programming (non-JTAG) MAX7000 devices
« Reply #65 on: March 11, 2021, 06:54:14 pm »
I tried pulling the pins, didn't work.
 

Offline TomKeddie

  • Newbie
  • Posts: 1
  • Country: ca
Re: Programming (non-JTAG) MAX7000 devices
« Reply #66 on: March 25, 2021, 04:07:47 am »
@migry awesome efforts on the non-jtag devices, I have the same problem. Seems like I should just ewaste them and use a bunch of 22v10s instead but I wanted to check what you ended up doing.  Thanks Tom.
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #67 on: May 02, 2021, 09:58:27 pm »
I have put further work on a back burner for the time being, however I would very much like to spend some more time.

The more I think about it, the more I like the idea of modifying DosBox to output the programmer "commands" to a serial port (USB RS232) as long as I can figure out how to do this inside DosBox. The serial output would connect to the Arduino Mega, which would be able to parse the data stream in order to set the pins and power supplies as just like the programmer would. The timings wouldn't be perfectly accurate, but hopefully would be good enough to get a response from the device.

I will look into "erase" as this appears to be the action people need/want. I did buy 10 EPM7032 devices, so I can sacrifice one and program the lock bit. These particular devices are the later JTAG ones, and I have confirmed that I am able to program them using the cheap Chinese Altera USB Blaster clone.
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: Programming (non-JTAG) MAX7000 devices
« Reply #68 on: May 03, 2021, 01:46:20 pm »
Is your USBBlaster clone's VCC pin 5 V tolerant ? Mine is not: internally has a level converter (A LCX245) that only accepts up to 3.3V supply voltage, I powered with 3.3V.
 

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2616
  • Country: 00
    • My random blog.
Re: Programming (non-JTAG) MAX7000 devices
« Reply #69 on: May 04, 2021, 12:03:12 am »
wouldnt that depend on the clone? those based on EZ-USB FX2LP CY7C68013A should be 5v tolerant
Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: Programming (non-JTAG) MAX7000 devices
« Reply #70 on: May 04, 2021, 07:30:48 am »
My clone doesn't have a cypress chip, it has a FTDI, an Altera CPLD and the LCX245.
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #71 on: September 20, 2021, 05:57:02 am »
So I have a log of the EPM7032 sequence which the ALL03 programmer applies to the device to confirm its ID, which of course it fails to do.

So I have wired up a perf board with a PLCC44 socket, where each pins comes to a row of 44 turned pin header for connection. I then found a 5V Arduino, a Nano, which has more or less the required number of pins.

Yesterday. I was able to code the data from the previously posted file into the Arduino sketch in order to generate the waveforms that would be applied by the ALL03 programmer. I then hooked all the programming pins (thanks once again to the site http://matthieu.benoit.free.fr/ ) to pins of the Arduino. Turns out that "analogue" pins named A0 to A5 can be used as digital, but not A6 and A7 - guess which pin I used for a critical signal! I was able to confirm that when the Vpp pin was taken over about 11V the chip went into test mode and previously clamped shift in data now had no contention and was the right level. I scoped the 2 suspected shift out pins: SDOUTA and SDOUTB, and they had identical waveforms which were defintely the EPM7032 responding to the stimulus.

Today. I wanted to properly capture the response. I didn't quite have enough pins, so I moved some stuff around. Mistake  :( . When I raised Vpp from 5V to 12V (which was OK yesterday) I was getting current clamping on my PSU, and a burning smell  :-DD . After some messing around the lights (of  the Arduino went out). Oops! Turns out the min hub (to which the Nano was plugged on) no longer was lit. When tested elsewhere the min hub appeared to light up, and the Nano too. The hub connected to the back of my Dell monitor. The EPM7032 was very hot, and clearly I had blown it up. I eventually figured out that you must ONLY connect Vpp when a number of other inputs are grounded, and appear to put the device into a state where Vpp does not destroy the chip, however I am not 100% sure which pins are the critical ones.

So I ripped out all the wires from the Nano to the EPM7032 board connector and started again. After the usual debugging and discovery of swapped wires, I got the same waveforms on SDOUTA and SDOUTB as yesterday. I used my Rigol scope logic analyser to capture the waveforms (attached).

I also confrmed which pins become outputs and which inputs when Vpp puts the EPM7032 into "programming" mode.

NTPW - input
MTIN - input
SCK - input
SDINA - input
BE - input
BEM - input
SS - input
SBI - input
TM - input
A0 to A6 - input
SDINB - input
SK - input

Vpp - needs around 12V to put the device into test mode (but ONLY do this if the other pins have been set!)

SDOUTA - output
SDOUTB - output
SCOA - output
SCOB - output

--migry
EPM7032/EPM7064 in PLCC44 package have different non-ISP programming pinout?
References: http://matthieu.benoit.free.fr/120.htm
« Last Edit: September 20, 2021, 06:04:30 am by Beta_vulgaris »
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline c64

  • Frequent Contributor
  • **
  • Posts: 288
  • Country: au
Re: Programming (non-JTAG) MAX7000 devices
« Reply #72 on: October 21, 2021, 04:08:44 am »
So, you found a dos software which talks to a programmer via LPT port. You are running it in dosbox and managed to intercept all requests it sends to LPT port. Is it correct? Now you need to send all data to the real MAX700 via com port.

You could run it in virtual box which supports dos and can have virtual com port. Not sure it your LPT port hacking will work under virtual box
 

Offline edevaldo

  • Newbie
  • Posts: 2
  • Country: us
Re: Programming (non-JTAG) MAX7000 devices
« Reply #73 on: October 21, 2021, 03:22:51 pm »
Quote
I wonder if someone who knows for sure can confirm that - if the security bit of a "S" type device has been set, can the device be erased by means of JTAG only, or as @bingo beleves, do you need a "parallel" mode type programmer to clear the security bit and erase the device?

Yes it can. The security bit does not prevent erasing. But there is a programming option to disable JTAG and make the pins available for IO. Used devices, particularly in lower pin count packages, are usually programmed to disable JTAG. When this happens you need parallel (not the port) programmer like the hilo to put the device back in a erased state and make t he JTAG pins available.

You are getting really close to it. Just fantastic.
 

Offline edevaldo

  • Newbie
  • Posts: 2
  • Country: us
Re: Programming (non-JTAG) MAX7000 devices
« Reply #74 on: October 21, 2021, 03:32:13 pm »
My point was that adding the extra circuitry to convert the non-JTAG device to the new JTAG equivalent would add many more extra flops, as compared to the 32 which form the basis of the device as "seen" by the end user.
 
To implement JTAG you need at least 4 flops for the state machine, one for the re-timing of TDO, at least 4 for the instruction register, 32 flops if you implement the Device ID register, plus any addition flops to tie into the old programming circuitry.

From my experiments on the non-JTAG EPM7032 there are at least two shift registers each 10 bits long (so this requires 20 flops). So even in the non-JTAG design there are more "hidden" flops needed for programming, than the 32 which are used by the end user.

[Edit: I originally said 16 user flops and not 32!]

A macrocell is a really complex piece of circuit. And you need high voltage circuitry to program each eeprom bit in the device and there may be hundreds or even a few thousand of them. Once read they may ned need to be latched somehow... For the different product terms you can select 16 or more inputs, then there is the expansion terms, optional routing, IO configuration, polarities, select clock and reset sources for the flops...

The additional circuit for JTAG is nothing by comparison. CPLDs may be even worse than FPGAs, and they need thousands of transistors to implement each logic element.
 

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 823
  • Country: es
Re: Programming (non-JTAG) MAX7000 devices
« Reply #75 on: October 22, 2021, 01:41:25 pm »
migry, I've tried to disassemble the AMAX70.EXE a bit and have identified the erase function. I can see the 10 42 08 21 84 10 42 08 21 84 pattern matching your log, the ReadID function sends it and receives 5x16 bits back from the chip. Those bits should contain an "ALTERA92" (for EPM7032) or "ALTERA93" (for EPM7032V) in some form. I could dig further if you share LPT pins to programmer regs mapping (don't want to dig into programmer schematics and PAL contents since you did it already).
I can see some sequences looking like prommer regs accesses, i.e. write reg addresses to LPT DATA port, pulse INIT pin, write reg value to DATA port, pulse AUTOLF, but it would be much faster to reuse your info (i.e. reg addresses, who are all those E0, E1,E3 etc I'm looking at).
Or you just follow https://stackoverflow.com/questions/6947413/how-to-open-read-and-write-from-serial-port-in-c to access serial port from DOSBox and implement that bridging. Beware, there are two IC-specific delays (called Tbe and Tpg in AMAX70.EXE, looks like it gets them straight from the ID data), both affect some pulse lengths sent via reg E2. Not sure how critical they are.
 

Offline fisafisa

  • Regular Contributor
  • *
  • Posts: 105
  • Country: es
Re: Programming (non-JTAG) MAX7000 devices
« Reply #76 on: December 06, 2021, 09:55:11 am »
I am sitting on quite some of these (for now unusable) devices...

Just an idea:
Run dosbox-x in a PI and use the PI IO/pins to interface to the device to be programmed.
Some voltage level shifting and possibly some IO expansion might be necessary but modifying dosbox so that every attempt to write/read from the HILO board is trapped has already been done successfully right ?

Would it be possible to  share the modified dosbox-x code...

Ciao

 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #77 on: December 14, 2021, 07:58:15 pm »
It's been quite some time since I last looked at this project, but it has not been forgotten.

I have about 50 new EPM7032s, but no way to program them.

Just recently I completed the following break out PCB. This will allow me to tidy up my breadboarded circuit.

1349687-0

I am happy to share the DOSBOX code, although I need to check that it is still working now I have transferred all files to a new PC. If this board allows messaging, please contact me via that method.
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #78 on: January 20, 2022, 07:33:03 am »
Altera Classic devices, PROGRAMMING Pin-outs for reference.
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline Zapotec

  • Newbie
  • Posts: 2
  • Country: it
Re: Programming (non-JTAG) MAX7000 devices
« Reply #79 on: April 24, 2022, 10:05:24 am »
Good morning !

I need to program EPM7032SLC44 with files made by a project writte in Quartus 13.0.1. I need to use all pins, JTAG pins too
The nice thing is that I have an (old) Elnec LabProg48LV programmer, that support this device. BUT.... its fail to program leaving the chip blank, after no error during programming, but (obviously) fails the verify.

OK I bought an USBBlaster and made a off circuit only programming board.

The problem is that in Quartus, when I try to program device, it told me that JTAG is disabled in project, closing programming window.
I start from Menu Tools->Programmer, scan JTAG, found device EPM7032S, load .JAM file, program. All fine, device works .. but !  jtags pins still enabled (so don't make my project funtions).
If I try to load .POF.... message : JTAG is disabled in file, can't load

If I put +12V (by resistor) on pin44, Quartus program fails also to find (jtag scan) the (blank) 7032S device in home made programmer

Have some idea ?
And wy my Elenec (but I try also with a newer one) falis to program the device (also fail Chip ID .. but is a known problem reported by Elnec).

One Thousand dollars question ;)
thanks
 

Offline GTT95

  • Contributor
  • Posts: 21
  • Country: fr
Re: Programming (non-JTAG) MAX7000 devices
« Reply #80 on: June 01, 2022, 04:29:51 pm »
Hello,

I'm facing quite same situation.

In my EPM7128S based design I need all 84 IO pins for the expected function.

However, I need the ISP feature to be available so that I can reflash CPLD's EEPROM while it is already mounted on the target circuit.

So my question is: once flashed and JTAG pins assigned to functionnal IO, is there a way to take back control over those pins so that the chip can be reflashed? Or is a "special" (non JTAG) programmer required to "factory reset" the chip and make the JTAG specific pins usable again for reprogramming?

Thanks a lot.
 

Offline marcopolo

  • Regular Contributor
  • *
  • Posts: 146
  • Country: fr
    • Retronik
Re: Programming (non-JTAG) MAX7000 devices
« Reply #81 on: June 01, 2022, 04:53:14 pm »
That's not possible, you need a LP6 ISA board + PL-MPU+ PLM7000-84 Adapter

This is the problem that many people who buy Altera CPLDs on Ebay encounter.

Perhaps you can use a FLEX10K FPGA.

Marc
French Electronic Documentation and Magazines: www.retronik.fr
The 68K Archives: marc.retronik.fr/motorola/68K/68000.html
 

Offline GTT95

  • Contributor
  • Posts: 21
  • Country: fr
Re: Programming (non-JTAG) MAX7000 devices
« Reply #82 on: June 02, 2022, 07:04:00 am »
So only by keeping the 4 JTAG pins as dedicated to the ISP function I can continue in-circuit reflashing?

My understanding is that devices from ebay may not be blank leading to the unability to in-circuit reflash through JTAG

The FLEX10K might be a good alternative. However the ratio between max user IO ant total pins is lower than MAX7000S series (only 66 IO for 100pins devices). Other drawback is a serial configuration Flash is required which adds an extra component to the design.
« Last Edit: June 02, 2022, 07:18:58 am by GTT95 »
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #83 on: June 02, 2022, 09:03:56 am »
So only by keeping the 4 JTAG pins as dedicated to the ISP function I can continue in-circuit reflashing?

My understanding is that devices from ebay may not be blank leading to the unability to in-circuit reflash through JTAG

The FLEX10K might be a good alternative. However the ratio between max user IO ant total pins is lower than MAX7000S series (only 66 IO for 100pins devices). Other drawback is a serial configuration Flash is required which adds an extra component to the design.
You can use a parallel PROM, although more pins, it can be multiplexed after configuration done as user I/Os (serial PROMs still the same, but not so ubiquitous as parallel ones).
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline GTT95

  • Contributor
  • Posts: 21
  • Country: fr
Re: Programming (non-JTAG) MAX7000 devices
« Reply #84 on: June 02, 2022, 10:25:56 am »
Are you refering to my last remark about configuring the FPGA? Was not aware it can be configured from parallel Flash. Anyway, there will still be limitation to 66 pins IO which will force selecting a higher FPGA  with more total pins.
 

Offline marcopolo

  • Regular Contributor
  • *
  • Posts: 146
  • Country: fr
    • Retronik
Re: Programming (non-JTAG) MAX7000 devices
« Reply #85 on: June 02, 2022, 11:31:07 am »
Anyway, there will still be limitation to 66 pins IO which will force selecting a higher FPGA  with more total pins.

And what is the problem?
Could you not use a 144-pin TQFP EPF10K10 with 102 I/O?

http://marc.retronik.fr/tmp-mj/AN116_Configuring_Flex6000_et_Flex10K.pdf
French Electronic Documentation and Magazines: www.retronik.fr
The 68K Archives: marc.retronik.fr/motorola/68K/68000.html
 

Offline GTT95

  • Contributor
  • Posts: 21
  • Country: fr
Re: Programming (non-JTAG) MAX7000 devices
« Reply #86 on: June 02, 2022, 12:44:14 pm »
A 144 TQFP means more than twice that much area and I am very restricted in PCB size.
 

Offline marcopolo

  • Regular Contributor
  • *
  • Posts: 146
  • Country: fr
    • Retronik
Re: Programming (non-JTAG) MAX7000 devices
« Reply #87 on: June 02, 2022, 01:21:46 pm »
To stay under 100x100 mm for a cheap PCB?
French Electronic Documentation and Magazines: www.retronik.fr
The 68K Archives: marc.retronik.fr/motorola/68K/68000.html
 

Offline GTT95

  • Contributor
  • Posts: 21
  • Country: fr
Re: Programming (non-JTAG) MAX7000 devices
« Reply #88 on: June 02, 2022, 04:17:43 pm »
Could be but actually reason is it is constrained by credit card size PCB.
 

Offline marcopolo

  • Regular Contributor
  • *
  • Posts: 146
  • Country: fr
    • Retronik
Re: Programming (non-JTAG) MAX7000 devices
« Reply #89 on: June 02, 2022, 04:28:56 pm »
Why use old 5V circuits?
French Electronic Documentation and Magazines: www.retronik.fr
The 68K Archives: marc.retronik.fr/motorola/68K/68000.html
 

Offline GTT95

  • Contributor
  • Posts: 21
  • Country: fr
Re: Programming (non-JTAG) MAX7000 devices
« Reply #90 on: June 02, 2022, 04:58:00 pm »
Because the design has to interface with a system delivering 5V TTL levels. Using a 3,3V device would require level translators through resistor based voltage dividers or other kind of ICs.
 

Offline marcopolo

  • Regular Contributor
  • *
  • Posts: 146
  • Country: fr
    • Retronik
Re: Programming (non-JTAG) MAX7000 devices
« Reply #91 on: June 02, 2022, 06:32:43 pm »
A 144 TQFP means more than twice that much area and I am very restricted in PCB size.

PLCC-84  30x30 mm (without socket)
TQFP-144  23x23mm

TQFP-144 area is 60% of the PLCC-84 area.
it leaves room for a serial configuration memory.
« Last Edit: June 02, 2022, 06:36:19 pm by marcopolo »
French Electronic Documentation and Magazines: www.retronik.fr
The 68K Archives: marc.retronik.fr/motorola/68K/68000.html
 

Offline YetAnotherTechie

  • Regular Contributor
  • *
  • Posts: 221
  • Country: pt
Re: Programming (non-JTAG) MAX7000 devices
« Reply #92 on: June 02, 2022, 10:59:13 pm »
Can't you retarget to a ATF1508AS? as described in Atmel’s Application Note 0916, or http://avitech.com.au/?page_id=3195
 

Offline GTT95

  • Contributor
  • Posts: 21
  • Country: fr
Re: Programming (non-JTAG) MAX7000 devices
« Reply #93 on: June 03, 2022, 08:06:44 am »
Quote
PLCC-84  30x30 mm (without socket)
TQFP-144  23x23mm

Agree, but the comparison was against the TQFP-100 version of EPM7128S. PLCC-84 version doesn't provide 84 user IO.

Quote
Can't you retarget to a ATF1508AS? as described in Atmel’s Application Note 0916

Was not aware of this Atmel equivalent. What benefit is there from using the Atmel CPLD? There are still 84 max IO pins. My guess is that I will experience same limitation while using the JTAG pins for ISP, preventing their reuse for functionnal IO.
 

Offline YetAnotherTechie

  • Regular Contributor
  • *
  • Posts: 221
  • Country: pt
Re: Programming (non-JTAG) MAX7000 devices
« Reply #94 on: June 03, 2022, 11:30:50 am »
The biggest benefit is that it's still in production, so you don't have to depend on the used market. It's also less power, more erase cycles and its jtag can be re-enabled by putting 12 volts on OE pin. https://www.hackup.net/2020/01/erasing-and-programming-the-atf1504-cpld/. There might be details that don't fit your use case, they are listed on the original atmel apnote.
 

Offline GTT95

  • Contributor
  • Posts: 21
  • Country: fr
Re: Programming (non-JTAG) MAX7000 devices
« Reply #95 on: June 03, 2022, 03:19:23 pm »
That sounds good. And also better documented about how to perform reprogramming. Let's know if it can be synthesized from Quartus II 9.0.
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #96 on: June 05, 2022, 11:05:09 am »
That sounds good. And also better documented about how to perform reprogramming. Let's know if it can be synthesized from Quartus II 9.0.
Yes, MAX 7000S/AE/3000A, FLEX 10K/KA/KE are supported up to Quartus II 13.0.
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline GTT95

  • Contributor
  • Posts: 21
  • Country: fr
Re: Programming (non-JTAG) MAX7000 devices
« Reply #97 on: June 06, 2022, 06:24:30 pm »
OK, but what about ATF1508AS? Seems not to be available as target device.
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #98 on: June 08, 2022, 03:11:15 am »
OK, but what about ATF1508AS? Seems not to be available as target device.
ATF1508AS can be converted from EPM7128S/AE by Microchip POF2JED.
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline GTT95

  • Contributor
  • Posts: 21
  • Country: fr
Re: Programming (non-JTAG) MAX7000 devices
« Reply #99 on: June 08, 2022, 08:59:32 am »
OK thanks, good to know synthesizing ATF1508AS from Quartus is only a matter of file format.
 

Offline c64

  • Frequent Contributor
  • **
  • Posts: 288
  • Country: au
Re: Programming (non-JTAG) MAX7000 devices
« Reply #100 on: June 12, 2022, 03:38:01 am »
Anyone know cheap programmer for ATF1508AS ? I'm not aware of any cheap clones on eBay. Programmer for Altera parts can be bought under $10
 

Offline c64

  • Frequent Contributor
  • **
  • Posts: 288
  • Country: au
Re: Programming (non-JTAG) MAX7000 devices
« Reply #101 on: June 12, 2022, 03:39:17 am »
Some people report that the same trick with 12v on OE pin (with series resistor) also works on MAX7000s. I haven't tried
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #102 on: June 13, 2022, 04:42:25 pm »
Anyone know cheap programmer for ATF1508AS ? I'm not aware of any cheap clones on eBay. Programmer for Altera parts can be bought under $10
Any JTAG debugger with SVF support, such as J-Link, CMSIS, FT232, USB Blaster, ByteBlaster, Platform Cable, etc.
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline GTT95

  • Contributor
  • Posts: 21
  • Country: fr
Re: Programming (non-JTAG) MAX7000 devices
« Reply #103 on: June 21, 2022, 01:26:08 pm »
Quote
and its jtag can be re-enabled by putting 12 volts on OE pin.
Is it specific to one version of ATF150? Schematic here:  https://www.hackup.net/2020/01/erasing-and-programming-the-atf1504-cpld/ has the alternate feature Vpp labelled for /OE1, however, the datasheet specifies only /OE1/I?

 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #104 on: June 21, 2022, 04:27:45 pm »
Quote
and its jtag can be re-enabled by putting 12 volts on OE pin.
Is it specific to one version of ATF150? Schematic here:  https://www.hackup.net/2020/01/erasing-and-programming-the-atf1504-cpld/ has the alternate feature Vpp labelled for /OE1, however, the datasheet specifies only /OE1/I?
No programming information is available from the datasheets. Only programmer manufacturers had the access to them, so just do some reverse engineering!
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline GTT95

  • Contributor
  • Posts: 21
  • Country: fr
Re: Programming (non-JTAG) MAX7000 devices
« Reply #105 on: June 22, 2022, 01:43:25 pm »
Maybe applying +12V to /OE1 through resistor and measuring the voltage on this pin. As regular Inputs shall have clamps, measuring +12 V would mean it is OK to accept Vpp, and not accept if mearuring +5V.
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: Programming (non-JTAG) MAX7000 devices
« Reply #106 on: June 23, 2022, 04:21:08 am »
I'll try that with the MAX7128S I got from ali...
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: Programming (non-JTAG) MAX7000 devices
« Reply #107 on: June 23, 2022, 01:19:00 pm »
When I apply ~12 V through a 2.2 kOhm resistor (12.10 V) to ~OE1 (PIN 84), I measure 11.97 V at PIN 84.
When I apply ~12 V through a 2.2 kOhm resistor (12.10 V) to ~OE2 (PIN   2), I measure 12.10 V at PIN  2.

Could it be that it needs 12 V on both pins ?... That I didn't try before.

When I apply 12 V to both PINs TDO changes from HIGH (~5 V), to LOW ~ 0 V.

Nothing, the chips are still not being detected :(
« Last Edit: June 23, 2022, 01:43:23 pm by ale500 »
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #108 on: June 23, 2022, 01:47:34 pm »
When I apply ~12 V through a 2.2 kOhm resistor (12.10 V) to ~OE1 (PIN 84), I measure 11.97 V at PIN 84.
When I apply ~12 V through a 2.2 kOhm resistor (12.10 V) to ~OE2 (PIN   2), I measure 12.10 V at PIN  2.

Could it be that it needs 12 V on both pins ?... That I didn't try before.

When I apply 12 V to both PINs TDO changes from HIGH (~5 V), to LOW ~ 0 V.

Nothing, the chips are still not being detected :(
You entered the parallel programming mode of Altera.
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline GTT95

  • Contributor
  • Posts: 21
  • Country: fr
Re: Programming (non-JTAG) MAX7000 devices
« Reply #109 on: June 23, 2022, 02:34:47 pm »
Quote
You entered the parallel programming mode of Altera

Does it mean to stay in serial JTAG based programming mode only /OE1 shall be put to 12V. Or is it specific to ATF150X devices?
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #110 on: June 23, 2022, 04:13:07 pm »
Quote
You entered the parallel programming mode of Altera

Does it mean to stay in serial JTAG based programming mode only /OE1 shall be put to 12V. Or is it specific to ATF150X devices?
MAX 7000AE/3000A/ATF1500 specific, these families are JTAG only.
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #111 on: August 10, 2022, 01:53:31 pm »
I am the original starter of this thread.

To recap, I have a bunch of NON-JTAG EPM7032/EPM7064/EPM7128 devices, obtained when there was a lab clear out of non-ROHS devices.

I have used GALs in a number of recent projects for which I have had PCBs made, and it would be nice to use these CPLDs in future projects. However I do not have a programmer for the MAX7000 devices.

I mentioned that the ALL03 programmer has been reverse engineered and information is available on the "benoit" website. I am able to run the programming software for the ALL03 in DOSBOX. The programs are DOS EXE files and use character graphics, as was common in the late 80's and 90's. Each device type has it's own EXE. There are several EXEs to support the Altera CPLD parts.

Last year I worked on an 8088 based IBM PC XT clone PCB/project. I needed a BIOS and found a disassembly of the Tandy1000 BIOS on GitHub. The author used a tool called "IDA Pro" to do the disassembly. It is an intelligent disassembler. there is a free version of this tool available for download. I downloaded and "had a play". As usual there's a learning curve.

Just recently I had the idea to re-visit the MAX7000 project with the idea of looking at the EXE code, so see if the programming algorithm could be determined.

I made a false start by using the wrong EXE ! I stated with the EXE which allowed the ALL03 programmer to program the EPM7064/96/128. Nevertheless it was a useful introduction to IDA Pro (Free). The biggest frustration is forgetting to click to select the current line of disassembly before assigning a label. Firstly the EXE is compressed using PKLITE, so I had to find a tool to remove this compression. Having done this the new EXE loads into IDA Pro and the tool does lots of work with no input needed. At the end of the file you can find lots of text strings. Some decompiled as strings, and others which are a list of bytes (not yet referenced by the code). It is also possible to search and find the I/O out and in instructions. I spent quite a few hours over the course of a week playing with the tool and adding labels and defining data types. I started to see code (C switch?) which used the selected device type and jumped to different code depending upon the device selected in the simple GUI. Then the penny dropped, I was looking at the wrong EXE.

So I found the EXE which programmed the ALL03 for the EPM7032 only, and I started a new IDA Pro project. I was able to make quick work thanks to the knowledge already gained.  I now started to see where the strings seen in the data section of the EXE were referenced, so the subroutine call could be assigned a readable name. I didn't understand what all the parameters do, but that is not necessary. This helped figure out where other stuff was. I then found the code for the main menu. When running the code (in DOSBOX) a single character selects an action. I found the jump table which mapped character pressed to subroutine. Interestingly some characters vector off, but they are not seen in the GUI on-screen. I don't know what they do, but at the moment this is not of interest.

I also downloaded the "debug" version of DOSBOX. This version of the code allows writing a trace file, which shows disassembly of the instructions as they are executed and gives a register dump. I was able to use grep and vim to process this file to extract all the I/O instructions, where the code speaks to the two ports on the PC ISA card. This gives a pretty clear picture on how the hardware is sequenced. Again thanks to the "benoit" website, the mapping of ALL03 pins (there are 40) to the pins of the EPM7032, are known.

When I run the EXE I get the message "Error Identification on hardware". Thanks to having schematics of the PC ISA card, and some example C source code (which allows users to write there own driver software), I realised this came from checking the magic counter in the PALs on the ISA card. IDK but perhaps it is a simple form of copy protection? I was able to find the code and hack it to return a "pass" result.

When I run the EXE and now get into the GUI and select the ERASE operation, I get the error message "ID code ERROR !". This string appears several times, but I was able to find it in code related to the 'E' (ERASE) command. After quite some effort I found the function which returned a Boolean false and triggered the message. I hacked the code to fix this too. When the code was run again, the programming software did "more stuff", so having the fail result, due to no real device in a socket, gives an incomplete DOSBOX trace file. I figured out that the first thing that the programmer does is try to determine if there is an ALTERA device in the socket. It does this by applying a stimulus, grabbing the resulting 160 bits, "fiddling" with them in some way, then comparing the resulting 9 bytes to an array of 10 strings, the first of which is "ALTERA92". If no string match is found the "ID code ERROR !" string is the result. By now I think(!) that I know how to stimulate the EPM7032 part in order to get the identification string response. Now over to my hardware to see what happens in practice.
 
The following users thanked this post: YetAnotherTechie, c64, vvervvurm, Beta_vulgaris

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #112 on: August 10, 2022, 02:17:58 pm »
If you have no familiarity with the ALL03 programmer, this will make no sense  ;D

BTW there are currently a couple of ALL03 programmers for sale on Ebay US, both around $500. If I lived in the US I would probably just bid on one of these and save a lot of my time!

Any for those interested in the EPM7032 and how the device identification string is "accessed", please read on.

The device VCC is powered to 5V. The NTPW pin is set to '1'. I'm unsure if it needs to already by '1' during power up, but the programmer sets it first before enabling VCC.
Vpp is ramped to 12V. I am pretty sure that this puts the device into test (or programming) mode where the user settings are switched off and various pins are put into input or output mode for programming purposes.
The 7 "ADDR" pins are forced with the value "0x7C". I have no idea why, or what these pins do, but I guess that the address selects different blocks of EEPROM.
Then 80 bits are shifted into SDINA and SDINB (the same data) using SCK (SCK is normally used for the name of a shift clock). The data shifted in is "00001" repeated 16 times.
Next data is shifted out using SK in blocks of 16 bits. The data on SCOA and SCOB is captured. I believe that this data stream should contain the device identifier (ALTERA92) coded in some way.
After each 16 bit clock SCK is clocked.
There are 5 blocks of 16 so 80 x 2 = 160 bits are shifted out and captured.

So over to my hardware.

I recently made a EPM7032 PLCC to DIL breakout PCB. I now find that I got the pin out incorrect and the PCB is useless   |O

So back to the old hardware, which uses a hand wired perf board, a breadboard for two DACs (VCC and Vpp) and a MEGA 2560 for control.

So I modified the code to apply the newly determined sequence.

I power the device on, ramp Vpp, do the toggling of SCK and CK clocks and drive SDINA/B and then ramp down Vpp and power off. In the Arduino code I loop on this sequence in order to look at the signals using my Rigol scope. The good news is that there is genuine serial data, the bad news is that it is random for each read. I must be missing something which resets the sequence.
 
The following users thanked this post: YetAnotherTechie, c64

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #113 on: August 10, 2022, 02:22:19 pm »
Some waveforms captured using the Rigol scope.

The good news is that I get a digital serial stream shifted out from SCOA and SCOB. SCOA is always zero, but SCOB waveform/data changed from run to run.

1562284-0
 
The following users thanked this post: YetAnotherTechie

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2616
  • Country: 00
    • My random blog.
Re: Programming (non-JTAG) MAX7000 devices
« Reply #114 on: August 11, 2022, 02:51:15 am »
:-+

migry, I've tried to disassemble the AMAX70.EXE a bit and have identified the erase function. I can see the 10 42 08 21 84 10 42 08 21 84 pattern matching your log, the ReadID function sends it and receives 5x16 bits back from the chip.

Then 80 bits are shifted into SDINA and SDINB (the same data) using SCK (SCK is normally used for the name of a shift clock). The data shifted in is "00001" repeated 16 times.

which is it?
also have you compared to ATF1502 A1500.exe?
Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #115 on: August 11, 2022, 11:56:16 am »
:-+

migry, I've tried to disassemble the AMAX70.EXE a bit and have identified the erase function. I can see the 10 42 08 21 84 10 42 08 21 84 pattern matching your log, the ReadID function sends it and receives 5x16 bits back from the chip.

Then 80 bits are shifted into SDINA and SDINB (the same data) using SCK (SCK is normally used for the name of a shift clock). The data shifted in is "00001" repeated 16 times.

which is it?
also have you compared to ATF1502 A1500.exe?
ATF15xx (ISP) CPLDs only have JTAG programming, when JTAG is "disabled" it can be re-enabled by Vpp high voltage.
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #116 on: August 11, 2022, 02:46:05 pm »


Quote
>> migry, I've tried to disassemble the AMAX70.EXE a bit and have identified the erase function. I can see the 10 42 08 21 84 10 42 08 21 84 pattern matching your log, the ReadID function sends it and receives 5x16 bits back from the chip.

>> Then 80 bits are shifted into SDINA and SDINB (the same data) using SCK (SCK is normally used for the name of a shift clock). The data shifted in is "00001" repeated 16 times.

which is it?

They are the same pattern.

SDINA is the top trace in the third picture (above). You can see the 00001-00001-00001- ..etc.. sequence applied to SDINA (same is applied to SDINB). It is clocked in by "SCK" (bottom trace).

In the software the data is shifted in, in 16 bit chunks, stored as 16 bit words in a table. The values shifted in are: 0842-1084-2108-4210-8421.

It's the same bit pattern.

The data read back on SCOA and SCOB is shifted out by the clock "SK", with a pulse of "SCK" every 16 clocks of "SK". The relationship of the two clocks are shown in the Rigol screen grab.

 

Offline pityokas

  • Contributor
  • Posts: 11
  • Country: ro
Re: Programming (non-JTAG) MAX7000 devices
« Reply #117 on: August 16, 2022, 10:42:48 am »
Hi, I'm try to figure out the pin-out for MAX7000 PLD-1 PLCC84 Beeprog.
Almost done, except last part of memory read incorrectly (wrong and repetition of data)
Maybe with combined information we can figure out what pins used for last part of memory and not involved in fist part.
Last part meaning from 0x6E00 (1bit) or 0xDC0(8bit) from total of 0x732F/0xE6F(8bit) for EPM7064 plcc84
I guessed will be same as parallel eproms addressing but it's not.

Attaching a read of epm7032S read in parallel mode.For 7064 almost identical except using more pins. Don't 100% trust on data because I have to make an experimental 48bit logic analyzer (FX2LA+CPLD) and I'm not sure if everything working but promising.
Use pulseview to open files.
 

Offline vvervvurm

  • Newbie
  • Posts: 4
  • Country: de
Re: Programming (non-JTAG) MAX7000 devices
« Reply #118 on: August 16, 2022, 10:42:05 pm »
@migry
Quote
The good news is that there is genuine serial data, the bad news is that it is random for each read. I must be missing something which resets the sequence.

maybe the real programmer has inverted logic? It could explain the random output of the chip. maybe have a look if the data changes on rising or falling edge of the clock signal?
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #119 on: August 17, 2022, 09:58:13 am »
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #120 on: August 17, 2022, 12:57:01 pm »
Hi, I'm try to figure out the pin-out for MAX7000 PLD-1 PLCC84 Beeprog.
Almost done, except last part of memory read incorrectly (wrong and repetition of data)
Maybe with combined information we can figure out what pins used for last part of memory and not involved in fist part.
Last part meaning from 0x6E00 (1bit) or 0xDC0(8bit) from total of 0x732F/0xE6F(8bit) for EPM7064 plcc84
I guessed will be same as parallel eproms addressing but it's not.


Hi Pityokas, I was confused about what information you were asking for help with.

My interpretation was that you have a Beeprog programmer (nice programmer unit supporting lots of ICs!) and you are trying to figure out the mapping from the ZIF socket to the pins of the EDPM7064 device?

While following various links I diid find an adaptor for this programmer for the EPM7032 (I recall) which was around $70. I thought that this wasn't bad value, as I have seen adapters (for various ICs) sell for hundreds of dollars for other programmers.

If I understand better what you are trying to do I may be able to help. I can run the EPM7064 software (A70X.EXE) in my DSBOX emulator, and I can collect some waveforms similar to the ones you collected.

I did look at your waveforms for the EPM7032 and there was a lot of things which looked familiar. Since the trace was quite long I got a little lost. If you were to capture another trace, such as ERASE, which is quite short, I can do the same thing, and we can compare waveforms?
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #121 on: August 17, 2022, 01:35:58 pm »
@migry
Quote
The good news is that there is genuine serial data, the bad news is that it is random for each read. I must be missing something which resets the sequence.

maybe the real programmer has inverted logic? It could explain the random output of the chip. maybe have a look if the data changes on rising or falling edge of the clock signal?

Hi @vvervvurm,

I have actually made some progress with the read out of the device ID "serial bit stream", since my last (big) posting. BTW my programmer is home made and is based around an Arduino Mega 2560 running custom C code.I have DAC control of VCC and Vpp (or Vpg - the high voltage ~12V programming voltage). The circuitry is based around cheap Arduino MCP4725 modules, an OP-amp and a couple of transistors.

So in the past I have made the mistake of continuing to "flog a dead horse", i.e. I have tried to debug a chip which is dead, but which I assumed was working  |O

So I realised that I needed to try some other devices. I had a few at hand. Here is the summary

1) EPM7032LC44-10 : original device, SCOA/B shows serial data but changes from run to run (involves a complete power down).
2) EPM7032LC44-12 : also show random serial data, but is more biases to a string of ones.
3) EPM7032SLC-44-10 (*) : a "newer" device which has JTAG pins - denotes by the "S" in the device code. Seemed to have no activity on SCOA/B.
4) EPM7032VLC-44-12: a 3.3V device (denoted by the "V" in the device code). Bingo. A stable and repeatable bit stream from SCOA and SCOB.  ;D I tried my "read" code and I got stable results but the data looked suspiciously similar to the device ID from address block 0.
4) EPM7032VLC44-12 (**) : also a 3.3V device. Device ID data stream works. Same as the previous "V" chip. The "read" code reads back all address blocks as 80 '1's (all FF == blank).

(*) This device was bought from China. It has laser markings. I did try one using a JTAG programmer and it did program and work.
Just FYI I have bought a number of counterfeit devices (e.g. MC68000, i8088) which originate from a China. The giveaway is that the tops have been sanded down and they have been remarked using laser etching. All my other genuine EPM7032 devices have the text printed in ink. I wanted to see if the JTAG parts could be programmed (or ERASEd) in old-style parallel mode.

(**) This device is black topped. It is a 100% genuine Altera part (I know it's providence). This used to be a trick of the Chinese counterfeiters, until they moved to laser etching. I have a MC68HC000-16 device which came from China via Ebay (yes let the buyer beware). I was able to use IPA to remove the fake ink markings and beneath I found the original Motorola markings of MC68000-8, so not HC and not 16MHz  >:( .

Black topping can be found on genuine devices, but it is of high quality as you might expect. Back in the day (80's/90's?) in the UK RS Components (our Digikey/Mouser) used to sell common ICs such as 7400 LS TTL devices which were black topped and marked with their logo. These were genuine full spec devices.

So success with the 3.3V devices, but not the 5V devices.

I now tried to make sense of the bit stream on SCOA/B, and went back to the IDA Pro disassembly. I found code which manipulated the bit stream. It took some time to figure out what was happening, and I wrote some C code to replicate the machine code in order to play with the bit stream. In one of those "wow" moments a string "ALTURA93" appeared. Close enough  ;D , but after editing the code all that appeared was garbage. After many more hours I found the issue, in that I needed to extend and zero the input array.

For those interested. Each serial out generates 80 bits. in the data area of the code there is an array with 80 elements. It is filled with numbers from 0 to 79 in a logical order (0,5,10,15, ... 70,75, then 1,6,11,16, ... finally 4,9,14, ... 79). It is used to unscramble the 80 bits and create a new string of 80 bits with them simply re-ordered. The "set of 5" appears regularly and must have some relation to the hardware.

I have attached a screen grab showing the captured 16 bits values on SCOA/B and SDOUTA/B (5 * 16 = 80 bits each), and the output from my C code.

I have also attached a grab of the strings embedded in the ALL03 A70X.EXE code. There are 8 strings, which are compared against the descrambled bit stream. The ALTERA93 corresponds to the "V" 3.3V device.
 
The following users thanked this post: YetAnotherTechie

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #122 on: August 17, 2022, 05:46:52 pm »
So I have been doing some more digging into the disassembly from IDA Pro.

Strings are pretty easy to find and many appear automatically on the first pass of IDA Pro. I saw that there is text which makes up the main menu/screen, but includes text for commands which are not printed on the screen. I also found the code which processes the keypress from the main screen/menu and there is table of jumps for every key in alphabetical order, which jump either to a subroutine or a blank. Again I noted a number of characters which are not in the main menu, but have code associated with them. I bit more investigation revealed that a location/flag is checked and if 0 the code is not executed. So I looked for where this location is changed, and turns out only in one place, the code associated with the "U" menu command (does not appear in the screen/menu). When I ran the code in DOSBOX and pressed "U" nothing of note happened. It took some more looking around and a bit of guess and finally if I press "u" followed by "I" followed by "u" the extra commands appear on the main menu/screen (see attachment). There is now a command to read and display the device ID. In Windows when I run the programming software (AMAX70.EXE) since there is no ISA card hardware, nor programmer, the program displays some error messages. So I hacked the binary to fool these checks and the program now executes code that otherwise wouldn't be, allowing me to get a clearer picture of the code execution using DOSBOX trace. The new "Read ID" command displays garbage since it probably sees all ones when reading the the SCOA/SCOB I/O port.

So now over to my Linux VM. Here some time ago i downloaded the DOSBOX-X sources and was able to compile and build a binary. I then proceeded to add my own module, which emulated 1) the ISA card and PALs 2) the ALL03 programmer registers, and 3) the EPM7032. Now that I know the serial bit stream for reading the device ID for a EPM7032V device, I added this emulation into my module. Now when I run the binary, I can enable the "hidden" commands with "uIu" and I can execute the "I" command (Read ID). The 3rd attachment shows the result, and confirms that I managed to get the emulation of the serial bit stream correct. Note that this bit stream also contains two non-ASCII bytes which define: Vpg - the high programming voltage (AKA Vpp) ; Tpg - the width of the programming pulse for writing a block; and Tbe - the width of the pulse for doing a bulk erase.

Both my EPM7032V devices give slightly different values for the 2 bytes defining these values, however the "ALTERA93" ASCII part is the same.

BTW I have just noticed that in the Linux binary the YELLOW text shows different information, so I will need to investigate why using the IDA Pro disassembly.
 

Offline pityokas

  • Contributor
  • Posts: 11
  • Country: ro
Re: Programming (non-JTAG) MAX7000 devices
« Reply #123 on: August 18, 2022, 08:32:34 am »
Hi, I'm try to figure out ... (Attachment Link)
This pinout?
Unfortunately that picture is not 100% correct.If we considering the plcc44 wiring corect then for EPM7064-84:
A2 and A5 is at 49 and 41 and the picture says AD6 AD3
pins 10,29,56,75 are SDOA,B,C,D
plcc pin44(A6) -> PLCC84 picture says  GAD0
And pin 12 used at initialization so cannot be L
Or my adapter is totally wrong.
Also 7128 use more data lines at different pins so EPM7064=7096=7128=7160 it's not true
The programmer require a different adapter for 7128 and 7192 and same for 7064 and 7096

Quote from: migry
...mapping from the ZIF socket to the pins of the EDPM7064 device?
Yes!

The PLCC84 PLD-1 cost 180usd, ok its using high quality zif but...

I inspired my adapter from here https://blog.system11.org/?p=2999, unfortunately was different for beeprog but counted the totally used pins and was exactly 48, so I made my adapter started from pin 1 until all connected, first tested with scope, the important pins VDD,GND VPP was at right position, also the JTAG pins, so tested some EPM7000S and one 7064, at first the 7064 generated some error but after erase was fine so considered was just a temporary error and put everything int box and forget about, until recently when really needed and got error again with another EPM7064 so started to dig deeper.

And now some research what I found:
Today made one random project for EPM7064-84, generated a pof file programed my PLD and got no error after verify, now where is the problem?
Interestingly an empty EPM7064 return a lot of 0 from address 6E00 but the programmer still saying is perfectly empty, odd...
Also the pof file bites are not linearly arranged in PLD, maybe vertically?
Changed the very first 2 bites to 0, the first 0 bit are at first reading the second after 5th reading(one reading return 16 or 17 bit).
I think the algorithm depend on ID, I made a dumb read(without chip) and got different scheme, like an old EPROM, clearly
visible A0,A1...A6 (000  001  010  011 ..)

Quote from: migry
If you were to capture another trace, such as ERASE, which is quite short, I can do the same thing, and we can compare waveforms?
Ok I will make some but I have only one EPM7064-84 the other are with S, I will order some 7032 without S from ali, let see.
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #124 on: August 18, 2022, 08:58:42 am »
Hi, I'm try to figure out ... (Attachment Link)
This pinout?
Unfortunately that picture is not 100% correct.If we considering the plcc44 wiring corect then for EPM7064-84:
A2 and A5 is at 49 and 41 and the picture says AD6 AD3
pins 10,29,56,75 are SDOA,B,C,D
plcc pin44(A6) -> PLCC84 picture says  GAD0
And pin 12 used at initialization so cannot be L
Or my adapter is totally wrong.
Also 7128 use more data lines at different pins so EPM7064=7096=7128=7160 it's not true
The programmer require a different adapter for 7128 and 7192 and same for 7064 and 7096
http://matthieu.benoit.free.fr/all03/adp-7064S-PL84/
http://matthieu.benoit.free.fr/120.htm
https://forum.system-cfg.com/viewtopic.php?f=18&t=13192
My adapter is compatible with all MAX 7000 PLCC84 packages for ALL-03?
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline pityokas

  • Contributor
  • Posts: 11
  • Country: ro
Re: Programming (non-JTAG) MAX7000 devices
« Reply #125 on: August 18, 2022, 09:41:57 am »
http://matthieu.benoit.free.fr/all03/adp-7064S-PL84/
http://matthieu.benoit.free.fr/120.htm
My adapter is compatible with all MAX 7000 PLCC84 packages for ALL-03?
No really help because no names on pins just connection so I can't identify after waveform.
But found interesting, only the SDOABCD pins are connected to pullup, maybe not needed in programming.

https://forum.system-cfg.com/viewtopic.php?f=18&t=13192
They talking about enable MAX7000S JTAG, I don't have problem to program any S type PLD.


All MAX7000S compatible because using JTAG pins, but the MAX7000 are not!
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #126 on: August 18, 2022, 09:51:44 am »
1568626-0
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline pityokas

  • Contributor
  • Posts: 11
  • Country: ro
Re: Programming (non-JTAG) MAX7000 devices
« Reply #127 on: August 18, 2022, 11:29:40 am »
(Attachment Link)
Ok let explain what I know and what no from this schematic compared with my adapter and my waveform:
Clocks: Pin 31,79,83 buffers, probably clock,ok, match my waveform.
SCO-s: Pin 4,23,62,81 trough 244 output, match my waveform
SDI-s: Pin 20,39,46,65 trough 244 input-> match
SDO-s: Pin 10,29,56,75 pullup, my waveform at initialization are all 4 set to high -> match
Missing: Pin 36,37,41,44,48,49,71 and some others,there are directly connected to zif, how to determine the position?
Maybe if migry generate a valid waveform for my epm ID, I can compare else this schematic not help more.

BTW my EPM7064-84 ID: 41 4C 54 45 52 41 39 37 A3 01 00 00 00 (ALTERA97) A301 probably revision and programming info
« Last Edit: August 18, 2022, 11:37:00 am by pityokas »
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #128 on: August 18, 2022, 12:36:30 pm »
I have been looking at this schematic and using it to try to emulate the epm7064 in my DOSBOX-X code base.

I think that pin 1 of the ZIF is incorrect. PLEASE SEE BELOW, this was written before thinking more fully (sorry!).

It is labelled pin35 (not apparently used for programming), but I think that it should be pin25, which is AD0. SEE BELOW (the adapter diagram could be incorrect ?).

ZIF pins 1 to 7 were AD0 to AD6 for the EPM7032, but once I had mapped the pins, I saw that AD0 of the EPM7064 was not connected.
Pins 1 to 8 map to ALL03 register "E0" and was used for the ADDR bus on the EPM7064 and I would assume that this was not changed for the EPM7064.

ADDED LATER: Apologies. It could be the picture of the pin out of the EPM7064 which is incorrectly labelled. In other words perhaps pin 35 is AD0, rather than pin25 ?

I now also note that pin 21 of the ZIF connects to SS_BI (waveform is the same as SS on the 7032).
The diagram of the adapter shows SS_BI on pin 73, but the schematic shows this pin going to pin 77 of the 84 pin PLCC device.

I note that BE is on pin 6 according to the adapter diagram, but I see no control of this from the schematic (just a pull-up).
In the schematic I see pin 19 of the ZIF socket connects to pin 69, but in the adapter diagram this does not show a test purpose.
In the schematic I see pin 36 of the ZIF socket connects to pin 16, but in the adapter diagram this does not show a test purpose.

In the adapter diagram the boxes coloured GREEN seem to indicate something special, but pin 16 shows no test purpose, ditto for 35 and 69.
It just makes me wonder if 16 is BE, 35 is AD0, and 69 is  SS_BI or TM ?

I wonder if it possible to determine which diagram is incorrect ?
« Last Edit: August 18, 2022, 01:15:44 pm by migry »
 

Offline pityokas

  • Contributor
  • Posts: 11
  • Country: ro
Re: Programming (non-JTAG) MAX7000 devices
« Reply #129 on: August 18, 2022, 01:02:53 pm »
Pins 25 and 35 not seems to be used.
Use this for input simulation.Do not skip the ID check, let the program decide what to do with information!
The vpp is still not connected. I did not make an input circuit for high voltage :)
« Last Edit: August 18, 2022, 01:06:43 pm by pityokas »
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #130 on: August 18, 2022, 01:20:39 pm »
Pins 25 and 35 not seems to be used.
Use this for input simulation.Do not skip the ID check, let the program decide what to do with information!
The vpp is still not connected. I did not make an input circuit for high voltage :)

I'm pretty sure one of these two pins is AD0.
You would need to do a blank checks, which increments the address by one, to confirm.

BTW I am still unclear as to your setup. Can you take a picture for clarification?

Am I correct in understanding that you have a BeeProg programmer which you are using to capture the waveforms from?

Have you made a home-brew adapter fro the 40 pin ZIF to the 84 pin PLCC ?

Is this what you are trying to debug ?
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #131 on: August 18, 2022, 01:32:16 pm »
I wonder if it possible to determine which diagram is incorrect ?
I recalled that the inner ring was EPM7032, NOT 7064? I forgot where I saw it.
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline pityokas

  • Contributor
  • Posts: 11
  • Country: ro
Re: Programming (non-JTAG) MAX7000 devices
« Reply #132 on: August 18, 2022, 01:35:51 pm »
Quote
Am I correct in understanding that you have a BeeProg programmer which you are using to capture the waveforms from?
Yes

Quote
Have you made a home-brew adapter fro the 40 pin ZIF to the 84 pin PLCC ?
PLCC84 to ZIF48

And yes I'm try to debug my adapter.
 
The following users thanked this post: migry, Beta_vulgaris

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #133 on: August 18, 2022, 02:26:28 pm »
(Attachment Link)

Is this your work at reverse engineering the adapter socket?

Or do you know who created the schematic?

At this point in time I am leaning towards believing this schematic, and thinking that the pin out (rectangle) diagram has some bugs.

Nevertheless I wonder where the person who created the diagram got the test pin names from?

Note: the 7032 only has SCOA/SCOB, where as the 7064 has SCOA/B/C and D.

This ties up with the fact that the ALL03 has an executable for the 7032 (only) and a different executable which supports the 7064/7096 and 7128.
The former "knows" about 2 serial read channels and the latter 4 (I will check my disassembly of the latter code to confirm).
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #135 on: August 18, 2022, 07:26:33 pm »
Pins 25 and 35 not seems to be used.
Use this for input simulation.Do not skip the ID check, let the program decide what to do with information!
The vpp is still not connected. I did not make an input circuit for high voltage :)

I have had a look at your traces, and I have found it difficult to understand them. The software used by the BeeProg might well stimulate the device in a different order.
Interestingly I see 3 pins which are unlabelled on the adapter diagram, but could be SDOUTB, C and D. Not that these pins show anything of interest anyway!

I have created a version of DOSBOX-X with an emulation of the EPM7064 device, and traces based around the pin mapping from the schematic (and some from the diagram). It isn't working in that the EPM7064 is not recognised, so the ALL03 software does not proceed further. The first thing that it always does is look for the device ID. For some reason it is not being seen, even though I am generating the same serial bit stream on SCOA as was done on the EPM7032.

Here are the traces. One difference between these and yours is that I see activity on "SS_BI" and yours is always zero.
NOTE: I may have some pins labelled incorrectly due to not knowing if the adapter diagram labels are correct.
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #136 on: August 19, 2022, 12:31:59 am »
NOTE: I may have some pins labelled incorrectly due to not knowing if the adapter diagram labels are correct.
Some of the inner labels are for EPM7032, I remembered, if I were correct.
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline pityokas

  • Contributor
  • Posts: 11
  • Country: ro
Re: Programming (non-JTAG) MAX7000 devices
« Reply #137 on: August 19, 2022, 04:39:01 am »
Here are the traces. One difference between these and yours is that I see activity on "SS_BI" and yours is always zero.
Interesting why SCOA=SCOB=SCOC=SCOD?
SCO is output, from where you get the data?
Also I don't understand why bee using 17 clock pulses for SK and ALL only 16?
Can you put a break-point on ID check just feed my ID ad let run?
SS_BI(pin 73) on ALL adapter connected to pulldown. I think you mislabeled, that pin is BV(pin71) and will be similar to my waveform.

Another interesting difference: ALL use SCK pulses after each data read, bee not, but bee using extra SK pulses and ALL not
Bee send 80 SCK pulses ALL send 90? counted right? can you expand and count?

Hint: if you can export your data as binary then you can import into pulseview and there is more tools like counter spi demodulator.
« Last Edit: August 19, 2022, 06:44:54 am by pityokas »
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #138 on: August 19, 2022, 12:50:02 pm »
Interesting why SCOA=SCOB=SCOC=SCOD?
SCO is output, from where you get the data?

All SCO outputs are the same because this is a trace from an emulated EPM7064.

Going back to the EPM7032 and the ALL03 software...
I compiled DOSBOX-X from sources. I can then run dosbox-x and load the ALL03 binary (AMAX70.EXE for the EPM7032). I then added my own module. This module emulates   1) the ISA card and the PAL protection(?) circuitry 2) the registers of the ALL03 programmer (e.g. there are 5 8 bit registers for driving the 40 pins of the ZIF socket, but there are others too) 3) the EPM7032.
As I mentioned the ALL03 software will not generate the proper waveforms unless the check for the ISA card is OK and also the check for the device in the socket (i.e. device ID read) is OK too. So once I had genuine traces from real silicon (the 7032V) for SCOA and SCOB, I added emulation of this to the code. After this was debugged the ALL03 programmer code is happy that it is seeing a genuine device and generates the full set of waveforms for all programming actions. It does however barf during programming because I do not emulate the EEPROM memory.

I trace the waveforms by writing "special" data to the LOG file. I then extract this data and create the stimulus in Verilog format. Weird yes!  ;D I have a Verilog testbench which I compile and simulate to generate the waveforms. There is no option to save waveforms AFAIK., but you could write Verilog code to write a binary file. How to make this compatible with Pulseview - I have no idea.

I copied the DOSBOX-X EPM7032 area and created a EPM7064 area and modified the emulation of the MAX device to reflect the change of pins, and I added SDINC, SDIND, SCOC and SCOD. I emulate the SCO pins, so what you see is my guess at their behaviour and is NOT from a real device. For some reason the device ID was not working for the EPM7064 (it DOES work for the '32). The device ID for the EPM7032 comes out of the SCOA pin. I simply copied the SCOA waveform into the B,C and D eumulation in case the software was looking for the device ID on a different pin.

I am very happy with these waveform traces for the EPM7032. This is way I am CERTAIN than your SS waveform is incorrect.

I then re-generate the waveforms on my desktop setup. There are photos earlier in this thread if you are interested. I use an Arduino to generate the stimulus.

Also I don't understand why bee using 17 clock pulses for SK and ALL only 16?
Can you put a break-point on ID check just feed my ID ad let run?

The sequence comes from the ALL03 software, however the TIMING is NOT accurate. I only log I/O writes and reads. My waveform is sort of like a condensed version of the stimulus. I t would look more like your capture on real ALL03 hardware (which I do not have - and is unavailable in the UK at a sensible price if at all).

Thanks to the IDA Pro work, I am confident that the waveforms are 100% correct, and they do have a sensible pattern. Perhaps without the software delay adding gaps it is less easy to spot each sub-sequence.

I was unable to determine the serial data for the ID from your waveforms, since they look so different to the ones from the ALL03 which I am used to.

I will use DOXBOX-X instruction trace to figure out why the device ID datastream is not working, but from initial look at the IDA Pro disassembly the code is more or less the same.



I hope this clarifies.

BTW I can go into more detail, but most readers are probably not interested. If you have specific questions about my setup, please send a direct message. I can also go into much deeper interest in a DM.
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #139 on: August 19, 2022, 01:00:12 pm »
Interesting why SCOA=SCOB=SCOC=SCOD?
SS_BI(pin 73) on ALL adapter connected to pulldown. I think you mislabeled, that pin is BV(pin71) and will be similar to my waveform.

TL;DR I think that the pin indicated in the rectangular diagram is incorrect.
According to the diagram "SS" is pin 73, but according to the more recent schematic of the adapter (and work with my EPM7064 emulation) it is pin 77.

I am now very familiar with the waveforms needed by the EPM7032.

SS is needed in order to get good data on SCOA/B. So I am pretty certain that if your device is wired to the programmer correctly you will see a waveform on "SS_BI".

SCOA/B is unloaded 16 bits at a time using the SK clock. For the first bit (of 16) SS is LOW, then it is HIGH for the next 15. At the end of every 16 SK clocks SCK is pulses (I sort of guess that this loads the next 16 bits into the output shift register).

I am making the assumption (and I could be wrong) that the behaviour of SS_BI for the 7064 will be the same as the behaviour of SS for the 7032. I think that I have now confirmed this from the EPM7064 emulation, however there is still confusion as to which is the SS pin on the device, since the source documents differ and/or are incomplete.
 

Offline pityokas

  • Contributor
  • Posts: 11
  • Country: ro
Re: Programming (non-JTAG) MAX7000 devices
« Reply #140 on: August 19, 2022, 02:08:29 pm »
All SCO outputs are the same because this is a trace from an emulated EPM7064.
Maybe wrong emulated?
On my waveform SCOA!=SCOB!=
The first 2 byte come from SCOA, the second from SCOB ....

Quote
How to make this compatible with Pulseview - I have no idea.
Binary file. byte after byte, that's all.

Quote
I am very happy with these waveform traces for the EPM7032. This is way I am CERTAIN than your SS waveform is incorrect.
On EPM7032?

Quote
SS is needed in order to get good data on SCOA/B. So I am pretty certain that if your device is wired to the programmer correctly you will see a waveform on "SS_BI".
SS is input or output for EPM?

 

Offline pityokas

  • Contributor
  • Posts: 11
  • Country: ro
Re: Programming (non-JTAG) MAX7000 devices
« Reply #141 on: August 21, 2022, 08:20:56 am »
Another read of EPM7032S-44 but this time with Topmax.
This is very close to your waveform, I think bee sending the reading address pointer every time, and ALL and maybe others just clock SCK once.
There are some spikes including on GND there are very short, just ignore, probably connected the GND to wrong place.
 

Offline pityokas

  • Contributor
  • Posts: 11
  • Country: ro
Re: Programming (non-JTAG) MAX7000 devices
« Reply #142 on: August 21, 2022, 10:24:37 am »
Attaching EPM7032S-44 erase/blank check waveform, nothing interesting, no commands, just static setup on pins.
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #143 on: August 21, 2022, 03:55:01 pm »
Thank you for making the waveform traces @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.

Here is a quick summary of my findings for the EPM7032 with some guesses added.

The Vpp pin when taken to a high enough voltage (*) puts the device into test/programming mode, and the pins are configured into inputs and outputs for SK, SCL, SDIN, SDOUT, SCO, etc.

SDINA and SDINB are used to shift in 80 bits of data. For the read ID sequence to work, a pattern of 00001-00001-000001-00001-00001 (for 80 bits) is required. I have no idea of the significance of this pattern. Data on SDINA and SDINB is clocked in using the SCK clock.

The "set of 5" is also seen in the tables in the ALL03 programming software. This must tie in with the architecture in some way.

The ADDR pins (A6-A0) select a block of EEPROM memory. Since 160 bits are shifted in (80 on SDINA and 80 on SDINB) then we can guess that each block of EEPROM is 160 bits.

Address block 0x7C (hex) is a special block which contains the "read ID". I have no idea if this block is protected from erase or is simple implemented as ROM (rather than EEPROM).

Data is clocked out on SCOA and SCOB. I have a suspicions that these are the outputs of two 16 bit registers, as 16 bits are shifted out using SK, with a clock of SCK every 16 clocks of SK. For the first bit of SS is low and for the next 15 bits SS is high. An alternate interpretation is that SS must be low when SCK is clocked to load new data into the 16 bit SCO registers.

Each device type generates a different stream for read ID. For the EPM7032VLC-44 "V" 3.3V device the datastream of SCOA is 0146-8AAB-F533-6083-3643 (5 sets of 16 bits, with MSB clocked out first). This was observed on a genuine device and captured using a Rigol oscilloscope. The 80 bits for each SCO shifted out is unscrambled using an algorithm based around sets of 5 bits. When the 80 bits shifted out of SCOA are descrambled it becomes 10 bytes "0xFE 0x07 A L T E R A 9 3" (i.e. 10 * 8 bits = 80). The first two bytes define: Vpg - the programming voltage needed on Vpp (called Vpg in the ALL03 software); Tbe - time for bulk erase in ms (determined by a look up table) [note I am guessing the purpose based on the letters "BE"); and Tpg - time to program one EEPROM memory block (also determined using a look up table). The ALL03 software has hidden commands which can be enabled with the sequence "uIu" which gives the "I" command which prints the decoded read ID and Vpg, Tpg and tBe (see attachment).

NTPW is the pin used for the programming and erase pulse. While Vpp/Vpg is high (12V or so) this pin MUST be '1'. It is pulsed LOW for between 20 to 500ms (depending upon device) to either program a block of EEPROM as addressed using the ADDR pins, or to erase everything. Of course it should only be taken low when the appropriate sequence has been applied to other pins.

the ADDR pins (A6-A0) select the block of EEPROM to be programmed or read back. When programming a block of EEPROM the data to be programmed is shifted in on SDINA and SDINB. When reading back a block it is the same as the "read ID " waveforms except that the ADDR pins select the block of EEPROM to be read. For blank check all EEPROM address blocks are read back and all 160 bits (80 from SCOA and 80 from SCOB) must be '1' to confirm the erased state. In the ALL03 blank check command address blocks 0 to 0x57 (87 decimal) are read back in order, then the next few blocks are not read sequentially but goes to 0x68 with the final two reads of address blocks 0x70 and 0x71. This is 106 address blocks in total or 2.21k bytes of data.

The ALL03 software reads in the data to be programmed in POF format. Using Altera Quartus 13.0 (free download) it is possible to create a POF for the MAX7000. My only concern is that the POF format might be different for different versions of the chip A,B,s (JTAG). I compiled a very simple piece of verilog code which simply routine pin 4 to pin 5 (no clocks or flops were used). The data portion of the POF file (having removed the head) was approx 1900 bytes. I do not know the data format, however the  size of the header can vary and contains textual information.



(*) for the EPM7032VLC-44 which is the "V" 3.3V Vcc device, I only needed to raise Vpp to 5.5V in order to enable test/programming mode and unload the read ID data stream (on a real device). Note: for programming or erase the required Vpp will be around 12V, the exact needed value is encoded into the read ID data stream.

In my DOSBOX-X emulation of the ALL03 ISA card, ALL03 registers, and EPM7032 device, I added emulation for the SCOA and SCOB data streams for the "read ID" sequence. I was able to use the ALL03 software to confirm that the data steams were correct, since when unscrabled the magic string "ALTERA93" appears. The emulation of the "read ID" is important, otherwise the software will not generate any further waveform stimulus unless a device has been detected via the "read ID" data stream mechanism.
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #144 on: August 21, 2022, 05:46:33 pm »
Request.

Does anyone have the Altera MAX+Plus II software? I believe that this software requires a license and possible uses a dongle for protection too.

Would it be possible to create some POF files for each of the EPM7032 devices which it supports?

I would like to look at the files to determine the size of the data section of this file, to see if it is the same or different length to the POF file created by the Quartus II 13.0 software which I am using.

The POF generated for the supported device EPM7032AE has a data section of 1901 bytes.
 

Offline marcopolo

  • Regular Contributor
  • *
  • Posts: 146
  • Country: fr
    • Retronik
French Electronic Documentation and Magazines: www.retronik.fr
The 68K Archives: marc.retronik.fr/motorola/68K/68000.html
 
The following users thanked this post: vvervvurm

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #146 on: August 21, 2022, 06:29:40 pm »
Does anyone have the Altera MAX+Plus II software?
I am working on cross-annotating this software, based on the Solaris version (with symbol table, Ghidra decompiler) and Windows (for debugging, Hex-Rays decompiler) MAX+plus 7.2 (available on the Internet Archive). I can upload the application and annotations if we need.
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #147 on: August 21, 2022, 06:41:11 pm »
I do not know the data format, however the  size of the header can vary and contains textual information.
Microchip(Atmel) POF2JED can output some debugging information to dump.txt, see whitequark's Twitter. I can upload the modified executable, too.
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #148 on: August 21, 2022, 07:07:19 pm »
Does anyone have the Altera MAX+Plus II software?
I am working on cross-annotating this software, based on the Solaris version (with symbol table, Ghidra decompiler) and Windows (for debugging, Hex-Rays decompiler) MAX+plus 7.2 (available on the Internet Archive). I can upload the application and annotations if we need.

If you have the chance to create a POF from a simple project for the EPM7032, it would be useful to know if the format as the same as generated by the Quartus software (which I would prefer to use).

I will take a look at the v7.2. I will be interested to see what level of capability it has (without licence?). I'm not sure which version of Windows it will work under ????

I did a quick experiment using Quartus II 13.0, generating some POFs from a trivial Verilog source.

EPM7032AELC44 - data length = 1901
EPM7032BTC44 - data length = 1945
EPM7032SLC44 - data length = 1892 (the S device has a modified architecture as compared to the non-S, so the smaller POF data section was a surprise).


 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #149 on: August 21, 2022, 07:18:01 pm »
I do not know the data format, however the  size of the header can vary and contains textual information.
Microchip(Atmel) POF2JED can output some debugging information to dump.txt, see whitequark's Twitter. I can upload the modified executable, too.

I wrote something quick and dirty using the Perl language. If you have a POF please try it and let me know. It is incomplete.

NOTE: I cannot upload files ending dot PL, so I renamed it to dot BAS. I am sure you can figure out what to do if you need to run it. Requires Perl.
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #150 on: August 21, 2022, 08:30:23 pm »
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)
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #151 on: August 21, 2022, 11:56:48 pm »
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.
« Last Edit: August 21, 2022, 11:58:54 pm by Beta_vulgaris »
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline pityokas

  • Contributor
  • Posts: 11
  • Country: ro
Re: Programming (non-JTAG) MAX7000 devices
« Reply #152 on: August 22, 2022, 05:48:29 pm »
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  :)

Quote
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?
 

Offline jdgabbard

  • Contributor
  • Posts: 11
  • Country: us
    • Retro Depot
Re: Programming (non-JTAG) MAX7000 devices
« Reply #153 on: August 23, 2022, 09:01:27 pm »
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...
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #154 on: August 23, 2022, 10:11:55 pm »
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  :-DD 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.

Quote
>> 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.
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #155 on: August 23, 2022, 10:23:44 pm »
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.
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #156 on: August 23, 2022, 11:10:56 pm »
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.
« Last Edit: August 28, 2022, 01:45:42 pm by Beta_vulgaris »
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #157 on: August 24, 2022, 12:27:14 pm »
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.
 
The following users thanked this post: Beta_vulgaris

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #158 on: August 28, 2022, 01:46:44 pm »
The inner ring is CROSS ANNOTATED FROM EPM7064S, so I was wrong.
https://www.mqp.com/ad359.htm
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #159 on: September 05, 2022, 09:32:45 am »
Altera Classic devices, PROGRAMMING Pin-outs for reference.
Updated: EP1800, from http://www.emulation.com/pdf/m1965.pdf.
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #160 on: September 05, 2022, 01:16:22 pm »
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.
 
The following users thanked this post: Beta_vulgaris

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 823
  • Country: es
Re: Programming (non-JTAG) MAX7000 devices
« Reply #161 on: September 11, 2022, 12:49:10 am »
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 ??
 
The following users thanked this post: migry, Beta_vulgaris

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 823
  • Country: es
Re: Programming (non-JTAG) MAX7000 devices
« Reply #162 on: September 13, 2022, 02:04:46 pm »
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?
 
The following users thanked this post: Beta_vulgaris

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #163 on: September 13, 2022, 05:11:37 pm »
Quote
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  ;D

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.
 
The following users thanked this post: Beta_vulgaris

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #164 on: September 13, 2022, 05:22:35 pm »
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.
 
The following users thanked this post: Beta_vulgaris

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 823
  • Country: es
Re: Programming (non-JTAG) MAX7000 devices
« Reply #165 on: September 13, 2022, 08:07:35 pm »
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)
 
The following users thanked this post: migry, Beta_vulgaris

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #166 on: September 14, 2022, 04:54:59 pm »
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.
 
The following users thanked this post: vvervvurm, Beta_vulgaris

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 823
  • Country: es
Re: Programming (non-JTAG) MAX7000 devices
« Reply #167 on: September 14, 2022, 06:51:58 pm »
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)
« Last Edit: September 14, 2022, 07:05:57 pm by abyrvalg »
 
The following users thanked this post: Beta_vulgaris

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #168 on: September 15, 2022, 12:29:00 pm »
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.
 
The following users thanked this post: Beta_vulgaris

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 823
  • Country: es
Re: Programming (non-JTAG) MAX7000 devices
« Reply #169 on: September 15, 2022, 11:51:20 pm »
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.
« Last Edit: September 16, 2022, 12:01:59 am by abyrvalg »
 
The following users thanked this post: migry, Beta_vulgaris

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 823
  • Country: es
Re: Programming (non-JTAG) MAX7000 devices
« Reply #170 on: September 16, 2022, 02:05:06 pm »
Updated version, working both ways
 
The following users thanked this post: migry, Beta_vulgaris

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #171 on: September 16, 2022, 08:00:04 pm »
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.
 
The following users thanked this post: Beta_vulgaris

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 823
  • Country: es
Re: Programming (non-JTAG) MAX7000 devices
« Reply #172 on: September 16, 2022, 10:32:24 pm »
Check the __init__ method definition of class Block (and other classes), I gave names to all those numbers already :)
 
The following users thanked this post: Beta_vulgaris

Offline migryTopic starter

  • Regular Contributor
  • *
  • Posts: 71
  • Country: gb
Re: Programming (non-JTAG) MAX7000 devices
« Reply #173 on: September 16, 2022, 10:39:17 pm »
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.
 
The following users thanked this post: Beta_vulgaris

Offline abyrvalg

  • Frequent Contributor
  • **
  • Posts: 823
  • Country: es
Re: Programming (non-JTAG) MAX7000 devices
« Reply #174 on: September 16, 2022, 11:30:57 pm »
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.
 
The following users thanked this post: Beta_vulgaris

Offline reverse

  • Newbie
  • Posts: 7
  • Country: ca
Re: Programming (non-JTAG) MAX7000 devices
« Reply #175 on: February 26, 2024, 12:22:07 pm »
Hi. Unfortunately the progress on this seems stalled. I am still looking for the adapter schematics/wiring for the non-JTAG EPM7064 plcc68/44//84 for Hi-LO ALL03 (probably it should work on my ALL07C), or for the Slovakian Dataman/Elnec/Beeprog...Thanks.
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #176 on: February 26, 2024, 04:09:02 pm »
Hi. Unfortunately the progress on this seems stalled. I am still looking for the adapter schematics/wiring for the non-JTAG EPM7064 plcc68/44//84 for Hi-LO ALL03 (probably it should work on my ALL07C), or for the Slovakian Dataman/Elnec/Beeprog...Thanks.
EPM7032/7064 have pin mappings and signal definations. https://mqp.com/ad359.htm and http://matthieu.benoit.free.fr/all03/adp-7064S-PL84.
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline reverse

  • Newbie
  • Posts: 7
  • Country: ca
Re: Programming (non-JTAG) MAX7000 devices
« Reply #177 on: February 26, 2024, 07:39:23 pm »
Nothing for the PLCC68 and other sockets, except for PLCC44. The PLCC84 example you are referring to is for JTAG version of the EPM7000S family, not for the "parallel programmed" family.
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #178 on: February 27, 2024, 09:31:41 am »
Nothing for the PLCC68 and other sockets, except for PLCC44. The PLCC84 example you are referring to is for JTAG version of the EPM7000S family, not for the "parallel programmed" family.
The wafer dies inside all packagings are all the same, so simply connect to the same macrocells.
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline reverse

  • Newbie
  • Posts: 7
  • Country: ca
Re: Programming (non-JTAG) MAX7000 devices
« Reply #179 on: February 27, 2024, 10:53:01 am »
While dies are identical in every family regardless of the pin quantity, their general I/O pins can be remapped at software level in almost arbitrary way therefore the correspondence to programming pins is not determined.
 

Online PCB.Wiz

  • Super Contributor
  • ***
  • Posts: 1473
  • Country: au
Re: Programming (non-JTAG) MAX7000 devices
« Reply #180 on: February 28, 2024, 07:50:28 am »
Hi. Unfortunately the progress on this seems stalled. I am still looking for the adapter schematics/wiring for the non-JTAG EPM7064 plcc68/44//84 for Hi-LO ALL03 (probably it should work on my ALL07C), or for the Slovakian Dataman/Elnec/Beeprog...Thanks.
I'm unclear on what a 'non-JTAG'  means ?
With the Atmel ATF15xx parts, the JTAG fuse can release the JTAG pins to become IO, but then you just apply ~12V (IIRC) to the Vpp pin, to override and enable the JTAG pins again.
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #181 on: February 28, 2024, 09:43:02 pm »
With the Atmel ATF15xx parts, the JTAG fuse can release the JTAG pins to become IO, but then you just apply ~12V (IIRC) to the Vpp pin, to override and enable the JTAG pins again.
ATF15xx series are based on MAX 7000AE, even the 5V parts. EPM7000AE also release JTAG pins on Vpp voltage assertion. http://matthieu.benoit.free.fr/all03/adp/HiLo_ADP-7064AE.PDF
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline reverse

  • Newbie
  • Posts: 7
  • Country: ca
Re: Programming (non-JTAG) MAX7000 devices
« Reply #182 on: February 29, 2024, 07:08:53 am »
"Non-JTAG" means ICs in question do not have JTAG interface at all and can only be programmed via other pins that are manufacturer's secret.
 

Offline c64

  • Frequent Contributor
  • **
  • Posts: 288
  • Country: au
Re: Programming (non-JTAG) MAX7000 devices
« Reply #183 on: February 29, 2024, 08:56:59 am »
I'm unclear on what a 'non-JTAG'  means ?
With the Atmel ATF15xx parts, the JTAG fuse can release the JTAG pins to become IO, but then you just apply ~12V (IIRC) to the Vpp pin, to override and enable the JTAG pins again.
7000S has JTAG
7000 has no JTAG
 

Offline Beta_vulgaris

  • Regular Contributor
  • *
  • Posts: 68
  • Country: 00
Re: Programming (non-JTAG) MAX7000 devices
« Reply #184 on: March 01, 2024, 11:02:03 pm »
"Non-JTAG" means ICs in question do not have JTAG interface at all and can only be programmed via other pins that are manufacturer's secret.
TI PAL chips (military) have official programming specifications.
Electronics, Geospatial, Aerospace
Programmable Logic Devices (PLD) Programming Algorithm Preservation
 

Offline reverse

  • Newbie
  • Posts: 7
  • Country: ca
Re: Programming (non-JTAG) MAX7000 devices
« Reply #185 on: March 02, 2024, 10:35:51 am »
This topic is exaclty about ALTERA reprogrammable devices, not about TI OTP PALs! You replies in this topic are like spam and by AI generated.
 

Offline reverse

  • Newbie
  • Posts: 7
  • Country: ca
Re: Programming (non-JTAG) MAX7000 devices
« Reply #186 on: March 08, 2024, 08:19:58 am »
I found the following official documents/tables describing the pin relation across different sockets of each family:

https://cdrdv2-public.intel.com/676788/epm7160e.pdf
https://cdrdv2-public.intel.com/676664/epm7096.pdf
https://pdf.dzsc.com/88888/2006916165239174.pdf
https://cdrdv2-public.intel.com/676785/epm7032.pdf
https://cdrdv2-public.intel.com/676926/epm7064.pdf

But my attempts to build adapter for HILO programmer based on them fail so far. Moreover for example I am puzzled by controversy in description of power rails  VCCIO and VCCINT distribution in 7064 table and in commercial adapter ADP-7064S-84 which is well documented and reversed here:

http://matthieu.benoit.free.fr/all03/adp-7064S-PL84/


 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf