Moin zusammen,

nachdem ich jetzt von Windows 10 wieder zurück auf Windows 7 bin, weil es einfach nur genervt hat, hab ich zur Zeit Probleme mit meinem SIO2USB. Folgendes Problem:

Atari fängt brav an zu laden, bleibt aber früher oder später mitten im laden "hängen". Nach 2-3 Sekunden fängt er sich dann, meistens, und lädt weiter... Das Phänomen ist mir neu, vorher lief alles wunderbar. Daher vermute ich ein Treiberproblem. Die neusten Treiber (Win7 64bit) hab ich von der FTDI Seite installiert, brachte aber kein Ergebnis

Kann mir da vielleicht jemand helfen?

Hallo Chaosfaktor

Du meinst wohl SIO2PC(viaUSB). SIO2USB ist ganz was anderes.

Tschüß

Mathy

Wahrscheinlich. Irritierender Weise wird für beide Gerätearten gerne die selbe Bezeichnung genutzt:

Das sio2usb Interface:

Autarkes SIO-Gerät zur Verwendung eines USB-Sticks als Diskettenersatz

Das sio2pc USB von Atarimax (wird im Siebdruck auf der Platine ebenfalls als "sio2usb" bezeichnet):

Gibt es in verschiedenen Bauformen.
Interface zum Einsatz eines PCs als SIO-Gerät (primär Floppyersatz).

sio2pc USB Homebrew:

Beispiel; verschiedene Ausführungen im Umlauf.
Dito.

Sleepy

Lach, ja mein ich Noch genauer gesagt die Lösung von Lotharek

Ich habe noch ein bissl weitergetestet und das Ding über Linux und Respeqt laufen lassen. Keine Auffälligkeiten so das ich einen Gerätefehler ausschließen kann... Hat denn keiner von euch sonst dieses Problem?

Wobei ich staune, dass es unter Linux besser klappt als unter Windows. Meine Erfahrungen waren eher umgekehrt.
Aber es könnte auch an der CPU-Leistung liegen.

Welchen bzw. wessen Linux-Build nutzt du da?

Hallo,

Chaosfaktor hat geschrieben:Hat denn keiner von euch sonst dieses Problem?

Doch, nur Probleme.
jedenfalls bei mir und unter Linux Ubuntu 12.04 sowie Mate 16.04. Es scheint ein Timing Problem (von Respeqt) zu sein.
Egal ob CTS oder RTS bei Respeqt eingestellt wird (beim SIO2PC(USB) auch umgestellt....)
Das Hardware-Handshaking könnte es sein. Probiere mal die SIO2BT Einstellung. Damit habe ich gute Ergebnisse erzielt.
Und es ist (BEI MIR) auch kein Hardware Problem. Mit SIO2BSD auf der Konsole funktioniert es ja gut.

dl7ukk hat geschrieben:Hallo,

Chaosfaktor hat geschrieben:Hat denn keiner von euch sonst dieses Problem?

Doch, nur Probleme.
jedenfalls bei mir und unter Linux Ubuntu 12.04 sowie Mate 16.04. Es scheint ein Timing Problem (von Respeqt) zu sein.
Egal ob CTS oder RTS bei Respeqt eingestellt wird (beim SIO2PC(USB) auch umgestellt....)
Das Hardware-Handshaking könnte es sein. Probiere mal die SIO2BT Einstellung. Damit habe ich gute Ergebnisse erzielt.
Und es ist (BEI MIR) auch kein Hardware Problem. Mit SIO2BSD auf der Konsole funktioniert es ja gut.

Hatte!
Letzten Winter funktionierte die seit ewigen Zeiten verwendete Einstellung "CTS" von "jetzt auf gleich" sowohl unter Linux Mint Cinnamon als auch Win 7 und Win 10 nicht mehr. Zuerst vermutete ich ein defektes Interface und tauschte es gegen mein Mobil-SIO2PC(USB) aus. Gleiches negatives Ergebnis! Beide Interfaces sind mit einem echten FTDI232R bestückt.

Da ich weder die Hardware der Interfaces noch der PCs/Notebooks und auch nicht die Software von RespeQt und AspeQt unter Linux und Windows verändert hatte, sind vmtl. Treiber und/oder Kernel verändert worden. Mit der Einstellung "NON" für Hardware Handshaking (heißt bei AspeQt "Wired...") funktionierte es dann wieder problemlos.

Es gibt allerdings auch Hardware/Software-Kombinationen am A8, die mit den SIO2PC(USB)-Interfaces ggf. Probleme verursachen können.

@Andreas: Wenn es immer noch der gleiche Laptop wie auf der letzten Fuji ist, dann liegt die Ursache höchstwahrscheinlich eher dort.

@Atarixle: Ich verwende unter Linux nachwievor deine Build, die auch irgendwo hier im Forum verlinkt ist. Die funzt einwandfrei . Das Herumexperimentieren ala Atariage habe ich mir geschenkt (PC-Link & BT). Es muss tagtäglich funzen, und dafür ist deine Build super. Featuritis ist mir nicht wichtig.

