Werking IC-Tester doorgronden

Op 15 december 2022 11:28:41 schreef flash2b:
Je zou ook bij het schema van de MiniPro TL866 kunnen kijken hoe ze het daar opgelost hebben:

https://www.obdii365.com/upload/pro/mini-pro-tl866-schematic-diagram.p…

Die doen het eigenlijk op de zelfde manier, dus ik denk dat hij daar ook de "inspiratie" vandaan heeft.
In de TL866 gebruiken ze wel registers (TTL) terwijl in deze IC tester hij een lomp grote microcontroller (ATMEGA2560) genomen heeft met heel veel I/O lijnen.

Als universele programmer is het niet handig zo. (er is maar een beperkt aantal pindrivers voor Vdd, Vpp, en Gnd)
Een 'all-in-one' driver per pin (die data in/out, Vdd, Vpp, of Gnd kan schakelen) is universeler.

Alle pinnen kunnen dan voor alles gebruikt worden.
(anders zul je natuurlijk net zien dat er een chip is die niet aangestuurd kan worden omdat de Vdd op een niet gesupporte pin zit...)

hoewel er wel universele assembler/compilers zijn zoals TASM (table driven assembler)

Voor een assembler is dat meer voor de hand liggend dan voor een compiler...

Ongeacht de taal, het moet omgezet worden naar dezelfde instructies.

Ja... nou... zo werkt het dus niet helemaal. Talen zijn best verschillend. En de gemiddelde compiler heeft ook nog wel een 'runtime library'. Die van basic is doorgaans een stuk groter dan die van C.

ijn code zal lang niet zo efficient zijn

Tsja... Dan zul je eerst 'efficiënt' moeten definiëren. Als in: als performance / memory geen enkel punt is, dan is jouw code (in basic) waarschijnlijk 'efficiënter' dan assembly (botweg omdat het sneller te schrijven en wellicht ook makkelijker aan te passen is).

Wat heel veel scheelt (of het nou basic of C is) is kennis van assembly en de onderliggende hardware architectuur. Daarmee voorkom je 'nare' constructies en lost de compiler / optimizer de rest op.
Basic heeft als groot nadeel dat het 'by design' minder geschikt is om in compacte code 'complexe' dingen te doen. Als je mijn eerder beschreven suggestie in basic schrijft, dan zal (bij een behoorlijke compiler) de object code niet serieus hoeven te verschillen van die in C of assembly. Maar de source kan wel eens lastiger leesbaar zijn.

[offtopic]Ik heb ooit eens een stukje 'serieel' voor een 8051 geschreven. Dat ding moest zo her en daar naar wat andere hardware luisteren en zo nu en dan wat uitbraken. Dat maak je generiek, dus in een soort van library.
Wie de 8051 een beetje kent (de kennis hier is inmiddels ook stoffig... te lang niks meer mee gedaan), die weet dat het een Harvard architectuur is met ROM, iRAM en XRAM. De iRAM is 'intern', de XRAM doorgaans extern en optioneel (al zal het tegenwoordig wel op dezelfde die zitten). Effectief zijn het 3 verschillende opcodes in assembly - met dezelfde mnemonic - de assembler mag de juiste erbij zoeken.
Goed, ik schrijf dat in C. En aangezien ik niet vooraf weet waar mijn uit te braken stukkie data woont, werk ik met void pointers. En vervolgens performed het voor geen meter (WTF... die core draait op een whopping 1MHz, waarom kan ik niet interrupt-driven 19k2 binnen lepelen??). Dat zijn een l*llige 2000 interrupts per seconde... Waar zit te pijn?
Afijn, het was dus ff zoeken, maar... compile-time weet de compiler niet waarmee de library wordt aangeroepen - in welk stukkie memory de boel staat. De pointer is 16 bits, maar blijkt als je de gegenereerde assembly bekijkt opeens een extra byte te krijgen. Die byte vertelt in welk soort memory de boel staat. Vervolgens wordt een stukje runtime library(!!) aangeroepen met als argumenten (oa) de pointer en die extra byte. Daarachter zit een if-boompje om naar de juiste opcode te jumpen en daarmee het gewenste resultaat te returnen of te schrijven (slimme compiler... bij een write naar ROM werd het een NOP ). En dat gebeurt dus bij elk character.
Ofwel: functioneel werkt dat, maar het is rete-duur qua performance (en in de praktijk dus onbruikbaar). 'Alles' naar XRAM pointer omkrikken leverde natuurlijk wel de gewenste code op...

