Hallo Besucher, der Thread wurde 116k mal aufgerufen und enthält 801 Antworten

letzter Beitrag von C=Mac am

Screenshots zu GeoDOS Desktop v3

  • Kann man da die Farbe ändern? Das Lila ist schon ein bisschen krass ;-)


    Pusti64

    Wirf mal einen Blick auf den ersten Screenshot in Post#1 ;)


    Weil TopDesk damals (wie heute) ungefragt Systemfarben ändert (die Dialogbox-Farbe) hatte ich den Farben-Editor schon eingebaut um das zurückzuändern... Gibt es ja so in der Art nun auch in GeoDesk.


    P.S. Wobei da wohl die Farbpalette von VICE etwas täuscht... das müsste eher das "Hellblau" sein...

  • Folgendes Problem:


    LW a 1581

    LW b Ultimate Reu

    LW c 1581

    LW D DNP


    Bei dieser Konfiguration bekomme ich immer wieder Grafikfehler siehe Foto

    Bei anderen Konfigurationen 3x 1581 1x Reu tauchen diese Fehler nicht auf,

    nur wenn ich DNP konfiguriere....................

    Keine Abstürze oder Hänger, aber diese Fehler auf dem GeoDesk...........

    Keine Grafikfehler wenn ich ein Programm starte, aber wenn ich zum GeoDesk zurückkomme............


    Grüße

  • Der Fehler tritt ganz sporanisch auf, also wenn ich ein Pro verlasse und zum GD zurückkehre. Das kann der Geos Editor sein, oder Write, aber auch wenn ich die Partion auf A oder C gewechselt habe.

    Eine Karte liegt immer in LW D

    Ich werde das nochmal testen, um den Fehler genauer zu Beschreiben.

  • uwe1972 :

    Könntest Du wenn der Fehler auftritt über die rechte Maustaste das Hintergrundbild mal abschalten und dann gleicher wieder einschalten?

    Wenn das Hintergrundbild aus ist sollte nur ein Muster angezeigt werden. Wenn Du das Hintergrundbild wieder einschaltest könnte man feststellen ob das Hintergrundbild im Speicher beschädigt wurde (dann wären die Grafikfehler wieder da) oder ob es was anderes ist.

  • Ich werde das nochmal testen, um den Fehler genauer zu Beschreiben.

    Anbei ein D64 mit einer aktuellen Testversion von GeoDesk64... nicht für den täglichen Gebrauch geeignet ;)


    Bei der Version hab ich eine Funktion von MegaPatch64 entfernt, die evtl. je nach Laufwerkstyp Probleme machen könnte.


    Das ist aber wirklich eine Testversion, denn ich hab auch einige Routinen "optimiert". Gerade der rechte Mausklick braucht doch recht Lange ohne TC64/SCPU bis das Menü erscheint. Geht jetzt etwas flotter, dafür ist gerade bei NativeMode die Anzeige des Inhalts etwas langsamer.

  • Ich habe das heute Nochmal getestet, Leider (oder zum Glück) konnte ich den Fehler nicht mehr Nachvollziehen................Keine Ahnung was da nun wieder Los ist.


    -Mir fällt aber ein, als der Grafikfehler auftauchte hatte ich einen anderen C64 angeschlossen. Den werde ich nochmal Überprüfen, Ob das nicht an einem mgl. C64 Defekt gelegen haben könnte???


    Die GD-Testversion habe ich getestet, keinerlei Abstürze oder Hänger, Aber wie Beschrieben

    läd alles etwas Langsamer ob nun mit oder ohne DNP Partionen.

    Herzlichen Dank Dafür

  • Die GD-Testversion habe ich getestet, keinerlei Abstürze oder Hänger, Aber wie Beschrieben

    läd alles etwas Langsamer ob nun mit oder ohne DNP Partionen.

    Auf x41/71/81-Laufwerken sollte da kaum ein Unterschied sein, bei Native ist halt besonders bei 16Mb-Laufwerken die GEOS-Routine ein Problem, die den freien Speicher berechnet. Und 65000 Blocks zu berechnen, das dauert halt. Deswegen würde ich auch nur im Notfall 16Mb-Partitionen verwenden.


    Schon vor 20Jahren hab ich max. 1600Kb oder 3200Kb verwendet. Das ist nämlich die Größe die man auf einer CMD-FD auch noch 1:1 sichern konnte.


    Da gab es bisher eine Testroutine die geprüft hat, ob zwischenzeitlich das Laufwerk gewechselt wurde. Falls nein musste der freie Speicher nicht neu berechnet werden. Die hab ich jetzt rausgenommen, den gerade bei Native ließ sich nicht 100%ig sicher sagen ob die BAM auf dem Laufwerk geändert wurde.


    Aber ich schau mir das mal an, evtl. baue ich eine Option ein um die Anzeige des freien Speichern abschaltbar zu machen. Wann immer aber eine Partition oder ein Verzeichnis gewechselt wird kann es auch damit weiterhin eine kurze Verzögerung geben.


    Es gibt noch ein paar "hänger" nach dem wechseln eines Fensters oder wenn man ein Fenster verschiebt. Werde ich mir irgendwann auch nochmal anschauen. Mit SuperCPU/TC64 oder VICE/Warp fällt das halt kaum auf, deswegen hab ich mich bisher nicht darum gekümmert...

  • Es gibt da einen kleinen Bug bei der Anzeige von GEOS-Dateiinformationen, z.B. bei einem PhotoScrap.


    Das kann unter Umständen einen ungültigen Autor beinhalten. Ich vermute da liegt Datenmüll im GEOS-Infoblock. Wenn man sich dann so ein PhotoScrap anzeigen lässt, dann stürzt GeoDesk64 bisher ab.


    Der GEOS 2.x DeskTop zeigt in so einem Fall erst gar keinen Autor an. DualTop zeigt "*" an... GateWay128 zeigt ebenfalls keinen Autor an...


    Ich hab da jetzt eine Prüfung eingebaut. Ist der Autor ungültig wird nichts angezeigt. Ändert man den Autor wird dieser dann in den Infoblock übernommen. Wird im nächsten Update zusammen mit weiteren Verbesserungen enthalten sein.


    Pusti64 : Zur Info: Ich hab das auch mit TopDesk64 getestet. Wenn der Autor ungültige Zeichen (<$20 oder >$7F) beinhaltet, dann stürzt auch TopDesk64 (28.12.20) ab. Hatte das auch mit MP128 getestet, aber da scheint es zu funktionieren, es werden aber wirre Zeichen angezeigt.

  • Es gibt da einen kleinen Bug bei der Anzeige von GEOS-Dateiinformationen, z.B. bei einem PhotoScrap.

    Ich weiss nicht ob man jeden Fehler, den irgendein Programm macht, abfangen muß ;-) .


    Wenn ich mit geoPaint 128 ein PhotoScrap erstelle, dann ist Byte $61 (1. Byte des Autor-Eintrages) 00 und die folgenden unbestimmt. Wenn ich mit dem Foto-Maänager einen Scrap erzeuge, dann sind Byte $61 und folgende mit 00 gefüllt. Das sagt mir, daß ein PhotoScrap keinen Autor enthält.


    Man müßte jetzt mal prüfen, welches Programm solche "fehlerhaften" Autor-Einträge erzeugt. Kann mir nur vorstellen, daß da das Byte $61 nicht auf 0 gesetzt wird ......


    Kannst Du mal so ein FotoScrap hier anhängen?


    Gruß

    Werner

  • Man muss nicht alle Fehler anderer Programme beheben, aber es ist eben falsch wenn ein Programm auf Grund fehlerhafter Daten anderer Programme abstürzt. So sehe ich das zumindest. Daher war es für mich klar das ich das in GeoDesk behebe. Ob Pusti da was am TopDesk ändert ist eine andere Sache.


    DESKTOP 2.x zeigt da generell keinen Autor bei einerm Photoscrap an, selbst wenn der gültig wäre. Hab ich eben nochmal getestet. Evtl. blende ich den Autor bei Datendateien auch komplett aus.


    Anbei ein D64 mit zwei PhotoScraps, eben unter GEOS 64 und GEOS 128 2.x frisch erstellt. Mit GeoPaint neues Bild erstellt, etwas gezeichnet, Edit->Kopieren. Ab $61 steht Programmcode. Bei Paint64 anderer Code als bei Paint128.


    GEOS 2.x, kein MegaPatch... Geopaint von RAMDisk71 gestartet.


    Die Scraps hab ich umbenannt, weil beide sonst den gleichen Namen nutzen.

  • Anbei ein D64 mit zwei PhotoScraps, eben unter GEOS 64 und GEOS 128 2.x frisch erstellt. Mit GeoPaint neues Bild erstellt, etwas gezeichnet, Edit->Kopieren. Ab $61 steht Programmcode.

    Das gleiche hatte ich hier auch unter Geos 64/128 probiert ;-) .


    Allerdings ist mein geoPaint (64/128) mit allen für Geos verfügbaren Patches für geoPaint ((fast) alle von mir ;-) ) gepatcht. Da ist dann Byte $61 mit Null belegt. Deshalb meine Aussage hier: Screenshots zu GeoDOS Desktop v3


    Gruß

    Werner

  • Allerdings ist mein geoPaint (64/128) mit allen für Geos verfügbaren Patches für geoPaint ((fast) alle von mir ;-) ) gepatcht. Da ist dann Byte $61 mit Null belegt. Deshalb meine Aussage hier: Screenshots zu GeoDOS Desktop v3

    Es ist aus meiner Sicht egal ob eine Version gepatched ist oder nicht.


    Ich hab vor kurzem versucht für jemanden eine Boot-Disk mit Anwendungen aus den Original-Boot-Disketten zu erstellen. Ich hab dazu die MegaPatch-Patches von Dir auf die Anwendungen angewendet. Und ich weiß was das für ein Krampf war. Per Download als CVT, dann umwandeln, dann die Anleitung suchen, usw... Das macht der normale Anwender nicht, garantiert. Ich hatte es dann auch aufgegeben... Da muss wirklich mal ein Wiki-Artikel oder HowTo dazu her...


    Also haben wir einen Plain-GEOS-Anwender der evtl. auf MP3 aktualisiert, dann den gleichen Fehler wie ich macht, einfach mal ein paar Dateien über INFO untersucht... und dann einen Absturz beim PhotoScrap bekommt.

    Aktuell sehe ich den Bug bei MegaPatch, mal sehen ob ich das noch behebe... aber falls nicht wird GeoDesk 64 V1.05 das Problem umgehen. Und ich denke das ist der richtige Weg. Unbekannte Zeichen in einem String sollten vor der Ausgabe gefiltert werden. MP3 sollte aber vor solchen fehlerhaften Strings abgesichert werden.

  • Und ich weiß was das für ein Krampf war.

    So kompliziert ist das gar nicht ;-) .


    Mir ist damals (irgendwann in den 1990ern) auch aufgefallen, dass das mit den Patches langsam unübersichlich wird. Deshalb habe ich bei "4 Lfw. für Geos" alle vorhandenen Patches zu einem zusammengefasst. Man braucht also bei Geos nur einmal Patchen (4 Lfw. für Geos). Für MP3 ist dann noch das MP3-Patch zusätzlich erforderlich und das wars.


    Gruß

    Werner

  • So kompliziert ist das gar nicht ;-) .

    Doch... man muss erstmal die passenden Patches finden. Und dann wissen das es die gibt. Und wie gesagt. Für die Bootdisk hatte ich mich nur auf Web-Downloads verlassen... und hab am Ende dann eine meiner alten 3,5"-Disketten mit Deinen Patches ausgegraben. Der Normalo-User hätte längst aufgegeben...


    GEOS mit allen Patches für Anwendungen + MP3 + TopDesk (oder GeoDesk) zu installieren ist keine "Klick&Run"-Aufgabe...


    Daher ja meine Idee mal so ein HowTo zu beginnen. Es wird aber mit Sicherheit kein einfacher Weg... denn alleine die Vielzahl an Hardware macht es nicht so einfach. Und ich hab mit dem Wiki noch keine Erfahrung. Wenn ich mal viel Zeit hab versuche ich mich mal daran...

  • Doch... man muss erstmal die passenden Patches finden. Und dann wissen das es die gibt. Und wie gesagt. Für die Bootdisk hatte ich mich nur auf Web-Downloads verlassen... und hab am Ende dann eine meiner alten 3,5"-Disketten mit Deinen Patches ausgegraben. Der Normalo-User hätte längst aufgegeben...

    Oder alles in der Wolke gefunden... schwer zu sagen, wie viele dort zuerst nachschauen würden... sollte aber vorkommen. :-)

  • Oder alles in der Wolke gefunden... schwer zu sagen, wie viele dort zuerst nachschauen würden... sollte aber vorkommen. :-)

    Klasse...

    Zitat

    Ich will GEOS 2.x mit MP3 installieren...

    Antwort:

    Zitat

    In der Wolke finden sich alle Patches

    Ergebnis:

    Zitat

    open1,8,15,"n:formatgeos,64":close1

    Und zurück zu Windows... was nicht wirklich besser ist. :bgdev


    Hat man keinen Zugang zur Wolke ist ein HowTo Sinnlos... zumindest aus meiner Sicht. Daher suche ich bei Anleitungen immer auf öffentlichen Servern nach den Dateien. Und in einem Wiki auf die Wolke verlinken? Macht wohl auch wenig Sinn...

  • Hat man keinen Zugang zur Wolke ist ein HowTo Sinnlos... zumindest aus meiner Sicht.

    Mag sein - allerdings kann man dem Howto ja jene D64 beilegen mit den Patches.