Hello, Guest the thread was called9.3k times and contains 389 replays

last post from wweicht at the

DT128-Native-Copy Test für MegaPatch128

  • 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. :thumbsup:


    Gruß
    Werner

  • 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

  • Dann also nochmal ganz langsam ;-)


    Ich sollte doch im DT64 an beschriebener Stelle drei nop's einfügen. Gilt das nun auch für DT128 oder nicht?


    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.

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

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

    Wird schwierig :gruebel , da ich leider aus Platzgründen die bereits funktionierende Trackanzeige schon streichen musste ;-)


    Pusti64

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

    Was würde ich nur machen, wenn es den lieben Werner mit seinen Extrawünschen nicht gäbe ;-)


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


    Pusti64

  • ... aus dem anderen Thema hier ;-) :

    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):

    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 ;-)

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

    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

    Code
    1. and #%00000111

    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.

  • Auf Wunsch anbei eine neue Testversion :bgdev mit Trackanzeige (rückwärtslaufend) beim Diskcopy und UV-Patch.
    Feadback jeder Art ist wie immer erwünscht ;-)


    Pusti64


    PS: Die "Trackanzeige" zeigt natürlich nicht den aktuellen Track an. Dient quasi nur dazu um die Länge der restlichen "Kaffeepause" abschätzen zu können.

  • So bin zum probieren gekommen. ;)


    UV's schliessen funktioniert auf:


    - REUNative
    - SD2IEC DNP


    so wie es soll. :D


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


    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.

  • Ich versuche das mit dem UV mal bei mir nachzustellen (wenn meine 1571 nur nicht kaputt wäre :gruebel ).


    Beim Umformatieren einer 1571 hast Du aber schon vorher den 1571 Treiber aktiviert? Wenn ja, dann mal kurz eine andere 1571 Disk einlesen. Dann die 1541 Disk einlegen und sofort ohne erneutes einlesen der Disk Formatieren. Funktioniert das dann wenigstens?


    Pusti64

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

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

    Werde es heute Abend versuchen zu richten ;-)


    Thx Pusti64

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

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

    Mal schauen, wie weit ich da mit den 5 gewonnenen Bytes komme :gruebel


    Wie gewonnenen so zerronnen ;-)


    Pusti64