Hallo zusammen, zur Zeit bastele ich an einem von mir reparierten Gould 1504 Oszilloskop herum, in dem ein MC6809 werkelt, und möchte ein paar kleine Hardware-/Software-Erweiterungen realisieren, um meine lausigen Reverse-Engineering Fähigkeiten zu verbessern. Da zu dem Gerät keinerlei spezifische Dokumentation verfügbar ist, musste ich mit dem leider relativ schlecht gescannten Service Manual für das Gould 1604 vorlieb nehmen. Letzteres ist zwar sehr ähnlich, das 1504 unterscheidet sich aber, wie ich herausfinden musste, unter anderem durch einen Satz größerer Speicherchips und eine dementsprechend abweichende Adressdekodierung. Diese benötige ich, damit Ghidra bei Disassembly und Dekompilierung hoffentlich möglichst fehlerarm arbeitet. Weil in der Adressdekodierung des 1504 aber teilweise auch PAL Chips statt einfacher NAND- und NOR-Gatter verwendet wurden, wäre das Speichermapping nur extrem zeitaufwändig manuell zu rekonstruieren und, durch erforderliches Auslöten von Chips, auch vermutlich nicht beschädigungsfrei. Ich habe zwar, basierend auf dem Inhalt der EPROMs, schon ein halbwegs gut aussehendes Speichermapping erstellt, aber dieses muss noch verifiziert/korrigiert werden. Bei dem bisher nur mäßig erfolgreichen Versuch, mir rudimentäre 6809 Programmierkenntnisse anzulesen, bin ich dann nach längerer Zeit zufällig über die HCF-Befehle gestolpert. Diese versetzen den 6809 durch illegale OP-Codes offenbar in einen Testmodus, in dem der Prozessor nicht mehr reagiert und nur noch stumpf die Adressen durchzählt. Meine Idee wäre nun, ein EPROM zu schreiben, welches den 6809 gezielt mit einem HCF Code füttert und dann die höchst- und niedrigstwertige Adressbusleitung des 6809 und jeweils die Chip-Enable-Eingänge des RAM-Chips, der ROMs und eventuell weitere Low-Level-IO Mappings aufzuzeichnen. Auf diese Weise müsste ja, sofern ich keinen Denkfehler gemacht habe, mit nur drei gleichzeitig zu beobachtenden Logikkanälen zu ermitteln sein, welche Chips wohin in den Speicherbereich des 6809 abgebildet werden. Nun bin ich mir aber nicht sicher, ob ich durch Versetzen des 6809 in den HCF-Modus eventuell irgendwelche Nebeneffekte, oder sogar Schäden an der restlichen Hardware des Oszilloskops verursachen kann. Hat hier diesbezüglich vielleicht jemand Erfahrungen oder erkennt ohne großes Nachdenken sofort, dass mein Plan noch andere Dummheiten beinhaltet bzw. gar nicht funktionieren würde. Über ein paar hilfreiche Eingebungen würde ich mich sehr freuen. Viele Grüße Denis
Schau dir jeweils die select Leitungen an und dazu die hohen Adressen. Dann solltest du die Adressen erkennen koennen. Das Eprom hast du schon ausgelesen ?
Du kannst also das/die EPROM austauschen weil sie gesockelt sind, aber nicht den Rest der Elektronik. Ich würde versuchen, den 6809 durch durchtrennen der HALT Leitung in den Halt Modus zu bringen. E und Q laufen als Takt weiter, aber Adress und Datenbus sind hochohmig so dass du deine eigenen Signale anlegen kannst, per 40-poligem Klemmadapter auf der CPU oder so. Dann kannst du Lese- oder Schreibbefehle auf vermutete Adressregionen absetzen und gucken wa da wie nach dem Adressdecoder reagiert.
Angehängte Dateien:
-
1604_memory_mapping.png
72 KB -
1504_memory_mapping.png
85 KB
Hallo, Danke für die Antworten. @Schorsch: Mit Chip-Enable-Eingängen meinte ich die Select-Leitungen. Die hohen Adressen wollte ich beobachten, um den Anfang des Adressbereichs zu sehen und die niedrigen, um die genauen Adressbereichsgrenzen zu sehen. Die ROMs habe ich schon alle ausgelesen und mit Hilfe von Ersatzchips auch schon versucht, daran herumzupatchen. Dabei habe ich aber herausgefunden, dass die Firmware des Gould 1504 im Gegensatz zum 1604 mit hoher Wahrscheinlichkeit einen Prüfsummenalgorithmus verwendet, um die Integrität der ROMs zu prüfen(zumindest die des Haupt EPROMS U2). Wenn ich auch nur ein Byte, z.B. in einer Zeichenkette für die Displayausgabe ändere, startet das Oszilloskop nicht mehr, sondern zeigt einen nicht dokumentierten LED-Fehlercode an. Daher muss ich zumindest so viel vom Code mit Ghidra verstehen, um den Prüfsummenalgorithmus zu finden und nach meinen Änderungen entsprechend anzupassen. Falls das hilfreich ist, habe ich mal Bilder vom 1604 Speicherpapping und von meinem bisher geschätzten 1504 Speicherpapping in Ghidra angehängt. Bei den Bereichen für U2 (0x9000-0xffff) und I/O (0x0-0x7f) bin ich mir schon recht sicher, dass die auch beim 1504 stimmen. U2 geht wegen der Startadresse in 0xfffe nicht anders und die Speicherzugriffe im I/O Bereich sahen in Ghidra bisher auch konsistent aus. Abweichend von 1604 wird im U2 EPROM der Bereich von 0x8000-0x8fff aber nicht genutzt und ich bin mir fast sicher, dass dorthin beim 1504 noch Teile des doppelt so großen RAM Chips (U3) oder I/O Adressen gemappt werden, weil dort, soweit bisher für mich ersichtlich, auch Schreibzugriffe erfolgen. Zusätzlich hat U29 halt doppelt so viele Pages, wie beim Gould 1604. @ Michael: Ja genau, die Speicherchips und die CPU sind gesockelt, aber die Chips für die Adressdekodierung nicht. Ein Problem beim Gould 1504/1604 ist, dass teilweise über der CPU direkt noch eine Platine montiert ist und auch sonst nicht sehr viel Platz wodurch das dranbasteln von CPU-Extendern etwas aufwändiger würde. Bevor ich die HCF-Codes kannte, wollte ich auch erst einen Adapter basteln, bei dem sich mit einem Mäuseklavier der Adressbus schalten lässt. Welchen Vorteil genau hätte denn deine Veriante gegenüber dem HCF-Modus? Denis
:
Bearbeitet durch User
Du könntest einen "NOP-Adapter" bauen und ihn statt der CPU einbauen. Dann rattert die cpu stetig den Adressbus durch ... Z.B.: https://www.aussiearcade.com/topic/97544-nop-design/
:
Bearbeitet durch User
Ja, genau an soetwas hatte ich zunächst gedacht(siehe vorheriger Post), bevor ich die HCF-Codes entdeckt hatte. Theoretisch macht der 6809 halt außer die Adressen hochzuzählen nichts mehr wenn man ihn mit einem HCF-Code füttert, auch nicht auf Interrupts antworten. Da bekommt man ihn dann nur mit einem Hard-Reset raus. Ich frage mich halt nur, ob durch das stumpfe Hochzählen der Adressen an anderer Stelle im Gerät irgendetwas destruktiv schief gehen kann. Der NOP-Adapter auf der verlinkten Seite sieht natürlich schick aus.
:
Bearbeitet durch User
Denis F. schrieb: > Welchen Vorteil genau hätte denn deine Veriante gegenüber dem HCF-Modus? Dokumentiert, langsam genug zum mitgucken, einfach, du kannst sogar einen 40-pol Flachbandkabeladapter in den CPU Sockel stecken und dann gemütlich ausklingeln.
Etwas Hintergrund zu HCF aka "Halt and Catch Fire": "The Z1 (1938) and Z3 (1941) computers built by Konrad Zuse contained illegal sequences of instructions which damaged the hardware if executed by accident." https://en.wikipedia.org/wiki/Halt_and_Catch_Fire_(computing)
Michael B. schrieb: > Denis F. schrieb: >> Welchen Vorteil genau hätte denn deine Veriante gegenüber dem HCF-Modus? > > Dokumentiert, langsam genug zum mitgucken, einfach, du kannst sogar > einen 40-pol Flachbandkabeladapter in den CPU Sockel stecken und dann > gemütlich ausklingeln. Hmmmm, also wäre der Vorteil nur die Kontrollierbarkeit. Dokumentiert, wenn auch nicht von Motorola, sind die HCF-Codes ja auch. Da man mittels Mäuseklavier nicht beliebig direkt zwischen zwei Adressen umschalten kann, müsste ich dann noch Multiplexer als Puffer dazwischen bauen, aber Multiplexer handgeschaltet zu befüllen ist recht langwierig, weshalb ich dann zwecks Automatisierung z.B. einen Arduino daran bauen müsste. Mit einem Arduino kann ich mir dann wiederum die Multiplexer schenken, brauche aber zur Sicherheit Logik-Level-Konverter, weil Gould sich einerseits entschieden hat mit 5.4V zu arbeiten und ich andererseits nicht sicher bin, ob ein Arduino-Ausgang genug Saft für die Speicherleitungen im 1504 hat. Also alles mit verhältnismäßig vielen Extra-Teilen und Bastelei für "einmal kurz nachsehen" verbunden. Vielleicht denke ich aber auch zu kompliziert und ein selektives "Adresse manuell einstellen"->"Oszi einschalten"->"Chip-Select auslesen"->"Oszi ausschalten" würde auch funktionieren, Insgesamt bleibt ja das Grundproblem bestehen, dass ich nicht weiß, ob es schädliche Nebeneffekte hat, einfach die Adressen durchzuschalten, während der Datenbus vermutlich die ganze Zeit einfach auf null bleibt. Es könnte ja sein, dass andere Komponenten im System eine bestimmte Initialisierung benötigen, um nicht in einem auf Dauer schädlichen Initialzustand festzuhängen. Wenn das ein generelles Problem wäre, würde es andererseits aber auch das Gerät frittieren, sollte die CPU mal aufgrund eines Wackelkontakts oder anderen Problems nicht mehr arbeiten, was ich so beim Reparieren von Geräten noch nicht beobachten konnte.
Denis F. schrieb: > Insgesamt bleibt ja das Grundproblem bestehen, dass ich nicht weiß, ob > es schädliche Nebeneffekte hat, einfach die Adressen durchzuschalten, > während der Datenbus vermutlich die ganze Zeit einfach auf null bleibt. Welche sollten das sein? Es werden keine Schreib-, sondern nur Lesezugriffe ausgeführt. Da müssten die Hardwaredesigner schon gezielt sehr bösartige Hardwarefehler in ihr Gerät eingebaut haben, damit das irgendwelche Probleme verursachen kann. Was man mit einem "HCF"-Decoder allerdings nicht herausfinden kann, sind Tricks zur Adressraumerweiterung à la "Bank Switching". Wenn im Gerät also mehr als in Summe 64 kiB RAM und ROM vorhanden sind, hilft der "HCF"-Decoder nur in der ersten Stufe vor der "Bank-Switching"-Logik. Zeig' doch mal ein Bild (hinreichend hoch aufgelöst, daß man Chipbezeichnungen lesen kann, gut ausgeleuchtet etc.) der beteiligten Platinen. Denis F. schrieb: > Die ROMs habe ich schon alle ausgelesen und mit Hilfe von Ersatzchips > auch schon versucht, daran herumzupatchen. Was willst Du denn daran ändern?
Gibt es den ROM Dump irgendwo zum Download? Falls nicht: stell ihn doch hier rein, dann sieht man worum es geht.
Du könntest die roms auch nutzen, um sie auf einem PC in einem Emulator laufen zu lassen. Geht einfacher als man denkt.
Christian X. schrieb: > um sie auf einem PC in einem Emulator > laufen zu lassen Dazu müsste der Emulator aber schon irgendwie die im Gerät verbaute Architektur aufweisen, d.h. RAM/ROM und Peripherie müssen an den korrekten Adressen liegen. Wo ein Hardwaredesigner den Kram im 64-kiB-Adressraum anordnet, ist aber beim 6809 bis auf sieben Vektoren in den oberen vierzehn Bytes (für Reset, drei Hardware- und drei Softwareinterrupts), die üblicherweise in einem ROM, bei anspruchsvolleren Konstruktionen aber auch mit einem zur Laufzeit alternativ einblendbaren RAM liegen können. Wie der Rest konzipiert ist, bleibt völlig dem Gestalter überlassen, anders als bei den anderen 68xx-Prozessoren oder 6502 ist es beispielsweise nicht erforderlich, die ersten 256 Byte im Adressraum für "schnelle" Speicherzugriffe mit 1-Byte-Adressen ("Zero-Page") vorzusehen, denn dank des "Direct Page"-Registers kann dieser Adressraum beim 6809 beliebig im Adressraum angeordnet werden (das Register legt die oberen acht Bit fest, die bei 8-Bit-Adressierung verwendet werden).
Angehängte Dateien:
Danke für die zusätzlichen Antworten! Harald K. schrieb: > Welche sollten das sein? Es werden keine Schreib-, sondern nur > Lesezugriffe ausgeführt. Da müssten die Hardwaredesigner schon gezielt > sehr bösartige Hardwarefehler in ihr Gerät eingebaut haben, damit das > irgendwelche Probleme verursachen kann. Nach dem Post von Harald war ich eben mal mutig, habe mir schnell ein HCF ROM gebaut und damit ein wenig herumgemessen. Der einzige funktionierende HCF-Opcode auf den 6809 scheint 0xCD zu sein. Ob er zum gewünschten Ergebnis führt, war aber zumindest in meiner Schaltung nicht immer konsistent. Manchmal musste ich das 1504 mehrmals einschalten, bevor das Adressmuster gepasst hat. Bemerkenswert ist auch, dass zumindest mein 6809 die Adressen nicht mit konsistenten Timings durch schaltet. Am Anfang des Adressbereichs gibt es einen Bereich in dem die Timings signifikant in beide Richtungen abweichen. Messtechnisch konnte ich den Frickelfaktor im Gerät etwas dadurch entschärfen, dass fast alle Adressleitungen des 6809 auch zu den beiden Pluginschnittstellen an der Rückseite des Geräts herausgeführt werden. Nach Konsultation des 1604-Service-Manual und nachmessen, konnte ich dort die Adressleitungen A1 bis A14 sowie ein "nicht(A15 oder A16)" Signal lokalisieren, was praktisch ein vollständiges Adressmonitoring erlaubt. Also habe ich dort den 16-Kanal Logictastkopf von einem Siglent SDS2104Xplus drangehängt und mit Kanal 1 die Chip-Select-Leitungen begutachtet. Dabei hat sich dann meine ROM-inhaltsbasierte Vermutung bestätigt, dass das Haupt-ROM U2 wirklich erst bei 0x9000 anfängt, statt wie beim Gould 1604 schon bei 0x8000. Auch meine weiter oben geäußerte Vermutung, dass der noch freie Bereich für mehr RAM genutzt wird, war richtig. Der RAM-Chip U3 wird beim 1504 auf 0x80-0x1fff und 0x8000-0x8fff gemappt. Ein vier Mal so großer RAM-Chip wie beim 1604 macht's möglich, wenn auch dabei recht viel Speicher verschwendet wird(es sei denn da ist noch RAM-Paging mit im Spiel). Dabei war auch schön zu sehen, dass U3 für jeden Speicherzugriff separat aktiviert wird. Leider konnte ich nicht in gleicher Weise den Adressbereich des Paged-ROM U29 bestimmen, weil dessen Chip-Select Leitung beim Betrieb im HCF-Modus gar nicht aktiviert wurde. Sofern mir dabei kein Messfehler unterlaufen ist würde das also bedeuten, dass im Grundzustand gar keine der 8 Memory Pages von U29 in den Hauptspeicher gemappt wird. Soweit nicht unerwartet, da die Memory Pages in U29 von einem MC74HC174A(Chip mit sechs D-Flip-Flops) geschaltet werden. Wenn das Dank HCF nicht den richtigen Zustand hat, kann es auch U29 nicht einschalten. Da ich aufgrund des ROM-Inhalts aber schon weiß, dass die Pages von U29 im 1504 alle 16K groß sind, wie beim 1604, ist nicht davon auszugehen, dass sich an der Speicherposition etwas geändert hat. Daher dürfte das High-Level-Speicherlayout soweit erst mal stimmen. Harald K. schrieb: > Zeig' doch mal ein Bild (hinreichend hoch aufgelöst, daß man > Chipbezeichnungen lesen kann, gut ausgeleuchtet etc.) der beteiligten > Platinen. Ein Bild auf dem man den Interessanten Bereich komplett sehen kann, lässt sich nur anfertigen, wenn man die Hauptplatine komplett entfernt, was sehr aufwändig ist. Hier mal eine kurze Übersicht, über die verbauten zentralen Chips: Prozessor: Motorola MC68B09P
1 | ID Chip Capacity Package Purpose |
2 | -----------------------------------------------------------------------------------------------
|
3 | U2 NM27C256Q 150 32K x 8 DIL-28 Main ROM |
4 | U29 TMS 27C010A-200JL 128K x 8 DIL-32 Paged ROM (only 64K on 1604) |
5 | U22 NMC27C64Q 200 8K x 8 DIL-28 Display ROM |
6 | U3 HY62256ALP-70 32K x 8 DIL-28 RAM (only 8K on 1604) |
Das Service Manual vom ähnlichen Gould 1604 gibt es hier: https://xdevs.com/doc/Gould/Gould_1602_1604_Full_Service_Manual_Service_Manual-GOULD1602_1604_Oscilloscope_SERVICE_MANUAL.pdf Interessant für den 6809 sind dabei die Schaltpläne auf den PDF-Seiten 113 und 114. Da sieht man trotz der schlechten Scanqualität relativ gut, wie die zentrale Systemarchitektur aussieht. Harald K. schrieb: > Was willst Du denn daran ändern? Unter anderem möchte ich die Geschwindigkeit des seriellen Acia 6551 Controllers für den optionalen Plotter umprogrammieren. Das hat schon mal jemand für das 1604 beschrieben, ist aber halt nicht ganz so einfach auf das 1504 übertragbar. Christian X. schrieb: > Sowas könnte man verwenden: https://github.com/spc476/mc6809 Ich bin gerade dabei den Code durch Ghidra zu jagen, weil mein intuitives Verständnis von Assembler-Code auch nach der Lektüre diverser 6809 Programmierbücher ziemlich lausig ist. Ghidra leistet beim dekompilieren wahre Wunder, aber hat auch noch so einige Probleme, die ich mangels Dokumentation der dazu nötigen Programmfeatures noch nicht lösen kann. Dazu zählen einerseits diverse Dekompilierfehler, welche manuelle Korrekturen erfordern und andererseits, wie man Memory Pages bzw. Overlays korrekt realisiert. Dieter S. schrieb: > Gibt es den ROM Dump irgendwo zum Download? Falls nicht: stell ihn > doch hier rein, dann sieht man worum es geht. Nein, zum Gould 1504 gibt es im Netz praktisch nichts. Ich habe den Satz ROMs mal angehängt. Die Dateinamen beinhalten den Chip, die Gould-Teilenummer, den Chipbezeichner im Gerät und die Firmwarerevision.
Denis F. schrieb: > Da sieht man trotz der schlechten Scanqualität relativ gut, > wie die zentrale Systemarchitektur aussieht. Irgendjemand hat mal ganz schlau festgelegt, daß man monochrome Vorlagen nur mit 1bpp scannen darf ... und dann kommt so ein Scheiß dabei raus. Ein Graustufenscan wäre hier viel besser. Schaltpläne, in denen ICs nur mit willkürlichen "Ux"-Bezeichnern versehen sind, sind natürlich auch ganz toll, auch wenn man mit etwas Erfahrung erahnen kann, daß z. U8 und U9 vermutlich '541 sind und U7 ein '245 ist. Statt den 6551 anders zu programmieren, könntest Du auch den verwendeten Quarztakt ändern. Beim Überfliegen des Schaltplans hab' ich das Ding allerdings nicht finden können; auf welcher Seite verbirgt der sich denn? Ich hab' nur einen "Dual RS423 Controller" finden können, und der ist definitiv was anderes als ein 6551. Ein 6552 kann das ach nicht sein, der hat 'ne andere Pinbelegung.
Denis F. schrieb: > > Unter anderem möchte ich die Geschwindigkeit des seriellen Acia 6551 > Controllers für den optionalen Plotter umprogrammieren. Das hat schon > mal jemand für das 1604 beschrieben, ist aber halt nicht ganz so einfach > auf das 1504 übertragbar. Du meinst das hier? http://www.hit-karlsruhe.de/aol2mime/gould_dso1604.htm Die dort beschriebenen Funktionen sind auf den ersten Blick fast identisch in den Dumps von Dir zu finden (z.B. die Funktion 0xE715 dort ist 0xA8AF bei Dir).
Harald K. schrieb: > Irgendjemand hat mal ganz schlau festgelegt, daß man monochrome Vorlagen > nur mit 1bpp scannen darf ... und dann kommt so ein Scheiß dabei raus. > Ein Graustufenscan wäre hier viel besser. > Für's Lesen am Bildschirm ja, für das Ausdrucken mit Laserdruckern aufgrund der Verrasterung nein. Letzteres ist aber kein Problem, wenn die Auflösung stimmt. Ich habe mal mit großem Zeiteinsatz die bis dahin nicht im Web verfügbare Anleitung für das Tektronix D755 mit 1200dpi digitalisiert. Da habe ich aufgrund der nur mäßigen Vorlage in der Nachbearbeitung fast jeden dritten Buchstaben per Hand reparieren müssen. Dafür hat ein Ausdruck des Ergebnisses aber nun bessere Qualität als das Original. Eine 300dpi Version davon gibt es auf Tekwiki: https://w140.com/tekwiki/images/f/f8/070-1487-10.pdf > Schaltpläne, in denen ICs nur mit willkürlichen "Ux"-Bezeichnern > versehen sind, sind natürlich auch ganz toll, auch wenn man mit etwas > Erfahrung erahnen kann, daß z. U8 und U9 vermutlich '541 sind und U7 ein > '245 ist. Ja, das muss man bei Gould immer in der Teileliste nachsehen, aber auch da stehen nur die nicht Custom-Teile. > Statt den 6551 anders zu programmieren, könntest Du auch den verwendeten > Quarztakt ändern. Beim Überfliegen des Schaltplans hab' ich das Ding > allerdings nicht finden können; auf welcher Seite verbirgt der sich > denn? > Der 6551 ist auch auf Seite 114 unten rechts: U18 "Keypad/Internal Plotter Driver ACIA /UART". Da ist beim 1604 ein 1.8432 MHz HC18/u dran. Ich habe für den bei mir nicht verbauten Plotter halt schon ein schickes ESP32-basiertes Web-Interface gebaut. Jetzt kann man sich via WiFi mit dem Gerät verbinden und bekommt vektorisierte Plots über ein Interface serviert. Dummerweise wird der Plotter aber nur mit 600 Baud gefüttert. Aufgrund der mechanischen Geschwindigkeitslimitierung beim Plotten ist das ja normalerweise OK, aber minutenlang auf Plots zu warten ist langweilig. ;-)
Dieter S. schrieb: > > Du meinst das hier? > > http://www.hit-karlsruhe.de/aol2mime/gould_dso1604.htm > > Die dort beschriebenen Funktionen sind auf den ersten Blick fast > identisch in den Dumps von Dir zu finden (z.B. die Funktion 0xE715 dort > ist 0xA8AF bei Dir). Ja, genau. Das meinte ich. Der Autor scheint sehr viel Ahnung von der Materie gehabt zu haben. Die Funktion in meinem ROM zu lokalisieren war auch relativ einfach, da es die Befehlssequenz sonst nirgendwo gibt. Patchen war auch einfach, hat aber nicht funktioniert, vermutlich, weil das Oszi die Integrität des ROMs prüft und im Negativfall gar nicht erst startet. Unter anderem daher mein Versuch den Startcode halbwegs verständlich zu dekompilieren. So schlecht sieht es bisher auch nicht aus. Immerhin die Funktion zur Versionsüberprüfung der Firmwarekomponenten habe mit hoher Wahrscheinlichkeit ich schon gefunden. Die Prüft, ob Gerät und Firmware und eventuell installierte Optionen kompatibel sind.
Denis F. schrieb: > > Patchen war auch einfach, hat aber nicht funktioniert, vermutlich, weil > das Oszi die Integrität des ROMs prüft und im Negativfall gar nicht erst > startet. Die Funktion 0x9D1B prüft die Checksumme des Bereich 0x90D1 bis 0xFFFF (die Startadresse 0x90D1 steht dabei an 0x9000). Der erwartete Wert der Checksumme (alle Bytes addiert, 16 Bit) steht an 0x9002 (das ist bei Dir 0x55C7). Es sollte also ausreichen den Wert an 0x9002 anzupassen wenn man etwas in dem Bereich 0x90D1 bis 0xFFFF ändert. Das Ganze ohne Garantie, das war nur schnell mal draufgeschaut.
Dieter S. schrieb: > Die Funktion 0x9D1B prüft die Checksumme des Bereich 0x90D1 bis 0xFFFF > (die Startadresse 0x90D1 steht dabei an 0x9000). Der erwartete Wert der > Checksumme (alle Bytes addiert, 16 Bit) steht an 0x9002 (das ist bei Dir > 0x55C7). > > Es sollte also ausreichen den Wert an 0x9002 anzupassen wenn man etwas > in dem Bereich 0x90D1 bis 0xFFFF ändert. Das Ganze ohne Garantie, das > war nur schnell mal draufgeschaut. Danke, das ist sehr hilfreich. So beschrieben hört sich das relativ schlüssig an und sieht auch in Ghidra plausibel aus. Die Funktion war bisher auch mein heißester Kandidat für die Checksummenberechnung, weil sie einer der ersten in der Hauptfunktion aufgerufenen Funktionen ist, einen Teil des Codes zur Versionsüberprüfung enthält und etwas mit einem festen Wert vergleicht, der ganz am Anfang vom ROM steht. Trotz Decompiler war ich aber bisher leider nicht in der Lage zu verstehen, was die Funktion genau macht. Sowohl der von Ghidra erzeugte C-Code, als auch der entsprechende Assemblercode erzeugen bei mir im Detail nur Fragezeichen, selbst wenn ich versuche das Ganze mit Stift und Papier durchzuspielen. Vermutlich ist mein Gehirn durch jahrzehntelange C und C++ Programmierung mit hier völlig unbrauchbaren Programmierparadigmen fehlkonditioniert. Was wäre denn eine gute Strategie mir selbst beizubringen wie man den von Dir identifizierten Code versteht? Oder war die Lösung hier einfach IDA Pro?
Denis F. schrieb: > Was wäre denn eine gute Strategie mir selbst > beizubringen wie man den von Dir identifizierten Code versteht? > Oder war die Lösung hier einfach IDA Pro? Ob Ghidra oder IDA Pro spielt keine große Rolle, man muß den jeweiligen CPU Befehlssatz einigermaßen verstehen (dafür gibt es Doku). Die Funktion bei 0x9D1B ist relativ einfach, zuerst wird die Checksumme des Haupt-ROM (U2) geprüft, dann in einer Schleife die einzelnen Bereiche von U29, die werden wohl in den Bereich 0x4000-0x7FFF eingeblendet wobei Adresse 0xB für das Einblenden des jeweiligen Bereichs zuständig ist. 0x9D48 prüft dann die Checksumme des Bereich, 0x9C1F ist für die Behandlung von Fehlern zuständig und wird mit unterschiedlichen Parametern aufgerufen, u.A. bei fehlerhaften Checksummen oder auch bei Fehlern im RAM Test. Das Listing ist die Funktion mit ein paar Kommentaren. Ob alles so stimmt wie geschrieben mußt Du selber am Gerät prüfen.
:
Bearbeitet durch User
Nachtrag: Die Prüfsumme bei den Bereichen (jeweils 0x4000 Bytes groß) in U29 ist die Summe (16 Bit) aller Bytes vom Anfang des jeweiligen Bereich bis zum Ende das im vorletzten 16-Bit Wort des Bereichs steht. Die Prüfsumme steht im letzten 16-Bit Wort des Bereichs. Beispiel erster Bereich U29: vorletztes 16-Bit Wort (Offset 0x3FFC im ROM Dump) ist 0x76D8, die Prüfsumme geht von 0x4000 bis einschließlich 0x76D8 (ab 0x4000 wird der Bereich eingeblendet) bzw. von Offset 0x0000 bis Offset 0x36D8 wenn man sich auf den ROM Dump bezieht. Das letzte 16-Bit Wort (Offset 0x3FFE im ROM Dump) ist 0x491C, das ist die Prüfsumme.
Dieter S. schrieb: > Ob Ghidra oder IDA Pro spielt keine große Rolle, man muß den jeweiligen > CPU Befehlssatz einigermaßen verstehen (dafür gibt es Doku). Ja, Doku habe ich jede Menge gelesen, aber wie ich heute herausgefunden habe ist mein Gehirn in der Anwendung immer wieder über die via 8-Bit emulierten 16-Bit Operationen und das richtige Berücksichtigen der ganzen Flags gestolpert. Insbesondere das Ignorieren des C-Dekompilats in Ghidra und ausschließliche Betrachtung der Assemblerbefehle bringt viel. Dank deiner wirklich sehr hilfreichen Eingebungen lichtet sich der Nebel langsam. Daher wundert mich im Checksummenalgorithmus nun auch, dass die Programmierer dort noch mit 8-Bit-Operationen summiert haben. Der 6809 unterstützt doch eigentlich schon 16-Bit-Addition. Ich habe dann mal eben ein kleines ROM-Prüfsummenkorrekturprogramm geschrieben und auf meinen früheren Patch für den ACIA Serial Controller angewendet(115200 statt 600 Baud). Nun futtert das 1504 das modifizierte ROM anstandslos und auch der Plot braucht statt 190 Sekunden nur noch 30. Dass es nicht noch schneller ist liegt daran, dass bestimmte Bytes einfach nicht in schnellerer Folge gesendet werden. Außerdem habe ich bei der höheren UART-Geschwindigkeit eventuell schon einen Übertragungsfehler entdeckt. Da muss ich nochmal debuggen, ob das eventuell schon zuviel Geschwindigkeit ist, oder das nur ein Schluckauf aufgrund momentan noch nicht finaler Verdrahtung ist. Dass 0xB die Adresse für das Memory-Paging von U29 ist, muss ich mir auf Hardwareseite nochmal genau ansehen. Das wäre ein Unterschied zum Gould 1604, wo das laut Doku in 0x9 passiert.
Denis F. schrieb: > > Dass 0xB die Adresse für das Memory-Paging von U29 ist, muss ich mir auf > Hardwareseite nochmal genau ansehen. Das wäre ein Unterschied zum Gould > 1604, wo das laut Doku in 0x9 passiert. Für die Page-Umschaltung ist vermutlich Andresse 0x0B und 0x09 verantwortlich. Wenn ich es richtig verstehe gibt es auch beim RAM verschiedene Bereiche. Die Funktion 0x9FE1 hat vermutlich etwas mit der Verwaltung der Bereiche zu tun, z.B. wenn ein Interrupt auftritt. Die Details habe ich mir aber nicht angesehen.
Denis F. schrieb: > ist mein Gehirn in der Anwendung immer wieder über die via 8-Bit > emulierten 16-Bit Operationen Das ist seltsam, weil der 6809 echte 16-Bit-Operationen mit dem Register D ausführen kann (das sich aus den beiden 8-Bit-Register A und B zusammensetzt). Denis F. schrieb: > Außerdem habe ich > bei der höheren UART-Geschwindigkeit eventuell schon einen > Übertragungsfehler entdeckt. Sollte dort Hardwarehandshake verwendet werden: der 6551 hat einen unappetitlichen Hardwarefehler, wenn dem via CTS das Senden abgeklemmt wird, hört er unmittelbar mitten im gerade übertragenen Byte auf, statt das noch zu Ende zu senden. Damit ist das übliche RTS/CTS-Handshake mit dieser ACIA/UART effektiv unbrauchbar. Ein alternativer Ansatz wäre ein Emulator, d.h. Du entfernst den Baustein aus seinem Sockel und bildest das Empfangs- und Sendedatenregister mit Latches o.ä. nach, die Du an einen (modernen) µC anschließt, und umgehst so die komplette Baudraten- und sonstwas-Mimik. Letztlich hat der 6551 vier Register, und das letzte davon ist für die Datenübertragung zuständig. Für vollständige und softwareagnostische Funktion müsstest Du bei Lesezugriffen auf die Register ISR und CSR (Interrupt- und Control-Status) ein sinnvolles Verhalten nachbilden. Wenn für die Plotteransteuerung kein Empfang von Daten nötig ist (da kein XON/XOFF verwendet wird), sondern Dein Oszilloskop nur senden soll, genügt es, im ISR die Bits 7 und 6 ("any bit" und TDRE) dauerhaft gesetzt zu halten, und im CSR Bit 6 und gegebenenfalls einige der unteren Bits für die Handshakeleitungen dauerhaft gesetzt zu halten. Sobald Dein µC in das Datenregister geschriebene Daten abgeholt hat, kann es an der Interruptleitung wackeln, und damit das komplette Protokoll steuern. Ich hab' das vor sehr langer Zeit mal mit einer Graphikterminalplatine gemacht, die ein Parallelinterface hatte, und an einem Computer betrieben werden sollte, der mit einer 6850 mit der Außenwelt kommunizierte. Die ist simpler aufgebaut als 6551 (der ganze Baudratenteilerkram fehlt), aber das Grundkonzept ist vergleichbar.
Harald K. schrieb: > Das ist seltsam, weil der 6809 echte 16-Bit-Operationen mit dem Register > D ausführen kann (das sich aus den beiden 8-Bit-Register A und B > zusammensetzt). Im Code des ROM wird das halt geflissentlich ignoriert. Da tauchen ständig Sequenzen wie ADDB ADCA auf. > Sollte dort Hardwarehandshake verwendet werden: der 6551 hat einen > unappetitlichen Hardwarefehler, wenn dem via CTS das Senden abgeklemmt > wird, hört er unmittelbar mitten im gerade übertragenen Byte auf, > statt das noch zu Ende zu senden. Damit ist das übliche > RTS/CTS-Handshake mit dieser ACIA/UART effektiv unbrauchbar. > > Ein alternativer Ansatz wäre ein Emulator, d.h. Du entfernst den > Baustein aus seinem Sockel und bildest das Empfangs- und > Sendedatenregister mit Latches o.ä. nach, die Du an einen (modernen) µC > anschließt, und umgehst so die komplette Baudraten- und sonstwas-Mimik. > Letztlich hat der 6551 vier Register, und das letzte davon ist für die > Datenübertragung zuständig. Für vollständige und softwareagnostische > Funktion müsstest Du bei Lesezugriffen auf die Register ISR und CSR > (Interrupt- und Control-Status) ein sinnvolles Verhalten nachbilden. > Wenn für die Plotteransteuerung kein Empfang von Daten nötig ist (da > kein XON/XOFF verwendet wird), sondern Dein Oszilloskop nur senden soll, > genügt es, im ISR die Bits 7 und 6 ("any bit" und TDRE) dauerhaft > gesetzt zu halten, und im CSR Bit 6 und gegebenenfalls einige der > unteren Bits für die Handshakeleitungen dauerhaft gesetzt zu halten. > Sobald Dein µC in das Datenregister geschriebene Daten abgeholt hat, > kann es an der Interruptleitung wackeln, und damit das komplette > Protokoll steuern. So, komplex musste ich an dieser Stelle gar nicht werden. Ich ziehe lediglich eine Leitung am Plotter-Interface auf Null auf der der echte Plotter Bereitschaft signalisiert(DSR am ACIA). Das reicht um dem Oszi beim Starten vorzugaukeln es, wäre ein Plotter da. Der ESP32 lauscht im Weiteren nur, was deshalb geht, weil es am Beginn und Ende der Plots eindeutige Sequenzen gibt auf die mein Logger entsprechend reagieren kann. Da das eine von mir innerhalb eines Plots detektierte fehlerhafte Byte ein 0xFF war, hatte ich zunächst den den Verdacht, dass meine höchst dilettantische Kopplung des 5.4V UART Signals an den ESP32 das Signal zu stark verfälscht, aber mit dem Oszi sieht das Signal vom Timing und den Signalflanken her sauber aus. Der ESP32 läuft zwar intern nur mit 3.3V, die Digitaleingänge(und nur die) sind aber heimlich 5V-tolerant und vertragen bis zu 5.5V. Das wird so nur nicht öffentlich gesagt, weil sonst viele "5V-tolerant" lesen und den ESP32 direkt frittieren, weil sie mit den 5V an Stellen gehen, wo die nichts zu suchen haben. Ich muss mir den Signalanschluss nochmal genau durch den Kopf gehen lassen. Als ich das gebastelt habe, habe ich erst mal nur sichergestellt, dass die Spannungen stimmen und die dabei auftretenden Source- und Sink-Ströme auf allen Seiten so klein wie möglich sind. Davon abgesehen funktioniert das Gesamtkonstrukt aber jetzt ganz brauchbar. Was ich nochmal durchdenken muss ist, ob die sehr selten auftretenden Empfangsfehler etwas damit zu tun haben können, dass es sich um ein NRZ-Signal handelt.
:
Bearbeitet durch User
Denis F. schrieb: > Im Code des ROM wird das halt geflissentlich ignoriert. Da tauchen > ständig Sequenzen wie ADDB ADCA auf. Das lässt annehmen, daß der Code ursprünglich nicht für 6809, sondern für 6800 geschrieben wurde. Auf Assemblerquelltextebene kann der 6809 auch Code für den 6800 ausführen (da die Opcodes geändert wurden, gibt es aber keine Binärkompatibilität). Die Möglichkeit, alten Quelltext weiterverwenden zu können, war auch damals schon wichtig, und der 6809 kam erst relativ spät zur Familie der 68xx-CPUs hinzu, so daß er eine große Codebasis nutzen konnte. Denis F. schrieb: > dass meine höchst dilettantische Kopplung des 5.4V UART > Signals an den ESP32 das Signal zu stark verfälscht 5.4 V? Da ist was faul. So ein Signalpegel kann aus einem 6551 gar nicht rauskommen, das ist kein CMOS-Baustein. Mit 5V versorgte (N)MOS-Logik schafft Highpegel irgendwo bei 3.6 V o.ä., aber niemals 5V. Oder beziehst Du Dich auf einen RS232-Treiber? (Falls einer da ist: Ich hab' ihn im Schaltplan nicht gesucht). Ich rate hier zu Widerstandsteilern, statt Dich auf undefiniertes Verhalten Deines ESP32 zu verlassen.
Harald K. schrieb: > Das lässt annehmen, daß der Code ursprünglich nicht für 6809, sondern > für 6800 geschrieben wurde. Auf Assemblerquelltextebene kann der 6809 > auch Code für den 6800 ausführen (da die Opcodes geändert wurden, gibt > es aber keine Binärkompatibilität). > > Die Möglichkeit, alten Quelltext weiterverwenden zu können, war auch > damals schon wichtig, und der 6809 kam erst relativ spät zur Familie der > 68xx-CPUs hinzu, so daß er eine große Codebasis nutzen konnte. Ah, soetwas in der Art hatte ich schon vermutet. > > 5.4 V? Da ist was faul. So ein Signalpegel kann aus einem 6551 gar nicht > rauskommen, das ist kein CMOS-Baustein. Mit 5V versorgte (N)MOS-Logik > schafft Highpegel irgendwo bei 3.6 V o.ä., aber niemals 5V. Wie ich aufwändig bei der Netzteilreparatur herausfinden musste, läuft im Gould 1504 die +5V Schiene lustigerweise tatsächlich per Design und entgegen der Dokumentation auf +5.4V. Das hat bei der 1600er Reihe schon einige andere Reparateure vor mir verwirrt, lässt sich aber eindeutig belegen. Ich kann aber heute Abend nochmal gerne genau nachmessen, was die TXD Leitung des 6551 ausspuckt.
Ich habe hier noch ein paar NOS G65SC51P-2 mit Datecode 8727 liegen. Falls die irgendwie hilfreich sein sollten gebe ich gerne welche gegen aufgerundetes Porto ab.
Dieter W. schrieb: > Ich habe hier noch ein paar NOS G65SC51P-2 mit Datecode 8727 liegen. > Falls die irgendwie hilfreich sein sollten gebe ich gerne welche gegen > aufgerundetes Porto ab. Hallo, und danke für das Angebot. Da der G65SC51P-2 dem ACIA 6551 ja ziemlich ähnlich ist, hilft er an dieser Stelle nicht wirklich - einen funktionierenden Sender habe ich ja schon und den Empfangsteil übernimmt bei mir der ESP32.
Denis F. schrieb: > Ich kann aber heute Abend nochmal gerne genau nachmessen, was > die TXD Leitung des 6551 ausspuckt. Habe mir die Signalleitung eben nochmal genau angesehen. Unbelastet gibt der ACIA 6551, wie vermutet, ein 5.4V Signal aus. Bisher hatte ich dort einen 10kΩ Spannungsteiler hingebaut mit dem ich die Signalspannung in ESP32-taugliche Bereiche gebracht habe, da flossen dann etwa 0.5 mA. Mit einem 20kΩ Spannungsteiler nur noch etwa 0.2 mA. In beiden Fällen sahen die Signale auch durch den Spannungsteiler belastet sauber aus. Gut zu sehen war, dass die Bytes mit 115200 Baud wesentlich schneller gesendet werden, als die Byteübertragungsfrequenz es nötig macht. Nun verwirrt mich, dass gestern die Fehler, welche in zusätzlich erkannten 0xFF Bytes bestehen, nur sehr sporadisch auftraten. Heute sind die Plots geradezu verseucht davon. Ich hatte zunächst schlechte Verbindungen oder Störsignale in der Nähe der Leitung im verdacht, konnte aber nichts entsprechendes finden. Jetzt muss ich mal schauen, ob ich die Fehler irgendwie auch mit dem Oszi sehen kann, wenn nicht ist es vielleicht ein Timingproblem auf Empfangsseite. Vielleicht versuche ich einfach mal ein ROM zu bauen, was nur mit 19200 Baud sendet.
:
Bearbeitet durch User
Mittlerweile konnte ich meine Übertragungsfehler auf ein Problem mit der Serial.available - Funktion des ESP32 zurückführen und einen funktionierenden Workaround finden. Mit Hilfe der tollen Tipps von Dieter konnte ich auch ermitteln, warum mich der C-Code des Ghidra Decompilers bisher immer so verwirrt hat: in Ghidras Sprachdefinitionen für den 6809 scheinen einige recht zentrale Fehler bezüglich der Auswertung der Flags drin zu sein. Infolgedessen wird völlig falscher Code produziert. Ich werde mal versuchen, ob ich das unter Verwendung der MC6809 Befehlsreferenz beheben kann und das Resultat dann in Richtung des git-Repos von Ghidra wandern lassen.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.