Is it possible to extend minipro to handle old fashioned TTL fusible links PROMs?

[DavidGriffith]

In GitLab by @vaxorcist on Jan 6, 2022, 24:34

Is it possible to extend minipro to handle old fashioned TTL fusible links PROMs, e.g. 74(x)188 32 X 8 = 256-Bit?

[DavidGriffith]

In GitLab by @radiomanV on Jan 6, 2022, 09:25

Depending on what exactly do you want the answer can be yes or no. If you want to read them then yes you can. I have added some bit banging support for testing purpose in my work repo. Because my immediate urge was to read some proms from old computers i have added some support for all chips which i was able to find in some old databooks. In the other hand if you want to burn/program them the answer is no or not directly without some adapters.

Look at this 82S126/129 programming procedure (extracted from the datasheet):

1. Terminate all device outputs with a 10kO resistor to Vcc. Apply /CE1 = High, CE2 = High and CE3 = High.
2. Select the Address to be programmed, and raise Vcc to Vccp = 8.75 ± 0.25V.
3. After 10us delay, apply VOUT = +17 ± 1V to the output to be programmed. Progam one output at the time.
4. After 10us delay, pulse the /CE1 input to logic low for 0.3 to 0.5ms.
5. After 10us delay, remove +17V from the programmed output.
6. To verify programming, after 10us delay, lower VCC to VCCH = +5.5± 0.2V, and apply a logic low level to the /CE1 input. The programmed output should remain in the high state. Again, lower VCC to VCCL +4.5 ± 0.2V, and verify that the programmed output remains in the high state.
7. Raise VCC to VCCP = 8.75 ± 0.25V, and repeat steps 3 through 6 to program other bits at the same address.
8. After 10us delay, repeat steps 2 through 7 to program all other address locations.

The first thing is the timing. The best resolution we can do by using the bit bang approach is ~1ms. But this is not important nor critical here. The big problem is the required voltages and their max. load. We can simultaneous apply two voltages. One named Vpp (9.5 - 17V range) and the other named Vcc (2.7 - 7.5V range) both limited at max ~100ma. If you exceed this current the over-current circuit will trigger an interrupt and the firmware will reset all pin drivers.
Those voltages are available only for the TL866II+ programmer. For the old TL866A we cannot even set the voltages.
Burning those fusible titanium-tungsten (Ti-W) or nichrome (Ni-Cr) links requires a high current (300-400ma) and our device can't handle this. The other issue is that we can't produce the required VCC voltage (8.75V) from either Vpp or Vcc. For more details please see the schematic diagram located in the docs directory here in this repo.

If you are interested only to read them please reply here, i will instruct you how to do this.

[DavidGriffith]

In GitLab by @vaxorcist on Jan 6, 2022, 12:43

Yes, I'm very interested in reading only, too. Thank you very much for your kind offer to give me instructions!

Am Do., 6. Jan. 2022 um 18:25 Uhr schrieb radioman (@radiomanV) < gitlab@mg.gitlab.com>:

...

