RespeQt 5.3 für Windows/Linux/Mac

1, 2, 3

Re: RespeQt 5.3 für Windows/Linux/Mac

von dl7ukk » Fr 24. Apr 2020, 00:52
Danke Walter,

auch die R 5.3 läuft,

... aber mit flow-control nur gruselig (am Lotharek SIO2USB-PC)
... egal ob ehci-pci oder ohci-pci benutzt wird
... mit rund 20% CPU Auslastung
... und mehrfach festgestellten Aufhängen (?), kein Datenverkehr mehr möglich
und CPU-Last bei 96% für RespeQt, Was macht RespeQt da? Erst
ein disconnect/ connect ließ RespeQt wieder arbeiten
... ohne flow-control geht es bis Pokey-Div 4 (am Lotharek SIO2USB-PC)
getestet mit Hias diag-ext.atr und einem DD Image im LW:#2
... Mit dem SECTORCOPY 1.5 sind die Ergebnisse (flow-control) auch nicht viel besser.

Eine Meldung war da noch ...
Code: Alles auswählen
[ 6345.956071] ftdi_sio ttyUSB1: use of SPD flags is deprecated
[ 6363.711097] ftdi_sio ttyUSB1: use of SPD flags is deprecated
[ 6393.752392] ftdi_sio ttyUSB1: use of SPD flags is deprecated

:(

Re: RespeQt 5.3 für Windows/Linux/Mac

von dl7ukk » Fr 24. Apr 2020, 01:10
PS:

Die Gegenproben mit sio2bsd (V1.19) und
atariserver (V0.30)

waren bis Pokey-Div 0 und flow-control (nur atariserver) ein voller Erfolg.

Was läuft bei mir anders, als bei Walter ???

Re: RespeQt 5.3 für Windows/Linux/Mac

von GoodByteXL » Fr 24. Apr 2020, 09:00
dl7ukk hat geschrieben:PS:

Die Gegenproben mit sio2bsd (V1.19) und
atariserver (V0.30)

waren bis Pokey-Div 0 und flow-control (nur atariserver) ein voller Erfolg.

Was läuft bei mir anders, als bei Walter ???

Tja, was ...

Nach meinen bisherigen Erfahrungen spielt meist die Hardware nicht sauber mit - und zwar auf der PC-Seite.

Wie du weist, brauchte ich noch bei keinem einzigen A8 irgendwelche Kondensatoren tunen oder entfernen, um SIO-High-Speed stabil nutzen zu können. Egal wie die A8 aufgerüstet und umgebaut sind, es gibt einfach kein Problem damit. Problem hatte ich nur mit den externen Geräten SIO2SD und S:Drive, weshalb ich die wieder weggegeben hatte. Eine andere Problemstelle mit HIghspeed-SIO war die MaxFlashCard als SDX-Basis - auch weggegeben. Problemlos waren bisher das MSC und das KMK/JZ IDEPLus 2 Rev. C.

Eine Baustelle am PC scheint vor allem unter Linux die USB-Schnittstelle respektive deren Einbindung im Kernel zu sein. Ich hatte in den ca. letzten 10 Jahren einige krude Erlebnisse. Bei manchen Mainboards schien die USB-3-Schnittstelle nicht nur für das FTDI nicht sauber zu funktionieren. Booten von Live-Linux-USB-Sticks funktionierte z. B. oft nicht. Umstecken auf USB-2 half bisher immer.

Die Länge eines USB-Kabels von guter Qualität habe ich durch Verkettung mehrerer Kabel bis auf 3,5 m genutzt, ohne Tempoeinbußen. Mein Setup seit ca. 5 Jahren mit Mainboards von Gigabyte, dann ASUS nun ASROCK zeigte immer wieder die Macken mit USB-3. Ich habe von USB-2 ein 2 m langes USB-Kabel laufen, daran dann ein 50 cm langes Adapterkabel von Standard- auf Mini-USB zum Anschluss der Platinen mit FTDI 232R und diese dann wahlweise direkt im SIO-Stecker verbaut oder per ca. 20 cm langem Flachbandkabel am SIO-Stecker angeschlossen. Der SIO-Stecker steckt dann in einer 1050 Speedy, die per normal langem SIO-Kabel an eine 1050 Turbo geht, von der dann ein normal langes SIO-Kabel zum 800XL geht, der seinerseits mit einer Dual-SIO-Buchse aufgerüstet ist.

Und ja, RespeQt scheint eine relativ hohe Systemlast zu erzeugen, was aber weder mit einem i3-4130, einem i5-4590S, noch mit dem AMD Ryzen 5 2600 ins Gewicht fällt. Schwächere System können da ggf. schon in Schwierigkeiten kommen.

Allerdings hatte ich RespeQt 4 auch mal unter Linux MInt 18 auf einem schwachbrüstigem Samsung-Notebook mit i3-330M laufen, ohne Probleme.

Was im Zusammenspiel mit dem FTDI und RespeQt auf jeden Fall hilft, ist der FIFO. Allerdings muss man wissen, was man macht!!! Ohne dessen oder anderer Hilfe kommt man selten schneller als mit PD 4 zurecht. Nur meine handgestrickte SDX-Flash-Card von Xenon/Dial macht dann PD 3.

Alternativ zum FIFO kann ich auch die Highspeed vom KMK/JZ IDEPLus 2 Rev. C aktivieren, allerdings dann ohne FIFO, da das einen Konflikt gibt, der die SIO abschießt. Aber beide stellen dann PD 0 stabil sicher. Allerdings läuft nicht jede A8-Software unter jeder Konfiguration. Selbst beim Handshake gibt es da Notwendigkeiten, weil es manchmal nur entweder mit (CTS) oder ohne Handshake läuft. Manche mehrstufigen Programme bedingen hier sogar ein Umschalten zwischen den einzelnen Ladestufen.

Wohlgemerkt, alles auf der Cinnamon-GUI unter Linux Mint 19.3 mit 5.3er-Kernel und nix mit Konsole.
Wenn ich Konsolenspiele will, nehme ich SDX. ;)

