GEOS MegaPatch V3 Release 2018

Es gibt 1.222 Antworten in diesem Thema, welches 218.947 mal aufgerufen wurde. Der letzte Beitrag (2. Juli 2025 um 17:17) ist von darkvision.

  • Ich dachte, das geht jetzt über den GEOS128.EDITOR bzw. mit dem GEOS.ColorEditor???

    Pusti64

    Aber nicht für TopDesk... der nutzt ja die eigenen Farben und greift nicht auf die MP3-Farbtabelle zu. Wäre natürlich toll wenn man das ändern könnte ;)

    P.S. Ein Beispiel ist z.B. das Pulldown-Menü, dafür gibt es in der MP3-Farbtabelle einen Farbwert. Die Farbe in TopDesk stellt man aber über Spez./Farben ein... würde sich TopDesk die Farbe aus der MP3-Farbtabelle holen, dann könnte man die Farbe des Menüs über den ColorEditor anpassen.

  • Aber nicht für TopDesk... der nutzt ja die eigenen Farben und greift nicht auf die MP3-Farbtabelle zu.

    Genau darum geht es bei meinem Vorschlag (siehe Bitte melde dich an, um diesen Link zu sehen. ).

    Für "Fenster 1" gibt es C_WinBack, für normale DB gibt es C_DBoxBack, für Menü gibt es C_PullDMenu. Hier können wir einfach die MP3-Farben benutzen.

    Die anderen Sachen sind eher TD-only und sollten dort bleiben. Man könnte hier natürlich irgendwelche andern MP3-Farben in TD benutzen, das ist aber nicht wirklich hilfreich (eher verwirrend!), da die MP3-Farben bestimmten Sachen zugeordnet sind.

    Und wenn wir jetzt noch die 80-Zeichen-Icons (Farbe an/Farbe aus/Standard; es gibt wohl noch ein paar mehr im TD versteckt) durch die 40-Zeichen-Icons ersetzen und über DOUBLE_W & Co verdoppeln, dürfte das auch einges an Speicher sparen. Das ist zwar nicht für alles sinnvoll (ich denke da z.B. an die Laufwerks-Icons) aber für vieles eben doch.

    Ich war bisher auch der Meinung, reine 80-Zeichen-Prg brauchen keine automatische Verdoppelung aber aus Speicherplatzgründen ist sie in vielen Fällen eben doch sinnvoll.

    Eben möglichst viele TD-Farb-Einstellungen mit den MP3-Farben erschlagen. Aber es gibt eben nicht für alles eine Entsprechung (Geos-Schaltfläche, Laufwerks-Icons und und und... Und nur diese sollen in TD bleiben.

    Gruß

    Werner

    PS: Doch, TD greift auf die MP3-Farbtabelle zu, z.B. für die 2 DBs (normal und Fehler). Da (zumindest an dieser Stelle) wird aber nichts permanent geändert. Nachem die DB geschlossen ist, steht in der Farbtabelle wieder der Wert, der da vorher stand :wink: .

  • Mit dem neuen Snapshot sollte die Farbauswahl wieder korrekt funktionieren...

    Ich war bisher auch der Meinung, reine 80-Zeichen-Prg brauchen keine automatische Verdoppelung aber aus Speicherplatzgründen ist sie in vielen Fällen eben doch sinnvoll.

    Ja, es gibt (und gab es bereits unter GEOS2.x) Dialogboxen, wo man das machen sollte, weil sonst einige System-Icons in seltenen Fällen nur mit halber Breite angezeigt werden. Hab mir jetzt ein Testprogramm geschrieben mit dem ich solche Fehler auch unter GEOS 2.x nachstellen kann. Ich hab die Farbwahl in TopDesk (Nicht-Standard-Dialogbox ohne DOUBLE_W) mal auf DOUBLE-W umgestellt, funktioniert. Und dann könnte man auch auf das lda #$80; sta DB_DblBit in der DBUSRROUT-Routine verzichten. Musste nur die Breite im Tabellenkopf mit DOUBLE_W anpassen und die X-Koordinate der 5 Icons von $90 auf $95 ändern. Kein Byte mehr, aber 5 Bytes eingespart.

    PS: Doch, TD greift auf die MP3-Farbtabelle zu, z.B. für die 2 DBs (normal und Fehler). Da (zumindest an dieser Stelle) wird aber nichts permanent geändert. Nachem die DB geschlossen ist, steht in der Farbtabelle wieder der Wert, der da vorher stand :wink: .

    Damals wusste man es wohl nicht besser, aber da müsste man doch eine Dialogbox mit Farb-Bit verwenden können, d.h. mit Farbangaben. Dann könnte man die TopDesk-Farbe direkt in den Tabellenkopf schreiben und gut ist.

    Ansonsten bin ich bei Dir: Das was MP3 an Farben bietet kann man verwenden, für den Rest könnte man die Farbwahl in TopDesk einschrumpfen. Für den Bereich rechts könnte man die GEOS-Bildschirmfarben verwenden. Für die TopDesk-Fenster könnte man die Fensterfarben verwenden (falls 8x8 kompatibel). GEOS, Zähler und Uhr Lfwk-Icons sind Sonderelemente... Da bin ich auch der Meinung könnte man einiges einsparen.

    Aber da klinke ich mich jetzt aus, falls es keine weiteren Probleme mehr in MP3 gibt... ich nutze TD nicht. Hab mir für Tests aber eben nochmal die US-Version auf die Arbeitsdiskette für MP3-US-128 kopiert. Damit passt die Farbwahl-Box auch.

  • Mit dem neuen Snapshot sollte die Farbauswahl wieder korrekt funktionieren...

    Erster kurzer Test (MP3-128) :

    Die Farb-Einstellungs-Dialogbox sieht wieder normal aus und bei der InfoBox stimmt das Schließen-Icon jetzt auch wieder. Die verschobene Icon hier kam wohl durch eine ungewollte Verdoppelung. Gute Arbeit, Danke.

    Und dann könnte man auch auf das lda #$80; sta DB_DblBit in der DBUSRROUT-Routine verzichten. Musste nur die Breite im Tabellenkopf mit DOUBLE_W

    Was ich hier meine mit Speicherplatzgründen meine ist: Das Icon hat 12 Cards Breite. Das sind sicher mehr Daten, als bei einem "40-Zeichen"-Icon, das nur 6 Cards breit ist und nur verdoppelt dargestellt wird.


    In den nächsten Tagen werde ich nochmal TD128 gründlicher untersuchen und nach Stellen suchen, wo dieses ominöse DB_DblBit (gibt es eigentlich irgendwelche Infos darüber, habe nichts gefunden) benutzt wird. Eine Stelle im letzten VLIR-Modul haben wir ja bereits... Dann mache ich einen Patch dafür fertig der das komplett aus TD128 entfernt.

    Auf jeden Fall gilt: Dieses DB_DblBit hat in keiner Anwendung was zu suchen. Es wird wohl intern von der Dialogbox-Routine benutzt um die System-Icons bei Bedarf automatisch zu vergrößern.

    Ich glaube aber, es wird außer bei TD128 nicht allzuviele Prg geben, wo das (warum auch immer) benutzt wird.....

    Und weitere Diskussionen zu TD128-Problemen, neuen Versionen und Patches sollten wir im TD128-Thread weiterführen:

    Bitte melde dich an, um diesen Link zu sehen.

    Gruß

    Werner

  • In den nächsten Tagen werde ich nochmal TD128 gründlicher untersuchen und nach Stellen suchen, wo dieses ominöse DB_DblBit (gibt es eigentlich irgendwelche Infos darüber, habe nichts gefunden) benutzt wird.

    DB_DblBit ist im RRB-Addendum $8871:

    Zitat

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

    Was nicht ganz richtig ist: DB_DblBit wird von DoDlgBox als Zwischenspeicher für die Verdopplung verwendet. Zu Beginn wird die Dialogbox gezeichnet, wenn hier bei Xlinks (r3H) das DOUBLE_W gesetzt ist, dann wird DB_DblBit auf $80 gesetzt. Der Wert wird dann für die System-Icons zur Verdopplung verwendet. MP3 sollte den Wert jetzt zu Beginn immer überschreiben, eine DBUSRROUT-Routine kann das aber nach Aufbau der Box wieder überschreiben.

    Was ich hier meine mit Speicherplatzgründen meine ist:

    Das ist mir schon klar, wird nicht ganz die Hälfte sein da die Bitmap womöglich komprimiert ist. Ganz persönlich würde ich die gleiche Schrift wie bei OK/Cancel versuchen. Oder die Buttons ganz weglassen und mit DBOPVEC auf einen Mausklick innerhalb der Dialogbox prüfen und eine Checkbox an-/ausschalten. Da ließe sich (vermutlich) noch mehr sparen. Aber das ist nicht meine Baustelle ;)

    Auf jeden Fall gilt: Dieses DB_DblBit hat in keiner Anwendung was zu suchen. Es wird wohl intern von der Dialogbox-Routine benutzt um die System-Icons bei Bedarf automatisch zu vergrößern.

    Das deckt sich mit meinen Nachforschungen... dabei hab ich jetzt festgestellt das es sogar einen Unterschied macht ob man GEOS 2.x.original startet, oder eine mit GeoMakeBoot erstellte Diskette. Und dabei macht es noch einen Unterschied ob man zwischendurch 1x eine Standard-Dialogbox aufgerufen hat oder nicht: DoDlgBox verändert nämlich direkt Kernal-Code und vererbt einer GeoMakeBoot-Diskette dann den "Bug" beim Verdoppeln der System-Icons. Das ist das einzige was ich jetzt in MP3 von heute noch anders mache als im Original-GEOS, da ich das als Bug ansehe.

    Ich glaube aber, es wird außer bei TD128 nicht allzuviele Prg geben, wo das (warum auch immer) benutzt wird.....

    Im VICE-Monitor: watch store 8871 ... Wenn das irgendwo im Kernal ($8000-$ffff) unterbricht, dann ist das OK, eine Adresse von $0400-$7fff wäre die Anwendung, eher nicht OK... Es schadet jetzt nicht mehr (bzw. ändert nichts mehr), da DoDlgBox den Wert jetzt immer setzt (Ausnahmen waren ja nur Standard-Box ohne Schatten oder Benutzerbox direkt nach dem Boot).

    Und weitere Diskussionen zu TD128-Problemen, neuen Versionen und Patches sollten wir im TD128-Thread weiterführen:

    :dafuer:

  • Hallo,

    Musste nur die Breite im Tabellenkopf mit DOUBLE_W anpassen und die X-Koordinate der 5 Icons von $90 auf $95 ändern. Kein Byte mehr, aber 5 Bytes eingespart.

    Tusch :wink: . Auch ich weiß mal was :wink: :

    siehe altes MegaAss-Handbuch S. 222 "3.3 Dialogboxen unter GEOS 128" :wink:

    es sogar einen Unterschied macht ob man GEOS 2.x.original startet, oder eine mit GeoMakeBoot erstellte Diskette.

    Das ist mehr oder weniger ein alter Hut :wink: .

    GeoMakeBoot speichert im Prinzip das im Speicher des Rechners befindliche Geos-Kernal so auf Diskette, daß es wieder gestartet werden kann. Das kann positive wie auch negative Auswirkungen haben.

    Startet man z.B. vor der Verwendung von GeoMakeBoot ein Auto_Exec das irgend etwas im Kernel ändert, dann wird diese Änderung natürlich von GeoMakeBoot mitgespeichert. Auf der neuen Boot-Disk braucht man das Auto_Exec dann nicht mehr. Das funktioniert aber nicht grundsätzlich. Kommt darauf an, was und wo durch das Auto_Exec etwas verändert wurde.

    Ganz persönlich würde ich die gleiche Schrift wie bei OK/Cancel versuchen

    Was aber auch sehr schwierig werden kann :wink: .

    Wie z.B. soll ich das Wort "Standard" mit gleicher Schrift in ein 6 Cards breites Icon bekommen :wink: .


    Zum Schluß auch mal was ernsthaftes zu MP3 :wink: :

    Gibt es in MP3 eine einfache Möglichkeit, die genaue Version des vorliegenden MP3 zu prüfen? Ich meine jetzt nicht den "Standard-Test" auf "M" und "P". Der funktioniert so ja schon seit 1999/2000.

    Hintergrund: Im mir vorliegenden MegaAss-HB (ich weiß, ist eigentlich auch schon nicht mehr aktuell) steht auf Seite 476 (DBUSRFILES):

    "Ab Version V3.3r4 lässt sich DBUSRFILES mit DBSETDRVICON verknüpfen."

    Das ist ja auch gut so. Aber wenn ich das in einem Programm verwende, müßte ich ja eigentlich auf Vorliegen dieser Version (oder neuer) testen (können). Ich laufe ja sonst Gefahr, daß das Ganze beim Anwender (wenn er eine ältere Version benutzt) einfach abstürzt...

    Gruß

    Werner

  • Wie z.B. soll ich das Wort "Standard" mit gleicher Schrift in ein 6 Cards breites Icon bekommen :wink: .

    Vergleiche mal die Schrift beim Abbruch-Icon, ich meine die Schrift ist auch schmaler als Cancel oder OK, sieht aber ähnlich aus. Aber klar, irgendwann geht das nicht mehr.

    Gibt es in MP3 eine einfache Möglichkeit, die genaue Version des vorliegenden MP3 zu prüfen? Ich meine jetzt nicht den "Standard-Test" auf "M" und "P". Der funktioniert so ja schon seit 1999/2000.

    Nein, hab ja nicht daran gedacht das es in vier Jahren so viele Verschiedene Versionen gibt und das nach so langer Zeit immer noch Bugs gefunden und behoben werden. Bleibt nur der Hinweis in der Anleitung (bzw. in der Infobox) das man r4+ braucht. Wobei die Version schon sehr alt ist (Anfang 2019?) und die drei bis vier Anwender, die GEOS/MP3 noch nutzen, hier sicherlich mitlesen ;)

  • Hallo,

    so langsam bin ich am verzweifeln .......

    Also: Neuestes MP3-128 (23.11.), TD128 original vom 28.12.21 per Hand gepacht (PatchSystem kommt mit dem Datensatz 0 nicht klar, ist zu groß). Mit dem Patch habe ich die insgsamt 5 Stellen (sta $8871, 2x im Hauptmodul, 2x im VLIR-Modul 9 und 1x im VLIR-Modul 12) durch je 3x nop ersetzt. MP3 neu gebootet und die Farbeinstellungen aufgerufen. Ergebnis: die 3 benutzerdefinierten Icons sehen normal aus, die 2 System-Icons (OK und Abbruch) sind zu schmal. Langsam frage ich mich, ob das Schreiben auf $8871 doch noch irgendwie nötig ist ???

    Ich sende diesen TD128 hier mal mit ...

    Gruß

    Werner

  • so langsam bin ich am verzweifeln .......

    Du hättest nur meine obigen Ausführungen umsetzen müssen, denn mir war schon vor dem Download klar wo das Problem liegt, hab das ja selbst mehr als 1x getestet und umgesetzt. ;)

    Musste nur die Breite im Tabellenkopf mit DOUBLE_W anpassen und die X-Koordinate der 5 Icons von $90 auf $95 ändern. Kein Byte mehr, aber 5 Bytes eingespart.

    Ergebnis:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Die Einsparung von 5Bytes beruht auf dem Wegfall von lda #$80/sta $8871.

    Langsam frage ich mich, ob das Schreiben auf $8871 doch noch irgendwie nötig ist ???

    Nur wenn man rumpfuschen will... wie oben geschrieben:

    Also DOUBLE_W für die X-Koordinate der Box und dann die X-Position der Icons von $90 auf $95 ändern.

    Das hab ich im VICE-Monitor gepatcht:

    Bitte melde dich an, um diesen Anhang zu sehen.

    $01,$10,$b7 sind Schatten, yoben, yunten

    $28,$80 ist xlinks gedoppelt = $0050 und $07,$a1 ist xrechts gedoppelt +1 = $020f

    Über den Wert $80 von xlinks wird DB_DblBit gesetzt. Das hat so auch schon im Original GEOS 2.x funktioniert, ist also jetzt keine Eigenheit von MP3. Das mit dem OK-Icon passiert aber in GEOS 2.x noch immer wenn man von einer Originalen GEOS-Diskette bootet und eine Dialogbox ohne DOUBLE-W mit OK-Icon aufruft = Halbe Breite. Erst wenn man 1x eine Dialogbox mit Double-W (z.B. Öffnen in GeoWrite) aufruft, dann passt das OK-Icon ab dann immer.

    Das ich einem 128er Programmierer das DOUBLE_W erklären muss ;)

    Ist halt Teufelszeug! :LOL :Peace

    (...aber im Ernst... man sieht das ist beim 128er alles etwas umständlicher... und den Zusammenhang mit Highbyte xlinks hat man damals wohl nicht gekannt und daher den "Workaround" mit sta DB_DblBit eingebaut, man müsste mal einen TD3/4 raussuchen der noch mit 40Z funktioniert und sehen ob das damals schon so eingebaut war).

  • So weit ich das auf die Schnelle beurteilen kann, lassen sich damit jetzt wirklich alle Berkeley Softworks Originale installieren. Selbst die ganz alten Originale wie US Writers Workshop lassen sich installieren - jene haben noch einen komplett anderen Kopierschutz, nämlich auf Track 36. Allerdings nur mit einer 1541 - was nicht überrascht, weil sich jene Originale auch mit GEOS 2.0 nicht mit einer 1571 installieren lassen (außer man nimmt den 1541 Treiber mit der 1571, jener Trick klappt auch mit dem neuen MP3 Snapshot).

    Mit dem aktuellen Snapshot habe ich das ergänzend auf meiner Ultimate 64 den neusten Zugang ausprobiert: GeoCalc in der US-Version. Verhält sich so, dass man es mit dem 1571 Treiber nicht installieren kann, jedoch problemlos mit dem 1541 Treiber.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

  • Mir ist eben folgender Text im Handbuch aufgefallen:

    Zitat

    3.3 Dialogboxen unter GEOS128

    Wenn man die bis hierhin beschriebene Struktur ohne Änderung auf dem C128 im 80-Zeichen-Modus anwendet, so führt das zu einem nicht vorhersehbaren und deshalb unbrauchbaren Aussehen der Box, da einige Elemente doppelt so breit dargestellt werden, andere jedoch nicht.

    Um die Dialogbox also richtig zu definieren, bedient man sich der automatischen Verdopplungstechnik von GEOS128. Weitere Information dazu finden sich bei der Beschreibung zu NormalizeX in Teil B, Kapitel 4.25 ab Seite 242.

    Grundsätzlich setzt man bei den x-Koordinatenangaben im Kopf der Dialogboxtabelle das Bit 15, d.h. man ODERt die Koordinaten mit DOUBLE_W und ggf. ADD1_W.

    Laut dem Handbuch sollten Dialogboxen also Grundsätzlich mit DOUBLE_W definiert werden. Das würde ich auch befürworten, weil man dann die Probleme im ersten Absatz eben nicht hat. Wobei:

    Zitat

    da einige Elemente doppelt so breit dargestellt werden, andere jedoch nicht.

    sich genau auf den "Bug" mit den System-Icons bezieht, den ich jetzt in MP3 gefixed habe. Man kann sich jetzt noch darüber streiten ob System-Icons immer gedoppelt werden sollen, oder nur in Abhängigkeit von dem Highbyte der X-Koordinate. Letzteres ist die Aussage im letzten Absatz oben, das man immer DOUBLE_W verwenden muss.

    Damit wird auch klar warum sich MP3(1999) bis MP3.3r10(220821) so verhalten haben, das die Buttons OK/Abbruch immer "gedoppelt" angezeigt wurden, weil ja TopDesk das DB_DblBit manuell über DBUSRROUT auf $80 gesetzt hat. Lässt man den Befehl weg, dann kann es passieren das OK beim ersten Start mit halber Breite angezeigt wird und später irgendwann mit doppelter Breite... also führt das zu

    Zitat

    ...einem nicht vorhersehbaren und deshalb unbrauchbaren Aussehen der Box,...

    weil jede Standardbox das Double-Bit in der Breite der System-Icons "überschreibt". Danach ist es immer gesetzt und daher erscheint danach ein System-Icon immer in doppelter Breite. Und das ist genau das Verhalten was ich zu Beginn der Arbeiten an MP3 ab 2018 festgestellt hatte... ab&zu gab es "halbe" Icons...

    Im Handbuch von 1990 steht also schon alles was man wissen musste um die Farbwahlbox unter GEOS128 richtig zu programmieren...

    Wie gesagt, das waren damals andere Zeiten... ich hatte jetzt ein paar Tage Zeit die Verdopplungstechnik genauer zu studieren (musste mich ja erst in der 128er-Code einlesen) und hatte dann den Sourcecode immer vor Augen. Damals war das nicht ganz so einfach, da kann man sowas mal leicht übersehen.

  • Hallo Werner,

    sollte sich mit der neuen Testversion für DE, US und ES unter

    Bitte melde dich an, um diesen Link zu sehen.

    erledigt haben :wink:

    Pusti64

  • Laut dem Handbuch sollten Dialogboxen also Grundsätzlich mit DOUBLE_W definiert werden.

    Sorry, aber das steht da nicht! :wink: :wink: .

    Die Überschrift sagt "Dialogboxen unter GEOS 128". Der nachfolgende Text beschreibt aber ausschließlich eine benutzerdefinierte DB. Bei einer Standard-Box habe ich im Kopf der DB-Tabelle gar keine x-Koordinate, die ich verdoppeln könnte (DOUBLE_W).

    Ich glaube daher kommt die ganze Konfusion ... :wink: .

    Gruß

    Werner

  • Bei einer Standard-Box habe ich im Kopf der DB-Tabelle gar keine x-Koordinate, die ich verdoppeln könnte (DOUBLE_W).

    Wozu auch? GEOS128-V2.0US:

    Code
    (C:$c1d8) m ee85 ee8a
    >C:ee85  20 7f 40 80 ff 80
    
    -> $40,$80 = $0040 ! DOUBLE_W
    -> $ff,$80 = $00ff ! DOUBLE_W

    Das sind die Koordinaten die DoDlgBox für eine Standard-Dialogbox verwendet und DOUBLE_W ist da automatisch gesetzt... passt alles ins Schema... Interessanterweise aber ohne ADD1_W.

    P.S. Vielleicht nochmal zur Klarstellung: Die Breite von System-Icons wird über das DOUBLE-Bit aus der linken x-Koordinate der Box definiert. Wenn man kein DOUBLE_W benutzt braucht es die "Workarounds" mit DB_DblBit. Wer dem nicht glaubt darf gerne eine Benutzerdefinierte Dialogbox (mit Schatten) ohne DOUBLE_W aber mit "OK" direkt nach dem Start eines originalen GEOS128 V2 (nicht mit geoMakeBoot) testen... (Und ja, ich hab das eben verifiziert...)

  • Wozu auch? GEOS128-V2.0US:

    Ja genau. "Wozu auch?"

    Ich nenne das gerne "die Arroganz der Programmierer" und nehme mich selbst da keineswegs aus :wink: . Außerdem soll das keinesfalls negativ oder als Beleidigung verstanden werden.

    (wenn ich im folgenden von ich spreche, dann ist nicht grundsätzlich ich als Person sondern der allgemeine Anwender gemeint)

    Um die Geos-Programmierung (in diesem Fall Dialogboxen) einigermaßen zu verstehen, muß ich also als "normaler User" Geos dissassemblieren um hinter die Geheimnisse zu kommen. Das MegaAss-HB hilft mir da nicht wirklich weiter, da es unter der Überschrift "Dialogboxen unter GEOS 128" lediglich benutzerdefinierte DBs erklärt und das an der Stelle aber nicht mal verrät. Der Leser wird also dadurch mit teilweise falschen (widersprüchlichen) Informationen versorgt...

    Man muß das mal ohne das Wissen aus anderen Quellen (z.B. Geos disassemlieren) betrachten und "nur" das MegaAss-HB an dieser Stelle lesen. Da kann ganz schön Verwirrung aufkommen:

    Bei einer Standard-Box habe ich im Kopf der DB-Tabelle gar keine x-Koordinate, die ich verdoppeln könnte (DOUBLE_W).

    Das allein ist mein Punkt.

    Könnte es sein, daß diese "DB_DblBit"-Konstrukte damals genau aus diesem Grund entstanden sind? Scheint mir einigermaßen logisch ... :wink: .

    Du hattest hier erwähnt, daß Du danach in älteren TD-Versionen mal schauen willst. Ohne das Ergebniss vorwegnehmen zu wollen, ich glaube das ist mindestens seit TD 3.0 (TD 2 gab es nie, wohl um Verwechselungen mit "DESKTOP V2" (den normalen Geos V2-Desktop zu vermeiden (nur eine Vermutung))) drin.

    Falls es hilft: Den Quellcode von TD V1.3 gibt es hier: Bitte melde dich an, um diesen Link zu sehen.

    Ich weiß natürlich, daß Du an einem neuen MegaAss-HB arbeitest. Ich hoffe, daß das da ausführlicher erklärt wird ... :wink:

    Gruß

    Werner

  • Um die Geos-Programmierung (in diesem Fall Dialogboxen) einigermaßen zu verstehen, muß ich also als "normaler User" Geos dissassemblieren um hinter die Geheimnisse zu kommen.

    Nein, das hat bereits BSW verbockt, durch Fehler im Kernal.

    Damit andere mal verstehen worum es hier geht, hier mal ein paar Screenshots. Entstanden mit GEOS128V2.0US, gestartet von einer Originaldiskette (nicht mir MakeBoot erstellt). Gezeigt wird eine benutzerdefinierte Dialogbox mit alles System-Icons.

    1) x-Koordinate ohne DOUBLE_W, direkt nach dem Start von GEOS:

    Bitte melde dich an, um diesen Anhang zu sehen.

    2) Eine Standard-Dialogbox mit "OK" (nutzt intern DOUBLE_W)

    Bitte melde dich an, um diesen Anhang zu sehen.

    3) Die gleiche Box wie 1), nur hat der Kernal jetzt beim OK-Icon auf Grund der Standard-Dialogbox das DOUBLE-Bit in der Breite dauerhaft gesetzt. Ab jetzt ist das OK-Icon immer gedoppelt. Den Zustand wie unter 1) bekommt man nicht mehr hin, außer nach einem REBOOT.

    Bitte melde dich an, um diesen Anhang zu sehen.

    4) Eine Benutzerdefinierte Box mit DOUBLE_W:

    Bitte melde dich an, um diesen Anhang zu sehen.

    5) Nach einem Neustart von GEOS eine Standard-Dialogbox (nutzt intern DOUBLE_W)

    Bitte melde dich an, um diesen Anhang zu sehen.

    6) Und direkt danach eine Benutzerdefinierte Box mit oder ohne DOUBLE_W (macht ab hier keinen Unterschied mehr). Wenn man kein DOUBLE_W verwendet muss man allerdings die Koordinate von Hand anpassen. Alle Icons werden aber ab jetzt immer mit doppelter Breite ausgegeben.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Das ist das was im MA-Handbuch mit "nicht vorhersehbaren" und "unbrauchbaren" Aussehen der Box bezeichnet wird.

    Screenshots bei einer Dialogbox ohne Schatten schenke ich mir, da wird das ganze noch unvorhersehbarer, denn das hängt dann immer von der vorherigen Konstruktion der letzten Dialogbox ab.

    MegaPatch produziert jetzt nur noch einfache oder doppelte System-Icons, inkl. YES/NO. Damit wird es jetzt zumindest "einheitlich". Ob das jetzt gut oder schlecht ist wird sich zeigen müssen. Dazu müsste man mehr Dialogboxen im 80Z-Bildschirm testen. Vor allem Dialogboxen mit den obigen System-Icons.

    Auf Grund der bisherigen Recherchen zu dem Thema kann ich hier nur die Empfehlung ausgeben, immer DOUBLE_W zu verwenden, auch wenn der 40Z-Modus nicht unterstützt wird. Und am besten immer einen Schatten zeichnen lassen, damit der Kernal-Fehler umgangen wird (unter MP3 nicht mehr erforderlich).

    Könnte es sein, daß diese "DB_DblBit"-Konstrukte damals genau aus diesem Grund entstanden sind? Scheint mir einigermaßen logisch ... :wink: .

    Mit 100%iger Sicherheit. Hätte man damals gewusst das ein einfacher DOUBLE_W bei den X-Koordinaten der Box ausreicht, dann hätte man sich die Aktionen mit DB_DblBit schenken können. Ausnahme sind Dialogboxen ohne Schatten, da auf Grund eines Fehlers im Kernal DOUBLE_W nicht gesetzt wird, sondern von der letzten Dialogbox übernommen wird. Damit wird das ganze noch unvorhersehbarer...

    Ich weiß natürlich, daß Du an einem neuen MegaAss-HB arbeitest. Ich hoffe, daß das da ausführlicher erklärt wird ... :wink:

    Das ist auf der Seite 222 bereits ausführlich beschrieben, der Text nimmt zwischenzeitlich eine ganze Seite im Handbuch ein. Abgesehen davon hat die bisher veröffentlichte Version des Teil D am Anfang ein Fußnotenverzeichnis von 104 Einträgen, aktuell sind es jetzt schon 115. In jeder "Lesung" finden sich weitere falsche Aussagen oder Festlegungen oder Fehler.

    Allerdings überarbeite ich den Teil A-C lediglich für mich Privat, denn ich will mir da keine Copyright-Verletzungen einhandeln. Daher die Fußnoten im Teil D, die zumindest auf die Fehler hinweisen und meine Ausführungen hier oder im MA-Thread, damit die Fehler dokumentiert werden.

    Wenn wir schon beim Thema sind: dlgBoxRamBuf umfasst zwar 417 Bytes, die werden aber nicht alle genutzt. Ich hab im Handbuch dokumentiert was dort alles abgelegt wird und da ist noch einiges an Luft (vermutl. für Erweiterungen reserviert).

    Gibt es in MP3 eine einfache Möglichkeit, die genaue Version des vorliegenden MP3 zu prüfen? Ich meine jetzt nicht den "Standard-Test" auf "M" und "P". Der funktioniert so ja schon seit 1999/2000.

    Im GEOS-Kernal gibt es ab $c011 ein Byte, das hier kein Label hat und somit wohl im MP3 auch nicht verwendet wird. In GEOS64 1.2, 1.5, 2.0, 2.0r, GEOS128 2.0 hat es immer den Wert $00. Im Programmers Reference Guide findet sich dazu folgendes:

    Im Mist64-Sourcecode zu GEOS findet sich das hier:

    Code
    nationality:
    .ifdef wheels
        .word 1 ; GERMAN
    .else
        .word 0
    .endif

    Demnach wäre nationality ein Word, das Highbyte aber immer $00, auch unter Wheels64 V4.4 (getestet). Man müsste mal andere Sprachversionen von GEOS testen, da hab ich aber keine Startdisketten. Wenn man dem Reference-Guide folgt wäre das Byte aber "reserved for future use".

    Wenn es keine andere Belegung des Bytes gibt, könnte man hier eine System-Version ablegen. $00=alles vor dem nächsten r10-Snapshot, $3a=(3.)3r10, $3b=(3.)3r11... usw., und >$80 = GDOS64.

    Dann hätte man eine erweiterte Versionsangabe, den version ($c00f) hat ja auch unter MP3 immer den Wert $20, weil es Anwendungen gab die mit $30 der Meinung waren, das es kein GEOS 2.x (<>$20) sondern eher eine frühere GEOS Version ist.

  • Hallo,

    Im Mist64-Sourcecode zu GEOS findet sich das hier:

    Dieser "Interpretation" (von wohl 2 Privatpersonen) würde ich keine höhere Priorität einräumen. Ist halt nur eine Interpretation. Da ist das Programmers Reference Guide (auch wenn es wohl Geos 2.0 noch nicht kennt) deutlich aussagekräftiger. Selbst das Wheels-Programmier-Paket (Concept, Concept+) spricht in seinen Sym-Dateien nur von Werten von 0 bis 12 (wobei ich ehrlich nicht glaube, daß diese 13 Geos- bzw. Wheels-Versionen je wirklich alle existiert haben...):

    Warum also sollte nationality ($c010) ein Word sein? Ist irgendwie unlogisch. Meiner Meinung nach ist $c011 frei bzw. "Reserved for future use".

    Gruß

    Werner

  • Warum also sollte nationality ($c010) ein Word sein? Ist irgendwie unlogisch. Meiner Meinung nach ist $c011 frei bzw. "Reserved for future use".

    Sehe ich genauso, daher hab ich das aktuellen Code für MP3 bereits umgesetzt, auch in GDOS64. In Anlehnung an "version" hab ich das Label "sysVersion" getauft, auch weil $c012 = sysFlgCopy heißt:

    $00=alles vor dem nächsten r10-Snapshot, $3a=(3.)3r10, $3b=(3.)3r11... usw., und >$80 = GDOS64.

    Mir war die Meinung eines dritten wichtig, daher: Danke für Dein Feedback.

    Wenn es doch noch GEOS-Versionen gibt die hier andere Informationen ablegen, dann hab ich noch zwei weitere Kandidaten gefunden. Die Adressen haben aber bisher unterschiedliche Werte <>$00. Daher wären die eher Plan B.

  • nur noch zur Ergänzung :wink: :

    Im Programmers Reference Guide steht eindeutig, daß es ein Byte ist (in meinem PDF (auch auf der Wolke)) auf Seite 412:

    "nationality = $C010 ; nationality byte"

    Gruß

    Werner

  • GeoCalc in der US-Version. Verhält sich so, dass man es mit dem 1571 Treiber nicht installieren kann, jedoch problemlos mit dem 1541 Treiber.

    Sorry, ist in der Diskussion hier irgendwie untergegangen :wink: .

    Nun, das eigentliche Thema liegt ja schon einige Zeit zurück (März) :wink: . Aber ich frage mich, was und vor allem wie soll MP3 da was ändern (können). Die Installationsroutinen der originalen Software sind halt so gschrieben, daß sie nur auf einem 1541-Lfw. funktionieren. Punkt.

    Wenn, dann müßte man die Installationsroutinen ändern und nicht in MP3 irgendeinen Workaround einbauen. Ich habe das kürzlich hier schon so ähnlich geschrieben: MP3 ist keine Patch, das Probleme in anderer Software löst. Und da es mehrere Software gibt, auf die das zutrift, soll MP3 jetzt auch noch mehrere Workarounds enthalten?


    Das trifft auch auf deutsche Geos-Produkte zu, wenn mich meine Erinnerung nicht täuscht auch auf Geos-Software von Drittanbietern (GUC, ...). Das hat also mal gar nichts mit MP3 zu tun :wink: . Die Ersteller der Software haben das so eingerichtet, damit muß und kann man leben.

    Lösung: Für die Installation die 1571 als 1541 einrichten und gut ist. Das sollte doch kein Problem sein. Zumindest hier im Forum steht es in der Regel dabei, daß die Installation auf 1541 durchgeführt werden muß.

    Verschwörungstheorie ON :bgdev :

    Das haben die nur gemacht, um uns zu ärgern!

    Verschwörungstheorie OFF :bgdev

    :winke:

    Gruß

    Werner