Posts by MOS6510

  • Projekt "Etherbridge"

    Übrigens Etherbridge Version 2.0 ist raus! :thumbsup: => Etherbridge V2.0


    Ein User hat auch bestätigt, dass die Software mit einer A2088XT und einer 3COM509 Netzwerkkarte im 8 bit XT Port funktioniert!
    Den entsprechenden Treiber hab ich mal angefügt (ist noch nicht im Etherbridge 2.0 Paket enthalten).


    Performance:
    Eine A2088XT schafft etwa 78kb/s (Roadshow+FTP, 68030/40MHz, Polling Mode)
    Meine A2286 schafft etwa 330kb/s (Roadshow+FTP, 68040/25MHz, Polling Mode)


    In den 90ern hatte ich mit der A2386 ähnliche Performance (AmitTCP+FTP, 68040/25MHz, Interrupt Mode).
    Meine A2386 ist derzeit leider defekt. Daher hab ich im Moment keine Geschwindigkeitstests mit dieser Karte.



    Viele Grüße,
    Heiko

    Files

    • 3C509.COM.zip

      (5.91 kB, downloaded 4 times, last: )

  • Projekt "Etherbridge"

    Der Ebserver vom Etherbridge verwendet bei access_type() im Parameter "ethertype" den Wert FFFF, was Wildcard entspricht. Will heißen, gibt mir alles. Als Type wird "Ethernet" fix voreingestellt. Die Byteorder spielt hier also keine Rolle.


    Die Stelle sieht konkret so aus:


    C
    1. res = AccessType( pktDriverIntNumber,
    2. CL_ETHERNET, //class "Ethernet" (0x01)
    3. TYPE_ANY, //=> 0xffff: "type any"
    4. 0, //Unit number "0"
    5. NULL, //=> ALL
    6. 0, //=> Typ len == 0
    7. AsmPacketRecFunc //RX Callback
    8. );


    Nur mal angenommen, die Byteorder würde hier eine Rolle spielen, wie sollte sich dann eine falsche Byteoder der Adressfelder eines Paketes auf ein Vertauschen der Nutzdaten der Pakete selbst auswirken? Wären die Adressen verdreht (durch falsches Big/Little Endian) wäre nur Empfänger und/oder Absender falsch, nicht aber die Nutzdaten des Paketes selbst. Du sagtest ja, du siehst jedes zweite Byte der Nutzdaten mit 0xFF.


    Da die Treiberansteuerung prinzipiell bei anderen Usern funktioniert, kann es aus meiner Sicht bei dir wirklich nur um einen lokalen Defekt einer Speicherseite liegen, also defekte obere/untere 8 bit ISA Hälfte oder in der Netzwerkkarte etc sein...


    VG, Heiko

  • Projekt "Etherbridge"

    Hast Du die "0xff Bytes" auch mit PKTSEND.com gesehen?
    Wenn jedes 2. Byte 0xff geschrieben wird klngt das für mich nach einem RAM-Defekt oder Bus-Defekt. Vielleicht auch einfach verdeckte Kontakte, entweder am Sockel der Netzwerkkarte oder eben auch an der Brückenkarte. Hast Du die schon mal gereinigt?

  • Projekt "Etherbridge"

    Hattest du mal mit den Testtools der Packet Treiber herumgespielt (PKTSEND.com, PKTTRAF.COM, PKTWATCH.com...) ?
    Wenn dann machen die DOS Treiber blöd, weil die Hardware vielleicht blöd macht (oberer Socket defekt, etc...).


    Etherbridge benutzt nur die DOS-Treiber, die natürlich laufen müssen.

  • Projekt "Etherbridge"

    Was ist eigentlich vor 4 Jahren daraus geworden? :-) Habt ihr es noch geschafft die Karten zum Laufen zu bekommen?


    Es wird nun Zeit für eine neue Version vom Etherbridge... :-)

  • 76. Marburger Stammtisch / Outback@Bytequest

    Auf vielfachen Wunsch :-) wollte ich gerne einmal in die Runde fragen, ob bei nächsten Treffen im Outback Interesse auf Bogenschießen besteht?


    Ich habe einen selbstgebauten 1,95m Langbogen. Eine Zielscheibe würde ich noch besorgen (nein, wir nehmen keinen Atari ST dafür ).
    Wir könnten auf Bytequest's Wiese einen kleinen Schnupperkurs dazu machen. Die Wiese liegt allerdings ein paar Minuten zu Fuß vom "Ponyhof" entfernt.
    Wegen der Sicherheit können wir das leider nicht direkt auf dem Hof machen.

  • i2c Schnittstelle Byteweise befehl übertragen

    ja, den Schaltplan hätte ich auch separat da. Über Kernel-Routinen kann man das natürlich nicht ansprechen. Da muss man in Assembler etwas selbst machen.
    Die Motorleitung wird als Datenleitung missbraucht...Es ist aber nicht schwer. Ist ja nur etwas "Bitwackeln" Die Codestellen hätte ich sogar auch da…aber wenn's das Buch in der Wolke gibt… :)