DT64 Native-Copy Test für MP64

Zitat von 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?

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

Zitat von uwe1972

wenn ich NUR SDs benutze nützt mir der TD Nix

Probiere es einfach mal .

Zumindest die 128er Version funktioniert hier mit DNP.

Gruß
Werner

Zitat von Pusti64

Feedback aller Art ist wie immer erwünscht

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

Zitat von 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

Zitat von 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

Zitat von uwe1972

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

Verstehe Deine Aussage nicht wirklich.

TD (TopDesk) kannst Du auch bei Verwendung von SD-Karten (SD2IEC) verwenden.
Ist einfach ein anderer Desktop.

Gruss C=Mac.

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.

Zitat von C=Mac

Verstehe Deine Aussage nicht wirklich.

Lies doch mal den Eingangspost

Zitat von darkvision

Lies doch mal den Eingangspost

Ups stimmt (bitte nur mit original CMD-Hardware testen!)
Kommt davon wenn man dauernd querliest.

Wobei uwe hat mehrere SD2IEC, somit kann er gleich Testen ob es funktioniert ein DNP von SD2IEC A nach SD2IEC B zu kopieren.

Gruss C=Mac.

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...

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

Zitat von uwe1972

der Fehler kommt bei allen Images Größe 4160...........

Was Bananen, kB oder Blöcke??? Womit wurden die Images erstellt?

Gruß
Werner

PS: Bitte mal konkretere Aussagen treffen

Zitat von 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.

-4160 KB denke ich wohl

-Images erstellt mit DirMaster 3.11
zeigen keinerlei Fehler an, Aufräumen klappt, Allerdings hab ich keine UVs erstellt

Danke darkvision, nun weiß ich Bescheid..........

Zitat von 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....

Zitat von 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