Habe mir von AtariXLXE obige Software heruntergeladen, um einen alten Schlepptop als ATR-Archiv zu verwenden. Nach dem Start bekomme ich die Mitteilung:

Kann serielle Port Geschwindigkeit nicht auf '19200' setzen: Eingabe-/Ausgabefehler.
Emulation gestoppt.

Mit dem Hinweis auf Mirkos Webseite:
Sometimes it happens, that AspeQt reports an error "Cannot open serial port '/dev/ttyS0': No Permissions." (or similar). In this case, you have to add yourself to the dialout-group (sudo usermod -aG dialout $USER in Ubuntu or as root using the command usermod -aG dialout {username} in debian). Then logout and log back in.

kann ich nix anfangen. Ich kann zwar "sudo usermod -aG dialout $USER" auf der Kommandozeile ausführen lassen (passiert nix ...), aber ausloggen? Ich kann einen Neustart auslösen, das isses.

Da ich mit Linux nur das kann, was von der Oberfläche her bedienbar ist, suche ich nach einem Hinweis, um AspeQt unter Linux nutzen zu können.

Die Hardware funktioniert auf dem Rechner unter WinXP/Win7 problemlos, daran liegt es also nicht.

N'abend

lass Dir doch erst einmal Deine Gruppenzugehörigkeiten anzeigen. Dann siehst Du ja ob Du in >dialout< drin bist.

walter:~$ less /etc/group | grep walter

das sollte dann etwa so aussehen .... sambashare:x:124:dl7ukk (hier für Samba und mich)

dl7ukk hat geschrieben:N'abend

lass Dir doch erst einmal Deine Gruppenzugehörigkeiten anzeigen. Dann siehst Du ja ob Du in >dialout< drin bist.

walter:~$ less /etc/group | grep walter

das sollte dann etwa so aussehen .... sambashare:x:124:dl7ukk (hier für Samba und mich)

Ähm, damit kann ich auch nix anfangen. Ich habe das Linux Mint per DVD eingeworfen, installiert und benutze es von der sehr schönen Oberfläche her.

Aber ich habe die Ursache gefunden:
AspeQt, also die von Mirko bereitgestellte Version, mounted als Schnittstelle 'S0', obwohl die serielle Schnittstelle bei mir im BIOS abgeschaltet ist und stattdessen ein FTDI F232R dranhängt. Den hatte Linux auch gefunden, aber offenbar ist die Voreinstellung eine andere. Statt 'S0' stellt man die Schnittstelle auf 'USB0' um und das war's schon.

Aber hier schon die nächste Frage:
Bei PD 7 ist Schluss, schneller funktioniert es unter Linux nicht, obwohl auf der gleichen Hardware AspeQt 0.8.8 unter WinXP und Win7 die Übertragung mit PD 0 rennen lässt. Was kann die Ursache sein?

Push ...

GoodByteXL hat geschrieben:Aber hier schon die nächste Frage:
Bei Pokey Divisor 7 ist Schluss, schneller funktioniert es unter Linux nicht, obwohl auf der gleichen Hardware AspeQt 0.8.8 unter WinXP und Win7 die Übertragung mit PD 0 rennen lässt. Was kann die Ursache sein?

Das habe ich mit 2 verschiedenen FTDI 232R Breakout Boards getestet, beide von Sparkfun mit original FTDI-Chip.

Was ebenfalls merkwürdig ist: Ab und an schläft die Verbindung einfach ein. Warten oder Emulation neu starten hilft dann manchmal ...

auf der Fujiama ist mir ähnliches passiert: während ich teils Stunden mit P0 arbeiten konnte, lief es manchmal nur mit normaler Geschwindigkeit.

Hast du mal die Windows-Version unter Linux probiert? Die hab ich auf dem Mac laufen und da hatte ich das Problem nicht bemerkt.

atarixle hat geschrieben:auf der Fujiama ist mir ähnliches passiert: während ich teils Stunden mit P0 arbeiten konnte, lief es manchmal nur mit normaler Geschwindigkeit.

Hast du mal die Windows-Version unter Linux probiert? Die hab ich auf dem Mac laufen und da hatte ich das Problem nicht bemerkt.

Nein, abr inzwischen weiß ich, das Linux und BSD sehr viel engere Timings fahren als Windows.

Hat jemand eine für Linux kompilierte Version von RespeQt im Angebot?

Vielleicht liefe die besser.

GoodByteXL hat geschrieben:

atarixle hat geschrieben:auf der Fujiama ist mir ähnliches passiert: während ich teils Stunden mit P0 arbeiten konnte, lief es manchmal nur mit normaler Geschwindigkeit.