Re: RespeQt 5.3 für Windows/Linux/Mac

von atarixle » Fr 24. Apr 2020, 09:16
Nur kurz zur Info:

Auf meinem Acer Aspire One von 2010 läuft RespeQt manchmal mit Pokey-Devisor 0 und manchmal nur mit normaler Geschwindigkeit.

Für diese komischen Timing-Probleme mache ich den FDTI-Chip verantwortlich.

Irgendwie schafft er PD0, aber wenn er nicht will, dann geht es einfach nicht. Selbes Verhalten auch mit SIO2BSD (Kommandozeilenprogramm).

Im Gegensatz dazu bringt eine echte COM-Schnittstelle immer ihre maximale Geschwindigkeit. Die schwächelt niemals - schaffte bisher auf meinen Systemen allerdings nur normales Highspeed (also 3x SIO).

RespeQt läuft - weil es aktiv am seriellen Port lauscht - immer mit 100% Systemlast. Systeme, bei denen das nicht ins Gewicht fällt, sind dann theoretisch die mit mindestens 2, praktisch sicherlich die ab 4 Kernen oder mehr.

Re: RespeQt 5.3 für Windows/Linux/Mac

von JoSch » Fr 24. Apr 2020, 10:49
Ja, die Systemlast von RespeQt ist schon ziemlich hoch. Dass die Systemlast runter muss, ist klar, besonders da wir aktuell auf Qt 5.6 bleiben, um alte XP-Rechner weiter zu bedienen und auch weiterhin auf schwächeren Raspberry Pis laufen zu können.
Da müssen wir auch jeden Fall dran. Dazu müssen wir aber erst noch ein bisschen Frühjahrsputz machen. ;-)

Re: RespeQt 5.3 für Windows/Linux/Mac

von GoodByteXL » Fr 24. Apr 2020, 12:30
atarixle hat geschrieben:Nur kurz zur Info:

