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?
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.
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ß
>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
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.
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.
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
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...
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. :-(
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?
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.
Thread beobachten
Seitenaufteilung abschalten