Need software for Intelligent universal programmer lk48

[stefankd]

some basics was done there for the devices files in 2009

[URL="https://hackmii.com/2009/02/48uxp_sw/"]https://hackmii.com/2009/02/48uxp_sw/

that's actually very complicated and since there is no way to analyze the XC3030A bitstreams and thus create our own such bitstreams it leaves really only one option - if there is XC3030A bitstreams and/or FW functions that allows:

1) pin bit-banging from the host
2) control the DACs output/the voltages of each pin

which will make possible new programming algorithms (for unsupported devices) to be implemented from the host, i.e. use the current software for what it already supports and above to allow adding new device support with the algorithm running on the host instead inside the XC3030A bitstreams

that means the key to such idea/possibility is still the "ICTEST.exe" for 48/48LV and the understanding why it is not available for 48xp/48uxp, i.e. they just abandoned it due to no customer demand for such feature, but still 48xp/48uxp FW has the necessary software infrastructure to support such feature or there is no way to make "ICTEST.exe" for 48xp/48uxp, because they changed the FW to disable the ability to do 1-2).

in other words and in very short - making open-source "ICTEST.exe" for 48xp/48uxp (if possible) is the best next step to be explored. unfortunately, 1st the weird nibble-mode using SPP that 48/48LV is using for Parallel communication needs to be understood.

[coromonadalix]

dang forgot to add GDBA___.txt wayback machine of 2009 has it, other years and snapshot is dead

https://limewire.com/d/i2aMZ#Gxg5tGWhhB

[coromonadalix]

some basics was done there for the devices files in 2009

https://hackmii.com/2009/02/48uxp_sw/


parse.py link

https://limewire.com/d/m8yyo#n7A94obSFZ

[stj]

well, i would be interested in knowing what that"ATtiny" chip connects with, the 8031 and / or the FPGA

[stefankd]

so the whole 5 bytes is "48410"
so is the 48 the hardware id? maybe.

yep, I totally agree with you! those 0x34, 0x31, 0x30 seems to be just ASCII for each digit of the FW version, i.e. ASCII 0x34 = 4, ASCII 0x31 = 1, ASCII 0x30 = 0 and hence firmware "4.10" and the other 2 bytes form "48", i.e. the ID of the programmer.

btw, these programmers and most from other makers work by loading an algorythm into a ram-based FPGA and then handing control to it.
the FPGA then sits between the parallel port and the pin-driver circuits and streams the data.

indeed, the software is just a front-end, it selects and sends the "program" from those "*.rez" files for each particular IC and hence the actual bit-banging of the pins is done entirely in hardware and it's done in such way and so the actual programming algorithm cannot be reversed with spying the Parallel port communication. BTW, LT48 includes "ICTEST.exe" that actually allows bit-banging of the pins from the host, i.e. from the PC software.

however, now with getting good insides about how at least FW3.x/FW4.x talk to the device it's possible open-source/alternative front-end to be developed. I guess the number of commands is very small GET_DEV_ID, GET_FW_VER, SEND_BYTE, etc to upload the actual "program" with the programing algorithm to the hardware. also, that way no U62 commutation can be ensured and thus no bricks.

now, if someone is capable enough to reverse-engineer the "*.rez" files and hence the programming algorithms that will be amazing, because it will allow even adding new IC support. also, if FW3.x/4.x have bit-banging capabilities like FW2.x then even be possible to do the programing from the host PC software and not need to write any "*.rez" programs.

[stj]

pp: rd34
pp: rd38
pp: rd34 //FW ver read 1
pp: rd31 //FW ver read 1
pp: rd30 //FW ver read 1

so the whole 5 bytes is "48410"
so is the 48 the hardware id? maybe.

btw, these programmers and most from other makers work by loading an algorythm into a ram-based FPGA and then handing control to it.
the FPGA then sits between the parallel port and the pin-driver circuits and streams the data.