Auf meinem Acer Aspire One von 2010 läuft RespeQt manchmal mit Pokey-Devisor 0 und manchmal nur mit normaler Geschwindigkeit.

Für diese komischen Timing-Probleme mache ich den FDTI-Chip verantwortlich.

Ich tippe da eher auf die USB-Anbindung, wenn der Chip ein echter FTDI ist. Ich habe damit bestückte Platinen verschiedener Hersteller in Gebrauch, und wenn es ein echter ist, funzt der auch einwandfrei. Es kann aber auch an der Kabelqualität liegen.

atarixle hat geschrieben:Im Gegensatz dazu bringt eine echte COM-Schnittstelle immer ihre maximale Geschwindigkeit. Die schwächelt niemals - schaffte bisher auf meinen Systemen allerdings nur normales Highspeed (also 3x SIO).

Dem muss ich widersprechen. Auch bei COM-Schnittstellen gibt es interessante Effekte. Einer davon ist die mgl. Unfähigkeit, schräge Baudraten für den Atari zu liefern. Dann jault der SIO-Ton förmlich bei schwankender Baudrate.

atarixle hat geschrieben:RespeQt läuft - weil es aktiv am seriellen Port lauscht - immer mit 100% Systemlast. Systeme, bei denen das nicht ins Gewicht fällt, sind dann theoretisch die mit mindestens 2, praktisch sicherlich die ab 4 Kernen oder mehr.

Mehr als 20% habe ich bisher nie gesehen. Aktuell beim Backup der SDX-Partition mit R4 von CF-Karte mit HDSC unter SDX pendelt die CPU-Last zwischen 6 - 8 %.
Bildschirmfoto vom 2020-04-24 12-15-26.jpgBildschirmfoto vom 2020-04-24 12-15-26.jpg

Re: RespeQt 5.3 für Windows/Linux/Mac

von atarixle » Fr 24. Apr 2020, 22:18
wow, nur 4% ... ist das mein Build von RespeQt?
Ist das das Serielle-Port-Backend oder das Atari-SIO-Backend?
Wie viele Kerne hast du?

EDIT: ... das ist mir neu ... auf meinem MacBook3,1 mit Ubuntu 20.04 LTS läuft es auch mit maximal 6%. Die Anzeige müsste stimmen, bei realen 100% würden sonst die Lüfter Rabats machen

EDIT2: und selbst auf meinem Acer Aspire One geht es nicht über 10% (bei Pokey Divisor 6).

Re: RespeQt 5.3 für Windows/Linux/Mac

von GoodByteXL » Sa 25. Apr 2020, 07:54
atarixle hat geschrieben:wow, nur 4% ... ist das mein Build von RespeQt?

Ja :)
atarixle hat geschrieben:Ist das das Serielle-Port-Backend oder das Atari-SIO-Backend?


Bildschirmfoto vom 2020-04-25 07-47-11.png
Bildschirmfoto vom 2020-04-25 07-47-11.png (48.33 KiB) 4458-mal betrachtet


atarixle hat geschrieben:Wie viele Kerne hast du?

6, also 12 Threads. Aber auch mit 2 Kernen auf dem alten Notebook war es nicht sehr viel höher.

atarixle hat geschrieben:EDIT: ... das ist mir neu ... auf meinem MacBook3,1 mit Ubuntu 20.04 LTS läuft es auch mit maximal 6%. Die Anzeige müsste stimmen, bei realen 100% würden sonst die Lüfter Rabats machen

EDIT2: und selbst auf meinem Acer Aspire One geht es nicht über 10% (bei Pokey Divisor 6).

Die Aussage "R läuft mit 100%" bezieht sich vmtl. auf R selbst, da es wohl immer volle Pulle läuft. Die Systemlast des Computers ist davon nur marginal betroffen. Mag auf einem Raspi anders sein.

Die Netto-Datenrate der Übertragung ist dann 10,7 KiB.

