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.

Zitat von 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.

Zitat von 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.

Zitat von 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 ?

Zitat von 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.

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

Zitat von 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.

Ich wollte hiermit zumindest bestätigen, dass die v08 Firmware sowohl mit einer Teensy 2 als auch Pro-Micro_7406 Variante in Kombination mit einem 1541C+Track0 Umbau nebst JiffyDOS 6 Firmware funktioniert.

Falls jemand beim Flash des Pro Micro außerhalb des Windows Ökosystems auch kurz graue Haare bekommen sollte, vielleicht die beiden folgenden Hinweise.

Die avrdude Kommandozeile kann folgendermaßen aussehen:

Achtung: die Pfade müssen natürlich an die jeweiligen lokalen angepasst werden!

Da Pro Micro Klone meistens keine Reset Taster bestückt haben und der Bootloader hochgradig zickig ist, funktioniert avrdude meistens nicht sofort; der Bootloader meldet Timeouts.

Abhilfe kann ein python3 Skript schaffen, das den Port kurz versucht zu öffnen und zu schließen (inspiriert vom Workaround der Arduino IDE):

Auch hier muss der Pfad logischerweise angepasst werden. Und PySerial installiert werden.

Der Ablauf ist dann: rest.py ausführen => avrdude starten => funktioniert.

reicht es nicht, die avrdude Zeile einzutippen, den ProMicro zu reseten (Pins liegen nebeneinander) und Enter zu drücken ? Zumindest unter Windows reicht die Zeit, dass avrdude das Kommando übernimmt. Oder fällt der Bootloader gleich wieder zurück ?

Zitat von Markus64

reicht es nicht, die avrdude Zeile einzutippen, den ProMicro zu reseten (Pins liegen nebeneinander) und Enter zu drücken ? Zumindest unter Windows reicht die Zeit, dass avrdude das Kommando übernimmt. Oder fällt der Bootloader gleich wieder zurück ?

Das Problem kenne ich, da ist wirklich gezieltes Timing gefragt.

Leider sind die Bootloader auch unterschiedlich und haben unterschiedliche Timeouts. Da nun aber der PC auch Zeit braucht, um das ProMicro zu erkennen, kann das spaßig werden.

Ich habe mir folgendes angewöhnt:

Mit dem Sleep habe ich herumgespielt, bis ich einen Wert hatte (müsste ich mal nachschauen, der ist bei mir in einem Skript versteckt).

Mit der Option "-e" bei avrdude wird der AVR gelöscht ("erase"). Dann habe ich für das Flashen an sich beliebig Zeit. Zumindest mein Bootloader tut sich schwer, wenn ich sofort flashen will, das geht sehr häufig schief und bricht während des Uploads ab.

Zitat von strik

Zitat von manfred.moser

1. Die Firmware auf dem ATMega8 musste korrekt installiert werden. Da die Platine keinen ISP-Header hat, musste ich den AT-Mega im TL-866 programmieren.

Die Firmware ohne Bootloader zu flashen hat nicht funktioniert, da dann kein USB-Gerät am PC erkannt wurde.

Richtig, der Bootloader enthält den USB-Code. Ohne den funktioniert nichts.

Zitat von manfred.moser

Ich kam dann darauf, wie es geht. Den Bootloader mit dem TL-866 auf den Chip, dann den Treiber in Windows installieren, anschließend kann man die eigentliche Firmware über USB mit dem Update-Tool von opencbm flashen.

Darauf muss man aber erst mal kommen.

Wenn dein TL-866 in der Lage ist, etwas zu flashen, ohne den Chip vorher zu löschen, ist es ganz einfach:

1. Bootloader flashen (mit Löschen)
2. Firmware flashen (ohne Löschen)

Falls das nicht geht kann man auch ein HEX-File erzeugen, welches beides (Firmware und Bootloader) enthält: Einfach die Ende-Kennung der Firmware entfernen (letzte Zeile) und dann firmware.hex und den Bootloader hintereinander in eine neue Datei kopieren. Aber da muss man erst einmal drauf kommen.

Zitat von manfred.moser

2. Der Treiber auf dem Windows10-X64 musste installiert werden. Mit dem Zadig-Treiber als libusb-win-32 hat es dann geklappt. Der Treiber aus opencbm hat bei mir nicht korrekt funktioniert.

3. opencbm musste korrekt installiert werden. Ich hatte zuerst immer einen Plugin-Fehler, bis ich den Hinweis hier im Forum gefunden hatte, dass man den Befehl "instcbm xu1541" aus dem Verzeichis ...\opencbm\amd64 heraus aufrufen muss. Erst dann war der Plugin-Fehler weg und es hat dann funktioniert.

Falsche Reihenfolge.

Neuere OpenCBM (>= 0.4.99.103) installieren den Treiber automatisch. Die aktuelle Version hat noch ein Problem mit dem Update der Treiber, wird aber in der kommenden behoben sein.

Der Install-Befehl lautet: "instcbm xu1541" (aus dem Hauptverzeichnis); es sucht dann die passende Version (i386 oder amd64) heraus, erzeugt einen schönen Eintrag in "Software" zum Deinstallieren und installiert am Ende, wenn gewünscht, die Treiber.

Das ist das Problem, wenn in solchen Foren so viele veraltete Informationen liegen.

Alles anzeigen

Hab das mal "Heute so gebastelt" rauskopiert. Passt hier ganz gut, auch wenn es um XU1541 geht.

strik kannst du die Kombination aus Bootloader und Firmware hier nochmal aufdröseln? (grün markiert)

Versteh ich noch nicht ganz

Zitat von Markus64

Hab das mal "Heute so gebastelt" rauskopiert. Passt hier ganz gut, auch wenn es um XU1541 geht.

XUM 1541 und XU15.41 sind zwei völlig unterschiedliche Geräte. Oder hab ich das falsch in Erinnerung? Dann tut es mir Leid, dass ich Blödsinn rede. Ich bin der Meinung, dass das Thema hier auf keinen Fall hingehört. Es bringt "Neue" Interessen nur völlig durcheinander.

Es müsste doch auch einen eigenen XU Bereich geben?!

Hilfe bei der XU1541

z.b.

Stefan