En ja, ik weet, naar huidige maatstaven is een 8051 natuurlijk wat eh... 'achterhaald'. Maar het geeft wel aan dat wanneer je een klein beetje kennis van de onderliggende architectuur hebt, je je code veel efficiënter kunt krijgen.

Nog zo'n aardige... locatie van locals. Een 8051 heeft nou eenmaal geen (nou ja, nauwelijks) stack. Locals hebben - een beetje afhankelijk van de compiler - een 'fixed' locatie (doorgaans link time bepaald). Grappig als je wat recursief gaat doen [/offtopic]

Basic heeft als groot nadeel dat het 'by design' minder geschikt is om in compacte code 'complexe' dingen te doen.

Die 'compacte code' is juist een nadeel van C...
Het is meestal een onbegrijpelijke aan elkaar geknoopte brij van vergelijkingen, shifts en and/or/xor's.
(ik heb er regelmatig 20 of zo op 1 regel gezien)

Nu weet ik dat je het ook netjes kunt doen, maar er zijn maar weinig C programmeurs die zich daaraan houden.
Doen ze liever quick and dirty. (schijnbaar zijn ze te beroerd om een paar extra toetsaanslagen te doen)

Tussen een assembler en compiler zit weinig verschil: beide zetten leesbare tekst in instructiecode om.
Een assembler is een compiler. (interpreter is een ander geval, maar die zijn gelukkig bijna uitgestorven)

Hello,

first of all sorry for writing in English, but my Dutch is limited to only a few words.

I stumbled across this post by accident and since I'm the one who developed the RCT I might be able to answer a few questions.

It is correct that the device is not 100% foolproof. ICs can be inserted the wrong way around, a wrong test can be selected, so that an IC is grilled as e.g. 4116/2708 with 12V and much more. Technically, however, this cannot really be prevented. What doesn't happen is that GND and 12V are active at the same time (this is impossible on the software side) and the hardware is developed in such a way that there is never a supply voltage during a reset etc. Of course, when you want you can enable all voltage drivers the same time when you write your own code but this is also true for other hardware, e.g. the mentioned TL-866.

The Zeners are designed to withstand the 12v and protect the ATmega. Only four Zeners are really essential, the others serve as protection if a short should occur within an IC that requires 12v. The 12v are usually only available for a very short time, so that they are not really stressed.

As far as "universal" is concerned, it is certainly possible to provide all supply voltages for each pin. This increases the cost of the components without bringing any real benefit. If you look at the supported components, you will probably find it very difficult to find ICs that are not supported.

The RCT was originally created only as a tool for repairing devices in my own collection. I've been collecting (home-)computers for almost 40 years and have now reached over 1000 devices, so it's normal for one to be defective every now and then. My personal RCT has tested several thousands of ICs in the last three years and and has survived some strange experiments. So when I started to implement the EPROM programming code the device also survived 28V. It is a pretty robust peace of hardware. Maybe not perfect in every detail but it does his job well.

I'm still amazed at how well the RCT is accepted by the community. It is primarily used by collectors of arcade machines, pinball machines, synthesizers and of course home computers. But there are also a few repair shops that use it.

Regards,
Stephan aka slabbi

Op 15 december 2022 12:30:20 schreef slabbi:
Hello,

first of all sorry for writing in English, but my Dutch is limited to only a few words.

I stumbled across this post by accident and since I'm the one who developed the RCT I might be able to answer a few questions.

It is correct that the device is not 100% foolproof. ICs can be inserted the wrong way around, a wrong test can be selected, so that an IC is grilled as e.g. 4116/2708 with 12V and much more. Technically, however, this cannot really be prevented. What doesn't happen is that GND and 12V are active at the same time (this is impossible on the software side) and the hardware is developed in such a way that there is never a supply voltage during a reset etc. Of course, when you want you can enable all voltage drivers the same time when you write your own code but this is also true for other hardware, e.g. the mentioned TL-866.

The Zeners are designed to withstand the 12v and protect the ATmega. Only four Zeners are really essential, the others serve as protection if a short should occur within an IC that requires 12v. The 12v are usually only available for a very short time, so that they are not really stressed.

As far as "universal" is concerned, it is certainly possible to provide all supply voltages for each pin. This increases the cost of the components without bringing any real benefit. If you look at the supported components, you will probably find it very difficult to find ICs that are not supported.