Re: RespeQt 5.3 für Windows/Linux/Mac

von HiassofT » Sa 25. Apr 2020, 21:32
GoodByteXL hat geschrieben:Die Aussage "R läuft mit 100%" bezieht sich vmtl. auf R selbst, da es wohl immer volle Pulle läuft. Die Systemlast des Computers ist davon nur marginal betroffen. Mag auf einem Raspi anders sein.

Die 100% CPU Last auf einem Kern tritt nach wie vor auf wenn man eine "richtige" serielle Schnittstelle unter Linux verwendet. Mit den meisten USB Adaptern (insb. FTDI) passiert das nicht.

Hintergrundinfo:

Wenn RespeQt auf das Command Signal wartet fragt es per ioctl den Status ab. Den liefert der Linux-Kernel bei einer on-board Seriellen nach ein bisschen CPU Arbeit sofort zurück und wenn Command noch inaktiv ist/war fragt es gleich wieder nach - der I/O Thread lastet also einen Kern zu 100% aus.

Bei FTDI Adaptern schickt der Kernel einen USB Request zum Adapter und wartet dann auf die Antwort. Das Senden und Empfangen braucht nur wenig CPU, die Antwort kommt aber erst nach 1-2ms. RespeQt fragt dann zwar ebenfalls gleich wieder nach aber die meiste Zeit ist die CPU idle bis die Antwort eintrudelt. Daher ist die CPU Last sehr gering, der I/O Thread schläft die meiste Zeit.

Wenn Disk-Transfers laufen ist das nicht so schlimm, da RespeQt dann immer nur kurze Zeit mit dem Warten auf den nächsten Command Frame verbringt - die meiste Zeit benötigt die serielle Übertragung und da ist die CPU ebenfalls die meiste Zeit idle bis die Übertragung beendet ist (dafür braucht dann die GUI CPU Leistung um das Log-Fenster zu aktualisieren).

Abhilfe für die 100% CPU Last ohne Transfer könnte eine kurze Pause beim Warten auf Command bringen. So mach' ich das auch in der Userspace Implementierung von AtariSIO, da warte ich immer 100µs bevor ich den Status abfrage.

so long,

Hias

Re: RespeQt 5.3 für Windows/Linux/Mac

von GoodByteXL » So 26. Apr 2020, 11:44
HiassofT hat geschrieben:
GoodByteXL hat geschrieben:Die Aussage "R läuft mit 100%" bezieht sich vmtl. auf R selbst, da es wohl immer volle Pulle läuft. Die Systemlast des Computers ist davon nur marginal betroffen. Mag auf einem Raspi anders sein.

Die 100% CPU Last auf einem Kern tritt nach wie vor auf wenn man eine "richtige" serielle Schnittstelle unter Linux verwendet. Mit den meisten USB Adaptern (insb. FTDI) passiert das nicht.

Hias

Danke für die Erläuterung. :)
Dann ist also ein FTDI-basierter USB-Adapter die bessere Lösung?
Oder bringt eine echte serielle Schnittstelle noch andere Vorteile als die Rückwärtskompatibilität von RespeQt zu älteren PCs?

Re: RespeQt 5.3 für Windows/Linux/Mac

von atarixle » So 26. Apr 2020, 13:47
Für RespeQt ist auch ttyUSB0 nur eine serielle Schnittstelle bzw. generell eine Schnittstelle. Dass dies eine serielle Schnittstelle am USB-Port ist, weiß nur der Linux-Kernel, dessen FTDI-Kernel-Modul (Gerätetreiber) das Gerät /dev/ttyUSB0 bereitstellt.

In RespeQt selbst ist gar keine USB- bzw. FTDI-Unterstützung implementiert.

Wenn du deine CPU nicht kochen willst, ist der FTDI derzeit die bessere Lösung, aber generell gibt es zwischen diesen beiden Lösungen von RespeQt's Standpunkt keinen Unterschied ... zumindest kein "besser" oder "schlechter".

