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

    Hab mich mal dazu entschieden:

    Zitat von C=Mac

    - Partition aus BackUp wiederherstellen und die gewünschten UV's/Dateien kopieren/löschen

    Und was muss ich feststellen?


    - Löschen von Dateien -> kein Problem
    - Löschen von UV's -> kein Problem
    - Erstellen von UV's -> kein Problem


    Dazwischen wurde mit GeoDOS aufgeräumt, ohne eine Fehlermeldung


    - Dateien in UV's kopieren -> kein Problem
    - Rücksprung ins Root -> zerstörte Icons, kryptische Namen


    Aufräumen bringt: Ungültige Sektoradresse, Fehlercode: 2


    Vermute mal dieser Bereich der Platte hat einen Schuss.


    Hab jetzt den Adapter auf SD bestehlt, trau der Platte nicht mehr.
    Ersetze lieber gleich auf SD, als durch eine alte Platte.


    Gruss C=Mac.

    Wieder was probiert, braucht halt immer viel Zeit.


    Neue Partition auf der HD erstellt und wiederhergestellt (vom SD2IEC kopiert).


    - Dateien in Unter-UV's gelöscht
    - Unter-UV's gelöscht
    - Im Root ein neues UV erstellt und drei alte gelöscht
    - Im neu erstellten UV ein Unter-UV erstellt und Dateien hinein kopiert
    - Zurück ins Root-Verzeichnis -> Partition zerstört (zerstörte Icons, kryptische Namen)


    Der Versuch mit TD aufzuräumen bring: Absturz nahe $D9AD
    Räume ich mit GD auf, wird BAM defekt (Code 6) als Fehler ausgegeben.


    Im Moment mache ich das selbe Vorgehen mit einem DNP-Image auf dem SD2IEC (selber Hinhalt wie die Partition), bis jetzt ohne Probleme.
    Das selbe habe ich auf der HD auch schon auf mehrere Partitionen gemacht, ebenfalls ohne Probleme.


    Keine Ahnung ob diese Partition "speziell" ist oder es ein Anzeichen ist das die HD stirbt.
    Das es sich um ein Software-Problem handelt glaube ich nicht.


    Gruss C=Mac.

    Okay, ist notiert. Komme aber, wie bereits bekanntgegebenen, momentan zu gar nichts was den C64/128 betrifft.
    Trotzdem Danke für die Rückmeldung.


    Pusti64

    Ich hab mir das mal näher angeschaut:


    Bei der TD64-Version steht bei $7319 der GEOS-Befehl "RenameFile". Wenn kein Fehler auftritt verzweigt TopDesk nach $7320.
    Hier wird jetzt der GEOS-Dateityp aus dirEntryBuf+$16 eingelesen und auf $00 getestet.


    In dem alten SourceCode den ich hier hab steht da noch ein CLC/RTS gefolgt von der DialogBox zum umbenennen von Dateien.


    In der neuen TD-Version steht hier der Programmcode welcher den ersten Sektor der Datei einließt und dann den Dateinamen ab Byte$04 speichert. Das sieht ganz nach Verzeichnis-Umbennenen aus und der Korrektur des Verzeichnis-Namen im Verzeichnis-Header.


    Wenn man da zusätzlich zum GEOS-Dateityp in $16 = $00 noch auf Byte $00 = CBM-Dateityp $86 testen würde, dann wäre das Problem behoben.

    Code
    1. lda $8416
    2. cmp #$00 ;Überflüssig.
    3. bne :keine_basic_datei
    4. lda $8400
    5. cmp #$86
    6. bne :kein_verzeichnis

    Wenn ich es mir so recht überlege... Einfach direkt nur den CBM-Dateityp testen... dann sind es nur zwei Bytes die man ändern muss...

    Code
    1. lda $8416 ändern in => lda $8400
    2. cmp #$00 ändern in => cmp #$86
    3. bne :exit...


    P.S. Aktuell bedeutet das das man mit TopDesk keine BASIC-Dateien umbenennen sollte. Das Ergebnis sind beschädigte Dateien.

    Ups, nicht schön.


    Aber wenn ich es richtig verstanden habe, betrifft es nur das Umbenennen von "Basic"-Dateien.
    Bei Native-Ordner und GEOS-Dateien funktioniert es wie es soll?


    Wie sieht es bei der 128'er-Version aus?



    Was ich letzthin hatte war folgendes:


    Laufwerke:


    A: RamLink Native
    B: FD 2000 1581
    C: HD-Native
    D: SD 1581


    Zwei Fenster waren offen, C + D, beide Fenster mit dem Befehl "alle Fenster schliessen" (Menüleiste) geschlossen.
    Danach konnte Laufwerke A - C nicht mehr geöffnet werden.
    Es erschien die gleiche Fehlermeldung, wie wenn bei der FD eine falsche Diskette eingelegt ist.
    Nur Laufwerk D konnte, nach mehrmaligen Versuch geöffnet werde.
    Danach konnten auch wieder A - C geöffnet werden.


    Leider konnte ich den Fehler nicht reproduzieren. :evil:



    Was mir auch noch aufgefallen ist, betrifft die Grösse von Native-UV's.


    Erzeuge ich mit TD-64 ein Native-UV und kopiere GEOS-Dateien hinein, wird die Grösse des UV angepasst.
    Erzeuge ich mit TD-64 ein Native-UV und kopiere Basic-Dateien hinein, wird die Grösse des UV nicht angepasst.
    UV bleibt bis zum Aufräumen immer gleich gross.


    Gruss C=Mac.

    Zitat von C=Mac

    Wie sieht es bei der 128'er-Version aus?

    Soweit ich das sehe, tritt das Problem nur bei TD64 auf. TD128 macht hier bei mir all das richtig. Dabei muss man aber auch bedenken, dass TD64 von Anfang Januar und TD 128 von Mitte März ist. Die Weiterentwicklung von TD 64 ist ja seit Januar vorerst eingestellt und bei TD128 wird es wohl auch noch etwas dauern (kalte Wintermonate ;-) ) ...


    Gruß
    Werner


    PS: @darkvision die aktuelle 128er-Version gibt es hier: DT128-Native-Copy Test für MegaPatch128

    Zitat von wweicht

    PS: @darkvision die aktuelle 128er-Version gibt es hier: DT128-Native-Copy Test für MegaPatch128

    Danke.


    Da ist das Problem definitiv nicht mehr vorhanden. Dort wird bereits $8400=$x6 getestet. Scheint also ein Problem in der nicht mehr unterstützten Dateiversion des TopDesk64 zu sein. Da man nur zwei Werte in der Datei ändern müsste wäre hier ein Patch denkbar bis TD64 evtl. doch nochmal gefixed wird.

    Zitat von wweicht

    Na klar, irgendwann nachher .

    Nur keine Eile... ich hab hier ja schon BASIC-Dateien umbenannt und in VICE kontrolliert das der Dateityp-Check bei Dateien funktioniert. Auch ein UV lässt sich umbenennen und bekommt dann den richtigen Namen.


    Aber eine unabhängige Meinung ist nie verkehrt :thumbup:

    Zitat von darkvision

    Ansonsten kann man dann das TDFIXED.D64-DiskImage für den C64/MegaPatch64 verwenden.

    Naja, es gibt da noch mindestens einen Fehler ( DT64 Native-Copy Test für MP64 ) .
    Und die 128er Version ist einiges weiter (z.B. Klicken auf unteren Fensterrand bei Native-Mode-Laufwerken (auch SD2IEC). Mal abwarten was wird .....


    Gruß
    Werner

    Zitat von wweicht

    Naja, es gibt da noch mindestens einen Fehler ( DT64 Native-Copy Test für MP64 ) .

    Ich bin ja jetzt nicht der TopDesk-Profi und kann daher nicht beurteilen ob jetzt alles funktioniert, aber ich vermute ich hab das Problem gefunden.


    Im Modul, in dem u.a. der Name eines Ordners eingegeben werden kann existiert auch die Routine. die nachfrägt ob die Dateien ohne Abfrage überschrieben werden sollen. Im Vergleich zur Version vom 10.12.18 wurde aber in der letzten Version hier eine Sprungtabelle zu weiteren Funktionen eingebaut und der Einsprung liegt jetzt 9 Bytes weiter hinten im Modul.


    Um das Modul nachzuladen und die richtige Adresse anzuspringen gibt es eine Routine ab $3a27:

    Code
    1. .C:3a27 A2 09 LDX #$09
    2. .C:3a29 A9 01 LDA #$01
    3. .C:3a2b 4C 8F 37 JMP $378F


    Das Problem liegt bei $3a29: Der Wert $01 wird mit drei multipliziert was dann die Einsprungadresse ergibt. Das ist im Original $01 x 3 +$6eaf (Startadresse) = $6eb2. Dort steht in der Version vom 10.12.2018 die Routine zum Ohne Abfage überschreiben.


    Bei der Version vom 4.1.19 ist die Routine noch identisch. Ab $6eb2 steht aber der JMP-Befehl auf die Routine zum eingeben des TD/UV-Namens. Der Einsprung für "Ohne Abfrage überschreiben" liegt aber bei $6ebb. Damit muss die obige Routine ab $3a27 angepasst werden:

    Code
    1. .C:3a27 A2 09 LDX #$09
    2. .C:3a29 A9 04 LDA #$04
    3. .C:3a2b 4C 8F 37 JMP $378F


    Ich hab den Wert im angehängten D64 mal geändert. Das kopieren funktioniert damit, mit SHIFT auch ohne Abfrage ob kopieren oder verschieben.


    Wie gesagt, ich kenne nicht alle ShortCuts, weiß nicht was sonst noch geändert wurde und ob diese Korrektur nicht andere Probleme verursacht. Falls jemand Zeit hat kann er ja mal testen... wenn nicht... auch kein Problem ;)


    Ich hab nur das Datum des TD und den Infotext angepasst um die Versionen zumindest etwas unterscheidbar zu machen. Seit der Version vom 4.1.19 wurden nur drei Bytes geändert... und eben der Infoblock/Diskname/Datum.