Posts by darkvision

Quote from Spockie

Ist es theoretisch vorstellbar, das auch über einen Hot Corner zu starten? Also die Maus in ein zu definierendes Eck zu schieben und nach einer Sekunde oder so startet der Bildschirmschoner?

Funktioniert!

Hab die Funktion eben implementiert... müsste ich noch konfigurierbar machen, aktuell hab ich 3sek. eingestellt. Links oben startet der Bildschirmschoner, rechts oben die Hilfeseite (sofern installiert). Aktuell reicht ein 8x8-Pixel Bereich, der Mauszeiger muss also nicht ganz genau links/rechts oben sitzen.

Etwas Finetuning braucht das aber noch, und vor allem weitere Tests...

Es sind natürlich auch andere Funktionen denkbar, daher mal die Frage in die Runde was man sich denn so vorstellen kann.

Ich könnte dann in der Konfiguration ein paar Funktionen zur Auswahl anbieten, ich werde mich aber beschränken müssen denn alles anzubieten was GeoDesk kann, das wäre dann wohl zu viel des guten.

Mögliche Funktionen für die Hot Corners:

* Bildschirmschoner starten

* GeoPaint DiaShow (auf dem zuletzt aktiven Laufwerk) starten

* Arbeitsplatz öffnen

* Geöffnete Fenster temporär ausblenden

...

...

Andere Vorschläge?

Quote from max2022

Übrigens befindet sich auf den Originaldisketten zum Buch (im Gegensatz zur Beschreibung im Buch) nicht das Programm MegaAssembler.

Das wäre sehr verwunderlich, denn ich hab ja das Buch schon seit über 25Jahren und damals hab ich bestimmt nicht bei M&T angerufen und nach dem Programm gefragt. Und ich hab damals ja damit gearbeitet.

Du hast MegaAss vermutlich bei zimmers.net heruntergeladen, das dortige D64 hat kein MegaAss drauf und die 153 Blocks frei. Das ist aber keine Original-Diskette, da hat schon jemand drauf assembliert und mehrere Dateien gelöscht.

Bei 8BitSearch und in der Wolke hab ich D64 gefunden *mit* MegaAss. Und damit auch die V4.4 eben assembliert.

Ich wäre mit solchen Aussagen also sehr vorsichtig, und würde erstmal andere Quellen testen.

P.S. Wenn Du Dich mal länger mit Downloads für den C64 beschäftigst, dann wirst Du feststellen das es viel Müll im Internet gibt. Wenn man schon hier im Forum angemeldet ist würde ich die naheliegensten Quellen durchsuchen.

Der Form halber möchte ich anmerken das auch die Disketten in der Wolke nicht "Original" sind, auch hier hat schon jemand Dateien umsortiert und assembliert. Der Inhalt unterscheidet sich von meinen D64 die ich von den Buchdisketten gezogen hab. "Objectcode" findet sich z.B. bei mir nicht, aber MegaAssV2 ist enthalten.

Quote from max2022

Gibt es übrigens zur aktualisierten Mega-Assembler-Version irgendwo eine aktualisierte Anleitung.

Die Anleitung beschreibt nur die Veränderungen gegenüber V2, kann man hier nachlesen. Am besten über das "..."-Menü "OPEN_RAW" auswählen, dann lässt sich das besser lesen. Das handbuch ist da unerlässlich für die Programmierung.

Dort sind am Ende auch die ERRATA zum Handbuch von R.B. und R.B. enthalten.

Quote from max2022

Hallo, wo kann man die letzte lauffähige, binäre Version vom MegaAssembler herunterladen ?

=> Oder muss man den aktuellen Quelltext vom MegaAssembler selbst "kompilieren" ?!

Ich hoffe mal Du willst die Version dann nicht auf die "Diskette zum MegaAssembler"-Handbuch packen und das Paket dann bei ebay verticken

Quote from max2022

Danach verkaufe ich dann das Buch "GEOS Programmierung mit dem Mega Assembler" (inkl. Diskette) via eBay...