i dont have a UXP to examin the board, but i wouldnt be surprised if either the 8031 or the cypress MCU is doing on-the-fly USB to Parallel conversion.
thats the only logical reason for the USB mode to be slower than the parallel-port.

[stefankd]

and the programmer probably responds with a numeric code for the model & firmware.

my main point though is different and it is that there is no "pp: rd" on my log anywhere and yet the FW revision information is properly exchanged, which leaves only 2 possibilities (IMHO):

1) there is bug in QEMU logging, i.e. what I wrote in my previous post as possibility about the "pdebug() calls" and that is why no such "pp: rd" is logged (BTW, that is now ruled out as you will read below)

or

2) if QEMU logs everything properly, since obviously there is no any read-backs of the Parallel Port "DATA"-register, what is left as option is that they encode "nibbles" (because there is no space for a whole byte there) from the response as part of the Parallel Port "CONTROL"-register and/or "STATUS"-register, which makes it insanely more complicated.

so, thanks to my HOWTO guide from my previous post, a friend already made logs from FW3.10 and FW4.10 units - he doesn't allow me to post the whole logs as he fear his SN are encoded there as well, but here is very small and the relevant portion of those logs:

grep "pp: rd3" logfw310.txt

pp: rd34
pp: rd38
pp: rd33 //FW ver read 1
pp: rd31 //FW ver read 1
pp: rd30 //FW ver read 1
pp: rd34
pp: rd38
pp: rd33 //FW ver read 2
pp: rd31 //FW ver read 2
pp: rd30 //FW ver read 2
pp: rd34
pp: rd38
pp: rd33 //FW ver read 3
pp: rd31 //FW ver read 3
pp: rd30 //FW ver read 3
pp: rd34
pp: rd38
pp: rd33 //FW ver read 4
pp: rd31 //FW ver read 4
pp: rd30 //FW ver read 4

grep "pp: rd3" logfw410.txt

pp: rd34
pp: rd38
pp: rd34 //FW ver read 1
pp: rd31 //FW ver read 1
pp: rd30 //FW ver read 1
pp: rd34
pp: rd38
pp: rd34 //FW ver read 2
pp: rd31 //FW ver read 2
pp: rd30 //FW ver read 2
pp: rd34
pp: rd38
pp: rd34 //FW ver read 3
pp: rd31 //FW ver read 3
pp: rd30 //FW ver read 3
pp: rd34
pp: rd38
pp: rd34 //FW ver read 4
pp: rd31 //FW ver read 4
pp: rd30 //FW ver read 4

so, the above not only proves there is no bug in the QEMU logging, but it also makes perfect sense that they read the FW version 4 times on Initialization:

3 times to test for EPP, ECP and Bi-Directional (as they call it) mode work-ability in the system and then one final read in the selected preferred mode (which preference is EPP->ECP->Bi-Directional based on which exact modes failed and which worked as they documented and I posted in my previous post).

also, that means the only option left for FW2.20 is the option 2), i.e. they are doing nibble-encoding in the STATUS/CONTROL-register bits for read-back-channel rather than using the DATA-register. that also explains why they claim such performance boots with no real change in the hardware, according to their website:

LabTool-48XP advantage over the LabTool-48
Double the speed - benchmark

LT-48 versus LT-48XP
Blank Check 59 sec 19 sec
Program 140 sec 58 sec
Verify 62 sec 32 sec
Total 261 sec 109 sec (2.4 time faster)

that is due to that more efficient communication protocol actually using the Parallel Port "DATA"-register for a read-back in FW3.x/4.x. bottom line is communication of FW2.x is insanely more complicated compared to FW3.x/FW4.x and at least I cannot decode it even with that nibble-encoding in the STATUS/CONTROL-register bits hypothesis (which is most like not a hypothesis, but the reality of what they are actually doing).

[EDIT] actually, it seems some of those nibble-encoding mechanisms were documented in articles for example by Douglas Boling, PC Mag Oct 27, 1992 and PC Magazine issue, Vol 11, No. 18, etc and in very short:

Encoding a read-back channel in a classic unidirectional parallel port (Standard Parallel Port / SPP) uses Nibble Mode (IEEE 1284 Mode 1), which multiplexes an 8-bit byte into two 4-bit nibbles sent sequentially over the 5-bit Status Register input lines

so, I think we can say FW2.x for sure uses SPP with some kind of nibble-mode and no wonder LT48 is 2 times slower on average, because you read-back each byte as 2x 4-bit nibbles.

[stj]

well given the small 8bit cpu, comms are probably kept small and simple.
the pc probably sends an "init" command,
and the programmer probably responds with a numeric code for the model & firmware.
probably with some checksum's on each data packet.

[stefankd]

actually it would be simpler to rip the eprom apart in a disassembler and run it in an emu than try to decode a comms log.
it's a *very* simple 8bit cpu with almost no pheripherals to create a memory map for.
you could probably emulate it in MAME !
https://github.com/mamedev/mame/

you're probably right and so far even that simple comms log I cannot make any sense of it - it's consistent though - by that I mean every time I run AEC software that is the log I get after the software shows "Labtool-48 found" and "Firmware version: 2.20".

however, I see nothing in that log that can resample anything "structured", I mean I was expecting to see something like "GET_FW_VER_COMMAND" send and then response with "2.20", but I see nothing like that to a point that I wonder if in QEMU source code:

https://github.com/qemu/qemu/blob/master/hw/char/parallel.c

all those pdebug() calls are on the right place and not that something there is a miss, i.e. small bug in QEMU logging. BTW, if someone else wants to make such logs and investigate here is something like a very short HOWTO guide:

======================================================================
Ubuntu 22.04.2 LTS x64 : no any particular reason, just what I had in hand for years on one old hdd

# wget https://download.qemu.org/qemu-6.2.0.tar.bz2 : again, getting QEMU v6.2 source code for no any particular reason other than that QEMU version was already installed in my Ubuntu 22.04.2 LTS, i.e. i wanted to replace just the executable with my modified one and not the whole QEMU installation

# tar xjvf qemu-6.2.0.tar.bz2
# cd qemu-6.2.0

# vi hw/char/parallel.c : or any other text editor if 'vi' is too weird for you and modify the line I mentioned in my previous post to activate the debug logging

# ./configure --target-list=x86_64-softmmu : depending on your environment it will fail several times complaining about missing dependencies, in my case I was missing "ninja" and "libpixman" and needed to install them:

# apt install ninja-build
# apt install libpixman-1-dev

# ./configure --target-list=x86_64-softmmu : run it again for final configuration after all the missing dependencies in your environment are installed.

# make -j8
# mv qemu-system-x86_64 myqemu-system-x86_64 : rename the newly build modified QEMU and so it can exist with the original one installed in your system

# modprobe parport_pc : load the driver for your LPT hardware with Linux support, in my case LPT port build-in the motherboard, hence the "parport_pc" driver (kenrel module), but it could be any PCI/PCIe LPT card, etc as far as it has Linux drivers that create "parport" Linux device, then it will work

then run the modified for LPT logging "myqemu-system-x86_64" QEMU with:

# ./myqemu-system-x86_64 -enable-kvm -cpu host -m 256 \
-drive format=raw,file=xpsp3.raw \
-serial none -parallel /dev/parport0

where "xpsp3.raw" image is your WinXP installation QEMU raw image and "/dev/parport0" is the device file of your motherboard real HW LPT port.

so, it's pretty easy and fast - building QEMU is surprisingly fast - maybe 10 minutes time even on that 15 years old computer. of course, you need to have image with WinXP installation, which I am omitting to include in this short guide how to prepare, because it's documented already by many other guides how to install WinXP in QEMU and prepare such image.
======================================================================

