Announcement: there is an English version of this forum on 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
DAS PAL22V10 lässt sich als GAL22V10 auslesen wenn die Sicherung nicht gesetzt ist. Programmieren geht nicht.
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
Wenn das Teil kombinatorisch arbeitet kann man eine Wahrheitstabelle aufstellen, bei registered Betrieb wird das seeehr sportlich.
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
Beitrag #5028821 wurde von einem Moderator gelöscht.
Hallo, naja, etwas anderes kann ich in einer 25 Jahre alten Maschine nicht erwarten :). 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.
Es gab mal von Atmel ein Programm WinCupl inkl. Testversion Damit kann man unter Win Gal-Gleichungen compilieren zu Jedec.
Angehängte Dateien:
-
Platine_Front.png
1,4 MB -
Platine_Rueck.png
1,7 MB
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.
Nun Gal kann er ja programmieren. Sind ja kompatibel. Problem immer noch die Logik.
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.
unter http://www.techno-junk.org/ Menu Old News - 2009 findet man Hinweise, wie man protected pals/Gals liest.
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
Alternativ könntest du bei diesen Leuten (->porchy) anfragen, ob sie es lesen könnnen: http://www.jammarcade.net/
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 ...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.