Hello, Guest the thread was called2.1k times and contains 28 replays

last post from darkvision at the

DiskCopy für 1541/71/81/SD2IEC/CMD

  • Basierend auf der Diskussion hier hab ich auf die schnelle einfache DiskCopy Tools für 1541/1571/1581 erstellt, die wirklich die Diskette kopieren, und nicht einzelne Dateien. Was passiert wenn man von den Dateien auf der Disk keine Ahnung hat und dann FileCopy nutzt kann man an diesem Beispiel hier sehen (Disk CMD-1750XL).


    Sollte mit echten Laufwerken, CMD-Partitionen, DiskImages usw. funktionieren. Mit JiffyDOS geht es etwas schneller, andere FastLoader nicht getestet... Keine Fehlerprüfung, simples read/write. Gibt drei Modi, Quelle und Ziel müssen aber immer unterschiedlich sein!


    Disk->Disk, Quell- und Ziel-Laufwerk werden als "Diskette" behandelt, kann ein echtes Laufwerk sein, eine Partition oder ein gemountetes DiskImage auf SD2IEC.


    Disk->Image, Die Quelldisk wird als Datei auf dem Ziel-Laufwerk gespeichert. Ziel kann ein SD2IEC-Verzeichnis oder ein VICE/IEC-Device sein. Eine CMD-Native-Partition >=1Mb für D81 geht auch.


    Image->Disk, Das Image wird wieder auf ein Laufwerk/Partition/DiskImage geschrieben.


    SD2IEC/D81 -> SD2IEC/D81 dauert mit TC64+JiffyDOS rund 10min, andere Programme schaffen das mit TC64 unter 5min... ich sehe das daher eher als Notlösung. Daher auch eher rudimentär.


    Man könnte das leicht auch noch für NativeMode (DNP) anpassen. Auf dem Quell-Laufwerk den Sektor 1/2 einlesen und aus Byte#8 die Anzahl der Tracks ermitteln. Sektor-Count wäre 256 = 0. Aber 16Mb will man damit nicht kopieren ;)


    Die drei Programme "COPY15x1" laden jeweils die Assembler-Datei "rdwrseklib" nach... einmal geladen kann man das Programm nach dem Kopiervorgang direkt wieder mit RUN starten, es wird dann nichts mehr nachgeladen.


    Der Hauptteil ist in BASIC, nur der aktuelle Track wird in Assembler kopiert. Den BASIC-Teil in Assembler umzusetzen macht das ganze nicht viel schneller... Wer will kann da ja noch eine bessere UI dafür schreiben...


    Der Source-Code zum Assembler-Teil ist als MegaAssembler/GeoWrite-Dokument auf Disk. Das bedeutet: Die Diskette nicht mit einem BASIC/FileCopy kopieren :bgdev

    Ich hab da jetzt einiges getestet... wer noch Fehler findet: Einfach melden.


    Und bitte keine Diskussion darüber das man doch dies oder jenes Programm nutzen kann... das weiß ich und einige davon funktionieren eben nicht mit SD2IEC... oder nur 1541... oder oder... Ich hab die Aufgabe eher sportlich gesehen, denn brauchen tue ich das selbst nicht (hab da was besseres) :D


    NUR FÜR C64!

  • Vielen Dank für die Arbeit! :love:

    Nicht zu viel davon erwarten... wie gesagt, ganz rudimentär.

    Man muss vor dem Programmstart Quelle und Ziel selbst einstellen (DiskImage mounten oder Partition wechseln). Komfort gibt es also nicht. Mit JiffyDOS ist das aber kein allzugroßes Problem...

  • Ah, so ein Ding hätte ich mir gewünscht als ich noch 1571, 1581 und HD hatte ;)


    Das Programm scheint aber nur für 1581-Disks ausgelegt zu sein, entgegen den Ausführungen hier im Thread?


    Vielleicht eine Laufwerkserkennung einbauen? Das müsste doch über Reset-Befehl-an-Floppy und dann Status-Abfrage auch in BASIC recht einfach zu erledigen sein? Dann kann man sich die Abfrage des "Copy-Mode" sparen:

    1. Quellaufwerk = Ziellaufwerk: D->D
    2. Quellaufwerk > Ziellaufwerk: I->D
    3. Quellaufwerk < Ziellaufwerk: D->I

    (eventuell im 3. Fall bei Ziel = 1571 fragen ob ein Diskcopy stattfinden soll? Braucht's aber m.E. nicht, dafür gibt's bessere Tools).

  • SUPER KOMPLIMENT!!

    Das erste Programm, was ein Diskcopy von 1581 auf D81 Image am c64 hinbekommt.

    ok, rudimentär, wie von Dir gesagt und ich brauchte 3 Laufwerke:

    #8 hatte die Programm-Dateien

    #9 mein Target (erfreulicher weise muß man keine leere D81 mounten, das macht das Programm von alleine

    #10 mein Source (die 1581 Demo Diskette)


    wurde 1:1 inkl. Subdirectory kopiert und Anzahl freier Blöcke am Ende stimmt auch überein.

    Also wenn ich viele 3,5" Disketten kopieren müsste, würde ich es evtl. noch etwas aufpeppen, aber für die max. 10-20 Disks geht es auch so.


    Vielen vielen Dank an @darkvision

    (und sowas schüttelst Du so aus dem Ärmel?) toll!!

  • Das Programm scheint aber nur für 1581-Disks ausgelegt zu sein, entgegen den Ausführungen hier im Thread?

    Nein, es gibt drei Tools auf der Disk, COPY1541, COPY1571, COPY1581... je nach Laufwerkstyp bzw. Emulationsmodus...

    Vielleicht eine Laufwerkserkennung einbauen? Das müsste doch über Reset-Befehl-an-Floppy und dann Status-Abfrage auch in BASIC recht einfach zu erledigen sein?

    Ich hab so eine Routine für GEOS entwickelt, die *NICHT* über die Reset-Meldung funktioniert, sondern über Laufwerkseigenschaften.

    Bei all den Speedern und geänderten ROMs ist mir das über RESET zu unsicher. Macht hier aber wenig Sinn... man wechselt ja kaum bei jeder Disk den Modus... zur Not sortiert man seine Originale vor ;)


    Dann kann man sich die Abfrage des "Copy-Mode" sparen:

    1. Quellaufwerk = Ziellaufwerk: D->D
    2. Quellaufwerk > Ziellaufwerk: I->D
    3. Quellaufwerk < Ziellaufwerk: D->I

    (eventuell im 3. Fall bei Ziel = 1571 fragen ob ein Diskcopy stattfinden soll? Braucht's aber m.E. nicht, dafür gibt's bessere Tools).

    Nein, der Kopiermodus geht immer von Quelle nach Ziel... aber das Ergebnis kann ein anderes sein. Entweder ich kopiere auf eine andere Disk oder in ein DiskImage auf einem größeren Laufwerk.

    Bei Disk -> Image lege ich mir den Stapel Disketten bereit, Ziel ist ein Verzeichnis auf dem SD2IEC und dann wird mit dem Modus für jede Diskette ein eigenes DiskImage erstellt...

    Bei Image -> Disk liegt der Stapel Leerdisketten vor dem Laufwerk, und damit gebe ich ein DiskImage auf dem SD2IEC an was ich wieder auf Leerdisketten kopieren möchte.

    Es geht also nicht um die Richtung, sondern darum was das Ergebnis sein soll. So viel KI kann man da gar nicht einbauen, das ein BASIC-Programm das von sich aus entscheiden kann was Du machen willst :D


    ok, rudimentär, wie von Dir gesagt und ich brauchte 3 Laufwerke:

    #8 hatte die Programm-Dateien

    Nein, es reichen zwei: Wenn das Programm einmal geladen ist muss man die Programmdateien nicht mehr bereithalten. Nach dem Kopieren einfach wieder "RUN" eingeben.

    Und wenn man vor dem Start noch das DiskImage wechseln will... dann kann man auch das Assemblerprogramm zuerst laden, dann den BASIC-Teil nur laden, aber nicht starten. Dann das Image wechseln und RUN eingeben. Das folgende setzt JiffyDOS voraus (wegen den @-Befehlen...)

    U.S.W.U.S.F...;)

  • Nein, der Kopiermodus geht immer von Quelle nach Ziel... [...] Es geht also nicht um die Richtung, sondern darum was das Ergebnis sein soll. So viel KI kann man da gar nicht einbauen, das ein BASIC-Programm das von sich aus entscheiden kann was Du machen willst :D

    Du hast meine Kurzschreibweise missverstanden. Die >/< geben keine Richtung an, sondern beziehen sich auf die Kapazität des Laufwerks:


    Quelllaufwerk und Ziellaufwerk identisch: einzig mögliche Aktion ist Diskcopy

    Quelllaufwerk hat mehr Kapazität als das Ziellaufwerk: einzig mögliche Aktion ist Image auf Disk schreiben

    Quelllaufwerk hat weniger Kapazität als Ziel: einzig sinnvolle Aktion ist Image erstellen


    (im dritten Fall gibt es wie gesagt theoretisch noch die Ausnahmesituation 1541->1541, da wäre theoretisch auch ein Diskcopy möglich.

  • Du hast meine Kurzschreibweise missverstanden. Die >/< geben keine Richtung an, sondern beziehen sich auf die Kapazität des Laufwerks:

    Ah... OK. Dann müsste ich aber die Laufwerkstypen ermitteln. Und bei SD2IEC testen ob Verzeichnis oder DiskImage. Das gleiche dann für VICE und IEC-Laufwerk. Bei CMD-HD den Partitionsmodus testen (ob Native oder 1571) usw usw...


    Wie gesagt mach ich das unter GEOS in den Testversionen aktuell über Laufwerkseigenschaften. Die RESET-Meldung ist mir nicht zuverlässig genug. SD2IEC kann z.B. kein gültiges M-R, so wie auch VICE/IEC-Device. Beide liefern aber unterschiedliche Fehler. 1571 kann kein G-P, 1541 kann keinen Sektor 255 lesen. Das geht also alles. Aber was für ein Aufwand...


    Man kann auch D81 nach CMD-Native kopieren. Da müsste man prüfen ob noch genügend Speicher frei ist und dann ggf. ob die Zieldatei schon existiert/ersetzt werden soll.


    Man könnte auch noch eine Laufwerksauswahl einbauen, eine Dateiauswahlbox, oder den Imagenamen aus dem Verzeichnisnamen automatisch erstellen. Ich hatte schon überlegt eine Oberfläche wie bei cbmHDscsi64 oder cbmSCSIcopy64 einzubauen, die an die CMD-Tools erinnert.


    War mir dann den Aufwand aber nicht wert. Wie gesagt mach ich das mit dem kopieren von DiskImages gefühlt schon seit Jahren, beim programmieren&testen am C64 fast täglich. Hätte nicht gedacht das es für BASIC-Anwender so ein Problem ist ;)


    Wer mehrere DiskImages erstellen will, immer mit den gleichen Laufwerken kann die ersten BASIC-Zeilen ab 100- anpassen und die beiden INPUT-Befehle durch D0=8 und D1=9 (Beispielhaft) ersetzen. Dann muss man das nicht immer eintippen...

  • Basierend auf der Diskussion hier hab ich auf die schnelle einfache DiskCopy Tools für 1541/1571/1581 erstellt, die wirklich die Diskette kopieren, und nicht einzelne Dateien. Was passiert wenn man von den Dateien auf der Disk keine Ahnung hat und dann FileCopy nutzt kann man an diesem Beispiel hier sehen (Disk CMD-1750XL).

    Ihr wisst aber schon, dass man das auch mit IMGCOPY machen kann?

    Also natürlich nicht von 1541 auf 1581 wie in dem anderen Thread gefordert ...



    Aber man kann mit IMGCOPY Image Dateien erstellen:

    • D64 aus 1541 Disketten
    • D71 aus 1571 Disketten
    • D81 aus 1581 Disketten
    • D80 aus 8050 Disketten
    • D82 aus 8250 bzw. SFD-1001 Disketten


    Und natürlich kann man die Image Dateien auch wieder auf Disketten zurück schreiben.

  • Ich wusste das sowas kommt ;)

    Ihr wisst aber schon, dass man das auch mit IMGCOPY machen kann?

    Auf die schnelle sieht das nach einem Windows/DOS-Programm aus oder täuscht mich das?


    Wenn ja, denn das war nicht die Aufgabe... ;) es sollte alles am C64 gehen.


    Und andere Lösungen wurden im anderen Thread ja auch aufgetan... ich glaube da war sogar was wie ZoomFloppy dabei. Ist nix für mich... ich bleib bei GEOS. Viel einfacher ;)

  • Ihr wisst aber schon, dass man das auch mit IMGCOPY machen kann?

    Also natürlich nicht von 1541 auf 1581 wie in dem anderen Thread gefordert ...

    im anderen Thread ging es auch nur darum ein Diskcopy 1:1 von 1581 auf D81 zu machen.

    Wo findet man Dein IMGCOPY?

  • Ach, das imgcopy stammt von dir. ;)

    Wäre natürlich super, wenn du da nochmal reinschauen könntest warum das aktuell nicht mit der 1581 funktioniert.


    30 Minuten zum Übertragen einer 1581 Diskette auf den PC macht einfach keinen Spaß (mit einem eigenen Tool im Standard-Modus).

  • 0 Minuten zum Übertragen einer 1581 Diskette auf den PC macht einfach keinen Spaß

    Ja das glaub ich ...



    Wäre natürlich super, wenn du da nochmal reinschauen könntest warum das aktuell nicht mit der 1581 funktioniert.

    Ich werde mir heute mal die OpenCBM Sourcen ziehen und gucken ob ich es kompilieren kann.


    Es ist nämlich so, dass ich gerne große Datenblöcke übertragen würde.

    Zur Zeit ist das zwar möglich (mit CBMctrl download und upload) aber es abartig langsam ist und einfach ewig dauert.

    Es geht nämlich nur mit der standard IEC Routine, und leider nicht mit dem parallel Kabel.



    Dabei könnte ich mir gleich das IMGcopy anschauen ...

    Leider liegt meine 1581 seit dem Umzug irgendwo im Keller herum.

    Keine AHnung ob ich die auf die schnelle finden kann.

  • Dabei könnte ich mir gleich das IMGcopy anschauen ...

    Leider liegt meine 1581 seit dem Umzug irgendwo im Keller herum.

    Keine AHnung ob ich die auf die schnelle finden kann.

    Du weisst, dass die 1581 inzwischen teuer gehandelt werden? :D


    Ich hatte meine OpenCBM-Routinen eigentlich für die CBM-Floppys mit Parallel-Bus geschrieben. Die sind im Standard-Modus ausreichend schnell. Und Damit kann ich ja auch das 1541-Format lesen und schreiben.


    Aber dass die 1581 im Standard-Modus dermaßen lahm ist, daran habe ich überhaupt nicht gedacht.

  • Ich denke das Thema ImgCopy kann man auch hier weiterbehandeln... zwei Threads zum gleichen Thema braucht es ja nicht ;)


    Auch wenn ich das selbst nur zur Genüge kenne, ist es doch ein weiterer Grund warum ich die Copy-Tools geschrieben hab. Im anderen Thread wurden auch Programme empfohlen die dann nicht funktionierten. Und wenn jetzt ausgerechnet ImgCopy mit 1581 nicht (oder wegen eines evtl. Bugs nur langsam) kann... dann war die schnelle reine C64-Alternative ja nicht so verkehrt :D;)


    Beim Thema Geschwindigkeit: Wie schnell geht es den mit ImgCopy wenn es denn richtig funktioniert ?


    Was die anderen Disk-Typen wie 8250 angeht... die DiskCopy-Tools sind ja zwei-geteilt:

    Der Assembler-Teil:

    Code
    1. SYS49152 - Copy Disk to Disk
    2. SYS49155 - Copy Disk to Image
    3. SYS49158 - Copy Image to Disk
    4. POKE 49152 + 9,SOURCE
    5. POKE 49152 +10,TARGET
    6. POKE 49152 +11,TRACK
    7. POKE 49152 +12,MAXSEKONTRACK

    Der Unterschied der drei SYS-Aufrufe besteht darin die Daten auf einen Ausgabekanal zu senden oder mit U1/U2-Befehl Sektorweise zu behandeln.

    Der SYS-Aufruf erwartet dann in den POKE-Adressen die Parameter. MAXSEKONTRACK ist die Anzahl der Sektoren, bei 256 für Native wäre das 0.

    Der SYS-Aufruf kopiert dann immer alle Sektoren eines Tracks.

    Bei den Image-Befehlen muss der Programmierer vorher selbst die Kanäle öffnen... kann man im BASIC-Code nachlesen. Bei DISK to DISK macht das der Assembler-Teil selbst, da man dabei ja den Daten/Befehlskanal jederzeit schließen und wieder öffnen kann.


    Der BASIC-Teil selbst fragt nur die Parameter ab und führt die Schleife aus, welche die Daten durch Aufruf der SYS-Befehle kopiert.


    Damit könnte man auch Programme für andere Diskettenformate schreiben, sofern sich das Gerät an den C64 anschließen und über den ser.Bus steuern lässt.


    Wenn ich die Zeit dazu hab schiebe ich den Code für BASIC+Assembler auf meine GitLab-Seite... ist ja nicht wirklich weltbewegendes dabei...