Re: RespeQt 5.3 für Windows/Linux/Mac

von HiassofT » So 26. Apr 2020, 14:28
GoodByteXL hat geschrieben:Dann ist also ein FTDI-basierter USB-Adapter die bessere Lösung?

Ganz grob abgekürzt: im Allgemeinen ja.

Es gibt ein paar Spezialfälle bei denen eine "richtige" Serielle im Vorteil ist, aber das sind (für die meisten User) nur eher unwichtige Nischenanwendungen.

zB ist es mit USB Adaptern praktisch unmöglich den XF551 Highspeed Modus zu emulieren da das Zeitfenster in dem die Geschwindigkeit umgeschaltet werden muss extrem klein ist. Kopiergeschützte CAS Files (die FSK Blöcke mit nicht "normalen" Bytes sondern beliebig kurzen/langen Folgen von 0 und 1 Bits enthalten) gehen auch nicht, da der direkte Zugriff auf die TxD Leitung fehlt (FTDI Chips würden das prinzipiell erlauben, aber das geht dann nur wenn man den Chip direkt anspricht statt über ttyUSB0 aber das wäre sehr aufwändiog, da man dann alles was der Linux Treiber macht noch mal selber implementieren muss).

Beide Sachen (XF551 und CAS mit FSK Blöcken) kriegt man aber auch mit einer "richtigen" Seriellen über die Linux/Unix API (also ttyS0) nicht wirklich hin da das Timing viel zu ungenau ist (Deiails erspar ich euch jetzt). Auf Windows/Mac dürfte das ziemlich gleich sein.

Ich habe diese Sachen in AtariSIO im Kernel-Treiber implementiert, mit direkt-Zugriff auf den 16550/950 Chip klappt's mit dem Timing.

Falls also irgendwer diese eher exotischen Features unter Linux mit einer richtigen Seriellen verwenden möchte wär's wahrscheinlich am einfachsten das AtariSIO backend in RespeQt zu verwenden. Das ist aber was für recht fortgeschrittene User die sich nicht davor scheuen ein Kernel-Modul zu compilieren - also eher nichts für die Massen :-)

Kurzum: da es kaum noch PCs mit on-board serieller Schnittstelle gibt und für die meisten User wohl Pokey Divisor 0 interessanter ist als XF551 Highspeed mit 38kbit/sec ist so ein FTDI USB Adapter wohl die beste Lösung.

so long,

Hias

Re: RespeQt 5.3 für Windows/Linux/Mac

von GoodByteXL » Di 28. Apr 2020, 12:42
Danke für die Erläuterungen. :)

Aber die Sache mit der XF-HS interessiert mich, da ich in dem Bereich keine Einschränkungen finden konnte bei Verwendung eines echten FTDI-Adapters. Es sei denn, du meinst etwas Anderes ...

HiassofT hat geschrieben:...
Es gibt ein paar Spezialfälle bei denen eine "richtige" Serielle im Vorteil ist, aber das sind (für die meisten User) nur eher unwichtige Nischenanwendungen.

zB ist es mit USB Adaptern praktisch unmöglich den XF551 Highspeed Modus zu emulieren da das Zeitfenster in dem die Geschwindigkeit umgeschaltet werden muss extrem klein ist.
...
Kurzum: da es kaum noch PCs mit on-board serieller Schnittstelle gibt und für die meisten User wohl Pokey Divisor 0 interessanter ist als XF551 Highspeed mit 38kbit/sec ist so ein FTDI USB Adapter wohl die beste Lösung.

so long,

Hias

Exakt das hatte ich vor längerer Zeit für mein Praxiswissen zur Verwendung des FIFO und ob mit (CTS) oder ohne Handshaking (NONE) in RespeQt 4.0 ausprobiert.

Auf meinem System laufen ohne FIFO:
- Diskettenbasierte DOS mit maximal PD 6 (TurboDOS 2.1HS).
- SPOS und vergleichbare OS-ROMs mit PD 4.
- SDX 4.49 auf meiner handgestrickten SDX 128 FlashCart mit PD 3.
(Wobei es egal ist, welchen A8 ich da einstöpsele.)
ATRs booten mit PD 16 (XF551) ist kein Problem, egal ob Handshaking an/aus.

