DT128-Native-Copy Test für MegaPatch128

Zitat von Pusti64

anbei eine neue gepatchte 128 DESKTOP-Testversion für MegaPatch-128.

Habe jetzt nur mal auf die Schnelle das probiert, was vorher nicht ging . Ein DNP 3184 kB auf C=REU Native und GeoRam Native (je knapp 12 MB) kopiert. Keine Probleme mehr feststellbar. Directory zeigt am Ende keinen Fehler mehr und Validate hat auch nichts zu meckern.

Scheint also zu funktionieren.

Gruß
Werner

Zitat von Pusti64

daher anbei die neue Testversion inklusive 27.02.2010 Patch,

Hatte noch nicht die Zeit das zu probieren...

Aber: Irgendwie verwirren mich Deine Beschreibungen...... (gilt auch für 64 Version). Was denn nun???

TD 128: in der Version von 2017 war dieses Patch bereits enthalten und verändert wegen der Probleme mit Native-Laufwerken

TD 64: Hier sollte eigentlich ein Teil des 2010-Patches entfernt werden (Boot-Sektor-Prüfung).

Deine Beschreibung besagt für mich, dass Du das fehlerhafte 2010er Patch wieder reingebaut hast...

Gruß
Werner

Zitat von Pusti64

Ich sollte doch im DT64 an beschriebener Stelle drei nop's einfügen.

Korrekt, damit im TD64 keine Boot-Sektor-Prüfung mehr stattfindet.

Zitat von Pusti64

Gilt das nun auch für DT128 oder nicht?

Nein, gilt hier nicht. Der TD128 von 2017 funktioniert an der Stelle so, wie er soll (Boot-Sektor-Prüfung).

Gruß
Werner

PS: Habe gerade mit TD 128 das erste DNP auf FD-Native kopiert. Funktioniert.
Hast Du da eventuell noch etwas Platz (wegduck )? Eine irgendwie geartete Anzeige, dass TD während des Kopiervorgangs beschäftigt ist, wäre nicht schlecht. z.B. wie beim Validate, wo die Menüzeile verändert wird oder irgendwie anders.....

Zitat von Pusti64

Ich hoffe, mir ist kein weiterer Fehler unterlaufen und Du meintest das so hier (siehe Anhang) !

Na, das sieht doch perfekt aus!
Gruß
Werner

... aus dem anderen Thema hier :

Zitat von darkvision

Ich hab das Problem im TopDesk gefunden:
Das aktuelle Unterverzeichnis schließen funktioniert nur auf Laufwerk A: und auch nur bei CMD-Laufwerken. Es gibt da im TopDesk folgende Routine (stammt von Pusti64 TD128 source code):

Code

1. ::1 jsr Tst_dblClick ; bei $4cec;$5318 20ec4c
2. bcc $534d ;$531b9030
3. ldx Save_AnzAktLfwFnst ; bei $042f;$531d ae2f04
4. lda $0524,x ;$5320bd2405
5. bne $535f ;$5323d03a
6. lda $04bf ;$5325adbf04
7. beq $534d ;$5328f023
8. lda curType ;$532aadc688
9. and #31 ;$532d291f
10. cmp #4 ;$532fc904
11. bne $534d ;$5331d01a
12. MoveB $8222,r1L
13. sta Abl_SubDirTrack,x ; bei $04fa,x;$5338 9dfa04
14. MoveB $8223,r1H
17. sta Abl_SubDirSektor,x ; bei $04fe,x;$5340 9dfe04
18. ora r1L ;$53430504
19. beq $534d ;$5345f006
20. jsr $06a4 ;$534720a406
21. jmp $536e ;$534a4c6e53

Alles anzeigen

Das Problem liegt in Zeile 6 (Bei TopDesk64 liegt der Code ab $4EAB):
Ab $04BF (TD64: $04B8) liegen vier Bytes die über die Laufwerke Auskunft geben. Pusti64 hat das hier so kommentiert:
Bei mir stehen da unter VICE folgende Werte: $00,$00,$08,$00 für GeoRAMNative, RAM81, FD4000, CREUNative.

Also wenn ich mir das so ansehe, scheint es zu reichen, Zeile 6 und 7 komplett durch nop zu ersetzen. Erst wird auf CMD geprüft (Zeile 6 + 7) und dann nochmal auf Native (Zeile 8 - 10). Letzteres müßte doch vollkommen reichen. Man müsste dann nur nochmal prüfen, ob für Native-Rams und Co Zeile 9 angepasst werden muss.....

Wobei sich mir die Frage stellt, warum TD für MP3 nicht einfach die MP3-Variablen nutzt statt alles selber zu speichern ..........

Gruß
Werner

Nachtrag: Durch die Umstellung meines Systems und Neuinstallation von MP3 habe ich jetzt auch die "Power-User" Kopier-Tastenkürzel in beiden TD-Versionen geprüft. Funktioniert mit originalem Tastatur-Treiber von MP3 problemlos . Mit geoKeys (PC-Tastatur unter Geos & Co) geht es nicht. Eine kurze Begründung steht im alten MP3-Programmierhandbuch (mp3web_5.htm) unter "PutKeyInBuffer".
Ist aber kein Problem. Dann kommt bei mir halt die DB, wo ich Kopieren oder Verschieben auswählen muss.