> radioman commented > : > > Depending on what exactly do you want the answer can be yes or no. If you > want to read them then yes you can. I have added some bit banging support > for testing purpose in my work repo. Because my immediate urge was to read > some proms from old computers i have added some support for all chips which > i was able to find in some old databooks. In the other hand if you want to > burn/program them the answer is no or not directly without some adapters. > > Look at this 82S126/129 programming procedure (extracted from the > datasheet): > > > 1. Terminate all device outputs with a 10kO resistor to Vcc. Apply > /CE1 = High, CE2 = High and CE3 = High. > 2. Select the Address to be programmed, and raise Vcc to Vccp = 8.75 ± > 0.25V. > 3. After 10us delay, apply VOUT = +17 ± 1V to the output to be > programmed. Progam one output at the time. > 4. After 10us delay, pulse the /CE1 input to logic low for 0.3 to > 0.5ms. > 5. After 10us delay, remove +17V from the programmed output. > 6. To verify programming, after 10us delay, lower VCC to VCCH = +5.5± > 0.2V, and apply a logic low level to the /CE1 input. The programmed output > should remain in the high state. Again, lower VCC to VCCL +4.5 ± 0.2V, and > verify that the programmed output remains in the high state. > 7. Raise VCC to VCCP = 8.75 ± 0.25V, and repeat steps 3 through 6 to > program other bits at the same address. > 8. After 10us delay, repeat steps 2 through 7 to program all other > address locations. > > The first thing is the timing. The best resolution we can do by using the > bit bang approach is ~1ms. But this is not important nor critical here. The > big problem is the required voltages and their max. load. We can > simultaneous apply two voltages. One named Vpp (9.5 - 17V range) and the > other named Vcc (2.7 - 7.5V range) both limited at max ~100ma. If you > exceed this current the over-current circuit will trigger an interrupt and > the firmware will reset all pin drivers. > Those voltages are available only for the TL866II+ programmer. For the old > TL866A we cannot even set the voltages. > Burning those fusible titanium-tungsten (Ti-W) or nichrome (Ni-Cr) links > requires a high current (300-400ma) and our device can't handle this. The > other issue is that we can't produce the required VCC voltage (8.75V) from > either Vpp or Vcc. For more details please see the schematic diagram > located in the docs directory here in this repo. > > If you are interested only to read them please reply here, i will instruct > you how to do this. > > — > Reply to this email directly or view it on GitLab > . > You're receiving this email because of your account on gitlab.com. If > you'd like to receive fewer emails, you can unsubscribe > > from this thread or adjust your notification settings. >

[DavidGriffith]

In GitLab by @radiomanV on Jan 6, 2022, 21:01

OK.
First create a working directory with mkdir work && cd work
Then clone and switch to the work branch wth git clone https://gitlab.com/radiomanV/minipro.git . && git checkout work
And finally build with make
Then ./minipro -V. If everything is right we can read our prom like this:
./minipro -p 74s188 -r 74s188.bin -z. Remove the -z flag if you're using the old TL866A, this is for bad pin contact detection and the TL866A hardware is limited and doesn't support this.
Use ./minipro -L 74s to search for supported 74s chips.
If you want, take a look in prom.c to see how the whole thing works and some details.
Remember that this bit banging approach is a work in progress / experimental support and i have not tested all chips.
Thanks.

[DavidGriffith]

In GitLab by @vaxorcist on Jan 6, 2022, 23:26

Thanks for the quick answer. Unfortunately there's a little problem:

$ ./minipro -p 74S188 -r 74S188.bin -z Device 74S188 not found!

I also tried it with the lower case "s":

$ ./minipro -p 74s188 -r 74s188.bin -z Device 74s188 not found!

make ran without problems: $ make Creating version.c Creating version.h gcc -g -O0 -Wall -I/usr/include/libusb-1.0 -DSHARE_INSTDIR="\"/usr/local/share/minipro\"" -c -o xml.o xml.c gcc -g -O0 -Wall -I/usr/include/libusb-1.0 -DSHARE_INSTDIR="\"/usr/local/share/minipro\"" -c -o jedec.o jedec.c gcc -g -O0 -Wall -I/usr/include/libusb-1.0 -DSHARE_INSTDIR="\"/usr/local/share/minipro\"" -c -o ihex.o ihex.c gcc -g -O0 -Wall -I/usr/include/libusb-1.0 -DSHARE_INSTDIR="\"/usr/local/share/minipro\"" -c -o srec.o srec.c gcc -g -O0 -Wall -I/usr/include/libusb-1.0 -DSHARE_INSTDIR="\"/usr/local/share/minipro\"" -c -o database.o database.c gcc -g -O0 -Wall -I/usr/include/libusb-1.0 -DSHARE_INSTDIR="\"/usr/local/share/minipro\"" -c -o bitbang.o bitbang.c gcc -g -O0 -Wall -I/usr/include/libusb-1.0 -DSHARE_INSTDIR="\"/usr/local/share/minipro\"" -c -o prom.o prom.c gcc -g -O0 -Wall -I/usr/include/libusb-1.0 -DSHARE_INSTDIR="\"/usr/local/share/minipro\"" -c -o minipro.o minipro.c gcc -g -O0 -Wall -I/usr/include/libusb-1.0 -DSHARE_INSTDIR="\"/usr/local/share/minipro\"" -c -o tl866a.o tl866a.c gcc -g -O0 -Wall -I/usr/include/libusb-1.0 -DSHARE_INSTDIR="\"/usr/local/share/minipro\"" -c -o tl866iiplus.o tl866iiplus.c gcc -g -O0 -Wall -I/usr/include/libusb-1.0 -DSHARE_INSTDIR="\"/usr/local/share/minipro\"" -c -o version.o version.c gcc -g -O0 -Wall -I/usr/include/libusb-1.0 -DSHARE_INSTDIR="\"/usr/local/share/minipro\"" -c -o usb_nix.o usb_nix.c gcc -g -O0 -Wall -I/usr/include/libusb-1.0 -DSHARE_INSTDIR="\"/usr/local/share/minipro\"" -c -o main.o main.c gcc xml.o jedec.o ihex.o srec.o database.o bitbang.o prom.o minipro.o tl866a.o tl866iiplus.o version.o usb_nix.o main.o -lusb-1.0 -o minipro

Result: $ ./minipro -V Supported programmers: TL866A/CS, TL866II+ Found TL866II+ 04.2.128 (0x280) Device code: 02105585 Serial code: 0Q0F23VDREVGRJJJ1O6K minipro version 0.5 A free and open TL866XX programmer Commit date: 2022-01-04 18:56:38 +0200 Git commit: 2850ae6cd00af4a9c5d6ed73190be6abd21949a7 Git branch: work TL866A/CS: 14330 devices, 9 custom TL866II+: 16441 devices, 9 custom Logic: 0 devices, 0 custom

I had a look into "prom.c"; and found a reference to 74S188 in line 45.

What's wrong?

My prommer is a TL866II Plus.

Am Fr., 7. Jan. 2022 um 06:01 Uhr schrieb radioman (@radiomanV) < gitlab@mg.gitlab.com>:

...

> radioman commented on a discussion > : > > OK. > First create a working directory with mkdir work && cd work > Then clone and switch to the work branch wth git clone > https://gitlab.com/radiomanV/minipro.git . && git checkout work > And finally build with make > Then ./minipro -V. If everything is right we can read our prom like this: > ./minipro -p 74s188 -r 74s188.bin -z. Remove the -z flag if you're using > the old TL866A, this is for bad pin contact detection and the TL866A > hardware is limited and doesn't support this. > Use ./minipro -L 74s to search for supported 74s chips. > If you want, take a look in prom.c to see how the whole thing works and > some details. > Remember that this bit banging approach is a work in progress / > experimental support and i have not tested all chips. > Thanks. > > — > Reply to this email directly or view it on GitLab > . > You're receiving this email because of your account on gitlab.com. If > you'd like to receive fewer emails, you can unsubscribe > > from this thread or adjust your notification settings. >

[DavidGriffith]

In GitLab by @radiomanV on Jan 6, 2022, 23:59

Yeah. Perhaps you have installed the global old database in /usr/local/. Leave it there and specify the local one with --infoic ./infoic.xml like this: ./minipro -p 74s188 -r 74s188.bin -z --infoic ./infoic.xml

[DavidGriffith]

In GitLab by @vaxorcist on Jan 7, 2022, 24:06

That really did the trick! Great, Thanks again!!!

Am Fr., 7. Jan. 2022 um 09:00 Uhr schrieb radioman (@radiomanV) < gitlab@mg.gitlab.com>:

...

> radioman commented > : > > Yeah. Perhaps you have installed the global old database in /usr/local/. > Leave it there and specify the local one with --infoic ./infoic.xml like > this: ./minipro -p 74s188 -r 74s188.bin -z --infoic ./infoic.xml > > — > Reply to this email directly or view it on GitLab > . > You're receiving this email because of your account on gitlab.com. If > you'd like to receive fewer emails, you can unsubscribe > > from this thread or adjust your notification settings. >

[DavidGriffith]

In GitLab by @radiomanV on Jan 7, 2022, 01:36

In the meantime i have changed this behavior to search the database in the current directory first and then the global. Please do a git pull && make clean && make then you can remove the --infoic ./infoic.xml from the command.

[DavidGriffith]

In GitLab by @vaxorcist on Jan 7, 2022, 07:23

Works perfect with the database in the current directory first now!

I'm considering to build an adapter that provides the necessary voltage and current to program older PROMs. I'm a little better in hardware than in software ;-))

Is the minpro software already prepared to do the programming control?

There are quite a lot of fusible link 32x8bit PROM types. Reading them is probably identical with most of them, if not all. But they differ in their programming parameters. Where do you store those values?

Thanks again for helping me out!

Am Fr., 7. Jan. 2022 um 10:36 Uhr schrieb radioman (@radiomanV) < gitlab@mg.gitlab.com>:

...

> radioman commented on a discussion > : > > In the meantime i have changed this behavior to search the database in the > current directory first and then the global. Please do a git pull && make > clean && make then you can remove the --infoic ./infoic.xml from the > command. > > — > Reply to this email directly or view it on GitLab > . > You're receiving this email because of your account on gitlab.com. If > you'd like to receive fewer emails, you can unsubscribe > > from this thread or adjust your notification settings. >

[DavidGriffith]

In GitLab by @radiomanV on Jan 8, 2022, 03:33

Where do you store those values?

Well, the xml database will tell us the chip name, programming algorithm, algorithm variant and other parameters like programming voltages, programming pulse value and chip package. Usually the read/programming algorithm is implemented in firmware and prior to any read/write transaction we first send an initial data structure to the programmer to initialize it. We call it begin_transaction were we tell to the firmware what programming algorithm is, what variant of this algorithm, what voltages and so on. In return the firmware will initialize all pin drivers and DC to DC converters to the required state. At this moment the chip is powered.

Then we begin to move data blocks back and forth like write this data block starting with address x or read n bytes from address x. Finally we send an end_transaction command and the firmware will reset its internal state and pin drivers.

The firmware has some bit-banging primitives mainly used by the official Windows software for self test, logic IC testing and bad pin contact detection. We can exploit these commands to manually manipulate each I/O line, pin driver, pull-up or pull-down resistor, DC-DC converters and so on. The only drawback is that it will be slow (like 1ms per usb transfer). For small chips (< 64K) this is acceptable but for bigger chips you have to wait.

So i have defined a bit-bang protocol in the database and when such a chip is detected then the normal procedure described above is skipped and all commands are passed to some dispatch routines which will detect what custom algorithm is needed, and if that algorithm is implemented will forward all commands to that implementation.

For example the prom.h/prom.c is such an implementation of a custom bit-bang algorithm. It will receive a data structure with all is needed and then will manually manipulate I/O lines and pin drivers according to implementation. This sounds complicated but it's not.

So in conclusion the xml database contains only the chip name and algorithm number along with some parameters but the effective implementation with all pin definitions for each chip it's in the firmware or for custom defined protocols in their implementation file.

Regarding to the hardware adapter i'm reserved that we can produce an adapter which will cover all prom chips we can read at this moment. So for now the prom support is read-only. If there are some proms that we can burn without any adapter (Vpp up to 17v/100mA and Vcc up to 7v/100mA) please let me know. I'll be glad to implement the write algorithm.

Right now i have some database inconsistencies and other weird things. When ready i will merge this support in the main project.