Hast du mal die Windows-Version unter Linux probiert? Die hab ich auf dem Mac laufen und da hatte ich das Problem nicht bemerkt.

Nein, abr inzwischen weiß ich, das Linux und BSD sehr viel engere Timings fahren als Windows.

Hat jemand eine für Linux kompilierte Version von RespeQt im Angebot?

Vielleicht liefe die besser.

Da es von RespeQt keine Click-To-Run-Version für Linux gibt und die vorliegende Version von AspeQt 0.8.8 für Linux nicht stabil läuft, habe ich heute WINE installiert und darin die portable Windows-Version von AspeQt 0.8.8 hineingepackt. Die Einstellung war für mich als Linux-Dummy-User fummelig und alles habe ich auch noch nicht ergründen können, z.B. den Zugriff auf ATR-Files über die Fensterfunktion. Aber mit Drag&Drop über die grafische Benutzeroberfläche kann man die ATRs dorthin ziehen und dann funzt es. Und - es läuft schnell und stabil und der Firlefanz mit der Linux-Version ist Geschichte.

Merkwürdigerweise läuft AspeQT unter Linux mit 100% CPU Belastung.

Das kann am gewählten Backend liegen oder auch nicht - ich weiß es nicht.

Bisher habe ich mich mit AspeQT für Linux nur soweit befasst, bis es funktioniert hat - weiter nicht.