also, you can use the above procedure to run the programmer in the future, i.e. when there will be no way on that very modern future computer to install WinXP/Win7/Win10, etc and the AEC software cannot work in that HW/OS of the future (as far as you have PCIe LPT card with Linux driver that creates "parport" device). so, it's not a total waste to know the above, even if it's not about reverse-engineering of the communication.

[stj]

actually it would be simpler to rip the eprom apart in a disassembler and run it in an emu than try to decode a comms log.
it's a *very* simple 8bit cpu with almost no pheripherals to create a memory map for.
you could probably emulate it in MAME !
https://github.com/mamedev/mame/

[stefankd]

I forgot to mention that the above log was made when using FW 2.20 unit with "ICTEST.exe" from software v3.71. so, according to the Archive.org copies of AEC website:

LabTool-48 Firmware 2.10 Support 3.3V Low Voltage chip (June 1997)
The LabTool-48 has release NEW Firmware 2.1 in June 1st, 1997. This new Firmware enhancement enable the LabTool-48 to support both 5V and 3V chip in Digital voltage (Logical Input & Output) and analog voltage (Vcc).

and FW 2.20, I believe is just version of 2.10 for the next production, i.e. with minor changes to reflect the next production batch, but not any changes in the communication protocol. so, we can say that up to FW 2.20 the communication protocol is the same. (and is what is in the log I made).

then again according to the Archive.org copies of AEC website:

LabTool-48XP SW 5.30 support EPP,ECP and Bi-direction Modes

The Labtool-48XP only work under parallel port with EPP has cause many inconvenience of customers who has notebook without EPP in parallel port, Advantech Equipment received many report regarding this issues since the introduction of Labtool-48XP.

With the effort of AEC’s R/D team, the SW 5.30 of Labtool-48XP has change the low level parallel port driver that allow the new Labtool-48XP software to work on EPP, ECP, ECP+EPP or Bi-direction mode without the performance decline even with ECP mode.

After execution the labtool-48XP software revision 5.30 EPP, ECP and Bi-direction driver will be open, the SW try to link the Labtool-48XP in EPP driver first, if it failure to connect the Labtool-48XP, the Labtool-48XP software will try the ECP driver and so on until the Labtool-48XP hardware been successfully detect and connect to the PC.

With this approach customer do not need to change the Parallel port set up in the BIOS, the Labtool-48XP software will figure out the parallel port mode and connect the hardware with proper parallel port driver automatically.

that is very interesting in many regards - especially, that ECP was causing "performance decline" and special measures needed to be taken and that SW 5.30 tries first to open EPP communication, if it fails then tries ECP and if again fails it falls-back to Bi-direction (which I guess means "SPP"). so, again, we can say that up to FW 3.10 the communication protocol is the same and what can be observed in SW versions from 5.01 to 5.30 in different modes, i.e. before SW v5.30 only EPP was used/forced.

now, in FWs up to 4.20 we know some further changes in the communication protocol had occurred, because UXP.EXE cannot speak in Parallel with FW 3.10 unit, but XP.EXE can speak with both FW 3.10 unit and FW 4.xx unit. so, FW 4.xx communication protocol has some extended features used by UXP.EXE, but it has backward compatible mode that allows XP.EXE to speak to it.

last, but not least, even it's just a speculation I am going to make and I cannot be sure about it, but QEMU support for making such convenient Logs of LPT port communication was added to the development version of QEMU on Nov 10, 2005 and a little bit later after that to the release version (one of the main reasons that was added to QEMU was in order to "spy" LPT scanners communication in Windows and develop drivers for Linux for those scanners). so, we can say that early 2006, the "hackers" received such convenient software way to capture all LPT port communication in software thanks to QEMU, exactly all the writes/reads an application is doing in Windows without need of logic analyzers and enormous logs (because the operations in hardware and logic signals are much more that simple read/write request from software and thus even more difficult to analyze). that's why I think it's not a coincidence the "clones" hit the market in 2007. maybe, QEMU support of HW LPT port passing and Log ability was the main tool they used.

