Hallo liebe Forengemeinschaft,
ich habe hier vor mir ein defektes und etwa 25 Jahre altes Schweißgerät
vom Typ ESAB DTC 200, welches ich versuchen möchte, wieder lauffähig zu
bekommen.
Laut Aussage des Vorbesitzers, liegt ein Defekt an der Steuerplatine der
Maschine vor. Optisch konnte ich keinen Fehler finden. Daher werde ich
mich langsam vorarbeiten müssen.
Die Platine besteht im Wesentlichen nur aus älteren analogen und
digitalen Standardkomponenten. Bis auf einen PAL vom Typ PAL22V10.
Da ich evtl. einen Bock bei der Untersuchung der Schaltung schießen
könnte, möchte ich das "Programm" des PALs gerne vorher sichern, da
alles, bis auf diesen Stein ersetzbar ist. Nur habe ich mit diesen
Bausteinen keine Erfahrung.
Sollte das Copy-Protection-Bit nicht gesetzt sein, so würde ich den
Inhalt gerne auslesen und sichern, um ggf. später einen neuen Stein als
Ersatz beschreiben zu können. Wie mache ich das? Könnt Ihr mir für den
PAL22V10 ein preiswertes Lesegerät empfehlen?
Ich verfüge leider nur über einen preiswerten Eprommer vom Typ TL866 aus
Fernost. Dieser unterstützt keine PALs, lediglich der GAL22V10 wird
unterstützt. Beide Steine dürften kaum kompatibel sein.
Ich würde mich über weiterführende Tipps sehr freuen.
Mit freundlichem Gruß
Schmidt
Hallo karadur,
das wäre ja schon einmal ein Anfang. Für ein evtl. Programmieren müsste
ich die eingelesenen Daten anschließend konvertieren?
Lattice bietet da, glaube ich, etwas an. Aber auch GALs scheint es
mittlerweile immer schwerer zu geben.
Sollte das Protection-Bit gesetzt sein, gibt es Tools, mit denen man die
Funktionsweise analysieren und dieses in einen "Code" umsetzen kann?
Also eine Funktionsbeschreibung des nicht auslesbaren Chips?
Mit Dank und Gruß
Schmidt
Versuchen die restliche Schaltung zu untersuchen was Eingang und was
Ausgang ist.
Mit Datenblatt und Testvektoren schauen was an den Ausgängen passiert.
Hallo,
genau an so etwas habe ich gedacht. Da am PAL/GAL die eine Seite des
Chips mit fixen Eingängen versehen ist, und die andere mit IOs, sollte
die Anzahl der Kombinationsmöglichkeiten beschränkt sein.
Es wäre dann nur interessant, das Ergebnis gleich wieder in eine
programmierbare Datei zu überführen, so dass der neu programmierte Stein
sich verhält wie der analysierte.
Gibt es da bereits etwas?
Mit Gruß
Schmidt
Schmidt schrieb:> sollte> die Anzahl der Kombinationsmöglichkeiten beschränkt sein.
na da wünsche ich dir viel Erfolg wenn da eine Statemachine
implementiert ist...
Schmidt schrieb:> sollte> die Anzahl der Kombinationsmöglichkeiten beschränkt sein.
Das dürfte ein Irrtum sein, bzw. das stimmt höchstens bei einer rein
kombinatorischen Schaltung, was aber extrem unwahrscheinlich ist. Der
Baustein enthält aber 10 Flipflops und kann daher theoretisch 1024
verschiedene Zustände annehmen und in jedem Zustand anders auf die
Eingänge reagieren.
Man müsste daher nicht nur die möglichen 4096 Eingangskombinationen
durchspielen, sondern alle Permutationen davon. Das sind viele
Millionen.
Georg
Hallo,
ich bin in dieser Technologie leider nicht firm und werde mich auch
wegen des einen Problems nicht tief hierein einarbeiten wollen.
Es erschien mir nur "abschätzbar", da es eine verhältnismäßig geringe
Menge an Funktionspins gibt, von denen einige fixe Pinfunktionen
aufweisen und es eine beschränkte Anzahl von möglichen Ausgängen gibt.
Dazwischen befinden sich eine Matrix mit angegliederter Logikfunktion,
die auf Gruppen von Spalten zugreifen und eine Ausgangsstufe.
Natürlich wird es mit allen Permutationen sehr viele Kombinationen
geben, die in eine Wahrheitstabelle überführt werden könnten. Aber es
stellt sich damit noch immer eine wesentlich einfachere
Ausgangssituation dar als z.B. bei einem Cyclon V :)
Daher fragte ich, ob es hierfür bereits Tools oder Prozesse gibt, um
PALs auch "reverse" zu sichern.
Mit Gruß
Schmidt
Was sind schon ein paar Millionen Kombinationen?
Die sind doch in wenigen Sekunden durchprobiert.
Was ich sicher weiß, dass man geschützte PEELs kopieren kann.
Und PEELs sind quasi GALs vom Hersteller International CMOS Technology
(ICT) corporation.
Die Flipflops kann man von außen gezielt setzen (Debug-Mode?).
Und von jeder FF-Kombination legt man alle Eingangskombinationen an und
schaut, was an den Ausgängen passiert.
Die Rückkopplungen müssen ebenfalls berücksichtigt werden.
eProfi schrieb:> Was sind schon ein paar Millionen Kombinationen?> Die sind doch in wenigen Sekunden durchprobiert.
Das mag ja durchaus zutreffen aber ein Programmiergerät erwartet
üblicherweise ein JEDEC-File und das hat man nach so einer Aktion noch
lange nicht.
Zunächst wäre es interessant, zu sehen, wo genau das PAL verbaut ist.
Wenn das beispielsweise eine Schaltung mit einem Microprozessor und
externem RAM/ROM sowie etwas Peripherie ist, dann kann das Ding ein
simpler Adressdecoder sein.
Zeig' doch mal ein Bild der Platine.
Hallo,
ich habe euch mal zwei Photos von der Platine gemacht. Wie gesagt,
handelt es sich hierbei um die Steuerplatine eines ESAB DTC 200
WIG-Schweißgerätes. Unterlagen zur Schaltung selbst konnte ich bislang
nicht ausfindig machen. Vielleicht hat einer von euch hierfür Unterlagen
oder eine Quelle?
Der PAL ist rechts neben dem Netzteil. Der Aufkleber auf dem Netzteil
zierte zuvor den Chip. Die Beschriftung ist auch im Original sehr
unleserlich. Das Logo könnte von AMD stammen. Typenbezeichnung:
PAL22V10-15PC 9430ABA A.
Ich bin für jeden Tipp dankbar.
Mit Gruß
Schmidt
karadur schrieb:> Es gab mal von Atmel ein Programm WinCupl inkl. Testversion
Mit CUPL (Vollversion) habe ich früher mal gearbeitet, war richtig toll:
Wahrheitstabelle eintippen, File erzeugen und Stein brennen anstatt drei
Tage Gatter zu löten.
Ich habe nie versucht, ob sich PAL und GAL überhaupt auslesen lassen und
auch keine funktionsfähige Programmierumgebung mehr dazu. Bausteine sind
noch einige vorhanden.
karadur schrieb:> DAS PAL22V10 lässt sich als GAL22V10 auslesen wenn die Sicherung> nicht gesetzt ist.
Kaum. Ein GAL funktioniert in Betrieb wie ein PAL, aber die Programmier
und Ausleseschnittstelle sind komplett anders. Das PAL hat schlicht
keine Ausleseschnittstelle.
> Programmieren geht nicht.
Ging halt nur ein Mal, beim Hersteller.
Schmidt schrieb:> ich habe euch mal zwei Photos von der Platine gemacht.
Danke dafür. Man erkennt, daß es definitiv keine
Microcomputer/-Controller-Schaltung ist, daher ist die These
"Adressdecoder" gleich ad acta zu legen.
Warum aber in drei Teufels Namen postest Du das als *.png? Das sind
Photos! Dafür ist das *.jpg-Format da.
PNG ist für Zeichnungen (nicht gescannte oder photographierte, sondern
am Computer mit entsprechenden Programmen gezeichnet) und für
Screenshots (nicht mit dem Handy photographiert). Für nix anderes.
MaWin schrieb:> Das PAL hat schlicht> keine Ausleseschnittstelle.
Typisches Mawin-Viertelwissen. Wieso kann dann mein Programmierer ein
PAL auslesen und als Jedec speichern?
Georg
Rufus Τ. F. schrieb:> Warum aber in drei Teufels Namen postest Du das als *.png?
Wie kann einer nur bei einem Hindu zu Besuch kommen und ihm einen
Rinderbraten mitbringen? Er würde mit Recht geköpft! ;)
Rufus Τ. F. schrieb:> in drei Teufels Namen
Muß doch sehr bitten. Pfingsten steht vor der Tür!:-)
Rufus Τ. F. schrieb:> PNG ist für Zeichnungen (nicht gescannte oder photographierte, sondern> am Computer mit entsprechenden Programmen gezeichnet) und für> Screenshots (nicht mit dem Handy photographiert). Für nix anderes.
Gewagte These...
MaWin schrieb:> Das PAL hat schlicht> keine Ausleseschnittstelle.
Bei den alten PALs wurden noch richtig Leiterzüge durchgebrannt, daher
kommt auch den Name Fuse bzw. Brennen fürs Programmieren.
Es wurden solange Stromstöße durchgejagt, bis das Rücklesen fehlerfrei
war. Das Rücklesen war also zwingend notwendig.
bilddirdeinemeinung schrieb:> Muß doch sehr bitten. Pfingsten steht vor der Tür!:-)
Man kann ja auch schreiben png ist haram und jpg ist halal wenn dir das
mehr zusagt.
Georg
Haben noch viele PALC22V10-15 (Cypress) und können sie auch noch
programmieren mittels einem ALL07. Falls das Auslesen klappt könnte ich
eines programmieren.
Hallo,
bevor meine Bildformatwahl nun Anlass für theologische
Auseinandersetzungen wird: Ich verwende PNG, weil es ein freies und
verlustfreies Bildformat darstellt.
Mit Gruß
Schmidt
Schmidt schrieb:> Ich verwende PNG, weil es ein freies und> verlustfreies Bildformat darstellt.
Verlustfrei ist völlig überflüssig.
Als JPG hätte man aber Bilder dieser geringen Qualität bequem auf
50..100kB eindampfen können.
Es soll ja Leute geben, die keine Flatrate haben.
Hallo,
vielen Dank. Das werde ich mir gleich ansehen.
Gruß
Schmidt
P.S. Das mit der Flatrate ist ein Argument. Die "geringe" Qualität
stammt daher, dass ich das Bild zur Datenreduktion vorher bereit auf 33%
verkleiner hatte. Gut, damit ist das Argument für verlustfrei auch
wieder verpufft :)
sabber schrieb:> unter http://www.techno-junk.org/>> Menu Old News - 2009>> findet man Hinweise, wie man protected pals/Gals liest.
Meinst du diesen Abschnitt:
Zitat von http://www.techno-junk.org/> If you do not want to build the PAL reader, there is a very low-cost> alternative for dumping combinatorial (not registered) PALs. You can> construct an adapter that connects a 20-pin PAL to a 32-pin socket. By> reading the PAL in a device programmer as a 27C020 EPROM you will get a> 256K dump which the PAL analysis software can interpret.
Das funktioniert in der Tat.
Aber nur wenn - wie im Abschnitt erwähnt und auch weiter oben schon
festgestellt - der GAL eine rein kombinatorische Logik enthält.
Ist eine State-Machine implementiert kannst du das Ergebnis vergessen da
es ja mehrere Zustände gibt und man keinerlei Ahnung hat ob das Ergebnis
nun die korrekte Wahrheitstabelle für einen Zustand (von vielen) oder
ein Mischmasch aus verschiedenen Zuständen darstellt. Mal ganz davon zu
schweigen um welchen Zustand bzw. welche Zustände da gerade abgebildet
wurden.
Einen Versuch ist es vielleicht Wert.
Falls sich der PAL nicht auslesen lässt diesen so behandeln als ob er
nur kombinatorische Logik enthält. Die Wahrheitstabelle aufstellen und
dann überprüfen ob diese Wahrheitstabelle mit den tatsächlichen Abläufen
im Gerät vollständig übereinstimmt (bzw. übereinstimmen kann).
Gibt es Abweichungen, so ist eine Statemachine implementiert. Dann
bleibt für den Fall das man wirklich genötigt ist den PAL zu ersetzen
nur die sonstigen Schaltungsfunktionen zu identifizieren und zu
überlegen wie diese Angesteuert werden müssen um selbst die
Konfigurationsdaten zu entwerfen.
Gruß
Carsten
Carsten S. schrieb:> Ist eine State-Machine implementiert kannst du das Ergebnis vergessen da> es ja mehrere Zustände gibt und man keinerlei Ahnung hat ob das Ergebnis> nun die korrekte Wahrheitstabelle für einen Zustand (von vielen) oder> ein Mischmasch aus verschiedenen Zuständen darstellt. Mal ganz davon zu> schweigen um welchen Zustand bzw. welche Zustände da gerade abgebildet> wurden.
Das kann man durchprobieren. So groß sind die State-Machines bei diesen
alten Bausteinen nicht.
Schreiber schrieb:> Das kann man durchprobieren. So groß sind die State-Machines bei diesen> alten Bausteinen nicht.
Ich habe schon vorgerechnet, dass das ein paar Millionen sind. Natürlich
kann das ein Testautomat durchspielen, aber damit hat man kein
Jedec-File zum Programmieren - was der Baustein mit seiner
Innenschaltung realisieren kann, ist ja nur eine Teilmenge aller
möglichen Permutationen. Man müsste also diese Millionen Daten nehmen
und die Redundanz solange reduzieren, bis das Ergebnis zum
physikalischen Aufbau des Bauteins passt. Hast du eine geeignete
Software, oder schüttelst du die aus dem Ärmel?
Georg
Bei einem 22V10 hängen alle Takteingänge der Flip-Flops in den
Makrozellen am Pin 1. Ansonsten gibt's da nur noch einen P-Term für
asynchrones Reset und einen für synchrones Preset (jeweils gemeinsam für
alle).
Zwar könnte man auch ohne diese Flip-Flops durch die kombinatorische
Logik Latches oder Flip-Flops realisieren, aber das wäre
Resourcenverschwendung. Und die PALs waren zu der Zeit teuer und die
Programmierausbeute deutlich unter 100%. Einen Großteil der Terme zum
Nachbau von Flip-Flops zu verschwenden, ist da relativ unwahrscheinlich.
Also einfach mal kontrollieren, was am Pin 1 so dran hängt, dann
erübrigt sich jede weitere Spekulation um State-Machine ja/nein ...
