Wo hast du deine Vice 3.4 GTK Version her?
Wenn ich auf Bitte melde dich an, um diesen Link zu sehen. gehe finde ich dort alles außer Linux.
Hast du dieses Package benutzt:
Bitte melde dich an, um diesen Link zu sehen.
Es gibt 64 Antworten in diesem Thema, welches 10.340 mal aufgerufen wurde. Der letzte Beitrag (
Wo hast du deine Vice 3.4 GTK Version her?
Wenn ich auf Bitte melde dich an, um diesen Link zu sehen. gehe finde ich dort alles außer Linux.
Hast du dieses Package benutzt:
Bitte melde dich an, um diesen Link zu sehen.
Wo hast du deine Vice 3.4 GTK Version her?
In Lubuntu 20.04 ein "sudo apt install vice" gemacht.
Du hast gut erkannt, dass Blöcke mit eigener Prüfziffer die Fehler bei der Datenübertragung verringern können, daher gibt es Lösungen um Fehler zu erkennen. Mit dem Parity Bit kann man eine 1-Bit Prüfzahl für jedes Byte festlegen, Protokolle wie XModem übertragen die Bytes als Block und senden Prüfsummen mit: Bitte melde dich an, um diesen Link zu sehen.
Viele Terminalprogramme biten XModem zur Datenübertragung.
Bringt mich allerdings nicht weiter, da ich wesentlich kürzere Datenmengen übertragen möchte.
Xmodem wäre doch etwas aufwändig.
Eher variable Blocklänge: Vorneweg ein Startbyte, die Blocklänge, die Daten, und am Ende eine Prüfsummenbyte.
Sowas in der Art.
Ich warte mal gespannt auf blockweisen Transfer.
Leider werde ich es wohl heute doch nicht schaffen. Das muss also noch etwas warten.
Ok, einen schnellen Test habe ich gerade noch gemacht. Und zwar sende ich einfach von meinem TCP-Server eine fest Anzahl von Zeichen und schaue, bis zu welcher Anzahl die vom Basic-Programm in Vice noch fehlerfrei empfangen werden. Mit einzelnen Zeichen hat das ja immer funktioniert. Mit beiden von mir getesten Vice-Versionen.
Ergebnis:
Die Version 3.6 schafft es nicht mal 20 Zeichen am Stück fehlerfrei zu empfangen. Drunter habe ich gar nicht probiert, weil das für ein Block-Protokoll zu wenig ist. Egal ob mit oder Handshake, bei einem Empfangspuffer von 256 Byte sollte der Empfang von 20 Zeichen am Stück kein Problem sein.
Aber: Mit der Version 3.1 (nicht GTK) schaffe ich es, 100 Byte am Stück fehlerfrei zu empfangen. So wie ich das eigentlich erwartet hatte Damit könnte man ein Block-Protokoll implementieren. Das Problem liegt also offensichtlich nicht an der Implementierung im C64-ROM sondern in Vice.
Das zeigt mal wieder, dass die neuen Vice-Versionen einfach grottig schlecht und viele Dinge nicht zu gebrauchen sind.
Man müsste jetzt noch mal verschiedenen Version probieren und die Changelogs durchschauen, ob in diesem Bereich mal iirgendwas gefixt wurde. Sorry, das ist mir zu aufwändig. Da habe ich hier genügend Projekte, als dass ich Lust hätte, wieder mit den Vice-Entwicklern rumzudiskutieren. Das brauche ich nicht mehr.
Also eigentlich, wie man es schon beim Basic-Progrämmchen gesehen hat: v3.6 (im Gegensatz zu v3.2) schafft es ja auch dort kaum, 20 Zeichen fehlerfrei zu übertragen.
Und vermutlich wurde das Problem exakt mit den zusätzlichen Settings für die "control lines" eingeführt.
Also ich habe jetzt den Code bei Sourceforge geladen, etwa 20 benötigte Ressourcen mit 'apt install' installiert und dann übersetzt, hat nur ein paar Stunden gedauert und dann hatte ich eine '3.4 (GTK3 3.22.30, GLib 2.56.4)' vielleicht ist Mint doch nicht so schön wie es aussieht.
Ich konnte jetzt aus einer Linux Shell Daten auf die serielle Schnittstelle im Vice übertragen und umgekehrt.
Mir ist es noch nicht gelungen Daten zwischen zwei laufenden Vice Programmen zu übertragen, das Problem liegt wohl daran dass man zuerst mit 'socat' die Umleitung starten muss und die Einstellung vom Vice beim Neustart aktiviert wird, letzteres ist ziemlich blöd, wenn man jedem Vice ein unterschiedliches Setting RS232 geben will, es scheint nur beim Neustart aktiviert zu werden.
ps.:
Vielleicht hilft es wenn ich hier frage:
Wie hast du den Vice nach dem Ändern der RS232 Einstellungen dazu gebracht diese ohne Neustart zu benutzen?
Also eigentlich, wie man es schon beim Basic-Progrämmchen gesehen hat: v3.6 (im Gegensatz zu v3.2) schafft es ja auch dort kaum, 20 Zeichen fehlerfrei zu übertragen.
Und vermutlich wurde das Problem exakt mit den zusätzlichen Settings für die "control lines" eingeführt.
Das Problem ist, dass die Windows-Version ab Version 3.2 (?) komplett neu aufgesetzt wurden.
Da wurde alles mögliche umgebaut und anders implementiert. Und am Anfang lief da auch fast überhaupt nichts mehr.
Man erkennt das auch, an der völlig anderen Menü-Struktur und den geänderen Datei-Dialogen.
Deswegen kann das auch ein ganz grundsätzliches Timing-Problem dieser neuen Versionen sein.
Es ist für mich schmerzhaft, den Kausalketten hier zu folgen zu versuchen.
Weil etwas in Basic gerade nicht geht, was die letzten 40 Jahre schon nicht ging, sind die Vice-Entwickler Schuld.
Xmodem wäre doch etwas aufwändig.
Eher variable Blocklänge: Vorneweg ein Startbyte, die Blocklänge, die Daten, und am Ende eine Prüfsummenbyte.
Sowas in der Art.
xmodem hat feste Blocklängen und ein Blocknummer ist aber sonst ähnlich.
Ja, das stimmt schon. Der Overhead ist gar nicht so groß, wie ich dachte.
Aber die feste Blocklänge ist eher unpraktisch und auf die Übertragung von Dateien ausgelegt.
Hier mal mein Test unter Windows 10 mit GTK3VICE-3.6.2-dev-win64-r42493 (nightly von Github aus dem Juli 2022, das ist das neueste, was ich rumliegen hatte, ohne nochmal neu downzuloaden)
CCGMS Future v0.2: Bitte melde dich an, um diesen Link zu sehen.
Habe jetzt überall 300 Baud reingehauen für's erste. Habe den Eindruck, man muss mal im CMD-Fenster die "Sync ... is behind" beobachten, das beruhigt sich dann irgendwie nach ein paar Sekunden.... ?! und funktioniert dann.
EDIT: Habe jetzt auf 2400 Baud erhöht und geht auch.
Bitte melde dich an, um diesen Anhang zu sehen.
Bitte melde dich an, um diesen Anhang zu sehen.
Bitte melde dich an, um diesen Anhang zu sehen.
Bitte melde dich an, um diesen Anhang zu sehen.
Bitte melde dich an, um diesen Anhang zu sehen.
@Bitte melde dich an, um diesen Link zu sehen.
Theoretisch könnte Vice beim Simulieren eines ACIAs das komplette Byte lesen und müsste nicht die an einem simulierten Userport herausgeschobenen Bits interpretieren.
Der ACIA auf der C64 Seite zusammen mit der Vereinfachung im Vice sollte eine wesentlich höhere Baudrate erlauben, die einzigen Problemchen dabei wäre die C64 Software die den ACIA unterstützen müsste bzw. ein gepatchtes Kernal.
Eine spezielle virtuelle Schnittstellen für die Zusammenarbeit mit VICE könnten die Funktion verbessern, ich befürchte da feht das wirtschaftliche Interesse.
Nur als Zwischenbemerkung an C64-Opa : Wenn du hier jemanden taggen möchtest, sodass die Person darüber auch benachrichtigt wird, tippe erst den Klammeraffen ein und direkt dahinter den Namen der Person. Das ist manchmal vielleicht etwas schwierig wegen Sonder- oder Leerzeichen. In diesem Fall kannst du so vorgehen: Nachdem du die ersten drei Zeichen eines Namens hinter dem '@' eingetippt hast, kommt auch schon eine Liste von Forumsmitgliedern mit zum eingetippten passendem Namen und du kannst dann per Anklicken die richtige Person auswählen. Manchmal sind aber auch mehr als drei Zeichen notwendig, bis der richtige Name zur Auswahl erscheint.
Bitte melde dich an, um diesen Anhang zu sehen.
Also man kann sehen dass es funktioniert.
Ich brauche jetzt nur noch etwas Gefühl für Vice.
Also von meiner Seite kann ich nur mitteilen, daß wenn ich eine Verbindung hinbekomme, geht die nicht schneller als 300 Baud.
Alles andere wird zu Datenmüll.
Sende ich eine Schleife von 0 bis 255 kommen auch alle Daten an, nur beim Empfänger dauert es etwas bis er die Daten empfängt.
Ok, ich hatte jetzt immer nur 1200 Baud getestet.
Habe jetzt überall 300 Baud reingehauen für's erste. Habe den Eindruck, man muss mal im CMD-Fenster die "Sync ... is behind" beobachten, das beruhigt sich dann irgendwie nach ein paar Sekunden.... ?! und funktioniert dann.
Ok, das waren jetzt Tests mit Terminalprogrammen. Die arbeiten ja ggf. ganz anders als die ROM-Routinen. Für mich macht das ganze nur Sinn, wenn es von Basic aus funktioniert. Ich teste das bei Gelegenheit nochmal mit 300 Baud.
Also man kann sehen dass es funktioniert.
Bei handgetippen Texten hatte ich übrigens gar keine Probleme. Die Probleme traten erst auf, als ich komplette Strings schnell hintereinander gesendet habe. Und ich habe bisher auch nur die Richtung TCP-Server zu Vice getestet, weil ich in der anderen Richtung ´gar nicht mit Problemen gerechnet habe. Bei Telnet bzw. TCP geht ja nichts verloren. Das müsste ich also auch noch mal testen.
Für mich macht das ganze nur Sinn, wenn es von Basic aus funktioniert.
Für mich macht es keinen Sinn, das in Basic zu machen.
Weil Basic wohl nicht nur zu lahm ist für erträgliche Baudraten, sondern auch zu lahm, um eine funktionierende Flow-Control hinzubekommen.
Und wie bringe ich das Terminalprogramm dazu, programmgesteuert automatisch Daten zu senden und empfangenen Daten zu verarbeiten?
Also bei mir hat die Verbindung zwischen Vice und netcat (also Terminal) bei 1200 Baud funktioniert (zumindest mit kurzen Strings)
Aber noch nicht zwischen Vice <-> Vice, ich werde es auch noch einmal mit 300 Baud testen.
Es ist ärgerlich, dass Netcat beim Beenden ein EOF schickt und der C64 (oder der Vice) dann die serielle Schnittstelle nicht mehr bedienen will.
Für mich sieht es so aus als ob ich Vice mit 'der richtigen' Einstellung starten muss, das geht aber nicht wenn ich die Einstellung nach dem Start ändern möchte.
Das Ganze ist ziemlich wackelig, Vice ist da keine große Hilfe, mit einem echten C64 war es irgendwie einfacher. So ist Vice als Entwicklungswerkzeug für RS232 Programme untauglich.
Schade ich wollte so was wie ein MUD versuchen, also so eine Art minimales Textadventure bei der mehrere Leute in einem Gebäude herumlaufen.
Meine Idealvorstellung wäre es gewesen, wenn jeder C64 die Zustandsvariablen (wer befindet sich wo und was hat er gesagt) zum nächsten C64 weiter geben, einen Ring (oder einen Tokenbus) kann man mit ein paar Kabeln sehr einfach aufbauen und vielleicht hätten 600 Baud schon für ein axeptables Spielergebnis bei 2-4 Teilnehmern gereicht.
Ich wollte das ganze mit Basic machen, so wie man auch Textadventures mit Basic schreiben kann, ich habe das auch eher als 'technische Demonstration und Programmierübung' gesehen.