[DavidGriffith]

In GitLab by @vaxorcist on Feb 6, 2022, 07:46

Today I tried to read two 82S181 and all I got was rubbish (at least I think so): Actually the ROM type is a AM27S181DC (no.1) resp. N82S181N (no.2)

./minipro -y -p 82S181 -r 23-128F3.BIN Found TL866II+ 04.2.128 (0x280) Reading Code... 0.43Sec OK

$ xxd 23-128F3.BIN 00000000: 00bf bfbf bfbf bfbf bfbf bfbf bfbf bfbf ................ 00000010: bfbf bfbf bfbf bfbf bfbf bfbf bfbf bfbf ................ 00000020: bfbf bfbf bfbf bfbf bfbf bfbf bfbf bfbf ................ 00000030: bfbf bfbf bfbf bfbf bfbf bfbf bfbf bfbf ................ ... up to the end ... 000003f0: bfbf bfbf bfbf bfbf bfbf bfbf bfbf bfbf ................

The second ROM behaved the same.

Any idea what might be the cause? Is the ROM AM27S181DC not supported?

Regards, Ulli

P.S. Why are my line endings gone?

Am Sa., 8. Jan. 2022 um 12:33 Uhr schrieb radioman (@radiomanV) < gitlab@mg.gitlab.com>:

...

> radioman commented > : > > Where do you store those values? > > Well, the xml database will tell us the chip name, programming algorithm, > algorithm variant and other parameters like programming voltages, > programming pulse value and chip package. Usually the read/programming > algorithm is implemented in firmware and prior to any read/write > transaction we first send an initial data structure to the programmer to > initialize it. We call it begin_transaction were we tell to the firmware > what programming algorithm is, what variant of this algorithm, what > voltages and so on. In return the firmware will initialize all pin drivers > and DC to DC converters to the required state. At this moment the chip is > powered. > > Then we begin to move data blocks back and forth like write this data > block starting with address x or read n bytes from address x. Finally we > send an end_transaction command and the firmware will reset its internal > state and pin drivers. > > The firmware has some bit-banging primitives mainly used by the official > Windows software for self test, logic IC testing and bad pin contact > detection. We can exploit these commands to manually manipulate each I/O > line, pin driver, pull-up or pull-down resistor, DC-DC converters and so > on. The only drawback is that it will be slow (like 1ms per usb transfer). > For small chips (< 64K) this is acceptable but for bigger chips you have to > wait. > > So i have defined a bit-bang protocol in the database and when such a chip > is detected then the normal procedure described above is skipped and all > commands are passed to some dispatch routines which will detect what custom > algorithm is needed, and if that algorithm is implemented will forward all > command to that implementation. > > For example the prom.h/prom.c is such an implementation of a custom > bit-bang algorithm. It will receive a data structure with all is needed and > then will manually manipulate I/O lines and pin drivers according to > implementation. This sounds complicated but it's not. > > So in conclusion the xml database contains only the chip name and > algorithm number along with some parameters but the effective > implementation with all pin definitions for each chip it's in the firmware > or for custom defined protocols in their implementation file. > > Regarding to the hardware adapter i'm reserved that we can produce an > adapter which will cover all prom chips we can read in this moment. So for > now the prom support is read-only. If there are some proms that we can burn > without any adapter (Vpp up to 17v/100mA and Vcc up to 7v/100mA) please let > me know. I will be glad to implement the write algorithm. > > Right now i have some database inconsistencies and other weird things. > When ready i will merge this support in the main project. > > — > Reply to this email directly or view it on GitLab > . > You're receiving this email because of your account on gitlab.com. If > you'd like to receive fewer emails, you can unsubscribe > > from this thread or adjust your notification settings. >

[DavidGriffith]

In GitLab by @vaxorcist on Feb 10, 2022, 07:40

The problem is gone - my fault. The reason is too embarrassing to publish :-(( (It has something to do with aging ...)

Regards, Ulli