[stefankd]

I made some popular adapters for LT48 -> https://reversing.pl/narzedzia/program/program.html

thank you, those are great!

the 48(U)XP luckily doesnt use scam-chips on it's adapters,
the adapters are passive.

yeah, in that regards AEC programmers are one of the most freedom-friendly.

BTW, for those of you that like number puzzles - I built modified QEMU:

https://github.com/qemu/qemu/blob/ma...har/parallel.c

with un-commenting:

//#define DEBUG_PARALLEL

and passing the HW LTP port on my motherboard to that modified QEMU allows to capture the AEC software communication with the programmer - the below log:

pp: rccc
pp: wcce
pp: rcce
pp: wccc
pp: rccc
pp: ws55
pp: wcd8
pp: wd00
pp: wcdc
pp: rs80
pp: wd4c
pp: rs80
pp: wcd1
pp: wcd0
pp: rs80
pp: wd00
pp: rs80
pp: wcd1
pp: wcd0
pp: rs80
pp: wcd1
pp: wcd0
pp: rs80
pp: wcd8
pp: rs80
pp: wd02
pp: rs80
pp: wcd5
pp: wcd4
pp: rsf0
pp: wd4c
pp: rsf0
pp: wcd1
pp: wcd0
pp: rsf0
pp: wdff
pp: rsf0
pp: wcd1
pp: wcd0
pp: rsf0
pp: wd00
pp: wcd1
pp: wcd0
pp: rsf8
pp: wcd8
pp: rsf8
pp: wd06
pp: rsf8
pp: wcd5
pp: wcd4
pp: rsf0
pp: wd4c
pp: rsf0
pp: wcd1
pp: wcd0
pp: rsf0
pp: wd55
pp: rsf0
pp: wcd1
pp: wcd0
pp: rsf0
pp: wd00
pp: wcd1
pp: wcd0
pp: rsa8
pp: wcd8
pp: rsa8
pp: wd0a
pp: rsa8
pp: wcd5
pp: wcd4
pp: rsf0
pp: wd4c
pp: rsf0
pp: wcd1
pp: wcd0
pp: rsf0
pp: wdaa
pp: rsf0
pp: wcd1
pp: wcd0
pp: rsf0
pp: wd00
pp: wcd1
pp: wcd0
pp: rsd0
pp: wcd8
pp: rsd0
pp: wd0e
pp: rsd0
pp: wcd5
pp: wcd4
pp: rsf0
pp: wd51
pp: rsf0
pp: wcd1
pp: wcd0
pp: rsf0
pp: wdaa
pp: rsf0
pp: wcd1
pp: wcd0
pp: rsf0
pp: wd55
pp: rsf0
pp: wcd1
pp: wcd0
pp: rsf0
pp: wd00
pp: wcd1
pp: wcd0
pp: rs88
pp: wcd8
pp: rs90
pp: wcd1
pp: wcd0
pp: rse0
pp: wcd8
pp: rsa0
pp: wcd1
pp: wcd0
pp: rs88
pp: wcd8
pp: rsb0
pp: wcd1
pp: wcd0
pp: rs90
pp: wcd8
pp: rsb0
pp: wcd1
pp: wcd0
pp: rsa0
pp: wcd8
pp: rsa8
pp: wcd1
pp: wcd0
pp: rsf8
pp: wcd8
pp: rsb0
pp: wcd1
pp: wcd0
pp: rsf8
pp: wcd8
pp: rsb0
pp: wcd1
pp: wcd0
pp: rse0
pp: wcd8
pp: rsb0
pp: wcd1
pp: wcd0
pp: rse8
pp: wcd8
pp: rs90
pp: wcd1
pp: wcd0
pp: rsa0
pp: wcd8
pp: rs98
pp: wcd1
pp: wcd0
pp: rsc0
pp: wcd8
pp: rs98
pp: wcd1
pp: wcd0
pp: rs80
pp: wcd8
pp: rs90
pp: wcd1
pp: wcd0
pp: rsb0
pp: wcd8
pp: rsa0
pp: wcd1
pp: wcd0
pp: rsc8
pp: wcd8
pp: rsb0
pp: wcd1
pp: wcd0
pp: rs90
pp: wcd8
pp: rsb8
pp: wcd1
pp: wcd0
pp: rse8
pp: wcd8
pp: rsb0
pp: wcd1
pp: wcd0
pp: rsb8
pp: wcd8
pp: rsb8
pp: wcd1
pp: wcd0
pp: rs88
pp: wcd8
pp: rsb0
pp: wcd1
pp: wcd0
pp: rs90
pp: wcd8
pp: rsb8
pp: wcd1
pp: wcd0
pp: rsa8
pp: wcd8
pp: rsb0
pp: wcd1
pp: wcd0
pp: rs80
pp: wcd8
pp: rs90
pp: wcd1
pp: wcd0
pp: rsb0
pp: wcd8
pp: rsa8
pp: wcd1
pp: wcd0
pp: rsa8
pp: wcd8
pp: rsb0
pp: wcd1
pp: wcd0
pp: rs90
pp: wcd8
pp: rsb8
pp: wcd1
pp: wcd0
pp: rs98
pp: wcd8
pp: rsb8
pp: wcd1
pp: wcd0
pp: rsc8
pp: wcd8
pp: rsb0
pp: wcd1
pp: wcd0
pp: rsf8
pp: wcd8
pp: rsb0
pp: wcd1
pp: wcd0
pp: rsf0
pp: wcd8
pp: rsb0
pp: wcd1
pp: wcd0
pp: rs80
pp: wcd8
pp: rs90
pp: wcd1
pp: wcd0
pp: rs90
pp: wcd8
pp: rs98
pp: wcd1
pp: wcd0
pp: rsf0
pp: wcd8
pp: rs90
pp: wcd1
pp: wcd0
pp: rs90
pp: wcd8
pp: rs98
pp: wcd1
pp: wcd0
pp: rs80
pp: wcd8
pp: rs98
pp: wcd1
pp: wcd0
pp: rs80
pp: wcd8
pp: rs80