Die Version passt nämlich nicht mehr zur Beschreibung im Buch...

Damit hier nicht der Eindruck entsteht hier würde sich nichts mehr tun... gab nur ein paar Fehler in MegaPatch, MegaAssembler und im GEOS-HowTo zu korrigieren. Und nebenbei hat man ja auch noch einen Job... Die Hardware-Basteleien und -Tests hab ich ja ad acta gelegt. Hab hier nur noch einen Quad-Expander für den Expansion-Port und eine 1581-Replica zum löten/basteln, wer braucht das schon

GeoDesk wurde zum Teil modularisiert, d.h. einige Routinen sind jetzt "Optional". Ziel ist es den Start etwas zu beschleunigen. In der ersten Stufe werden TaskMan und Spooler beim Start übergangen wenn nicht konfiguriert.

In der zweiten Stufe werden GeoDesk-Funktionen ausgelagert, damit diese beim Start nicht geladen werden wenn nicht benötigt. Die Funktionen werden in den Menüs dann kursiv dargestellt.

Über das neue Programm GEODESK.mod können die Funktionen installiert werden:

Ein "*" vor der Funktion zeigt an das die Funktion in der GEODESK-Programmdatei (nicht im RAM) installiert ist. Bei den Texten Bedarf es noch etwas Finetuning...

Quote from wweicht

Man muss aber nicht unbedingt alles in den GeoDesk reinbauen, was geht

Hat ja nur drei Jahre gedauert... aber damit ist CVT in Zukunft optional. Manchmal höre ich auf die Anwender

Damit wird GeoDesk etwas kleiner... und ich konnte eine 1541-Disk mit drei verschiedenen Laufwerkstreibern und GeoDesk auf eine angepasste 1541-Disk packen

CVT ist trotzdem sinnvoll, gerade wenn das mit dem WiC64 noch weiter verbessert wird. Damit kann GeoDesk ohne extra Tools konvertierte GEOS-CVT-Dateien umwandeln.

In der dritten Stufe sollen die Startprogramme optimiert werden, Der Start von GDOS dauert aktuell ewig, weil beim Start auch die ganzen Konfigurationsmenüs geladen werden. Das zu ändern steht auf der ToDo-Liste.

Es gab beim Linux-Kernal mal die Diskussion ob Micro-Kernal oder Monolitischer Kernal. Ähnliches findet sich hier bei GeoDesk, also alles in GeoDesk einbauen oder extra Programme.

Die Modul-Variante ist in etwa der Mittelweg wie beim Linux-Kernal: Man kann eine kleine Boot-Version von GeoDesk verwenden und bei Bedarf extra Module entweder fest in die Boot-Version integrieren oder (in Planung) in den laufenden Kern von GeoDesk integrieren.

Es gibt also noch einiges zu tun... daher gibt es aktuell auch keine neuen Snapshots. Das neue System muss erst stabil funktionieren. Und ich hab da ein paar Ideen für neue Module

Leider macht einem da der Job manchmal einen Strich durch die Rechnung... also bitte etwas Geduld

Quote from wweicht

Quote from darkvision

MegaAssembler v4.4 als SourceCode released

habe nun doch einen Fehler entdeckt :

auf Seite 1 von "src.CallMegaAss3" steht unter "if newMegaAss = FALSE " direkt vor "endif":

...

h "Startet MegaAssembler V2 oder V-Link."

Das führt zu einem Fehler, da der alte MegaAss "h" nicht kennt. Man kann also das alte CallMegaAss nicht mit dem alten MegaAss erzeugen.

Gruß

Werner

Display More

Danke für den Hinweis... ich passe die Source-Disk entsprechend an. Zur Not hat man ja aber den neuen V4.4

Quote from wweicht

Jetzt bin ich zufrieden ...

Na Gott sei dank

Quote from darkvision

Man kann den Patch weglassen wenn ich das in GeoDesk so regele wie TopDesk, der einfach die Bildschirmfarbe löscht.

