Hallo! Ich habe hier einen 6809 Computer der für eine maschinelle Steuerung verwendet wurde. Der Code aus den Eproms liegt in disassemblierter Form vor. Weiterhin sind die Schaltpläne vorhanden. Ich habe leider nur rudimentäre Kenntnisse in 6809 Assembler-Code und suche jemand der mir - gegen Bezahlung - hilft den Code zu verstehen um ihn auf Arduino zu portieren. Den fachlichen Background der Ansteuerung kann ich beisteuern. Wer kann hier helfen? Gruss Harald
:
Verschoben durch User
Harald Konrad schrieb: > Der Code aus den Eproms liegt in disassemblierter Form > vor. Das ist heftig viel Arbeit, weil so ein Disassembler nicht erkennt, ob eine Tabelle mit Texten oder sonstigen Konstanten eben eine solche Tabelle ist, er wird versuchen, die in Assemblerbefehle zu übersetzen, was natürlich kompletten Quark liefert ... Wie groß ist/sind denn das/die EPROM(s)? Ob es möglich ist, die Steuerung mit einem Arduino nachzubilden, hängt davon ab, was als Peripherie am '09 angeschlossen ist. Zwar mag einem die Taktfrequenz, mit der der 6809 getaktet wird (1 oder 2 MHz, was einen 4- oder 8-MHz-Quarz bedingt), gering erscheinen, dafür aber kann hat der durchaus einiges an Rechenleistung; der '09 beherrscht 16-Bit-Arithmetik (und wenn es die CMOS-Variante von Hitachi namens 6309 ist, dann sogar, wenn auch nie offiziell dokumentiert, sogar 32-Bit-Arithmetik). Ich habe weder die Zeit dafür noch willst Du mich dafür bezahlen, Dir Dein Disassemblat in eine verständliche Form zu bringen, aber ich kann mir Deinen Schaltplan ansehen, und eine Bauch-Einschätzung abgeben, ob eine Chance besteht, das dort umgesetzte mit einem AVR umzusetzen.
Harald Konrad schrieb: > Den fachlichen Background der Ansteuerung kann ich beisteuern. Dann solltest du dir überlegen ob es nicht sinnvoller ist die Steuerung einfach neu zu programmieren, statt die alte zu disassemblieren. Hast du denn ein komplettes Lastenheft oder kannst eins erstellen?
Wenn der 6809-Code auf exakte Laufzeit von Befehlssequenzen getrimmt ist, dann steht vor der Umsetzung des Codes erst einmal das exakte Verständnis der kontrollierten Hardware.
Ich kenne den 6809-Code noch. Das übertragen des Codes, auch des Assemblertextes ist praktisch nicht möglich, da die 6809-CPU Adressierungen verwendet, welche der Arduino (RISC) einfach nicht kennt. Wenn die Hardware und die Funktionen bekannt sind, dann empfehle ich das Neuprogrammieren. Joe
Joe schrieb: > Das übertragen des Codes, auch des Assemblertextes ist praktisch nicht > möglich, da die 6809-CPU Adressierungen verwendet, welche der Arduino > (RISC) einfach nicht kennt. Wenn von Arduino die Rede ist, gehe ich davon aus, daß die Algorithmen in eine Hochsprache übersetzt werden sollen, denn sonst könnte ja auch gleich von AVR geredet werden. Andererseits: Nur weil der 6809 sehr komplexe Adressierungsarten kennt, bedeutet das nicht, daß die Software diese auch nutzt; das könnte auch eine simple Portierung von Code für den älteren 6800 sein. Wird statt des AVR ein leistungsfähigerer µC verwendet (irgendein Cortex-ARM), dann könnte natürlich auch ein 6809-Emulator verwendet werden ...
Joe schrieb: > Das übertragen des Codes, auch des Assemblertextes ist praktisch nicht > möglich, da die 6809-CPU Adressierungen verwendet, welche der Arduino > (RISC) einfach nicht kennt. Das wäre nur dann ein Problem, wenn die Befehle 1:1 umgesetzt werden müssten. Ansonsten lässt sich selbsverständlich alles portieren. Das Programm wird dann halt etwas länger. Oliver
Joe schrieb: > Ich kenne den 6809-Code noch. > > Das übertragen des Codes, auch des Assemblertextes ist praktisch nicht > möglich, da die 6809-CPU Adressierungen verwendet, welche der Arduino > (RISC) einfach nicht kennt. Natürlich kann man nicht für einem 6809 Befehl einen einzelnen Ersatzbefehl setzen. Aber wenn einen viel schnelleren Prozessor und genug Platz im ROM zur Verfügung hat, dann kann man sich Makros basteln, die den Löwenanteil abdecken. Bissel mitdenken ist an anderer Stelle angesagt: bei den Flags und bei der Bytereihenfolge. So hat 68xx ein echtes Borrow, AVR ein invertiertes. Und 68xx ist big endian, AVR little endian.
:
Bearbeitet durch User
A. K. schrieb: > Aber wenn einen viel schnelleren Prozessor und > genug Platz im ROM zur Verfügung hat, dann kann man sich Makros basteln, > die den Löwenanteil abdecken. Bleibt die Frage, ob ein AVR tatsächlich signifikant schneller ist als ein 6809. Zu bedenken ist auch, daß der 6809 16-Bit-Arithmetik unterstützt, also auch über 16-Bit-Daten-, Adressierungs- und Indexregister verfügt. Und es bleibt die Frage nach der genutzten Peripherie. Daher: Wo bleibt der Schaltplan oder wenigstens ein Bild der Elektronik?
Rufus Τ. Firefly schrieb: > Bleibt die Frage, ob ein AVR tatsächlich signifikant schneller ist als > ein 6809. 6809: 1-2MHz, Laufzeit der meisten Befehle 2-7 Takte. Bei einem 1MHz 6809 hat ein 20Mz AVR also 40-140 Takte Zeit, um einen einzelnen 6809 Befehl abzuarbeiten.
:
Bearbeitet durch User
Blöde Frage: Warum willst Du den 6809-Code portieren? Wenn die Funktionalität passt und "nur" die alte Hardware defekt ist (oder Du davor Angst hast): Den 6809 kann man heute noch recht problemlos bekommen. Ggf. reparieren und Ersatzteile für alle obsoleten oder obsolet-werdenden Teile auf Lager legen. Nach 30 Jahren dürften alle Macken der vorhandenen Software bekannt sein - so robust ist eine neue Software erstmal nicht. Wenn Du neue Funktionalität brauchst: Programmier's neu. Das dürfte (sofern die Ansteuerung höchst esoterischer, undokumentierter Komponenten geht) fast immer günstiger und schneller sein als das portieren mit nachgelagerter Anpassung.
A. K. schrieb: > 6809: 1-2MHz, Laufzeit der meisten Befehle 2-7 Takte. Bei einem 1MHz > 6809 hat ein 20Mz AVR also 40-140 Takte Zeit, um einen einzelnen 6809 > Befehl abzuarbeiten. Ja. Schon. Nur immer schön daran denken, daß auch 16-Bit-Arithmetik im Spiel sein kann. Und 6809 konnten durchaus auch mit 2 MHz betrieben werden (die schicke CMOS-Version von Hitachi gab es sogar als 3-MHz-Ausführung). Noch aber wissen wir nichts weiter über die Hardware, die da ersetzt werden soll.
Hallo! Vielen Dank erst mal für die vielen Antworten. Hätte ich ja nie gedacht in so kurzer Zeit. Eine Wahnsinns-Community hier! Es geht nicht darum Code 1:1 zu portieren sondern die Funktionen des Programms zu verstehen - Subroutinen zu erkennen, Wie funktioniert die I/O? Wo liegen Datenblöcke und wie sind sie aufgebaut? etc. Das wäre der erste Schritt um den es mir erst mal ausschließlich geht und wo ich Hilfe brauche. Also brauche ich jemand der Ahnung hat von 6809 Assembler. Mir geht es auch nicht darum eine defekte Maschine wieder zum Leben zu erwecken sondern einer Maschine eine neue zeitgemäße Steuerung zu verpassen. Viel später dann soll das ganze komplett neu programmiert werden - geplant ist ein Arduino in Kombination mit einem Gameduino 2 um die grafische Benutzeroberfläche mit Touchsteuerung zu haben. Es handelt sich um eine Strickmaschine. Die Ausgabe erfolgte damals auf einer 7-Segment-Anzeige und mit minimalistischer Tastatur. I/O erfolgte über einen 6821A. Das Eprom ist 32K - aber einen Grossteil kann man wohl zügig ausklammern. Schaltpläne kann ich hier leider im Forum nicht veröffentlichen da ein Copyright drauf liegt und ich denjenigen noch nicht erreicht habe. Das ganze ist schon eine heftige Herausforderung aber evtl. hat ja jemand Lust darauf. Spannend ist es allemal.
Rufus Τ. Firefly schrieb: > Ja. Schon. Nur immer schön daran denken, daß auch 16-Bit-Arithmetik im > Spiel sein kann. Herrje - für wie teuer hältst du die? Jedes Bit einzeln?
Meines Erachtens kommt ein komplettes Neuschreiben resp. Re-enginering besser als eine Portierung aus Disassebmler. Also Scope an Ein/Ausgänge, die Eingabelogik und die Aktorenansteuerung verstehen und das Ganze from the scratch neu machen. Andernfalls erbt man die alten Fehler und Krücken aus den Widrigkeiten der damaligen Softwareentwicklung. Servus,
Jemand muß dazu die ganze Hardware und Gerätefunktion im Detail kennen, und auch den 6809-Assembler noch präsent in Erinnerung haben. Denn es ist ja nicht nur die reine Software. Es sind ja da oft hardwareabhängige bedingte Sprünge drin, wie z.B. Jump if Pin x.y = Low. Mit einem Simulator kommt man da auch nicht immer ans Ziel. Also es ist harte Arbeit, nicht nur drei Tage, wenn ein Code etwas größer ist, wenn auch nur 3kB. Die ganze Doku und Quelltextinfo ist ja im Disassemblat gar nicht mehr vorhanden. Gelegentlich gibt es hier ähnliche Anfragen, z.B. 8051-Code, aber das führt meistens zu keiner Endlösung. Man kann ein Re-Engineering machen, aber ich würde mich sogar fast noch davor sträuben, für ein Gerät, was ich selbst vor Jahren erstellte. Wie ein Elefant, der vom 10m-Turm in ein halb abgelassenes Becken springen soll. Ich denke, daß man da in der Größenordnung ab z.B. 5k€ Entlohnung (Bauchgefühl) jemanden suchen kann, der bereit ist, es zu machen. Und dafür kann man überlegen, ob man es nicht ganz neu macht. Da ich selbst mal in der Entwicklung war: Es war oft schon schwer und haarsträubend, für ein kleines Gerät auch in den fremd geschriebenen Quellcode einzusteigen. Wie muß das da erst bei Disassemblercode sein? Gibt es keine Möglichkeit, noch irgendwie an den Ursprungsprogrammierer heran zu kommen? Dann bezahlt man den halt.
Nachtrag: Oft kann man Assemblercode nach C portieren. Dafür braucht aber auch einer 6809-Kenntnisse. Ob man dann leichter damit zurecht kommt, weiß ich nicht.
Ja so ein dokumentierter Assembler-Code wäre eine feine Sache - aber leider unmöglich. Die Firma existiert seit 1998 nicht mehr und da kommt man an keine Informationen ran. Ich will auch nicht bis ins letzte Byte abtauchen, sondern nur die wichtigsten Routinen lokalisieren, das interne Datenformat verstehen (um es zu portieren) sowie die I/O Funktionen Und ja, man muss das Memory-Layout verstehen - aber Schaltpläne sind ja gottseidank da. Wer Lust hat kann mir ja schreiben unter harald@hiddestorf.net
Genau sowas darf ich momentan machen. Und dies unter erschwerten Bedingungen des Lärms am Arbeitsplatz. Zufällig kenne ich mich mit dem Prozessor aus, weil ich füher damit viel gemacht habe. Ich stimme allerdings den Vorrednern zu, dass ohne Kenntnis der Prinzipabläufe eine Rekonstruktion der SW viel aufwändiger wird, als das Neuschreiben. ASM der in C übersetzt wurde, ist auch nicht unbedingt effektiv. Sowas wird in jedem Fall teuer, als die 5k :-) und lohnt nur, wenn man kleine Änderungen gemacht werden sollen. Der Code wie gesagt lässt sich ja nicht direkt portieren und muss neu verfasst werden. Da würde man als Ausgangsbasis aber nicht einen halbverstandenen reengineered code sondern einfach eine Anforderungsspec hernehmen.
ASM-Entwickler schrieb: > ASM > der in C übersetzt wurde, ist auch nicht unbedingt effektiv. Ein moderner ARM arbeitet C compilierten Code oft schneller ab, als ein Ur-8051 oder hier 6809 das in Assembler machte. Das sollte kein großes Problem sein. Allerdings muß man Assembler dann mal nach C portieren, und das geht genau ohne Schaltplan, rein in der Software. Gute Kenntnisse in Struktogrammen und Programmablaufplan sind für eine Portierung hilfreich.
Der vorhandene Code ist nicht der heilige Gral - besser gesagt er ist eher Müll aus heutiger Sicht - ich sage nur 8stellige Segmentanzeige und eingebaute Tastatur mit 15 Tasten ... deshalb soll ja alles neu geschieben werden - aber nicht 1:1 sondern neu durchdacht. Dazu ist es eben notwendig bestimmte dinge im vorhandenen Code zu verstehen - nicht mehr - erst mal. Grundlage ist aber das Verstehen der I/O Prozesse, der Fehlermeldungen, das Datenformat der eingespeicherten Muster etc.
ja die 68xx haben -wie geschrieben- auch komplexere Befehle, aber 1. sind die langsamer getaktet und 2. brauchen sie dafür sehr viele Takte. Mit AVR sollte das, sogar mit Luft drin, auf jeden Fall machbar sein. Aber es gibt ja nicht nur AVR (oder?), sondern auch aktuell noch Akku-Masch, mit denen man das umsetzen könnte. ..oder das Progr. gleich ganz neu machen.
>Oft kann man Assemblercode nach C portieren.
portieren kann man das schon gar nicht, weil es völlig unterschiedliche
Ebenen sind.
Man kann höchstens aus vorliegendem ASM versuchen zu 'ermitteln' oder zu
'erraten', was jemand in einer Hochsprache hätte schreiben können, was
dann zu dem vorl. ASM führen könnte; - was extrem viel Aufwand sein
dürfte.
Ein Elektroniker schrieb: > Allerdings muß man Assembler dann mal nach C portieren, > und das geht genau ohne Schaltplan, rein in der Software. Nein. Tut es nicht, weil ohne Schaltplan nicht klar ist, welche Adresse welche Bedeutung hat. Ein 6809 ist kein µC, bei dem die Peripherie an festgelegten Adressen in standardisierter Form zur Verfügung steht, sondern das ist ein Prozessor, der --außer der fest vorgegebenen Adresse für Reset- und Interruptvektoren-- überhaupt keine Vorgaben über Speicherbelegung, I/O-Adressen etc. macht. Die aber muss man kennen, möchte man das Disassemblat in irgendwas les- und nachvollziehbares übersetzen.
>>Das Eprom ist 32K - aber einen Grossteil kann man wohl zügig >>ausklammern. >Dazu ist es eben notwendig bestimmte dinge im vorhandenen >Code zu verstehen - nicht mehr - erst mal. Heutzutage mag ein 32KB Programm als Trivialitaet erscheinen, aber unterschaetze nicht, was Programmierer in den 80er alles in 32KB unterbrachten, insbesondere dann, wenn Assembler verwendet wurde. Aehnlich ist es bei Datenstrukturen, da damals jedes Bit kostbar war... -> Kannst Du den Eprominhalt auslesen und hochladen? -> Welche Peripherie (6821, 6850,...)ist auf dem Board? -> Kannst Du den Schaltplan "lesen" und aus den Adressdekodern eine Beschreibung der Anschluesse generieren? Das waere eh der naechste Schritt, um ein IO/memory layout zu generieren. Also etwas sowas wie: 0x0000-0x7fff ist ein 32KB SRAM Baustein (z.B.) An 0x8abc ist ein 6821 Datenregister, Bit 0 ist der Motor-Seite-links-unten-quer-schraeg, Bit 1 ist die Photodiode, um festzustellen, dass die Rueckholgeschichte an der Initialposition ist, etc. Nach dieser Analyse/Dokumentation ist der Schaltplan dann eine nette Referenz, aber nicht mehr kriegsentscheidend. -Tiramisu PS: Eurocom-II rulez! SCNR!
Tiramisu schrieb: > aber unterschaetze nicht, was Programmierer > in den 80er alles in 32KB unterbrachten, Komplette Betriebssyteme. Für den 6809 unvergessen bleibt OS-9 von Microware, das ist ein Echtzeitmultitaskingbetriebssystem. (Das wurde dann später unter dem Namen OS-9/68k auf den 68k portiert, und noch später als OS-9000 auch auf PC-Hardware genutzt, mit dann allerdings eher überschaubarem Markterfolg).
Ja genau - das ist der erste Schritt. Schaltplan interpretieren und "übersetzen" so wie beschrieben damit klar ist wie welche Peripherie angesprochen wird unter welcher Adresse etc. Auch dafür brauche ich Hife. der I/O Baustein ist ein 6821a - hatte ich oben geschrieben ... Tiramisu schrieb: >>>Das Eprom ist 32K - aber einen Grossteil kann man wohl zügig >>>ausklammern. > >>Dazu ist es eben notwendig bestimmte dinge im vorhandenen >>Code zu verstehen - nicht mehr - erst mal. > > Heutzutage mag ein 32KB Programm als Trivialitaet > erscheinen, aber unterschaetze nicht, was Programmierer > in den 80er alles in 32KB unterbrachten, insbesondere dann, > wenn Assembler verwendet wurde. Aehnlich ist es bei > Datenstrukturen, da damals jedes Bit kostbar war... > > -> Kannst Du den Eprominhalt auslesen und hochladen? > -> Welche Peripherie (6821, 6850,...)ist auf dem Board? > -> Kannst Du den Schaltplan "lesen" und aus den Adressdekodern > eine Beschreibung der Anschluesse generieren? Das waere > eh der naechste Schritt, um ein IO/memory layout zu generieren. > Also etwas sowas wie: > 0x0000-0x7fff ist ein 32KB SRAM Baustein (z.B.) > An 0x8abc ist ein 6821 Datenregister, Bit 0 ist der > Motor-Seite-links-unten-quer-schraeg, Bit 1 ist die > Photodiode, um festzustellen, dass die Rueckholgeschichte > an der Initialposition ist, etc. > Nach dieser Analyse/Dokumentation ist der Schaltplan dann eine > nette Referenz, aber nicht mehr kriegsentscheidend. > > -Tiramisu > > PS: Eurocom-II rulez! SCNR!
Ja, der EPROM Inhalt habe ich ausgelesen - das war ja die Grundlage für den disassemblierten OP-Code den ich habe.
Als nächstes solltest du das Datenblatt lesen. Nach dem Reset holt sich der Prozessor auf den Adressen FFFE und FFFF die Startadresse. Darunter stehen die Startadressen der Interrupts. Siehe Seite 9: http://bitsavers.trailing-edge.com/pdf/motorola/_dataSheets/6809.pdf Die Werte im EPROM die in diesen Adressen stehen geben an wo du den Disassembler ansetzen musst. Ein Simulator wäre da beim Disassemblieren sicher sehr hilfreich.
Harald Konrad schrieb: > Ja genau - das ist der erste Schritt. > > Schaltplan interpretieren und "übersetzen" so wie beschrieben damit klar > ist wie welche Peripherie angesprochen wird unter welcher Adresse etc. > Auch dafür brauche ich Hife. Wenn da ein paar 74138 sind oder andere einfache Gatter, geht es einfach. Hast du eine programmierbare Logik im Adressdecoding (PAL), wird es 'lustig' Helmut S. hat es ja schon angesprochen: Wie hast du das Disassembling gemacht? Am Anfang vom EPROM angefangen oder intelligent anhand des Resetvektors?
Verbaut sind: 74LS393N, 74LS10N, 74LS04N, 74LS165, 74LS05B1 und 58341N zur Display-Ansteuerung Disassembling hatte ich über den ganzen EPROM Inhalt gemacht - aber der Reset-Vektor zeigt auf dsa richtige Byte (OP-Code) - also das sieht gut aus im Textoutput des Disassemblers
Es ist wirklich die Frage, ob der alt Code hilft die Hardware zu verstehen, oder ob man die Hardware nicht ggf. auch rein aus dem Schaltplan leichter verstehen kann. Auch mit dem Code hat man das Problem das man die IO Zugriffe den Leitungen zuordnen kann. Es ist dann auch noch die Frage wie viel der alten HW soll erhalten bleiben. Für das eigentliche Programm ist vermutlich eine komplette Neuentwicklung einfacher als den alten ASM Code zu verstehen. Es kann auch gut sein das man neu deutlich mehr als 32 K braucht, weil man nicht in ASM, sondern C schreibt. Auch war der 6809 soweit ich weiß recht Effizient mit der Codegröße - der AVR braucht für die gleiche Funktion da vermutlich mehr Code. Vom Tempo her sollte es ausreichen - das RAM im AVR könnte aber knapp werden.
Harald Konrad schrieb: > Verbaut sind: 74LS393N, 74LS10N, 74LS04N, 74LS165, 74LS05B1 und 58341N > zur Display-Ansteuerung Und kein RAM?
Der Elektronik-Part der in der Strickmaschine ist bleibt erhalten (Musterselektion / Positionsbestimmung) - deshalb ist es auch wichtig die Ansteuerungsprozesse zu verstehen. Der Arduino Due hat 96KB SRAM - das sollte reichen auch mit gameduino 2 library - denke ich mal.
es gibt zwei RAM Versionen der Maschinen: 8K und 32K EPROMS sind 2x 32K EPROMS drauf - (Programm und Muster) wobei ich mir nicht sicher bin ob der gesamte Adressraum beider EPROMS genutzt wird und ein Memory-Banking stattfindet oder ob nur ein Teilbereich jeweils angesprochen wird. Dafür muss ich erst das Datenformat des Mustereproms und die Adressselektionsmechanismen verstehen. Kann gut sein dass in der Maschine die ich habe die EPROMS nachträglich upgedated wurden und vorher kleinere EPROMS drinnen waren.
Ich kenne mich mittlerweile mit den Innereien eines 6809 aus, weil ich einen Emulator in Python dafür geschrieben habe bzw. schreibe: https://github.com/jedie/DragonPy Aber ich kann mich den Vorrednern nur anschließen, ich denke man braucht viel, viel Zeit, um das ROM zu verstehen... Dabei ist der 6809 wahrscheinlich weniger das Problem. Dazu gibt es ein haufen Daten im Netz. Der Prozessor wurde und wird z.B. im Universitären Umfeld in Vorlesungen genutzt... Viel mehr wird die Peripherie Rätsel aufgeben und dazu wird sich vermutlich nicht wie mehr finden, als die Blanken Datenblättern, wenn überhaupt...
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.