Hello, Guest the thread was called128k times and contains 574 replays

last post from thierer at the

ZoomFloppy als billiges Teensy Device

  • Können wir uns darauf einigen, dass weniger als eine Minute eine ziemlich gute Zeit ist? :thumbup:

    22 Sekunden für 40 Tracks ist eine "ziemlich gute Zeit". :)


    Allerdings benötigt OpenCBM immer mehr als 30 Sekunden.

    Dafür funktioniert es aber auch mit jedem Laufwerk.

    Und es nimmt die Mechanik nicht so her.


    Manche Speeder sind echt grenzlastig ...

  • Ok, also können die das auch. Bei OpenCBM in den alten Docs sind die ganz alten USB Kabel noch erwähnt. Die sind sehr langsam.

    Ich weiß nicht mehr wie der Modus in OpenCBM heißt. 'Burst Modus' kann schon hinkommen. Da hatte ich auch immer unter 1 Minute. Der normale Modus war deutlich langsamer. Ich habe mit Parallel Port, OpenCBM, Linux, Speeddoskabel (XM1541) und OC-118N kopiert.

  • Für das XUMFloppy gibt es jetzt wohl auch JiffyDOS Support. Hab es nur gelesen. Ich selber habe keine umgebauten Geräte, hab also Parallel-Übertragung nie probiert. :nixwiss:

    "Was heute noch wie ein Märchen klingt,kann morgen Wirklichkeit sein.Hier ist ein Märchen von übermorgen.Es gibt keine Kupferka­bel mehr,es gibt nur noch die Glasfaser und Terminals in jedem Raum.Man siedelt auf fernen Rech­nern.Die Mailboxen sind als Wohnraum erschlossen.Mit heute noch unvorstellbaren Geschwindigkeiten durcheilen Computerclubs unser Da­tenverbundsystem.Einer dieser Com­puterclubsist der CCC.Gigantischer Teil eines winzigen Sicher­heitssystems,das die Erde vor Bedrohungendurchden Gilb schützt.Begleiten wir den CCC und seine Mitglieder bei ihrem Patrouillendienst am Rande der Unkenntlich­keit. CCC'84 nach ORION'64"

  • https://github.com/thierer/OpenCBM/tree/jiffy_support


    Zur praktischen Anwendung kann ich nichts sagen. :nixwiss:


    Sicher weiß strik mehr

    "Was heute noch wie ein Märchen klingt,kann morgen Wirklichkeit sein.Hier ist ein Märchen von übermorgen.Es gibt keine Kupferka­bel mehr,es gibt nur noch die Glasfaser und Terminals in jedem Raum.Man siedelt auf fernen Rech­nern.Die Mailboxen sind als Wohnraum erschlossen.Mit heute noch unvorstellbaren Geschwindigkeiten durcheilen Computerclubs unser Da­tenverbundsystem.Einer dieser Com­puterclubsist der CCC.Gigantischer Teil eines winzigen Sicher­heitssystems,das die Erde vor Bedrohungendurchden Gilb schützt.Begleiten wir den CCC und seine Mitglieder bei ihrem Patrouillendienst am Rande der Unkenntlich­keit. CCC'84 nach ORION'64"

  • Wieso fragt ihr nicht thierer selbst? ;) Es ist ja immerhin sein Patch.


    Jiffy war doch bei den XUM-Geräten nie ein Hindernis und ist ja auch nicht parallel.

    Das mit dem Parallel ist wohl ein Mißverständnis.


    Und: Richtig, es war bislang kein Hindernis, allerdings konnten die XUM davon auch nicht profitieren. Das will thierer nun ändern.

  • Ah ok, dann hab ich JIFFYDOS und Parallel-Übertragung gleichgestellt. Sorry für die Verwirrung :schande:

    "Was heute noch wie ein Märchen klingt,kann morgen Wirklichkeit sein.Hier ist ein Märchen von übermorgen.Es gibt keine Kupferka­bel mehr,es gibt nur noch die Glasfaser und Terminals in jedem Raum.Man siedelt auf fernen Rech­nern.Die Mailboxen sind als Wohnraum erschlossen.Mit heute noch unvorstellbaren Geschwindigkeiten durcheilen Computerclubs unser Da­tenverbundsystem.Einer dieser Com­puterclubsist der CCC.Gigantischer Teil eines winzigen Sicher­heitssystems,das die Erde vor Bedrohungendurchden Gilb schützt.Begleiten wir den CCC und seine Mitglieder bei ihrem Patrouillendienst am Rande der Unkenntlich­keit. CCC'84 nach ORION'64"

  • Der praktische Nutzen dürfte sich für die meisten Anwender tatsächlich in Grenzen halten. Beschleunigt werden nur Übertragungen, die das originale, serielle IEC-Protokoll verwenden. Und das sind mit opencbm nicht so viele, weil die Tools normalerweise (dh in Kombination mit einer 1541 oder 1571) automatisch auf die "serial" oder "parallel" Transferprotokolle wechseln. Mit "parallel" kann Jiffy-DOS sowieso nicht mithalten (weil *nicht* parallel) und die Seriell-Varianten sind ungefähr auf dem Niveau von Jiffy-DOS.


    Es gibt 3 Anwendungsfälle, die profitieren (sollten):


    1. Nicht-1541/1571 Laufwerke mit Jiffy-DOS Unterstützung. Da scheint es wohl einige Laufwerke von Drittherstellern zu geben (zB CMD). Die alternativen Transferprotokolle von opencbm funktionieren da evtl. wegen Inkompatibilitäten nicht, dann kann JD nützlich sein. Ich habe aber kein einziges solches Laufwerk, deshalb kann ich es nicht testen. Mit der sd2iec Firmware messe ich für cbmcopy eine 10x Beschleunigung, das ist aber ein rein akademischer Anwendungsfall.

    2. Da die Aushandlung und Anwendung des Protokolls für den Host-Computer transparent zwischen xum1541 Adapter und Laufwerk erfolgt, werden auch Übertragungen zwischen einem VICE und einem per opencbm "real device" angeschlossenen Laufwerk beschleunigt. (Braucht aber natürlich trotzdem ein JD ROM im Laufwerk und die Beschleunigung ist mit nur 2x auch nicht gewaltig).

    3. Up- und Downloads in/aus dem Floppyspeicher sind auch beschleunigt, aber bei den paar kB RAM fällt es nicht weiter ins Gewicht und das ROM liest man ja nicht so häufig aus...


    Wer einen Anwendungsfall (-laufwerk) und/oder Interesse hat, kann sich die für sein Board benötigte, modifizierte Firmware hier herunterladen. Ich rate aber dazu, vorher ein Backup der aktuell geflashten Firmware zu machen. Da ich nur Pro Micro-basierte Boards habe, sind auch nur die getestet.


    Speziell an Rückmeldungen (positiv & negativ) zu anderen Laufwerken als 1541 und 1571 wäre ich interessiert. (Wenn mit einem exotischen Laufwerk ohne JD Unterstützung *keine* Probleme auftreten, dann wäre das auch eine hilfreiche Nachricht).


    Um mit einer 1541 oder einer 1571 zu testen, muss als Übertragungsprotokoll mit --transfer=original explizit das serielle Originalprotokoll ausgewählt werden! Sonst wird wie oben beschrieben automatisch auf ein anderes Protokoll umgeschaltet und das JD-Protokoll nur für den Upload des Drive-Codes verwendet. Sinnvoll sind Tests auch im Wesentlichen nur mit cbmctrl und cbmcopy. d64copy schaltet mit --transfer=original auch automatisch den "Warp" Modus ab, dadurch ist es dann sowieso langsam.

  • Der praktische Nutzen dürfte sich für die meisten Anwender tatsächlich in Grenzen halten. Beschleunigt werden nur Übertragungen, die das originale, serielle IEC-Protokoll verwenden.

    Naja, so würde ich das nicht sagen ...


    Es ist großartig!


    Der Upload des Drive Code geht jetzt blitzartig!

    Früher war da diese typische Wartezeit bevor das Laufwerk losgelegt hat.


    CBMCTRL UPLOAD und DOWNLOAD geht jetzt auch super schnell!


    Genial!

    Danke für den Jiffy Patch!!




    Meine ganzen Änderungen im OpenCBM für das MeGALoDOS hätte ich mir eigentlich sparen können.

    Du hast im Grunde genau dasselbe erreicht ...


    Aber so kenne ich jetzt wenigstens die OpenCBM Sourcen ein wenig besser ... :D

  • Es ist großartig!


    Der Upload des Drive Code geht jetzt blitzartig!

    Früher war da diese typische Wartezeit bevor das Laufwerk losgelegt hat.

    Danke, das freut mich, wenn es dir hilft :thumbsup:! Allerdings braucht nach meiner Erfahrung der Drivecode auch ohne JD Unterstützung nur unter 1 Sekunde, da merke *ich* nicht, wenn das schneller geht... Von welchem Programm & Laufwerk redest du da?


    Bei größeren Up- und Downloads ist der Unterschied tatsächlich deutlich, aber auch der Einsatz mit MeGALoDOS widerspricht glaube ich meinem "... für die meisten Anwender ..." nicht :).

  • Was ist denn mit der Übertragungsgeschwindigkeit insgesamt?

    Der Unterschied auch an einer 1571 zwischen den von CBMxFER bemühten OpenCBM-Invokationen und Nibtools ist ja für ganzseitige Transfers schon drastisch.

    Kommt man damit jetzt auch ungefähr auf die Geschwindigkeit von Nibtools? Das oben liest sich eher so wie "nein".


    Wenn doch, müsste die ZoomFloppy das ja am besten auch bekommen. Wer pflegt denn da die Firmware? go4retro oder strik ?

  • Wenn doch, müsste die ZoomFloppy das ja am besten auch bekommen. Wer pflegt denn da die Firmware? go4retro oder strik ?

    Martin hat die FW für das ZF auch geändert, allerdings kann er es mangels ZF nicht testen.


    Ich habe ZF, aber kein Laufwerk mit JD. Mein EPROM-Simulator ist gut verstaut. Da ich gerade einen Haufen Projekte (leider auch dringerere als dieses Hobby) gleichzeitig habe, habe ich keine Zeit dafür, das alles aufzubauen um es testen zu können.


    Wenn jemand mit ZF-Gerät einen Test machen will kann thierer oder ich bestimmt eine Firmware zur Verfügung stellen.


    Grundsätzlich "gehört" die FW des ZF wohl Nate Lawson, allerdings machen sowohl thierer (einige) als auch ich (wenige) da commits.

  • Kommt man damit jetzt auch ungefähr auf die Geschwindigkeit von Nibtools? Das oben liest sich eher so wie "nein".

    Ist auch "nein". nibread liest ja nur parallel oder SRQ, das ist nicht vergleichbar. Die Jiffy-DOS Unterstützung leistet auch keinen nennenswerten Beitrag zur Beschleunigung von d64copy. (Der Code-Upload zur Floppy wird beschleunigt, das war's dann im Wesentlichen aber auch).


    Wenn doch, müsste die ZoomFloppy das ja am besten auch bekommen.

    In dem von mir verlinkten Verzeichnis ist auch eine Firmware-Datei für die Zoomfloppy. Grundsätzlich sind die Boards ähnlich genug, dass es funktionieren sollte, aber ohne Testmöglichkeit kann ich eben nicht 100%ig ausschließen, dass ich einen Fehler gemacht habe.