Hello, Guest the thread was called914 times and contains 11 replays

last post from Spockie at the

RAMLink Backup Tool

  • Inspiriert durch eine User-Frage aus diesem Thread hier:


    Ist irgendwie an mir vorbei gegangen. ( Programm RL-Init, Anm.d.Red ;) )


    Kann man damit ein komplettes BackUp der RL - z.B. auf der HD - machen und in einem "Rutsch" wieder zurück kopieren?

    Falsch interpretiert, aber...


    Mit den Möglichkeiten eines SD2IEC, GeoDOS64 und MP3 fehlt da nicht mehr viel um das zu programmieren:


    - Man legt mit GeoDOS64 vier Container-DNPs an, jeder 64Kb (für Directory) +4Mb für Daten.
    - Kopieren der RL-Sektoren via DIRECT-ACCESS in den Datenbereich der DNPs.


    Für ein Restore die Daten aus den 4 DNPs auslesen und zurückschreiben.


    Der Einfachheit halber wäre ein fester BACKUP-Name sinnvoll SD2IEC:/root/RLBACKUP0(1-4).dnp,
    Das Backup/Restore-Utility müsste dann nur "CD<-" und "CD:RLBACKUP0x.dnp" an das SD2IEC senden um das Image zu wechseln.


    Das würde aber immer 16Mb sichern/wiederherstellen. RL-INIT+Backup einzelner Partitionen wäre evtl. schneller.


    Das ist jetzt alles keine Hexerei, vieles davon liegt schon auf der Area6510.
    Aber gäbe es überhaupt Bedarf dafür?


    Wenn ich mittels RL-Init die Partitionen auf der RL automatisch einrichten lasse nutze ich GeoDOS um 1x1581 DiskImage auf die RL zu kopieren... und anschließend startfähig zu machen. Für mich wäre das also momentan der Overkill... aber evtl. haben ja andere Bedarf dafür...

  • Falsch interpretiert, aber...

    :cry:
    Was ich auch immer falsch interpretiere. Ist ja echt zum :schande::D
    Wenn ich es jetzt richtig verstanden habe, nimmt einem RL-Init das manuelle erstellen der Partitionen ab.
    Das Kopieren muss manuell erfolgen.



    Mit den Möglichkeiten eines SD2IEC, GeoDOS64 und MP3 fehlt da nicht mehr viel um das zu programmieren:

    8)



    - Man legt mit GeoDOS64 vier Container-DNPs an, jeder 64Kb (für Directory) +4Mb für Daten.

    Da fragt der Ahnungslose - also ich - sich warum 4 DNP's, man kann doch gleich ein 16 MB-DNP machen?
    Die RL hat ja maximal 16 MB Speicher, somit könnte dies in "einem Rutsch" erfolgen.



    Das würde aber immer 16Mb sichern/wiederherstellen.

    Man kann nicht immer alles haben.
    Und bei einem Crash (Stromausfall, Netzteil ausgesteckt) müsste eh die ganze RL wieder hergestellt werden.



    RL-INIT+Backup einzelner Partitionen wäre evtl. schneller.

    Wenn ich nur in einer RL-Partitionen Daten ändere, ist dies sicherlich der schnellere Weg.
    Wobei dann kann ich auch die Daten manuell sichern und wieder zurück kopieren.


    Ob's bedarf dafür gibt?
    Schwierig zu sagen, ist sicherlich die Luxusvariante; nice to have aber kein muss.


    Gruss C=Mac.

  • kurze Zwischenfrage: Wie lege ich mit GeoDos die DNP's an? Das habe ich noch nicht herausgefunden...


    Gruss C=Mac.

  • Da fragt der Ahnungslose - also ich - sich warum 4 DNP's, man kann doch gleich ein 16 MB-DNP machen?

    Ohhhh Du unwissender!!! :Peace:D
    Ein 16Mb-DNP gibt es nicht! Matte-Nachhilfe für Anfänger: 255 Spuren a 256 Sektoren a 256 Bytes / 1024 = XXX Kb??? Wenn Du dann 16.384 raus bekommst würde ich die Schule wiederholen ;)


    Ich hab zuerst sogar mit 2x8Mb überlegt. Aber wenn GEOS das Laufwerk öffnet wäre ein Teil des Verzeichnisses in Teil #2 Datenbereich der RAMlink, also kein reales Verzeichnis, Daher dann die 4x4Mb... Das wäre "SAVE" auch wenn jemand das DiskImage als "Laufwerk" öffnet...


    Ob's bedarf dafür gibt?e
    Schwierig zu sagen, ist sicherlich die Luxusvariante; nice to have aber kein muss.

    Sehe ich genauso... daher die Frage...

  • Der Taschenrechner kommt auf 16'320 KB; gerundet 16 MB.

    Fail... :bgdev gerundet != mathematisch richtig. :ChPeace


    Aber das ist der Grund warum man kein 16Mb-DNP anlegen kann. Das CMD-Format unterstützt logischerweise nur 255 Spuren. Und 255 Spuren sind nun mal nur 16.320Kb. Daher wird das nie via "16Mb"-DiskImages funktionieren. Also muss man den RL-Speicher aufteilen. Ich finde 4Mb sinnvoller...

  • Warum denn überhaupt unbedingt "DNP"? Einfach eine Datei auf dem SD2IEC öffnen, da die ganzen 16 Megabyte reinschreiben und gut is. Dem SD2IEC ist doch egal, ob der Inhalt der Datei irgend einer Dateiformats-Konvention folgt.

  • Warum denn überhaupt unbedingt "DNP"? Einfach eine Datei auf dem SD2IEC öffnen, da die ganzen 16 Megabyte reinschreiben und gut is. Dem SD2IEC ist doch egal, ob der Inhalt der Datei irgend einer Dateiformats-Konvention folgt.

    Weil die GEOS-Routinen zum lesen/schreiben von ganzen Datenblöcken so schön praktisch sind. Ich vermute mal das erstellen bzw. zurückspielen könnte ca. 30-45min. dauern. Hochgerechnet vom kopieren eines D81 auf die RAMlink. Ob das Byte-weise über den IEC-Bus schneller geht? Das SD2IEC führt zwar das TurboDOS von GEOS nicht aus, aber es überträgt die Daten zumindest im gleichen Format. Daher könnte das evtl. sogar schneller sein als das Byte-weise schreiben in eine einzelne Datei.

  • I use CMD's BCopy+ to backup my RamLink to my CMD HD. The HD needs a "foreign partition" made. I created a 17mb partition of that. Using BCopy+ you can backup and restore. Time involved for either is about 25 minutes.

    Hi,


    can you please elaborate? What is a “foreign partition”? I am in search for exactly this solution, to make a backup from my RAMLink to my CMD HD. I am currently using BCopy (without the “+”) V 1.22. My version of BCopy insists of using real disks. I would like to see a version which supports CMD HD partitions instead.

  • Ok, habe es selber herausgefunden. Man braucht dazu wirklich BCopy+ (V1.30). Das kann auf die HD backupen und beschränkt sich nicht nur auf Disks als Speichermedium. Braucht man eine Partition, die größer als das Maximum von 16 MB sind (weil die zu backupende RAMLink bereits 16 MB hat), dann kann man mit dem „Foreign Creator“ solche Partitionen machen. BCopy+ erkennt diese Partitionen auch.


    BCopy+ und Foreign Creator gibt es auf der CMD Tooldisk von Maurice Randall und überall im Internet zum Download.