Hallo Besucher, der Thread wurde 141k mal aufgerufen und enthält 1104 Antworten

letzter Beitrag von Juergen Johannes am

GEOS MegaPatch V3 Release 2018

    Zitat von darkvision

    Demnach scheint es mit verschiedenen Laufwerken möglich zu sein, ich hatte dabei aber schon zerstörte GeoWrite-Dokumente.

    Müßte man wirklich mal prüfen ;-) .

    Eine Ursache könnte das 4-Lfw-Patch sein. Das originale geoWrite (und die anderen) kann ja nur A: und B: . Wenn man jetzt auf C: oder D: arbeitet, dann könnte im Patch "vergessen" worden sein, diese Stelle (laden und speichern von Scraps) auch darauf anpzupassen (möglicherweise hat ein gewisser wweicht da vor vielen Jahren etwas geschlampt ;-) ). Solange man aber auf A: und B: bleibt, sollte es theoretisch funktionieren ...


    Gruß

    Werner

    Ich hab mir das mal angeschaut und das dürfte nur ein Problem mit 1581 und ggf. NativeMode-Laufwerken sein.


    geoWrite wechselt zwischen App- und Doc-Laufwerk. Dabei wird SetDevice aufgerufen was den Treiber aus der REU lädt. Das Problem ist das dabei auch ein Teil der BAM auf den zuletzt aktualisierten Wert zurücksetzt da der dritte BAM-Sektor im Treiber gespeichert wird (bei 1541/1571 gibt es max. zwei BAM-Sektoren im Speicher, aber außerhalb des Laufwerkstreibers).


    Damit kann je nach Lage des reservierten Blocks für das PhotoScrap evtl. ein Sektor belegt werden, geoWrite wechselt das App-Laufwerk und wieder zurück zum Doc-Laufwerk und dann ist der zuvor belegte Sektor wieder "Frei", da die BAM nicht auf Disk aktualisiert wurde.


    Mann müsste das jetzt mal mit GEOS 2.x und einem Original GeoWrite testen. App auf A: und Doc auf B:, beides 1581. Da aber auch im Original-GEOS immer $0D80-Bytes = Größe des Laufwerkstreiber getauscht werden müsste das da genauso sein. Bei jedem Wechsel des Treibers wird eine temporäre Änderung in der BAM nicht gespeichert.


    Das seltsame ist das die MP3-Treiber eigentlich für den Fall sogar eine extra Routine bekommen haben, die beim Aufruf von SetDevice ebven diesen 3.BAM-Sektor im Kernal aktualisiert. Da müsste ich jetzt mal schauen warum das nicht ausgeführt wird.


    Bis dahin gilt aber bei 1581/Native und einfügen eines PhotoScraps besser APP+DOC auf dem gleichen Laufwerk. Dann wechselt der Kernal den Laufwerkstreiber nicht und die BAM wird dann auch nicht zurückgesetzt.

    P.S. Kleine Ergänzung:

    Das Problem tritt nur auf wenn auf dem Doc-Laufwerk der erste Sektor für das PhotoScrap beim speichern im Dokument auf Track 41-80 liegt. Das ist der 3.BAM-Sektor der ab $9C80 im Bereich des Laufwerkstreiber gespeichert wird.


    Auf einem leeren Laufwerk oder wenn die benötigten freien Blöcke auf Track 1-40 liegen, dann dürfte es daher keine Probleme geben. Ich hab nur einen kurzen Test mit einer leeren RAMDisk gemacht, da funktioniert es.

    Zitat von DJ SID

    Ist es richtig, daß ich die Scrap-Funktion unter MP64/128 nicht mehr nutzen kann?

    Ist wohl behoben. Gibt einen neuen Snapshot auf https://bitbucket.org/mkgit64/area6510/downloads/ .


    Aber es gibt ein mögliches weiteres Problem mit geoPaint128 und Taskmanager, das lt. Change.log noch genauerer Untersuchung bedarf...


    Gruß

    Werner

    Hallo,


    habe den aktuellen MP3 Snapshot (64 und 128 von heute früh) jetzt einige Male installiert und bisher keine Probleme festgestellt.


    Aber im Setup (beide Versionen) steckt ein Fehler, der wohl schon länger drin ist (wohl seit DESKTOP nicht mehr mitgeliefert wird) und auch mir nicht auffiel, obwohl ich ihn zumindest bei MP3-64 jedes mal am Bildschirm gesehen habe ;-) (DESK TOP wurde gestartet). Bei MP3-128 ist es nicht ganz so extrem, da es da eigentlich nur einen Desktop gibt (Topdesk), der auf MP3 ausgerichtet ist. Aber das Problem ist auch vorhanden, wenn ein anderer Desktop benutzt wird.


    Erklärung:

    Was steht im letzten Bild bei der Installation? Richtig, man soll/muß irgendeinen Desktop benutzen. Problem: Ich habe ein älteres MP3 mit GEODESK. GEODESK ist der Desktop und liegt irgendwo auf einem Laufwerk. Wenn jetzt die Installation auf einer leeren Disk durchgeführt und abgeschlossen ist, habe ich ein Problem. Es wird nach einer Datei namens "DESK TOP" gesucht, die aber nicht da ist...

    Ich habe das bisher deswegen nicht bemerkt (beachtet), weil ich bei MP3-64 immer auch den Topdesk 64 auf der Bootdisk habe (ich überschreibe immer die alte Bootdisk). Deshalb konnte das Setup bei mir immer auch ohne Probleme beendet (verlassen) werden.


    Meiner Meinung nach müßte sich das MP3-Setup den zu Beginn den im Kernel verankerten Desktop-Namen merken und ganz am Ende dort wieder eintragen. Dann wird nach Abschluß der Installation ein irgendwo vorhandener GEODESK auch gefunden und ich kann ihn vor einem Neustart auf die neue Bootdisk kopieren...

    Wenn nicht, muß ich im Extremfall nach der Installation der neuen Version mein altes System nochmal starten, um den benutzten Desktop auf die neue Bootdisk kopieren können...


    Gruß

    Werner

    Zitat von wweicht

    Meiner Meinung nach müßte sich das MP3-Setup den zu Beginn den im Kernel verankerten Desktop-Namen merken und ganz am Ende dort wieder eintragen.

    "Won't fix."

    Der Standard-Name ist "DESK TOP". Wenn Du einen anderen DeskTop startest (wie auch immer, selbst die Datei "TopDesk 64" wird von MP3 ja nicht automatisch gestartet), dann hast Du das System verändert. Auch GEODESK muss in "DESK TOP" umbenannt werden um automatisch zu starten. Ausnahme sind die GO/...-Tools. Aber das ist ein Custom-Setup.


    Aber selbst wenn ich das in GDOS (das ja mehrere DeskTop-Namen unterstützt) über die GD.INI gelößt haben sollte, dann ist die Adresse wo der DeskTop-Name im Kernal steht nicht genau definiert. Eine 100%ige Erkennung des Namens ist gar nicht bzw. nur mit großem Aufwand möglich. Das fange ich bei einem System das sein EOL erreicht hat nicht mehr an. Außer Dir hat das ja bisher keiner bemängelt, und wie der Geopaint128-Bug (der seit 3.3r9 enthalten war) scheint das System auch kaum noch jemand wirklich zu nutzen. Lohnt den Aufwand nicht.

    Im Anhang ein D64 mit den schon im GDOS64-Thread angesprochenen Maustreibern, die für MP3 ein Problem mit IconPainter (Die Malfunktion ist dauerhaft aktiv...) beheben. Das Problem betrifft MP64 und MP128. Die Treiber sind sprachunabhängig, gelten also für MP3-DE und MP3-EN. Ich lade das auch noch auf die AREA6510 hoch...


    Das Problem führe ich direkt auf einen Fehler im MegaAssembler-Handbuch zurück (mouseData, S.193), wo falsche Werte für Button gedrückt oder nicht aufgelistet werden. Es war damals wohl schnell klar das die Werte vertauscht sind, aber trotzdem noch einen Fehler enthalten. Das ist in den Errata der Bachmänner zum MegaAss auch beschrieben (letzter Stand ist wohl 29.7.1998).


    Die Maustreiber entstanden aber schon viel früher, mein SuperSmart64-Treiber vom Feb.1997 hat den Fehler auch schon drin.


    Ich hab das später irgendwann bemerkt das man $80 und nicht $FF nach mouseData schreiben sollte (so macht das auch GEOS-V2) und das in meinem MegaAss-Handbuch mit Tipp-EX reinkorrigiert. In die Maustreiber ist das aber nie eingeflossen, weil es wohl kein Programm gab das damit ein Problem hat. Bis auf den kürzlich getesteten IconPainter. Mit dem falschen Wert in mouseData denkt das Programm der Feuerknopf bzw. Mausbutton ist gedrückt und zeichnet ohne Unterbrechung.


    Vermutlich ist das der älteste Bug in MP3, das zu dem Zeitpunkt gerade erst am entstehen war... 25Jahre...


    Beim nächsten Build kommen die Treiber automatisch mit... ansonsten kann man den manuell über TopDesk&Co laden oder direkt auf der BootDisk austauschen. Ich hab das unter VICE mit MP3-64 und MP3-128 (IconPainter läuft nur im 40Z-Modus) getestet.


    Vielleicht setze ich mich doch mal dran und aktualisiere das MegaAss-Handbuch. Das PDF in der Wolke ist ja auch unvollständig und die Fehler könnte man mal korrigieren. Die Errata und Ergänzungen könnte man direkt einpflegen, den MegaAss-V4 als Anhang/Zusatz mit aufführen. Naja... die fehlenden Index-Seiten und Kapitel 2 hab ich eh schon als Text, da fehlen ja nur noch knapp 400 Seiten ;) Der langen Winterabende rücken ja so langsam näher... :whistling:

    Zitat von wweicht

    Was ist IconPainter? Ich überlege schon ein paar Tage (wurde ja in einem anderen Thema schon erwähnt) welches Programm da gemeint sein könnte... ;-) . Der Name sagt mir nichts. Von welcher Quelle stammt das Prg?

    Vielleicht hat das Programm auch einen anderen Namen... die GEOS-Klasse zeigt P/S-Editor, muss ja aber nichts heißen. Im Infoblock tauch aber M&T auf, evtl. ist Dir das ein Hinweis. Aber hier ein paar Screenshots, evtl. sagt Dir das mehr. Die Quelle kann ich Dir nennen... meine Programmsammlung von damals. Woher ich das Programme hatte, keine Ahnung.


    Es spielt aber auch keine Rolle (ausser das man damit das Fehlverhalten der Maustreiber testen kann). Unter GEOS 2.x mit dem Wert $80 in mouseData funktioniert das Programm auch. Mit dem alten MP3-Maustreiber runter GEOS2 zeigt das Programm den Fehler, mit dem neuen Maustreiber nicht mehr. Es wird auch nur der Wert geändert der nach mouseData geschrieben wird... $00/$80 und nicht mehr $00/$FF.


    P.S. Ha... gefunden!!! Dürfte der P/S-Editor aus dem MegaPack2 sein...

    Zitat

    Der P/S-Editor dient zum Editieren von Datei-Piktogrammen und Sprites.

    Was dann aber seltsam ist, denn ich muss das Programm ja dann auch mal getestet haben, sonst hätte ich das nicht auf meine Anwendungsdisk kopiert. Ist aber wohl schon 1990 rausgekommen, evtl. hab ich das dann damals vorher kopiert und mit GEOS 2 geht es ja und dann mit MP3 nie mehr getestet... und wohl auch kein anderer ;) Wobei es mit einem Joystick gehen müsste... vielleicht sind ja alle Nutzer des Programms GEOS2 oder Joystick-Anwender...


    P.P.S. Auf der MegaPack2-D2 ist es drauf.... hab ich auf meinen Originaldisketten gefunden...

    Es ist schon sehr lange her seit ich mich mit dem C128/64 beschäftigt haben.

    Wird mal wieder Zeit, falls sie überhaupt noch funktionieren.

    Hab aber glaub schon alles vergessen :rolleyes:


    Kann man von einer älteren MP3-Version (ca. 2 Jahre her) gleich auf die Aktuellste wechseln?


    Wie ich gesehen habe gibt es eine neue Webseite von darkvision.


    Gruss C=Mac.

    Zitat von C=Mac

    Kann man von einer älteren MP3-Version (ca. 2 Jahre her) gleich auf die Aktuellste wechseln?

    Ja.


    Zitat von C=Mac

    Wie ich gesehen habe gibt es eine neue Webseite von darkvision.

    Ja, dort findest Du auch die aktuelle (Test)-Version (21.08.2022) zum Download. Das "Test" sollte man nicht so ernst nehmen ... ;-) Läuft hier problemlos


    Gruß

    Werner

    Hallo,


    irgendwie habe ich ein Problem unter MP3-128 (aktuelle Version) ;-) . Habe das jetzt nur unter MP3-128 probiert (WinVICE), aber es ist zuverlässig nachvollziehbar.


    Das Problem betrifft die benutzerdefinierte Dialogbox mit Icons. Wenn ich hier ein Icon anlege, dann ändert sich die Position des Icons, je nachdem ob meine DB einen Schatten hat oder nicht. DBs mit Schatten scheinen wie gewollt zu funktionieren.


    Anbei ein D64 mt einem kleinen Testprogramm und dem Quellcode dazu. Das Programm läuft nur unter MP3-128.

    Übrigens, wenn ich die 2 DBs im Quellcode tausche (erst mit Schatten, dann ohne Schatten), dann stimmt die Icon-Position bei beiden überein. Sehr seltsam das ...


    Ich habe zwar eine Lösung für mein geplantes Prg gefunden (Hintergrund = Schatten-Muster der DB), so daß der Schatten quasi nicht sichbar ist, aber ... ;-)


    Gruß

    Werner


    PS: Es kommt vor (größere DB und mehrere kleinere benutzerdefinierte Icons) daß die Icons teilweise weit außerhalb der DB dargestellt werden.

    Zitat von wweicht

    Das Problem betrifft die benutzerdefinierte Dialogbox mit Icons. Wenn ich hier ein Icon anlege, dann ändert sich die Position des Icons, je nachdem ob meine DB einen Schatten hat oder nicht. DBs mit Schatten scheinen wie gewollt zu funktionieren.

    Also auf den ersten Blick ist das seltsam, aber nicht immer reproduzierbar.



    Unter dualTop liegt das OK-Icon beim ersten Start außerhalb der Box, bei einem zweiten Start passt es dann. Bei TopDesk passt es nie... das wirft den Verdacht auf das hier ein Wert nicht korrekt initialisiert wird. Müsste mir den 128er-Kernal mal anschauen. Unter MP64 scheint die Position immer gleich zu sein.


    Mal sehen was ich da rausfinden kann... Ob Farbe aktiv oder nicht (über GEOS.Editor) scheint daren jedenfalls nichts zu ändern.

    Zitat von darkvision

    das wirft den Verdacht auf das hier ein Wert nicht korrekt initialisiert wird.

    Ja ;-) .


    Nur zur Ergänzung:

    Für mich (in der konkreten Anwendung) sieht das folgendermaßen aus (2 geoPaint-Doks vom 80 Zeichen-Screen im Anhang).

    Bei "kaputt" (Schatten der DB ist aus) scheinen die Koordinaten der 5 Icons oben verdoppelt zu werden. Die 4 Pfeile müßten links vom Namen stehen und das Schließen-Icon rechts. Das Schließen-Icon ist soweit nach rechts gewandert, dß es in "einer neuen Zeile" erscheint (etwas tiefer).

    Bild "OK" zeigt, wie ich mir das eigentlich gedacht habe (Schatten ist an, mit gleichem Muster wie Hintergrund) ...


    Und ja, das da oben ist eine Dialog-Box, auch wenn es nicht so aussieht ;-)) . Aber es erfüllt so seinen Zweck (die Icons sind aktiv und das Menü ist deaktiviert).


    An Farbe liegt es nicht, hatte ich schon probiert...


    Gruß

    Werner

    OK, es scheint etwas mit dem Wert in dlgBoxDblBit (DB_DblBit, $8871) zu tun zu haben und damit mit der Verdoppelungstechnik von GEOS128. Wenn Du die X-Koordinate des OK-Icon wie folgt änderst:

    Code
    1. b OK,1!DOUBLE_B,1,NULL

    Also die Verdoppelungstechnik aktivieren, dann klappt es immer.


    Das passt auch zum obigen Verhalten das es bei mir ab&zu auch ohne Anpassung funktioniert. In TopDesk ist das Bit gesetzt (was nicht unbedingt heißen muss das TopDesk das Bit verändert, evtl. ruft TopDesk eine GEOS-Routine auf die das dann setzt). In dualTop ist es nach dem ersten Start gesetzt, nach dem ersten Start der Dialogbox dann nicht mehr. Setze ich den Wert manuell auf "0" dann klappt das mit der Dialogbox auch unter TopDesk.


    In deinem Fall dürfte ein lda #0; sta $8871 ausreichen, wenn Du nicht mit der Verdoppelungstechnik arbeitest. Ich muss mir den Code dazu aber genauer anschauen um rauszufinden wie man das im Kernal anpasst. Das mit den Icon-Positionen und Größen mit und ohne Verdoppelungstechnik ist mir aber schon seit 2018 immer wieder mal aufgefallen. Bisher wurde einfach der Wert von graphMode nach dlgBoxDblBit kopiert und dann passte es. Evtl. weil die getesteten Dialogboxen die Verdoppelungstechnik nutzen.


    Danke für den Hinweis. Ich kann da aber nichts versprechen... denn das Verhalten ist auch unter GEOS128 (ohne MegaPatch) so nachvollziehbar, d.h. vor dem Start $8871 auf $00 setzen, dann geht das mit der Dialogbox.

    Zitat von GEOS-MegaAssembler Errata von R+R.B.

    $8871

    Hier muß im GEOS 128 eine Kopie von graphMode stehen, damit im 80-Zeichenschirm in einer Dialogbox

    ohne Schatten die Icons korrekt dargestellt werden.

    Da kam Dein Hinweis gerade noch rechtzeitig, werde ich in meiner Version des Handbuchs anpassen, denn $8871 muss $00 sein wenn man im 80Z-Modus keine Verdoppelung einsetzt. Daher ist es keine Kopie von graphMode.

    Zitat von wweicht

    Und ja, das da oben ist eine Dialog-Box, auch wenn es nicht so aussieht ;-)) . Aber es erfüllt so seinen Zweck (die Icons sind aktiv und das Menü ist deaktiviert).

    Ich hab mir die beiden Screenshots mal angeschaut, da ist das schon auffällig. Du kannst es ja mal mit dem $8871-Trick versuchen ob das damit dann verschwindet.


    Aber warum überhaupt eine Dialogbox? Auch wenn es gut ist weil man damit einen Fehler gefunden hat, aber das geht doch auch mit DoIcons. Egal, wird schon seinen Grund haben ;)


    Ah... wer lesen kann: Menü soll deaktiviert werden.