Ich hab in den letzten Jahren einfach zu viel Code neu geschrieben und teilweise gleich danach wieder vergessen, denn die Funktion ist in GeoDesk bereits enthalten.

In den GeoDesk-Optionen -> DeskTop -> Hilfsmittel -> [_] Hintergrund (verwenden): Wenn deaktiviert, dann wird der Bildschirm wie bei TopDesk gelöscht. Dann ist das mit der seltsamen Farbwahl bei calendar+blackjack kein Problem mehr.

Ich ziehe trotzdem die gepatchte Variante von Calendar mit Hintergrund vor, der Patch bleibt also

Quote from wweicht

1. Unterschiedliche Laufwerkstypen unter Geos 64 ohne RAM-Erweiterung (gilt nur für Geos 64!)

Hab ich ergänzt... GEOS128 hab ich am Rande auch erwähnt.

Quote from wweicht

Es kommt (auch hier im Forum) immer mal wieder vor, daß behauptet wird, es ginge ohne RAM-Erweiterung unterschiedliche Laufwerke ohne Konfigurieren auf jeder Disk zu benutzen. Das geht aber rein technisch nicht.

Genau... hat man CONFIGURE auf jeder Disk, dann geht es auch bei GEOS64. Ohne Speichererweiterung und ohne CONFIGURE gehen nur Laufwerke vom gleichen Typ.

Faktisch hat das vorgehen unter GEOS64 aber so viele Nachteile, das man das vorgehen so nicht empfehlen kann. Ich hab aber eben ohne Speichererweiterung problemlos Dateien von einer 1541 auf eine 1581 kopiert, von dort dann GeoWrite gestartet und nach der Rückkehr waren wieder 1541+1581 im DeskTop erkennbar.

Ist auf der B:1581 nur DESKTOP vorhanden, dann fehlt bei der Rückkehr zum DeskTop anschließend das Laufwerk A:1541 weil DESKTOP keinen Treiber dafür finden kann.

Technisch geht es also mit CONFIGURE auf jeder Disk, sinnvoll ist es auf Grund der Nachteile aber nicht. Und nicht alle Programme können damit umgehen. GeoWrite kann z.B. kein Laufwerk wechseln und blockiert die Funktion. Andere Programme gehen evtl. davon aus das man bei mehreren Laufwerken auch jederzeit das Laufwerk wechseln kann, was dann zu Problemen bis hin zum Absturz führt.

Wer eine Bestätigung dazu braucht, hier ist der Source code zu DESKTOP2 und die Stelle wo DESKTOP sich um die Laufwerkstreiber kümmert. Es wird eben CONFIGURE gesucht und der Treiber manuell geladen (die Byte-Tabelle am Ende ist übersetzt die GEOS-Klasse "CONFIGURE").

Ich gebe Dir daher recht wenn es darum geht das man bei verschiedenen Laufwerken unter GEOS64 eine Speichererweiterung nutzen sollte, sonst hat man ggf. nur Probleme.

Quote from wweicht

Hier wird Konfigurieren gezeigt ohne erkannte RAM-Erweiterung. Das Bild kann ja bleiben , im Text dazu sollte aber erwähnt werden, daß da je nach Konfigurieren-Version auch "Keine Ram-Erweiterung" oder "0 kB" stehen kann. Das "NONE" gibt es nur im US-Geos und auch da nicht in jeder Version soweit ich das sehe...

Ebenfalls korrigiert, Danke.

Quote from Juergen Johannes

MegaPatch V3 vom 23.05.2022 64+128, jeweils auf CMD RL 1581er Partition installiert.

Zur Erklärung:

Der behobene Fehler tritt nur bei C64+RAMLink (ohne SuperCPU) auf. Da ich unter VICE die RAMLink am 128er nicht emulieren kann, kann ich nicht sagen ob das Problem auch dort existiert hat. Der Fehler lag aber im Laufwerkstreiber und wurde dort für C64+C128 behoben.

