Hello, Guest the thread was viewed4.1k times and contains 55 replies

last post from darkvision at the

Fehler in TopDesk64 (ggf.TD128) r4/r5 (ggf. auch TD1.3)

  • Kleiner Zwischenstand:

    Weitere Fehler hab ich jetzt nicht mehr gefunden... es gibt zwar noch ein paar Stellen im Code die ich persönlich als Fehler ansehe, aber das ist meist eher ein "unerwartetes" Verhalten (z.B. bei Fenster maximieren/minimieren). Auch gibt es hier und da noch fragwürdigen Code (der schon so in TD13 enthalten ist, z.B. jsr InitForIO/jsr DoneWithIO direkt hinterheinander). Und natürlich das ändern der Systemfarben ;)


    Ich hab insgesamt 56 Stellen im Code gefunden, die nicht mehr verwendet werden. In der Summe >400 Bytes. Wenn ich das in allen Modulen beim assemblieren ausblende, ist TopDesk anschließend 3 Blocks kleiner... und scheint noch zu funktionieren. Sind meistens NOP-Befehle, aber auch nicht mehr ausgeführter Code, z.B. bei Validate findet sich noch Code aus geoDOS64-V2 zum löschen einer BAM auf einer gateWay-RAMDisk. Der Code wird nicht mehr aufgerufen, kann unter MP3 auch nicht auftreten (gibt hier keine gateWay-RAMDisk). Auch das reservieren eines Bootsektors ist noch enthalten, wird aber aktuell nicht ausgeführt. Das sollte wieder rückgängig gemacht werden.


    Ich muss noch die Labels anpassen und an ein paar Stellen selbstmodifizierenden Code entfernen, an manchen Stellen macht das den Code aufwändiger als notwendig. Auch gibt es Texte/Labels im Hauptmodul die nur in den einzelnen Modulen verwendet werden. Auch da ist noch einiges an Optimierung möglich.

  • So, ich hab jetzt aus gegebenem Anlass TD64-21, TD28-21 und TD28-22 nochmal auf den UV-Bug hin überprüft.

    Pusti64 : Ich wollte auch TD128 von Deiner RAMLink-Disk testen, Du meintest da sei eine 24er-Version drauf, ich hab da aber auch nur ein TOPDESK128 von 2021 drauf gefunden. Oder passt da nur das Dateidatum nicht? Ich hab mir die extra nochmal aus der Konv. heruntergeladen.


    Testumgebung:

    FD2000 mit D2M, formatiert als Native. Die Disk hab ich präpariert: Byte #$20 im ersten Dir-Block = $01, Byte #$21 = $02. Das entspricht Ordner-Nr. 1+2 für die beiden ersten Dateieinträge.


    Ergebnis:

    TD64-281221: UV1 erstellt, UV2 erstellt, beide werden nicht angezeigt. Ordner A und B erstellt. Öffne ich Ordner A -> UV1 ist sichtbar, öffne ich Ordner B -> UV2 ist sichtbar.

    Lösche ich jetzt nur die beiden UV, dann verbleibt die Ordner-Nr. an Byte #$20+#$21 im ersten Verzeichnisblock.


    TD128-281221: Wie TD64-21


    TD128-031222:

    UV1 und UV2 erstellt, beide werden nicht angezeigt. Ordner A und B erstellt. Order A geöffnet, dann werden hier beide UV1 und UV2 angezeigt. UV gelöscht, an Byte #$20+#$21 finde ich die Bytes $01,$01 und nicht mehr $01,$02.


    Also betrifft der UV-Bug alle "aktuellen" TD-Versionen. Order Unterverzeichnisse löschen würde ich aktuell auf Programm-/Datendisketten grundsätzlich nicht. Bei TD64 funktioniert das außerhalb eines Ordners, bei TD128 sieht das anders aus (siehe vorherige Beiträge).


    Ich hänge mal das D2M hier als Anhang an, da kann jeder selber testen. Wie oben beschrieben zuerst 2x UV erstellen auswählen, auch wenn im Fenster kein UV angezeigt wird, es ist da! Dann zwei Ordner anlegen und diese öffnen... je nach Version tauchen da dann 1 oder 2 UVs auf.


    Wichtig ist das beim löschen eines UV der Ordner-Eintrag korrekt gelöscht werden. Ansonsten kann es passieren das man mit GeoWrite ein Dokument erstellt, das landet an so einer Stelle mit vorhandener Ordner-Nr und dann ist es a) entweder nur in einem Unterordner oder b) in einem Ordner der nicht existiert -> Man sieht es gar nicht mehr. Eigentlich wäre es gut es gäbe in TopDesk eine Funktion "Ordner deaktivieren" und im Info-Menü eine Funktion "Ordner-Nr. entfernen"...


    Pusti64 : Du kannst mir nochmal eine 24er-Version schicken, ich schau da auf die Änderungen drauf.


    P.S. Ja, das ZIP ist nur 1,9Kb groß... das D2M enthält aber auch fast nur $00-Bytes, lässt sich gut zippen.

  • Vielen Dank fürs testen.


    Testumgebung:

    FD2000 mit D2M, formatiert als Native. Die Disk hab ich präpariert: Byte #$20 im ersten Dir-Block = $01, Byte #$21 = $02. Das entspricht Ordner-Nr. 1+2 für die beiden ersten Dateieinträge

    Ich glaube, ich weiß jetzt auch, warum ich da kein Problem habe ;-) (DNP frisch formatiert, UV1 angelegt, sichtbar; UV2 angelegt, sichtbar, UV3 in UV1 angelegt; sichtbar) .


    Wenn ich das richtig verstehe, tritt das Problem im Zusammenhang mit TD-Ordnern auf.


    Ich würde nie auf die Idee kommen, auf Native-Lfw. TD-Ordner anzulegen. Ich weiß, wo die herkommen. Sie wurden für Geos V2.x auf 1541-, 1571- und 1581-Formaten entwickelt!

    Ganz Früher fand ich die auch mal gut und habe sie auch benutzt. Aber damals bei der Anpassung von geoZIP für Wheels an das alte MP3 (von 2000/2003) habe ich sie hassen gelernt. Ich mußte sie nämlich beim Packen auslassen, wollte ja nicht, daß der Entpackende (der TD nicht hat oder kennt) irgendwelcher seltsamen Dateien auf seinem Rechner nach dem Entpacken findet...


    Gruß

    Werner

  • diese 24er-Version enthält z.B. deinen Vorschlag zum UV-Problem.

    Beim Löschen eines UV habe ich aber noch nichts geändert.


    Pusti64

    Der Code sieht gut aus, hab es auch getestet mit dem D2M von oben, dabei werden dann beim erstellen eines UV jetzt beide Ordner-Nr gelöscht. Auch innerhalb eines Ordners wird jetzt beim erstellen eines UV die Ordner-Nr. an die richtige Stelle geschrieben...

  • Ich würde nie auf die Idee kommen, auf Native-Lfw. TD-Ordner anzulegen.

    Du nicht, andere schon. Und es geht ja auch... und sollte auch keine Probleme machen. Leider hat sich halt ein Bug eingeschlichen, kann passieren.


    Ich war nie ein Fan der Ordner (wegen der inkompatiblen Ordner-Nr. im Verzeichnis) und auch nicht von DNP (wegen der schlechten Struktur der BAM, da ist die der 1541 ja noch besser...). Und 16Mb sind ohne Turbo (am C64 mit 1MHz) echt träge...


    Ordner haben aber einen Vorteil gegenüber UVs: Ich kann Anwendungen und Dokumente in einem Verzeichnis haben, aber in verschiedenen Ordnern, das bringt etwas Struktur rein. Das geht bei UVs nicht, da muss Anwendung und Dokument in einem UV sein. Daher kann ich nachvollziehen wenn Anwender das nutzen wollen. Und wenn es wieder funktioniert spricht da auch nichts dagegen. Ich nutze weder Ordner noch UVs... ich hab mich bei GeoDesk für Filter entschieden. Da ich nur selten mehr als 160 Dateien auf einer Disk habe (nutze ja kein DNP) ist das auch kein Problem...


    Ich bin der Meinung wenn eine Funktion möglich ist, dann muss die Funktionieren. Ob einzelne die Funktion nicht nutzen spielt dabei keine Rolle.. andere sehen das ggf. anders. Und wenn man Ordner auf Native deaktiviert kommt bestimmt jemand und will das wieder aktiviert haben...

  • Wäre diese Behauptung richtig...

    Meines Wissens nach so NEIN!


    Bei der Einrichtung von RAM-Topdesk wird geprüft, ob noch genug RAM frei ist (eine 64 kB-Bank). Ist das nicht der Fall, gibt es eine Fehlermeldung. Das Löschen/Neueinrichten einer RAM-Disk wäre nur nötig, wenn man nicht genug RAM frei hat. Da muß man dann abwägen: große RAM-Disk oder RamTopDesk.


    Gruß

    Werner

  • Nein, das ist da (und wohl auch schon bei TD V1) genauso. Es wird geprüft, ob Speicher frei ist.

    Schau Dir mal den Quelltext zu V1 an (sub10)... ich würde mal behaupten der Code wandert in Bank#0 in den Bereich von REU-MoveData, die Funktion wird danach auch abgeschaltet. Da ist eigentlich kein Platz für alles, aber evtl. für das Hauptmodul. Hier mal ein Auszug:

    Der Kommentar in Zeile#40 ist Original... Zeile#17 ist Bank#0.


    Daher dürfte V1 mit allen RAM-Programmen arbeiten, sofern die nicht selbst den Bereich von REU-MoveData in Bank#0 missbrauchen. Bei den TopDesk1-Versionen spielt daher die RAMDisk keine Rolle. Man müsste sich mal V3.x anschauen, da fehlt mir aber die Motivation dazu...

  • Ich hab in der Zwischenzeit weitere Fehler gefunden... kleinere (Maximieren/minimieren von Fenstern funktioniert nur für genau 1 Fenster) und größere (Disketten mit mehr als 255 Dateien und "zurück blättern"). Ist jetzt aber nichts was einen von der Nutzung des TopDesk abhalten sollte :)


    Für mich selbst hab ich aber ein paar "Verbesserungen" eingebaut, die, oh Wunder, den TopDesk sogar kleiner machen. Aktuell sind es (trotz einiger Bugfixes und Verbesserungen) vier Blocks weniger. Ein Grund dafür ist Code in TopDesk64 der vom MP3-Kernal kopiert, aber nicht "bereinigt" wurde (Bildschirm unter Menü retten/wiederherstellen, ca.90 Bytes entfernt). Oder "Dateien retten", wo das ersetzen des "Alle"-Icons durch Text ca. 30 Bytes einspart. Nicht immer sind Icons die Lösung ;)



    Im Original sind es 218 Blocks.


    Selbst in TopDesk-V1 findet sich Code (der auch in V4/V5 enthalten ist) der sich optimieren lässt. Da sehe ich wirklich einen Vorteil wenn man den Code offen legt und andere sich den Code anschauen können und ggf. kommentieren können.


    Ich hab jetzt die meisten Fehler im Hauptmodul beseitigt... mal sehn was daraus wird. Noch gibt es viel zu tun...

  • Irgendwie erschreckend, wieviele Fehler in TD sind und ich benutze das Programm schon lange (TD128) und hab es nie bemerkt.

    Naja, je komplexer Software wird, desto höher die Chance auf Bugs... sieht man ja an meinen Programmen ;)


    Hier sind es ja zuletzt nur Kleinigkeiten die man vermutl. einfach bisher nicht entdeckt hat weil der Anwendungsfall eher untypisch ist (wer maximiert schon mehrere Fenster und minimiert diese anschließend? Oder wer navigiert beim öffnen einer Diskette über CursorUp zum Ende der Disk?)


    Zumindest ist das verhalten jetzt dokumentiert.


    Deine "Verbesserungen" gefallen mir....................:thumbsup:

    Der TopDesk sieht "Gespiegelt" aus, sicher Ideal für Linkshändler...............

    Die "Verbesserungen" sind ja nur minimal... aber ein Grund warum mir TopDesk nie wirklich gefallen hat war die UI... zu bunt, zu unstrukturiert, zu aufgeregt. Der Datei-Info-Dialog ist ein gutes Beispiel. MP3 hat da klare Vorgaben für die Farbe der Titelzeile einer Dialogbox, aber die Infobox hat weder in Punkto Optik noch in Punkto Farben die Regeln eingehalten. Es wurde halt nie wirklich an MP3 angepasst. Einfach mal die Dateiauswahlbox von MP3 mit der Infobox vergleichen. Wirkt wie ein Fremdkörper.


    Auch die anderen Dialogboxen (kopieren oder überschreiben) sehen zumindest aktuell "konfus" aus. Das "Verschieben"-Icon hatte ja früher die doppelte Breite, mit halber Breite wirkt es aber auch "seltsam". Daher hab ich das ebenfalls entfernt. Das witzige daran: Das "Verschieben"-Icon hat eine komprimierte Größe von 92 Bytes, unkomprimiert wären es ~97 Bytes. Und ich meine die Texte sind kleiner und leichter zu übersetzen... und verständlicher (meine persönliche Meinung),



    Ob das jetzt für den Anwender "Logischer" ist sei mal dahingestellt, es wirkt aber aufgeräumter. Evtl. kommt da noch ein "Oder" dazu um kenntlich zumachen das JA und OK zwei Optionen sind. Es ist aber für mich zumindest konsistent. Aktuell sieht das so aus...



    Fettschrift und Plaintext, verschiedene Icon-Positionen, unterschiedlicher Font im Icon-Text.


    Es sind Kleinigkeiten, aber die UI sah für mich immer nicht "richtig" aus... vermutlich gefiel mir der TopDesk deswegen nie wirklich. Auch meine Bastelversion ist noch nicht so wie sie sein soll, aber in erster Linie entferne ich die Bugs. Die Optik kommt nur wenn mir danach ist was anderes zu machen. Heute eben die Kopieren-DBs...


    Auch das der TopDesk ungefragt die Systemfarbe der Dialogbox geändert hat war mir schon immer ein Dorn im Auge (ist zwischenzeitlich abgestellt... die Farbe der TopDesk-Dialogbox kann man zwar noch ändern, hat aber keine Auswirkungen mehr auf andere DB außerhalb des TD).


    Viel schlimmer finde ich aber den Code selbst. Da gibt es massiv selbst-modifizierenden Programmcode. Bei einer Demo die zur Laufzeit optimiert wird ist das ja OK, hier aber ist der Code gleich 3x enthalten: 1x im Original, 1x modifiziert und 1x zurückgesetzt. Dazu kommen dann die STA-Befehle um den Code anzupassen. Hier und da ein Flag-Test wäre wesentlich effizienter und weniger Fehleranfällig. Einiges hab ich schon entfernt... und wie zu erwarten war wurde der Code kleiner.


    Auch ist der Code hier und da auf viele Stellen verteilt. Man sieht einfach das hier verschiedene Personen daran gearbeitet haben. Hier und da wurde dann was eingefügt, evtl. noch bevor der Code für TDv5 reassembliert und optimiert wurde. Das hat was von "Patches" die man an passende Stelle eingefügt hat.


    Es gibt viele Punkte die ich geändert habe die hier gar nicht erwähnt wurden. Hier geht es in erster Linie auch nur darum die groben Fehler zu dokumentieren, ob die dann auch behoben werden ist ein völlig anderes Thema.


    Die Screenshots oben dokumentieren nur wie ich mir den TopDesk damals hätte vorstellen können... und das "gespiegelte" soll nur kenntlich machen das es meine Bastelversion ist (und ja, selbst da gibt es eine Verbesserung: Man kann das Laufwerk-Icon beim tauschen nicht mehr woanders ablegen...)


    P.S. Zum Thema Dokumentation noch das hier:


    Ich muss mir davon mal ein Buch drucken lassen... knapp 600 Seiten... wenn ich denn mal damit abgeschlossen habe.


    P.S.2: Ja, so sieht es für mich besser aus:

  • Und beim vorbereiten des heutigen commit hab ich noch einen kleinen "Möchtegern-Bug" gefunden, also etwas das nicht richtig ist, aber (aktuell) keinen Fehler produziert.

    Code
    1. ; *FEHLER*
    2. ; Hier wird ein Byte mehr kopiert als
    3. ; eigentlich erforderlich.
    4. ldy #7
    5. :x705A lda v706D,y ;GEOS-Register in
    6. sta r0,y ;REU aktualisieren.
    7. dey
    8. bpl x705A
    9. jmp StashRAM

    Eigentlich werden hier die Register r0 bis r3L initialisiert, also 7 Bytes. Das y-Register müsste also mit ldy #7-1 = ldy #6 initialisiert werden. Aktuell produziert das keinen Fehler. Wenn aber eine andere Routine sich auf den Wert in r3H verlässt würde das ggf. einen Fehler verursachen.


    Durch die Überarbeitung des TD-SourceCodes hab ich für mich selbst was gelernt, nämlich wie obiges einfacher geht:

    Code
    1. ldy #(r3L - r0L)
    2. :x705A lda v706D,y ;GEOS-Register in
    3. sta r0,y ;REU aktualisieren.
    4. dey
    5. bpl x705A
    6. jmp StashRAM

    Da muss man nicht mehr die Anzahl der Bytes berechnen die in der Schleife initialisiert werden sollen. Durch das von-bis ist das klar ablesbar.


    Es gibt noch andere Fälle wo sowas mit ganzen Zahlenwerten fehleranfälliger ist: Beim sichern von Registern auf den Stack. Hier mal ein Beispiel:

    Ist zwar richtig (und entspricht dem Objectcode), aber klarer wird es im SourceCode damit:

    Man sieht sofort das die Register r0L bis r15H gesichert/zurückgesetzt werden (mal abgesehen davon das es an der Stelle gar nicht erforderlich ist, die beiden Loops kann man komplett löschen).


    Oder das hier:

    Der Initialisierungs- bzw. Vergleichswert für das X-Register ist ein definierter Wert, da kann man schnell mal die falsche Zahl reinschreiben. Klarer wird es so:

    Beim abwärtszählen reicht ein von-bis. Beim aufwärtszählen ist beim cpx ein +1 erforderlich (ein BEQ+BCC wäre 2 Bytes länger).


    Für mich selbst hab ich die Schreibweise jetzt verinnerlicht da es den Code lesbarer macht und (Tipp-/Denk-)Fehler reduziert. Ist evtl. was für das MegaAssembler-Handbuch :)


    Also Code-Analyse kann hier und da auch helfen die schreibweise des eigenen Code zu verbessern. Ein Grund mehr weiterzumachen :)

  • Gefällt mir :thumbup:, was du da machst...................


    Der erste Topdesk, (Ich meine den von der Geos 2.5 Diskette, in s/w)

    hatte etwas, was es nie wieder bei einem der Nachfolger gab/gibt

    Das beste am Original, was mir bis heute etwas fehlt:

    Beim Anklicken eines Laufwerks wurden die Fester "Ausgespuckt",

    ein sehr schöner Effect, den ich heute manchmal etwas Vermisse...................:P

    Aber das nur Nebenbei..............