GAL Reverse Engineering aus JEDEC

Beitrag "Re: Kann man die Programmierung von GAL wieder auslesen?" kann wahrscheinlich keine GALs.

Michael B. schrieb:

Beitrag "Re: Kann man die Programmierung von GAL wieder auslesen?" kann wahrscheinlich keine GALs.

Nice! War etwas Gefrickel so ein altes 16-bit Programm mal eben zum Laufen zu bekommen....aber es funktioniert einwandfrei, hab so das Ergebnis noch nicht verifiziert, aber sieht auf den ersten Blick gut aus!

Sagenhaft, das kann man immer noch herunterladen und das Readme sagt:

EECMOS GAL DEVICES: GAL16V8 GAL16V8A GAL16V8QS GAL20V8 GAL20V8A GAL20V8QS GAL20RA10 GAL22V10 GAL22CV10 GAL6001

Ja die alten DOS-Programme laufen einfach, ohne Treiber nachzuladen und ähnliches. Wahrscheinlich auch in der DOS-Box. Einen 22V10 in der 3,3V-Version von Philips hatte ich auch mal ausgelesen und mit JED2EQN.exe umgewandelt. http://www.next.gr/components-datasheets/22V10.pdf aber das war kein GAL. Der saß auf der Platine hier: Beitrag "Re: Philips PZ5032 CPLD freies Development Tool?" ein PAL-Prommer am Druckerport mit DOS-Software.

Yup faszinierend...

Ein File liefert einen Error "Illegal macrocell fuse configuration"...ich arbeite mich in die Materie gerade wieder rein so nach 20 Jahren, daher mal kurz in die Runde geworfen....

Ein 20V8, SYN=1, AC0=1, also complex mode. Das sollte doch bedeuten, dass es keinen Sinn macht fuer AC1 was Anderes als 1 zu setzen, oder? Bei mir sind da auch ein paar 0 gesetzt, sobald ich die Alle auf 1 konfigurier laeuft das File durch. Also, eindeutiger Fehler im JED File, oder Denkfehler von mir?

Ingo schrieb:

ich bin gerade dabei etwas reverse engineering an einem GAL20V8 zu probieren - JEDEC File ist vorhanden,

(...)

Kennt ihr aber darueber hinaus evtl. Tools die einem dabei helfen, sei es Zwischenschritte, oder vielleicht sogar gleich die ganze Logik rausknobeln?

Ich hab' mir vor Jahren ein solches Tool programmiert. Wenn Du magst, kannst Du mir die JEDEC-Datei zukommen lassen, dann disassembliere ich sie Dir und sende Dir die Gleichungen zurück.

Grüßle, Volker

Ingo schrieb:

Ein 20V8, SYN=1, AC0=1, also complex mode. Das sollte doch bedeuten, dass es keinen Sinn macht fuer AC1 was Anderes als 1 zu setzen, oder?

Das Datenblatt von ST, bzw. SGS-Thomson, aus dem Jahr 1992 zeigt eine Darstellung der Multiplexer, die von den Konfigurationsbits SYN, AC0 und AC1(n) geschaltet werden. Ich interpretiere das für SYN=1, AC0=1 und AC1(n)=0 so, dass der Ausgangspuffer der OLMC dauerhaft abgeschaltet wird. Dummerweise schaltet AC1(n)=0 bei den OLMCs der Pins 16 bis 21 den Feedback-Multiplexer auf den Ausgang des D-FF, das aber im Combinatiorical Mode nicht aktiv sein dürfte. Also sinnvoll erscheint mir diese Konfiguration nicht zu sein. Das könnte vielleicht dazu dienen einen Ausgangspin des GALs permanent zu deaktivieren.

Grüßle, Volker

Christoph db1uq K. schrieb:

Ja die alten DOS-Programme laufen einfach, ohne Treiber nachzuladen und ähnliches.

Wenn du was in Python suchst, kannst du das hier probieren: https://github.com/ChrisEAlfred/galparse

Ich habe das mal an den gal16v8 angepasst, das ist hier zu finden: https://github.com/nospam2000/galparse/tree/gal16v8

Viele Grüße,

Michael

Ich hatte noch ein zweites Programm, JED2AHDL von DataIO, im Synario-Paket enthalten. Ebenfalls ein DOS-Programm: http://ebook.pldworld.com/_semiconductors/Atmel/Databook%20CDROM/Atmel/prod147.htm da kann man es anscheinend einzeln herunterladen.

Hier mein JED-File und das daraus erzeugte ABL-File, nur mit symbolischen Namen. Der Rest ist noch reverse engineering ähnlich dem Disassemblieren fremder Programme.

Ich sehe gerade, das Programm hat ein "Jahr 2000 Problem" Created by JED2AHDL ABEL 6.00 on Wed May 19 11:57:04 19;0 das sollte 2010 heissen.