is what is giving "Labtool-48 found" and "Firmware versions: 2.20", but it makes no any sense to me, i.e. how they read-back for example the FW version, because there is no "pp: rd" lines. BTW, you can see in "parallel.c" how those log lines are generated. so, the communication protocol is not anything obvious or simple as it seems, but maybe some of you will have some idea....

[coromonadalix]

hi i was on the xeltek subjects, and wont talk anymore of them, not to derail this thread

[stj]

the 48(U)XP luckily doesnt use scam-chips on it's adapters,
the adapters are passive.

[coromonadalix]

i have some of the same files and others pdf's too uxp soft from 6.70 up to the 14.3 win 7 and win 10 ? ...

around 1.6 gig, sure there are duplicates of the posted links, should i archive and share it too ? and someone host this ? with many searches and same results, well have a good archive loll

LT48UXP_670 up to the last win 7 win 10 versions ...

IF yes, tell me ... il create a limewire link



@stefahkd
i was able to buy 20 of theses crypto chips before they dissapeared, and i have some software developmant kit to communicate, the lkt4101 is sometimes called AE801
it's known to self destruct if you wrongly mess with it the bad way / or trigger it's safety

[coromonadalix]

oh i said the best at the moment

because an special adapter can be put on it, to mimick and accept tons of cheap adapters vs the xeltek costly ones ... sure there is no absolute programmer, always something missing

[toriman]

Polish AEC Labtool archive there:

https://support.elmark.com.pl/progra.../aec/archiwum/

Should be good to archive all available software from any source

Greetz
tOri

