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
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.
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.
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!
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.
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...