Was ggf. eine gute Idee wäre: ein "AppImage" der stabilen Build von dir erzeugen. Mit anderen Programmen unter Linux/Windows habe ich damit gute Erfahrungen gemacht.

atarixle hat geschrieben:Wobei ich staune, dass es unter Linux besser klappt als unter Windows. Meine Erfahrungen waren eher umgekehrt.
Aber es könnte auch an der CPU-Leistung liegen.

Welchen bzw. wessen Linux-Build nutzt du da?

Ganz normal Linux Mint 18.1 (Cinnamon)... CPU Leistung schließe ich bei einem Quad Core mit 3.1 GhZ einfach mal aus

Aber ich habe die Sache mit den Handshakes noch nicht getestet, werde ich dann heute Abend mal in Angriff nehmen und dann berichten... Auf jedenfall ziemlich nervig.....

GoodByteXL hat geschrieben:Das Herumexperimentieren ala Atariage habe ich mir geschenkt (PC-Link & BT) [...] Featuritis ist mir nicht wichtig.

Kannst Du den verächtlichen Ton nicht lassen?
Warum gibst Du nicht einfach zu, dass Du Dich mit dem Kompilieren von RespeQt nicht auskennst?
So lange atarixle es gemacht hat, war doch alles in Ordnung. Kaum macht er es nicht mehr, ist RespeQt pfui.
Als SDX Expert solltest Du am Besten zu schätzen wissen, wie gut und bequem PCLINK ist...

Ich werde mir heute Abend mal die R4 vornehmen ...

... nope, ich lass es ... mit jeder neuen RespeQt Version werden ältere Systeme, wie das derzeit noch aktuelle Debian 8 "Jessie", unbrauchbar. Ein neueres Linux benutze ich nicht, weshalb RespeQt R4 nun komplett nutzlos für mich ist. Selbst wenn ich es unter Debian 9 kompiliere, läuft es nicht unter Debian 8, welches mein aktuelles System auf all meinen Rechnern ist.

Soll sich jemand anders damit quälen ...

Es liegt wohl an Qt und nicht an RespeQt selbst.
Hast Du dieses Tool benutzt?

Es liegt an beiden.

QT liefert mit jeder neuen Minor-Version Inkompatibilitäten gegenüber der letzten Version.

Und RespeQt nutzt diese neuen Versionen - die wie gesagt - nichts in einem Minor-Update zu suchen haben.

Etwa 30 Jahre nach Windows 3.11 schafft es QT, die Funktion "always on top" mitzuliefern. Diese Funktion, die erst in QT 5.4 vorkommt, muss nun unbedingt von RespeQt benutzt werden, wodurch ich es nicht mehr in Debian 8 mit QT 5.3 kompilieren kann.

Ebenso irgend eine Funktion für den Seriellen Port, der bei QT erst mit Version 5 kam.
Wie zur Hölle hatte RespeQt mit QT 4.8 überhaupt kompiliert werden können?

Nee, Leute ... hat Spaß gemacht, aber das mach ich nicht mehr mit.

Seht Euch stattdessen SIO2BSD an (http://drac030.krap.pl/en-inne-pliki.php) - das Ding lässt sich vollkommen ohne irgendwas kompilieren und läuft einfach, ohne dass man tausendfach mit Handshake und all solch Zeug, von dem ich zu SIO2PC-Zeiten nie gehört hatte, herumexperimentieren muss.

... weil's mich nachts wachgehalten hat: http://atarixle.ddns.net/download/#respeqt

Cool
Danke

.. allerdings ohne Linux 32 Bit Support.

Wie schonmal im AtariAge-Forum erwähnt, läuft die Windows-Version hervorragend unter WINE.

Soooo...

GoodByteXL hat geschrieben:Letzten Winter funktionierte die seit ewigen Zeiten verwendete Einstellung "CTS" von "jetzt auf gleich" sowohl unter Linux Mint Cinnamon als auch Win 7 und Win 10 nicht mehr. Zuerst vermutete ich ein defektes Interface und tauschte es gegen mein Mobil-SIO2PC(USB) aus. Gleiches negatives Ergebnis! Beide Interfaces sind mit einem echten FTDI232R bestückt.

Da ich weder die Hardware der Interfaces noch der PCs/Notebooks und auch nicht die Software von RespeQt und AspeQt unter Linux und Windows verändert hatte, sind vmtl. Treiber und/oder Kernel verändert worden. Mit der Einstellung "NON" für Hardware Handshaking (heißt bei AspeQt "Wired...") funktionierte es dann wieder problemlos.

Nun laufen beide Interfaces ohne Veränderung wieder problemlos mit der Einstellung "CTS" für das Handshaking - sowohl unter Win als auch unter Linux. Habe Schwierigkeiten mit dem Schreiben in höherer Geschwindigkeit als SIO 1x unter Linux nach dem letzten Update. Unter Win alles bestens. Weiß der Bitgeier, was da los ist ...