nochmal :
und wenn man Zeile 6 und 7 komplett löscht und die ganzen bcc, bne und beq hier anpasst, hat man schonmal 5 Bytes frei für was auch immer

Zitat von wweicht

Eine kurze Begründung steht im alten MP3-Programmierhandbuch (mp3web_5.htm) unter "PutKeyInBuffer".

Für die unwissenden: Dabei geht es um das Speichern von "gedrückten Tasten" die vom C64 später ausgeführt werden sollen. Scheinbar sendet geoKeys die Daten an diesen Puffer, daher funktioniert die Abfrage über die Tastenregister nach C= oder SHIFT nicht. geoKeys User bleibt also nur die Dialogbox.

Zitat von wweicht

Also wenn ich mir das so ansehe, scheint es zu reichen, Zeile 6 und 7 komplett durch nop zu ersetzen. Erst wird auf CMD geprüft (Zeile 6 + 7) und dann nochmal auf Native (Zeile 8 - 10). Letzteres müßte doch vollkommen reichen. Man müsste dann nur nochmal prüfen, ob für Native-Rams und Co Zeile 9 angepasst werden muss.....

Sehe ich auch so... es muss nur auf Native gestestet werden. Zeile #9 muss nicht angepasst werden. Es geht ja nur um das Laufwerksformat, da würde auch ein

reichen. Wenn man es genau nimmt nutzt gateWay oder Wheels (Bin mir gerade nicht sicher...) Bit 4+5 für die CMD/RL-Erkennung. Das wird zumindest in GeoDOS geprüft.

So bin zum probieren gekommen.

UV's schliessen funktioniert auf:

- REUNative
- SD2IEC DNP

so wie es soll.

Auf CMD-Laufwerke hab ich es (noch) nicht probiert, da am C128 keine angeschlossen sind.
Muss zuerst um stellen oder auf die 64'er-Version warten.

Aufgefallen ist mir folgendes Verhalten:
Kopiere ich Dateien von z.B. der 1571 in ein UV und will das aktive Fenster der 1571 schliessen, verhält sich TD so als ob er in einem UV wäre.
Liesst das Directory noch einmal ein, es muss ein zweites mal auf Schliess-Icon geklickt werden oder lange klicken.
Ist aber nur beim Kopieren in ein UV der Fall, sonst ist es mir nicht aufgefallen.

Trackanzeige scheint zu funktionieren, jetzt sieht man das TD noch lebt und nicht eingeschlafen ist.

So langsam wird das noch was mit dem TD.

Jetzt muss noch das Problem beim Formatieren mit einer 1571 behoben werden.
1541-Disk können nicht auf 1571 umformatiert werden = Diskfehler $10, dies betrifft auch falsch formatierte Disketten.
GeoDOS kann diese ohne Probleme formatieren.

Gruss C=Mac.

Zitat von C=Mac

Kopiere ich Dateien von z.B. der 1571 in ein UV und will das aktive Fenster der 1571 schliessen, verhält sich TD so als ob er in einem UV wäre.
Liesst das Directory noch einmal ein, es muss ein zweites mal auf Schliess-Icon geklickt werden oder lange klicken.

Kann ich hier reproduzieren, auch beim kopieren von 1581/A: in ein UV/D:. Danach muss ich das Laufwerk A: 2x schließen. Hängt also nicht mit der 1571 zusammen.

Das scheint daran zu liegen das nach dem kopieren das Ziel-Laufwerk aktiv ist aber das Quell-Laufwerks-Fenster das aktive ist. Klickt man hier jetzt auf schließen wird curType ausgewertet, da steht aber der Wert des Ziel-Laufwerks = Native = UV schließen. Lässt sich unter VICE testen, nach dem kopieren steht in curDrive/curType Daten des Ziel-Laufwerks obwohl das Fenster des Quell-Laufwerks aktiv ist.

Es reicht aus 1x in das Ziel-Laufwerk zu klicken und danach auf das Quell-Laufwerk. Dann lässt sich das Fenster direkt schließen.

Man müsste am Ende vom Kopieren auf das Quell-Laufwerk wechseln oder beim Schließen auf das passende Laufwerk zum Fenster wechseln damit curType den richtigen Wert beinhaltet. Oder aber an Stelle von curType indirekt über ldy curDrive/lda driveType -8,y den Wert auslesen.

Zitat von darkvision

Oder aber an Stelle von curType indirekt über ldy curDrive/lda driveType -8,y den Wert auslesen.

Wobei das hier "Müll" ist... curDrive zeigt ja auch auf das falsche Laufwerk. Also entweder zuerst das passende Laufwerk zum aktiven Fenster ermitteln (Xreg beachten) und SetDevice oder dann über driveType gehen.

Der Bug war auch schon immer da, nur ist das bisher evtl. deswegen nicht aufgefallen weil A: ein CMD-Laufwerk sein musste, sonst hat das schließen ja immer direkt das ganze Fenster geschlossen. Auch auf einem anderen Native-Laufwerk mit UVs.