Für Ultimate64-Anwender oder nicht-Besitzer einer RAMLink ist das Update nicht notwendig.

Das Problem war das gleiche wie damals beim TaskSwitcher zwischen geoWrite-Dokumenten. Hier stürzte geoWrite jetzt ab nachdem man das Dokument beendet hat und auf "Öffnen" oder "Erstellen" klickt... aber nur wenn der Cursor im vorherigen Dokument an einer bestimmten Stelle stand. Nur mit einer RAMLink (und ich meine nur ohne SuperCPU). Evtl. ist das deshalb bisher nicht aufgefallen.

MegaAssembler v4.4 als SourceCode released ( Download hier, wie immer zum selber assemblieren ).

Behobene Fehler:

* Der Linker berechnet eine falsche Dateigröße wenn eine nicht-GEOS-Datei in die VLIR-Datei eingebunden werden soll. Es wird dabei 1 Block für den Infoblock abgezogen, den es bei der non-GEOS-Datei nicht gibt.

* Der obige Fehler tritt nur auf wenn die assemblierte Teildatei den GEOS-Datei-Typ 0 = "Nicht-GEOS" bekommt. Das kann bis V4.3 passieren wenn für den "f"-Opcode (GEOS-Dateityp festlegen) ein Symbol verwendet wird, welches im Source-Code aber nicht definiert ist. Ergebnis ist ein "f"=0 = Nicht-GEOS.

* "Paramter speichern" im Linker kehrt nicht ins Menü zurück und es sieht so aus als passiert nichts. Der Linker kehrt jetzt wie im Assembler-Teil nach dem speichern der Parameter ins Hauptmenü zurück.

Ergänzungen:

* Im Parameter-Menü des Assembler gibt es eine neue Option "Pseudo-Opcodes testen". Aktiviert man die Option, dann wird beim assemblieren der Operand der Pseudo-Opcodes getestet und ggf. ein Fehler ausgegeben. Da die Funktion neu ist und noch ein paar mehr Tests braucht ist die Option standardmäßig deaktiviert, ist aber zu empfehlen: Bei Assembler-Befehlen wird bei fehlenden Symbol-Definitionen ja auch ein Fehler ausgegeben.

Im Teil#4 (src.MegaAss4) mussten ein paar Symbol-Namen gekürzt werden, da sich sonst die Version mit MegaAssembler V2 nicht übersetzen lässt... der Commit ist also etwas umfangreicher als eigentlich notwendig.

Quote from wweicht

Was hat Y2k mit 4 Lfw. zu tun? .

Nichts... Copy&Paste... hast Du aber sicherlich selbst bemerkt... Kann bei so viel Text und Tests schon mal passieren. Ist im aktuellen PDF korrigiert. Im Gegenzug hab ich endlich das patches_mp3_64d.7z-Archiv aktualisiert...

Thema erledigt.

Ich hab jetzt im HowTo eine Liste der 23 CONFIGURE-Versionen aufgeführt die ich gefunden habe, inkl. der 2.1.1. Wobei es auch ein 2.1+ gibt wo die GeoRAM ebenfalls schon mit 4Mb erkannt wird. Die max. unterstützte DACC-Größe hab ich bei jeder Version mit aufgeführt.

Und ja, 4Mb-Versionen bringen kaum Mehrwert, außer das RAM-Process ein paar mehr freie Blocks findet. Seltsamerweise aber nur etwas mehr, ca. 2000 Blocks. Keine Ahnung was man mit so viel freiem Speicher und dem Programm anfängt.

Quote from wweicht

Ich weiß nicht, ob es so gut ist, da auf externe Links zu setzen. Solche Links können schnell mal ungültig werden. Willst Du die Anleitung "ständig" anpassen? .

Hab ich nicht vor. Wichtig sind ja eher die zu erledigenden Schritte bis zum Ziel, woher die Disketten kommen kann mir egal sein. Das deutsche GEOS ist ja auch nicht verlinkt. Da die Anleitung in Deutsch ist werden die meisten sich das Material aus der Wolke laden... Die Links sollen nur eine erste Anlaufstelle sein, zur Not weiß man wonach man suchen muss.

