Aber sicher, dass dies die v3.1 ist? Soweit ich mich erinnere, wurde die IP232 Einstellung erst später eingeführt.
Ich hab nix von "3.1" geschrieben. Bei mir läuft:
Bitte melde dich an, um diesen Anhang zu sehen.
Es gibt 64 Antworten in diesem Thema, welches 10.312 mal aufgerufen wurde. Der letzte Beitrag (
Aber sicher, dass dies die v3.1 ist? Soweit ich mich erinnere, wurde die IP232 Einstellung erst später eingeführt.
Ich hab nix von "3.1" geschrieben. Bei mir läuft:
Bitte melde dich an, um diesen Anhang zu sehen.
Du hattest leider überhaupt nicht dazu geschrieben, welche Version du nutzt.
Da ich ja, wie gesagt, die RS232-Schnittstelle nie benutzt habe, habe ich mal versucht, ein paar Infos zu finden. Vor allem wegen der Handshake-Leitungen.
Gibt's aber anscheinend nicht. Es gibt Hinweise, dass man irgendwie X-Draht aktivieren kann. Aber welche Handshake-Leitungen dann benutzt werdem, das seht nirgends. Beispiele Basic-Programme, die den Handshake nutzt, habe ich auch nicht gefunden.
Und was die Handshake-Einstellungen in Vice für eine Bedeutung haben, auch nicht.
Schade, ich fand das jetzt spontan, inspiriert durch diesen Thread, eine witzige Idee, mit Basic aus Vice heraus mit der Aussenwelt zu kommunizieren. Aber wenn man da erst mal solche Grundlagenforschung betreiben muss, dann ist mir das auch zu aufwändig.
Hier geht es ja eigendlich um das Thema zwei Vice-Rechner miteinander zu verbinden.
Trotzdem möchte ich mal meine Erfahrung mit der RS232 erzählen:
Ich habe hier einen Raspberrypi 400 und am USB-Anschluss einen billigen USB-Seriell Adapter.
An diesem habe ich einen Mikrocontroller ATtiny2313 über RX/TX angeschlossen.
Meine Einstellungen im Vice 3.6.1 SDL sind wie folgt:
Machine settings -> RS232 settings -> Userport RS232 emulation
Machine settings -> RS232 settings -> Userport RS232 baud rate -> 300
Machine settings -> RS232 settings -> Device 1 /dev/ttyUSB0
Machine settings -> RS232 settings -> Device 1 baut rate -> 300
Machine settings -> RS232 settings -> Device 1 use IP232 protocol
Das Basic-Programm aus der 64'er habe ich mal angehängt.
Bei einer Verbindung mit 300 Baud, kann ich aus dem Vice-Emulator mit dem Microcontroller kommunizieren.
Nicht besonders schnell, aber es geht.
![]()
Weiß irgendjemand, was es mit diesem komischen IP232-Protokoll auf sich hat? Was ist das?
Weiß irgendjemand, was es mit diesem komischen IP232-Protokoll auf sich hat? Was ist das?
Readme von Vice 3.4 auf csdb :
- added support for the IP232 protocol that was used by the long lost VICE1.19
hack, and which is supported by tcpser for emulating DTR/DCD (carrier detect)
Gerade mal mit größeren Datenmengen probiert. Vom Telnet-Server zu Vice. Mit 1200 Baud.
Das funktioniert bei mir weder mit Vice 3.1 noch mit Vice 3.6 fehlerfrei.
Vice 3.1 scheint einen internen Puffer zu haben, der erst nach 11 Zeilen überläuft.
Bei Vice 3.6 sind von Anfang an Fehler drin.
Genau meine Beobachtung, außer daß ich dachte, die 3.1 würde korrekt funktionieren. Bei der 3.6 stimmt es ja schon nach wenigen Zeichen nicht mehr.
Macht auch keinen Unterschied ob ich IP232 aktiviert habe oder nicht. IP232scheint ja auch nur für tcpser zu sein.
Wobei ich nicht glaube, dass das ein Fehler von Vice ist. Ohne Handshake läuft der Puffer des C64 sehr schnell voll (256 Byte habe ich inzwischen gelesen) und dann gehen Zeichen verloren. Das ist bei RS232 ganz normal. Man muss also rausfinden, wie der Handshake funktioniert. Aber ich habe dazu nichts gefunden.
Eine andere Möglichkeit wäre, dass man blockweise überträgt. Also zum Beispiel immer 128 Byte (oder variable Größe, ggf. mit Prüfsumme) und dann jeden Block bestätigt. Dann braucht man keinen "Hardware"-Handshake. Xon/Xoff wäre auch eine Möglichkeit.
Ich probiere das morgen mal blockweise.
Ich hab nix von "3.1" geschrieben. Bei mir läuft:
Ich sehe dass du eine aktuellere Version nutzt, für meine Mint Version gab es halt nur 3.1.
Da ich über "apt install" keine neuere Version aus den Standardquellen bekomme muss ich mir eine selber kompilieren (das hasse ich).
Alles anzeigenWobei ich nicht glaube, dass das ein Fehler von Vice ist. Ohne Handshake läuft der Puffer des C64 sehr schnell voll (256 Byte habe ich inzwischen gelesen) und dann gehen Zeichen verloren. Das ist bei RS232 ganz normal. Man muss also rausfinden, wie der Handshake funktioniert. Aber ich habe dazu nichts gefunden.
XOn/XOff Handshake
Der Handshake müsste durch 'einschalten' funktionieren, also XOn/XOff (Software bzw. 3 Wire Handshake) müsste durch die internen Treiber des C64 selbst gesendet werden. Ein Nachteil des XOn/XOff Handshakes besteht darin, dass man dann keine 'Raw-Data' übertragen kann sondern auf ASCII (z.B. Bin -> Hex Wandlung) umsteigen muss, da bei Binärzeichen ganz zufällig auch die XOn/XOff Character drinnen sein könnten.
RTS/CTS Handshake
Dann gibt es noch den RTS/CTS Handshake das heist die Schnittstellen signalisieren über zusätzliche Handshake Leitungen dass sie Empfangen können.
Wenn die Treiber beim C64 korrekt geschrieben sind dann müssten beide Handshakes funktionieren, ich würde aber nicht meine Hand dafür ins Feuer legen.Ein Handshake durch User Software unter BASIC kann man vergessen, BASIC weiß nichts über den genauen Zustand der Sende oder Empfangsbuffer.
Es gibt noch die Möglichkeit ohne Handshake zu arbeiten, dabei muss man dafür sorgen dass der Empfänger die Bytes schnell genug abholen kann und ich weiß nicht ob das eine Basic Programm beim C64 noch bei 1200 Baud garantieren kann. Ich weiß auch nicht wie gut Vice darin ist auf RTS/CTS Handshake Signale zu reagieren.
Eigentlich wäre es das Beste gewesen auf dem simulierten C64 einen speziellen Treiber zu nutzen, der eine Art 'virtuellen ACIA' zur Verfügung stellt. Vice könnte direkt nachsehen welche Bytes er übertragen soll und Handshake Signale generieren. Ich vermute aber dafür gibt es zu wenig Nachfrage.
Ich habe noch ein wenig Probleme mit dem Zitieren in diesem Forum ... werde ich noch lernen.
Früher(tm) hab ich mal Daten per ser. Schnittstelle vom Amiga zum C64 übertragen und dort auf EProms gebrannt.
Die Datenübertragung übernahm ein Basic Programm*, alles selber geschrieben, Details weiß ich nicht mehr, außer dass ich wohl irgenwelche Geschwindigkeiten zwischen 600 und 1200 Baud feherfrei hinbekommen zu haben.
* Auf dem Amiga wurden die Daten IMR mit 'copy data.txt ser:' übertragen, auf dem C64 wurden sie empfangen und wohl in eine Datei geschrieben.
Dann gibt es noch den RTS/CTS Handshake das heist die Schnittstellen signalisieren über zusätzliche Handshake Leitungen dass sie Empfangen können. Wenn die Treiber beim C64 korrekt geschrieben sind dann müssten beide Handshakes funktionieren, ich würde aber nicht meine Hand dafür ins Feuer legen.
Ein Handshake durch User Software unter BASIC kann man vergessen, Basic weiß eigentlich nichts über den Zustand der Sende oder Empfangsbuffer.
Die Informationen über den Pufferzustand würde man wohl rausbekommen, aber du hast recht. Es macht keinen Sinn, das in Basic zu handhaben.
Bleibt die Frage, welcher Handshake implementiert ist. Daszu müsste man ins ROM schauen. Das ist mir alles zu aufwändig.
Wenn ich beide Seiten selbst programmiere, dann favorisiere ich wie schon gesagt, den blockweisen Transfer mit Rückmeldung. Bei einer Puffergröße von 256 Byte würde ich eine maximale Blocklänge von 128 Byte wählen.
Nehmt einfach CCGMS als Terminalprogramm, das schafft 4800 Baud per Userport ohne Flowcontrol (RTS/CTS).
Und per UP9600 dann halt 9600 Baud mit Flowcontrol.
Nehmt einfach CCGMS als Terminalprogramm, das schafft 4800 Baud per Userport ohne Flowcontrol (RTS/CTS).
Und per UP9600 dann halt 9600 Baud mit Flowcontrol.
Wer sagt denn, dass auf dem C64 ein Terminalprogramm laufen soll? Ich weiß nicht, was C64-Opa genau vor hat, aber ich will da eine eigene Software laufen lassen, die über die RS232 kommuniziert.
In BASIC kannst Du halt nicht mehr als eine dreistellige Baudzahl realisieren, sonst gehen halt Daten verloren, außer, Du baust Flowcontrol mit ein (dann kannst Du von BASIC Brutto 1200 Baud machen mit Netto 300 Baud). ![]()
Ich habe ja gar keine besonderen Geschwindigkeitanforderungen. Erst mal soll es überhaupt funktionieren.
Ich habe noch ein wenig Probleme mit dem Zitieren in diesem Forum ... werde ich noch lernen.
Darunter dann die Antwort auf einen zitierten Bereich hineinschreiben, also in das etwas andersfarbige unten, nicht direkt oben in diesen zitierten Bereich mit hinein. Das war dein Fehler. ![]()
Im ROM des Amiga ist der RTS/CTS Handshake und der XOn/XOff Handshake implementiert, man braucht gar nicht ins ROM zu schauen.
Das Ganze ist hier Bitte melde dich an, um diesen Link zu sehen. recht gut beschrieben
Der Handshake wird noch mal hier erklärt:
Bitte melde dich an, um diesen Link zu sehen.
Das 'X-Draht' Protokoll benutzt die Leitungen RTS/CTS um seinem Gengenüber zu sagen ob er was empfangen kann.
Das 3-Wire bzw. XOn/XOff Protokoll benutzt dazu spezielle Datenworte (XOn/XOff).
Laut Dokumentation gibt es keine Version ohne Handshake, will man mit 3 Leitungen (Masse, TXD, RXD) auskommen, dann wählt man eben das mit XOn/XOff
Ich habe die Schnittstelle mit folgendem Kommando angesprochen:
Und das steht für:
- 300 Baud
- 8 Datenbits
- Keine Parity Bit
- 1 Stopbit
- 3 wire bzw. XOn/XOff bzw Software Handshake
- Vollduplex
Möchte ich RTS/CTS Handshake haben dann würde das so aussehen:
Jetzt hat die C64 Schnittstelle 2 richtig doofe Probleme:
1. Das Rausschieben der einzelnen Datentbits geschieht in Software
2. Handshake (auch bei RTS/CTS) geschieht auch in Software
Ist der C64 zu langsam um die einzelnen Datenbits am Userport rechtzeitig abzufragen oder zu senden dann sind die Ergebnisse verkehrt, egal ob der Handshake richtig eingestellt ist.
Bei Vice habe ich das zusätzliche Problem, dass ich nicht weiß ob er die Bits richtig abfragt und interpretiert, so wie es hier aussieht könnte es da Probleme geben.
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.
Ich habe ja gar keine besonderen Geschwindigkeitanforderungen. Erst mal soll es überhaupt funktionieren.
Sehe ich auch so.
Habe nochmals mit v3.2 kurz getestet, da funktioniert es aber doch gut selbst mit relativ langen Zeichenketten:
Bitte melde dich an, um diesen Anhang zu sehen.
Mit derselben Zeichenkette in v3.6, da fehlen massenhaft Zeichen:
Bitte melde dich an, um diesen Anhang zu sehen.
Das war eine einzige Kette
1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ
Ist doch ordentlich lang.
Allerdings hat der ja offenbar das Progrämmchen auch genau auf VICE angepaßt, kann also ja auch sein, daß es so auch nicht korrekt läuft auch realer Hardware. ![]()
Ich warte mal gespannt auf blockweisen Transfer. ![]()