P.S. I made a "mirror" of this directory for some reason
P.P.S. If anyone is interested in - I made some popular adapters for LT48 -> https://reversing.pl/narzedzia/program/program.html - use translator to read, links to GERBER files are placed at end of page

[stefankd]

14.10
https://web.archive.org/web/20241007...-48UXP_ALL.pdf

LabTool-48UXP Version 14.20 Device List

thank you all for the PDFs/URLs! IMHO, at this point, it's best if someone is interested enough to setup some web place where people can put their AEC archives, etc and build up the collection to as full as possible, instead of dealing on file-per-file basis. BTW, I've found here:

https://asix.tech/_museum/programmers/aec/

DOS software (v4.61, the latest is v4.71, but v4.71 is available on Archive.org) for the original 48/48LV model.

what is unique about the above URL is that it hosts probably the only copy left on the web of the "PCT_318.ZIP". so, "PCT_318" was/is "ROM emulator" module that connects to those DB-9 ports ("Module A" and "Module B") found on 48/48LV:

https://web.archive.org/web/20010216043030fw_/http://www.aec.com.tw/products/pct-318.htm

and thus the EXE inside "PCT_318.ZIP" contains the communication protocol how to "speak" to those ports on 48/48LV in case someone is interested in reverse-engineering that and be able to use those ports on 48/48LV for some custom tasks.

for xeltek they have crypto chips on the socket and placed on the programmer pcb

yes, but what is important to be noted is that the crypto-chip on the main-board and on the sockets is used in the exact same way, i.e. the same communication protocol and they just serve a slightly different purpose - one is to prevent the main-board from cloning, the other is to do the same with the socket plus add planned-obsolescence limiting how many times a socket can be used similarly to the way how ink-printer-cartridges were artificially limited to a number of pages. anyway, i gave the Xeltek story just to serve as an idea about the MCU found in AEC devices and how such protections are implemented. BTW, crypto-chip on Xeltek is rumored to be "LKT4101", but it's pin-compatible with "ATtiny25" and the Russian hack described in those articles in details implemented in C programing languages firmware for "ATtiny25" that re-implements all the crypto-functionality of that obscure Chinese-made "LKT4101" chip. so, they really fully cracked it open and I think if noting more about the main topic here those articles are with good educational value.

[stj]

there is no "best" with programmers,
it depends on what your doing with them.

i have a T56 for modern flash chips, tv eeproms etc,
but i also have an ice-technologies micromaster1000 for ancient stuff like PAL's, PEEL's BPROMS and other 1970's and 80's stuff.
the newer programmers always miss something the old ones handle.
i have other programmers too, but the MM1000 and the T56 cover most parts.
a 48XP and the T56 would be ideal but i had to get rid of my 48XP because it was so expensive - maybe they will drop in value now and i can get one again!

[coromonadalix]

for xeltek they have crypto chips on the socket and placed on the programmer pcb, the 5000 6100 7000 7500 have what they call a magicchip who became megamagic ... i paid 300$ usd for the xeltek 5000

With it you can use any cheap ic socket, the 5000 had at least 26 reversed socket pcb, i had them all

for the 7500 it goes beyond that, and the megamagic is 400$ usd to get

you have to go on telegramm to talk with aleksander, a russian guy who broke the crypto sequences

i think it is the same guy ive talked too on telegram




The best one now is the xeltek 7500, $$$ pricy as hell, but the current "best one out there"

Elnec beeprog as far as i know was not hacked, if it is, i dont know ..... beeprog 4 is out, more standard then beeprog 3, but elnec charge premium on their sockets, avoid the beeprog 2c, its a reduced beeprog 2, to ulock it it's 250$ usd (at least)
Galep 5 is a good, but less brand and parts qty limitted

And some Elnec are now obsolete below beeprog 2 on some models, no more sw updates

As of now market for universal programmer is slighty shifting, oldies are still popular and priced high

I want to sell my "very clean" Chipmaster 6000uxp ... mmm how much should i ask loll now stuck at v14.30