Making of – Amiga Dateiübertragung
Im letzten Artikel zur PC – Amiga Dateiübertragung habe ich ja bereits gezeigt zu welcher Lösung ich nach 3 Wochenenden gekommen bin. Der Weg war hart, ich habe sicher alles falsch gemacht was man falsch machen kann. Ich habe in diesem Artikel alles dokumentiert woran ich gescheitert bin. Sollte mein erster Artikel euch noch nicht auf die Lösung gebracht haben, dieser Artikel beinhaltet nun wirklich die gesamte Information.
Making of – Amiga Dateiübertragung
Der wohl am härtesten recherchierte Artikel meines Lebens bekommt würdig ein Making of. Daten senden über eine serielle Schnittstelle ist gar nicht so schwer. Obwohl ich das vor vielen Jahren sogar noch in der Schule gelernt hatte ist es mir doch sehr schwer gefallen eine funktionierende Lösung zu finden. Man ist heute durch Plug and Play USB und Co verwöhnt. Man vergisst welche Technologie und Protokolle im Hintergrund laufen. Ein Grund mehr, warum die Beschäftigung mit vintage computing neben einem spannenden Hobby auch sehr lehrreich sein kann.
Das Scheitern (Woche 1)
Meinen ersten Testlauf habe ich mit einer USB-Seriell Adapter Platine gemacht. Die war recht günstig und schien wegen der Schnittstelle auch für spannende Raspberry Pi Projekte geeignet zu sein. Nachträglich kann ich diese für den Retro Einsatz nicht empfehlen (die Stärken des Boards liegen offenbar wo anders). Mir haben an der Platine die offenen Schnittstellen gefallen. Mit ein wenig Dokumentation und Zeit kann man da sicher auch recht gut die Daten am Raspberry Pi über GPIO abgreifen.
Meine ersten Dateien wurden problemlos übertragen. Damals habe ich die Standardwerte der seriellen Schnittstelle verwendet (ich hatte keine Ahnung von den Möglichkeiten). Eines der ersten Probleme war die falsche Dateigröße. Ich habe die Datei mit dem bereits erwähnten receive.bas Skript übertragen. Das lha Programm war aber am Amiga 500 nicht lauffähig (obwohl die korrekte Version von AmiNet). Ein nicht ganz übertragenes Programm wird mit der Fehlermeldung „file is not an object module“ beendet. Das ist ärgerlich. Es gibt im Internet zwar ein paar Referenzen dazu, dort wird aber nur erklärt, dass man eventuell das e (für execute) Bit setzen muss. Ein
1 | protect lha.run +e |
führte zu keiner Lösung. Anbei einige Screenshots meiner Versuche. Zu diesem Zeitpunkt war ich mir sicher, die Datei wurde falsch übertragen. Meine erste Vermutung war das deaktivierte RTS/CTS Handshake. Ich habe das unter Linux auch probiert, da wurden aber nie Daten gesendet. Ich vermutete das Problem am Kabel beziehungsweise am Betriebssystem. Was also machen?
Wir ändern das Setup (Woche 2)
Vielleicht war das Linux Dateisystem schuld an der kaputten Datei. Eventuell auch der Umweg der seriellen Übertragung über den USB Anschluss. Ohne das je zuvor korrekt getestet zu haben blieben mir kaum Alternativen. Ich ging also den beschwerlichen Weg und tauschte die Sender Hardware komplett aus. Anstatt vom Raspberry Pi über USB zu senden habe ich einen uralten Laptop mit Windows XP herangeschafft mit einer echten seriellen Schnittstelle. Mit einem Mal hatte ich beide vermuteten Fehlerquellen ausgeschaltet, es musste einfach funktionieren.
Wie üblich hatte ich keine Ahnung wie man unter Windows Daten über die serielle Schnittstelle schickt. Auch wusste ich nicht wie man die Schnittstelle ändert. Nach einiger Recherche habe ich das so gemacht:
Die korrekte Einstellungen für die Schnittstelle eingegeben:
1 | mode COM1 BAUD=9600 PARITY=n DATA=8 OCTS=ON |
Wichtig war, dass die Tabelle die Daten wie im Bild zu sehen ausgibt.
Eine beliebige Datei kann dann mit folgendem Befehl übertragen werden:
1 | copy lha.run \\.\COM1 |
Im Screenshot steht ein anderer Dateiname. Mittlerweile war ich so verzweifelt, dass ich sogar schon andere Programme und Archive übertragen habe.
Die Screenshots zeigen, dass ich das RTS/CTS Handshaking aktiviert hatte. Irgendwo habe ich zu diesem Zeitpunkt gelesen, dass es ohne nicht funktioniert. Ohne USB Adapter hat das auf Anhieb funktioniert. Leider habe ich aber nicht mit dem receive.bas Skript am Empfänger gearbeitet (damit hätte es sicher funktioniert) sondern mit der seriellen Schnittstelle direkt. Ich habe am Amiga 500 in der Shell die übergebenen Daten direkt in die Datei geschrieben:
Auch bei dieser Methode muss der Sender eine Datei doppelt schicken. Nachdem die Datei komplett übertragen wurde drückt man am Amiga in der Shell CTRL+C und startet die Übertragung ein zweites Mal. Es erscheint sofort „**BREAK“ weil der Buffer voll ist. Leider war die übertragene Datei immer um die paar Bytes aus dem letzten Buffer zu klein und damit kaputt.
Neues Kabel (Woche 3)
Mein letzter Rettungsanker war ein neues Kabel. Ein USB-Seriell Kabel (ohne Adapterplatine). Das habe ich mir extra neu zugelegt nachdem ich nach kompatibler Hardware gesucht hatte. Damit funktioniert die RTS/CTS Einstellung auch am Raspberry Pi. In einem interessanten Forum habe ich zur Fehleranalyse folgende 4 Punkte kennengelernt:
- als erstes muss man sichergehen, dass man das richtige Kabel hat. Auf dem Kabel muss irgendwo Null-Modem stehen. Falls nicht hilft der Beschreibungstext auf der Packung.
- ein relativ häufiger Fehler ist, dass man Daten an den falschen COM Port schickt. Unter Windows muss man dazu nachschauen ob COM1 default ist.
- Kabeltest. Dafür stellt man die Daten der Schnittstelle auf:
9600 Baud, 8 Daten Bits, kein Parity, 1 Stop Bit, kein Handshaking
und schickt nur einzelne Zeichen über die Schnittstelle. Auf der anderen Seite sollten diese Zeichen ausgegeben werden. - Handshaking. Das letzte Problem ist das Handshaking. Funktioniert der unter 3 gezeigte Schritt auch mit Handshaking ist alles ok, falls nicht unterstützt das Kabel (oder wie bei mir der Adapter) diese Funktion gar nicht.
Ich habe Punkt 3 bestanden, Punkt 4 nicht. Punkt 3 funktioniert so:
Linux: echo „Hallo Text“ > /dev/ttyUSB0
Amiga: type SER:
Man muss den Linux Befehl mehrere Male ausführen. Sobald der Buffer voll ist wird die Shell am Amiga mit den Hallo Texten vollgeschrieben. Die Lösung war zuletzt eine Kombination aus korrektem Kabel, Übertragung mit Handshaking und receive.bas um die fehlenden Bytes aus dem Buffer in die Datei zu schreiben. Wow.
Mein neues Lieblingskabel:
Fazit
Nach 3 Wochenenden müsste es mir peinlich sein, dass ich mehrmals knapp dran war und nur durch Blödheit die Lösung nicht schneller gefunden habe. Mir ist um die Zeit nicht leid. Immerhin habe ich recht viel dazu gelernt und die Übertragung mit mehreren Möglichkeiten und sogar zwei unterschiedlichen Sender Systemen (Linux und Windows) durchgeführt. All diese gelernte Information ist euch hoffentlich bei eurer Fehlersuche nützlich. Falls ja dürft ihr gerne einen Kommentar schreiben. Solltet ihr trotzdem noch Probleme haben, dann bitte ich um eure Fragen. Ich sollte euch allen die Lösung verraten können.