Hallo Besucher, der Thread wurde 38k mal aufgerufen und enthält 318 Antworten

letzter Beitrag von DJ SID am

DT64 Native-Copy Test für MP64

    Mach doch bitte mal ein paar nähere Angaben über Deine Systemkonfiguration und von wo nach wo Du was kopieren wolltest.


    Pusti64

    Da gibts nicht viel


    C64
    LW A-D SDIEC jeweils 4160 KB


    Das Kopieren kam von C=Mac, der meinte ich könnte das Testen, da ich mehrere SDs habe.


    Werner, Ich weiß Natürlich das du Profi bist, aber meine Images zeigen absolut keine fehler an,
    Aufräumen klappt. Nur mit dem gepatchten TD hab ich Probleme.........


    Hier ein Image, kannst ja selber Testen

    Ich hab eben mal DT64 genutzt um von einer FD4Native auf GeoRAM-Native zu kopieren. Beide Laufwerke zeigen im GEOS.Editor "3184KBytes" an, also gleich groß. Kopieren funktioniert. Ich kann die UVs öffnen und bis ans Ende scrollen, danach springt DT64 zurück auf Seite#1.


    Kein RAMTopDesk, DT64 ist die einzige DESKTOP-Kopie auf allen Laufwerken...


    Aufräumen allerdings führt auf dem RAMLaufwerk zu BADBAM.


    Kopiere ich zuerst die FD4N-Disk mit GeoDOS auf das RAM-Laufwerk und lasse danach DT64 die Disk nochmals kopieren dann klappt anschließend auch das aufräumen. DT64 scheint also keine echte 1:1 Kopie zu erstellen, zumindest was Track#1 angeht.
    Das dem so ist kann ich auch daraus erkennen das bei einem größeren Ziel-Laufwerk hinterher in Sektor 1/2 noch die größere Anzahl an Tracks steht.


    Ich müsste mir jetzt mal die BAM / Track#1 von der "beschädigten" RAMNative-Disk und der Original FD4Native-Disk betrachten und vergleichen. Aber evtl. ist es besser einfach nur zwischen gleichen großen Disks wirklich 1:1 zu kopieren, ohne Manipulationen an der BAM.


    P.S. Evtl. gibt es Unterschiede beim Layout der BAM auf der NativeMode-Disk und der FD4. Muss auch mal prüfen wie MP3 hier die BAM erstellt und ob die wirklich ohne Unterschied zum CMD-Layout sind.


    P.S2: Evtl. liegt es auch am RAMNative-Treiber: Die Treiber haben eine Art "Cache" Funktion, evtl. liegt es auch daran. Bevor ein neuer BAM-Sektor für interne Routinen geladen wird prüft der Treiber ob der aktuelle Sektor modifiziert wurde. Falls ja schreibt er den zurück auf Disk und lädt erst danach den neuen BAM-Sektor. Wenn jetzt DT64 beim DiskCopy den Sektor vorher überschreibt während der aktuelle Sektor im Cache "Dirty" ist, würde ggf. der "alte" BAM-Sektor im Cache auf Disk kopiert. Ich vermute aber eher Unterschiede im Layout der BAM... ich bastele mir mal ein Testprogramm dazu...

    So, Testprogramm ausgewertet und für meine Disk gibt es eine Erklärung für BADBAM... siehe Screenshot.


    Das zeigt den Vergleich der BAM nachdem DT64 die Disk kopiert hat (oben) und nachdem mit GeoDOS die Disk kopiert und anschließend mit DT64 überschrieben wurde.


    Der wichtige Unterschied liegt im Byte $0000:$01AB/AC. Das Ist Track#1, Sektor #1. Die Bytes definieren den Borderblock. Der muss beim DiskCopy von Quelle nach Ziel übernommen werden. Ansonsten belegt DT64 den beim aufräumen der Ziel-DIsk in der BAM obwohl er auf der Quell-Disk an ganz anderer Stelle liegt. Das führt dazu das bei Dateien die den BorderBlock-Sektor der Ziel-Disk für Daten nutzen dieser auf der Ziel-Disk bereits belegt ist -> BADBAM.


    P.S. Die Byte-Adressen sind um 2Bytes verschoben da VICE beim speichern eines MemoryDumps zwei Bytes für die Startadresse in die Datei mitschreibt, daher liegen die beiden Bytes für den Borderblock hier zwei Bytes weiter hinten bei $01AD/AE...

    Okay, das sollte sich ohne größere Probleme beheben lassen und vielen Dank für den Test bzw. Tipp ;-)


    Pusti64

    Hallo,


    Zitat von uwe1972

    Da gibts nicht viel


    C64
    LW A-D SDIEC jeweils 4160 KB

    Alle auf Native-Mode? Und wie und mit welchem Programm bekommst Du z.B. den TD von Pusti64 auf die/das DNP?


    Zitat von uwe1972

    Werner, Ich weiß Natürlich das du Profi bist

    Nicht wirklich, aber ich weiss ein wenig ;-) .....


    Zitat von uwe1972

    aber meine Images zeigen absolut keine fehler an,
    Aufräumen klappt. Nur mit dem gepatchten TD hab ich Probleme.

    Achso, und was ist das?:

    Zitat von uwe1972

    nun werden alle meine DNPs mit 4160 KB garnicht mehr Geöffnet...........sondern gleich als Defekt angezeigt, und GeoDos hat sich gleich vor Schreck Aufgehangen, nachdem es mich mit der Fehlermeldung das "das Image defekt sei" beglückt hat

    also keine Probleme.... ;-) .


    Ich vermute mal, Du kopierst den TD auch mit DirMaster auf das DNP? Dann herzlichen Glückwunsch. Jede Geos-Datei, die mit Dirmaster kopiert wird, ist anschließend kaputt. Ich hatte das mal mit geoPaint versucht. Da fehlten auf der Zieldisk mal eben 2000 Bytes von geoPaint. So oder so ähnlich dürfte das auch mit TD sein. Wer Dirmaster benutzt, ist selber Schuld!!!!!


    Zitat von uwe1972

    Hier ein Image, kannst ja selber Testen

    Das Image ist ausnahmsweise völlig in Ordnung. Nur hat es nicht 4160 kB, sondern 4032 Blocks, was ungefähr 1 MB ist.


    Gruß
    Werner

    Also, nein ich kopiere Programme nur unter MP3 von 1581 auf DNP.
    Dafür habe ich extra MP3-Partionen eingerichtet wo dann ein Lw entweder eine 1581 oder 1571 ist.
    und mit so einer Test.MP3 hab ich auch den TD getestet.


    Ich binn jetzt etwas verwirrt, mit dem DNP im DirMaster (Ja ich weiß) werden 4061 Blocks angezeigt
    bringe ich da jetzt was Durcheinander???


    Zitat von uwe1972

    -Images erstellt mit DirMaster 3.11

    Warum benutzt Du nicht das Programm von hier (C64-Version)?
    Ja das erstellen eines DNP dauert und setzt die aktuelle Firmware des SD2IEC voraus.


    Zitat von darkvision

    DT64 scheint also keine echte 1:1 Kopie zu erstellen, zumindest was Track#1 angeht.

    Dann warte ich mal, mit dem Versuch eine 16 MB-Partition in ein DNP zu kopieren.


    Gruss C=Mac.

    Zitat von uwe1972

    Ich binn jetzt etwas verwirrt, mit dem DNP im DirMaster (Ja ich weiß) werden 4061 Blocks angezeigt

    OK, nicht drüber nachdenklen, ist ein Fehler in DirMaster, den aber auch andere Programme haben (z.B. auch 64Copy). Hier wird eine falsche Zahl Blöcke angezeigt. Auf echten CMD-Geräten im Native-Mode werden 29 Blöcke zusätzlich für Directory-Blöcke (für je 8 Dateien) reserviert. Das sollte eigentlich auch für DNPs gelten. Unter MP3 solltest Du die korrekte Zahl sehen:
    4032 Blocks free (bei einem leeren Image).


    Zitat von C=Mac

    Warum benutzt Du nicht das Programm von

    Er kann auch die neuere Version von hier: d81 erstellen mit Bordmittel benutzen, die läuft auf C64 und C128. Habe da nur spezielle C64-Befehle rausgeschmissen, damit es eben auch am C128 funktioniert ;-) .


    Gruß
    Werner


    PS: achso, ist ihm zu langsam ;-) ....

    Zitat von uwe1972

    An der FW solte es nicht liegen die hatte Useen ja gefixt.........

    Du musst aber alle 4 SD2IECs einzeln updaten. Also: SD-Karte mit Update in SD2IEC 1 einlegen, Rechner an, Firmware wird (normalerweise) automatisch aufgespielt. Dann Firmware-Update auf SD2IEC 2, dann auf SD2IEC 3 und dann auf SD2IEC 4. Ansonsten könnte theoretisch immer noch eins mit älterer Firmware sein, dass irgendwie dazwischen funkt....


    Gruß
    Werner

    Hallo @uwe1972

    Zitat von darkvision

    Nach etwas Recherche sind das 5V/300ma.

    mal so ne Frage zwischendurch: Wie sind Deine 4 SD2IECs eigentlich mit Strom versorgt? Alle am C64 oder extern. Es könnte sein, dass bei Dir der Strom zusammenbricht. 4 x 300 mA = 1,2 A alleine für die SD2IECs. Grenzwertig, wenn die alle am C64 hängen. Der braucht auch noch Strom.


    Gruß
    Werner

    -Meine Evos habe ich alle einzeln Ge-Updatet, klar.


    -Alle 4 Evos werde durch ein Externes Netzteil mit Strom versorgt, da solte also Nix schief gehn.......


    -Nun zum Programm zum DNPs erstellen:


    Is ja nicht schlecht, Aber Irgendwann ändert sich die Text-Farbe, so das man Nix mehr lesen kann,
    habs mehrmals probiert, auf versch.LW und sogar den C64 gewechselt...........(Foto).........



    Nun zum TD: Ich habe also versucht ein 4160KB großes DNP von A nach D zu Kopieren unter TD.
    Nach 70 Minuten hab ich dann Ausgeschalten, da hatte sich wohl was aufgehangen..........
    Nach erneutem Booten sind scheinbar alle Dateien da, aber da scheinen auf D irgendwie Blöcke zu fehlen wie GeoDos zeigt, (Das allseits bekannte Problem)...........

    Zitat von uwe1972

    Aber Irgendwann ändert sich die Text-Farbe, so das man Nix mehr lesen kann,

    Nimm mal die Version, die C=Mac weiter vorne verlinkt hat. Kann sein, dass die besser lesbar ist......


    Hier nochmal der Link: d81 erstellen mit Bordmittel



    Zitat von uwe1972

    GeoDos

    Welche Version? Dagibt es seit einiger Zeit 2962 und seit heute 2963. Die sollten es schon sein ;-) .... Und beim Kopieren könnte es noch Probleme geben, siehe weiter vorne.


    Gruß
    Werner

    Zitat von uwe1972

    Aber Irgendwann ändert sich die Text-Farbe, so das man Nix mehr lesen kann,
    habs mehrmals probiert, auf versch.LW und sogar den C64 gewechselt...........(Foto).........

    Komisch, sieht komplett anders aus, als das Programm welches ich verlinkt habe. ?(


    Bei mir ist der Hintergrund schwarz und die Texte verschieden farbig.
    Kann alles einwandfrei lesen.


    Gruss C=Mac.

    Zitat von uwe1972

    wären diese DNPGrößen so richtig???
    4144/ 4208 / 4032 / 3184 / 2048

    Das Programm fragt Dich wieviele Blöcke ä 64 KB Du erstellen willst.


    255 Blöcke ä 64 KB = 16'320 KB (Grösstes DNP, dauert > 13 min.)
    50 Blöcke ä 64 KB = 3200 KB


    Du kannst die Wunschgrösse (in KB) einfach durch 64 teilen, dann weisst Du wieviele Blöcke nötig sind (nur ganze Blöcke).


    Gruss C=Mac.

    Zitat von C=Mac

    Komisch, sieht komplett anders aus, als das Programm welches ich verlinkt habe.

    Ja, ich habe ja einen Teil der Farbcodes rausgeschmissen, da nicht unbedingt C128 kompatible. Auf meinem Monitor Philips CM8833-II ist das aber im C64-Mode noch lesbar in meiner Version.

    Zitat von uwe1972

    wären diese DNPGrößen so richtig???

    Was willst Du erreichen, die Größe, die Du mir geschickt hast oder eine andere?


    Die Größen-Angabe erfolgt in Tracks. Das sind Zahlen von 1 bis 255. Bei dem DNP, das Du mir geschickt hast, waren das 16.


    Die Berechnung erfolgt folgendermassen: (Anzahl der Tracks x 256) - 64
    Das ergibt dann die Größe in Blöcken, die Dir zur Vergügung stehen. Wenn Du die Angabe in kB willst, dann musste Du das Ergebnis nochmal durch 4 Teilen (4 Blöcke sind 1 kB).


    Gruß
    Werner