Gelöst: Serielle Schnittstelle mit Falcon auf Hatari 2.5.0 und EMUTOS 1.2.1

[Chocco]

Ich habe heute echt lange an der seriellen Schnittstelle gefummelt, aber in der Falcon Emulation bekomme ich sie nicht stabil ans laufen.
In der Doku wird empfohlen, den SCC Kanal B zu verwenden, aber da schnubbeln immer nur ein paar Zeichen durch und dann hängt das Teil. Das aktuelle RUFUS meckert in der Doku über die Falcon Schnittstellen und rät zur Verwendung von HSMODEM. Wenn die Emulation nicht ordentlich arbeitet, dann sollte eine andere Software wohl kaum ein Wunder vollbringen? Wenn die Emulation auf TT umgeschaltet wird, funktioniert die Emulation der Ports wunderbar. In dem Fall kann ich aber die erweiterten VIDEL-Auflösungen nicht verwenden.

Hat jemand Erfahrungen mit den seriellen am Falcon über Hatari und kennt vielleicht eine Lösung?

Grüße

[czietz]

Nutzt Du denn auf dem TT auch die SCC-Ports oder die MFP-Ports?

M.W. ist die Hatari-Emulation des SCC alles andere als vollständig. Andererseits wurde an der SCC-Emulation in den letzten Monaten eifrig gearbeitet. Verbessert sich die Situation, wenn Du einen aktuellen Build von Hatari statt des 2.4.1er Releases verwendest?

[Chocco]

In der TT Emulation verwende ich die "normale" Modem 1 Schnittstelle "--rs232-in und --rs232-out" und die funktioniert ganz prima auch mit 19200. Habe ein HW-Terminal zum testen drangehängt.

Die Hatari 2.5.beta liegt im Download nur für Windows vor. Ich baue mir die Version immer aus des Sourcen und dann für den 64Bit Raspberry. Habe leider keine Windows Maschine.

[czietz]

Ich baue mir die Version immer aus des Sourcen und dann für den 64Bit Raspberry.

Okay, d.h. Du nutzt kein Hatari 2.4.1, sondern eine Version, die Du aus dem aktuellen Git-Stand von heute frisch gebaut hast? Dann wären die Verbesserungen am SCC der letzten Monate in Deiner Version schon enthalten.

[Chocco]

Okay, d.h. Du nutzt kein Hatari 2.4.1, sondern eine Version, die Du aus dem aktuellen Git-Stand von heute frisch gebaut hast? Dann wären die Verbesserungen am SCC der letzten Monate in Deiner Version schon enthalten.

Ja, stimmt. Meine Version ist die 2.5.0-devel vom 10. Februar. Ich habe für meine Zwecke die Tastaturbelegung angepasst und sonst ist alles unverändert.

Den Betreff habe ich korrigiert.

Die aktuellen 2.5.0 Sourcen kann ich im DL-Bereich momentan nicht finden.

[czietz]

Die aktuellen 2.5.0 Sourcen kann ich im DL-Bereich momentan nicht finden.

Irgendwie bin ich jetzt verwirrt, sorry. Was meinst Du mit "aktuellen 2.5.0 Sourcen" und "DL-Bereich"? Die Idee ist ja, dass Du jederzeit den aktuellen Source-Code aus Hataris Git-Repository (git://git.tuxfamily.org/gitroot/hatari/hatari.git oder https://git.tuxfamily.org/hatari/hatari.git/) beziehen kannst. Woher hast Du denn den Stand vom 10. Februar, wenn nicht aus Git?

Allerdings: Die letzten SCC-Änderungen in Hatari waren im Januar 2024; insofern wären sie in Deinem Stand vom 10. Februar wohl drin.

Nächste Frage: Verhält es sich anders, wenn Du doch einmal HSMODEM lädst? Weder die Routinen in Atari TOS noch die in EmuTOS sind für besonders gute Performance ausgelegt.

[Chocco]

Die aktuellen 2.5.0 Sourcen kann ich im DL-Bereich momentan nicht finden.

Irgendwie bin ich jetzt verwirrt, sorry. Was meinst Du mit "aktuellen 2.5.0 Sourcen" und "DL-Bereich"? Die Idee ist ja, dass Du jederzeit den aktuellen Source-Code aus Hataris Git-Repository (git://git.tuxfamily.org/gitroot/hatari/hatari.git oder https://git.tuxfamily.org/hatari/hatari.git/) beziehen kannst.

Nächste Frage: Verhält es sich anders, wenn Du doch einmal HSMODEM lädst? Weder die Routinen in Atari TOS noch die in EmuTOS sind für besonders gute Performance ausgelegt.

In https://git.tuxfamily.org/hatari/hatari.git/ ist aktuell nur die 2.4.1 als letzte Version zu sehen. Allerdings stelle ich mich auch häufig dämlich an. Wo genau siehst Du denn die Sourcen zu 2.5.0?

Ich habe jetzt HS-MODEM 7 aus atariuptodate geladen, für SCC Kanal B konfiguriert und getestet. Läuft unter altem und neuen RUFUS problemlos. Mein eigenes Programm läuft ebenfalls! Hätte ich nicht gedacht und danke für den Tipp.

Wenn Hatari mit der SCC-Emulation und dem SCC-Treiber aus HS-MODEM nun richtig läuft, müsste dann EMUTOS an dieser Stelle nicht nochmals optimiert werden?

[czietz]

In https://git.tuxfamily.org/hatari/hatari.git/ ist aktuell nur die 2.4.1 als letzte Version zu sehen. Allerdings stelle ich mich auch häufig dämlich an. Wo genau siehst Du denn die Sourcen zu 2.5.0?

Ich glaube, wir reden aneinander vorbei. Es gibt (noch) keine Version 2.5.0 von Hatari. Aber der Stand im Git-Repo ist jederzeit aktuell. Das letzte Update ist derzeit drei Stunden alt: "3 hours   Add debug line". Die Idee ist, dass Du das Programm git auf Deinem Rechner installierst und dann ebenso jederzeit die aktuellen Sourcen hast.

Einmalig:
git clone https://git.tuxfamily.org/hatari/hatari.git/
... und später zum Aktualisieren, im Verzeichnis "hatari", das von git clone angelegt wird:
git pull

(Ich weiß immer noch nicht, woher Du überhaupt die Sources auf dem Stand vom 10. Februar hast, wenn nicht über git?)

Wenn Hatari mit der SCC-Emulation und dem SCC-Treiber aus HS-MODEM nun richtig läuft, müsste dann EMUTOS an dieser Stelle nicht nochmals optimiert werden?

Ich habe den aktuellen Stand von EmuTOS (also nicht die Version 1.2.1, sondern den aktuellen Stand) ganz, ganz kurz auf einem echten Falcon mit Connect getestet und konnte in beide Richtungen Text übertragen. Wenn Du genauer beschreibst, was nicht funktioniert, gucke ich es mir in ein paar Wochen an. Aktuell habe ich keine Zeit (und es ist leider nicht so, dass EmuTOS Dutzende von weiteren Entwicklern hätte).

Aber beachte: Die seriellen Treiber sowohl in Atari TOS als auch in EmuTOS sind nicht auf Performance optimiert und eine Verwendung von HSMODEM ist immer ratsam.

[Chocco]

Ich glaube, wir reden aneinander vorbei. Es gibt (noch) keine Version 2.5.0 von Hatari. Aber der Stand im Git-Repo ist jederzeit aktuell. Das letzte Update ist derzeit drei Stunden alt: "3 hours   Add debug line". Die Idee ist, dass Du das Programm git auf Deinem Rechner installierst und dann ebenso jederzeit die aktuellen Sourcen hast.

Ich komme mit dem gequote nicht klar 

Die Sourcen holte ich mir IMMER über über den Download Link auf der https://hatari.tuxfamily.org Homepage und dann rechts auf "Download". Auf der Download-Seite erscheint direkt oben ein Link auf die "latest Release" und dieser Link führt auf eine Verzeichnisseite mit verschiedenen Versionen, ist aber nicht git. Dort hatte ich die Version geladen, die ich aktuell verwende. Das git hatte ich bisher nie verwendet. Habe es nun auf meinem Pi installiert. Danke dafür 

Beobachtete Fehler in EMUTOS 1.2.1 und Falcon Emulation mit Modem auf --scc-b-in und --scc-b-out gemapped auf /dev/ttyUSB0 am Raspi5.

Schnittstelle am Raspi5 über minicom konfiguriert auf 19200 8N1. An der Schnittstelle ist ein HW-Terminal mit Einstellung auf VT52 eingesteckt.

1. Rufus 1.06
1.1.Im Menu "Parameter" lässt sich die RS232 wunschgemäß (19200 8N1 no handshake) konfigurieren. Zeichen über Tastatur werden korrekt gesendet und empfangen - auch Key-Repeat funktioniert.

1.2. Im Menu "Transfer" => "ASCII Datei senden" die Datei "RUFUS.TXT" auswählen. Der Sendedialog erscheint, aber es werden keine Zeichen gesendet. Kein Abbruch möglich, es hilft nur ein Reset.

2. Rufus 1.4.2
2.1. Im Menu "Optionen" lässt sich die RS232 wunschgemäß (19200 8N1 no handshake) konfigurieren. Zeichen über Tastatur werden nicht gesendet oder empfangen.

2.2. Im Menu "Datei" => "ASCII senden" die Datei "FALCON.TXT" auswählen. Ergebnis wie 1.2. und nur durch Reset zu lösen.

3. Eigenes Progrämmchen in Pure-C gibt String mit ca. 30 Zeichen zeichenweise über Bconout() aus.
3.1. Es erscheinen meist nur 4 Zeichen auf dem Terminal. Anschließend reagiert die Schnittstelle nicht mehr. Erst nach Neustart der EMULATION werden wieder ein paar Zeichen übertragen.

3.2. Selbes Progrämmchen in Pure Pascal zeigt selbes Verhalten der Schnittstelle.

Man zweifelt natürlich erstmal an den eigenen Fähigkeiten, aber ich konnte mir dieses Verhalten einfach nicht erklären. Nachdem RUFUS 1.4.2 einen Hinweis auf die problematischen SCC-Ports am Falcon gab, habe ich die Emulation auf TT geschaltet und --rs232-in /-out verwendet. Hier lief dann alles, wie erwartet.

Mit dem SCC.PRG aus HS-MODEM arbeitet die Falcon Emulation nun auch/bisher fehlerfrei.

Vielen Dank für die Unterstützung!

[czietz]

3. Eigenes Progrämmchen in Pure-C gibt String mit ca. 30 Zeichen zeichenweise über Bconout() aus.
3.1. Es erscheinen meist nur 4 Zeichen auf dem Terminal. Anschließend reagiert die Schnittstelle nicht mehr. Erst nach Neustart der EMULATION werden wieder ein paar Zeichen übertragen.

Ich habe ein vergleichbares Testprogramm geschrieben. Ist auch angehängt, wenn Du testen möchtest. Ja, unter Hatari sehe ich auch nur vier Zeichen, wie Du. Hingegen auf dem echten Falcon unter EmuTOS:



Alle Zeichen werden ausgegeben!

Also doch eher ein Hatari-Problem? Wie gesagt, für tieferes Debugging fehlt mir leider die Zeit.

[gh-baden]

Hängen sollte natürlich nichts, aber 19k2 sind eigentlich viel zu viel für ohne Handshake. Schalte das besser mal ein, bspw. RTS/CTS.

[joejoe]

Hängen sollte natürlich nichts, aber 19k2 sind eigentlich viel zu viel für ohne Handshake. Schalte das besser mal ein, bspw. RTS/CTS.

Bei der Ausgabe?, das sollte auch mit deutlich mehr Dampf auf der Leitung ohne Probleme funktionieren.

Vier Zeichen lassen mich aber an den TX Buffer im SCC denken, aber gibt es die  nicht nur im ESCC? (4Byte TX, 8Byte RX). Durch Tausch des SCC gegen einen ESCC lassen sich ganz komfortable effektive Übertragungsraten realisieren. In der Emulation sollte das ja "soft" gehen, vielleicht liegt da der Hase im Pfeffer?

 

[Chocco]

Alle Zeichen werden ausgegeben!

Also doch eher ein Hatari-Problem? Wie gesagt, für tieferes Debugging fehlt mir leider die Zeit.

Ich habe nochmals etwas an Hatari "gespielt", also Systemtakt und die Parameter der CPU Emulation verändert. Am Verhalten der Falcon SCC hat sich nichts verändert. Man müsste halt wissen, was HSMODEM bei der Ansteuerung des SCC anders macht, als die Routinen in EMUTOS.

Ich habe gelesen, dass der Falcon auch einen MFP und eine weitere serielle Schnittstelle besitzt, die jedoch nicht rausgeführt wurde. In der Hatari Dokumentation wird beschrieben, man solle deshalb SCC-B nehmen. Grundsätzlich müsste der MFP in der Emulation doch vorhanden und nutzbar gemacht werden können?
 

[Chocco]

Hängen sollte natürlich nichts, aber 19k2 sind eigentlich viel zu viel für ohne Handshake. Schalte das besser mal ein, bspw. RTS/CTS.

Habe ich eben ausprobiert. Ändert sich nichts. Unter EMUTOS kommen nur 4-Zeichen und beim nächsten Zugriff hängt die Maschine.

Mit HSMODEM rennt der Falcon wie der Blitz und in der TT-Emulation über MFP-Serielle arbeiten 19200 auch völlig problemlos mit reinem EMUTOS.

[czietz]

Der SCC-Betrieb, wenn EmuTOS unter Hatari läuft, wurde ab Snapshot "20240320-202543-5e08a364" (https://sourceforge.net/projects/emutos/files/snapshots/20240320-202543-5e08a364/) verbessert. Zumindest gibt mein Testprogramm aus Antwort #9 nun auch unter Hatari alle Zeichen aus, wie auf dem echten Falcon.

Zwei Anmerkungen:

- Für eine ernsthafte Nutzung der seriellen Schnittstellen ist HSMODEM weiterhin empfohlen, denn dessen Treiber sind viel mehr auf Performance optimiert (Das gilt auch unter Atari TOS.)

- Warum diese Änderung nicht ins EmuTOS-Release 1.3 eingeflossen ist: Risikominimierung. So kurz vor dem Release fixen die EmuTOS-Maintainer nur noch kritische Bugs. Zu groß ist das Risiko, etwas zu verschlimmbessern.