The RCT was originally created only as a tool for repairing devices in my own collection. I've been collecting (home-)computers for almost 40 years and have now reached over 1000 devices, so it's normal for one to be defective every now and then. My personal RCT has tested several thousands of ICs in the last three years and and has survived some strange experiments. So when I started to implement the EPROM programming code the device also survived 28V. It is a pretty robust peace of hardware. Maybe not perfect in every detail but it does his job well.

I'm still amazed at how well the RCT is accepted by the community. It is primarily used by collectors of arcade machines, pinball machines, synthesizers and of course home computers. But there are also a few repair shops that use it.

Regards,
Stephan aka slabbi

Thanks for the extensive answer, I started this topic (you might have seen the translation ) to understand how the RCT works, as I also made a handful of "Stand alone testers" eg for the 2114 etc. , for some others I use my TL866 but its hard to add your own IC's there. So I was also looking for something more universal.

@Arco as far as I can see for the "Exotics" (e.g 2708) or chips with some weird power pin assignment a whole bunch of adapter PCB's are available (also the Gerber's) on Stephan's site.

Oh, there are some other exotics supported The 2708 is maybe interesting, because it can also be programmed with an adapter (for dumping not necessary).

On http://8bit-museum.de/rct you will find four pdf files containing lists with supported DRAMs, SRAMs, PROMs, logic ICs.

In these lists some really exotic ICs are listed. Some have only been used in single systems.

Die 'compacte code' is juist een nadeel van C...

Eh... je bedoelt het grootste voordeel??!?

(ik heb er regelmatig 20 of zo op 1 regel gezien)

Daar hoeft helemaal niks onbegrijpelijk aan te zijn.

Nu weet ik dat je het ook netjes kunt doen, maar er zijn maar weinig C programmeurs die zich daaraan houden.

Ik denk dat de meesten het netjes en begrijpelijk doen. Ik heb zelden moeite gehad om te begrijpen wat er staat.

Tussen een assembler en compiler zit weinig verschil: beide zetten leesbare tekst in instructiecode om.

En dat is dan ook zo'n beetje de enige overeenkomst... De verschillen zijn enorm, de resultaten verschillen ook enorm. Als je zegt dat dat hetzelfde is, dan heb je duidelijk nog nooit zo'n ding geschreven en alleen maar op F-doe-wat-leuks getikt om te hopen dat windows wat zinnigs genereert (hahahaha).

De verschillen zijn enorm, de resultaten verschillen ook enorm.

Het frontend is simpelweg een parser, die jouw opdrachten probeert om te zetten in voor de betreffende processor begrijpelijke instructies.
De taal maakt maar weinig uit: assembly, c, basic, pascal, ...

Ook het resultaat hoeft niet veel te verschillen: gecompileerde (goed geschreven) basic is maar marginaal groter als assembly (if any)
Oudere compilers waren inderdaad minder efficient, maar dat is al lang niet meer zo.

De taal maakt maar weinig uit: assembly, c, basic, pascal, ..

Wat een berg onzin. In assembly hoeft dat ding helemaal niks in 'begrijpelijke instructies' om te zetten. Die heeft de programmeur al geschreven (en zo niet, dan barft het wel). 1-op-1 naar opcodes vertalen. Meer niet. Dat gaat geen enkele compiler redden - basic matched nou eenmaal niet 1-op-1 op opcodes...

gecompileerde (goed geschreven) basic

Daar zijn we dus: je moet de onderliggende assembly en architectuur kennen en de compiler begrijpen om het 'goed' te kunnen schrijven. Juist bij basic is dat 'by design' nou precies niet het idee...

Overigens wil dat niet zeggen dat je een dergelijke testtool niet in basic zou kunnen maken. Zeker voor poortjes en zo is het aantal test mogelijkheden zeer beperkt. Dus ook als het niet erg efficiënt in elkaar zit blijft het ruim sneller dat de 'tester' zelf

btw it is not RCT related but maybe it is useful for someone:

I have several NOP Testers on my website, the newest one is a NOP Tester for the MOS 6501 (do not mix with the Rockwell R6501).

I have a few prototypes available which I give away free of charge for testing purpose. When you own a 6501 and want to test this, please let me know.

Op 21 december 2022 15:28:09 schreef slabbi:
btw it is not RCT related but maybe it is useful for someone:

I have several NOP Testers on my website, the newest one is a NOP Tester for the MOS 6501 (do not mix with the Rockwell R6501).

I have a few prototypes available which I give away free of charge for testing purpose. When you own a 6501 and want to test this, please let me know.

Hi Stephan,

Thanks for the offer. Currently I only own 6502'a and Z80's , but maybe someone else is using a 6501 here.