Hallo zusammen, ich benötige etwas Hilfe von Experten, die sich mit Z80-Schaltungen und Z80-Eprom-Programmierung auskennen: Ich bin gerade dabei mich in eine alte Fleischmann FMZ-Zentrale 6800 mit Z8400 CPU einzuarbeiten. Einerseits ist das total sinnfrei, andererseits kann ich dabei sehr viel Neues lernen und mich in Themen einarbeiten, die ich bisher noch nicht gelernt habe mit elekronischen Schaltungen. Ich finde den Aufbau der Zentrale und diese alte CPU total klasse. Was möchte ich machen? Ich möchte den ROM auslesen und ersetzen. Ich möchte den alten Programmcode gerne versuchen zu verstehen, ich kenne ja die Nutzerinteraktionen und das Verhalten. Assembler-Grundlagen habe ich vor langer Zeit einmal gelernt. Und ich habe auch darüber nachgedacht irgendwann ein eigenes Programm zu schreiben, welches ich mit dem Z84 und seinen umgebenen Bausteinen ausführen und nutzen kann. Zunächst einen Überblick, was in der alten FMZ-Zenrale überhaupt drin steckt: - CPU: Z8400AB1 - Peripherie: Z8440AB1, Z8430AB1, Z8420AB1 - ROM: D2764C-3 - RAM: D4364C-I5L - eine serielle Schnittstelle - diverse weitere Bausteine für I/O Softwarefrage: Nun habe ich mich grundlegend gefragt, ob ich vielleicht auch in der Programiersprache C etwas programmieren, kompilieren, auf den ROM der Z84 flashen und ausführen kann. Welche Entwicklungsumgebung könnt ihr mir dafür empfehlen? Für mich ist das schon eine ganze Weile her und ich kenne bisher so etwas wie Visual Studio und Ecplipse. Mit der Arduino-IDE habe ich erste Erfahrungen gesammelt. Und ich habe Linux-Kenntnisse. Vermutlich macht auch eine Z80-Emulation zum ausprobieren von Code Sinn? Hardwarefragen: Bei der Zentrale gibt es diverse Tasten und vier 7-Segment Anzeigen sowie LEDs. Es sind Eingaben möglich, die über die Bedienelemente verarbeitet werden. Damit kann beispielsweise eine Lokadresse einem Handregler zugeordnet werden. Ich habe mich nun gefragt, wo wäre der Ort, wo die Zentrale Eingaben und Zuordnungen speichert? Interessant ist dabei, dass die Zentrale 3 AA-Batterien benötigt, um diese Speicherung aufrecht zu erhalten nach dem Ausschalten. Es werden nur wenige Kilobyte Speicher benötigt. Bleibt das dann im RAM erhalten oder sollte ich mir alle anderen ICs noch einmal genauer ansehen, ob da einer ist der etwas Speicher bietet? Eine weitere Fragestellung ist noch Folgende bzgl. des ROMs: Ich habe nun mit einem T48-Programmer den D2764C-3 ausgelesen und möchte diesen zur Überprüfung gerne erst einmal auf einen anderen ROM flashen und schauen, ob dann noch alles so geht wie zuvor. Dafür habe ich recherchiert, dass der AT28C64 sich gut eignen könnte, weil er die gleiche Pinbelegung hat. Also habe ich das Binärfile auf einen AT28C64 geflasht und diesen ausprobiert. Leider geht so gar nichts. Liege ich mit meiner Annahme falsch, dass wenn die Pinbelegung und Größe des Eproms gleich ist, dass es dann gehen sollte den ROM zu klonen? Wie kann ich meine(n) Fehler eingrenzen? Vermutlich habe ich irgendetwas nicht bedacht. Auf jeden Fall erkenne ich nach nochmaligen Auslesen des AT28C64, dass dort die augenscheinlich zuvor ausgelesenen Bytes drauf geschrieben worden. Über jeden Ratschlag und Tipp für meine Lernumgebung würde ich mich sehr freuen. Viele Grüße, Jens
Angehängte Dateien:
-
20230901_144646.jpg
57 KB -
20230825_074428.jpg
83 KB
Jens schrieb: > Liege ich mit meiner Annahme falsch, dass wenn die Pinbelegung und Größe > des Eproms gleich ist Die Pinbelegung ist nicht gleich! Der 28C64 hat auf Pin 27 die !WE Leitung. Diese muss auf VCC liegen damit das funktioniert.
> Nun habe ich mich grundlegend gefragt, ob ich vielleicht auch in der > Programiersprache C etwas programmieren, kompilieren, auf den ROM der > Z84 flashen und ausführen kann. Keine Ahnung wie kompatibel die Kiste ist zu einem echten Z80, aber das sollte dann gehen: https://de.wikipedia.org/wiki/Small_Device_C_Compiler > Mit der Arduino-IDE habe ich erste Erfahrungen gesammelt. Naja. Was du tun musst ist herauszufinden wo denn deine Hardware genau Rom und Ram liegen hat, danach dann Linkerscript anpassen, das was man angeblich nicht wissen muss, und dann den Compiler anwerfen. > Und ich habe Linux-Kenntnisse. Immer sehr lobenswert. > Vermutlich macht auch eine Z80-Emulation zum > ausprobieren von Code Sinn? Eher weniger weil du ja in einer Hochsprache programmieren willst. Ausserdem hast du bei Embedded schnell das Problem das dir dann die Hardware des Zielsystems fehlt. > Bleibt das dann im RAM erhalten oder sollte ich mir alle anderen ICs > noch einmal genauer ansehen, ob da einer ist der etwas Speicher bietet? Woher sollen wir das wissen? Du musst deine Hardware solange betrachten bis du selber den Schaltplan nachmalen kannst.... Vanye
Damit die Verwirrung etwas kleiner wird: Z8400 ist die SGS Bezeichnung für einen normalen Z80. Auch die anderen Z84* Bausteine sind aus der normalen Z80 Produktlinie. 8440 = SIO-0 8430 = CTC 8420 = PIO Alle aus der 4MHz Reihe. Als erstes solltest du das Schaltbild der Anlage aufnehmen. Das ist gut investierte Zeit. Natürlich kann man auch aus dem disassemblierten Code auf IO-Adressen schliessen. Nach meiner Erfahrung ist das aber deutlich schwerer. Für die Programmentwicklung ist ein Eprom-Emulator sinnvoll. Den kannst du an einem Abend mit etwas Lochraster selbst bauen.
:
Bearbeitet durch User
Jens schrieb: > Ich möchte den alten > Programmcode gerne versuchen zu verstehen Dann brauchst Du erstmal den exakten Schaltplan des Gerätes und die vollständige Protokollbeschreibung des FMZ. Ansonsten ist das nur ein Stück Elektroschrott. Jens schrieb: > - CPU: Z8400AB1 > - Peripherie: Z8440AB1, Z8430AB1, Z8420AB1 > - ROM: D2764C-3 > - RAM: D4364C-I5L > - eine serielle Schnittstelle > - diverse weitere Bausteine für I/O Dieses ganze Geraffel könnte man durch einen ATmega2560 ersetzen. Debugger und C-Compiler wären dann kein Problem. Jens schrieb: > Und ich habe > Linux-Kenntnisse. Die nützen dafür nicht.
Thomas Z. schrieb: > Die Pinbelegung ist nicht gleich! Der 28C64 hat auf Pin 27 die !WE > Leitung. > Diese muss auf VCC liegen damit das funktioniert. Naja, die 2764er haben dort /PGM, das muss im Normalbetrieb auch auf VCC liegen. Wenn der Inhalt des 2864 also wirklich identisch zum EPROM ist, müsste das schon funktionieren. Das -3 beim EPROM heißt vmtl. 300ns Access-Time, und da liegt der AT28C64 deutlich drunter, sollte also ok sein. Es sei denn ... man wollte es Raubkopierern ein wenig erschweren. Dazu VCC am EPROM überprüfen, außerdem, was an A9 dran hängt. Nur Prozessor und RAM sowie Adressdekoder? Oder ist da irgendwas dran, mit dem man A9 auch auf 12V ziehen kann?
Du kannst ja den EPROM Dump hier reinstellen damit man sieht womit man es zu tun hat.
Habe gerade mal ChatGPT befragt, der ist gerne bereit, Dir bei der Rückumwandlung von Hexcode in Z80 Assembler zu helfen. Vielleicht in Etappen, denke nicht, dass man da 8kB einfach hochladen kann. Und die Peripheriebausteine wird er auch sicherlich kennen. Allerdings muss ich auch sagen, dass ich das Projekt zum "Lernen" etwas suboptimal finde. Aber wenn Du gerne möchtest ist das natürlich auch okay.
:
Bearbeitet durch User
Hallo zusammen, vielen Dank zunächst an euch alle für die vielen Tipps und Hinweise. Ich bin nun erst mal eine Weile beschäftigt und melde mich bald wieder. Ich verfolge auch weiter die neuen Beiträge, schreibe dann aber erst wieder, wenn ich was zu melden habe. Den SDCC setze ich mir unter Ubuntu auf und ich habe mir auch noch ein Z80-MBC3 bestellt, um erst einmal mit den einfachsten Dingen bei der Programmierung des Z80 zu starten. Der Hinweis zu dem 28C64 und dem Pin 27 WE war gut und das verfolge ich später mal weiter. Das ganze Layout nachzuzeichnen ist eine umfangreiche Aufgabe. Puhh, es sind zwar nur 2 Layer. Aber das wird bei mir etwas dauern. Die Idee von einem Dissassembly mit ChatGPT vom Binary in C finde ich ja richtig spannend. Ich kann mir vorstellen, dass dieses ROM in den 80ern eher direkt in Assembler implementiert wurde. Aber hat das von euch schon mal jemand erfolgreich mit ChatGPT für alte Bins umgesetzt? Sehr coole Idee auf jeden Fall. Ist die Weitergabe von solchen ausgelesenen Binaries erlaubt? Ich bin da etwas unsicher. Viele Grüße, Jens
:
Bearbeitet durch User
Jens schrieb: > Das ganze Layout nachzuzeichnen ist eine umfangreiche Aufgabe. Puhh, es > sind zwar nur 2 Layer. Aber das wird bei mir etwas dauern. Es geht ja nur darum Georg G. schrieb: > auf IO-Adressen schliessen Also wo und wie die ganzen -CS angeschlossen sind. Gruss Chregu
> Also wo und wie die ganzen -CS angeschlossen sind.
Bete das es nicht an einem IC endet wo PAL oder GAL drauf
steht. Hat man frueher ja gerne mal gemacht.
Vanye
Dann muss man eben im Code nach den Adressen suchen. Da der Z80 einen eigenen I/O Adressbereich und entsprechende Befehle hat, ist längst nicht so aufwändig wie bei Memory mapped I/O.
Vanye R. schrieb: > wo PAL oder GAL drauf > steht Auf den ersten Blick nicht, aber der TO könnte ja ein höherauflösendes Bild machen! Gruss Chregu
Ein bischen Literatur (User-Manual CPU): https://www.zilog.com/docs/z80/um0080.pdf Die IO: http://www.z80.info/zip/um0081.pdf Der "Programming the CPU z80" von Zaks ist mittlerweile frei verfuegbar: http://www.z80.info/zip/zaks_book.pdf 2021 wurde ein aehnliches Problem geloest: Beitrag "Hilfe bei Z80 Opcodes" Dort wurde insbesondere auf den dZ80 hingewiesen (ein Disassembler). Wenn Du mehr ueber die Z80 wissen willst/musst: www.z80.info (vielen Dank an Gaby) Gruesse VaxWoman
Jens schrieb: > Die Idee von einem Dissassembly mit ChatGPT vom Binary in C finde ich ja > richtig spannend. Ich kann mir vorstellen, dass dieses ROM in den 80ern > eher direkt in Assembler implementiert wurde. Zuück in C habe ich nicht behauptet. Assembler geht, schon probiert. Und ja, bei 8kB Speicher wurde es sicherlich in Assembler programmiert. Das merkt man beim Disassemblieren auch ziemlich schnell.
Harald A. schrieb: > Rückumwandlung von Hexcode in Z80 Assembler Das kann ich dir gern machen, kein Problem. C-Compiler (Q-C), Assembler, Linker für Windows (bis XP getestet) oder DOS (Freedos im Fenster) kannst du mit Handbüchern (pdf) auch bekommen. Die IO-Adressen der PIO - SIO - CTC sind schnell gefunden. Um die Abfrage der Tasten und Controller sowie die Ausgabe zu verstehen, ist es imho schon notwendig, die Schaltung aufzunehmen. Mich wundert, dass im Netz dazu nichts zu finden ist.
Ich würde gerne mal ehrlich wissen, warum mein Beitrag bzgl. ChatGPT mittlerweile -4 erzielt hat. Was ist daran falsch? ChatGPT kann tatsächlich mittlerweile eine große Hilfe sein, nach dem reinen Disassembler geht es ja weiter in der Interpretation - wenn man möchte.
:
Bearbeitet durch User
Harald A. schrieb: > Ich würde gerne mal ehrlich wissen, warum mein Beitrag bzgl. ChatGPT > mittlerweile -4 erzielt hat. Was ist daran falsch? Der TO möchte am Beispiel des Z80 Programmieren lernen. Das ist quasi die Antithese zu einer "KI" wie ChatGPT. Zumal gerade ChatGPT nichts anderes als ein Google-Papagei ist.
Harald A. schrieb: > nach dem reinen > Disassembler geht es ja weiter in der Interpretation Dazu sagt ChatGPT:
1 | Die genaue Funktion der Unterfunktion hängt von der spezifischen Anwendung oder dem Programm ab, das den Z80-Code verwendet. Ohne weitere Informationen ist es schwierig, den genauen Zweck oder die Bedeutung des Codes zu bestimmen. |
Genau deswegen ist ChatGPT keine Hilfe. Den Maschinencode in Assembler wandelt jeder Disassembler besser. Die eigentliche Arbeit ist das genaue Verstehen, was der Code macht.
Harald A. schrieb: > Ich würde gerne mal ehrlich wissen, warum mein Beitrag bzgl. ChatGPT > mittlerweile -4 erzielt hat. Weil Niemand mehr dieses ständige Geschwafel über KI ertragen kann. Falls vorhanden, könnte Deine natürliche I helfen, das zu erkennen.
Harald A. schrieb: > Ich würde gerne mal ehrlich wissen, warum mein Beitrag bzgl. ChatGPT > mittlerweile -4 erzielt hat. Was ist daran falsch? Gib doch diese Frage einfach mal bei ChatGPT selbst ein. ;-)
Hallo zusammen, ich bin noch fleißig dabei die Leiterbahnen zu verfolgen. Für CPU, ROM und RAM habe ich alle Adress- und Datenleitungen verfolgt und handschriftlich notiert. In welchen (möglichst freien) Programm sollte ich das visualisieren, damit ihr mir gut folgen könnt? Habt ihr einen Tipp? Andreas B. schrieb: > Naja, die 2764er haben dort /PGM, das muss im Normalbetrieb auch auf VCC > liegen. Wenn der Inhalt des 2864 also wirklich identisch zum EPROM ist, > müsste das schon funktionieren. Ich habe gemessen: Auf WE liegt Vcc mit 4,76V an. Am Pin A9 habe ich 0V gemessen. Es sieht auch so aus, dass dieser Pin unbelegt ist. Ist das ungewöhnlich oder sollte da was sein und ich habe es nicht erkennen können? Hat noch jemand eine Idee, warum es dennoch nicht gehen könnte? Zum Schaltplan: Ich kann erkennen, dass vom Eprom A0 bis A7 auf A5 bis A7 vom Z8400 gehen. A0 bis A2 gehen außerdem weiter auf den RAM. Weiterhin sind A11 vom Eprom auch mit A11 vom Z8400 und auch mit A11 vom RAM verbunden. O0 und O1 vom Eprom sind mit O1 und O2 vom RAM verbunden und gehen auf der Rückseite bis in die Nähe von D4, D3 und D5 vom Z8400. Hier verdeckt der Sockel die Sicht. Weiterhin gehen 03 bis O7 vom ROM auf 04 bis O8 vom RAM. Spannend finde ich, dass am Ende A0 bis A2 auch auf einen AD-Wandler ADC0809 gehen. Es gibt 8 Handregler, bei denen über ein Poti 0 bis 12k Ohm und ein Schalter anliegen. Je Handregler gehen Leitungen an IN1 bis IN8. Es gibt auch noch ein MUX 74LS251 und einen DEMUX 74HCT139 in diesem Kontext sowie ein NAND 74LS00. Komisch dabei: von den 8 Datenleitungen ist 2-4 mit O5 des ROM bzw. O4 des RAM verbunden. Weiterhin scheinen 2-8 und 2-2 verwendet worden zu sein (ergibt etwas wie 01010001). Warum da nicht drei hintereinander verdrahtet sind, keine Ahnung. Der CE vom ADC0809 hängt über den DEMUX direkt an A15 vom Z8400. Mal schauen, wie das funktioniert. Eine fehlerhafte Ablesung ist natürlich möglich. Einige Leitungen führen zu Punkten die enden (möglicherweise Messpunkte) oder an Punkte, an denen auf die Oberseite gewechselt wird. Nach einer Stunde verschwimmt einem auch alles und man erkennt gar nichts mehr. Soweit der aktuelle Zwischenstand. Viele Grüße, Jens
:
Bearbeitet durch User
Jens schrieb: > Spannend finde ich, dass am Ende A0 bis A2 auch auf einen AD-Wandler > ADC0809 gehen. Ganz normal! Interessant wäre, ob irgendwo ein '138 oder '139 verbaut ist, der jeweils von MREQ und/oder IORQ des Z80 angesteuert ist, und wo welcher Y hingeht. Dann noch welche Adressen an A, B und C liegen. Dann hast Du schon fast alles :-)) Gruss Chregu
Jens schrieb: > Ich habe gemessen: Auf WE liegt Vcc mit 4,76V an. Am Pin A9 habe ich 0V > gemessen. Es sieht auch so aus, dass dieser Pin unbelegt ist. Ist das Statische Messungen helfen da nicht. Eigentlich sollte Pin 27 (WE/PGM) direkt an VCC (ggf. über einen Widerstand) angeschlossen sein. Und A9 müsste direkt mit dem entsprechenden Adresspin von CPU und RAM verbunden sein. Unbelegt kann nicht sein, sonst würde das EPROM ja nur zur Hälfte genutzt, außerdem sind offene Eingänge pfui. Dann würde man im EPROM-Dump auch sehen, dass da alle (vmtl. 512-Byte-) Blöcke doppelt vorkommen. Mir kam nur eine ungewöhnliche "Kopierschutzmaßnahme" in den Sinn: Eine kleines Stück Code wird vom EPROM ins RAM kopiert, dieser schaltet A9 auf 12V, liest die ID des EPROMs aus und sagt "njet", wenns kein Original ist. Ist zwar sehr unwahrscheinlich, dass das tatsächlich so eingebaut ist, aber andererseits - der Prozessor hat kein internes ROM, der gesamte Code frei zugänglich im EPROM, recht einfache Platine, kein kundenspez. Display oder so - das lädt doch zum Nachbau ein. Irgendeine - wenn auch banale - Schutzmaßnahme würde ich da schon erwarten.
Jens schrieb: > DEMUX 74HCT139 Das ist der Adressdekoder. Du wirst an den Select Eingängen (A,B) vermutlich ein paar höhere Adressleitungen der CPU finden sowie auch an den Enable und /Enable Eingängen der beiden Dekoder. Er wird so verschaltet sein, das er insgesamt 8 Speicherblöcke auswählt. Das Speichermapping ist wichtig. Also sorgfältig den 74139 und seine Anschlüsse durchmessen. Den ADC hast du ja schon gefunden. Bei einem der Dekoder wird der /Enable Eingang auf eine Adressleitung führen, die beim anderen Dekoder auf den Enable Eingang geht (einmal low aktiv einmal high aktiv) mit dieser Adreeleitung wird zwischen den beiden umgeschaltet. Das war sozusagen der Klassiker beim 139. Andere Designer haben da gerne den 74138 benutzt. Unbekannte Z80 Boards (wie z.B. damals den Mupid) habe ich genackt, indem ich nur die Adresse einer SIO rausklingelte und dann in den EPROM einen Monitor gebrannt habe. Mit dem konnte ich dann recht bequem über die Serielle das Board dechiffrieren.
:
Bearbeitet durch User
Andreas B. schrieb: > Mir kam nur eine ungewöhnliche "Kopierschutzmaßnahme" in den Sinn Vergiss es, da ist kein Schutz verbaut. Deine Variante ist mir in der freien Natur noch nie untergekommen, viel zu komplex, zu einfach zu sehen und simpel zu umgehen.
Matthias S. schrieb: > Das war sozusagen der Klassiker beim 139 Nicht eher: ein Dekoder IO, der Andere Mem... Gruss Chregu
Jens schrieb: > Hallo zusammen, > > ich bin noch fleißig dabei die Leiterbahnen zu verfolgen. Für CPU, ROM > und RAM habe ich alle Adress- und Datenleitungen verfolgt und > handschriftlich notiert. > > In welchen (möglichst freien) Programm sollte ich das visualisieren, > damit ihr mir gut folgen könnt? Habt ihr einen Tipp? Papier und Bleistift 1.0 reicht. Du musst die Verbindungen so oder so per Hand erfassen (fuer Dich auf malen), ein handy-Photo oder einen Scan reicht voll aus. > Spannend finde ich, dass am Ende A0 bis A2 auch auf einen AD-Wandler > ADC0809 gehen. Es gibt 8 Handregler, bei denen über ein Poti 0 bis 12k Wenn Du das Manual fuer den ADC0809 angeguckt haettest, haettest Du gesehen, dass das ein acht-Kanal-Multiplexer ist. Acht Eingaenge -> 3 Bits. Weiter waere auch wichtig, wie RD und WR geschaltet werden. > Der CE vom ADC0809 hängt über den DEMUX direkt an A15 vom Z8400. Mal > schauen, wie das funktioniert. Das koennte bedeuten, dass der ADC0809 Memory-Mapped ist (Es ist auch wichtig, welches Signal an welches Pin des ADC geht: Der ADC0809 hat keinen CE, du musst das Ding mit einem Write auf "Start" und "ALE" starten). Siehe Handbuch. 1) Suche den PIO (8420): Suche Pin4 (CE), die muss zu einem Demux (*) gehen. A/B und C/D sind vermutlich mit A0 (CPU) verbunden. M1 und IOREQ sind auch wichtig fuer die Z80-IO. Aufzeichnen. Pin 35 RD: Suche ob das Signal direkt zur CPU geht. 2) Suche die SIO (8440): Suche pin 35 (CE), die muss auch zu einem Demux (*) gehen. B/A und C/D sind vermutlich A0 und A1. Pruefe, ob M1 und IOREQ bestaetigt sind. Bestimme RD (Pin 32). 3) Suche den CTC (8430): Suche Pin 16. Bestaetige CS0/CS1 (Pin 18/19) als A0/A1. Pin 6 ist RD (bestaetige). 4) Bestimme am ROM Pin 20/22: CE und OE. 5) RAM: RAM Pin 20/22 sind ebenfalls wichtig. 6) Das ROM muss zwangsweise am 0x0000-0x1fff sein. Gehe mal davon aus, dass 1986 (das Geburtsjahr der Zentrale) wurden die Bytes noch per Hand eingekloeppelt (es gab sehr wenige Compiler). Richtig spannend wird dann die Tastatur und Display :-) Du musst um weiter zu machen die Datenblaetter dieser (mittlerweilen) antiken Bausteine lesen. Sobald Du die Grundzuege der Schaltung erfasst hast, solltest Du die Interrupt-Verarbeitung der Schaltung versuchen zu verstehen. Die Z80 war seiner Zeit sehr voraus und hatte drei Interrupt-Modi (komplett inkompatibel). Wenn man z80-Bausteine benutzt hatte, konnte man schon (1980!) Interrupt-Vektoren pro Interrupt-Kanal benutzen. Ist heute Standard, aber damals war das ganz neu. Viel Glueck Vaxwoman
Angehängte Dateien:
-
20230909_182037a.jpg
10 KB
Chregu: Also IORQ gehen nur auf Z8440 SIO und Z8430 CTC Counter Timer. MREQ erscheint mir nicht verbunden zu sein. Andreas B: Nachdem ich den D2764 vom Sockel genommen habe, sehe ich dass A9 in Richtung RAM weiter geht. Da wäre mir ein sinnvolles "Raten" / Erfahrungswissen und eine Annahme am liebsten. Sonst muss ich den großen Kühlkörper runternehmen und dafür muss ich vorher einige Bauteile auslöten. Das ist aufwendig. Kann ich das vermeiden? Ich bin gerade auch noch am 74HCT139 und SN74LS252. Könnt ihr mir bitte vielleicht sagen, was das für ein Bauteil ist? Rot, breit und flach, 9 Pins, Bezeichnung L91S472, gibt es auch an vielen Stellen vor den ICs, auch als mit der Bezeichnung M09-1-R, L91 22R, M09-1-R. Das habe ich noch nie vorher gesehen.
Georg G. schrieb: > Andreas B. schrieb: >> Mir kam nur eine ungewöhnliche "Kopierschutzmaßnahme" in den Sinn > > Vergiss es, da ist kein Schutz verbaut. Deine Variante ist mir in der > freien Natur noch nie untergekommen, viel zu komplex, zu einfach zu > sehen und simpel zu umgehen. Glaub ich auch nicht. Das war alles per Hand gekloeppelt, China war weit weg, der Markt der Modelleisenbahn war auch nicht so gross. Vor allen Dingen war schon DCC am Horizont. Vaxwoman
Jens schrieb: > Könnt ihr mir bitte vielleicht sagen, was das für ein Bauteil ist? Rot, > breit und flach, 9 Pins, Bezeichnung L91S472, gibt es auch an vielen > Stellen vor den ICs, auch als mit der Bezeichnung M09-1-R, L91 22R, > M09-1-R. > > Das habe ich noch nie vorher gesehen. Widerstand-Netzwerk. Pull-Up oder Pull-Down-Widerstaende. Vaxwoman
Christian M. schrieb: > Nicht eher: ein Dekoder IO, der Andere Mem... Das kann sicher auch sein. Sollte aber schnell klarwerden.
Jens schrieb: > Könnt ihr mir bitte vielleicht sagen, was das für ein Bauteil ist? Widerstands-Netzwerk für Pullup Widerstände. 1 x rein, 8 x raus
Danke für eure Hilfe. Es freut mich, dass ihr mich dabei unterstützt. Es gibt viel zu lesen. Die Datenblätter habe ich mir alle heruntergeladen. Ich bin dann wieder erst mal beschäftigt und melde mich wieder...
Vielleicht solltest Du 10EUR in einen USB-Logic-Analyser investieren (Zum Vergleich: 2 Weizenbiere in der Kneipe, oder eine halbe Mass am Oktoberfest): https://www.ebay.de/itm/255283244102 oder: https://www.ebay.de/itm/115356630618 Fuer die Z80 (mit max. 6Mhz) ist das mehr als ausreichend und kann sehr schoen mit 5V spielen. Software: https://www.saleae.com/de/downloads/ Am teuersten waren die Clips. Gruesse Vaxwoman
Der 74HC139 wird oft als 2 Decoder benutzt, z.B. einmal für die Speicher und einmal für die IO-Chips. Ich würde beim Nachverfolgen rückwärts gehen, d.h. ausgehend von den /CE-Signalen der Chips zurück zur CPU verfolgen.
Vax W. schrieb: > 10EUR [...] USB-Logic-Analyser Vax W. schrieb: > https://www.saleae.com Uiuiui, phöse... Gruss Chregu
Christian M. schrieb: > Vax W. schrieb: >> 10EUR [...] USB-Logic-Analyser > > Vax W. schrieb: >> https://www.saleae.com > > Uiuiui, phöse... > > Gruss Chregu Dann nimm Sigrok. Noch was substanzielles? Vaxwoman
Jens schrieb: > Ich kann erkennen, dass vom Eprom A0 bis A7 auf A5 bis A7 vom Z8400 > gehen. A0 bis A2 gehen außerdem weiter auf den RAM. Weiterhin sind A11 > vom Eprom auch mit A11 vom Z8400 und auch mit A11 vom RAM verbunden. Das EPROM ist ein 2764, das hat 8 kiB Kapazität. Man kann davon ausgehen, daß alle Adressleitungen des EPROMs mit der CPU verbunden sind, also A0 bis A12. Als "Kopierschutz" haben manchmal boshafte Entwickler die Reihenfolge der Adressleitungen zwischen CPU und EPROM durcheinandergebracht. Das gleiche kann auch mit den Datenleitungen D0..D7 passieren. Das dient dazu, ausgelesene EPROMs vor Disassembliervorgängen zu "schützen". Klingel also mal alle Adress- und Datenleitungen an CPU und EPROM der Reihe nach durch, wenn eine 1:1-Beziehung (also A0 an A0, A1 an A1 etc.) besteht, ist alles OK, wenn nicht, musst Du Dir die "Verwürfelung" penibel dokumentieren. Das RAM ist ein 4364, das hat ebenfalls 8 kiB Kapazität; das bedeutet, daß auch sämtliche Adressleitungen des RAMs mit der CPU verbunden sind. Interessant sind also die Adressleitungen A13..A15 der CPU. Wenn der '139 als Adressdecoder verwendet wird, ist damit zu rechnen, daß diese Leitungen dort auftauchen, wenigstens an einer der beiden Hälften des '139. Die andere Hälfte des '139 wird dann vermutlich als Adressdecoder für die Peripheriebausteine verwendet werden; bei I/O-Zugriffen werden aber nur die Adressleitungen A0..A7 verwendet. Es ist daher recht wahrscheinlich, daß A6 und A7 an diesen Baustein geführt werden. Weitere Details wurden hier Beitrag "Re: Alte FMZ-Zentrale 6800 mit Z84" schon schön beschrieben.
> Als "Kopierschutz" haben manchmal boshafte Entwickler die Reihenfolge > der Adressleitungen zwischen CPU und EPROM durcheinandergebracht. Jaja, die boesen Entwickler mal wider. Warum sollte man etwas machen das jeder Schwachkopf in drei Minuten mit dem Durchgangspiepser rausfinden kann. Nee, sowas hat gemacht um mit einem einfacheren Layout durchzukommen. Platinen hat man ja frueher nicht fuer 5Euro in China bestellt und Multilayer war krass teuer. Vanye
Vanye R. schrieb: >> Als "Kopierschutz" haben manchmal boshafte Entwickler die Reihenfolge >> der Adressleitungen zwischen CPU und EPROM durcheinandergebracht. > Nee, sowas hat gemacht um mit einem einfacheren Layout durchzukommen. > Platinen hat man ja frueher nicht fuer 5Euro in China bestellt und Ist aber für das angebliche Nichtfunktionieren mit 2864 statt 2764 völlig egal. Wenn die Kopie tatsächlich korrekt ist, muss es auch mit dem 2864 gehen.
Harald K. schrieb: > Als "Kopierschutz" haben manchmal boshafte Entwickler die Reihenfolge > der Adressleitungen zwischen CPU und EPROM durcheinandergebracht. Das > gleiche kann auch mit den Datenleitungen D0..D7 passieren. Naja. "Kopierschutz" wohl eher. Das erinnert mich daran:
1 | #!/usr/bin/perl -w
|
2 | #
|
3 | # permute bits in a binary EPROM image
|
4 | #
|
5 | # $Id: bitpermute 242 2012-10-26 14:39:56Z schwenke $
|
6 | |
7 | my @bit = ( 1, 2, 4, 8, 16, 32, 64, 128 ); |
8 | |
9 | my $pattern= shift or die "usage: $0 pattern <infile >outfile |
10 | pattern must be a permutation of (0..7)\n"; |
11 | my @pattern= split '', $pattern; |
12 | |
13 | my $c; |
14 | while (defined($c= getc)) { |
15 | my $input = ord $c; |
16 | my $output = 0; |
17 | for (my $i= 0; $i < 8; ++$i) { |
18 | if ($input & $bit[$i]) { |
19 | $output |= $bit[$pattern[$i]]; |
20 | }
|
21 | }
|
22 | printf "%c", $output; |
23 | }
|
24 | exit 0; |
Anwendung:
1 | ~ $hd test.bin |
2 | 00000000 ce b5 ff 0e 01 12 63 29 |......c)| |
3 | |
4 | #unteres und oberes Nibble tauschen |
5 | ~ $cat test.bin | bitpermute 45670123 | hd |
6 | 00000000 ec 5b ff e0 10 21 36 92 |.[...!6.| |
7 | |
8 | #bits 3 und 7 tauschen |
9 | ~ $cat test.bin | bitpermute 01274563 | hd |
10 | 00000000 ce 3d ff 86 01 12 63 a1 |.=....c.| |
Das hab ich vor Jahren mal geschrieben, um eine Firmware mit diesem "Kopierschutz" zu disassemblieren :)
:
Bearbeitet durch User
Kurzer neuer Zwischenstand zum HCT139 (wie von euch erwartet, aber noch mit Lücken - meine Augen machen schlapp); 1A <-> 8400, A14 1B <-> 8400, A15 2A <-> RAM, A3 2B <-> RAM, A4 1Y0 <-> RAM, CE1 1Y1 <-> RAM, CE2 1Y2 <-> nc 1Y3 <-> nc 2Y0 <-> 8400, RFHS ??? 2Y1 <-> 8420, CE 2Y2 <-> 8430, CE 2Y3 <-> 8400, HALT 1G <-> 74LS00, 5A und 5Y <-> RAM, A11 2G <-> 74LS00, 2A und 2Y <-> 1G Ist das eine alternierende Umschaltung? Erscheint das sinnvoll und nachvollziehbar? Bei den anderen Dingen geht es die nächsten Tage weiter. Viele Grüße, Jens
:
Bearbeitet durch User
Jens schrieb:
A14, A15 Input Demux, /CE RAM ist zweifach (sicher flash). Dein 1Y0 ist
ROM (sonst nix boot). Wenn A14/A15 gesichert sind, dann hast Du Speicher
(ROM) von 0x0000 - 0x3fff, RAM bei 0x4000 - 0x7fff. $0x8000 - 0xffff
sind nicht belegt (mit Deiner Beobachtung dass A15 an den ADC0809
angeklemmt koennte das passend und der ADC ist memory-mapped).
A2, A3 Input Demux, /RFSH ist Ausgang der CPU, /HALT auch (also falsch),
/CE PIO und /CE CTC koennte passen, und dann koennte gelten:
PIO $0x04-$0x07, CTC $0x08-$0x0B
Gucke bitte noch, ob an den NAND-Gattern (74LS00) /MREQ bei dem ersten
Demux angeklemmt, /IORQ beim zweiten.
Wenn sonst keine IO-Geraete am Bus sind, kann man auch den Bus nicht
komplett adressieren, man findet dann z.B. die PIO bei $0x14, $0x24 und
so weiter.
Vaxwoman
Jens schrieb: > Ist das eine alternierende Umschaltung? Der '139 besteht aus zwei identischen Blöcken. Der erste ist für RAM & ROM zuständig, und der zweite für Peripherie ... und sieht seltsam aus. Der erste Block teilt den Adressraum in vier gleichgroße 16-kiB-Blöcke: 0x0000 bis 0x3FFF 0x4000 bis 0x7FFF 0x8000 bis 0xBFFF 0xC000 bis 0xFFFF Es ist immer nur einer der vier Ausgänge auf Low-Pegel, alle anderen sind high. Da beim Z80 der Resetvektor auf Adresse 0x0000 liegt, muss der erste Block vom EPROM genutzt werden. Deine Annahme Jens schrieb: > 1Y0 <-> RAM, CE1 ist daher ziemlich sicher falsch. /CE1 ist beim 4364 ein Active-Low-Eingang. CE2 hingegen ist ein Active-High-Eingang; Du solltest bei solchen Signalen dringend die Polarität mit hinschreiben. Entweder durch vorangstellten / oder ! oder #. Eine Bitte: Die Bedeutung der Kürzel 8400 etc. wurde Dir schon erklärt, nutze doch bitte die korrespondierenden Namen (CPU, CTC etc.), das macht's einfacher. Die Doppelpfeile sind, da das eindeutige Ein- bzw. Ausgänge sind, auch nicht sinnvoll. Jens schrieb: > 2A <-> RAM, A3 > > 2B <-> RAM, A4 Nein. A3 und A4 sind keine Signale, die aus dem RAM kommen. Die werden von der CPU erzeugt, nicht andersrum. > 1G <-> 74LS00, 5A Meinst Du A5? Das ist äußerst unwahrscheinlich, denn der '139 schaltet seine Ausgänge in den Tristate (Hochohmig), wenn dieser Eingang (wieder fehlt hier das Negationszeichen) nicht auf Lowpegel liegt. Da eine Adressleitung dranzupacken ist widersinnig.
Vax W. schrieb: Selbstgespraeche ... > A2, A3 Input Demux, /RFSH ist Ausgang der CPU, /HALT auch (also falsch), > /CE PIO und /CE CTC koennte passen, und dann koennte gelten: > PIO $0x04-$0x07, CTC $0x08-$0x0B Da war wohl mehr mein Wunsch: PIO $0x08 - $0x0f, CTC bei $0x10 - $0x17 Glaube ich jedenfalls. Jetzt bin ich zu muede. Vaxwoman braucht ihren Schoenheitsschlaf. Vaxwoman
Harald K. schrieb: > denn der '139 schaltet seine Ausgänge in den Tristate (Hochohmig) Das Datenblatt sagt was anderes.
Mario M. schrieb: > Das Datenblatt sagt was anderes. Du hast recht. Korrektur: Harald K. schrieb: > Meinst Du A5? Das ist äußerst unwahrscheinlich, denn der '139 schaltet > seine Ausgänge alle auf Highpegel, wenn dieser Eingang (wieder > fehlt hier das Negationszeichen) nicht auf Lowpegel liegt.
Jens schrieb: > Kurzer neuer Zwischenstand zum HCT139 (wie von euch erwartet, aber noch > mit Lücken - meine Augen machen schlapp); Einen Durchgangspruefer (also Ohmmeter) hast Du schon, oder? Das Leben waere dann deutlich einfacher. vaxwoman
Vax W. schrieb: > Einen Durchgangspruefer (also Ohmmeter) hast Du schon, oder? Das Leben > waere dann deutlich einfacher. > > vaxwoman Guten Morgen zusammen. Ich habe schon viel gelernt und bin auf dem Weg ein Bild zu bekommen zu der Schaltung, aber ich bin noch lange nicht fertig. Der SIO und PIO wird noch spannend, da war ich noch gar nicht viel unterwegs mit meinem Auge Zu deiner Frage: Ja habe ich. Hab auch einen Oszilloskop-Adapter fürs Tablet. Den Logic Analyser habe ich bestellt. Da ich alltäglich nicht sehr viel mit all den Themen zu tun habe, stell ich mich vielleicht auch nicht immer klug damit an. Gestern war ich auch platt, konnte nicht mehr alles lesen und antworten. Heute bin ich auch stark eingebunden bis abends und komme erst dann dazu alle Hinweise von euch noch einmal durchzugehen. Aber kurz zu meinem lezten Beitrag: Die Pin-Bezeichnungen habe ich aus dem Datenblatt übernommen. Da das alles nicht wiederspruchsfrei war, zeichne ich das später noch einmal auf. Und: Ich habe da sicher noch Fehler drin. Die lange parallel laufenden Leiterbahnen und regelmäßigen Wechseln zwischen oben und unten sowie dem richtigen Zuorden zum Pin fordern meine Augen ganz schön heraus. Aber ich habe den Kühlkörper ohne Löten ausgebaut bekommen und nun alle ICs vom Sockel, da lässt es sich besser Leiterbahnen verfolgen.
:
Bearbeitet durch User
Jens schrieb: > Vax W. schrieb: > >> Einen Durchgangspruefer (also Ohmmeter) hast Du schon, oder? Das Leben >> waere dann deutlich einfacher. > Und: Ich habe da sicher noch Fehler drin. Die lange parallel laufenden > Leiterbahnen und regelmäßigen Wechseln zwischen oben und unten sowie dem > richtigen Zuorden zum Pin fordern meine Augen ganz schön heraus. > > Aber ich habe den Kühlkörper ohne Löten ausgebaut bekommen und nun alle > ICs vom Sockel, da lässt es sich besser Leiterbahnen verfolgen. Das brauchst Du doch gar nicht: Suche die SIO, Pin 35 (/CE). Pruefe Durchgang mit Durchgangspruefer zum Demux ('139). Es gibt genau vier Moeglichkeiten am Demux (2-4 Decoder). Pinnummer am '139 aufschreiben. Fertig. Ueblicherweise gucke ich Platinen einmal grob an, suche mir die Datenblaetter (z.B. 74LS139, SIO-0) und dann kommt der Durchgangspiepser. Gruesse Vaxwoman
Guten Morgen zusammen, ich bin dem Rat von Vaxwoman gefolgt und habe alle Verbindungen die ich abgelesen habe mit dem Multimeter durchgemessen. Ich habe ein paar Fehler korrigiert ggü. meinem Zwischenstand. Es ergibt sich nun für den HCT139 ein etwas klareres Bild: 1G: 74LS00,5A und 74LS00,5Y hängt an MREQ der CPU 2G: 74LS00,2A und 74LS00,2Y hängt an IORQ der CPU 1A: CPU,A14 1B: CPU,A15 2A: RAM,A3 2B: RAM,A4 1Y0: ROM,CE (Korrektur zu oben) 1Y1: RAM,CE (Korrektur zu oben) 2Y0: 8440(SIO),CE 2Y1: 8430(CTC),CE 2Y2: 8420(PIO),CE Mehr CEs gibt es ja nicht. 2Y3 geht auf einen 74LS02,4A und 1Y3 geht auf einen 74S251,G (muss ich noch weiter verfolgen). Hier hängen vermutlich ein paar Eingänge von den Handreglern dran. Für den 74LS00 komme ich an zwei Stellen nicht weiter, die Frage ist ob das überhaupt relevant ist: - Pin 4 (2Y) und Pin 5 (3A) sind verbunden und auch Pin 6 (3Y) und Pin 1 (1A) sind verbunden. Aber ich finde kein Ende für Pin 2 (1Y). Ist das relevant? - Pin 12 (6Y) geht auf RFSH der CPU, aber Pin 13 (6A) kann ich nirgends zuordnen. Macht das Sinn? Wo kann ich suchen, was da an 6A anliegen könnte? Vielleicht ist das auch nicht wichtig hier weiter zu machen für den Moment? Viele Grüße, Jens
:
Bearbeitet durch User
Jens schrieb: > 2A: RAM,A3 > > 2B: RAM,A4 Nein. Hab' ich weiter oben schon geschrieben. Die Quelle für diese Leitungen ist entweder die CPU oder gegebenenfalls ein unidirektionaler Bustreiber (der als "Verstärker" eingesetzt wird), niemals aber das RAM. Du hättest genausogut auch das EPROM angeben können, denn diese Leitungen sind auch mit dem EPROM verbunden. Also: A3 und A4 liegen da schon an, aber sie kommen aus der CPU.
Harald K. schrieb: > Also: A3 und A4 liegen da schon an, aber sie kommen aus der CPU. Das stimmt, ich kann es nicht mehr korrigieren, daher hier: 2A: CPU,A3 2B: CPU,A4 VG, Jens
:
Bearbeitet durch User
Das ist doch schon mal nicht so schlecht. Jetzt, sheer guesswork: Beim '251 werden an D0-D7 (Eingaenge) Taster angeklemmt sein. Der '251 hat einen 3bit Selector, A,B und C (Pin 11 - Pin 9). Gehe mal davon aus, dass da A0 - A2 anliegt. Der ausgewaehlte Pin ist dann bei Pin5 oder Pin6 des '251 und wird eingelesen. Poor man's IO-Port. Jetzt versteht man auch, warum die Entwickler A3 und A4 fuer das Decoding benutzt haben. End of guess work. Jetzt wuerde ich noch die Interrupt-Leitung durchklingeln (Bei der CPU ist der /INT-Eingang spannend, alle anderen Mitspieler sind OpenCollector-Outputs). Relativ wichtig waere die Verschaltung von IEI/IEO an den IO-Bauteilen (SIO, CTC und PIO): Damit kann man, beim Interrupt Mode 2, eine Prioritaetskette (daisy-chain) bauen (siehe https://de.wikipedia.org/wiki/Z80_Interrupt-Logik). Welche Interrupt-Verarbeitung benutzt wird, kannst Du in der SW der Zentrale sehen (ab 0x0000). Diese Reference-Card (immerhin nur zweiseitig) hilft Dir um den Startup-Code zu verstehen (ist in bunt): https://ballyalley.com/ml/z80_docs/Z80%20CPU%20Instant%20Reference%20Card%20(Color).pdf Oder versuche es mit einem Disassembler. LS00 ist ein einfacher Vierfach-NAND. Wenn Du weitere Logik-Funktionen brauchst, verbindest Du einfach ein paar Gatter (Z.B. NOT x ist x NAND x). Nicht so schlecht ist https://de.wikipedia.org/wiki/NAND-Gatter LS02 ist das gleiche in NOR. Jetzt weisst Du wo die Bauteile im Speicher/IO-Bereich liegen, Du weisst auch welche Teile, jetzt musst Du mit der SW anfangen, das Protokoll der Zentrale analysieren. Wenn Du das verstanden hast, kannst Du zu Weihnachten eine Lok um den Baum fahren lassen (drei Monate ist schon ambitioniert). vaxwoman
Vax W. schrieb: > Poor man's IO-Port. Ich fand damals die Z80-PIO viel zu umständlich. Für die Ausgänge habe ich 74LS573 Latches verwendet, für die Eingänge 74LS541 Tristate Treiber.
Vax W. schrieb: > Das ist doch schon mal nicht so schlecht. Jetzt, sheer guesswork: > Gehe mal davon aus, dass da A0 - A2 anliegt. Der ausgewaehlte Pin ist > dann bei Pin5 oder Pin6 des '251 und wird eingelesen. Das ist richtig, habe ich durchgemessen. Es werden 8 Schalter und 8 Potis eingelesen über die beiden 74LS251. Sobald ich etwas SW schreiben kann, kann ich die ja dann auch auslesen. Habe auch das Z80-MBC3 aufgebaut, damit starte ich dann meine ersten Programmierversuche. Die Verschaltung von IEI/IEO an den IO-Bauteilen (SIO, CTC und PIO) nehme ich mir am Wochenende vor. Es fehlen ja auch noch die Taster und 7-Segmentanzeigen, die sind auch am SIO und PIO. Außerdem gibt es noch eine Serielle Schnittstelle. Zwei Fragen noch: Danke für die Reference-Card. Hast du hier noch Tipps, wie ich vorgehen kann, also wie verwende ich diese? Wie fange ich an im Hex-Editor den Code zu lesen, also wo startet und endet der Startup-Code? Gibt es da einen einheitlichen Aufbau? Ich habe mir unter Ubuntu auch den z80dasm geladen. Ab welcher Adresse starte ich dann den Disassembler? > Jetzt weisst Du wo die Bauteile im Speicher/IO-Bereich liegen, Du weisst > auch welche Teile, jetzt musst Du mit der SW anfangen, das Protokoll der > Zentrale analysieren. Wenn Du das verstanden hast, kannst Du zu > Weihnachten eine Lok um den Baum fahren lassen (drei Monate ist schon > ambitioniert). > Hehe, na mal schauen. Ich bin ja noch etwas langsam dabei, weil ich das das erste Mal so mache. Aber ich bleibe weiter dran und melde mich, wenn ich neue Erkenntnisse oder Fragen habe. Noch mal vielen Dank für die Hilfe dabei. VG, Jens
:
Bearbeitet durch User
Peter D. schrieb: > Ich fand damals die Z80-PIO viel zu umständlich. Wenn man keine Interrupts braucht, und nichts von dem, was die PIO an Hardwarefeatures bietet, dann kann man sich das auch "von Hand" stricken. Möchte man aber beispielsweise einen Drucker mit Centronics-Interface ansteuern, nimmt einen der Hardwarehandshake der PIO einiges an Arbeit ab. Das war bei der 8255 und in der 65xx/68xx-Welt mit der PIA 6520/6521/6820/6821 genauso.
:
Bearbeitet durch User
Jens schrieb: > > Ich habe mir unter Ubuntu auch den z80dasm geladen. Ab welcher Adresse > starte ich dann den Disassembler? Ich hatte es schon weiter oben geschrieben: wenn Du das EPROM Image hier hochladen würdest könnte man Dir helfen.
Jens schrieb: > Ab welcher Adresse starte ich dann den Disassembler? Ab 0, da das EPROM im Adressraum bei 0 beginnt. Beim Z80 muss es das, da dort der Resetvektor liegt.
Jens schrieb: > Ich habe mir unter Ubuntu auch den z80dasm geladen. Ab welcher Adresse > starte ich dann den Disassembler? Du (und die CPU) faengt bei 0x0000 an. Dann wird sehr haeufig ein JR oder JP folgen weil der Bereich 0x00 - 0x7f bei der Z80 ziemlich gut belegt (RST0, RST8 [0x0008], RST10 bis zu RST38 [0x0038]. Der NMI liegt bei 0x0066) ist. Das ist alles Hard-Coded in der CPU. Wenn Du den Anfang der Start-Routine gefunden: Disassembler dort darauf setzen und gucken. Gruesse Th.
ich habe in Erinnerung dass der IDAPro für Z80 recht vernünftigen Output erzeugt. Vor Urzeiten habe ich mit dem IDA verschiedene Z80 Systeme reverse engineered (wie hier diese Aufgabe) https://de.wikipedia.org/wiki/Interactive_Disassembler täuscht mich meine Erinnerung, oder nicht?
Harald K. schrieb: > Jens schrieb: >> Ab welcher Adresse starte ich dann den Disassembler? > > Ab 0, da das EPROM im Adressraum bei 0 beginnt. Beim Z80 muss es das, da > dort der Resetvektor liegt. Da sollte man schon noch ein wenig unterscheiden. Der Z80 setzt beim Reset den Programmcounter auf Adresse 0 und fängt direkt mit der Programmausführung an. Dort muss also der erste Befehl stehen, oft ein C3xxxx, also JMP Adresse. Von Resetvektor spricht man eher dann, wenn von der prozessorspezifischen "Startadresse" erst die 16 oder 32 Bit breite Adresse des Programmanfangs in den Programmcounter geladen wird.
Ich habe den z80dasm bei 0 beginnend bemüht und er hat das hier rausgehauen. Bin gespannt, was ihr dazu sagt...
:
Bearbeitet durch User
Dann kannst Du jetzt anfangen zu basteln (die Initialiserung der Station):
1 | l01bbh:
|
2 | [...]
|
3 | ld sp,041f6h |
4 | di
|
5 | ld a,000h |
6 | ld i,a |
7 | im 2 |
8 | ld hl,04067h |
9 | ld b,050h |
10 | xor a |
Die Interrupt-Tabelle liegt bei $0x0000, Interrupt Mode 2. Und wenn Du weiter suchst, findest Du (Initialisierung SIO-Channel 2):
1 | ld (0406bh),hl |
2 | ld (04069h),hl |
3 | ld hl,l003ch |
4 | ld b,00bh |
5 | ld c,003h |
6 | otir
|
und ein bischen weiter die initialisierung des 1.Kanals:
1 | ld hl,l002fh |
2 | ld b,00dh |
3 | ld c,001h |
4 | otir
|
Mit dem Manual des SIO kannst Du dann bestimmen, wie die seriellen Schnittstellen arbeiten. Ein bischen spaeter Timer und PIO. Viele Glueck Vaxwoman
Jens schrieb: > Ich habe den z80dasm bei 0 beginnend bemüht und er hat das hier > rausgehauen. Bin gespannt, was ihr dazu sagt... Es geht um das binäre Image aus dem EPROM und nicht um das was Dein Disassembler daraus macht. Sinnvolles Reverse-Engineering macht man mit dem binären Image und nicht mit dem was irgendein Disassembler produziert hat.
Vax W. schrieb: > Hatte jemand mal ghidra > (https://github.com/NationalSecurityAgency/ghidra/) ausprobiert? Egal ob man Ghidra, IDA Pro oder ein anderes Reverse Engineering Tool verwendet: man braucht dazu das binäre Image um es in das Tool zu laden. Dann kann man daran arbeiten den Code zu verstehen, je mehr Erfahrung man hat um so schneller kommt man zu Ergebnissen. Welches Tool man nimmt ist nebensächlich und hängt von den persönlichen Präferenzen des Benutzer ab.
Beitrag #7498640 wurde vom Autor gelöscht.
Angehängte Dateien:
-
H-Term_output.png
34 KB -
20230908_222455.jpg
230 KB -
20230908_210058.jpg
230 KB -
20230908_210102.jpg
230 KB
Hallo zusammen, vielen Dank für euer Feedback. Ich habe eine Hex-Darstellung des Binaries in Notepad++ und zur Hilfe nehme ich mir den Disassembler-Code. Ghidra und IDA Pro finde ich sehr spannend, IDA Pro gibt es ja auch als Testversion. Das ist alles sehr viel Neues für mich und wird mich noch eine ganze Weile beschäftigen. Ich habe mir nun aber zunächst noch die serielle Schnittstelle mit meinem Rechner geschnappt, um zu schauen was da darauf so passiert: Angeschlossen habe ich sie nach Anleitung von Uli Johann, wobei ich nur GND, RX und TX an mein USB-Serial-Tool PL2303 / YP-01 angeschlossen habe: (https://fmz-info.digitalshop-uli-johann.de/fmztechnik.html) > Die Pegel von RXD (Empfangsdaten) und TXD (Sendedaten) sind umgekehrt > zur normalen V24 Norm bzw. einer Com-Schnittstelle eines PCs. > Damit ist die FMZ Schnittstelle kompatibel zu Homecomputern wie C64. > Das ist nicht weiter tragisch, da die Schnittstellen auf Flanken > reagieren. Um die Schnittstelle der FMZ-Zentrale nicht zu zerstören, > muss ein Pegelausgleich auf der RXD Leitung der FMZ-Zentrale erfolgen. > Man benötigt dazu eine Zenerdiode ZPD 4.7 und einen Wiederstand mit > 2,2 KOhm. Für die Z-Diode keinen Vergleichstyp oder ähnliche Spannung > wie z.B. 5.2 V verwenden, das funzt nicht. Der Ring an der Diode muss > zum Pin 3 der FMZ-Zentrale zeigen. Könnt ihr das nachvolziehen und mir bitte den Hintergrund für den Pegelausgleich erklären? Ich habe mich bisher nie mit einem C64 beschäftigt und auch nie die Unterschiede bei der Beschaltung angesehen. Spielt das bei dem YP-01 überhaupt eine Rolle? Zu dem Terminal Emulator: Als Eistellungen habe ich die in dem FMZ-Handbuch beschriebenen Einstellungen verwendet (2400 Baud, 2 Stop-Bits, 8 Daten-Bits, Parity 0), siehe Screenshot. Zu erwarten wäre nun ein Verhalten, dass die Steuerzeichen als ASCII die ich sende auch wieder ebenso zurückkommen. Ich bekomme aber nur komische Zeichen zurück (siehe Screenshot). Bin mir nicht sicher, ob ich etwas falsch mache. Es ist ja zunächst schön, dass überhaupt etwas passiert. Habt ihr so etwas ähnliches schon mal gesehen und einen Rat für mich? Da ich auch nicht sicher sein kann, was in den letzten 30 Jahren mit der Zentrale bzw. seriellen Schnittstelle gemacht wurde, kann auch ein Defekt irgendwo erst mal nicht ausgeschlossen werden: Es sind zwei Hex Inverter 74LS04 und 74LS05 vorgeschaltet bevor es auf den Z8440 SIO geht. Wenn einer dieser Bausteine defekt ist, wäre das Verhalten dann nachvollziehbar? Und kann ich das vielleicht irgendwie eingrenzen, wenn ich beim Z8440 mal direkt auf Rx und Tx mit entsprechender Vorschaltung gehe? Wie sollte dann die Vorschaltung zum 8400 am besten aussehen? Viele Grüße, Jens
:
Bearbeitet durch User
Hallo zusammen, ich habe versucht etwas besser zu verstehen, wie die serielle Schnittstelle funktioniert. Bitte schaut mal, ob ich es richtig verstanden habe: Der DM7405N verfügt über Open-Collector-Ausgänge. Daher muss für einen High-Pegel (Logisch 1) der Ausgang mit einem Pull-up Widerstand hochohmig gehalten und für Low-Pegel (Logisch 0) auf GND gezogen werden. Gemessen habe ich 1KOhm für das Widerstandnetzwerk der Pull-up Widerstände am RxD, TxD, RTS, CTS, DTR und DCD. Bedeutet das nun, dass zur Kommunikation an dem RxD-Eingang ein High-Pegel anliegt und dieser dann einfach auf Low gezogen werden muss? Ok, soweit kann ich ja vielleicht noch folgen. Wie bringe ich das nun aber mit den RS232-Pegeln zusammen (-3..-15V, +3..15V)? Soll die Z-Diode bei einem High-Pegel die Spannung immer bei max. knapp unter 5V begrenzen? Dient dann der 2,2K Widerstand dazu den Strom bei Low-Pegel zu begrenzen? Im Datenblatt steht, dass der Strom bei Low max. 16mA sein darf. Wie ist das dann aber mit einem Low-Pegel mit -3V bis -15V? Da verstehe ich die Schaltung nicht. Ich bitte euch mir zu helfen das zu verstehen. Viele Grüße, Jens
:
Bearbeitet durch User
@TO: Willst Du wirklich nicht mal den (bis anhin aufgenommenen) Schaltplan reinstellen und (hochauflösende) Bilder von Vorderseite UND Rückseite? Ich habe mir Deine Prosa durchgelesen, aber ich verstehe nicht, was Du Fragen willst. Gruss Chregu
Hallo Chregu, ich habe bisher nur Handskizzen. Einen Schaltplan kann ich erstellen, wenn ich einmal komplett durch bin. Es fehlen nur noch SIO und PIO. Habe im Studium vor Ewigkeiten mal mit Target 3001! gearbeitet. Habt ihr sonst eine Empfehlung? Jetzt hab ich mir ja den SIO und die serielle Schnittstelle vorgenommen. Bei meinen Fragen beschäftigt mich dabei: - Warum haben die einen 7405 am TxD und 7404 am RxD verwendet? Gelesen habe ich davon, dass dann mehrere Teilnehmer möglich werden wie am IEC-Bus. - Ich wundere mich auch noch über die Vorschaltung: Bei einem Low-Pegel können von RS232 -15V anliegen. Wie ist das dann bei der Zenerdiode bei mit der Flussrichtung? Die schaltet durch und zieht den Eingang auf Gnd, richtig? Anstatt der einfachen Schaltung kann ich vermutlich auch einfach einen MAX232 vorschalten? Ich vermute auch, dass die Inverter kaputt sind. Es kommt ja nur Murx zürück, s.o. Hochauflösende Fotos meinst du von der Platine oben und unten? Die kann ich noch machen, wenn es hell ist. Viele Grüße, Jens
:
Bearbeitet durch User
Jens schrieb: > Ich vermute auch, dass die Inverter kaputt sind. Es kommt ja nur Murx > zürück, s.o. bei serieller Kommunikation habe ich es früher so gemacht: KEIN "Device" angeschlossen, sondern erst mal auf der "Terminal" Seite RX-TX zusammen geschaltet, und KEINE Steuerleitung (zwecks Datenfluss-Kontrolle) beschaltet. Somit habe ich ein "lokales" loopback und kann sicher sein, dass a) Daten auf der TX-Seite rausgehen b) Daten auf der RX-Seite reinkommen danach kann man sich mit der Pegel-Anpassung des "Device" beschäftigen, und überlegen wie man von +12/-12 auf 0/+5 kommt, und welche Pegel eine "0" und welche eine "1" übertragen sollen. Zum Schluss kann man sich noch Gedanken machen über - Geschwindigkeiten und Start/Stopbits - Datenfluss-Kontrolle (per Software oder über Steuerleitungen) --> Wo stehst du denn aktuell in dem Prozess? Was hast du schon, was weißt du, bzw. wo sind noch Unklarheiten? Wenn "nur Murx" zurück kommt, kann es ja auch bedeuten, das dein Device gar kein Loopback der gesendeten Zeichen macht, und du tatsächlich nur Signal-Schrott einfängst.
:
Bearbeitet durch User
Jens schrieb: > Ok, soweit kann ich ja vielleicht noch folgen. Wie bringe ich das nun > aber mit den RS232-Pegeln zusammen (-3..-15V, +3..15V)? Deine Hardware ist nicht für RS232-Pegel ausgelegt, sondern für den Betrieb mit sog. "TTL-Pegeln". Um einen PC o.ä. mit Deiner Hardware kommunizieren zu lassen, brauchst du einen USB-Seriell-Wandler ohne RS232-Pegelwandler. Z.B. so etwas: https://www.amazon.de/dp/B0B212NKGJ Mit einem standardkonformen Pegelwandler wirst Du Deine Hardware beschädigen, die mag keine Eingangspegel < 0V und auch keine > 5V. Es kann sein, daß eine zusätzliche Invertierung der Signale erforderlich ist; um das beurteilen zu können, müsste man den Schaltplan sehen und sich nicht durch blumige Prosa kämpfen müssen. Ist jeweils nur ein Gatter der Inverter 7405/7404 zwischen der 9poligen Buchse und der SIO verbaut, oder sind da jeweils zwei Gatter in Reihe geschaltet?
Danke für eure Tipps Harald K. schrieb im Beitrag > Ist jeweils nur ein Gatter der Inverter 7405/7404 zwischen der > 9poligen Buchse und der SIO verbaut, oder sind da jeweils zwei Gatter in > Reihe geschaltet? Ja, es ist nur ein Gatter zwischen Buchse und SIO. Ich denke die 7405/7404 könnten defekt sein. Unschön ist, dass sie direkt eingelötet sind. Wenn ich sie ersetze, dann auf jeden Fall gleich mit Sockel. Kann ich es irgendwie eingrenzen, z.B. direkt am SIO abgreifen und mit einem MAX232 verbinden? VG, Jens
Jens schrieb: > Kann ich es irgendwie eingrenzen, z.B. direkt am SIO abgreifen und mit > einem MAX232 verbinden? Wenn Du an dessen anderer Seite dann eine Schnittstelle mit RS232-Pegeln betreiben willst, ja. Du musst allerdings die Verbingung zwischen dem Gatter und dem RX-Eingang der SIO trennen, da Du sonst zwei Ausgänge parallelgeschaltet hast (das des Gatters und das des MAX232). Wenn Du so einen "TTL"-Seriell-Adapter hast, kannst Du den allerdings statt des MAX232 anschließen. Immer dran denken: Rx und Tx müssen gekreuzt werden, d.h. Ein- muss mit Ausgang verbunden werden. Aber auch hier muss die Verbindung zwischen dem (dann unbenutzten) Gatter und dem RX-Eingang der SIO getrennt werden.
Ich habe ja keine Ahnung davon, aber ich wuerde erstmal gucken, an welcher SIO die serielle (DB9)-Buchse haengt. Dann wuerde ich mit einem 10EUR-USB-LA einfach messen, was kommt. Ich wuerde sogar soweit gehen, dass ich bei Label l003ch (oder l002fh) mal gucken wuerde wie die SIO initialisiert wird. Dann waere z.B. klar, ob Handshake notwendig oder nicht. Das (wirklich schoene) SIO-Manual von Zilog (http://www.hartetechnologies.com/manuals/Zilog/Zilog%20Z80-SIO%20Technical%20Manual.pdf) ist ja fast schon ein Kunstwerk. Die Prosa ueber die Beschaltung der RS232 habe ich mir nicht durchgelesen (TL;DR): Wenn der TO nicht willens oder faehig ist, die zwei oder drei Gatter auf ein Blatt Papier zu malen, dann ist das nicht so wichtig.
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.