Vielleicht gibt es auch noch einen Schalter für das Kompilieren von AspeQT, den ich noch nicht kenne (kompiliert hab ich's einfach nur mit qmake).

atarixle hat geschrieben:Vielleicht gibt es auch noch einen Schalter für das Kompilieren von AspeQT, den ich noch nicht kenne (kompiliert hab ich's einfach nur mit qmake).

Ja, als Dummy-User finde ich es merkwürdig, wenn wie gestern auf atariage behauptet wird, dass man RespeQt ganz einfach mal so lauffähig kompilieren könnte, dann aber keine Zeit dafür ist.

Das zeigt mir als Linux-Laien, dass es offenbar doch nicht so einfach geht wie behauptet wird bzw. das Ergebnis nicht zufriedenstellend ist.

Kannst du mal schauen, ob du RespeQt R2 "einfach so" ready-to-run kompilieren kannst? Es hat wesentlich weniger Macken als AspeQt 0.8.8 (und AspeQt 1.0.0).

Unter http://www.abbuc.de/~atarixle/download/#respeqt findest du meinen Build von RespeQt.

Allerdings habe ich nur die Möglichkeit, für Debian 8 in 64 Bit zu kompilieren. RespeQt basiert auf QT5, so dass die entsprechenden Pakete installiert sein müssen, um QT5-Programme auszuführen.

Mein Build sollte auf allen QT5-fähigen 64-Bit-Linuxen laufen.

Unter Linux Mint 17.2 sollte es somit laufen, sofern du die 64 Bit Version installiert hast.

Läuft es nicht, so installiere die nötigen QT5-Pakete, in dem du

Code: Alles auswählen

sudo aptitude install libqt5network5 libqt5core5a libqt5widgets5

in ein Terminal eintippst und mit deinem Passwort bestätigst.

Danke für die Hilfe.
Sobald ich wieder Zugriff auf meinen Heimrechner habe, teste ich das aus und werde berichten. Mobil muss ich mich mit Win10 'rumplagen.

ich korrigiere:

Code: Alles auswählen

sudo aptitude install libqt5network5 libqt5core5a libqt5widgets5 libqt5printsupport5

atarixle hat geschrieben:ich korrigiere:

Code: Alles auswählen

sudo aptitude install libqt5network5 libqt5core5a libqt5widgets5 libqt5printsupport5

Wie mir die Paketverwaltung Synaptic zeigt, sind diese Pakete in Linux Mint 17.2 standardmäßig enthalten. Ein erster Start funktioniert reibungslos. Werde nachher mal einige längere Tests laufen lassen.

GoodByteXL hat geschrieben:

atarixle hat geschrieben:ich korrigiere:

Code: Alles auswählen

sudo aptitude install libqt5network5 libqt5core5a libqt5widgets5 libqt5printsupport5

Wie mir die Paketverwaltung Synaptic zeigt, sind diese Pakete in Linux Mint 17.2 standardmäßig enthalten. Ein erster Start funktioniert reibungslos. Werde nachher mal einige längere Tests laufen lassen.

Große Klasse - läuft einwandfrei ohne die Aussetzer, Hänger und Abstürze der alten Linux-AspeQt-Version.

Freut mich

Warum das nun besser läuft, als meine Versionen von AspeQt, weiß ich nun nicht.

Das Programm besteht ja aus Code von vielen verschiedenen Herstellern. Geändert hat sich alles: debian, gcc, QT, *speQT … alles neu

atarixle hat geschrieben:Warum das nun besser läuft, als meine Versionen von AspeQt, weiß ich nun nicht.

Das ist ja auch egal, Hauptsache ist, dass es nun funzt . Und die Einrichtung unter Linux Mint 17.2 war direkt vom Desktop her simpel. Wer wie ich derzeit von Win nach Linux migrieren will, findet mit Mint einen leichten Einstieg. Das einzige Manko bisher ist, dass in den Anleitungen, Guides, Foren etc. immer sofort und oft fast ausschließlich auf die Kommandozeile eingegangen wird, ohne die Möglichkeiten über das Desktop zu erläutern. Da muss man sich selbst durchklicken ...

Die nächste Baustelle für mich ...

Das Problem bei Linux in dieser Hinsicht ist, dass die Möglichkeiten auf dem Desktop von Distribution zu Distribution zu unterschiedlich sind. Deshalb wird auf die Kommandozeile eingegangen.

atarixle hat geschrieben:Das Problem bei Linux in dieser Hinsicht ist, dass die Möglichkeiten auf dem Desktop von Distribution zu Distribution zu unterschiedlich sind. Deshalb wird auf die Kommandozeile eingegangen.

... und dann wundern sich die Linux-Fans, dass Otto-Normal-User dabei meist struwelige Haare kriegt und dann "reumütig" zu Windows zurückkehrt. Aber diesmal will ich das dicke Brett durchbohren ...

ein zweiter Grund für das häufige Ausweichen auf die Kommandozeile ist, dass Linux in all seinem möglichen Funktionsumfang so mächtig und flexibel ist, dass grafische Werkzeuge einen immensen Umfang hätten. Allein die Kompatibilität zu UNIX schreibt diese reichhaltigen Möglichkeiten auf der Kommandozeile vor.

Nachteil ist, dass nicht jeder gern die einzelnen Schritte einer Kommandozeile erklärt, was es dem Einsteiger nicht gerade leicht macht.

Doch eigentlich ist die Linux-Kommandozeile nicht viel anders als die von MS-DOS oder SpartaDOS:

Code: Alles auswählen

Befehl --Schalter Argumente

Wobei "Befehl" meist ein "Programm" ist, welches sich im Ausführungspfad befindet.

atarixle hat geschrieben:ein zweiter Grund für das häufige Ausweichen auf die Kommandozeile ist, dass Linux in all seinem möglichen Funktionsumfang so mächtig und flexibel ist, dass grafische Werkzeuge einen immensen Umfang hätten. Allein die Kompatibilität zu UNIX schreibt diese reichhaltigen Möglichkeiten auf der Kommandozeile vor.

Nachteil ist, dass nicht jeder gern die einzelnen Schritte einer Kommandozeile erklärt, was es dem Einsteiger nicht gerade leicht macht.

Doch eigentlich ist die Linux-Kommandozeile nicht viel anders als die von MS-DOS oder SpartaDOS:

Code: Alles auswählen

Befehl --Schalter Argumente

Wobei "Befehl" meist ein "Programm" ist, welches sich im Ausführungspfad befindet.

Ok, driften wir mal "off topic":
Ja, das ist mir schon alles klar. Die ersten Versuche mit Linux hatte ich 1994; damals ein Kurs an VHS. Überzeugt als Anwender hatte es mich bis zu der aktuellen Mint Version 17.2 nur sehr bedingt. Meist hat es beim Installieren schon die Grafik zerschossen, Treiber für 08/15-Hardware aus der Win-Welt gab es nicht, etc., etc. . Mint 17.2 in der deutschen Distribution von "linuxmintusers.de" konnte ich mit Hilfe aus dem Forum in Sachen Treiber dann endlich mal anwenderfreundlich installieren. Finde ich toll.

Aber mal im Ernst, als Anwender von Programmen, z.B. Officepaket, ist mir das zugrunde liegende Betriebssystem völlig egal. Es muss eine grafische Benutzeroberfläche haben und mit einem einfachen Werkzeug (z.B. Maus) die Möglichkeit bieten, Programme zu installieren und zu benutzen. Wenn ich mit einem OS basteln will, dann SpartaDOS X . Oder ich gehe zurück in die 1970er und nehme CP/M.

Ich weiß, dass das in den Augen der Fachleute ein Sakrileg ist, aber als Dummy User brauche ich genau das. Wenn ich Zeit investiere, dann in die Produktivseite - z.B. Handbücher ...