Hello, Guest the thread was called4.5k times and contains 28 replays

last post from sauhund at the

TCP/IP over IEC

  • RR-Net hat mich bisher immer nur amüsiert. Sündhaft teure Hardware gegen ein Problem werfen das eigentlich keins ist.


    Am Wochenende ist mir eine Idee gekommen wie man das so richtig elegant lösen kann:


    Anstatt TCP/IP over Ethernet verwendet man TCP/IP over IEC, also das serielle Kabel für Peripherie. Das TCP/IP wird von einem Router eingespeist oder mit anderen Worten von einer preiswerten Linuxbüchse (hat sowieso jeder rumstehen) mit einem XA1541-Kabel am Parallelport der ausserdem mit dem Internet verbunden ist. Dann setzt man auf dem Router die Defaultroute aufs Internet und die


    Praxistest: Ich habe mir vc1541 geschnappt und übersetzt. Dieses Programm simuliert auf dem Server eine 1541 unter frei wählbarer Laufwerksadresse. Ausserdem kommt es mit einem normalem XA-Kabel aus und braucht nicht wie 1541emu ein Spezialkabel.


    Mit etwas gewürge habe ich das Programm übersetzt bekommen - die Compilersuite ist doch ziemlich historisch. Anschliessend habe ich etwas rumgebastelt und zumindestens den ersten primitiven Proof-of-Concept erreicht:


    Mein "Internet-Empfangs-Gerät" war unter Adresse 12 erreichbar, das Sendegerät unter #13. Natürlich hatte ich noch kein Routing, technisch gesehen habe ich nichtmal TCP/IP übertragen. Aber ich konnte beliebige Zeichenketten übertragen wobei mir allerdings der unfertige Status der Empfangsroutinen von vc1541 einige Steine in den Weg gelegt haben. Ich muß mich jetzt noch etwas tiefer in den Code einarbeiten, vieleicht bastle ich was komplett eigenes auf IEC-LISTEN/SEND-Ebene im Linuxrechner. Nicht wirklich ein Bereich in dem ich mich auskenne und Doku kenne ich dazu auch keine.


    Dann müßte man Contiki das IP-over-IEC-Protokoll beibringen. Ich habe Contiki nie zum Compilieren gebracht, aber das ist sicher machbar.


    Und zu guter Letzt muß man irgendwie das echte Routing auf Linux-Ebene hinbekommen. Das müßte theoretisch ohne Kernel-Support gehen, da man auch im Userspace Pakete generieren und weiterleiten kann aber im Idealfall macht mans im Kernel und hat dann eben ein Netzdevice IEC neben ETH0. Und natürlich müßte dieses Interface auch mit verrückten Lösungen zurechtkommen wie z.B. "mehrere C64 in einem IEC-Broadcast-Segment". Dann könnten mehrere C64 untereinander native vernetzt über IEC kommunizieren, was natürlich vorraussetzt daß jeder C64 mit einem erweitertem IEC-Stack auch verschiedene Adressen hat.


    Das ganze ist noch Lichtjahre von FERTIG entfernt. Aber insgesamt ein interessantes Konzept und die Geschwindigkeit ist durchaus ausreichend mit 300 Zeichen pro Sekunde - eben normales IEC-Protokoll. Eine XAP-Variante könnte sicher nochmals deutlich schneller arbeiten.


    Achtung, jetzt wirds richtig experimentiel:


    Im Idealfall hat man im PC einen Daemon der die IEC-Kommunikation sammelt und je nach Empfängeradresse an Dienste verteilt. Z.B. IEC#4 auf einen cups-Filter, #8 ignorieren weil das ein echtes 1541-Laufwerk ist, #9 landet in einem D64-Image, #10 ist ein Unix-Verzeichnis, #12 ist das Internet-Gerät. Und jeweils einen kleinen Dämon je Dienst, frei konfigurierbar und schön schlank.


    Und nein, 64HDD ist keine Alternative. Das kostet Geld und ist kein Opensource.


    Man schauen was aus meiner Idee so wird.

  • Hallo,


    nur ein kurzer Hinweis: Ausser für einen Proof-of-Concept würde ich nicht das originale IEC-Protokoll benutzen, sondern etwas anderes, was deutlich besser asynchron arbeiten kann. Ansonsten frißt dir die Kommunikation gerade auf der Linux-Seite die wertvolle Prozessorzeit weg.


    Denke auch daran, dass unter Linux (und Windows) bislang kein stabiler "64hdd-Ersatz" vorhanden ist. Das liegt an dem verfl***ten Timing, welches die Kiste bei allzu einfacher Implementierung komplett stillegen würde. Es ist nun einmal einfacher, als Controller am IEC-Bus zu opererieren, als das operieren als gesteuertes Gerät.


    Also: Die Hardware kannst nutzen, das Protokoll solltest du dir aber selbst überlegen. C64-seitig sollte es in der Lage sein, auch größere Wartezeiten auf Seiten des PCs zu verkraften ohne Fehler zu erzeugen.


    Gruß,
    - Spiro.

  • vc1541 scheint damit gut zurecht zu kommen. Immerhin hat es in der letzten Release Support für XE-Verkabelung bekommen, das entlastet schon mal ganz dramatisch das Timing da die Kommunikation so sauber Interrupts auslösen kann (können sollte nach meinem Verständnis).


    Aber Du hast Recht, irgendwie ist das ganze X/XH/XE/XA-Kabel-Zeug ziemlich verwurstet. 1541emu verwendet ein anderes Kabel und scheint ein effizienteres Timing hinzubekommen.


    Es ist auch garnicht so einfach sich bei IEC auf etwas festzulegen: Das eigentliche IEC-Protokoll wird bei Speedern ja nur dazu verwendet die Verbindung herzustellen und die Parameter zu übermitteln, danach gehts relativ protokolfrei durchs Gemüsebeet. Die Aussage "TCP/IP over IEC" wird dann ganz schnell zu "TCP/IP over IEC-Cabel with new protocol". Denn wenn man das alte IEC-Protokoll über Bord wirft dann macht auch eine XAP-Verkabelung Sinn und da bleiben richtig Reserven bei der Bandbreite und das Timing wird auch entspannter.


    Back to Topic: Ich meine mit einer XE/XA-Verkabelung, also gekreuzte Kabel und Interrupts über ATN-Leitung, da sollte das IEC-Protokoll nur sehr wenig Resourcen schlucken. Sehe ich das richtig?


    Insgesamt stellt sich die Frage ob man mit einer XAP-Verkabelung etwas stabiles und nicht zu resourcenhungriges unter Linux hinbekommt. Ich sags ganz ehrlich, ich weis es nicht. Zu meiner vollaktiven C64-Zeit gabs kein Linux, selten Parallel-Verkabelung und schon garkeine XAP-Verkabelung. Auf jeden Fall ist die C64-Seite nicht das Problem sondern die Art der Verkabelung und die Fähigkeit mit Interrupts unter Linux auf IEC-Traffic zu reagieren.

  • das problem ist wohl das unter gängigen desktop multitasking betriebssystemen ein interupt nicht wirklick "sofort" bearbeitet wird (werden kann). selbst mit kernel treibern ist das noch immer problematisch. darum brauchst du idealerweise ein komplett asynchrones protokoll.


    davon ab sind lpt ports etwas das ausstirbt, daher sind ethernet oder usb auf dauer wohl die bessere lösung.

  • Hallo,


    Quote

    Original von Crass Spektakel
    vc1541 scheint damit gut zurecht zu kommen. Immerhin hat es in der letzten Release Support für XE-Verkabelung bekommen, das entlastet schon mal ganz dramatisch das Timing da die Kommunikation so sauber Interrupts auslösen kann (können sollte nach meinem Verständnis).


    Nein, leider nicht. Der Grund für das XM und XA-Kabel findet sich auf meiner Homepage hier: http://cbm4win.sf.net/#faq_hw ("Why are the X1541 or XE1541 cables not supported?").


    Diese Beschreibung bezieht sich allerdings nur auf das "Listener-Hold-Off", genauer: Auf die Reaktionszeit, wenn ich als Antworter kein EOI signalisieren will. Dann muss ich zwingend innerhalb von 200 us reagieren können. Das geht nur mittels Interrupt, deshalb ist das XM-Kabel so verschaltet wie es ist.


    Wenn ich mich nun als ein Nicht-Controller (z.B. als Floppy) ausgebe, dann habe ich noch eine andere Zeit, die ich einhalten muss: Sofern der Computer sein ATN aktiviert, muss ich innerhalb von 1 ms antworten. 1 ms hört sich viel an, allerdings muss ich hier ja pollend zugreifen, da das ATN keinen Interrupt erzeugen kann. So gesehen wird 1 ms schon relativ schwer.


    Das ist auch der Grund, wieso cbm4win/cbm4linux nicht "die andere Seite" unterstützen, d.h., sich nicht als Floppy ausgeben können. Das könnte irgendwann mal ergänzt werden, falls wir da eine gute Lösung für finden.


    Quote


    Aber Du hast Recht, irgendwie ist das ganze X/XH/XE/XA-Kabel-Zeug ziemlich verwurstet. 1541emu verwendet ein anderes Kabel und scheint ein effizienteres Timing hinzubekommen.


    Richtig, 1541emu erzeugt diese Antwort auf ein ATN per Hardware - übrigens genau so wie auch eine echte 1541-Floppy. Deshalb ist 1541emu da auch unkritisch.



    Quote

    Ich meine mit einer XE/XA-Verkabelung, also gekreuzte Kabel und Interrupts über ATN-Leitung, da sollte das IEC-Protokoll nur sehr wenig Resourcen schlucken. Sehe ich das richtig?


    Mit XE-Kabel: Definitiv nicht, da wird das Halten das Timing ein reines Glücksspiel, siehe obigen Link. Mit XM-Kabel sieht das anders aus, da geht es, sofern der Interrupt rechtzeitig ist (das ist nicht selbstverständlich, weder Linux noch Windows sind Echtzeitsysteme!). Allerdings greifen XM/XA-Kabel nicht das ATN-Problem an, sondern das "non-EOI-Response" - Problem.


    Quote


    Insgesamt stellt sich die Frage ob man mit einer XAP-Verkabelung etwas stabiles und nicht zu resourcenhungriges unter Linux hinbekommt. Ich sags ganz ehrlich, ich weis es nicht.


    Wie gesagt, wir denken daran, eine Lösung zu finden. Allerdings wird das schon recht heftig in die Resourcen gehen.


    Ürigens sehe ich das alles ähnlich wie "sauhund", wobei ich persönlich eine USB-Lösung anstreben würde, idealerweise mit der cbm4linux/cbm4win-Schnittstelle.


    Gruß,
    - Spiro.

  • Quote

    Original von sauhund
    ich würde ja was bauen was sich nach aussen hin als usb massenspeicher meldet.....dieser ganze cbm4irgendwas kram ist doch auch frickelware :)


    He! Nicht persönlich werden! ;)


    Es spricht ja nichts dagegen, beides zu ermöglichen. Ich würde ja auch den umgekehrten Fall mögen, dass der PC als Massenspeicher für einen C64 dienen kann.


    USB bietet da einige Möglichkeiten.


    Gruß,
    - Spiro.

  • lol :)


    ne, das schöne an der usb-massenspeicher lösung wäre ja das man da auf pc seite keine software brauchen würde, und damit viele probleme sich garnicht erst stellen.


    andersrum wäre dann entweder ein relativ hoher hardwareaufwand angesagt (hostfähiger usb chip, mikrocontroller mit genug dampf etc) oder es liefe wieder auf irgendeine speziallösung mit software raus (die nicht nur jemand schreiben, sondern auch aktuell halten muss). gefällt mir beides nich so doll wenn ich ehrlich bin.

  • Quote

    Original von sauhund
    ne, das schöne an der usb-massenspeicher lösung wäre ja das man da auf pc seite keine software brauchen würde, und damit viele probleme sich garnicht erst stellen.


    Das stimmt. Dennoch: Man kann es so schaffen, dass einerseits keine extra Hardware notwendig ist, andererseits aber die "Extra-Funktionen" trotzdem erreichbar sind.


    Quote

    andersrum wäre dann entweder ein relativ hoher hardwareaufwand angesagt (hostfähiger usb chip, mikrocontroller mit genug dampf etc)


    Wieso müßte der USB-Chip hostfähig sein? Für den PC ist das immer noch ein Slave.


    Gruß,
    - Spiro.

  • Quote

    Wieso müßte der USB-Chip hostfähig sein? Für den PC ist das immer noch ein Slave.


    ehrm was? wenn du da *ohne* irgendeine speziallösung in software was auf der andren seite dran anschliessen willst, dann läuft es auf einen usb host raus. das es auch anders geht steht ausser frage, aber das wäre dann keine "plug&play" lösung mehr.

  • Quote

    Original von sauhund
    ehrm was? wenn du da *ohne* irgendeine speziallösung in software was auf der andren seite dran anschliessen willst, dann läuft es auf einen usb host raus.


    Ah, jetzt verstehe ich was du meinst. Einfach dieses USB-Gerät plus Festplatte, USB-Stick oder ähnliches, und das Teil soll funktionieren. Richtig? Dann bräuchte man tatsächlich einen Host-fähigen USB-Chip.


    Gruß,
    - Spiro.

  • Quote

    Original von Fröhn
    Und dann USB wollen. USB ist definitiv die KOMPLIZIERTERE Variante und nicht das RR-Net.


    Man beachte, dass die Zitate von unterschiedlichen Personen stammen.


    Im übrigen ist USB gar nicht so kompliziert, sofern man die richtigen Chips hat. Da dürfte es nicht deutlich komplizierter als RR-Net sein, aber dafür weitaus flexibler.


    sauhund: Ich sehe das Problem bei cbm4x nicht, ausser, dass man wegen des Timings etwas "unsauberes" mit dem Kernel machen muss. Mit einem USB-Treiber wäre das hingegen nicht notwendig.


    Gruß,
    - Spiro.

  • Quote

    Original von strik
    Im übrigen ist USB gar nicht so kompliziert, sofern man die richtigen Chips hat. Da dürfte es nicht deutlich komplizierter als RR-Net sein, aber dafür weitaus flexibler.


    Na das glaub ich nicht. Für USB braucht man auch einiges an Hardware und dann noch Treiber für Windows etc. Bei RR-Net ist halt im Endeffekt nur ein CS8900A da...


    Ausserdem: Warum ständig neue Lösungen zusammenfummeln, wenn es funktionierende und vor allem GUTE Lösungen gibt.

  • Quote

    Na dann muß man aber nen Embedded Controller zwischen USB und IEC klemmen, naja ist bei USB evtl sowieso nötig.


    ja, logisch. wenn das ganze auch nur ansatzweise brauchbar sein soll als "floppyersatz" muss das eh sein, fast egal bei welcher lösung. ich finds da auch schade das das rr-net so "dumm" ist, da hätte man auch gut den tcp/ip kram von nem kleinen controller erledigen lassen können. (wäre dann natürlich NOCH teurer geworden, auch klar)