EPROMs auslesen - Fallstricke

    Hallo zusammen.


    Während der Vorbereitungen zur Ablösung des regulären 3,5" Diskettenlaufwerkes gegen einen Gotek Floppy-Emulator beim SNI PCD-3M/25 wollte ich den Austausch nutzen, um einige EPROMs von installierten AT-Erweiterungskarten zu sichern bzw auszulesen, um der Katastrophe zuvorzukommen, wo möglich.


    Ich verwende einen Batronix Batego II BX-48 und Prog-Express V3.7.x unter Ubuntu 10.04LTS. Ja, ja - etwas älter.:fp:


    (I) Mit einer MG-128E lief es gut. Dann wollte ich die EPROMs des Adaptec AHA-1542A auslesen, das mit zwei NMC27CP128Q-200 (12.5V) bestückt ist. Diese Größenvariante fehlt in der Liste des Programmes zur Vorauswahl. Kann man da einfach irgendeinen, ähnlichen EPROM von AMD, Intel o.a. nehmen? - Ggf mache ich mir auch unnötigen Aufwand und die ROMs gibt es schon (wieder) irgendwo im Netz. Hatte ich net explizit vorher er-g**gle-t




    (II) Dann sollte noch der EPROM der Netzwerkkarte gesichert werden. Da finde ich kein EPROM der mir bekannten Größe. U15 mit Aufkleber (MAC) ist das einzige, gesockelte IC mit Aufkleber. Da kann ich kein Fensterchen wahrnehmen unter dem Aufkleber. Die anderen, beklebten IC's sagen mir auch nichts. Auffälliges?



    (III) Kann NSSI die ROM's auch komplett auslesen? Hatte das vorher noch gemacht und dann hat das Diskettenlaufwerk wahrscheinlich Spur 0 überbügelt mit dem Index einer anderen Diskette. Das war schräg. Alle vorher mit NSSI ausgelesene Daten waren dann nicht mehr lesbar. Und da ich tierisch angefresen war, wurde die Diskette an Ort und Stelle zerknietscht und per Luftweg in die dunkelste Ecke befördert, was eine Wiederherstellung der Daten nun aussichtlos macht. Dieser Ausbruch ist mir lange net mehr... :aerger:


    (IV) Können Am27C010-205DC EPROMs beim Auslesen einen Defekt erleiden, wenn man ein alternatives Modell des selben Herstellers, jedoch mit größeren Zugriffszeiten selektiert? ...



    ... Die Checksum hatte bei beiden, mir vorliegenden EPROM-Bausteinen Abweichungen. Nach Wiedereinsatz wollte die SS1+ nichts mehr über die serielle Konsole ausspucken. Inzwischen hat die SPARCstation 1+ inklusive EPROMs bei herrwieger ein neues Zuhause gefunden. Anhang der betroffenen EPROM-Inhalte SUN-525-1108-05-AK-OBP1.3.zip für alle die es interessiert - Alternativ kann man auch OBP 2.9 für die SS1+ nehmen.


    Gute Nacht.

    EPROMs sollten nach Möglichkeit immer entnommen werden und in einem Programmer ausgelesen werden, da nicht selten Adressbereiche umgemappt werden und das was irgendwelche Software "ausliest", nicht dem Original entspricht.


    Adaptec Hostadapter und modernere BIOS (mit Extended ROM area bzw. Protected Mode Biosteil) sind notorische Beispiele dafür. Oder Grafikkarten, die einen Teil des ROMs je nach gewählter Konfiguration mappen.

    Bezüglich des Adaptec, die Images gibts auf microsemi zum Herunterladen.


    Netzwerkkarten brauchen nur ROM, wenn sie booten können sollen. Bei Deiner ist der EPROM-Sockel leer. Und dass das OTPROM mit der MAC kaputtgeht, ist weniger wahrscheinlich als Datenverlust durch Selbstentladung der EPROM-Kondensatoren (speziell, wenn mit dem sog. "Intel-Algorithmus" gebrannt wurde).


    EPROMs mit langsameren Zugriffszeiten zu nehmen, funktioniert nur, wenn im Original-Design auch mehr Luft drin war. Tipp: Fotos von der entsprechenden Hardware im Web sichten. Da sieht man oft, dass der Hersteller oft auch langsamere oder schnellere Chips verbaut hat, wohl abhängig davon, was gerade am einfachsten verfügbar war. Die EPROms gehen davon nicht kaputt, aber die Daten sind u.U. nicht stabil genug, wenn man zu langsame Teile nimmt.

    Das war an sich nicht die Frage:


    Nein, beim Auslesensollte es kein Problem sein, dem Eprommer einen alternativen, langsameren Typ zu nennen. Auch die Programmierspannungen sind dabei herzlich egal, an sich muß nur das Pinout gleich sein. Wenn der Eprommer allerdings eine genaue Bestimmung des EPROM-Typs vornehmen will und die scheitert, kann es sein, dass er das EPROM-Lesen auch verweigert.


    Tobias

    Zitat von 6502

    Bezüglich des Adaptec, die Images gibts auf microsemi zum Herunterladen.

    Ausgehend von https://storage.microsemi.com/de-de/support/_eol/index.php nicht...

    https://storage.microsemi.com/…upport/_eol/isa/aha-1540/

    https://storage.microsemi.com/…upport/_eol/isa/aha-1542/

    https://storage.microsemi.com/…a-1540a&dn=aha-1540a.html

    https://storage.microsemi.com/…a-1542b&dn=aha-1542b.html

    https://storage.microsemi.com/…1542cf&dn=aha-1542cf.html

    https://storage.microsemi.com/…1542cp&dn=aha-1542cp.html


    Mal schauen ... leider nein

    http://files.mpoli.fi/hardware/HDD/ADAPTEC/

    Danke. Ist gut für die Nachfolgemodelle B/CF/CP. Leider nichts dabei für den AHA-1540/1542A.



    Der NMC27CP128Q weicht laut Datenblatt einzig bei den Pins 20 und 27 etwas ab, bspw vom selben Hersteller beim NMC27C64 und von TI, AMD.


    Pin# ; </> ; NMC27CP128 ; NMC27C64 ; AM27C128 ; TMS27C128JL
    27 ; > ; AR ; PGM ; PGM ; PGM
    20 ; > ; CE / PGM ; CE ; CE ; E

    Legende

    CE, E#, E := Chip Enable Input

    PGM, P#, P := Program Enable Input

    AR := Block Select Input







    Geht nun einer der Alternativen, bspw. TMS27C128? Diese EPROMs sind auf einem zweiten Board gesteckt?

    Der AHA-1542A wurde von Adaptec schon viel länger nicht mehr unterstützt als die späteren Varianten.

    Überrascht mich aber trotzdem, dass das letzte BIOS-Update nicht zum Download vorrätig ist.


    Bezüglich der EPROMs, entscheidend ist nicht der Name, sondern was in den Datenblättern zur Verwendung der PGM/Enable Pins steht, die Programmierspannungen usw. Die Adress- und Datenpins sind bei allen gleich, die "Steuerpins" nennt jeder Hersteller nach seinem Geschmack.

    Die Datenblattwühlerei muss ich mir bald auch antun, wenn ich den ganzen Epromkram hier auf Halde abarbeite :fp:

    Ergänzung: Batronix BATEGO II BX38 - mit Firmware Version 02.08


    Teilerfolg. Vom zweiten Controller - ein AHA-1540A ASSY 416006-04 Rev D - wurden die EPROMs mit Chip Select "TMS27C128-JL" für BIOS mit dem TMS27C128JL sowie BIOS (V4.04) mit dem TMS27C128-2JL ausgelesen.




    Falls jemand seine Sammlung vervollständigen möchte/muss/will, die Firmware-/EPROM-/BIN-Images des Adaptec AHA-1540A / AHA-1542A wurden angehängt.


    Für den NMC27CP127Q-200 mit Chip Select "TMS27C128-JL" ging es schief, zumindest für die Checksum.

    Muss mal den

    Beim ersten Board - Adaptec Inc. AHA-1542A, ASSY 416006-03 Rev D, FCC ID: FGT5AG1542A - gab es bei der Checksum eine Fehlermeldung und auch die Error-LED des Gerätes war aktiv. Das habe ich dann ignoriert und den Lesevorgang fortsetzen lassen.


    MCODE





    BIOS




    Neue Anhang, inklusive dieser BIN-Dateien im Anhang.


    Morge teste ich ob dieses Board noch tut. Dazu muss das Gotek nochmal ab- und ein anderes Floppy angehangen werden. Zusätzlich noch ein SCSI-Device extern anschließen. Dann von Diskette mit den Treibern booten und mittels debug.exe ins Adaptec Konfig-Menü springen. - So eine Wuselei.


    Nachtrag:


    Dachte auch kurz, das Versions-Schema identifiziert zu haben, leider nach Vergleich mit Versionsangabe im Hex-Editor bei gelandenem BIN nicht deckend. Beispiel BIOS 420404 vom zweiten Board 15"42" ist Version "04.04" --> 420404. Ging beim ersten Board mit 420407 und Version "04.05" nicht auf. Ggf. ist die Angabe "XXYYYY-ZZ A" eher eine Part# von Adaptec.

    Zitat von fritzeflink

    Ich musste etwas suchen aber meim MEMPROG hat den

    Beim auslesen des EPROM per Brenner ist der eingestellte Typ unkritisch.


    Der Typ des EPROM ist wichtig beim schreiben, wegen der unterschiedlichen Spannungen und Programmier Algorithmen.


    Sonst müsste man im Computersystem auch irgendwo den Typ einstellen ...

    Dieser Thread hat mich gerade darauf gebracht, dringend mal mein AMI BIOS von meinem 386er Board 386L V1.0 auszulesen. Der Rechner ist relativ oft im Einsatz und ohne BIOS wäre dann Essig.


    ARA386DX


    Elitegroup Computer Systems, Inc.

    ECS 386L V1.0

    Chipset: ITOPDX D01131 050591

    AMI 386L-011 BIOS Chip


    Das hat wunderbar geklappt. Gut, dass es da noch alte BIOS-Tools gibt. ;)

    Adaptec AHA-1540A funktioniert nach wie vor. Das BIOS kann sowohl für den 1540A als auch 1542A verwendet werden.


    Mir stellen sich noch weitere Fragen die sich aus den vorangegangenen Beiträgen ergeben:


    1) Welche Auswirkung hat eine abweichende Checksum beim Auslesen auf das Ergebnis (BIN)?


    2) Lässt sich das OTPROM (one-time PROM) der Netzwerkkarte mit Hilfe eines Adapters über den Programmer auch sichern/auslesen?


    3) Wie gelötete ICs mit Aufkleber und Beschriftung auslesen, die vermuten lassen, das es sich auch um "Firmware" handelt? (Bspw VGA-Karten) - Über Kontakt-Klemmen? :grübel:


    4) Welche Rolle spielt das Byte Ordering? - Beim Auslesen anscheinend nicht, da sich das im Hex-Editor bzw später nachträglich änder lässt.


    5) Welche Faustformel kennt ihr bzgl Auswahl/Verwendung des Byte Ordring beim EPROM-Handling?


    Heute geht es dann mit anderen Boards und deren EPROMs weiter. Ich ergänze dann die BINs der Einfachheit halber hier per Anhang. Das kann gern fortgesetzt werden. Ggf Firmware die es woanders nicht gibt.

    Kann oder mag meine Fragen keiner beantworten?


    Ferner zeigen sich weitere Fallstricke auf einigen der Boards: es geht um die Antwort auf Frage #3, bzgl der Programmable Logic Devices (PLD).


    So gut wie alle SNI Boards sind mit Aufklebern auf den (meist verlöteten) Bauteilen versehen und damit sicher PLDs (PLA, PAL, GAL usw).


    D458 / D519:


    D512:


    D525 (ausnahmsweise alle gesockelt):


    D534:

    ...alternativ...


    D674:


    MG-128:


    Habe mal etwas im Wikipedia gestöbert:


    https://en.m.wikipedia.org/wiki/Programmable_logic_device


    Folgend noch Links mit Infos, in denen beschrieben ist, wie man ein Dump von einiges der PAL-Typen (combinat. logic) erstellt. Davon habe ich keine Ahnung. Mal schauen, ob der BX48 kann, mit Adapter.


    https://www.edaboard.com/showt…Protected-PAL-GAL-reading

    führt mich auf -->

    https://web.archive.org/web/20…emuviews.com/elec/pal.php

    https://web.archive.org/web/20…uviews.com/pal/index.html


    Und soweit wollte ich in PLDs nicht einsteigen. Wie soll ich von denen denn bitte ein Dump erstellen, wenn die auch noch verlötet sind? Ggf sind das auch noch registered PALs.


    Ideen ggf dazu, evtl auch mit einigen Antworten zu meinen vorhergehenden Fragen? :capone: Na dann gute Nacht! X/

    • Offizieller Beitrag

    Ich sehe hier reichlich Auseinandersetzung mit dem Thema. Welche Deiner Fragen sind unbeantwortet?

    Wenn Du klare Fragen formulierst, kann man Dir besser helfen.

    Wenn Du wissen willst, was das für Bauteile auf den SNI Boards sind, musst Du wohl die Aufkleber runtermachen.

    Ich frage mich allerdings, ob es Vernünftig ist, ohne Not daran rumzulöten.

    Ich versuche mal, die Fragen, die ich sehe, zu beantworten:


    1. Auslesen eingelöteter Bauteile. Kann funktionieren, muss aber nicht. Funktioniert nur, wenn der Baustein während des Auslesens durch umgebende Schaltkreise (z.B. Bustreiber) volkommen isoliert ist. Das ist oft nicht der Fall - Dann liest du nicht den Inhalt des Bausteins, sondern die umgebenden Logikpegel. Deine Kopie ist dann keine. Ich würde grundsätzlich alle Bauteile aus ihrer Schaltung entfernen. Wenn das nur durch Auslöten geht, kommt das Risiko dazu, dass man mehr kaputt als ganz macht. Würde ich nur in seeeehr dringenden Fällen machen.
    2. Auslesen von PLDs. Kann gehen, muss aber nicht. Praktisch alle PLDS (PAL, GAL, CPLD) besitzen eine brennbare Security-Fuse, die das Auslesen verhindern soll. Die ist ziemlich sicher bei den meisten kommerziell verkauften Geräten gebrannt. Dann kannst du mit deinem EPROMmer nichts mehr ausrichten. Solche Bausteine lassen sich nur über eine Behavior-Analyse (alle Eingänge in allen Kombinationen durchtickern, kucken, was an den Ausgängen rauskommt, daraus die Logik rückwärts ableiten und daraus ein neues JEDEC mit gleichem Verhalten erstellen) auslesen. Das erzeugt nur eine neue Logik mit gleichem Verhalten, nicht notwendigerweise eine exakte Kopie. Das funktioniert ganz gut bei rein kombinatorischer Logik, sobald der Chip ein Register (also einen "inneren Zustand" - PALs mit "R" im Namen) hat, wird das extrem komplex bis unmöglich, vor allem, wenn man nichtmal ungefähr weiß, wozu der Chip eigentlich gut ist (also, was er eigentlich machen müsste) und ob er überhaupt nur kombinatorische Logik drin hat. Vergiss es. Um das richtig hinzukriegen, muss man die gesamte Schaltung verstehen.
    3. Die Frage mit der "abweichenden Prüfsumme" beim Auslesen verstehe ich nicht. Wo nimmst du die Prüfsumme her und von welcher weicht sie ab?
    4. OTPROMs (ich denke du meinst maskenprogrammierbare ROMs, keine OTP-EPROMs) lassen sich genauso gut oder schlecht wie andere ROMs lesen. Nur kann man die nirgends im Laden kaufen. Ein passender Ersatzbaustein (z.B. ein EPROM mit passender Pinbelegung oder durch Adapter-Sockel angepasster Pinbelegung) muß also verfügbar sein, sonst bringt dir deine Kopie nichts, wenn du nichts hast, wo du sie reinprogrammieren kannst.
    5. Gelötete ICs siehe oben. Da kannst du alles Mögliche lesen, was da gar nicht drin ist. Lieber lassen. Und nicht deswegen auslöten. Sowas macht man nur in absoluten Notfällen.
    6. Byte Order ist vollkommen egal, solange du den Inhalt nicht verstehen (z.B. disassemblieren) willst. Einfach auslesen, wie es kommt und ins .bin packen. Solange die Kopie genau gleich ist, auch nix mit Hex-Editor oder sonstwas ändern.
    7. Die Frage nach der "Faustformel fürs Byte Ordering" verstehe ich auch nicht. Solange deine Kopie eine exakte Kopie des Chip-Inhalts ist, und in einen neuen, equivalenten, Baustein gepackt werden kann, ist die Byte Order doch egal.


    Tobias

    2 Mal editiert, zuletzt von tofro ()

    Gefällt mir 4
    Zitat von Toast_r

    Welche Deiner Fragen sind unbeantwortet?

    Die Fragen sind in Post #13 formuliert und Dank Tobias ( tofro) sind es inzwischen weniger.



    Meine Hauptsorge mit den PLDs kam auch erst auf, als ich wissen wollte um was es sich bei den Bausteinen mit Aufklebern handelt. Da man deren Funktion nun also nicht durch bloßen Neukauf wiederherstellen kann, auch nicht zwingend mit Dump/Analyse wurde ich schon nachdenklich.

    Das Datenblatt mit dem folgenden Absatz hat mir dann den Rest gegeben und jetzt habe ich Panik bzw. ...

    Zitat von Lattice Semiconductor GAL20V8 Datenblatt, p.1

    In addition, 100 erase/write cycles and data retention in excess of 20 years are specified.

    ... wieder um eine bittere Erkenntnis reicher. - Glücklicherweise haben einige Boards glücklicherweise keine PLDs, leider auch einen niedrigere Leistungsklasse


    Danke Tobias für Deine Antworten! Auf deine Gegenfragen versuche ich so gut mir möglich einzugehen.


    Zitat von tofro
    1. Auslesen eingelöteter Bauteile. Kann funktionieren, muss aber nicht. (...) Würde ich nur in seeeehr dringenden Fällen machen.

    Soweit will/wollte ich auch nicht gehen müssen bzw. kann ich das auch (noch) nicht. Also lasse ich es.


    Zitat von tofro
    2. Auslesen von PLDs. Kann gehen, muss aber nicht. (...) nur über eine Behavior-Analyse (alle Eingänge in allen Kombinationen durchtickern, (...), daraus die Logik rückwärts ableiten (...)) auslesen. (...)

    Dazu dient dann das PCB unter den angegebenen Links aus Beitrag #14, das von den (non-registered) PLDs (d.h. mit kombinat. Logik) alle Kombinationen durchgeht und deiese in ein Dump-File wegschreibt. Zumindest ein Anfang für eines der Boards, da gesockelt (bspw. D525)


    Zitat von tofro
    3. (...) Wo nimmst du die Prüfsumme her und von welcher weicht sie ab?

    Die Frage bezog sich auf die EPROMs und das Programmiergerät zum Auslesen. Das macht die Software vor dem Auslesevorgang selbst. Man kann das ignorieren und es wird trotzdem versucht auszulesen


    Zitat von tofro
    4. OTPROMs (ich denke du meinst maskenprogrammierbare ROMs, keine OTP-EPROMs) (...)

    Das bezog sich auf den kleinen Baustein auf der Netzwerkkarte mit der MAC-Adresse drin. Dachte OTP stehe da für One-Time-Programmable. Habe das von 6502 aufgegriffen, da es mir plausibel schien/scheint. Und da hat Toast_r nicht unrecht, dass man den Aufkleber enfernen sollte, um den Baustein kategorisieren zu können.


    Zitat von tofro
    5. Gelötete ICs siehe oben. Da kannst du alles Mögliche lesen, was da gar nicht drin ist. Lieber lassen. Und nicht deswegen auslöten. Sowas macht man nur in absoluten Notfällen.

    Bezog sich auf meine Frage #3 aus Beitrag #14 zu Bausteinen mit Aufklebern, also PLDs. - Ja, ich lasse die Finger davon, begriffen. :yes:


    Zitat von tofro
    6. Byte Order ist vollkommen egal, solange du den Inhalt nicht verstehen (z.B. disassemblieren) willst. (...)
    7. Die Frage nach der "Faustformel fürs Byte Ordering" verstehe ich auch nicht. Solange deine Kopie eine exakte Kopie des Chip-Inhalts ist, (...), ist die Byte Order doch egal.

    Check. Nummer 6 beantwortet 7 gleich mit. Danke nochmal!



    Noch eine abschließende Frage zu den PLDs: ist die Haltbarkeit der PLDs ähnlich zu den voll-integrierten ICs zu sehen?

    Aber eigentlich kann ich mir die Frage gleich selbst beantworten, siehe Datenblatt GAl20V8.


    Daraus kann ich nur einen Schluß ableiten - die bittere, neue Erkenntnis - das PLD-Zeug braucht kein Schwein, wenn man bedacht ist diese Hardware zu "konservieren" bzw. in meiner Lebenslage vergeudete Zeit. Ist der Aufwand vorab abzusichern nicht vertretbar oder wie in diesem Fall sehr anfällig für das Provozieren eines Schadens an der laufenden Komponente, lohnt es nicht. Das kann ich so nur mit Humor ertragen: ::gwunsch::, escimo!


    Zumindest die Diskussion hat sich definitiv für mich gelohnt. :danke: nochmal.


    Gruß, Stephan

    Zitat von escimo

    Noch eine abschließende Frage zu den PLDs: ist die Haltbarkeit der PLDs ähnlich zu den voll-integrierten ICs zu sehen?

    Aber eigentlich kann ich mir die Frage gleich selbst beantworten, siehe Datenblatt GAl20V8.

    Das Datenblatt sagt erstmal etwas darüber aus, wie oft man das PAL/GAL mit einer anderen Logik beglücken kann - und Datenblätter machen normalerweise pessimistische Schätzungen. 100-mal ist da ganz schön viel, das macht man ja nicht alle Tage, sondern typisch genau einmal. Normalerweise gehen PAL/GALs nicht sehr viel eher kaputt wie ihre TTL-Gegenstücke (aber: *). Als Vergleich: Praktisch jeder Elko in deinem Computer hat seine maximale Lebenszeit laut Datenblatt normalerweise so ab ca. 8000 Stunden Einschaltdauer (Das ist weniger als ein Jahr durchgehend!!!) überschritten. Die meisten halten aber wesentlich länger. Also laß' sich von dem Datenblatt nicht erschrecken (das gilt auch für die "Haltbarkeit" der Programmierung).


    (*) Traditionelle PALs (vor allem) und GALs werden typisch wesentlich wärmer als normale TTL-Bausteine. Da die potentielle Lebensdauer praktisch jeden Halbleiters exponentiell mit der Temperatur nach unten geht, sind PLDs auf gute Kühlung angewiesen. Das vorausgesetzt, halten sie ewig. Sonst: eher nicht.


    Tobias

    Zitat von tofro
    Zitat von escimo

    Noch eine abschließende Frage zu den PLDs: ist die Haltbarkeit der PLDs ähnlich zu den voll-integrierten ICs zu sehen?

    Aber eigentlich kann ich mir die Frage gleich selbst beantworten, siehe Datenblatt GAl20V8.

    Praktisch jeder Elko in deinem Computer hat seine maximale Lebenszeit laut Datenblatt normalerweise so ab ca. 8000 Stunden Einschaltdauer (Das ist weniger als ein Jahr durchgehend!!!) überschritten.


    Tobias

    Das mit der Elko-Haltbarkeit ist nicht richtig!

    Die angegebene Lebensdauer in Stunden bezieht sich auf den Betrieb bei maximaler Temperatur - also meist 85 Grad (oder 105 Grad C).

    Je 10 Kelvin weniger verdoppelt sich die Lebensdauer - deshalb funktionieren die 40 Jahre alten Elkos auch meist noch, wenn sie nicht ausgetrocknet oder ausgelaufen sind.

    (Die Elkos in den Flachbildschirmen, Fritz-Boxen, Sat-Receivern gehen so schnell kaputt, da sie direkt neben den Reglern sitzen, sehr heiß werden und natürlich auch viel in Betrieb sind.)


    Zum Thema GAL: In den meisten kommerziellen Schaltungen sind PAL's und keine GAL's - die waren billiger und brauchen ja in der Regel nicht noch einmal programmiert werden. Bei PAL's kann die Programmierung nicht verloren gehen, da physikalisch etwas weggebrannt wird!


    Anmerkung GAL: GAL's die geschützt sind kann man zwar nicht auslesen, aber immerhin löschen und wieder nutzen ;)


    Never Touch a Running System: Ich hab selbst schon EPROM's ausgelesen und anschließend falsch herum in die Platine zurück gesteckt... - so etwas passiert halt! Ein guter Eprom Brenner bemerkt das falsch gesteckte EPROM ja zum Glück.

    Inzwischen hatte ich einige Probleme mit teil-korrodierten Kontakten an DIP-40 EPROMs der Reihe 27c1024 . Konnte ich aber inzwischen "umschiffen" mit Hilfe eines "längs-zu-quer"-Adapter, auch als DIP-40 Sockel bekannt.



    Hatte auch Anti-Oxidationsmittel zur Hand und verwendet, das half aber nur geringfügig, auch bei mehrmaliger Anwendung. Viele der EPROM'er haben Halterungen die quer zur Längsachse der EPROMs spannen/fixieren, nicht längs wie in einem regulären Sockel. Und genau der half mir hier als "Adapter". Check.

    Zitat von Toast_r

    Durch die sehr kleine Kontaktfläche an der Schmalseite waren die ziemlich unzuverlässig.

    Kontaktfläche an der Schmalseite = Kategorie Billigfassungen.

    Bei denen von TI sind die Pins sogar von alleine rausgefallen, wenn man die gestanzte Plastikfolie unten rauszog.

    Die waren aber lange nicht die schlechtesten.

    Manche waren schon nach dem ersten IC locker und ausgeleiert.