ZoomFloppy als billiges Teensy Device

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

Stefan

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.

Quote from Kongo-Otto

Ich weiß nicht wie schnell das XU Kabel war.

Langsam. Wesentlich langsamer als ein XA1541 oder gar XAP1541.

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.

Wiewas? Jiffy? Parrallel? Hast Du eine Quelle dazu? Jiffy war doch bei den XUM-Geräten nie ein Hindernis und ist ja auch nicht parallel.

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

Zur praktischen Anwendung kann ich nichts sagen.

Sicher weiß strik mehr

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

Quote from ius

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

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.

Quote from Diddl

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 ! 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 ?

Quote from ius

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.

Quote from ius

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

Quote from ius

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.