Hello, Guest the thread was viewed45k times and contains 318 replies

last post from DJ SID at the

DT64 Native-Copy Test für MP64

    Anbei ein neue gepatchte DESKTOP-Testversion für MegaPatch-64.

    Bei mir funktioniert es bisher einwandfrei. Die Start-DNP's müssen kleiner- oder gleichgroß der Ziel-DNP's sein und bitte nur mit original CMD-Hardware testen!
    Eine größere Start-DNP wird zwar in der Auswahl angeboten, aber nach "OK" geht es wieder zurück zur Auswahl

    Es handelt sich hier um ein Patch bzw. TESTPROGRAMM !!!! Datenverlust möglicherweise inklusive

    Pusti64

    Quote from Pusti64

    Anbei ein neue gepatchte DESKTOP-Testversion für MegaPatch-64.


    Bei mir funktioniert es bisher einwandfrei.

    Ich hab zumindest mal angefangen das kopieren von SD2IEC auf RL zu testen... Copy läuft zumindest an. Musste es dann aber abbrechen weil ich noch was anderes testen wollte und ich nicht wusste wie lange das 16Mb-Copy dauert...


    Wie lange hat den das Copy bei Dir gebraucht/mit welcher Größe? Nur damit ich weiß wie lange das dauern könnte und ich es in meine Tagesplanung einbauen kann...


    Schade ist das es keine Fortschrittsanzeige gibt. Gut wäre es z.B. in dem Feld wo sonst die noch zu kopierenden Dateien beim Dateien kopieren angezeigt werden die verbleibenden Spuren anzuzeigen. Das ist ja nur die Ausgabe einer Zahl. Oder hab ich da nur nicht lange genug gewartet und die Ausgabe erfolgt nach Ende der aktuellen Spur?

    Quote from uwe1972

    Das heißt also, wenn ich NUR SDs benutze nützt mir der TD Nix??
    Schade..........

    Habe das Kopieren und Aufräumen gerade problemlos mit Werners DNP von SD nach RL und HD ausprobiert.
    Daher wie Werner es bereits geschrieben hat, probiere es einfach aus ;-)
    Scheinbar gibt es bisher "nur" Probleme mit CBM REU. Da hier aber fast eine 1:1 Kopie erstellt wird, könnte der Fehler eventuell auch an anderer Stelle, wie z.B. Treiber oder Aufräum-Routine, liegen.


    Feedback aller Art ist wie immer erwünscht ;-)


    Pusti64

    Quote from wweicht

    Mmmhh, hast Du mal probiert mit diesem TD64 ein echtes CMD-Native-Gerät zu validieren? Theoretisch sollte da zuverlässig am Ende ein BAM-Fehler kommen. Den habe ich da reingebaut ;-) .....
    Gruß
    Werner

    Beim DT128 etwa auch?


    Dann bräuchte man auch mal ein paar Hintergrundinfos dazu ;-)


    Zumindest funktioniert das Aufräumen auf RL und HD bei mir unter DT64/128 bisher ohne Fehler $06. FD muss ich erst noch ausprobieren.


    Pusti64

    Quote from Pusti64

    Beim DT128 etwa auch?

    ursprünglich ja. Ich habe das originale TD-Patch 64/128 für MP3 irgendwann zwischen 2003 und 2010 geschrieben. Da habe ich die bestehenden echten Fehler (Ram TD (C64 und C128), und Laufwerkstausch (nur C128-Version)) gefixt. Zusätzlich habe ich die Validate-Funktion des original TD durch die von geoDOS V2.95 ersetzt.
    Während ich damals da dran saß, kam mir die Idee, einen Boot-Sektor-Schutz einzufügen. Das normale Geos-Validate gibt immer einen eventuell vorhandenen Boot-Sektor auf allen Laufwerkstypen wieder frei, so dass er später eventuell überschrieben wird...


    Das funktioniert aber so nicht auf CMD-Geräten im Native-Mode, da dort Track 1 Sektor 0 immer als belegt gekennzeichnet ist. Daher der BAM-Fehler.


    Letztes Jahr wurde ich darauf aufmerksam und habe hier im Forum eine verbesserte Version von TD 128 veröffentlicht ( MP3 Patch und Laufwerksverwaltung ) . Eine Erklärung dazu (inclusive Quellcode) gibt es hier: MP3 Patch und Laufwerksverwaltung .


    Solltest Du diese Version benutzen, besteht das Problem nicht mehr.


    Zum Probieren müsstest Du eine CMD-Native-Partition für C128 mit Boot-Sektor (Auto-Boot) benutzen. Zum Erstellen eines Boot-Sektors am C128 findest Du hier einen Link: neue Version von MacBootMake


    Quote from Pusti64

    Zumindest funktioniert das Aufräumen auf RL und HD bei mir unter DT64/128 bisher ohne Fehler $06

    Das Problem: ich habe damals gedacht, es könnte ja jemand auf die Idee kommen, MP3-128 Bootdisketten mit MP3-64 zu validieren. Das hat in der Zwischenzeit sogar schon jemand getan ;-) ....
    Deshalb befindet sich der Fehler auch im gepatchten TD 64 für MP3 (Stand 2010). Ich bin jetzt der Meinung: Bootsektor-Prüfung in MP3-64 kann komplett raus. Wer das macht, ist selber Schuld ;-).


    Ich bin bisher aber noch nicht dazu gekommen den TD 64 für MP3 entsprechend zu ändern.


    Versuche also mal eine CMD-Partition vom C128 mit Boot-Sektor in MP3 64 zu validieren. Dann sollte der BAM-Fehler eigentlich zuverlässig kommen.


    Aber: Der Fehler ist in Wirklichkeit kein Fehler. Er tritt nur auf, weil eben auf CMD-Geräten Track 1 Sektor 0 immer geschützt ist. Das eigentliche Validate ist vorher schon abgeschlossen.


    Gruß
    Werner

    Mit TD64 hab ich jetzt 16Mb von SD2IEC nach RL kopiert und validiert. Ohne Probleme... und nur ca. 20% langsamer als GeoDOS. Ist also doch viel schneller als ich auf Grund des blinkens der LEDs am SD2IEC vermutet hatte.


    Aufräumen mit GeoDOS zeigt keine Änderungen in der Größe des belegten Speichers. Hab aber auch keine UVs auf der Disk gehabt.


    Auch das kopieren von Dateien von RAMLink Native nach RAM1581(innerhalb einer 2MB REU als DACC) funktioniert.


    Hier funktioniert alles. :thumbsup:

    Hmmmmmmmm, bin nicht wirklich Begeistert.


    also neuen TD kopiert auf eine extra angelegte Test-MP3 Partion, neu gebootet,
    dann Fehlermeldung "Geos Anwendung Defekt, BlaBla".


    Gut, war vermutlich meine Schuld, hatte wohl vergessen vorher den Ramdesk auszuschalten.
    Das nächsten Booten hat zwar geklappt, aber 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...........
    der Fehler kommt bei allen Images Größe 4160...........


    Ich werd aber das Kopieren von A nach B und B nach C usw. Morgen gerne nochmal Testen.............


    Grüße

    Hm... hört sich gar nicht gut an...
    ich würde erst einmal sicherstellen das bei nur einem Laufwerk mit dem neuen TDNM alles funktioniert. Dann weitere Laufwerke einrichten auf denen aber keine andere Version des TD sichtbar sein sollte. Evtl. kommt TopDesk hier durcheinander weil der neue TDNM Programmteile vom alten TD nachlädt.


    Wenn TopDesk seine Hauptdatei über die GEOS-Klasse sucht wäre es evtl. sinnvoll wen Pusti64 hier eine neue Klasse vorsieht. Evtl. sowas wie "TD64u01 R4.07" für Update1 für TopDesk 4.x...

    Quote from uwe1972

    Aber was genau ist denn nun an dem gepatchten TD gepatcht worden??? Das Aufräumen funktioniert auch mit dem O-TD.............

    Steht doch im Eingangspost... bzw. Themen Überschrift: Kopieren von NativeMode-Disketten. Der alte TopDesk hat da gravierende Mängel weil die Routine wohl nie an NM angepasst wurde.

    Quote from uwe1972

    -Images erstellt mit DirMaster 3.11

    Ich hatte Dich persönlich und auch hier im Forum schon mehrmals öffentlich vor diesem DirMaster gewarnt. Das Programm macht nur Mist!! In der SD2IEC-readme wird auch vor dem Programm gewarnt. Aber wer nicht hören kann, muss fühlen....



    Quote from uwe1972

    -4160 KB denke ich wohl

    Warum nur wußte ich das vorher und habe nach dem Programm gefragt, womit die DNPs entstanden sind? (auch die Antwort wußte ich schon vorher ;-) )


    4160 kB kann gar nicht sein. Es müßten eigentlich 4144 kB oder 4208 kB sein. Werte dazwischen sind normalerweise nicht möglich.


    Gruß
    Werner