Hallo zusammen, Ich habe hier aus dem Jahre 1984 eine tadellos funktionierende "Prozessor Karte" in einer Maschine, dich ich gern erhalten möchte. Die Hauptkomponenten darauf sind: - Prozessor: 6502 (8bit, 64k) - RAM: HM 6116 LP-3 (16k) - EPROM: 2532 (32k) - 2x VIA: 6522 Der erste Schritt wäre mit dem Galep 5 den EPROM auszulesen und den Datenstand zu sichern, ggf. auf einen 2732 mit entsprechendem Pin Swap zu brennen. Für die wenigen Leute, welche noch weltweit mit der Maschine arbeiten ist diese "Prozessor Karte" eine BlackBox. Von der ganzen Maschine gibt es Ordner voll Schaltpläne, nur der Inhalt des EPROM bzw. die Logik des damit realisierten µC ist nicht (mehr) dokumentiert. Wenn ich nun die HEX Daten aus dem EPROM habe, kann ich daraus dann über einen disassembler einen assembler oder C code bekommen, um zu verstehen, was die Karte macht? lg Frank
Frank K. schrieb: > Wenn ich nun die HEX Daten aus dem EPROM habe, kann ich daraus dann über > einen disassembler einen Assembler Ja. Aber der ASM-Code, der dort rauskommt, ist nicht nur ohne Kommentare, dort sind auch alle Variablen bestenfalls durchnummeriert. Mir etwas Glück erzeugt der Dissasembler Sprungmarken. Sowas ist nur schwer lesbar. Daraus die Funktion abzuleiten ist eine Heidenarbeit! > oder C code bekommen, um zu Eher nicht. Warum willst du die Funktion analysieren? Wenn die Black Box funktioniert, reicht das doch.
Frank K. schrieb: > kann ich daraus dann über einen disassembler einen assembler Kannst du versuchen. Aber du wirst halt keine sinnvollen Labels oder und keine brauchbaren Namen für Konstanten sehen, sondern nur Programmadressen. Und wenn ich als Programmierer gewollt hätte, dass du dich schwer tust, dann könntest du mit dem ausgelesenen "Assemblercode" nichts anfangen. Ein Sprung mitten in einen Zwei-Byte-Befehl reicht schon aus, um die meisten Reverse-Engineerer mit einem Knoten im Hirn aufgeben zu lassen... ;-) > oder C code bekommen Kannst du aus einem Kuchen wieder Eier, Zucker und Mehl machen?
Hallo Lothar M., Lothar M. schrieb: > Ein Sprung mitten in einen Zwei-Byte-Befehl reicht schon aus, um die > meisten Reverse-Engineerer mit einem Knoten im Hirn aufgeben zu > lassen... ;-) worin besteht denn da die Schwierigkeit genau? Vielleicht habe ich das Problem ja nicht verstanden, aber wenn der Zwei-Byte-Befehl von PC-1 bis PC+0 reicht, dann interessiert den Prozessor das Byte bei PC-1 doch herzlich wenig? Dann müsste ich doch einfach nur ab PC+0 neu disassemblieren???
Moin, - > - Prozessor: 6502 (8bit, 64k) > - RAM: HM 6116 LP-3 (16k) 2KByte bitte! > - EPROM: 2532 (32k) 4KByte bitte! > Der erste Schritt wäre mit dem Galep 5 den EPROM auszulesen und den > Datenstand zu sichern, ggf. auf einen 2732 mit entsprechendem Pin Swap > zu brennen. Die Platine auseinderbroeseln, mit Pieper gucken, wie die VIAs verschaltet sind (der 6116 ist von 0x0000 - 0x07ff, 2732 von 0xf000 - 0xffff, wg. der Vektoren). Du kannst latuernich disassemblen (es gibt auch SW die hilft), Emulatoren gibt es auch, aber: Why bother? Wenn das Ding tut was es soll. Gruesse Th. P.S.: gehe mal davon aus, dass der Code in 1980 per Hand gekloeppelt war. C-Compiler ist so 1990.
Peter M. schrieb: > Zwei-Byte-Befehl von PC-1 bis PC+0 reicht, dann interessiert den > Prozessor das Byte bei PC-1 doch herzlich wenig? Richtig. Dein Disassembler zeigt dir nämlich den Ein-Byte-Befehl gar nicht an, sondern nur den unsinnigen und nutzlosen Zwei-Byte-Befehl. > Dann müsste ich doch einfach nur ab PC+0 neu disassemblieren??? Ja, du müsstest aber auch wissen, dass du das tun musst. Und bis dahin hast du im einfachen Fall unsinnigen Code und im komplizierteren Fall unerklärlichen Code vor dir liegen.
Wenn das Teil von 1984 ist, kann es moeglich sein, dass der EPROM-Inhalt mittlerweile nicht mehr ganz taufrisch ist. Wenn die Steuerung allerdings jetzt noch funktioniert, dann scheint ja soweit alles zu stimmen. Trotzdem waere eine Datensicherung des EPROMs sehr anzuraten (das hast Du ja schon geschrieben). 1984 hat noch niemand solche Dinge in C programmiert. Da wurde so etwas direkt in Assembler codiert. Fuer den 6502 gibt es recht gute Disassembler, die aus existierendem bytecode wieder "lesbaren" Assemblercode machen. Sprungadressen oder Speicheradressen heissen dann eben labelABCD und haben keinen sprechenden Namen. Aber jemand, der 6502 Assembler programmieren kann, versteht, was da passiert. Da ja auch nur 4kBytes an EPROM vorhanden sind, sind das ja auch nicht sooo viele Codezeilen, die zu verstehen waeren (ca 2000). Evtl lohnt es sich da bei den C64 Fans nachzufragen (z.B. bei www.forum64.de oder forum.classic-computing.de) ob jemand bereit waere die HEX-Daten aufzubereiten und die Funktion zu extrahieren.
Lothar M. schrieb: > Peter M. schrieb: >> Zwei-Byte-Befehl von PC-1 bis PC+0 reicht, dann interessiert den >> Prozessor das Byte bei PC-1 doch herzlich wenig? > Richtig. Dein Disassembler zeigt dir nämlich den Ein-Byte-Befehl gar > nicht an, sondern nur den unsinnigen und nutzlosen Zwei-Byte-Befehl. Der Disassembler sollte schon merken, dass er mit der Sprungmarke mitten in einem Zwei-Byte-Befehl landet. Ich habe das mal mit 8051-Code gemacht, da wurde das als Fehler ausgegeben. Gerne passiert das auch in nicht erkannten Textbereichen. Etwas blickig muss man schon sein, sonst sollte man das gleich bleiben lassen. Ich wüsste jetzt auch nicht, warum sich 1980 ein Programmierer das hätte antun sollen. Am längsten sitzt man wahrscheinlich da dran, mit dem Einsprung eine sinnvolle Funktion hinzubekommen. Thomas
andi6510 schrieb: > 1984 hat noch niemand solche Dinge in C programmiert. Da wurde so etwas > direkt in Assembler codiert. Oder Basic, oder Pascal!
andi6510 schrieb: > 1984 hat noch niemand solche Dinge in C programmiert. Da wurde so etwas > direkt in Assembler codiert. Oder Basic, oder Pascal! Bilder möglich?
Dankeschön für die vielen wertvollen Hinweise, 1984 war ich gerade in der 3. Klasse ;-). Alle Komponenten auf der Platine bekommt man noch, der Inhalt des EPROMs ist eben unersetzbar. Daher als erstes sichern, dann clonen und prüfen, ob es dann noch hoffentlich läuft. Von den damals 30 gebauten Maschinen sind noch ca. 12 weltweit in Betrieb. Jemand hat schon mal im Rahmen einer Maschinen Revision die EPROMs gesichert und dabei festgestellt, dass diese sich alle unterscheiden. Vermutlich wurde diese "bahnbrechende" neue Technik damals permanent weiterentwickelt.
Moin, - es gab in den 80-er des letzten Jahrhunderts Pascal-Compiler (DOS65 z.B.), aber ob der Code Standalone laeuft ist die Frage. Das gleiche gilt fuer Basic. Gruesse Th.
Opampa schrieb: > Oder Basic, oder Pascal! Dann müsste der Basic Interpreter in einem der EProms sein. Um die Zeit gab es für den 6502 meines (begrenzten) Wissens nach keine Basic Compiler. Auch Pascal wäre da ein Exot. Frank K. schrieb: > Von der ganzen > Maschine gibt es Ordner voll Schaltpläne Sicher dass da nirgends der Assembler Code ausgedruckt dabei ist. Damals hat man Code durchaus noch auf (Endlos)papier dokumentiert.
Moin, - Frank K. schrieb: > gesichert und dabei festgestellt, dass diese sich alle unterscheiden. Oder Optionen freigeschaltet (wie beim Tesla). Die Frage ist weiter (und nicht beantwortet): Why bother? Wenn das Ding laeuft. Gruesse Th.
nun ja wie schon geschrieben 4k ist jetzt noch überschaubar. Das Ding wird ziemlich sicher in Assembler programmiert sein, zu der Zeit waren Cross Compiler noch nicht allgemein verbreitet. Damals wurde Firmware auf spez. Maschinen mit 8'' Laufwerken gebaut. PCs waren noch nicht üblich. Versuche rauszubekommen wie Ram und Eprom und VIAs im Speicher gemappt sind. Es wird vermutlich so sein, dass das Eprom am Ende und das Ram am Anfang liegt. Wenn du das Eprom hier hochlädst mach ich dir gerne einen IDA Disassembler Lauf. Der wird ohne Zusatzinfos zwar ziemlich häslich aussehen ist aber schon mal ein erster Start.
Zu meinen 8051 Assemblerzeiten habe ich aus Bequemlichkeit konstante Argumente als DB direkt hinter den Call plaziert. Die Argumentenliste war entweder konstant, nullterminiert oder das erste Argument war die Länge. Weiter ging das Programm nach der Liste, d.h. die aufgerufene Funktion hat den Returnstack entsprechend korrigiert oder ist nach DPTR gesprungen. Ein Disassembler würde sich daran bestimmt die Zähne ausbeißen und versuchen, die Argumente als Befehle zu interpretieren.
Peter D. schrieb: > Zu meinen 8051 Assemblerzeiten habe ich aus Bequemlichkeit konstante > Argumente als DB direkt hinter den Call plaziert. Du bist ja nur mies. Das ist sehr undankbar zum verstehen. Gruesse Th.
Es handelt sich um eine Gastronomiekaffeemaschine. Das ist halt nun mal so. Bis zum Gegenbeweis.
Nach Möglichkeit solltest Du zum Auslesen einen EPROM-Leser/Brenner verwenden, der das Auslesen bei verschiedenen Versorgungsspannungen beherrscht. Auf diese Art und Weise kann man erkennen, ob es Bits gibt, die auf der Kippe stehen, d.h. z.B. bei 4,3 V noch die korrekte Null, aber bei 5,1 V schon eine Eins liefern.
Peter D. schrieb: > Zu meinen 8051 Assemblerzeiten habe ich aus Bequemlichkeit konstante > Argumente als DB direkt hinter den Call plaziert. > Die Argumentenliste war entweder konstant, nullterminiert oder das erste > Argument war die Länge. Weiter ging das Programm nach der Liste, d.h. > die aufgerufene Funktion hat den Returnstack entsprechend korrigiert > oder ist nach DPTR gesprungen. > Ein Disassembler würde sich daran bestimmt die Zähne ausbeißen und > versuchen, die Argumente als Befehle zu interpretieren. Der Keil C51 Compiler macht das bei einigen LibFunctionen auch so. Beispiel cccase. Da muss man dem Dissassebmer halt etwas helfen dann wird das schon. Ein guter Disassembler geht erst mal nur vom Reset Vector aus und stellt nicht erreichbare Code Teile auf DB. Die Interrupts werden dann in folgenden Durchgängen bearbeitet
Mit dem Hex-Code können die wenigsten etwas anfangen. Sieht zwar toll aus, aber 1:1 brennen ist das, was die meisten damit machen können. War das Ganze im Original Assembler, so könnte man eventuell noch den Rückwärtsgang einlegen. Aber war es C, so geht das Ganze schon damit los, das wie bei jedem anderen Programm, "Dein" Code abgearbeitet wird, aber regelmäßig irgendwelche Bibliotheksfunktionen (C) aufgerufen werden, deren Stiel wieder völlig anders ist wie der des C-Source. Ohne einen Namen ist die Identifikation einer Funktion echt eine sehr aufwendige Sache. Bei kompaktem Code, bei Mikrokontrollern üblich geht es oft um die Ersparnis von wenigen Bytes, kann man so etwas kaum lesen. Die wenigsten Disassembler können z.B. Daten von Sprungtabellen unterscheiden und können damit diese von "echten" Funktionen trennen. Dein disassemblierter Sermon bleibt somit lückenhaft und man weiß oft nicht mal: Sind das denn nun Daten oder ist das Code, der nur nicht Disassembliert wurde?
Beitrag #6704423 wurde von einem Moderator gelöscht.
Frank K. schrieb: > Dankeschön für die vielen wertvollen Hinweise, 1984 war ich gerade > in > der 3. Klasse ;-). Alle Komponenten auf der Platine bekommt man noch, > der Inhalt des EPROMs ist eben unersetzbar. Daher als erstes sichern, > dann clonen und prüfen, ob es dann noch hoffentlich läuft. Von den > damals 30 gebauten Maschinen sind noch ca. 12 weltweit in Betrieb. > Jemand hat schon mal im Rahmen einer Maschinen Revision die EPROMs > gesichert und dabei festgestellt, dass diese sich alle unterscheiden. > Vermutlich wurde diese "bahnbrechende" neue Technik damals permanent > weiterentwickelt. Da werden Kalibrierdaten dabei sein.
@ Thomas Z. Danke, sobald ich den Code ausgelesen habe, poste ich ihn hier.
Andreas S. schrieb: > Nach Möglichkeit solltest Du zum Auslesen einen EPROM-Leser/Brenner > verwenden, der das Auslesen bei verschiedenen Versorgungsspannungen > beherrscht. Auf diese Art und Weise kann man erkennen, ob es Bits gibt, > die auf der Kippe stehen, d.h. z.B. bei 4,3 V noch die korrekte Null, > aber bei 5,1 V schon eine Eins liefern. Ein Bekannter kommt mit einem GALEP V vorbei. Habe nur nachgesehen, dass der EPROM unterstützt wird. Fall es diese Funktion kann, bei welchen Versorgungsspannungen sollte man auslesen? Wenn also alle OK ist, müßten die beiden Dumps dann identisch sein?
:
Bearbeitet durch User
Thomas W. schrieb: > Du bist ja nur mies. Das ist sehr undankbar zum verstehen. Im Gegenteil, im Quelltext hat man keine Mühe, DB-Anweisungen und Befehle zu unterscheiden. Und es ist auch besser lesbar, da man nicht umständlich an ganz anderer Stelle im Datensegment eine Label vergeben muß. Man muß das Label auch nicht vor dem Aufruf in Register laden, d.h. spart auch Code. Man sieht die Argumente im Klartext direkt beim Aufruf, z.B.:
1 | call acomp_c |
2 | db 12345678h |
3 | call puts_c |
4 | db 'Hallo Welt', 0 |
Moin, - Peter D. schrieb: > Thomas W. schrieb: >> Du bist ja nur mies. Das ist sehr undankbar zum verstehen. > > Im Gegenteil, im Quelltext hat man keine Mühe, DB-Anweisungen und Im Quelltext ist es perfekt, das weiss ich. Im Binary ist eine andere Sache. Gruesse Th.
Mein erster Computer war 1979 ein 6502-Rechner Rockwell AIM-65. Zwei oder drei Jahre später hatte ich auch ein 8k großes Basic dazu, aber fast alles in Assembler geschrieben und auch gelegentlich fremde Programme analysiert. Später noch ein AppleII-Nachbau, da gab es öfters Steckkarten mit Software im Eprom. Die GPIB-Bus-Karte "7490" war besonders kompliziert. Den durchgängigen 2k-Adressbereich hatte der Entwickler nicht genutzt sondern per Bankswitching 256 Byte- Bereiche umgeschaltet. Irgendwo in dem 256 Byte-Bereich war jeweils ein "Wurmloch" in dem man durch das Bankswitchen in eine Nachbargalaxie gelangte. Eine andere Steckkarte hatte ein Adressbit invertiert am Eprom anliegen. Gemein!
Thomas P. schrieb: > Der Disassembler sollte schon merken, dass er mit der Sprungmarke mitten > in einem Zwei-Byte-Befehl landet. Solange da gültiger Code steht ist dem das völlig egal. Zu Apple II-Zeiten hatte fast jede Steckkarte zu Beginn ihres ROM-Bereiches solche Code-Konstrukte. Da hat man versucht, die Lücken zwischen den vorgegebenen Einsprungadressen möglichst effizient zu nutzen. Frank K. schrieb: > Ein Bekannter kommt mit einem GALEP V vorbei. Habe nur nachgesehen, dass > der EPROM unterstützt wird. Fall es diese Funktion kann, bei welchen > Versorgungsspannungen sollte man auslesen? Wenn also alle OK ist, müßten > die beiden Dumps dann identisch sein? Wenn der Brenner Verify low/high kann, wird er Dir schon was passendes vorschlagen. Ansonsten 4,5 V, 5,0 V und 5,5 V, das passt eigentlich immer. Üblicherweise ist das Image korrekt, welches die meisten Nullen enthält. 27xx-EPROMs löschen nach Eins und brennen nach Null. Verblassende Zellen nehmen wieder den gelöschten Zustand an, kippen also nach Eins.
Hallo, vor vielen Jahren habe ich 6502-Code mit DASMX recht gut disassemblieren können (inkl. symbolischer Addressen). DASMX nimmt standardmässig .BIN-Files als Quelle. Hinweis zu den möglichen Adressen der 2 VIA6522: Die müssten wahrscheinlich ganz am Anfang des Codes initialisiert werden. Darum sehe ich Chancen, die aus dem Code zu erhalten. Offen ist eine mögliche Verwendung des NMI- und IRQ- Eingangs der CPU. Die VIAs haben IRQ-Ausgänge. Näheres könnte man aus dem Schaltplan der Prozessorplatine ersehen. (Der 6502 hat die Vektoren am Ende des Codes). MfG Wuff_W
Andreas S. schrieb: > Nach Möglichkeit solltest Du zum Auslesen einen EPROM-Leser/Brenner > verwenden, der das Auslesen bei verschiedenen Versorgungsspannungen > beherrscht. Halte ich für unnötig. Hab noch nie mit einem Eprom Probleme gehabt wenn die Maschine funktioniert. Auch nicht bei 30 Jahre alten. Frank K. schrieb: > ggf. auf einen 2732 mit entsprechendem Pin Swap zu brennen. Hack das einfach in alle Pages rein. Das funktionierte bei mir immer. Christoph db1uq K. schrieb: > Eine andere Steckkarte hatte ein Adressbit invertiert am Eprom anliegen. > Gemein! Alufolie wirkt da Wunder. Die wickelt man um einen Pol des Durchgangsprüfers und tastet die Platine damit ab.
Hi Nur Mal kurz zum Nachdenken.... Ich habe eine funktionierende Maschine, befürchte aber, das Programm könnte möglicher Weise zerstört werden. Also, Programmsicherung. OK. Nun will ich aber wissen, wie es funktioniert und das Programm lesen. Vielleicht befürchte ich kleine Bugs. Da bist du aber ohne die Kommentare ziemlich hilflos, selbst wenn ein "Programmrückübersetzer" dir das Rohprogramm fehlerfrei liefert. Ein disassemblierter Maschinencode dürfte dir da einiges abverlangen. Da ist es wesentlich einfacher, die Funktionen der Maschine neu zu programmieren, da du ja die einzelnen Schritte relativ einfach nachbilden kannst. Im Ergebnis bist du vermutlich dreimal schneller als mit der Analyse des alten Programms und hast dazu noch eine gute Dokumentation. Ein Beispiel Eine Steuerung einer Anlage wurde auf eine andere SPS umgebaut. Im alten Programm waren noch viele Leichen und der Automatikablauf wahnsinnig verkompliziert. Die größte Sorge der Inbetriebnehmer einer externen Firma. Was haben die nicht alles im Vorfeld angestellt, um die Automatikabläufe mit Filmaufnahmen festzuhalten in der Hoffnung, das der generierte Code der Anpaßsoftware dann pflegbar wird. Die Handfunktionen waren bereits fertig, keine große Sache. Also der Vorschlag, einfach die Automatik durch schrittweise Abarbeitung der Handfunktionen zu ersetzen. Hat zwar einen Tag gekostet, aber dafür genügte bei der Inbetriebsetzung nur ein Tastendruck und fertig. Das alte Programm hatte vorher schon so viele Macken, das Fehlfunktionen an der Tagesordnung waren. Also, setz ein neues Programm auf, das ist einfacher und sicherlich auch nachhaltiger. Gruß oldmax
Obwohl ich Jahrzehnte kein 6502-Programm mehr geschrieben habe, würde ich eine Rekonstruktion aus dem vorhanden EPROM-Inhalt eher als Fingerübung ansehen. Seinerzeit war es doch üblich, aus .bin-Dateien wieder assemblierbaren Quellcode zu bekommen. Datenbereich zu extrahieren war dabei kein Problem. Wo die VIAs liegen sieht man sofort und 4 kB Programm sind doch überschaubar. Trotzdem tauchen hier wieder alle möglichen Bedenkenträger auf :-(
Frank K. schrieb: > Der erste Schritt wäre mit dem Galep 5 den EPROM auszulesen und den > Datenstand zu sichern, ggf. auf einen 2732 mit entsprechendem Pin Swap > zu brennen. Würde ich nicht machen. Es gibt doch noch 2532. So exotisch teuer auch wieder nicht. Andere Kunden bezahlen das sicher. Bei Maschinen-Steuerungen werden ganz andere Preise aufgerufen.
Als ich noch EPROMS benutzt habe, hatte ich zwischen den Funktionen Lücken (0xFF) gelassen. Der Befehl (MOV R7,A) hatte nicht gestört. War eine Funktion fehlerhaft, dann konnte ich in die Lücke einen Sprung zur korrigierten Funktion brennen, ohne löschen zu müssen. D.h. ein fertiger EEPROM enthielt dann haufenweise toten, fehlerhaften Code.
Peter D. schrieb: > D.h. ein fertiger > EEPROM enthielt dann haufenweise toten, fehlerhaften Code. Das ist aber garnicht gut. Lebendiger, fehlerfreier, bis auf's letzte Bit optimierter Code ist da viel besser. Dafür hatte man schließlich seinen EPROM-Emulator ;-) Beim 6502 gibt es für nachträgliche Ergänzungen oder Stopp-Marken den BREAK-Befehl (0x00).
Hab noch was gefunden: Verwendung des NMI- und IRQ-Eingangs der CPU: Diese sind über einen 3,3k Pullup an 5V aus der Rechnerkarte nach außen geführt und der IRQ zusätzlich auf die beiden VIA. Die CS2 (Pin 23) haben am Leiterzug stehen: $E 900 - $E 90F und $E 910 - $E 91F, das düften wohl die Adressbereiche für die I/Os sein. Wenn ich die EPROMs ausgelesen habe (Wir haben 2 Anlage mit je 2 solcher Rechnerkarten darin), werde ich mal von einem EPROM den Inhalt posten und den Schaltplan der Karte dazu.
:
Bearbeitet durch User
Wir mussten auch mal eine Steuerkarte nachbauen, da es keine Ersatzteile dafür mehr gab. Da war glaube ich auch ein 8051 drauf. Außerdem waren da nach Frequenz-Spannung-Wandler und ADCs drauf. Statt einen 8051 haben wir einen FPGA drauf getan und den 8051 als SoftCore im FPGA realisiert. Der ursprüngliche ADC hat die gemessene Spannung zu einem langen im Puls gewandelt, das Programm hat dann die Zeit des Pulses gemessen. Der ADC wurde durch ein viel schnelleren mit seriellen Interface ersetzt. Im FPGA gab es dann eine Umsetzung das draus wieder einen Puls generiert. Wir haben ebenfalls den EEPROM ausgelesen und disassembliert. Meine Aufgabe war es den Assemblercode durchzugehen um Testfälle zu generieren, die möglichst alle Pfade das Programms durch gehen. Dann konnten wir die alte Steuerkarte mit der neuen vergleichen, um sicher zustellen das beide das gleiche Verhalten haben.
Frank K. schrieb: > Die CS2 (Pin 23) > haben am Leiterzug stehen: $E 900 - $E 90F und $E 910 - $E 91F, das > düften wohl die Adressbereiche für die I/Os sein. Dann ist der Addressdecoder umständlicher als ich jetzt erwartet hätte. Bei nur 4 Bausteinen würde ich die Dinger in 16k Schritten in den Speicher einblenden. Das binary wäre auch die Gelegenheit mal Ghitra anzutesten vieleicht ist der Output dort besser.
m.n. schrieb: > Dafür hatte man schließlich > seinen EPROM-Emulator ;-) Sowas war beim 8051 nicht nötig, man konnte bequem über den EA-Pin auf externes RAM als Codespeicher umschalten. Und dann brachte Atmel den AT89C51 und AT89C2051 mit Flash raus. Mit einem AT89C51 habe ich mir dafür ein Programmiergerät gebastelt. Meine EPROM-Bastelzeit war also nur sehr kurz. Ich habe aber noch aus DDR-Zeiten das Robotron Löschgerät K0421. Ich hatte es mir von der Firma geliehen, aber nach der Wende gab es keinen mehr, dem ich es zurück geben konnte. Die AT89C2051 im DIP-20 habe ich sehr gerne genommen. Sie sind auch immer noch gut beschaffbar und wir haben sie auch noch in einem Produkt im Einsatz.
Peter D. schrieb: > Sowas war beim 8051 nicht nötig, man konnte bequem über den EA-Pin auf > externes RAM als Codespeicher umschalten. Dann musste man aber für das externe ROM einen Daten- und Adressbus haben und konnte nicht alle vier Ports frei verwenden. Beim 8051 habe ich zuletzt Dallas DS5000 als in-circuit-Emulator genommen. Das sind Mikrocontroller mit batteriegepuffertem RAM als Programmspeicher und Notlöschfunktion, für EC-Kartenleser und ähnliche sicherkeitskritische Anwendungen. Die haben aber neben dem batteriegepufferten Programmspeicher auch einen tollen Bootloader, dem man über die UART direkt ein Intelhex reinschieben kann.
>Zu Apple II-Zeiten hatte fast jede Steckkarte zu Beginn ihres ROM-Bereiches >solche Code-Konstrukte. Dazu fällt mir ein, die Steckkarte wußte nicht, in welchem Slot sie steckt. Daher machte sie einen Unterprogrammaufruf in ihr Eprom, der direkt auf ein "Return from subroutine" führte. Anschließend stand die Adresse des Slots auf dem Stack.
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.