Ahoi, hier mal eine Frage an die alten Hasen :-) Von meiner Arbeit aus habe ich eine alte 19" Regelungsbaugruppe mit einen Intel 8080 und zwei Eproms mit seinen Programm darauf. Das Programm ist eigendlich nur ein PID-Regler mit grenzwert erkennung. Da ich mich mit naja sagen wir mal den Grundlagen/ anfängen der µC nicht wirklich gut auskenne hier mal die frage was es für Programme gibt "Disassenmber" oder vielleicht auch andere möglichkeiten die Eprom inhalte in Assembler zurüch zu übersetzen und vielleicht auch noch weiter bis hin zu einen Struktogramm, damit ich die möglichkeit habe das Programm zu verstehen und mir einen überblick über die Funktionsweise dieser baugruppe zu verschaffen. Hab natürlich auch schon ein wenig gegoogelt und ausprobiert aber noch nicht so richtig ans Ziel gekommen und da das mal wieder alles ziemlich Zeitkritisch ist hoffe ich auf eure Hilfe um ein wenig schneller zum Ziel zu kommen :-) Anbei mal den Eprom inhalt... Gruß Matthias
IDA (Pro) ist eigentlich der übliche Disassembler für Hacker und kennt auch den 8080, aber es gibt natürlich viele andere die man mit '8080 Disassembler' findet, nicht alle mit so bequemer Oberfläche.
Matthias W. schrieb: > Da ich mich mit naja sagen wir mal den Grundlagen/ anfängen der µC > nicht wirklich gut auskenne hier mal die frage was es für Programme gibt > "Disassenmber" oder vielleicht auch andere möglichkeiten die Eprom > inhalte in Assembler zurüch zu übersetzen Das ist nicht so schwer. Nur: wenn du dann den Assembler hast fangen die Probleme an. Denn die Sprungmarken und die Variablen haben allesamt irgendwelche sinnlose Namen. Eine Wertetabelle oder Zeichenketten werden gnadenlos in sehr seltsame Assemblerbefehle "zurückübersetzt". Du müsstest also schon sehr genau wissen, warum da wo was und wie angesteuert ist > und vielleicht auch noch weiter bis hin zu einen Struktogramm, Vergiss es. > damit ich die möglichkeit habe das Programm zu verstehen Glaub mir: ohne herausragende Kenntnisse der Prozessorarchitektur und der Hardware wird das nichts. > einen überblick über die Funktionsweise dieser baugruppe zu verschaffen. Du weißt doch schon, was sie tut: > Das Programm ist eigendlich nur ein PID-Regler mit grenzwert erkennung. Was ist denn dein eigentliches Problem? Willst du die Funktion der Baugruppe ändern?
:
Bearbeitet durch Moderator
Lothar Miller schrieb: > Was ist denn dein eigentliches Problem? Willst du die Funktion der > Baugruppe ändern? Ist doch mal wieder alles ganz klar: Er will ans Ziel kommen. :)
Wie Lothar schon geschrieben hat. Du brauchst zumindest die Infos welche Peripherie an welchen Adressen steckt und wie diese Peripherie angesteuert wird. Damals gabs für alles und jedes noch externe ICs. Disassemblieren geht noch aber von da an brauchst du ganz viel Brain 2.0. Ich würde zum Spielen oder lernen einen modernen µC nehmen, da ist in dem Chip mehr drin an Rechenleistung und Peripherie als auf der ganzen 19" Karte.
:
Bearbeitet durch User
moin, erstmal schön das schon so viele wach sind hier ;-) Ja na klar über mein eigenliches Ziel habe ich mich noch nicht so richtig ausgelassen. Ja ich weiss die Funktion der baugruppe. Und ich kenne auch ziemlich genau die Baugruppe und dessen aufbau. Und habe auch eine vorstellung von ablauf des Programms - das z.B. die regelbarameter über einen Multiblexer eingelesen werden, bezihungsweise durchgeschaltet werden und die anliegene Spannung über einen D/A-Wandler und einen OP ausgelotet wird usw. der eigenliche hintergrund ist das die Baugruppe einen defekt hat und ich diese wieder in schuß bringen soll/muss. Da es alles nicht einfach ist bei laufenner Baugruppe einen fehler zu finden gibt es jetzt mehrere ansätze um ans Ziel zu kommen. Einer an diesen ansätzen währe natürlich ein eigenes Prüfprogramm zu schreiben welches mehr oder weniger statische zustände auf der Baugruppe schaft um ordendlich einzelne bereiche durchzumessen - da ich aber nicht wirklich Assembler kann und auch nicht mit der 8080 technologie vertraut bin brauche ich hier viel Zeit und Forschung. Ein anderer weg wäre das bestehende Programm zu modiefizieren um eine art zwischen lösung von der ersten möglichkeit zu erhalten und etwas weniger forschung/zeit zu brauchen. gruß
auf IDA bin ich auch schon gestoßen (Demo), aber irgendwie noch keine richtigen ergebnisse erhalten :-(
@udo: aktuelle µC sind mir vertraut - bin kein Profi aber komme mit C mitlerweile an ganz brauchbare Ergenisse.
>Da es alles nicht einfach ist bei laufenner Baugruppe einen fehler zu >finden
gibt es jetzt mehrere ansätze um ans Ziel zu kommen.
Das Programm zu disassemblieren ist aber der komplizierteste und auch
unsinnigste Ansatz.
Nach so vielen Jahren im Betrieb ist sicher kein Softwarefehler
vorhanden, und wenn, dann ist der längst akzeptiert.
Da ist die Hardware defekt.
Spannungen (Versorgungsspannungen) messen ist schon mal ein netter,
einfacher Anfang.
Ein/Ausgänge kontrollieren der nächste Schritt...
Na ja, nach so vielen Jahren kann auch mal ein bit im EPROM kippen und zu Kauderwelsch im code führen. Ein Regler, der ständig sbstürzt und resettet regelt vestimmt nicht gut.
Das wird wieder mal ein Spiel der Art: Ich sehe was, was du nicht siehst. Matthias W. schrieb: > Ja ich weiss die Funktion der baugruppe. Und ich kenne auch ziemlich > genau die Baugruppe und dessen aufbau. Und habe auch eine vorstellung > von ablauf des Programms
Detlef Kunz schrieb: > Das wird wieder mal ein Spiel der Art: Ich sehe was, was du nicht > siehst. quatsch, ist doch völlig klar, R42 ist zu groß.
Tock schrieb: > quatsch, ist doch völlig klar, R42 ist zu groß. Das wissen aber auch nur Leute, die "hitchhikers guide to the galaxy" gelesen haben.
Ach Leute, ich frage hier doch nur nach ansätzen und möglichkeiten, soll ich echt zwei dich DIN A4 ordner einscannen und hochladen? Es geht doch nicht darum das Ihr die Baugruppe Repariert sondern nur ob dieser ansatz prinziebel sinnig ist ihn weiter zu verfolgen. Wir reden hier auch nicht über 0815 Fehler wie Interne Spannung weg oder Eprom defekten oder einer fehlenden Adressleitung - mit sowas würde ich euch nicht nerven. Gruß
Matthias W. schrieb: > Ach Leute, ich frage hier doch nur nach ansätzen und möglichkeiten, Ansatz: Eproms erst mal in Sicherheit bringen. Dann neue besorgen und da Prüfprogramme dafür entwickeln. Da die Hardwareschaltung bekannt ist, sollte das eigentlich nicht so schwer sein, die richtigen Pins zu setzen. 8080 lernen musst du sowieso. Wenn du auf Disassemblieren und verstehen von komplexem vorhandenem Code setzt, dann noch viel mehr, als wenn du in aller Ruhe erst mal mit kleinen Brötchen anfängst.
Ja, so wird wohl mein weg aussehen :-| erstmal vielen Dank euch allen gruß
Aus dem klassischen Disassembler kommt im ersten Durchlauf etwas wie
1 | L0000: C3 74 01 JP L0174 |
2 | L0003: F3 DI |
3 | L0004: C3 04 00 JP L0004 |
4 | L0007: 00 NOP |
5 | L0008: C9 RET |
6 | L0009: 00 NOP |
7 | L000A: 00 NOP |
8 | L000B: 00 NOP |
9 | L000C: 00 NOP |
10 | L000D: 00 NOP |
11 | L000E: 00 NOP |
12 | L000F: 00 NOP |
13 | L0010: C3 AE 0F JP L0FAE |
14 | L0013: F3 DI |
15 | L0014: C3 14 00 JP L0014 |
oder
1 | L0174: 16 32 LD D,'2' |
2 | L0176: 21 00 00 LD HL,L0000 |
3 | L0179: AF XOR A |
4 | L017A: 32 74 3B LD (L3B74),A |
5 | L017D: 31 00 3C LD SP,L3C00 |
6 | L0180: D5 PUSH DE |
7 | L0181: 11 02 20 LD DE,L2002 |
8 | L0184: CD 5F 0F CALL L0F5F |
9 | L0187: F3 DI |
10 | L0188: 21 33 03 LD HL,L0333 |
11 | L018B: 11 01 20 LD DE,L2001 |
12 | L018E: CD 5F 0F CALL L0F5F |
13 | L0191: F3 DI |
14 | L0192: D1 POP DE |
15 | L0193: 21 00 3B LD HL,L3B00 |
16 | L0196: 01 AA 55 LD BC,L55AA |
17 | L0199: 70 LD (HL),B |
18 | L019A: 7E LD A,(HL) |
19 | L019B: 71 LD (HL),C |
20 | L019C: B8 CP B |
21 | L019D: C2 13 00 JP NZ,L0013 |
Das ist aus deinem ersten Eprom, der Anfang des Programms. Nun musst du aus diesen kryptischen Zeilen wieder einen Sinn heraus konstruieren. Für einen Anfänger ist das sehr frustrierend und zeitraubend. Es gibt aber Spezialisten, die deine 4kBytes in ein, zwei Tagen abarbeiten. Dazu müssen dann aber genaue Angaben zur Hardware und zum Zweck des Programms vorliegen. Und diese Spezialisten kosten Geld.
:
Bearbeitet durch User
Georg G. schrieb: > Das ist aus deinem ersten Eprom, der Anfang des Programms. Nun musst du > aus diesen kryptischen Zeilen wieder einen Sinn heraus konstruieren. Wobei eines der Probleme darin besteht, für Dinge wie L0174 sinnvolle Namen zu finden. Was wiederrum meistens dazu führt, dass man erst mal den Code im Detail analysieren muss und (manchmal auch mit ein wenig Glück) errät, was wohl die ursprüngliche Absicht an dieser Stelle war. Das geht wiederrum oft nur dann, wenn man genug Erfahrung hat, dass man typische Konstrukte wiedererkennt und auch eine ungefähre Vorstellung davon hat, was wohl (algorithmisch gesehen) an dieser Stelle im Code höchst wahrscheinlich passieren wird. Das ganz ist also ein Ping-Pong Spiel aus Code lesen, eine Erwartungshaltung bilden, die Erwartungshaltung mit dem Code überprüfen und die Hypothese gegebenenfalls modifizieren. Obiger Anfang ist nicht so schwer zu lesen. Denn was wird am Anfang passieren? Erst mal wird alles initialisiert. D.h. da muss der Stackpointer auf irgendeinen Bereich im Speicher gesetzt werden (üblicherweise ans hintere Ende), und die restliche Hardware initialisiert. Was finden wir
1 | L017D: 31 00 3C LD SP,L3C00 |
d.h. die Chance stehen nicht schlecht, dass das Label L3C00 eigentlich RAMEND heissen sollte. Der Teil hier ist interessant
1 | L0188: 21 33 03 LD HL,L0333 |
2 | L018B: 11 01 20 LD DE,L2001 |
3 | L018E: CD 5F 0F CALL L0F5F |
wenn HL geladen wird UND DE geladen wird, dann sind da oft Kopieraktionen im Spiel. Das könnte man mal prüfen, indem man nachsieht, was der Code an 0F5F macht. Hier
1 | L0193: 21 00 3B LD HL,L3B00 |
2 | L0196: 01 AA 55 LD BC,L55AA |
3 | L0199: 70 LD (HL),B |
4 | L019A: 7E LD A,(HL) |
5 | L019B: 71 LD (HL),C |
6 | L019C: B8 CP B |
7 | L019D: C2 13 00 JP NZ,L0013 |
liegt einer der Schüssel zum Verständnis im Jump-not-zero an L0013. Sieht man dort nach, dann passier dort ein
1 | L0013: F3 DI |
2 | L0014: C3 14 00 JP L0014 |
Interrupts disablen und eine Endlosschleife? Das kann nur ein Fehlereinsprung sein, in dem der Prozessor zum Nichtstun verdammt wird. D.h wenn ich das mal als ERROR bezeichne, dann ergibt der vorhergehende Code den Sinn, dass das ein Speichertest ist. Über HL wird ein Muster in den Speicher geschrieben und dann nachgesehen, ob der geschriebene Wert auch im Speicher steht. Wenn nicht, dann Fehler. Und so geht das dahin bei der Codeanalyse. Identifizierte Dinge führen zu Namen von Labels, die einen dann wieder bei der weiteren Codeanalyse helfen. Und so vervollständigt sich das Assemblerlisting immer mehr, auch mit Kommentaren. Viele Assembler Programme haben auch gewisse Schemata, wie die Register eingesetzt werden. Auch das wäre vernünftig zu dokumentieren bzw. rauszukriegen. Denn mit einem vergessenen Push/Pop kann man sich ganz schnell den Tag versauen. Und erst dann kann man anfangen darüber nachzudenken, im Code Modifikationen vorzunehmen
:
Bearbeitet durch User
Georg G. schrieb: > Das ist aus deinem ersten Eprom Es muss ja nicht sein, dass A0, A1, A2, mit A0, A1, A2 verbunden sind , auch die Datenleitungen liessen sich vielleicht D7, D3, D6, D4, D5, D2, D1, D0 besser routen...
MaWin schrieb: > Es muss ja nicht sein Das ist richtig. Aber da man auf den ersten Blick sinnvollen Code erkennt, ist die Wahrscheinlichkeit hoch.
Für einen wie mich der vor 22 Jahren im alter von 12 auf nem 80286 angefangen hat sicherlich machbar aber sehr aufwändig. Da ich seit ich 16 Bin elktronische Schaltungen entwickle und repariere wirst du mit Oszilloskop und Logcanalizer sehr viel schneller ans Ziel kommen. Wenn du kein Assembler Crack bist lass es sein (das Disassemblieren).
Bin noch nicht ganz wach, wollte damit sagen, daß es der bessere Ansatz für dich wäre den Fehler in der Hardware zu finden. Und selbst Jemand der schon lange mit Assembler zu tun hat einen Bitdreher per Disassemblierung zu finden keinen Spaß macht. Wenns natürlich wirklich an einem gedrehtem Bit im EEPROM liegt ist das natürlich... Aber eventuell kannst du ja den Adressbus und Datenbus abhorchen und so die Fehleradresse lokalisieren.
Matthias W. schrieb: > Georg G. schrieb: >> Und diese Spezialisten kosten Geld. > > Kennst du jemanden der sowas macht? Ja, ich mache so etwas. Vor ewiger Zeit, d.h. Mitte der achtziger Jahre, hatte ich das z.B. das ROM des Sharp MZ-80K per Disassembler von vorne bis hinten analysiert. Glücklicherweise hatte ich auch das Service Manual inklusive Schaltplan zur Hand und konnte daher auch stets die Hardware bzw. Peripherieregister nachverfolgen. Das ganze hat mich so geprägt, dass wenn ich heutzutage auf einen beliebigen Hexdump schaue, anfange, ihn automatisch in Z80-Assembler zurückzuübersetzen; so wie einige Funker/Funkamateure Vogelgezwitscher als Morsecode dekodieren. Der Sharp MZ-80K besitzt einen Z80, welcher Deinem 8080 sehr ähnlich ist. Wie schon von einigen Vorredner angedeutet, würde eine Analyse und Kommentierung eines 4KB-EPROMs einige Tage benötigen. Wenn Du ernsthaft interessiert bist, kann ich Dir/Euch gerne ein Angebot dafür unterbreiten. Schicke ggf. eine E-Mail an andreas@schweigstill.de . Gruß, Andreas
Falls man doch einen Bitfehler vermutet, sollte man den EPROM im Programmiergerät auslesen und neu programmieren. Oft sind schwache Bit da noch lesbar. Vor allem wenn man die Auslesegeschwindigkeit reduzieren kann. Evtl. auch die Spannungsversorgung bis an die Maximalgrenze erhöhen.
@Michael_ (Gast): "Evtl. auch die Spannungsversorgung bis an die Maximalgrenze erhöhen." Damit sorgst Du eher dafür das Du die gekippten Bits nicht mehr lesen kannst. Ein Epromer liest programmierte Roms bei 6V Vcc um sicher zu sein, das die Bits stabil programmiert sind, die hohe VCC hebt die Thresholdspannung der FET Zellen an. Wenn Du das mit einem wackeligen Eprom machst, erreichst Du das sich der Fehler manifestiert, also genau der entgegengesetzte Weg ist richtig. Gruß, Holm
Es ist wohl nicht nicht erwiesen dass ein EPROM-bit-Dreher die wirkliche Fehlerquelle ist. Und da erscheint mir der Aufwand des Disassemblierens doch recht hoch. So manche dieser alten Schaltungen hatten da ihre Hardwareprobleme, z.B. unzureichende Abblockung der chips. Aus meiner eigenen Erfahrung kann ich sagen, dass ein 64kbit CMOS EPROM seit 1989 seinen Dienst tut in meinem Z80180 basierten arbiträren Funktionsgenerator. Wenn da mal ein bit kippt, kann ich das Gerät wegschmeißen, da ich schon lange keinen EPROMMER mehr besitze und die CP/M Entwicklungsentwicklung natürlich auch perdu ist.
voltwide schrieb: > Wenn da mal ein bit kippt, kann ich das Gerät > wegschmeißen, da ich schon lange keinen EPROMMER mehr besitze und die > CP/M Entwicklungsentwicklung natürlich auch perdu ist. Es gibt genug Leute, die dir da helfen können. CP/M kannst du notfalls auch in einer VM auf deinem PC laufen lassen. Es gibt freie Emulatoren, die sogar recht fix sind.
An den TO: Ein gutes Foto der Platine wäre auch hilfreich gewesen. Denn der 8080 ist ja vermutlich kein Autist und muss irgendwie mit der Welt kommunizieren. In deinen Binärfiles ist aber nur recht obskurer Kram diesbezüglich zu sehen. An einer Stelle sieht das Eprom gepatcht aus, einen Bitdreher kann man mit guter Wahrscheinlichkeit dort ausschließen, das Muster passt nicht dazu. Was mich wundert: Im Eprom ist kein Versions oder Copyright String zu sehen, eher ungewöhnlich für ein kommerzielles Produkt.
Holm Tiffe schrieb: > Damit sorgst Du eher dafür das Du die gekippten Bits nicht mehr lesen > kannst. Jedenfalls hat das damals mit 2K Russentypen funktioniert. Das waren N-MOS. Die haben oft mal ein Bit vergessen. Und vor allem mit der Standard Routine 20ns auslesen. Versuchen würde ich das trotzdem mal.
Michael_ schrieb: > Falls man doch einen Bitfehler vermutet, sollte man den EPROM im > Programmiergerät auslesen und neu programmieren. > Oft sind schwache Bit da noch lesbar. Vor allem wenn man die > Auslesegeschwindigkeit reduzieren kann. Evtl. auch die > Spannungsversorgung bis an die Maximalgrenze erhöhen. Müsste es nicht genau andersrum sein - sprich, dass ich eher bei besonders niedriger Versorgungsspannung die Chance habe, den richtigen Inhalt einer Speicherzelle aus dem EPROM auszulesen? Ich beziehe mich dabei auf den Programmieralgorhytmus, da wird während des programmierens bei erhöhter Versorgungsspannung (VCC = 6.5 ±0.25V)getestet ob das BIT richtig gesetzt ist, bevor zur nächsten Zelle übergangen wird. Ich wäre jetzt davon ausgegangen, dass die VCC=6.5V den worst case Zustand für die Erkennung darstellt.
Holm Tiffe schrieb: > Damit sorgst Du eher dafür das Du die gekippten Bits nicht mehr lesen > kannst. > > Ein Epromer liest programmierte Roms bei 6V Vcc um sicher zu sein, das > die Bits stabil programmiert sind, die hohe VCC hebt die > Thresholdspannung der FET Zellen an. Wenn Du das mit einem wackeligen > Eprom machst, erreichst Du > das sich der Fehler manifestiert, also genau der entgegengesetzte Weg > ist richtig. > > Gruß, > > Holm Sorry, hatte ich überlesen!
Jetzt aber doch noch mal ne Frage dazu: @Holm Holm Tiffe schrieb: > Wenn Du das mit einem wackeligen > Eprom machst, erreichst Du > das sich der Fehler manifestiert, also genau der entgegengesetzte Weg > ist richtig. Der Vorgang ist doch reversibel, oder? Sprich wenn ich die Versorgungsspannung wieder herunterdrehe, erkenne ich wieder den richtigen Zustand bei "grenzwertigen" Speicherzellen? Ich Frage deshalb ob man die Methode dazu nutzen kann (im Falle eines Defektes eines Gerätes) zu testen, ob der Inhalt eines EPROMs eh schon "grenzwertig" ist oder nicht, ohne den Inhalt dabei zu zerstören.
Schon klar, Matthias: (schrieb:) > Ach Leute, ich frage hier doch nur nach ansätzen und möglichkeiten, Ich mag aber keine Antwort geben, deren wirtschaftlichen Erfolg ich selbst nicht sehen kann. Entweder willst Du ein kommerziell genutztes System verbessern / von einem Mangel befreien, oder eines, das nicht kommerziell genutzt wird. Im ersten Fall erwartet Dein Kunde Qualität und eine lohnende Nutzungsdauer. Dissassemblieren eines 8080-Progamms lohnt nur, um eine Konstante zu finden, zu verbessern - und alles andere zu lassen, wie es war. Gibt es die Entwicklungsumgebung überhaupt noch? Oder verlangt die bei Neustart einen Treiber, der gegen 1982 entsorgt wurde? Denn je mehr Du änderst, desto schlimmer wird die Verschlimmbesserung. Da greif besser die Spannung an dem Multiplexer ab, den Du beschrieben hast, bilde das Ganze mit einer Karte von National Instruments und Lab View nach, spendiere einen eigenen PC und speise das Regelsignal wieder in die alte Platine ein. Ich möchte vermuten, selbst ein Raspberri Pi als Huckepqack-Reiter auf der vorliegenden Regelkarte könnte letzlich günstiger sein als Disassemblierung und neue KKodierung. Ciao Wolfgang Horn
egal² schrieb: > Ich Frage deshalb ob man die Methode dazu nutzen kann (im Falle eines > Defektes eines Gerätes) zu testen, ob der Inhalt eines EPROMs eh schon > "grenzwertig" ist oder nicht, ohne den Inhalt dabei zu zerstören. Genau deshalb verifizieren manche Programmiergeräte je einmal an der oberen und an der unteren Grenze der Versorgungsspannung. Ob jetzt oben kritischer ist als unten oder umgekehrt hängt vom Design der Sense Amps ab. Dazu muss man den inneren Aufbau des jeweiligen EPROM-Typs kennen. Matschige EPROMs haben aber eigentlich immer verlängerte Zugriffszeiten. Daher lassen sie sich im EPROMmer mit 250 kHz noch auslesen, während sie in der Applikation mit 1-2 MHz schon ausfallen.
egal² schrieb: > Jetzt aber doch noch mal ne Frage dazu: > > @Holm > > Holm Tiffe schrieb: >> Wenn Du das mit einem wackeligen >> Eprom machst, erreichst Du >> das sich der Fehler manifestiert, also genau der entgegengesetzte Weg >> ist richtig. > > Der Vorgang ist doch reversibel, oder? Sprich wenn ich die > Versorgungsspannung wieder herunterdrehe, erkenne ich wieder den > richtigen Zustand bei "grenzwertigen" Speicherzellen? > > Ich Frage deshalb ob man die Methode dazu nutzen kann (im Falle eines > Defektes eines Gerätes) zu testen, ob der Inhalt eines EPROMs eh schon > "grenzwertig" ist oder nicht, ohne den Inhalt dabei zu zerstören. Ja, klar ist das reversibel, Du kannst das bei jedem Lesevorgang umschalten. So eine EPROM Zelle ist ja ein FET mit 2 Gates, wovon Eines praktisch vollisoliert ist un die Ladung durch einen ominösen Tunnelvorgang erhalten hat. Mit diesem Gate stellst Du praktisch den Grundarbeitspunkt der Zelle ein und mit dem Restlichen FET und seiner Betreibsspannung kannst Du dann den Effekt auslesen. Wenn die Eproms halb leer sind, sind die beim Lesen auch lichtempfindlich.. logisch, die Schaltschwelle wird auch dadurch beeinflußt. Gruß, Holm
Holm Tiffe schrieb: > beim Lesen auch lichtempfindlich Manche sind auch nach richtigem Programmieren lichtempfindlich. Es gab mal einen Bauvorschlag für eine Kamera, die als Sensor ein Eprom hatte. Mit den ersten dynamischen RAMs ging das auch, war nur schwieriger, das Gehäuse zu öffnen.
soul eye schrieb: > Genau deshalb verifizieren manche Programmiergeräte je einmal an der > oberen und an der unteren Grenze der Versorgungsspannung. Viele Programmer haben neben der Typenwahl auch noch separate Einstellmöglichkeiten der Programmierspannung und der Betriebsspannung, sogar mein Uraltgerät. Dafür schickt man einen am Terminal eingegebenen Code über RS232, das Gerät wird an der RS232 einfach wie ein Modem bedient. An meinem Gerät lassen sich Abstufungen von je 0,25V einstellen. In der Anfangszeit stellte ich einfach nur den nächstbesten Typ für Fabrikate verschiedener Hersteller ein, und das tat es auch. Oft liegt die Schrittweite von 0,25V sogar in der angegebenen Toleranz, und falls die Spannungen am Programmer sowieso präzise sind. Ich werde die Sache mal im Auge behalten, und beim nächsten Auspacken des Programmers mal EPROMs unter verschiedenen Spannungseinstellungen testen. Allerdings lassen sich nicht alle Spannungen grenzenlos einstellen, sondern nur von 5 bis 25V in den 0,25V-Schritten. Parallele EEPROMs wie der 28C16A werden mit nur 5V gebrannt. Aber z.B. 18V oder 22V kann man schon mal für einen 21V-Typ einstellen. Der Programmer merkt das sofort, und bricht beim ersten fehlerhaften Byte ab, beim Totalschaden natürlich auch. Wobei die CMOS-Typen allerdings garantiert nicht die Spannungen alter NMOS-Typen vertragen, da verabschiedete sich durch Verwechselung schon mal ein CMOS-Stein. Uralte 2516 von 1979 hielten die Daten mal erstaunlich gut, ich bekam sie kaum gelöscht. Mindestens fünf Durchläufe im Löschgerät, ca. zwei Stunden. Diese könnte ich aber zu Datenerhaltstests verwenden, z.B. ein mal löschen, und wieder testen, usw.. Modernere natürlich auch, dann nach einer Minute das Löschgerät abschalten. Beim 8080 hätte ich jetzt geglaubt, daß er noch PMOS-EPROM mit drei Spannungen hatte.
MaWin schrieb: > Georg G. schrieb: >> Das ist aus deinem ersten Eprom > > Es muss ja nicht sein, dass A0, A1, A2, mit A0, A1, A2 verbunden sind , > auch die Datenleitungen liessen sich vielleicht D7, D3, D6, D4, D5, D2, > D1, D0 besser routen... Doch. Das muß sein. Sonst müssten die Leitungen beim EPROM-Brenner genauso verlegt sein oder der Hexcode müsste entsprechend verdreht werden. Sowas kann man mit einem RAM machen. Da ist es egal. mfg.
Thomas Eckmann schrieb: > Doch. Das muß sein. Sonst müssten die Leitungen beim EPROM-Brenner > genauso verlegt sein oder der Hexcode müsste entsprechend verdreht > werden. Sowas kann man mit einem RAM machen. Man könnte ja aber doch vor dem Brennen die Brenndaten mit einem kleinen selbst geschriebenen Progrämmchen verdrehen, was bits in einem Byte einfach vertauscht. Zumindest für die acht Datenleitungen. Bei Adressen wird es bestimmt aufwändiger. Aber das ist Nonsens, selbst auf einer einlagigen Platine bekommt man die Leitungen noch gut hin, z.B. 8051 mit dem Daten-/Adreßmultiplexer und externem EPROM, selbst schon gemacht. Vielleicht vor dem PC-Zeitalter, als man Layouts noch von Hand klebte bzw. zeichnete.
Über den Aufwand die komplette Funktionalität zu extrahieren wurde ja schon einiges gesagt, daher klemme ich mir das. Aber angeblich gibt es wohl ein IDA-Plugin namens SmartDec, das ein wenig C approximieren kann: http://decompilation.info/ Hab ich aber selber auch noch nicht getestet.
Falk Schilling schrieb: > C approximieren Das Programm stammt aus keinem der gängigen 8080 C-Compiler. Es fehlen die typischen Funktionsprologe/Epiloge. 8080 und C ist auch eher selten. Als C modern wurde, war der 8080 schon out. Die Konstrukte sind eher Assembler typisch. IIRC gab es nur einen Compiler, der auf die RST-Befehle optimierte (Quality Computers mit AO). Und der ist es definitiv nicht. Bei einem Compiler wäre auch die Runtime Lib in einem Stück dazu gelinkt, typisch am Ende. Die erkennt man schnell. Ohne Schaltbild sehe ich aber keine Chance, da viel sinnvolles zu erkennen. Diverse Peripherie ist Memory mapped. Da muss man schon wissen, was sich dahinter verbirgt. Ansonsten sieht es nett gemacht aus, keine Bastelarbeit. Das RAM wird im Betrieb zyklisch auf defekte Zellen untersucht. Da war jemand echt feige. Es würde mich nicht wundern, wenn auch das Eprom mit einem CRC gesichert wäre.
Georg G. schrieb: > Das Programm stammt aus keinem der gängigen 8080 C-Compiler. Du meinst wahrscheinlich einen Assembler. In Unternehmen wurde z.B. 8048 um das Jahr 1978 herum noch rein in Assembler programmiert, mit einer speziellen teueren Intel-Programmierstation, als es noch keinen PC gab. Die Dinger waren teurer als ein PC, und konnten aber sonst weiter nichts.
Häsch Define schrieb: > Du meinst wahrscheinlich einen Assembler. Ich weiß schon, was ich schreibe :-) Der Beitrag war als Antwort auf den Hinweis von Frank gedacht, der einen "de-C-her" gefunden hat. Mit MDS800, 8" Floppies und ISIS als "Betriebssystem" habe ich seinerzeit auch gearbeitet. Meinen schönen S100 CP/M Kasten, der deutlich schneller und bequemer war, wollte der Kunde nicht.
Georg G. schrieb: > Es würde mich nicht wundern, wenn auch das Eprom mit einem CRC > gesichert wäre. Nö, genau das gib es wohl nicht, dann wäre das leidige Thema "Bitfehler" aus der Welt (naja, aus dem Thread). Also ich hab jetzt nicht explizit danach gesucht, aber das wäre ja mit eine der ersten Sachen, die nach dem Reset erfolgen sollten, und da war nichts auffälliges, außer dieser zyklich gepulsten Sache, die unverständlich ist, wenn man nicht weiß was drausen dran hängt. Wahrscheinlich handelt es sich hier um die Abfrage von "Kommunikationslaser 17" und dies hier ist die Steuerung von "Bombe 20". ;) Und dann zitier ich mich mal selbst: Detlef Kunz schrieb: > Das wird wieder mal ein Spiel der Art: Ich sehe was, was du nicht > siehst.
Georg G. schrieb: > Mit MDS800, 8" Floppies und ISIS als "Betriebssystem" habe ich > seinerzeit auch gearbeitet. Meinen schönen S100 CP/M Kasten, der > deutlich schneller und bequemer war, wollte der Kunde nicht. Das waren doch beides vergleichsweise traumhafte Arbeitsumgebungen im Vergleich zu meinem damaligen Ablauf: - Programm auf Papier erstellen - per Hand in (Z80-)Maschinencode übersetzen, dabei tausendmal kontrollieren, ob die Branches korrekt berechnet waren - in der Schule am PET2001 oder CBM30xx eintippen - mit anderen Anwesenden um den Zugriff auf DAS gemeinsam genutzte Diskettenlaufwerk streiten - auf Diskette speichern - Diskette und EPROM und DM5,- einem Mitschüler (zwei Jahrgangstufen über mir) geben - den Mitschüler dazu bringen, obige Teile seinem Kumpel, der einen EPROM-Brenner besaß, geben zu lassen - ein bis zwei Wochen auf Rücklieferung des programmierten EPROMs warten - Programm ausprobieren Das war also ziemlich wenig praktikabel. Bei meinem SC/MP II konnte ich wenigstens den RAM-Inhalt per DIP-Schalter programmieren. Aber als ich dann meinen Sharp MZ-80K bekam, strickte ich mir dann auch gleich den EPROM-Brenner des NDR-Klein-Computers dran. Allerdings musste ich die Adressdekodierung etwas umbauen und natürlich eine Programmierroutine schreiben. Waren das die "guten alten Zeiten"? Nein. Ich habe dabei zwar sehr viel gelernt, aber wirklich produktiv war das nicht, selbst für Bastler. Einen Riesendurchbruch brachte dann der Hi-Lo Systems ALL-03, den ich mir um 1989 herum kaufte. Den Brenner habe ich immer noch, aber leider ist die Schnittstellenkarte irgendwann abhandengekommen. :-(
:
Bearbeitet durch User
Georg G. schrieb: > Das Programm stammt aus keinem der gängigen 8080 C-Compiler. Es fehlen > die typischen Funktionsprologe/Epiloge. 8080 und C ist auch eher selten. > Als C modern wurde, war der 8080 schon out. Danke dir, wieder was gelernt! Ist immer wieder interessant, Rechnerarchitektur in der Historie zu betrachten. Und zu meiner Verteidigung: zu der Zeit Ende 70er/Anfang 80er war ich auch noch Quark im Schaufenster... :)
WENN wie oben >L0000: C3 74 01 JP L0174 >L0003: F3 DI usw. ... noch lesbar sein sollte, dann ist dieser EPROM noch zu 90% gesund und hat höchstens Einzelbits, die gekippt sein könnTEN. Das kam aber seltener vor. Von der Wahtscheinlichkeit her sollte TS Mattias erst mal Spannungen prüfen und mit dem Komponententester kranke Verbindungen nach außen kontrollieren. Die SW ist von der Häufigkeit her gesehen seltener das Problem. Ich tippe eher auf äußere Einflüsse wie Überspannungsfolgen oder kaputte Eingänge, gerissene Leiterzüge ....
oszi40 schrieb: > WENN wie oben >>L0000: C3 74 01 JP L0174 >>L0003: F3 DI usw. > > ... noch lesbar sein sollte, dann ist dieser EPROM noch zu 90% gesund > und hat höchstens Einzelbits, die gekippt sein könnTEN. Hmm, das "usw." fehlt bei mir. Bedeutet das nun das der EPROM jetzt nur zu 89% gesund ist? ;) Ich versteh die Diskussion sowieso nicht. Man liest den EPROM aus und lässt den Brenner die Daten verifizieren. Wenn man ein guter Brenner hat, dann macht er es mit mindestens 2 Spannungen. Der Labtool48 machte das so. Ok, wie ich eben feststellen musste gehört mein Galep5 nicht zu den "gute" Programmern :(
Häsch Define schrieb: > Viele Programmer haben neben der Typenwahl auch noch separate > Einstellmöglichkeiten der Programmierspannung und der Betriebsspannung, > sogar mein Uraltgerät. Es geht hier nicht um die Programmierspannung, sondern um die Betriebsspannung beim auslesen. soul eye schrieb: > Matschige EPROMs haben aber eigentlich immer verlängerte Zugriffszeiten. > Daher lassen sie sich im EPROMmer mit 250 kHz noch auslesen, während sie > in der Applikation mit 1-2 MHz schon ausfallen. Sag ich doch auch. Schön gemächlich und mit der 20ns Routine. Und nicht mit den optimierten. Andreas Schweigstill schrieb: > Das waren doch beides vergleichsweise traumhafte Arbeitsumgebungen im > Vergleich zu meinem damaligen Ablauf: > - Programm auf Papier erstellen > - per Hand in (Z80-)Maschinencode übersetzen, dabei tausendmal > kontrollieren, ob die Branches korrekt berechnet waren > - in der Schule am PET2001 oder CBM30xx eintippen Welches Jahr war das etwa?
Michael_ schrieb: > Welches Jahr war das etwa? Hmmm, da muss ich überlegen... Das müsste so um 1982-1983 herum gewesen sein.
Andreas Schweigstill schrieb: > Das müsste so um 1982-1983 herum gewesen Ohje... wo war das denn? Ich durfte 1969 schon mit Lochstreifen (5 Kanal) an der Zuse arbeiten. Das waren hier dann ja paradiesische Zustände :-) 1982 gab es schon die ersten 5.25" Festplatten mit sagenhaften 5MBytes Kapazität, alternativ die 17" Laufwerke mit 14Mbytes fest und 7MBytes Wechselplatte. Einen Prozessor für den SC/MP-II habe ich hier noch, falls du was aufbauen möchtest, auch das dazu passende Eprom (5204) mit 512Bytes und 60V Programmierspannung. Der Programmer mit Kälberzähnen zur Dateneingabe ist leider schon verschrottet.
Bei Altersschwäche würde ich mir als erstes die Elkos ansehen bzw. ausmessen ist nicht selten das diese austrocknen und dann nur noch optisch vorhanden sind.
Andreas Schweigstill schrieb: > Hmmm, da muss ich überlegen... Das müsste so um 1982-1983 herum gewesen > sein. So "programmiert" habe ich wenig später etwa 84/85. Mit dem Robotron LC-80, da konnte man nur die Adresse und den Code als Hex sehen. Auf dem Papier mit Farbstiften die Sprünge und Unterprogramme markiert und dabei die Takte gezählt. Den Programmer aus der Doku hatte ich mir nachgebaut. Und für die alten 2708/U555 erweitert. Bei Bedarf würde der sicher noch funktionieren. Die Elkos werden es nicht sein. Auf der Platine waren selten welche, meist Keramik oder Tantal. Höchstens im Netzteil, das merkt man, wenn die Spannungen nicht stimmen.
Georg G. schrieb: > Andreas Schweigstill schrieb: >> Das müsste so um 1982-1983 herum gewesen > > Ohje... wo war das denn? Das war am Trave-Gymnasium in Lübeck, welches in Sachen Naturwissenschaften sogar ausgesprochen gut ausgestattet war. Wir hatten immerhin ca. zehn PET und CBM, die per IEEE-488 vernetzt waren und sich den Drucker und das CBM-4040-Doppeldiskettenlaufwerk teilten. Später kamen noch zwei CBM-8096 hinzu, deren über 32KB hinausgehenden Speicher jedoch keine Anwendung nutzen konnte. Um den Computerraum betreten zu dürfen, musste man formal schon den Informatikunterricht in der Oberstufe oder einen Computerkurz besucht haben. Ich war damals der einzige Mittelstufenschüler, der eine Ausnahmegenehmigung hatte. Das Problem war nämlich, dass es kaum qualifizierte Lehrer gab, die den Computerunterricht leiten durften. Dafür mussten sie selbst irgendeinen Kurs des Kultusministeriums besucht haben. Der mit Abstand fähigste Lehrer in Sachen Computer war jedoch mein Kunstlehrer. Wir bastelten in der Freizeit ziemlich viel an seinen Video-Genies (Tandy TRS-80-Clones) herum. > Ich durfte 1969 schon mit Lochstreifen (5 > Kanal) an der Zuse arbeiten. Das waren hier dann ja paradiesische > Zustände :-) Das war aber mit Sicherheit nicht an einem normalen Gymnasium. Eine der Lübecker Berufsschulen hatte damals aber auch schon einen Großrechner von Wang, an dem irgendwelche kaufmännische Software und COBOL gelehrt wurden. > 1982 gab es schon die ersten 5.25" Festplatten mit sagenhaften 5MBytes > Kapazität, alternativ die 17" Laufwerke mit 14Mbytes fest und 7MBytes > Wechselplatte. Ich kenne noch aus dem "Computerclub", den ein Lübecker Fachhändler wöchentlich veranstaltete und in dessen Rahmen man alle möglichen Systeme (Apple II, MZ-80K, TI-99/4(A), Exidy Sourcerer, Atari 400/800, usw.) bestaunen und ausprobieren konnte, auch noch eine gigantische Fest-/Wechselplatte mit 5+5MB von Cameo, die an einem Apple II hing. Kostenpunkt: 20kDM. > Einen Prozessor für den SC/MP-II habe ich hier noch, falls du was > aufbauen möchtest, auch das dazu passende Eprom (5204) mit 512Bytes und > 60V Programmierspannung. Der Programmer mit Kälberzähnen zur > Dateneingabe ist leider schon verschrottet. Hmmm, vielen Dank für das Angebot, aber so groß ist mein Interesse am SC/MP-II auch nicht mehr. Apropos 5204: solch ein EPROM ist mir zuletzt 1997 in einem damals nagelneuen(!) HF-Leistungsmeskopf von R&S über den Weg gelaufen.
:
Bearbeitet durch User
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.