Zwei C64 auf Vice sollen über RS232 Daten tauschen

Es gibt 64 Antworten in diesem Thema, welches 10.319 mal aufgerufen wurde. Der letzte Beitrag (2. November 2022 um 00:49) ist von -trb-.

  • 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.

  • 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)

    "Werter Pöbel, wertes Gesocks ... aus dem Arsche zieht euch den Stock ..."

  • 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).

  • Einmal editiert, zuletzt von C64-Opa (29. Oktober 2022 um 23:04) aus folgendem Grund: Typos und Ungenauigkeiten

  • 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.

    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • 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). :D

    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • 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. :)

  • detlef

    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:

    Code
    open 2,2,0, chr$(6)+chr$(0)

    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:

    Code
    open 2,2,0, chr$(6)+chr$(1)


    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

    Code
    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. :thumbsup: