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

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

    Das OpenCBM kann "alle Sektoren" oder nur "belegte Sektoren" kopieren.

    Nur belegte zu kopieren ist natürlich praktisch, weil viele Disketten nicht ganz voll sind und es daher entsprechend schneller geht.


    Das OpenCBM ImgCopy braucht für eine ganz volle 1581 Diskette etwas über drei Minuten im Modus S2 und im S3 Modus nur noch 40 bis 50 Sekunden.

    Da wäre aber noch Potential, wenn man den Code in der 1581 optimieren würde.

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

    Danach wollte ich gerade fragen. Dann muss ich nicht den Unassembler bemühen. :D

    Ich finde die Kombination aus Assembler und Basic hier sehr gelungen. Die Assemblerroutinen für die Geschwindigkeiten und das Basic für die Flexibilität und Übersicht.


    Ich dachte, die 1581 wäre am C64 auch relativ lahm, weil die Fast-Mode fehlt. Oder läuft bei dir alles mit Jiffy-Dos?


    Ich bin halt nicht so Retro, dass ich alles am C64 machen muss und nutze daher auch ganz gerne Tools vom PC aus. Deswegen der Wunsch nach einem funktionierenden imgcopy.


    Aber wenn du die Sourcen für dein Copy-Programm veröffentlichst, dann würde ich mal schauen, ob man das mit wenig Aufwand für die CBMs umstricken kann um damit direkt die 8050/8250 ansprechen zu können.

  • Danach wollte ich gerade fragen. Dann muss ich nicht den Unassembler bemühen. :D

    Ich finde die Kombination aus Assembler und Basic hier sehr gelungen. Die Assemblerroutinen für die Geschwindigkeiten und das Basic für die Flexibilität und Übersicht.

    Wären ja nicht mal 500 Bytes Assembler-Code... würde sicherlich nicht all zulange dauern zum disassemblieren. :)

    Ich dachte, die 1581 wäre am C64 auch relativ lahm, weil die Fast-Mode fehlt. Oder läuft bei dir alles mit Jiffy-Dos?

    Ja, das ist mit JiffyDOS... ohne dauert 1581 wohl knapp 1h... habs aber nicht getestet. SuperCPU oder TC64 bringt da auch nicht viel, das langsame ist der ser.Bus.

    Ich bin halt nicht so Retro, dass ich alles am C64 machen muss und nutze daher auch ganz gerne Tools vom PC aus. Deswegen der Wunsch nach einem funktionierenden imgcopy.

    Ist ja kein Problem... ich sehe meine Tools auch eher als Notlösung, z.B. wenn man (irgendwann mal) wieder auf Treffen gehen kann und mal schnell eine Diskette einlegt um ein Abbild zu ziehen. Ohne das man PC mitschleppen muss oder Laufwerke an den PC anklemmen oder GEOS starten muss. Es ist ja wirklich die Minimallösung: Keine Fehlerabfrage, kein wirkliches UI. Aber für den "ab&zu"-Fall reicht es.

    Aber wenn du die Sourcen für dein Copy-Programm veröffentlichst, dann würde ich mal schauen, ob man das mit wenig Aufwand für die CBMs umstricken kann um damit direkt die 8050/8250 ansprechen zu können.

    Es sind ja nur Open/Close und Print/Get-Befehle in Assembler. Nichts was es in den Standard-Codebeispielen nicht gibt. Sicherlich geht es auch schneller, kompakter... aber bei 512 Bytes... :rolleyes:


    Ich ergänze noch etwas Beschreibung, dann lade ich es hoch. Kein Thema... evtl. am Wochenende.

  • Es sind ja nur Open/Close und Print/Get-Befehle in Assembler. Nichts was es in den Standard-Codebeispielen nicht gibt. Sicherlich geht es auch schneller, kompakter... aber bei 512 Bytes... :rolleyes:

    Ich bin mit den ROM-Routinen nicht so fitt, deswegen wäre es einfacher, wenn ich das "abkupfern" könnte. :D

  • Aber wenn du die Sourcen für dein Copy-Programm veröffentlichst, dann würde ich mal schauen, ob man das mit wenig Aufwand für die CBMs umstricken kann um damit direkt die 8050/8250 ansprechen zu können.

    Thema 8250... das sind doch Doppellaufwerke ?


    Dann wird z.B. bei Block-Read (bzw U1/U2) auch das Drive abgefragt (0/1) ? Wenn ja könnte ich das im Assemblerteil gleich noch mit einbauen das man das Laufwerk ebenfalls an die Routine übergeben kann. Bisher ist das bei 1541/71/81 ja immer "0".

  • detlef : Ich hab die Assembler-Bibliothek erweitert und der Code steht als TXT-File hier zur Verfügung. Der eigentliche Source-Code ist für geoWrite... evtl. eher uninteressant. Müsste ausreichend kommentiert sein. Lässt sich sicherlich optimieren...


    Am Anfang stehen die von mir genutzten ROM-Routinen und ZeroPage-Register.


    Die Doppellaufwerks-Nummer kann jetzt wie die anderen Parameter per POKE übergeben werden. Ebenso hab ich ein paar Fehlerprüfungen eingebaut, z.B. für Lese-/Schreibfehler. Oder wenn man versucht ein falsch benanntes D64 auf eine 1571-Disk zu kopieren...


    Wegen der Fehlerprüfung habe ich auch die BASIC-FrontEnds angepasst. Es gibt da jetzt zwei Modi:

    - Fehler nur zählen, aber ignorieren (kopiert so viel wie möglich).

    - Beim ersten Fehler abbrechen (überschreibt auch keine Disk-Images).


    In beiden Fällen bekommt man am Ende angezeigt auf welchem Track der Fehler passiert ist.


    Ich hab auch mal versucht das auf xpet zu laden, mehr als das Verzeichnis konnte ich mir nicht anzeigen lassen :whistling: Aber wenn ich das richtig sehe muss für den Assemblerteil eine andere Startadresse gewählt werden. Mehr hab ich mir nicht angeschaut.

    Für die Anpassung an 8250 müsste man im BASIC-Teil ggf. die DRIVE-Nr. abfragen und die max. Anzahl an Sektoren ab Zeile 500 anpassen und die max. Anzahl an Tracks in Zeile 71. Ich denke das Tool der 1571 lässt sich dafür am einfachsten anpassen... oder Du nimmst gleich was besseres ;)


    Die aktuellen BASIC-Tools sind eher auf Lesbarkeit im "Quelltext" ausgelegt. Ich hab die BASIC-Dateien mal mit CompactorIII komprimiert, da werden dann aus 16Blocks noch 10Blocks. Wer will kann also die Dateien noch etwas kleiner machen.


    Man kann die BASIC-Tools +RDWRSEKLIB im übrigen auch auf ein SD2IEC-Verzeichnis kopieren, in welches man die DiskImages speichern will. Dann hat man immer alles gleich parat und ist im richtigen Verzeichnis zum speichern.


    Die neue Version gibt es hier... zusammen mit ein paar Hinweisen zu den neuen Copy-Modi.


    Es bleibt eine Notlösung, auch wenn das Interesse hier größer war als gedacht. :)

  • Nachdem ich noch ein paar Bugs beseitigt habe funktioniert nun auch CMD-Native / DNP :)

    Code
    1. CMD FDNative/1.6M Disk -> SD2IEC/DNP-DiskImage: 21min20sec.
    2. SD2IEC/DNP-DiskImage -> CMD FDNative/1.6M Disk: 23min03sec.

    Man kann auch DiskImages auf einer CMD/Native-Partition erstellen:

    Code
    1. SD2IEC/D64 Disk -> CMD FD-Native/D64-DiskImage: 2min12sec.

    Ich sehe das aber eher als Proof-of-Concept, denn mit GEOS/MP3+GeoDesk64:

    Code
    1. SD2IEC/DNP-DiskImage -> CMD FDNative/1.6M Disk: 10min43sec.
    2. CMD FDNative/1.6M Disk -> SD2IEC/DNP-DiskImage: 10min45sec.

    Immer am C64mk2 mit TC64v2...


    Bei CMDFD->DNP ist auch das erstellen des DNP mit 72sec. enthalten, d.h. schreiben auf SD2IEC ist schneller als auf CMDFD. Interessant ist auch das es unter GEOS kaum eine Rolle spielt ob CMDFD-DNP oder DNP-CMDFD. Unter BASIC mit JiffyDOS macht das doch noch einen spürbaren Unterschied.


    Wenn man also bedenkt das man GEOS in minimal 3sek starten kann, dann ist es allemal eine Überlegung Wert GEOS als DiskCopy-Tool zu installieren. Ist ja nochmal 50% schneller als copydisk mit JiffyDOS. :D