Generell gilt, dass bei manchen Geschwindigkeiten RespeQt mglw. ein Problem beim Synchronisieren hat, nicht nur bei PD 16:
Code: Alles auswählen
[Disk 1] Geschwindigkeitsabfrage."
Serial port read timeout. 4 of 5 read in 103 ms"
Geschwindigkeit des seriellen Ports ist gesetzt auf 38400."
[Disk 1] Lesen von Sektor 8 (128 Bytes)."


Allerdings scheint dieses Problem auch irgendwie von der A8-Software abzuhängen, denn wenn die (z. B. SpartaDOS 3.x) sauber abfragt, tritt diese Anzeige bei mir nicht auf.

Und was mir noch auffällt: Die Anzahl der sinnlosen Abfragen auf nicht installierte Hardware (z. B. durch TurboDOS - siehe Beispiel unten) fällt z. B. bei SpartaDOS weg.

Code: Alles auswählen
[Disk 1] Lesen von Sektor 7 (128 Bytes)."
[Disk 1] Kommando: $48, aux: $0020 NAK."
[Disk 1] Kommando: $48, aux: $0020 NAK." [x2]
...]
[Disk 1] Kommando: $48, aux: $0020 NAK." [x28]
[Disk 1] Geschwindigkeitsabfrage."
Serial port read timeout. 4 of 5 read in 103 ms"
Geschwindigkeit des seriellen Ports ist gesetzt auf 38400."
[Disk 1] Lesen von Sektor 8 (128 Bytes)."


Wenn ich den FIFO zuschalte, verschwinden die meisten Fehler, lediglich
Code: Alles auswählen
Geschwindigkeitsabfrage."
Serial port read timeout. 4 of 5 read in 103 ms"

bleibt, wirkt sich aber nicht aus. Man sieht es halt im Log-File...

Re: RespeQt 5.3 für Windows/Linux/Mac

von HiassofT » Di 28. Apr 2020, 15:17
Hallo Walter,

Du hast da das Ultraspeed Protokoll mit Divisor 16 getestet, das ist kein Problem.

Das Highspeed Protokoll der XF551 ist etwas anders, da wird der Command Frame vom Atari und das ACK vom Laufwerk in Normalgeschwindigkeit übertragen, danach muss der Atari (bzw PC) innerhalb von ein paar hundert Mikrosekunden auf Highspeed umschalten.

Zum Thema Logs: ich würde mich freuen wenn man die Log-Meldungen gezielter bzw auch komplett abschalten könnte. Zum Testen kann es sinnvoll sein sich anzeigen zu lassen welche Kommandos RespeQt nicht behandelt (zB weil das Kommando nicht unterstützt wird oder weil kein D2: Laufwerk gemountet ist), oft ist aber nicht mal die Anzeige der behandelten Kommandos wirklich sinnvoll - gerade auf schwachbrüstigen Rechnern wie dem RPi0/1 oder recht alten PCs erzeugt das Log-Fenster richtig viel CPU Last.

so long,

Hias

Re: RespeQt 5.3 für Windows/Linux/Mac

von GoodByteXL » Di 28. Apr 2020, 16:39
HiassofT hat geschrieben:Du hast da das Ultraspeed Protokoll mit Divisor 16 getestet, das ist kein Problem.

Das Highspeed Protokoll der XF551 ist etwas anders, ...

Ahja, dann habe ich das doch Miss(t)verstanden. Doch dann müsste ja jemand die XF551 in RespeQt extra einbauen, um sie emulieren zu wollen. (Programmier)-technisch vielleicht interessant, aber Nutzen?

In den neueren Beta-Versionen 4.3 - 5.3 von RespeQt sind ja schon Archiver und Happy emuliert, habe ich bisher nicht sinnvoll verwenden können. Ich bin halt doch ein Dummy-Mainstream-User. :)

