Hallo zusammen. Kann mir eventuell jemand von euch einen Tip geben wie man die Bedingung für eine 'E48' Ausgabe in den angehangenen Dateien ausfindig machen könnte? Da kenne ich mich leider nicht so gut mit aus. Das System besteht aus 3 Platinen. Prozessorplatine, Platine zum speichern von Daten und eine Displayplatine mit 7 Segment Anzeigen (6 Stück). Auf der Prozessorplatine befindet sich eine Z8400 CPU, Z8420 PIO, Z8536 CIO, 1X TMM2016BP SRAM, 2x TMS27128 Eeproms und diverse Logic-IC's. Auf der Speicherplatine befindet sich ein PCF8571 SRAM wo Kalibrierdaten gespeichert werden. Leider hat der PCF8571 durch eine leere Pufferbatterie einen Teil seiner Daten verloren was zur Ausgabe dieses Fehlercodes führt. Jetzt wäre meine Frage ob man Anhand der Opcodes irgendwie nachvollziehen kann welcher Wert auf welcher Adresse fehlt oder fehlerhaft ist? Vom Hersteller gibt es dafür leider keinen Support mehr. Vielen Dank schon mal im voraus.
Angehängte Dateien:
-
PCF8571_Speicherinhalt.PNG
6,8 KB
Ein RAM ohne Spannung ist wie eine Uhr, die stehengeblieben ist. Irgendetwas kann man sicher ab- bzw. auslesen. Hat nichts mit eventuellen Opcodes zu tun.
Deine Disassemblate stimmen so nicht. Eeprom1.txt beginnt mit 6 Bytes text, nicht ops! Eeprom2.txt enthält komplett unsinnige Befehlsfolgen, zB unmittelbar aufeinander golgendes Beschreiben immer wieder desselben Registers; mmio dürfte nicht gemeint sein. Zudem ist die Adresslage unbekannt. So wird das nichts.
Percy N. schrieb: > Eeprom2.txt enthält komplett unsinnige Befehlsfolgen Nö, EEPROM2 ist tatsächlich der erste. Schau dir einfach mal den Anfang an: Initialisieren des Stackpointers, Einstellen des Interrupt-Modes:
1 | 0001 0000 31 FF D7 LD SP,0D7FFH |
2 | 0002 0003 AF XOR A |
3 | 0003 0004 ED 47 LD I,A |
4 | 0004 0006 ED 5E IM 2 |
5 | 0005 0008 F3 DI |
6 | 0006 0009 18 0F JR L0001 |
Ab hier sind es allerdings Daten:
1 | 0007 000B 00 NOP |
2 | 0008 000C 00 NOP |
3 | 0009 000D 00 NOP |
4 | 0010 000E 00 NOP |
5 | 0011 000F 00 NOP |
6 | 0012 0010 AA XOR D |
7 | 0013 0011 04 INC B |
8 | 0014 0012 DA 04 DA JP C,L0002 |
9 | 0015 0015 04 INC B |
10 | 0016 0016 DA 04 F2 JP C,L0003 |
11 | 0017 0019 03 INC BC |
also:
1 | .db 0, 0, 0, 0, 0 |
2 | .dw 4aah, 4dah, 4dah, 4dah, 3f2h |
Ab 3f2h stehen auch tatsächlich irgendwelche Daten-Tabellen (auf 3f1h befindet sich ein RET).
1 | 0018 001A 21 EA 02 L0001: LD HL,02EAH |
Hier geht's dann richtig los. Aber da durchzusteigen, ist 'ne Sisyphusarbeit, erstmal müsste man ja Daten und Code im Disassemblerlisting sauber separieren (wie ich das hier eben manuell angefangen habe). Bessere Disassembler konnten einen dabei auch unterstützen, indem sie beispielsweise durch Sprünge gar nicht erreichbaren Inhalte gleich von sich aus als Daten dargestellt haben, statt diese zu disasemblieren.
Vielen Dank für die Antworten. Habe gerade gesehen das die Dateien falsch beschriftet sind 2 ist Eeprom 1 und 1 ist Eeprom 2. Hatte die mal vor längerer Zeit als .hex in eine Oshonsoft Z80 Simulator Testversion geladen und die Software hat mir diese beiden Dateien ausgegeben. Seit dem versuche ich verzweifelt nach irgendetwas zu suchen was einer E48 Ausgabe ähnelt. Müsste ja theoretisch was mit 79H, 66H und 7F zu tun haben wenn ich das richtig verstanden habe. Hätte die beiden Eeprom-Daten auch als Hex und Bin zur Verfügung wenn man da mehr drin erkennen kann. Beste Grüsse
Ich habe eben einmal in das Datenblatt zum PCF8571 gesehen. Das ist ein ganz "normales" RAM. Also ohne jegliche Spannungsüberwachung. Sollte die CPU "merken", dass der Strom ausgefallen ist, so geschieht das wahrscheinlich über eine, im RAM abgelegte, Prüfsumme. Die wahrscheinlich bei jedem Rechnerstart überprüft wird. Sollte es so sein, so fällt das Problem in die Kategorie: "Kannste machen nix, muste gucken zu". ...aber Auch für den Hersteller sollte es eine Möglichkeit geben den "Erststart" zu ermöglichen. Also das RAM mit initialen (Defaults) Werten zu besetzen. Auch der Kunde sollte diese Möglichkeit haben. Zumindest die Werte zu ändern. Vielleicht gibt es hierfür einen "versteckten" Jumper. Die alten Werte sind aber, auf jeden Fall, unwiederbringlich im Nirwana.
Moin, - Klaus F. schrieb: > oder fehlerhaft ist? Vom Hersteller gibt es dafür leider keinen Support > mehr. Und wenn Du dem Hersteller Geld gibst? Auch Disassemblieren und Analysieren des Code gibt es nicht fuer umme. Best effort geht ja eigentlich immer und Du hast wenig zu verlieren. Gruesse Th.
Hallo. Ja das mit der Prüfsumme ist richtig. Ich habe durch einige rumprobiererei festgestellt das eine Checksum-8 Prüfsumme von Adresse 00-5E berechnet und nach Speichern in Adresse 7F geschrieben wird. Wird auch nach jeder geänderten Einstellung auf 7F aktualisiert.
Na ja schade. Kann man wohl nichts machen. Vielen Dank trotzdem an alle. Beste Grüße
Hast du eigentlich eine Idee, über welchen Port die von dir beobachtete Ausgabe erfolgt?
Noch etwas! Wenn Du jemanden kennst, der Dir den EPROM-Code Disassembliert, kannst Du eventuell eine Sequenz finden, die den Speicher (beim Erststart) initialisiert. Vielleicht sogar mit - für den Anfang sinnvollen - (Erfahrungs-)Werten. Die Sequenz könnte mit der Abfrage eines Jumpers verbunden sein.
Klaus F. schrieb: > Hallo. Meinst du an welchen Ports des PIO? PIO ist ja überhaupt schon mal 'ne Aussage. Lass dir mal nicht alles aus der Nase ziehen bitte. Wir haben doch keine Ahnung, was da wie verschaltet ist. Du hast eingangs was von „Ausgabe“ geschrieben, das kann von einer Siebensegmentanzeige bis zu einer seriellen Schnittstelle alles sein. Wäre auch cool, wenn du noch eine Idee hast, welche IO-Adressen besagte PIO (falls an dieser diese „Ausgabe“ dran ist) hat. Mit ein paar Details hätte man eventuell schon eine Chance, in dem Bithaufen was einzugrenzen. Was ebenfalls interessant sein könnte: wo hängt denn der I²C-Bus vom PCF8571 dran?
Laut Hersteller muß die ganze Platine mit dem PCF... getauscht werden. Der stellt die aber nicht mehr her. Die PLATINE läuft aber mit anderer Software (anderer Maschinentyp) einwandfrei. Ich habe mir sagen lassen das nur die im Eingang hochgelade Software mit dem Dauerspeicher "Verheiratet" wurde. Daher vermute ich stark das der PCF8571 von Werk aus mit Werten beschrieben wurde. Mfg
Ich habe nicht die geringste Ahnung von der verwendeten Hardware - und ob da tatsächlich ein Jumper/Schalter vorhanden ist. Wenn Du den disassemblierten Code hast, musst Du Dich, im Zweifelsfalle durch die Sequenzen hangeln, bei denen auf den Speicher zugegriffen wird. Ich hätte, so ich die teure PIO verwenden durfte, einen Port genutzt. Ist aber schon etliche-komma-fünf Jahre her – und manch einer hier im Forum hatte damals noch ein negatives Alter.
Ach so. Ja die Ausgabe von dem Fehlercode erfolgt auf der Displayplatine mit den 7 Segment Anzeigen. Der PIO ist auf jeden Fall mit einem MM5450 Display driver verbunden und von da aus an die 7 Segmentanzeigen. Mfg
Jörg W. schrieb: > PIO ist ja überhaupt schon mal 'ne Aussage. Lass dir mal nicht alles aus > der Nase ziehen bitte. Stand schon im ersten Beitrag.
Sorry, mir ist das zu viel Salami: alles kommt scheibchenweise. Bitte kritzele mal eine Skizze von dem Teil (Bleistift und Handyfoto genügt, wenn das einigermaßen scharf wird), auch die Adressen der Peripheriebausteine sind wichtig. Ohne solche Infos findet man in dem Code nichts. Bei dem MM5450 müsste man schon auch noch wissen, wo welche Pins der Siebensegmentanzeige dran sind, damit man eine Idee hat, nach welchem Bitmuster man tatsächlich suchen muss. Und es ist natürlich interessant, an welchen PIO-Pins der mit CLK und DATA klemmt.
Percy N. schrieb: > Jörg W. schrieb: >> PIO ist ja überhaupt schon mal 'ne Aussage. Lass dir mal nicht alles aus >> der Nase ziehen bitte. > > Stand schon im ersten Beitrag. Dass eine PIO da ist, ja. Dass die Anzeige an einem seriellen Schieberegister ist, haben wir gerade erst erfahren. Dessen CLK/DATA könnten nun auch noch an der CIO hängen, oder eben an der PIO.
Auf ports 00 und 01 scheint heftig mit verschiedenen bits gewackelt zu werden. Was mit port 58 ist, musst Du selbst herausfinden.
Klaus F. schrieb: > Welche Ports sind denn damit gemeint? IO Ports, also Adressen, die auf dem Adressbus ausgegeben werden und zusammen mit /IORQ decodiert. Typischerweise sitzt da sowas wie ein 74138 dafür drauf. Die unteren beiden (glaub' ich) Adressbits gehen direkt an die Peripheriebausteine durch, sodass jeder von ihnen insgesamt vier Adressen hat. Die nächsten drei Bits werden decodiert, damit lässt sich für bis zu 8 verschiedene Peripheriebausteine das /CS erzeugen. Die Verbindung der Ausgänge des 74138 zu den /CS-Pins dieser Bausteine ist daher wichtig. Dann hat der 74138 noch drei enable-Eingänge (verschiedene Polarität und verschieden logisch verknüpft). Im einfachsten Fall kann man die so verschalten, dass alle dauerhaft aktiv sind (mehr als 8 Peripheriebausteine werden bei dir ja nicht gebraucht), dann würden sich die IO-Adressen zyklisch wiederholen.
Danke für die ausführliche Erklärung. Muss mir das morgen mal genauer anschauen. Mfg
Angehängte Dateien:
-
Schaltung_Gesamt.jpg
240 KB -
Prozessor.jpg
240 KB -
Dauerspeicher.jpg
230 KB -
Display.jpg
240 KB -
Skizze_1.jpg
200 KB -
Skizze_2.jpg
220 KB
Guten morgen zusammen. Ich habe mal Fotos und Skizzen zur Schaltung erstellt. Die Skizzen sind zwar nicht schön aber man hoffentlich halbwegs die Verdrahtung erkennen. Diese Fehlermeldung lässt sich über eine angesteckte Folientastatur auch wegquittieren. Also wird die CPU wahrscheinlich irgendwo in einem Loop hängen bleiben bis die Taste betätigt wurde, oder wieder ausgeschaltet wird. Mfg
Habe die Eeproms auch noch mal mit dem https://onlinedisassembler.com disassembliert. Da sind keine Labels sondern direkt Adressen angegeben. Vielleicht kann man da mehr mit anfangen. Mfg
> Vielleicht kann man da mehr mit anfangen.
Grunsaetzlich ist das was du da willst kein PRoblem. Man muss deinen
Source nur einmal durch einen disassembler schicken und danach dann
30-40h von Hand mit Gehirnschmalz bearbeiten.
Dabei ist dein Problem vermutlich noch eher einfach weil man ja nur mal
relativ am Anfang die Stelle finden muss wo die Daten gelesen werden.
Es ist also auf jedenfall ein loesbares Problem!
Und das musst auch du tun und nicht wir. Zum einem muss man dabei
naemlich des oefteren mal deine Platinen in die Hand nehmen um
Leiterbahnen nachzuverfolgen, zum anderen was wuerdest du sagen wenn ich
dich bitten wuerde mal eben an meinem Auto den Motor zu wechseln. Das
duerfte naemlich so in etwas ein vergleichbarer Arbeitsaufwand sein.
Ich empfehle dir aber auch den Tip mit der Initialisierung nachzugehen.
Sowas muessen die ja in der Fertigung auch geloesst haben. Wenn du Pech
hast kann es natuerlich sein das man dazu von einem Fertigungsrechner
was reingeschrieben hat, aber deine Platinen sind ja relativ alt. Da
kann es auch sein das man nur einen Jumper stecken muss.
Olaf
Noch einen Tip,es waere extrem hilfreich wenn du einen Disassembler auftreibst der einen Source ausspuckt der selber wie assemblierbar ist und ein identisches Binaerfile liefert. Dann hast du naemlich einen sinnvolle Basis fuer Aenderungen am Code. Olaf
Olaf schrieb: > Grunsaetzlich ist das was du da willst kein PRoblem. Man muss deinen > Source nur einmal durch einen disassembler schicken und danach dann > 30-40h von Hand mit Gehirnschmalz bearbeiten. > Dabei ist dein Problem vermutlich noch eher einfach weil man ja nur mal > relativ am Anfang die Stelle finden muss wo die Daten gelesen werden. > Es ist also auf jedenfall ein loesbares Problem! > > Und das musst auch du tun und nicht wir. Zum einem muss man dabei > naemlich des oefteren mal deine Platinen in die Hand nehmen um > Leiterbahnen nachzuverfolgen, zum anderen was wuerdest du sagen wenn ich > dich bitten wuerde mal eben an meinem Auto den Motor zu wechseln. Das > duerfte naemlich so in etwas ein vergleichbarer Arbeitsaufwand sein. > > Ich empfehle dir aber auch den Tip mit der Initialisierung nachzugehen. > Sowas muessen die ja in der Fertigung auch geloesst haben. Wenn du Pech > hast kann es natuerlich sein das man dazu von einem Fertigungsrechner > was reingeschrieben hat, aber deine Platinen sind ja relativ alt. Da > kann es auch sein das man nur einen Jumper stecken muss. > > Olaf Danke für das Feedback. Ist nur die Frage wie z.B. so ein entsprechender Befehl(e) aussieht nach dem ich suchen muss. Mfg
out xx,y , ganze Gruppe von mnemonics xx sind beliebig zu wählende 16bit-Registerpaare bc, de, hl der Z80-CPU, deren Inhalt beim Ausführen des out-Befehls auf die Adressleitungen der CPU gelegt werden, auf die Datenleitungen der Inhalt von (register) y, beispielsweise des accus, oder direkt auf den out-Befehl folgende Zahl. Dazu IOrequest statt Memoryrequest als Steuerleitung. Ports sind also als solche adressierbar und nicht als "einfache" Speicheradressen. Lesen geschieht mit der Begelsgruppe in xx....
Entweder die 8080-lompatiblen OUT (xx),yy mit xx und yy jeweils 8-bit-Wert; diese Form taucht in Deinem ersten Disassemblat auf. Oder OUT rp, r OTIR & Co nicht vergessen!
Klaus F. schrieb: > [...] > > Danke für das Feedback. Ist nur die Frage wie z.B. so ein entsprechender > Befehl(e) aussieht nach dem ich suchen muss. > Mfg Der Speicherzugriff wird mit einem der LD- (lade-) oder der Block-Transfer-Befehle realisiert sein. (Eine andere Möglichkeit gibt es nicht). Es lässt sich nur leider nicht sagen, welcher davon oder welche Adressierungsart der LD-Befehle verwendet wurde. Der Block-Transfer wäre etwas einfacher zu finden. Nur das möglicherweise, die Zieladresse im DE-Registerpaar das Ergebnis einer Berechnung sein könnte, so dass die Speicheradresse etwas aufwendig zu ermitteln ist. Allerdings halte ich das eher für unwahrscheinlich, falls es darum geht, die Stelle mit der Initialisierung zu finden. Kommt darauf an, ob der Autor versucht hat, diese Funktion zu verbergen. Es wäre notwendig, dass Du die Adressierungsarten und zumindest die LD und Befehle kennst. Z.B. das Dokument hier: http://z80.info/zip/z80cpu_um.pdf enthält eine Befehlsbeschreibung. Es gibt noch andere - und vermutlich nach der langen Zeit -, auch solche in deutscher Sprache. Ausserdem musst Du irgendwie sinnvoll mit dem Problem umgehen, dass Jörg oben erwähnt hat. Nämlich, dass ein einfacher Disassembler nicht zwischen Code und Daten unterscheiden kann. Du musst also, - dafür gibt es Software-Werkzeuge, falls Du das nicht ganz "von Hand" machen willst -, den Code ganz durchgehen und entscheiden, - zum Teil kann das das erwähnte Werkzeug -, ob ein Speicherinhalt ein Befehl oder ein Datum ist.
Klaus F. schrieb: > Da sind keine Labels sondern direkt Adressen angegeben. Vielleicht kann > man da mehr mit anfangen. Ganz schlechte Idee. Theor schrieb: > Ausserdem musst Du irgendwie sinnvoll mit dem Problem umgehen, dass Jörg > oben erwähnt hat. Nämlich, dass ein einfacher Disassembler nicht > zwischen Code und Daten unterscheiden kann. > Du musst also, - dafür gibt es Software-Werkzeuge, falls Du das nicht > ganz "von Hand" machen willst -, den Code ganz durchgehen und > entscheiden, - zum Teil kann das das erwähnte Werkzeug -, ob ein > Speicherinhalt ein Befehl oder ein Datum ist. In Deinem ersten Disassemblat erkennt man verschiedene kurze Subroutinen,,die jeweils mit einem RET beendet wertden. Danach geht der Vode teilweise einfach mit der nächsten Subroutine weiter, obwohl nach dem RET im Normakfall ein Label folgen sollte. Daran erkennt man, dass etwas nicht stimmt, mit hoher Wahrscheinlichkeit die Adresslage. Dasurch zeigen absolute Sprungadressen auf andere Speicherstellen als den Code. Deinen Onlinedisassembler kenne ich nicht; ich habe früher gern mit RESOURCRCE von Ward Chtistensen gearbeitet; die Z80-Version heißt REZ.COM. Du solltest es ebenso wie einen geeigneten CO/M-Emulator im Betz finden können.
Moin, - bei Eprom2 sieht man den Start-code (Stack auf 0x0d7f, dann weisst Du, wo der 2k Block ist). Die initialisierung auf Port 02 und 03 mit OTIR ist offensichtlich, Port 01 ist Read and Write (0x004e [in, Set bit, out]). Mit Datenblatt und Durchgangspieper gucken, was bei 02 und 03 ist. Die SDA/SCL beim I2C-RAM durchklingeln, bei der Z80 muss das I2C per Hand gemacht werden. Dann Memory-Map bauen. Der Inhalt von Eprom1 ist kein "ueblicher" Z80-Code, 0x123456 am Anfang koennte ein "Option-Rom"-Kennung sein. Dann ein paar Sprung-Tabellen (alles auf 0x4000 - 0x7fff). Ist keine Rocketscience, aber muehsam. Ein Paar Disassembler/Assembler (so dass Du dein Disassembler-Output als Input fuer den Assembler benutzen kannst) waere sehr hilfreich. Offensichtlich notwendig: Eproms, UV-Loeschlampe und Eprom-Brenner. Gruesse Th.
Ich werfe dazu noch einen billigen EzUSB Logikanalysator (10€) + sigrok (0€) in den Ring. Der LA kann 16 bit, das reicht für den Datenbus und ein paar Steuersignale und sigrok hat einen Z80-Decoder dabei. Bestell in Europa, dann ist das Teil in einer Woche da. Ein paar Stunden, um alles ans Laufen zu bringen und verstanden zu haben. Laufen lassen und auf Lesesignal vom Speicher triggern und schauen, was vor dem Trigger passiert ist; das gleiche nochmal mit den Adressen. Das grenzt das Problem schneller ein, als die Z80 + HW durch einen extrem langsamen Emulator (aka. brain + pen + paper) laufen zu lassen.
Martin H. schrieb: > Ich werfe dazu noch einen billigen EzUSB Logikanalysator (10€) + sigrok > (0€) in den Ring. Der LA kann 16 bit, das reicht für den Datenbus und > ein paar Steuersignale und sigrok hat einen Z80-Decoder dabei. Bestell > in Europa, dann ist das Teil in einer Woche da. Ein paar Stunden, um > alles ans Laufen zu bringen und verstanden zu haben. Laufen lassen und > auf Lesesignal vom Speicher triggern und schauen, was vor dem Trigger > passiert ist; das gleiche nochmal mit den Adressen. Das grenzt das > Problem schneller ein, als die Z80 + HW durch einen extrem langsamen > Emulator (aka. brain + pen + paper) laufen zu lassen. Hallo Martin. Ja das mit dem LA hatte ich auch noch vor. Hatte ich schon bestellt und ist heute angekommen. Probiere das bei Gelegenheit mal aus. Eeproms, Eepromlöscher und Programmer habe ich auch da. Mfg
Was mir in deinen Skizzen noch fehlt ist der IO-Adress-Decoder. Der entscheidet ja über die Bausteinadressen, also den ersten Parameter bei OUT und den zweiten bei IN. Was mir ebenfalls noch nicht klar ist: SDA muss bidirektional sein, du willst ja was aus dem EEPROM lesen können. Auch wer den Clock für die beiden LED- und Displaytreiber bereitstellt, ist nicht klar.
> Ist nur die Frage wie z.B. so ein entsprechender > Befehl(e) aussieht nach dem ich suchen muss. Wie sieht der Geldschein aus mit dem du ein neues Auto kaufen kannst? :-D Also theoretisch musst du den ganzen Source einmal von Anfang bis ende durchlesen und verstehen. Und dabei noch gleich das richtig fummeln was ein dummer Disassembler nicht schafft. Eine Aufgabe von Monaten! Da aber zu vermuten ist das das was du suchst eher am Anfang des Programmlaufs vorkommt besteht die Hoffnung das es in Tagen loesbar ist. Allerdings multiplizieren sich diese Tage bei deinem Wissenstand leider zu Wochen. Aber danach kannst du Z80 Assembler programmieren. Ist doch auch mal was. Braucht zwar heute keiner mehr, ist aber die Grundlage um ein guter Embeddedprogrammierer für Hochsprachen zu sein. .-) Olaf
Das beste ist so wie ich das hier sehe ist, ich warte einfach bis mir noch so eine Maschine ohne diesen Fehler über den Weg läuft. Hatte eigentlich auch von keinem erwartet das er das Problem für mich löst. Das ich von diese komischen Z80 Kram keine Ahnung habe hatte ich Eingangs geschrieben. Danke trotzdem an alle Beteiligten.
Klaus F. schrieb: > Hatte eigentlich auch von keinem erwartet das er das Problem für mich > löst. Wie auch, wenn Du beharrlich die Beschaltung der Adressdekoder verheimlichst?
@ Klaus F. Au weia. Ich sehe eben erst, dass die Konfigurationsdaten in einem RAM mit seriellem Bus gespeichert sind. Dann ist mein Beitrag oben nicht sinnvoll, Tut mir leid. (@ Mods: Kann ggf. gelöscht werden, falls Ihr das für sinnvoll haltet).
Moin, - Klaus F. schrieb: > Das beste ist so wie ich das hier sehe ist, ich warte einfach bis mir > noch so eine Maschine ohne diesen Fehler über den Weg läuft. Falls Du noch mitliest: Du hast eine Maschine (il macchina) gekauft. Da sind Kalibrationsdaten im RAM gespeichert (fuer diese individuelle Macchina), gepuffert mit einem Akku mit endlicher Lebensdauer. Jetzt ist der Strom alle und il Macchina ist Elektroschrott. Ist das ungefaehr die Zusammenfassung? Backup: Ist nicht moeglich. Neuer Satz Kalibrationsdaten: gibt nicht mehr. Jetzt verstehe ich warum Stallman so verpisst war dass er die GPL ins Leben gerufen hat. Gruesse Th.
Thomas W. schrieb: > gepuffert mit einem Akku mit endlicher Lebensdauer. Aber wo ist er denn? Das längliche Teil über dem blauen Stecker?
Wieso sind auf ALLEN Fotos jegliche Nummern, Aufkleber (Eproms), Platinenversionen absichtlich unkenntlich gemacht? Wieso wird der Name der Steuerung/Maschine nicht genannt? Sondern verschwiegen? Fällt das nur mir auf? Warum sollen zielführende Tipps ja nicht für andere, spätere Leser mit Fabrikat und Typ der Maschine verknüpfbar (suchbar) sein?
Nichtverzweifelter schrieb: > Wieso wird der Name der Steuerung/Maschine nicht genannt? Vielleicht könnte der Hersteller was dagegen haben??? Stichwort Copyrights
> Fällt das nur mir auf?
Hat mich auch schon gewundet. Ziel ist die Minimierung des Hilfserfolgs.
:-D
Olaf
Olaf schrieb: >> Fällt das nur mir auf? Die Binaries der Eeproms hat er auch nicht zur Verfügung gestellt, um sie mal zwecks Hilfe durch einen Simulator jagen zu können...
Klaus F. schrieb: > Hätte die beiden Eeprom-Daten auch als Hex und Bin zur Verfügung wenn > man da mehr drin erkennen kann. Hat da ingendwer mal nach gefragt. Es heißt immer nur "Monate lange Arbeit". Helfen will doch eh keiner. Aber ist nicht schlimm. Mfg
Klaus F. schrieb: > Vielleicht könnte der Hersteller was dagegen haben??? Stichwort > Copyrights Was ist das denn für ein Blödsinn? Aber disassemblierte ROM-Listings stellst Du hier einfach ein? Oder soll die Provenienz des Gerätes verschleiert werden, warum auch immer? Klaus F. schrieb: > Helfen will doch eh keiner. Du brauchst ganz andere Hilfe.
Hofmann Geodyna 88? https://www.motor-talk.de/forum/reifenmontiergeraet-hofmann-geodyna-88-t6281634.html
> Hofmann Geodyna 88?
Interessant. Man fragt sich wofuer so eine dumme Schuessel ein Ram
mit Kalibrierdaten braucht...
BTW: Ich muesste noch irgendwo eine Stange mit den I2C-Rams rumliegen
haben,
waren ja IMHO das erste I2C-IC das damals abgekuendigt wurde weil da
kein richtiger Sinn fuer vorlag nachdem die Fernseher keinen MCS48
mehr verwendet haben. :-D
Olaf
Klaus F. schrieb: > Das beste ist so wie ich das hier sehe ist, ich warte einfach bis mir > noch so eine Maschine ohne diesen Fehler über den Weg läuft. Hatte > eigentlich auch von keinem erwartet das er das Problem für mich löst. > Das ich von diese komischen Z80 Kram keine Ahnung habe hatte ich > Eingangs geschrieben. Du hättest es besser haben können, wenn du dich nicht gar so sehr bedeckt gehalten hättest. Also wenn du geschrieben hättest, was du da für eine Maschine vor dir hast und wenn du z.B. anstelle der zwei Textdateien einfach den binären Inhalt beider Speicher-IC's gepostet hättest. Und nein, dieses Forum ist zwar hilfreich, aber es ist kein Cola-Automat, wo man auf den Knopf drückt und schon kommt der Pappbecher mit dem fertigen Drink heraus. Etwas eigene Arbeit (auch Einarbeitungsarbeit in den Z80) wäre vonnöten gewesen, schließlich ist es DEINE Maschine, die jetzt doof herumsteht und nicht mehr benutzbar ist. Hier gibt es genug Leute, die einen durchaus lesbaren Quellcode aus deinen EPROM-Inhalten machen können, so daß dir alles Weitere leichterfallen würde. W.S.
W.S. schrieb: > Und nein, dieses Forum ist zwar hilfreich, aber es ist kein > Cola-Automat, wo man auf den Knopf drückt und schon kommt der Pappbecher > mit dem fertigen Drink heraus. :-) Dass ich dir mal 100%ig zustimme, passiert sicher selten. Kannst drei Kreuze in den Kalender machen. ;-)
Hallo. W. S. Das ist alles schon richtig. Aber ich habe ziemliche Bauchschmerzen dabei gehabt die Binär Dateien sowie Typ und Hersteller in einem Forum zu veröffentlichen. Das ist die Sache nicht wert. Kenne mich mit den Urheberrechten etc. nicht aus und habe kein Bock mich mit dem Hersteller anzulegen. Die beiden Textdateien kann man jedenfalls nicht so einfach wieder in Binär Files wandeln und vervielfältigen. Ja ist jetzt blöd gelaufen. Mfg
Naja, wenn der Hersteller etwas nicht mehr supporten will, dann ist das verständlich (Aufwand vs. Nutzen), aber dann muss er auch damit leben, dass sich $KUNDE Hilfe woanders sucht. Das Ding wird eh keiner mehr 1:1 nachbauen heutzutage, nicht einmal in China. :-)
Moin, - dafuer wurde auch im UrhG ein paar Passus eingefuehrt. In a nutshell: Wenn der Hersteller das Ding nicht mehr supported oder der Hersteller nicht mehr existiert, darf der Eigentuemer des Geraetes die SW dekompilieren und "reparieren" (UrhG §69d). Aber nur fuer den eigenen Bedarf, darf aber Hilfe suchen. Aber natuerlich muss der Eigentuemer des Geraetes den Urheber vorher fragen. Gibt er Dir ein Angebot ab (z.B. eine Fantastilliarde) kannst Du nichts mehr machen. Das ist natuerlich sehr vereinfacht erklaert, aber Moeglichkeiten gibt es schon. Ob sich das lohnt muss sich der TO ueberlegen, denn die gebraucht verfuegbaren Platinen sind latuerlich genau so alt wie das Exemplar dass er auf dem Tisch hat. Gruesse Th.
Hallo Jörg W. Das stimmt natürlich. Ist ja mittlerweile auch schon über 30 Jahre alt das gute Stück. Hofmann selbst hat die Sparte irgendwann mal an Snap-On abgegeben. Und dort ist man bei den alten Dingern nur bereit zu reparieren wenn man sich die Ersatzteile so wie in diesem Fall die Anpassplatine selbst besorgt. Und ob die das wieder ans laufen bekommen geben die auch keine Garantie. Mfg
Klaus F. schrieb: > Die beiden Textdateien kann man jedenfalls nicht so einfach wieder in > Binär Files wandeln und vervielfältigen. hust, hust …
1 | perl -ne 'chomp; next unless /^\d{4} [0-9A-F]{4} ([0-9A-F ]{11})/; $x=$1; $x=~tr/ //d; @x = pack("H*", $x); print @x;' Eeprom_2.txt > Eeprom_2.bin
|
OK, mein Perl ist ein bisschen rostig geworden, dauerte 5 Minuten länger als gedacht …
Also wenn du noch irgendwie Hilfe haben willst, solltest du dich mindestens mal um die Belegung des IO-Adress-Decoders kümmern.
Eeprom_1 ist übrigens nur bis Adresse 2385H wirklich gefüllt; der restliche Inhalt ist identisch mit dem von Eeprom_2 (also vermutlich mit einem "dirty buffer" programmiert worden).
Hallo Jörg W. Kannst du mir bitte die Namen der Adress Decoder sagen. Wahrscheinlich schon mal der 74139 oder? Eeprom 2 ist übrigens nur für die Feinwuchtungsfunktion. Wenn E48 beim Selbsttest ermittelt wird dann hat der komplett keine Funktion. Dann läuft die angeblich nur mit Eeprom 1. Ich lade die Bin Files gleich mal hoch und hoffe ich wecke keine schlafenden Hunde. Mfg
Klaus F. schrieb: > Kannst du mir bitte die Namen der Adress Decoder sagen. Wahrscheinlich > schon mal der 74139 oder? 74138, schrieb ich schon mal. Gab's auch als i8205 in gut heizender Schottky-TTL. ;-) http://kazojc.com/elementy_czynne/IC/8205-3.pdf (Erstaunlich, dass davon kaum ein Datenblatt zu finden ist.) > Eeprom 2 ist übrigens nur für die Feinwuchtungsfunktion. Das ist der, der bei dir Eeprom_1.txt heißt. Ja, wurde ja schon gemutmaßt, dass der eine Art Add-On ist. Hat am Anfang diese 123456 stehen und danach einen Sprungverteiler. > Ich lade die Bin Files gleich mal > hoch und hoffe ich wecke keine schlafenden Hunde. Wie geschrieben, mit obigem Stücken Perl fallen die auch aus deinen Listings raus. ;-)
Zumindest passen sie zu meinen rekonstruierten Daten. ;-)
1 | $ sha256 -r *bin *BIN |
2 | b2917a472095c6126ac372ae2031cb657bec4a1568ced367a1fcb654069f4035 Eeprom_1.bin |
3 | fc6be8ca4d430f82065fc99e06547a502bb518944e731043d559fbce275e2a2b Eeprom_2.bin |
4 | fc6be8ca4d430f82065fc99e06547a502bb518944e731043d559fbce275e2a2b GEODYNA88_V4.1_IC4_VERSION_884_CKS_ED13.BIN |
5 | b2917a472095c6126ac372ae2031cb657bec4a1568ced367a1fcb654069f4035 GEODYNA88_V4.2_IC5_VERSION_884_CKS_ED7B.BIN |
Jörg W. schrieb: > hust, hust … Ach was, das ist so nebenbei überhaupt kein Problem. Aber: was ich geradezu unverschämt finde, ist ein Hersteller, der irgend etwas Wichtiges_ bei einem Gerät in einem _volatilen (!!!!!!) Speicher aufhebt und keinerlei Not-Zurück-zum-Urzustand vorgesehen hat. So einer gehört frei nach Osmin behandelt (zuerst geköpft und dann gehenkt usw..) Aber vielleicht ist so eine Restaurierungs-Routine ja in der Firmware vorhanden und ist bloß nicht dem Käufer mitgeteilt worden. Mir ist es aber ein bissel zu aufwendig, hier ne komplette Rückübersetzung für knapp 32K Code zu liefern. Die obigen Textdateien sind Käse, denn im Code wird viel mit Tabellen gemacht. IM2, I=0. RAM wohl C000..DFFF, ach wer will soll selber mal reinschauen. Ohne Stromlaufpläne wird mir das aber zu abenteuerlich. W.S.
Respekt. Wie hast du die Textdateien denn Übersetzt bekommen? Ja finde ich auch ziemlich unverschämt das nach Ausfall der Batterie die gesamte Platine getauscht werden musste. Da werden die wohl ordentlich mit verdient haben. ;)
Moin, - es ist ein wenig komisch: ab 0x0010 ist eine Interrupt-Tabelle (04aa,04da, 0xf2), die Routinen sind auch schoen mit RETI abgeschlossen. Die einzige Initialisierung finde ich ab 0x001a, jeweils zwei Bytes nach Port 2 oder 3: Meine Vermutung: Port 0x00 und Port 0x01 sind PIO ein/Ausgaenge, 02/03 sind die zugehoerigen Command-Ports der Z80-Pio. Initialisierung mit 0xCF, F9: Das passt auch schon, denn ein 0xcf auf die PIO gibt ein bitweises I/O, 0xF9 ist die Bit-maske die Ein/ausgaenge definiert. Spannend ist was fehlt: Setzen der Interrupt-Vektoren (die muessten ca. 0x0010 sein), das Nicht-init der Z8536 CIO. Gruesse Th.
W.S. schrieb: > Jörg W. schrieb: >> hust, hust … > Aber: was ich geradezu unverschämt finde, ist ein Hersteller, der irgend > etwas Wichtiges_ bei einem Gerät in einem _volatilen (!!!!!!) Speicher > aufhebt und keinerlei Not-Zurück-zum-Urzustand vorgesehen hat. So einer > gehört frei nach Osmin behandelt (zuerst geköpft und dann gehenkt usw..) Beitrag "Re: Hilfe bei Z80 Opcodes" Gruesse Th.
W.S. schrieb: > Aber vielleicht ist so eine Restaurierungs-Routine ja in der Firmware > vorhanden und ist bloß nicht dem Käufer mitgeteilt worden. das koennte natuerlich sein. Selbst meine Billig-Wasch-Maschine von AEG hat (nach Magic Tasten druecken) einen Fehler-Reset (nur durch Google gefunden). In der Gebrauchsanleitung stand: Rufe Service. Sende Geld. Gruesse Th.
Mit was für IDE's oder Software und was für Betriebssysteme arbeitet ihr beiden denn da wenn ich mal fragen darf? Ich suche schon monatelang im Netz nach sowas. Gruß Klaus
IDE? Emacs :-) Aber das Rückgewinnen des EPROM-Inhalts habe ich wirklich direkt auf der Kommandozeile zusammen editiert. Das ist ja 'ne Eintagsfliege, die muss ich mir nicht aufheben. Benutzter Perl-Script steht oben.
Der Klaus soll mal die Hardware "liefern". Um einen Port anzusteuern legt die Z80 CPU bei einem out -Befehl den Pin IOreq (=Input Output request) auf active low, da es sich um einen Schreibvorgang handelt zusätzlich den Pin WR (=write) auf low, und auf den Adressbus die portadresse. Ein möglicher Adressselector, gier ein 3bit zu 8 Ausgänge Decoder 74138 wurde genannt, über dessen Beschaltung kannst Du die realen portadressen ermitteln. Einfacher gehts auch: An den unteren 8 Adressleitungen, kann man direkt 8 Portbausteine anschliessen, an jede Leitung einen. Nur derjenige wird dann mit low angesteuert, alle anderen Adressbits bleiben high. Schwupp, kannst Du Dir die wenigen, möglichen Bitkombinationen zusammensetzen, also aus der Leitungsführung eines ChipSelect-Pins eines Portbausteins zurück, auf welche Adressleitung, oder welchen Ausgang des zusätzlichen 3 zu 8 Decoders diese Leitung halt führt. Suche dann nach den entsprechenden Kombinationen aus dem Byte für den out-Befehl sowie dem nachfolgenden Adressbyte. Diese Zweierkombination suchst Du dann im Code. Es wurde schon geschrieben, dass das serielle Hineintakten und Hineinschreiben in den I 2 C (i-quadrat c) RAM durch Programmcode erzeugt werden muss. Vielleicht hilfts. Gaaaanz anderer Weg: Aus betriebsbereiter weiterer Maschine den anscheinend nötigen Grunddatensatz "kopieren", danach evtl. vorhandene Nachkalibrierung starten (soweit vorhanden). Dazu brauchts aber etwas Zusatzhardware.
Übrigens möchte ich anmerken, dass Dir im Thread reichlich Leute Hilfestellung angedeihen lassen. Auch sehr detailliert und strategisch richtig. Dein "beleidigtes" Mir-will-eh-keiner-helfen ist etwas unangebracht.
Aha. Auf der Platine ist kein 138er drauf. Nur 139(oben über dem RAM). Unter Eeprom1 die 5 sind dann noch 11, 32, 74, 04 und 393er. Und Nu?
Nichtverzweifelter schrieb: > Übrigens möchte ich anmerken, dass Dir im Thread reichlich Leute > Hilfestellung angedeihen lassen. Auch sehr detailliert und strategisch > richtig. Dein "beleidigtes" Mir-will-eh-keiner-helfen ist etwas > unangebracht. Ja sorry an alle. Da hast du natürlich recht. Mfg
Klaus F. schrieb: > Aha. Auf der Platine ist kein 138er drauf. Nur 139(oben über dem RAM). Den kannte ich bislang noch gar nicht. Vermutlich macht der sowohl die Decodierung des Speichers als auch der Peripherie mit je einer Hälfte. Da ja nur drei Speicher- und zwei IO-Bausteine benutzt werden, genügen jeweils vier Pins. Ich würde an deiner Stelle von den Chipselect-Pins der Peripheriebausteine rückwärts verfolgen, dann weißt du, welche Hälfte des '139 für IO zuständig ist. Dann musst du schauen, wohin die zugehörigen Adressleitungen an die CPU gehen (vermutlich sind das A3 und A4) und wie der zugehörige Enable-Pin (der '139 hat pro Kanal nur einen) verschaltet ist. Könnte sein, dass der direkt an /IORQ der CPU geht.
Du suchst Dir den Chipselect Eingang eines Portbausteins heraus, und gehst rückwärts die Leiterbahn entlang, sie muss ja an der CPU oder dem Ausgang eines (von mir aus 139ers) enden... Endet sie an dem 139er suchst Du Dir einfach TTL 74139 pinout, wirst das Innenleben finden und kannst hieraus rückwärts die Bitkombination ermitteln, die zur Aktivierung genau dieser einen Leitung führt. Der 138er (acht) wäre ein 3 zu 8 Decoder 3 bits a,b,c ergeben acht möglichkeiten, nur der eine aus acht Ausgang wird aktiv, aktiviert den daran angeschlossenen Portbaustein, einigermassen klar verständlich? Ja, es gibt auch ein hartverdrahtetes Interruptschema, bei dem ausschliesslich Z80 Bausteine in einer DaisyChain hintereinandergeschaltet sind. Ob das hier so gemacht/benutzt wird, weiss ich einfach nicht. Ich hab die Platinen samt Leiterbahnen, doppelseitig, ja nicht vor mir. Eindeutig wird es eben nur, wenn Du die restliche Beschaltung ergänzen kannst. Um den Beispiel 7474er brauchst Du Dich schon mal nicht kümmern, 04er sind auch nur einzelne Inverter, die höchste Wahrscheinlichkeit, die einzelnen ICs auf den vorhandenen Adressraum zu verteilen, word wohl über den 139 laufen.
Ok. Werde das mal versuchen so wie ihr das erklärt habt. Kann ein bißchen dauern da das Neuland für mich ist. Bei Fragen melde ich mich nochmal. Vielen dank
Viel Erfolg. Tatsächlich "einfacher" wäre die "Raubkopie" des NVRAMs aus einer zweiten Maschine. Die müsste man aber erst einmal haben! Ausserdem wäre die Kalibrierung nicht richtig, wohl würde die Firmware aber "gültige Kalibrierdaten" vorfinden und nicht in der Fehlermeldung 48 verharren. Damit wäre die Maschine bedienbar, jetzt eben nicht.
Nichtverzweifelter schrieb: > Tatsächlich "einfacher" wäre die "Raubkopie" des NVRAMs aus einer > zweiten Maschine. Ja das wäre am einfachsten. Aber die Kisten werden auch langsam immer rarer. Ich kenne alleine schon 2 Leute aus Foren die das gleiche Problem damit haben. Plus der aus dem Motortalk Forum. Wenn man welche findet haben die meistens immer irgendwelche Fehler. Alles nicht so einfach. Mfg
Habe das Teil mal durch dZ80 geschickt und mir dabei Mühe gegeben, die eingebetteten Datenbereiche zu finden. Weiß nicht, ob alles stimmt, aber zumindest grob sollten sie passen. Nett an diesem Teil: es kann ein "reference file" schreiben, und man kann darin bspw. alle im Code referenzierten IO-Ports notieren lassen. Das sollte die Suche nach den IO-Adressen ein bissel einschränken.
Angehängte Dateien:
-
Skizze.jpg
220 KB -
logic_analyzer_pcf.PNG
210 KB
Hallo. Sorry das ich mich erst jetzt melde. Habe oben die Beschaltung angehangen. Die scheint etwas anders zu sein wie vermutet. Desweiteren hab ich an den I2C Bus des PCF mal einen Logic Analyzer drangehangen und gestartet. Das ist alles was bis zum Fehlercode da passiert. Wenn ich das richtig interpretiere möchte die CPU anscheinend Daten von Adresse 7B haben. Da ist natürlich kein Eintrag. Oder muss das anders ausgewertet werden? Mfg
Ich nutze in solchen Fällen gern z80dasm: https://www.tablix.org/~avian/git/z80dasm.git/ Damit lassen sich Symbole und Blöcke in separaten Dateien definieren und es kommt ASM-Code raus, der sich mit z80asm bitgenau wieder zum originalen Binary verwandeln läßt. Radare2 ist auch sehr mächtig, wenn man es aber nicht täglich nutzt, vergisst man die nötigen Shortcuts: https://www.radare.org/r/ Für Geld und Windows gibt (bzw. gab, ich kann keinen Z80 Support mehr erkennen) es noch IDA Pro, aber damit habe ich keine Erfahrung: https://www.hex-rays.com/ GHIDRA von der NSA kann wohl auch Z80, ich habe damit aber auch keine Erfahrung: https://ghidra-sre.org/ Thomas W. schrieb: > es ist ein wenig komisch: ab 0x0010 ist eine Interrupt-Tabelle > (04aa,04da, 0xf2), die Routinen sind auch schoen mit RETI abgeschlossen. Beim Z80 kommt im Interrupt mode 2 (IM2) der Highteil des Interruptvektor aus dem I-Register und der Lowteil aus der Peripherie. Das I-Register wird an Adresse 4 mit 0 initialisiert. So ganz klar ist mir aber auch nicht, wie die Interruptroutinen (03F2h, 04AAh und 04DAh) hier angesprungen werden. Dises ominöse serielle RAM scheint ja in den Speicher an die Adressen 0CFF0h bis 0CFF3h gemappt zu werden. Hat das Ding eigentlich eine serielle Schnittstelle oder eine ASCII-Tastatur? Ab Adresse 0B48H steht eine Sprungtabelle, die ASCII-Zeichen auswertet (E C-ALUHbdpc).
Hallo Jörg. Wie funktioniert die Ansteuerung an ein 7 Segment Display überhaupt. Legt die CPU jeden Buchstaben / Zahl einzeln mit der Zieladresse auf den Datenbus? Kann mir das irgendwie schlecht vorstellen. Speziell wie man da jetzt mit der suche in der .asm beginnt. Mfg
Angehängte Dateien:
-
Tastatur.PNG
56 KB
Bernd schrieb: > Hat das Ding eigentlich eine serielle Schnittstelle oder eine > ASCII-Tastatur? Hallo. Da ist eine einfache Folientastatur dran. Damit werden dann einfach die 9 Pins rechts an der Displayplatine gebrückt. Mfg
Moin, - > Thomas W. schrieb: >> es ist ein wenig komisch: ab 0x0010 ist eine Interrupt-Tabelle >> (04aa,04da, 0xf2), die Routinen sind auch schoen mit RETI abgeschlossen. > Beim Z80 kommt im Interrupt mode 2 (IM2) der Highteil des > Interruptvektor aus dem I-Register und der Lowteil aus der Peripherie. > Das I-Register wird an Adresse 4 mit 0 initialisiert. So ganz klar ist > mir aber auch nicht, wie die Interruptroutinen (03F2h, 04AAh und 04DAh) > hier angesprungen werden. Du hast aber die Haelfte meines Posts uebersehen: Ich habe keine Init-Routine fuer die CIO gesehen (Pio an 0x00-0x03 halte ich fuer sicher, die Steuercodes sind schon passend. Was fehlt ist die Interrupt-Vektoren fuer die Pio). Der CIO Z8536 ist relativ komplex zu programmieren und das fehlt mir etwas. Tabelle Register <-> Wert mit OTIR geladen, und da muss auch etwas initialisiert in der Art (z.B.) Timer2 Overflow -> Interrupt -> Pointer auf die Interrupt liste. Das fehlt alles. > Dises ominöse serielle RAM scheint ja in den Speicher an die Adressen > 0CFF0h bis 0CFF3h gemappt zu werden. Warum? Gruesse Th.
Ach! Genau solche Threads wie Dieser machen das "Mikrkontroller.net" zur Pflichlektüre für den Freak!! :-O @Klaus: ich bin zwar nicht Jörg, habs aber so implementiert: Im RAM hast Du nen "Bilschirmspeicher" der die Anzeige in ASC2 repräsentiert. Alle paar Millisekunden wird einer der Plätze des Bildschirmspeichers durch ne Interruptroutine an einen 7-Segmentdekoder gesendet. An diesem Dekoder sind alle Segmente der Anzeige parallelgeschaltet. Gleichzeitig legt die Routine an die Anode des betreffenden Stelle Spannung an, so das diese aufleuchtet. das geht immer im Kreis herum. So wird Stelle 1 des Speichers kurz auf Stelle 1 der Anzeige gezeigt, Stelle 2 dann auf Stelle 2 der Anzeige u.s.w. Wenns schnell genug geht, leuchten alle Stellen scheinbar gleichzeitig. mfg
Hallo. Achso ja jetzt kann ich mir das ungefähr vorstellen. Vielen Dank. ;)
Klaus F. schrieb: > Hallo. Achso ja jetzt kann ich mir das ungefähr vorstellen. Vielen Dank. > ;) :-P Na damals war ich 14 und das meine 1. Multiplexerfahrung. Bitte nicht lachen. :-P mfg
Klaus F. schrieb: > Habe oben die Beschaltung angehangen. Die scheint etwas anders zu sein > wie vermutet. In der Tat. Für den 74LS32 braucht es noch ein drittes Signal: Pin 10. Das sind ODER-Gatter, wenn Pin 9 (A5) und Pin 10 (vielleicht /IORQ?) low sind, dann wird die PIO aktiviert. Die nimmt also einen ziemlich großen Adressraum ein. :-/ Die CIO dagegen scheint memory-mapped angebunden zu sein, warum auch immer. Der erste Decoder des '139 reagiert ja auf /MREQ und teilt den Speicheradressraum in 4 Blöcke (0 ... 3FFF, 4000 ... 7FFF, 8000 ... BFFF, C000 ... FFFF). Der letzte Adressbereich wiederum wählt den zweiten Decoder da drin aus und nimmt noch A11 und A12 zuhilfe, sodass an seinen Ausgängen die Signale für die Blöcke C000 ... C7FF (Alias E000 ... E7FF), C800 ... CFFF (E800 ... E8FF), D000 ... D7FF (F000 ... F7FF) und D800 ... DFFF (F800 ... FFFF) entstehen. Der zweite dieser Blöcke (C800 ... CFFF) steuert die CIO an. Der dritte ist schätzungsweise der RAM-Block (der SP wird ja zu D7FF initialisiert). Ich glaube, das, was Bernd als RAMPORT bezeichnet hat (CFF3) bedient in Wirklichkeit die CIO.
So, ich habe mir nochmal den zweiten EPROM mit der Sprungtabelle angesehen. Die zielt immer auf den Bereich ab 4000H. Ich denke so: 1. EPROM 0000H - 3FFFH 2. EPROM 4000H - 7FFFH Man sollte da den ROM-Bereich als eine Einheit sehen. Von 0000H - 7FFFH. Hab das mal zusammengefügt und auch reassembliert. Mit dem Z80 Simulaor IDE. Weiterhin das Zilog Developer Studio 3.68 benutzt.
Moin Joerg, - das die CIO memory-mapped angebunden ist macht Sinn und dann mach auch viele andere Sachen Sinn: Bei der Init-routine wird eine Tabelle mit der Groesse 0x2c von 0xa3a nach 0xcff3 kopiert (ab 0x002c). Wenn Du Dir die Tabelle anguckst, siehst Du:
1 | 0a3a 2b 88 Port B Data Direction |
2 | 0a3c 28 00 Port B Mode Definition |
u.s.w. Spannend finde ich, dass der Z8536 kein MREQ fuer den IntAck brauchst, den IntAck musst Du dir selber basteln. Das Z80-uebliche IEI/IEO gibt es auch. Das Memory-Mapping macht es latuernich nicht einfacher. The only easy day was yesterday. Gruesse Th. P.S.: Der Z8536 hat drei Ports (Port C vier bit breit, B und A jeweils acht bit). Addressiert wird das Ding ueber A0/A1, wobei gildet:
1 | A1 A0 |
2 | 0 0 Port C (0CFF0H) |
3 | 0 1 Port B (0CFF1H) |
4 | 1 0 Port A (0CFF2H) |
5 | 1 1 Control-Port (0CFF3H) |
Mit CIO hatte ich noch nix am Hut. Von daher wird Eure Hypothese schon stimmen. Ich hatte nur an mehreren Stellen Zugriffe auf den Bereich CFF0h bis CFF3h gesehen.
Bernd schrieb: > Mit CIO hatte ich noch nix am Hut. Ich auch nicht, hatte nur den seltsam verdrahteten Adressdecoder analysiert.
@Klaus: die exakte Anbindung des I²C ist auch noch nicht ganz klar. Du hast da oben ein Stück gezeichnet, aber das ist nur eine Datenrichtung. Damit könnte man dann die Routinen für den I²C-Zugriff finden.
Hallo Jörg. Da schaue ich nochmal genau nach. Das doofe ist das da noch Transistoren, Widerstandsnetz, etc. davorhängen. Ich möchte mich aber jetzt schonmal bei allen Beteiligten für die sehr Kompetente Mitarbeit bedanken. Super Forum ist das hier. Beste Grüße und ein schönes Wochenende
Klaus F. schrieb: > Hallo Jörg. Da schaue ich nochmal genau nach. Das doofe ist das da noch > Transistoren, Widerstandsnetz, etc. davorhängen. Nicht ganz unnormal bei I²C. Dazu musst du wissen, dass der I²C-Bus von den aktiven Komponenten nur in Richtung Masse gezogen werden kann; auf Potenzial (5 V in diesem Falle) gehalten wird er durch zwei Pullup-Widerstände (Bereich wenige kΩ). Die treibenden Elemente sind daher Transistoren im "open collector"- oder "open drain"-Modus. Bei heutigen Controllern lässt sich sowas auch in Software machen (Umschalten des Ports zwischen Ausgang und Eingang), bei den Z80-Komponenten wäre das zu umständlich gewesen (mehrere Steuerwörter Richtung PIO senden). Daher hast du dort in Richtung Eingang den von dir schon dokumentierten MC14584 (Schmitt-Trigger), aber in Richtung Ausgang wird da noch ein Transistor sein, der die Leitung runter zieht. SCL scheinen sie direkt mit einem MC14584-Gatter zu treiben, wenn deine Schaltung stimmt. Das ist nicht völlig I²C-konform, aber wenn man das Verhalten der angeschlossenen Bauteile gut genug kennt, kann das schon funktionieren. (Normalerweise ist auch SCL open-drain, damit die angeschlossenen Teile durch Herunterziehen von SCL anzeigen können, dass sie noch nicht bereit sind). Prinzipiell kann die CIO auch open-drain-Ausgänge schalten, aber dein Schaltplan hat den I²C ja in Richtung PIO gehen.
Hat schon einer von Euch herausgefunden, was die Error- Meldung eigendlich bedeutet? Vielleicht liegt der Fehler außerhalb der Platine, weil ingend nen Sensor nicht reagiert, hängt das Ganze? mfg
Hallo. Der weiß das leider auch nicht. Hat ein Kollege bei ihm schon nachgefragt. Mfg
Angehängte Dateien:
-
Skizze_1.jpg
120 KB
Hier noch die Zuordnung der LED-Segmente. Die Bitnummerierung entspricht dabei dem Datenblatt des MM5450, d.h. das niederwertigste Bit (erstes Bit nach dem Startbit) heißt Bit 1 (geht nicht auf eine der 7-Segment-Anzeigen). Damit sieht das Datentelegramm so aus:
1 | Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 … 34 |
2 | high ? 1A 1B 1C 1D 1E 1F 1G 1. 2A 2B 2C 2D 2E 2F 2G 2. 3A 3B 3C 3D 3E 3F 3G 3. … |
Das Startbit muss immer high sein, und es müssen immer 35 Taktimpulse gesendet werden, da die Übernahme intern erst mit dem 35. Impuls erfolgt. Jetzt wäre rauszufinden, welcher der vielen Zugriffe auf 0cff2h (Portregister A der CIO) dafür zuständig ist, den MM5450 zu befüllen, dann hätte man zumindest die Anzeigeroutine.
Die "Beschaltung" vor dem CMOS static RAM PCF8571 könnte einfach auch nur der Spannungsversorgung dienen. Die Pufferbatterie muss ja von der normalen Betriebsspannung entkoppelt sein, ist sie ein Akkumulator, erklären sich Widerstände und Dioden. Wichtig hierbei: Die jetzt "defekte" Stützbatterie darf den Betrieb des I2C-Rambausteins nicht unmöglich machen (Zellenschluss).
Geil! ich würd jetzt erst einmal die Batterie prüfen: Ist Spannung drauf? Ist sie tot? Oder ist nur ne Zelle tot? Dann würd ich ne neue, Geladene paralalellöten, die alte abschneiden und neu testen. mfg
Bei 1,2V ist es nur eine Zelle :-) Ja, erst eine neue anschließen und dann die alte abschneiden. Evtl. schlafen die Daten nur wegen zu geringer Spannung. Was sagt eigentlich das Handbuch aus, für einen Batteriewechsel? Deshalb fragte ich hier. michael_ schrieb: > Aber wo ist er denn? > Das längliche Teil über dem blauen Stecker?
Hallo. Kann leider momentan keine Anhänge hochladen. Wahrscheinlich ist in unserem Dorf hier mal wieder alles überlastet. Versuche es später nochmal. Mfg
Angehängte Dateien:
-
IMG_20210307_115017.jpg
230 KB -
IMG_20210307_114757.jpg
230 KB -
20181222_133850.jpg
230 KB
Hallo. Über die Batterie steht da leider gar nichts drin. Nur Platine tauschen bei diesem Fehler. Habe wie im Anhang eine super Alternative zur Originalbatterie. Wird einfach eine CR2032 reingeclipst. Könnte den Datensatz vor Wechsel extern sichern und wieder zurückschreiben. Im Moment habe ich unter der Platine einfach eine CR2032 mit Lötfähnchen parallel angelötet. Mfg
Moin, - Klaus F. schrieb: > zur Originalbatterie. Wird einfach eine CR2032 reingeclipst. Könnte den > Datensatz vor Wechsel extern sichern und wieder zurückschreiben. Im - also Du hast eine funktionsfaehige Macchina? Das ist mir nicht ganz klar. - Du hattest am Anfang aufgemalt, dass SDA/SCL an PA0/PA1 an der PIO angeschlossen ist (ueber einen Schmitt-Trigger). Stimmt das so? Denn bei I2C hast Du ja eine bidirektionale Kommunikation und die Umschaltung der Port-Direktion via Port 0x02 (command-Port Port A) sehe ich in der Quelle nicht. (Ich habe gesehen, Du bist noch dran). I hold. Gruesse Th.
Klaus F. schrieb: > Wird einfach eine CR2032 reingeclipst. Vorsicht: mach das nur, wenn du dir sicher bist, dass da kein Ladestrom in die CR2032 fließen kann. Sonst kann die explodieren.
Thomas W. schrieb: > also Du hast eine funktionsfaehige Macchina? Das ist mir nicht ganz klar Hallo Thomas. Nein die Maschine ist nicht funktionsfähig. Hab die ja in Einzelteile hier auf dem Tisch liegen. Bin da nur schon eine große Weile dran am rumexperimentieren. Mfg
Moin, - OK. Du hattest mal gesagt, dass Du eine Pruefsumme ueber das i2c-RAM von 00 - 0x5f bestimmt hattest und die Pruefsumme in 0x7f gespeichert war. Wie hast Du die Summe bestimmt? Ich hatte gestern abend ein wenig nach einer Summen-Rechnung in der Quelle (Eprom_2.txt) geguckt (da muss ja ein DJNZ, ld b, 0x5E, buffer, ein ADC, ADD, SUB, SBC in einer Schleife sein). So auf die Schnelle nichts gesehen. Gruesse Th.
Hallo Thomas. Ich hätte gehen das sich nach der Speicherung einer Einstellung immer auch der letzte Wert in dem Hexdump mit ändert. Also hätte ich rückwärts ab 7E mal die Werte einfach auf 01 geändert. Bei falscher Prüfsumme hagelt es dann sofort einen E63. Das war bis 5E nicht der fall. In einem Hex Editor mit Einstellung Checksum-8 kann man das gut nachvollziehen. Mfg
Angehängte Dateien:
-
Skizze.jpg
240 KB
@Thomas, @Jörg. Hallo. Hab die I2C Verdrahtung noch mal neu Skizziert. So muss es eigentlich richtig sein. Mfg
Würde bedeuten: PIO.A0 = SDA_in, PIO.A1 = SCK, PIO.A2 = SDA_out Der MC14584 invertiert alle Signale, vermutlich wird auch der OC/OD-Treiber hinter SDA_out nochmal invertieren.
Moin, - das passt: Das Steuerwort fuer Port A ist 0xF9:
1 | In In In In In out out in |
Also (nach Joerg): PIO.A0 = SDA_in, PIO.A1 = SCK, PIO.A2 = SDA_out Gruesse Th.
Klaus F. schrieb: > Ich hätte gehen das sich nach der Speicherung einer Einstellung immer > auch der letzte Wert in dem Hexdump mit ändert. Also hätte ich rückwärts > ab 7E mal die Werte einfach auf 01 geändert. Was hab ich denn hier für einen Schrott geschrieben. Die Autovervollständigung eines Smartphones ist ja manchmal auch unvorteilhaft. Was kann ich denn jetzt noch beitragen? Nach was muss der Quelltext denn jetzt durchsucht werden? Mfg
Klaus F. schrieb: > Nach was muss der Quelltext denn jetzt durchsucht werden? Zwei Angriffspunkte: mit der LED-Belegung kannst du rausfinden, welche Routine dafür zuständig ist, die 7-Segment-Anzeigen zu bedienen. Die gehen ja über CIO.A1 (data), clock müsstest du nochmal ausklingeln. Dann kannst du feststellen, wer da irgendwann dieser Routine die Fehlermeldung übergibt. Anderer Pfad: die I²C-Kommunikation mit dem PCF aufdröseln und schauen, wer wann auf den Speicher zugreift.
Moin, - Klaus F. schrieb: > Was hab ich denn hier für einen Schrott geschrieben. Die > Autovervollständigung eines Smartphones ist ja manchmal auch > unvorteilhaft. > Was kann ich denn jetzt noch beitragen? Nach was muss der Quelltext denn > jetzt durchsucht werden? > Mfg Ich hatte Dich schon verstanden ... Du hast ja den schoenen Logic-Analyzer. Da koenntest Du ein Trace von SCL/SDA von Start-Up der Maschine bis Fehlermeldung anfertigen und die Tracedatei posten (ja, auch ich habe den Logic-Analysator) Ich habe ein paar Routinen identifiziert (vielleicht):
1 | L0120: Send Stop oder Ack |
2 | L0121: Adressiere Slave in L? (Routine $0cdb-$0910) |
3 | L0013: Delay (Parameter in BC) |
4 | L0139: Read i2c-Input (1 bit) result in D |
Gruesse Th.
Thomas W. schrieb: > Da koenntest Du ein Trace von SCL/SDA von Start-Up der > Maschine bis Fehlermeldung anfertigen und die Tracedatei posten Hallo Thomas. Anbei die Tracedatei. Einstellung 8 bit ist doch richtig oder? Mfg
Ne, missverstand: Du hast ja die Salea Logic Software. Die SW hat einen freundlichen Knopf "Start" und zeigt Dir (wenn richtig angeklemmt) die I2c-Kommunikation. Wie Du das in https://www.mikrocontroller.net/attachment/495727/logic_analyzer_pcf.PNG gezeigt hast. Wenn die Messung fertig ist, kannst Du mit Option -> Save Capture die Daten speichern. Dieses .logicdata-Datei bitte posten. Die kann ich dann wieder einlesen. Der Zeitraum fuer die Messung: Wie lange braucht denn die Macchina von Power-Up bis zur Fehlermeldung? Denn den Zeitraum haette ich gern, weil in dem Zeitraum muss der Speicherblock gelesen werden (128Byte * 8 bit muss man sehen koennen). Gruesse Th.
Thomas W. schrieb: > Da koenntest Du ein Trace von SCL/SDA von Start-Up der > Maschine bis Fehlermeldung anfertigen und die Tracedatei posten Ok. Hier die .logicdata Datei. Mfg
Moin, - danke. Ich finde es ist sehr dunkel auf dem Bus, denn es liesst ein ganzes Byte von 0x00 (es ist ein " ", 0x20) und dann ist dunkeltuten. Ich werde erstmal versuchen, die I2C-Routinen etwas mehr zu verstehen. Gruesse Th.
Hallo. Kann den Fehler auch noch wegquittieren und alles hinterkommende aufzeichnen. Aber macht wahrscheinlich keinen Sinn weil man ja wissen möchte was bis dahin passiert. Mfg
Doch, weil ich ja raetseln muss, wo und wie die Daten hin- und hergeschoben werden. Je mehr, desto besser. Und wenn die Fehlermeldung nach dem freundlichen 0x20 an Adressse 0x00 kommt, muss man mal gucken was das Ding will. Gruesse Th.
hallo Thomas. Hier mal mit einer Quittierung über die Stop Taste. Mit der Stop Taste können Fehlermeldungen übersprungen werden. Ausgenommen sind Schäden am Programmspeicher und Datenspeicher. Da ist dann bei der Fehlermeldung Endstation (E50 und E51). Mfg
Und was war die erste Datei? Die hatte eine schoene Datentransfer zum RAM. Th.
Was für ein Qaos. Die erste war schon richtig. Muss hier erstmal was löschen. Mfg
Moin, - die beiden I2C-Traces waren sehr hilfreich. Ich war nicht sehr hilfreich, weil ich schon seit lange Zeit nicht mehr I2C-Kommunikation per Fuss programmiert habe. - Beim Start der Macchina wird am Anfang der Kommunikation das Speicher-Wort in 0x07B abgefragt (2 x acht bit). - Wenn Du den Fehler quittierst, dann wird (im Wesentlichen) der Inhalt des I2C-Ram kopiert und es wird eine Checksum in 0x7f geschrieben (das ist das, was Du auch gesehen hattest). Naechste Aufgabe: Was la Macchina haben will. Ein Frage zum Verstaendnis: Offensichtlich sind die Parameter im I2C-RAM ungueltig. Funktioniert das Ding trotzdem? Gruesse Th. P.S.: Die Maschine startet und sendet und empfaengt:
1 | <Address 0xA0> <0x7B> <Slave Address 0xA0> <0x00> <0x20 + NACK> |
Ich interpretiere das so: Lese zwei Bytes ab 0x7B.
Hallo. Habe jetzt auch mal den Memoryguard (und die unglückliche Nebenspannungsversorgung) durch die oben genannte Alternative mit neuer CR2032 ersetzt,und danach den alten Datenstand wieder eingeschrieben. Ergebnis bleibt gleich. Mfg
Thomas W. schrieb: > Ein Frage zum Verstaendnis: Offensichtlich sind die Parameter im I2C-RAM > ungueltig. Funktioniert das Ding trotzdem? Moin Thomas. Ja wenn man den Fehler Quittiert kann man "bedingt" damit arbeiten. Es fehlt dann aber die komplette Feinwuchtfunktion (Laufruhenoptimierung) wo ja angeblich Eeprom2 für zuständig ist. Mfg
Klaus, - jetzt gibt es verschaerftes Guesswork: In Eeprom_1 (das auf 0x4000 sitzt) ist ja die Fein-Wucht-SW (die Fein-Wumme). Zur Erinnerung: 3 Bytes Magic, acht Vektoren. Ich habe jetzt nach 0x0a0 (address RAM) und 0x7b (Speicherstelle) gesucht und finde bei 0x40a9 die Kommandos zum RAM. Die Software vergleicht dann mit (0x4000) und (0x4001), d.h. 0x12 und x034. Und gibt halt ein Ret Z oder ein RET mit sehr vielen Parameter gesetzt. Mein verschaerftes Guesswork ist jetzt: Schreibe im I2C-Ram in 0x7B eine 0x12, in 0x7C eine 0x34 und starten. Jetzt wird latuernich die Fein-Wumme mit sehr lustigen Parameter starten. Ich hoffe, es kommt niemand zu schaden. Die Parameter fuer die Fein-Wumme bekomme ich natuerlich nicht raus. Gruesse Th.
Hallo Thomas. Ich werd bekloppt. Das funktioniert tatsächlich. Auch der Servicecode C45C wo 4 Parameter für die Laufruhenoptimierung eingegeben und gespeichert werden müssen funktioniert wieder. Na das wird wohl viele dieser Maschinen vor dem Schrotthändler bewahren. Ich bin echt sprachlos. Das ihr in dem Source überhaupt etwas erkennen könnt finde ich echt beeindruckend. Da kann man wirklich nur den Hut vor Ziehen. Vielen herzlichen dank für den harten Einsatz. Natürlich auch an alle anderen die hier Mitgewirkt haben.
Hallo. Für alle die das Problem nach Batteriewechsel beseitigen möchten: 1. Den oben angehangenen Hexdump in den Datenspeicher einschreiben (hier fehlen nur noch die Kalibrierdaten, Grundeinstellungen hab ich schon vorgenommen) 2. Die Maschine mit den Servicecodes C80C-C84C neu Kalibrieren Bei fragen zur Kalibrierung einfach hier melden. Vielen Dank nochmal. Ist wirklich ein Top Forum. Mfg
Klaus, - vielleicht koenntest Du einen neuen Thread mit dem Ergebnis "Fahrzeugelektronik" erstellen. Der geneigte Leser braucht bestimmt Name und Type der Macchina weil Google natuerlich nur den Titel indiziert und der freundliche Schrauber sucht bestimmt nicht nach Z80-Opcodes. Gruesse Th.
Thomas W. schrieb: > der freundliche Schrauber sucht bestimmt nicht nach Z80-Opcodes. :-)) @Klaus: kannst ja per Link auf den Beitrag in diesem Thread verweisen. Jede Beitragsüberschrift ist ein Link.
Hallo. Hab gestern in der Aufregung ganz vergessen die 0xFF Einträge durch 0x00 zu ersetzen. Dann steht u.a. auch der Zähler für Anzahl der Messläufe (C12C) auf dem max. Wert von 65535. Also bitte diesen Hexdump benutzen. Mfg
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.