Quote from wweicht

Patch System

...

Ein besserer externer Link ist vielleicht der:

http://www.zimmers.net/anonftp…k/Programme/gt115a.d64.gz

Da ist das zumindest erfüllt.

Kann ich anpassen, Danke.

Quote from wweicht

Wenn Calender für das Jahr 2000 gepatcht ist, stimmt der Kalender! Bei den Bildern von darkvision ist er noch nicht für das Jahr 2000 gepatcht.

Genau... Anfangs war der Y2K-Patch ja nicht enthalten. Soweit ich das sehen konnte könnte man den Patch auch so ändern, das Calendar das ":millenium"-Byte ($9FAD) auswertet und verwendet, dann läuft Calendar (beinahe) ewig

Werd ich aber nicht mehr erleben, und die meisten C64 bestimmt auch nicht. Sind ja noch ~60Jahre bis der jetzige Y2K-Patch nicht mehr funktioniert. Von daher belassen wir es bei der aktuellen Lösung, der Patch-Code ist ja gut dokumentiert damit künftige IT-Archäologen wissen was Sie ändern müssen

Ich hab jetzt auch mal alle CONFIGURE-Versionen rausgesucht... für 64/128, reu/georam/ramlink, 2.0/2.1/2.1.1 ... deutsch/english... sind bis jetzt 16 Versionen. Werde da zumindest eine Auflistung ergänzen welche Version wofür geeignet ist.

Zumindest die 2.1.1 scheint auch mit InstallDriveD zu funktionieren. Die letzte Version davon war 1.2? Ich hab das Programm nur auf TopDesk-Disketten gefunden (eine V3.2/DE findet sich bei zimmers.net). Evtl. ergänze ich noch einen Abschnitt dazu, falls man mit DualTop mit vier Laufwerken unter GEOS2 nutzen will. Oder wer will mit TopDesk3.x.

Und ja, konnte bei 2.1.1 die von wweicht aufgezeigten Fehler nachstellen. Ich hab es aber geschafft A-C mit RAM1581 zu konfigurieren. Ich konnte das Programm danach aber nicht mehr beenden. Also irgendwie ist das bei MP3 einfacher

Quote from darkvision

GEOS-Install-HowTo ist aktualisiert, die Patches für Calculator (1.0/1.2de/us)

Quatsch... ich meinte natürlich Calendar... nicht Calculator...

Quote from wweicht

Ja schon, aber es gibt z.B. auch geoZIP für MP3. Da bekommt man von den .CVTs nichts mit, da das Programm das automatisch macht, beim Packen und Entpacken.

Das Hauptproblem bleibt aber selbst mit SuperCPU gleich: Man muss das ZIP auf den C64 oder zumindest auf eine DOS-Diskette bekommen. OK, 3,5" sind heute wieder der "Standard" ( siehe Mega65 ) und mit dem WiC64 kann man von HTTP auch direkt auf den C64 downloaden. Als Befehlszeilen-User kann man noch VICE verwenden. Das kann aber nicht jeder (letzteres ist aber im HowTo beschrieben...)

Also hat man diese ZIPs oder CVT und muss die erstmal auf ein von GEOS lesbares Dateisystem übertragen, und daher ist D64/D81 der deutlich einfachere Weg. geoZIP/MP3 selbst liegt ja als CVT/7Zip in der Wolke... das kann geoZIP bestimmt nicht entpacken...

GEOS-Install-HowTo ist aktualisiert, die Patches für Calculator (1.0/1.2de/us) und Blackjack (1.0/1.1/1.2-de/us) hab ich auf meiner geos-patchfiles-disk (D64 / TXT) auch online gestellt (mit dem RunTime-Patch), braucht man aber nur wenn man GeoDesk64 nutzt und daher werde ich mir in GeoDesk jetzt eine Option einbauen, mit der man das so einstellen kann wie in TopDesk oder es wird zuvor der Standard-GEOS-Hintergrund aktiviert. Dann ist der Patch auch nicht mehr nötig. Aber wo ich den Patch habe lösche ich den natürlich nicht, hat ja irgendwie trotzdem Spaß gemacht damit zu experimentieren.

Quote from wweicht

Ist blanke Theorie, was ich jetzt schreibe:

Muß nicht sein. Man ändert einfach: bei "Neue Datensatzlänge = 0" so, daß nicht mehr gespeichert wird ....

Ja, aber das setzt dann für Calendar die neue PATCHSYSTEM-Version voraus. Und bis die Fertig ist...

Gut, ich muss meine Patches noch weiter testen, hat also noch etwas Zeit.

Ich passe meine Texte noch so an das man einfach eine Seite im Quelltext löscht um den Runtime-Patch zu entfernen, dann könnte man auch die neue PATCHSYSTEM-Version verwenden.

Quote from wweicht

Und die 80 Zeichen-Version gibt es offiziell ja garnicht (Patch eines Anwenders ). Die würde ich erstmal außen vor lassen ....

Ansichtssache... zumindest ist die Version im Umlauf und in der Wolke.

Vorweg Danke für die Infos zu den Patchtexten.

Quote from wweicht

Und nochmal wichtig: Alle Patches die vor "4 Laufwerke für Geos" entstanden, sind in den "4 Lfw. für Geos"-Paches enthalten. Ältere Patches braucht man also nicht mehr.

Quote from wweicht

Warum ich jetzt ausgerechnet beim 64er geoPaint dieses Änderung nicht mit aufgenommen habe (im 128 geoPaint-Patch ist sie drin) kann ich nicht mehr sagen. Dann brauchen wir wohl noch das Publish-Patch aus SH 59...

Ich hab heute morgen write, paint und publish 64/128 mit den drei extra Patches und dann 4LWK, MP3 und Y2k-Patches versehen. Wenn die extra Patches als erstes angewendet werden dann dürfte das ja kein Fehler sein, stellt aber sicher das alles enthalten ist. Sonst müsste man jetzt den 64er-Paint-Patch eine Beschreibung beilegen das hier gPp2.01 benötigt wird und beim 128er nicht.

Für die drei Patches hab ich auch eine öffentliche Download-Quelle gefunden, die kann also jeder auch auf ein pures GEOS 2.x ohne extra Patches anwenden.

Quote from wweicht

Keine Ahnung, ob das wirklich eine gute Idee ist.

1. es gibt nur wenige Programme, die das Problem haben

2. bisher ist es bei etlichen Patches nur bei "Calendar" aufgetreten

Der RunTime-Patch wird nur 1x direkt beim ersten Start ausgeführt und passt die Dateigröße an, danach verbleibt der Code am Ende des Programms, wird aber nicht mehr ausgeführt. Die Startadresse im Infoblock kann man nämlich ändern und beim ersten Start wird der Runtime-Patch angesprungen. Der ändert dann die Endadresse+Startadresse und speichert den Infoblock.

Es findet danach auch keine Prüfung mehr statt, der Code hängt dann einfach nur noch hinten dran. Der Rest des Programms ist bis auf die eigentlichen Patches unverändert.

Da der Speicher in dem Bereich sowieso uninitialisiert ist gibt es hier keine Nachteile außer die 50Byte größere Dateigröße.

Vertretbar wenn man so in Zukunft auch weitere Korrekturen einpatchen kann ohne eine Patch-Anwendung zu schreiben.

Quote from wweicht

3. eigentlich müßte man mal sehen, ob man PatchSystem anpassen kann...

Das wäre sicherlich die beste Lösung, dann setzen Patches aber eine bestimmte PATCHSYSTEM-Version voraus und dann haben wir neben der 64er/128-Version noch eine spezielle 128er-Version (bei den MP3DE64-Patches enthalten) und eine aktualisierte Version. Das macht es dann doch eher undurchsichtiger.

Und wenn es dann nur wegen Calendar 1.2 ist (1.0 geht auch ohne diesen RunTime-Patch), dann würde ich den Patchtext mit Runtime-Patch einer zusätzlichen PATCH-SYSTEM-Version vorziehen.

Wobei ich es schon als Fehler sehe das die Datensatzlänge #0 korrigiert wird, auch wenn nur der Infoblock als Datensatz #254 gepatcht wird.

Quote from wweicht

Oh man, da wird mir ja übel, wenn man das Ganze verstehen oder überblicken will .

Aber eines ist mir doch aufgefallen:

gPp2.01

wird erwähnt (obwohl in einem anderen Patch von mir bereits enthalten) . Es fehlen gPup1.01 und gWp2.12. Alle 3 patchen ein paar Kleinigkeiten im Menü und stammen (ohne irgendeine Anleitung) aus 64er Sonderheft 59. Die Anleitung hat M&T dann irgendwann später in einem "normalen" 64er Heft nachgereicht. Keine Ahnung, welches das war....

Aber wie gesagt: Alle 3 sind eigentlich obsolet, da definitiv in einem der Paint-, Publish-, Write-Patches von mir bzw. bei Write von F. Rehwagen enthalten.

Ich bin auch nicht sicher, ob die wie in der Anleitung beschrieben für DE- und US-Geos sind. Die 3 Patches stammen definitiv aus Deutschland von J.-M. Groß.

Display More

Jetzt wird mir übel... Wenn der gPp2.01 Patch in einem Deiner Patches enthalten ist, warum gibt es dann keine Fehlermeldung? Keine Check-/Prüfsummen? Ist da noch mehr obsolete? Der Patch ist ja nach wie vor im 4LWK-Patchset enthalten das man für MP3 benötigt. Dann soll man den nicht anwenden ?

Ich hab heute wegen eines neuen Bugs in MP3/GDOS+RAMLink-ohneSuperCPU geoWrite 2.1 getestet... der Bug bringt geoWrite ganz schnell zum Absturz. Egal... lässt sich ggf. lösen.

Da war in meinem alten geoWrite ein Patch von JMG auf 2.11 enthalten, keine Ahnung wo der herkam. Und jetzt kommt da noch ein 2.12 dazu? Man, wie soll das ein Neu-Anwender finden?

Danke für die Hinweise... muss ich mir mal zusammensuchen... aber es gibt auch gutes zu berichten (hoffentlich):

Ich hab die Patches für die Fensterfarbe+Y2k für Calendar zusammengefasst... ohne das die Endadresse geändert wird. OK, die Adresse wird geändert, aber ich hab das Patch-System überlistet (jaja... es macht aber das Programm auf Disk ca. 50Byte größer weil RunTime-Patch, aber besser als die 30Blocks mit der neuen Größe des Datensatzes).

Jetzt muss ich erstmal die bisher unbekannten Patches suchen... dann passe ich die Anleitung an und uploade ggf. meine Patches für Calendar+Blackjack.

Quote from wweicht

Aahhh, ja, ich erinnere mich dunkel. Da war doch was ....

Aus der Erinnerung:

Calendar war/ist ein Hilfsmittel und nutzt eine Trick, um den Geos-Bildschirm beim Starten des DAs zu sichern. Es wurde einfach die Endadresse so hoch gesetzt, daß der Bildschirm mit gesichert wurde. Das machte es leider unmöglich, eine Patch-Text zu schreiben, da Patch-System die Endadresse immer geändert hat. Deshalb habe ich das als Programm veröffentlichen müssen.

Das Problem kam so aber recht selten vor, Calendar war also eher die Ausnahme ....

Und über genau diesen "Fehler" bin ich jetzt gestolpert... Meine Version funktionierte unter GeoDesk, aber bei TopDesk gab es dann einen Absturz... und es war die Endadresse.

