Hallo Besucher, der Thread wurde 5,4k mal aufgerufen und enthält 28 Antworten

letzter Beitrag von sauhund am

TCP/IP over IEC

    Was ist an TCP/IP resourcenfressend?


    Natürlich muß der C64 keine 64k-Jumbo-Frames beherschen.


    Die Packets kann man in der Grösse beschränken, Stichwort MTU/MRU. Ich denke 256 Bytes inkl. Header wären ein guter Defaultwert für IP-over-IEC.


    Natürlich könnte man auch ATM oder X.25 über IEC fahren aber da siehts bei der C64-Software noch dünner aus :-)


    Egal, trennen wir mal die Probleme:


    1. PCs mit derzeitig üblichen Kabeln können nicht als Peripheriegerät verwendet werden. Das ist eher eine Hardwarefrage und keine Softwarefrage und das emu1541-Kabel zeigt daß es mit minimalem Mehraufwand auch besser geht.


    2. Eine Software für den PC braucht man natürlich um den rohen IEC-Traffic zu verwalten, aber auch um auf Talk/Listener-Ebene zu kommunizieren. Sobald das steht dürften weitere Spielereien nur noch Fingerübungen sein, z.B. Dienste unter verschiedenen Gerätenummern, mehrere Dienste auf einem Rechner, D64-Images, G64-Images, Unix-Verzeichnissse, cbm2cups-Filter usw...


    3. TCP/IP over IEC ist nur eine Spezifikationsfrage. Sobald man die IEC-Verkabelung und die PC-Software fertig hat muß sich halt mal jemand hinsetzen und etwas definieren und dabei mitdenken und das dann noch in C64- und Linux-Netzwerktreiber umsetzen. Das ist was ganz anderes als die IEC-Treiber und kann theoretisch auch erst sehr viel später implementiert werden.


    Ist also doch etwas umfangreicher und die Idee "TCP/IP over IEC" wird da zu einer klitzekleinen Nebensächlichkeit.


    Trotzdem ist das ein interessanter Ansatz da die Hardware weit einfacher als alle Alternativen sind, weil man dann wirklich ohne Disketten am C64 arbeiten kann und somit die langsam sterbenden Laufwerke und Disketten in Rente schicken kann und der wichtigste Punkt, IEC ist die lingua franca zur externen Kommunikation auf dem C64, über IEC kann man die Funktionen von sehr vielen Spezialbauteilen (RR-Net, MMC64 und viele andere) problemlos ersetzen und das bei höherer Kompatibilität.

    Neue Nachricht für eine konkretere Frage:


    Das emu1541-Kabel erledigt ja eine Funktion bereits in Hardware. Jetzt behaupte ich mal daß eine billige 8Bit-Atmel-Einchip-CPU auch nicht viel aufwändiger in ein Superkabel zu integrieren wäre und dabei noch massiv leistungsfähiger wäre, sozusagen ein Protokollkonverter damit der PC nich so viel schwitzen muß. Dann ist man zwar nichtmal mehr emu1541-kombatibel aber wer kannte schon emu1541 und btw, die Seiten zu emu1541 findet man nichtmal mehr mit Google.


    Schön wäre es wenn das Kabel in beide Richtungen verwendet werden könnte, zum einen damit der C64 einen PC als Peripherielaufwerk verwenden kann und zum anderen damit man am PC ein C64-Laufwerk verwenden kann.


    Edit, wer nach dem richtigem Begriff sucht der findet auch noch Seiten zu 1541emu:


    http://members.surfeu.fi/1541/
    hochkompatibles Kabel
    einfaches Kabel

    Hallo,


    Zitat

    Original von Crass Spektakel
    Natürlich muß der C64 keine 64k-Jumbo-Frames beherschen.


    Die Packets kann man in der Grösse beschränken, Stichwort MTU/MRU. Ich denke 256 Bytes inkl. Header wären ein guter Defaultwert für IP-over-IEC.


    Mir scheint du verstehst den Sinn der MTU/MRU nicht. Sie beschränkt die Größe der Transmission Unit (bei MTU), nicht aber die Größe der zu übertragenden Pakete. IP beherrscht eine Fragmentierung, d.h., größere Pakete werden zu kleineren "umgebaut" bevor sie versendet werden.


    Beispiel (ich ignoriere zur Vereinfachung der Ausführungen die Größen der Header und ein paar weitere Details;)): Angenommen, ich sende ein UDP-Paket mit 3000 Byte. Wenn der IP-Stack will (!) kann er dieses Paket in zwei Pakete zu 1500 Byte teilen und einzeln verschicken. Der Empfänger baut sie dann wieder zusammen.


    Nun kann dieser zerstückeln auch "zwischendurch" passieren: Ein Sender sendet ein Paket von 1500 Byte. Eine Leitung zwischendurch kann aber nur 1000 Byte maximal versenden. Dann teilt der Rechner oder Router, der über diese Leitung senden will, das Paket in zwei kleinere auf, und die Daten können trotzdem verschickt werden. (Ein Sender kann dies unterbinden, indem er das "Dont Fragment" (DF)-Bit setzt.)


    Setzt du die MTU also herunter hast du nicht viel gewonnen, da immer noch 64 KB-Pakete ankommen können, bloß nun halt gestückelt. Im Endeffekt vergrößerst du also die Last auf dem C64, da er nun sogar mehrere Frames verarbeiten muss.


    Im übrigen gibt es eine Mindestgröße für die MTU, die bei 576 (?) Byte liegt.




    Zitat


    1. PCs mit derzeitig üblichen Kabeln können nicht als Peripheriegerät verwendet werden. Das ist eher eine Hardwarefrage und keine Softwarefrage und das emu1541-Kabel zeigt daß es mit minimalem Mehraufwand auch besser geht.


    So ist das falsch. Es ist ein Software- bzw. OS-Problem. Mit einem Echtzeitbetriebssystem (QNX, RT-Linux), welches mir garantiert in 1/2-Millisekunden-Rastern einen Timer aufrufen kann, wäre dies absolut kein Problem. Natürlich ist das 1541emu-Kabel eine Hardware-Lösung für das Software-Problem (übrigens auf die gleiche Art, wie auch Commodore das gelöst hat), allerdings liesse sich das Problem eben doch völlig problemlos in Software lösen, wenn die Systeme das hergeben würden. Windows z.B. schafft maximal ein Millisekunden-Raster, und das auch nicht garantiert.


    Zitat

    Original von Crass Spektakel
    Das emu1541-Kabel erledigt ja eine Funktion bereits in Hardware. Jetzt behaupte ich mal daß eine billige 8Bit-Atmel-Einchip-CPU auch nicht viel aufwändiger in ein Superkabel zu integrieren wäre und dabei noch massiv leistungsfähiger wäre, sozusagen ein Protokollkonverter damit der PC nich so viel schwitzen muß. Dann ist man zwar nichtmal mehr emu1541-kombatibel aber wer kannte schon emu1541 und btw, die Seiten zu emu1541 findet man nichtmal mehr mit Google.


    Natürlich kann man das Problem mit einem Mikrocontroller problemlos lösen. Immerhin wird da auch schon daran gearbeitet. Ein großes Problem, dass ich dabei sehe, ist allerdings, dass sich das ganze kaum jemand antun wird. Ein X?1541-Kabel kann noch fast jeder selbst bauen. Eine Mikrocontroller-basierte Lösung hingegen ist schon deutlich aufwendiger.


    Das 1541emu-Kabel hat auch den gravierenden Nachteil, dass es NUR als Slave geeignet ist. Den SC z.B. könnte man daran nicht betreiben, weil das 1541emu-Kabel keine Möglichkeit hat, ATN zu aktivieren.


    Besitzt hier jemand ein 1541emu-Kabel? Gegen eine zur-Verfügung-Stellung könnte ich mir vorstellen, Support dafür in cbm4win/cbm4linux einzubauen.


    Zitat


    Schön wäre es wenn das Kabel in beide Richtungen verwendet werden könnte, zum einen damit der C64 einen PC als Peripherielaufwerk verwenden kann und zum anderen damit man am PC ein C64-Laufwerk verwenden kann.


    Das Problem hier ist, dass der Parallel-Port hierfür eine Leitung zu wenig besitzt. Man muss das Problem also durch aufwendigere Hardware lösen (wobei dann z.B. IMHO direkt eine USB-Lösung am günstigsten wäre).


    Gruß,
    - Spiro.

    Zitat

    Mir scheint du verstehst den Sinn der MTU/MRU nicht. Sie beschränkt die Größe der Transmission Unit (bei MTU), nicht aber die Größe der zu übertragenden Pakete. IP beherrscht eine Fragmentierung, d.h., größere Pakete werden zu kleineren "umgebaut" bevor sie versendet werden.


    Nein, das paßt schon. Daß ich die Grösse der zu empfangenden Packets nicht auf dem Empfänger sondern auf dem Server einstellen muß ist mir bekannt. Da bei IP-over-IEC sowieso ein PC dazwischensteckt kann man auf dem die MTU passend setzen und schon paßts.


    Die 576 Bytes Minimum gelten imho nur für TCP-over-Ethernet, aber im Prinzip ists egal, man muß sich nur auf einen sinnvollen Wert einigen. 576 ist ja recht sinnvoll.