Dafür funktioniert der Textdrucker nicht mehr, der für mich äußerst nützlich war ...

Zu den Logs völlig dacor, denn ich mache normalerweise das Fenster zu. Die meisten Dinge erkenne ich am SIO-Sound, nach so vielen Dekaden ... :D

Re: RespeQt 5.3 für Windows/Linux/Mac

von JoSch » Do 30. Apr 2020, 10:17
GoodByteXL hat geschrieben:Dafür funktioniert der Textdrucker nicht mehr, der für mich äußerst nützlich war ...

Ich arbeite gerade daran, den ganzen Bereich zu überarbeiten.
Für das Textausgabefenster habe ich aber noch keine Idee, wie ich das integrieren soll.
Kannst Du mir Deinen Usecase sagen? Brauchst Du das Textfenster, um den Text als PC-Text zu exportieren?

Re: RespeQt 5.3 für Windows/Linux/Mac

von atarixle » Do 30. Apr 2020, 15:41
Einer der Textdrucker geht noch in RespeQt. skriegel hatte doch einen Screenshot von der funktionierenden Druckerausgabe unter RespeQt 5.3 für macOS gepostet: https://atariage.com/forums/topic/30413 ... nt=4498510 ... Daraufhin hab ich's unter Linux getestet - läuft!

Re: RespeQt 5.3 für Windows/Linux/Mac

von GoodByteXL » Do 30. Apr 2020, 20:16
JoSch hat geschrieben:
GoodByteXL hat geschrieben:Dafür funktioniert der Textdrucker nicht mehr, der für mich äußerst nützlich war ...

Ich arbeite gerade daran, den ganzen Bereich zu überarbeiten.
Für das Textausgabefenster habe ich aber noch keine Idee, wie ich das integrieren soll.
Kannst Du mir Deinen Usecase sagen? Brauchst Du das Textfenster, um den Text als PC-Text zu exportieren?

Ja, zumeist genau dafür.

Aber, wie atarixle schrieb:
atarixle hat geschrieben:Einer der Textdrucker geht noch in RespeQt. skriegel hatte doch einen Screenshot von der funktionierenden Druckerausgabe unter RespeQt 5.3 für macOS gepostet: https://atariage.com/forums/topic/30413 ... nt=4498510 ... Daraufhin hab ich's unter Linux getestet - läuft!

Es funktioniert wirklich - :) - aber erst, nachdem ich eine neue LM-Installation auf einer jungfräulichen SSD angelegt hatte und darin dann R5.3 startete. Ggf. hatten die 'gesammelten' Versionen von RespeQt und/oder Quicktime etwas blockiert, denn ich bekam zuvor immer einen Error 138.

So geht's:
Für P1 'Atari1020' und 'Text printer' auswählen, dann daneben das Druckersymbol für 'verbinden' klicken. Dann wird die Auswahl durch Ausgrauen bestätigt und das Auswurfsymbol daneben aktiviert. Damit geht es dann zurück.

Aber:
Nachdem ich einmal einen anderen Printer versucht hatte, bin ich wieder bei Error 138 und RespeQt wird danach direkt beendet. Und das kann ich bisher nicht mehr korrigieren. Neustart von Linux und Atari800XL helfen nicht mehr.

Vielleicht hilft das bei der Fehlersuche ...

Re: RespeQt 5.3 für Windows/Linux/Mac

von JoSch » So 3. Mai 2020, 17:54
Ja, das kann sein. Es hatten sich an verschiedenen Stellen des Druckercodes Fehler eingeschlichen.
Ich habe jetzt einiges umgestellt und Eric hat den 1020 gefixt. Ich muss dann auch noch an die restlichen Drucker ran. Der 1027 sollte eigentlich der ideale Textdrucker sein.
Ich hoffe, ich kann in den nächsten Tagen mal ein Alpha-Build von meinen Änderungen machen.
1, 2, 3