Das DA hat eine größere Endadresse als Daten im Programm vorhanden sind. Wie Du sagst wird damit Speicher reserviert. Und was macht das PATCH-SYSTEM? Trotz #0 für keine neue Dateilänge ändert es die Endadresse im Infoblock. Das ist für mich nicht logisch. Es ist sogar noch schlimmer, denn ein Patch der nur den Infoblock ändert, verändert die Datensatzlänge des Programms trotzdem. Sonst könnte ein zweiter Patch die Dateilänge wieder korrigieren.

Man kann es zwar mit dem Patch-System selbst lösen (Neue Datensatzlänge setzen), dann wird die Calendar-Datei aber 30 Blocks größer

Quote from wweicht

Das Jahr 2000 - Patch für den Kalender gibt es ziemlich sicher , so daß da 2022 stehen könnte... .

Ich hab Calendar auch mit und ohne die Y2K-Patches getestet, um zu sehen ob die Änderungen funktionieren. Man soll die Patches ja ausgiebig *VORHER* testen

Und Calendar ist doch eine Patch-Anwendung, kein Patch-Text. Ich müsste also jetzt den Source-Code analysieren was da geändert wird um es zu ergänzen. Ich glaub ich würde das schon hinbekommen, wenn ich denn wollte.

Quote from wweicht

Also: man benutzt den vorhanden Patch-Text und ergänzt spätere Änderungen einfach in diesen Patch (ein Patchtext kann ja 60 Seiten haben , da st Platz ... ). Dann den Dateinamen (zeigt oft die Version an) etwas verändern und gut ist.

Deshalb haben die Patch-Texte ja Versionsnummern im Dateinamen (2.0_1, 2.0_2 usw...). Aus meiner Sicht etwas unübersichtlich, und gerade bei TextPrint war das mit der Programm-Version im Dateinamen noch unübersichtlicher.

Quote from wweicht

Über Checksummenprüfung (Checksummer) kann man auch verhindern, daß ein Programm, wo ein Bereich anders ist (falsche Checksumme) nicht gepatcht wird.

Sind für alle Bereiche die ich ändere enthalten. Sogar für den Infoblock.

Quote from wweicht

PatchSystem ist eigentlich recht einfach und simpel. Man muß sich nur drauf einlassen . Bei Fragen dazu, kein Problem. Einfach fragen .

Es ist einfach, es ist simpel. Manche Dinge sind aber in der Anleitung gar nicht beschrieben oder ich musste mir die Informationen aus dem Kontext heraus selbst erschließen. Aber bevor ich da die Anleitung anpasse ergänze ich lieber ein paar Kommentare in meinen Texten. Die Anleitung selbst verweißt ja darauf das man aus anderen Patch-Texten lernen soll

Quote from wweicht

Jetzt haben wir mit den Y2K-Patches und Deinen schon wieder 2 Patches für ein und das selbe Programm ....

Man kann den Patch weglassen wenn ich das in GeoDesk so regele wie TopDesk, der einfach die Bildschirmfarbe löscht. Daher ist zumindest der Patch OPTIONAL, der Y2K-Patch aber empfohlen oder erforderlich.

Für andere DAs (Calc64 help, Publish help... kennst Du sicherlich...) müsste ich jetzt auch einen Patch schreiben, weil die komplett die Farbe vom Bildschirm löschen anstatt nur im Bereich der Anwendung selbst (wie Calendar und Blackjack das z.B. machen). Würde schicker aussehen, für MP3 gibt es da ja extra Routinen für. Aber lohnt den Aufwand wohl nicht denn ich müsste mich wieder mit MP128 beschäftigen

Ich sammle mal ein paar DAs und dann überlege ich mir wie ich die Optionen in GeoDesk einbaue, damit Farbe+Hintergrund für DAs vom DeskTop aus ordentlich rüberkommen. Der Calendar+Blackjack-Patch waren eher für das verstehen des PatchSystems gedacht, das ich künftig nicht mehr benötigen werde