GDOS64

Quote from darkvision

Wenn es da eine Erweiterung gibt, dann nur für Native, und das wäre dann eher eine "GEOS-format V1.0(extended)". Ideen hab ich dazu, könnte sogar jeder Native-Desktop validieren. Aber der Platz in den Treibern ist so knapp, evtl. scheitert es dann nicht an der Idee, sondern an der Umsetzung. Wenn es nur bei einem Native-Treiber nicht geht, dann hat sich das erledigt... und ich glaube das wird eher der Knackpunkt sein.

Ich hab meine Idee mal mit em RAMNative-Treiber umgesetzt und getestet... Funktioniert und scheint weder mit GeoDOS64, dualTop, TopDesk ein Problem zu haben. Validate geht (ausser bei dualTop, kann kein Native), auch öffnen von Dokumenten mit der App im erweiterten Border.

Der Screenshot zeigt ein Verzeichnis "TEST1" das nur zwei Dokumente enthält (die ersten beiden Dateien). Dazu werden Dateien aus einem definierten Verzeichnis zusätzlich angezeigt, hier hatte ich das UV "Shared" als erweiterten BorderBlock definiert. In dem UV "Shared" hab ich 11 Dateien abgelegt. Die werden jetzt in jedem Unterverzeichnis mit angezeigt.

Die Idee war einfach eine GEOS-Diskette zu erstellen und in den ungenutzten Bytes des BAM-Blocks 1/1 eine zusätzliche Kennung für eine GEOS-Diskette V2 zu ergänzen. Hier wird dann auch der Tr/Se für das "Shared"-Directory abgelegt. Der BAM-Block 1/1 beinhaltet nur ein paar wenige Verzeichnisbytes und den Disknamen mit GEOS-Kennung. Alleine das hinzufügen der GEOS-Kennung nutzt schon Bytes die im CMD-Handbuch als "Reserved" bezeichnet werden. Das ergänzen einer weiteren GEOS-Format-Kennung V2 richtet hier also keinen größeren Schaden an. Wenn so eine Diskette in Umlauf kommt dürfte kaum jemand die Format-Kennung "V2" bemerken und da die Bytes in der Regel "Reserviert" sind dürften andere Anwendungen auch kein Problem damit haben.

GeoDesk hätte in den Laufwerkseigenschaften dann eine Option "V2-Disk erzeugen" wo man dann ein "Shared"-Verzeichnis auswählt. D.h. das Verzeichnis wäre frei wählbar.

Kopiert man alle Dateien rekursiv auf eine andere Diskette dann kopiert GeoDesk nur das Verzeichnis, nicht die Dateien aus einem Borderblock. Topdesk kopiert sowieso nur das Verzeichnis ohne Dateien. dualTop/GeoDOS64 können keine Verzeichnisse kopieren.

Der Laufwerkstreiber ändert beim laden der BAM den Zeiger auf den Borderblock und eine Anwendung die über GetNxtDirEntry Dateien einließt findet dann auch die Dateien im Shared-Verzeichnis.

Beim Schreiben der BAM (z.B. Validate) wird der Zeiger auf das Shared-Verzeichnis wieder durch den Borderblock ersetzt. Daher funktioniert Validate, da die Dateien im Shared-Verzeichnis nicht doppelt ausgewertet werden.

Und jetzt kommt der Haken: Der dafür notwendige Speicherplatz erfordert ca. 35Bytes im Treiber... beim FDNative sind noch 17 frei, bei RLNative noch 8Bytes... d.h. es ist nicht bei allen Native-Treibern genügend Speicher frei um das umzusetzen.

Zu den 35Bytes kämen noch ein paar Bytes dazu um die Dateien aus dem Shared-Verzeichnis nicht im ROOT anzuzeigen. Die 8Bytes des RL-Treibers reichen daher in gar keinem Fall... selbst wenn ich noch ein, zwei Bytes rausquetschen könnte.

Daher bleibt es wohl bei den 8 Dateien aus dem Borderblock. Technisch wäre es zwar möglich (fast) unbegrenzt viele Dateien in jedem Verzeichnis zusätzlich einzublenden, aber wenn es nicht bei allen Native-Treibern geht, dann ist es besser auf dieses Feature zu verzichten. Sonst sind die Treiber untereinander nicht kompatibel und es würde nur Rückfragen handeln warum es bei RAMNative geht, nicht aber bei RLNative.

Ich hake das ganze jetzt unter "Proof-of-Concept" ab... 8 Dateien im Borderblock. Mehr geht nur wenn man den Borderblock erweitert. Das wäre Optional noch denkbar, mit einem entsprechenden Hinweis das diese Disks nicht mehr 100% GEOS kompatibel sind. Da dies wie gesagt nur Native betreffen würde wäre das Risiko das solche Disketten in Umlauf kommen eher gering...

Quote from wweicht

bei darkvision ( https://bitbucket.org/mkgit64/area6510/downloads/ ) gibt es einen neuen GDOS-Snapshot zum Download.

Stimmt... nach fast einem Monat hab ich doch ein paar Fehler gefunden (Uhrzeit setzen beim TC64, Fehlermeldung bei ungültiger Laufwerkskonfiguration beim booten, setzen von Größe/Zeit beim Spooler...).

Ich hab auch ein Update von GEOS 2.x durchgeführt, mit nur 1x1581 und RAM1581 (unter VICE). Ging ebenfalls problemlos. Was aber nicht heißt das es keine Fehler mehr gibt, die fallen einem nur nicht mehr so schnell auf

Quote from Juergen Johannes

Nur die Neuerung im Hilfesystem (Änderung im jeweiligen Update) hatte ich mir angeschaut. Das finde ich schon mal Super. Tolle Idee, so hat man eine Änderungsübersicht bei jeder neuen Version.

Ist erstmal nur ein Versuch... aber evtl. hilft mir das beim Handbuch... die WhatsNew Texte kann ich dafür dann ggf. recyclen. Wollte ich schon länger mal testen und war gut so, denn dabei sind mir ein paar Fehler im Hilfesystem aufgefallen die ich so beseitigen konnte. Und mit der Dateiauswahl ist es jetzt einfacher andere Texte direkt zu öffnen.

Den automatischen Verzeichnisindex musste ich aber auf 64 Dateien begrenzen (Dateiauswahl, Laufwerk wählen und dann "OK" klicken...). Mehr wäre zwar möglich, aber zusammen mit dem Infotext aus dem GEOS-Infoblock könnte das den Speicher überlaufen lassen. Also entweder aufwändig testen ob der Speicher voll ist, oder die Dateianzahl begrenzen. Letzteres war einfacher...

Quote from uwe1972

PS. Bekommst bei Gelegenheit eine Disk mit symbolen und der Abgespeicherten Datei...............

(Bin aber noch nicht ganz fertig geworden)

Wenn ich andere Icons wollte könnte ich die ja direkt in GDOS einbinden Ich hab weder Bedarf an anderen Icons noch an den Trenndateien, ich nutze immer den Textmodus.

Der IconManager war nur die konsequente Weiterführung der Anpassungsmöglichkeiten von GeoDesk, nachdem man schon alle Farben anpassen kann. Die Fensterdekorationen bleiben aber fix, die 8x8 Pixel-Kästchen zum ändern der Größe von Fenstern usw. bieten wenig Raum für Anpassungen, das lohnt den Mehraufwand dann nicht.

Der IconManager kann zwar dazu genutzt werden um Icons zu zeichnen, ist aber eher rudimentär. Mit dem Programm IconEditor geht das deutlich komfortabler. Dort dann als Datei-Icon speichern und in GeoDesk dann einlesen. Lediglich Farbe muss man dann nacharbeiten.

Ich hab dafür noch ein paar Ideen/Erweiterungen für den IconManager auf der Liste, aber vom Grundsatz her ist der Fertig. Wer eigene Icons entworfen hat kann die gerne hier anhängen. Auch Fehler sollte man eher hier posten, nicht per Konversation. Ich melde mich hier nur noch selten an und lese Konversationen daher eher nicht.

Beim testen hab ich auch den IconPainter V3 von F.K./C.C. und M&T getestet, der scheint aber ein Problem zu haben. Auch unter MP3... unter GEOS 2.x funktioniert der. Werde ich mir bei Gelegenheit mal anschauen.

P.S. Fehler gefunden. Ist ein Problem im Maustreiber und ist so schon in MP3.0 von 1999 enthalten. Werde ich in GDOS anpassen und bei Gelegenheit in MP3.3 übernehmen. Bei Bedarf kann ich die korrigierten Maustreiber dann auch hier anhängen.

Anbei ein D64 mit einem aktualisierten Maustreiber, der das Problem mit IconPainter (Dauermalfunktion) behebt. Einfach auf die Bootdisk kopieren (wer will kann den vorher testen Arbeitsplatz -> Eingabegerät wählen). Beim nächsten Update kommt der Treiber aber automatisch mit.

Quote from Juergen Johannes

Kleine Anmerkung:

Der gd64v00fix (SuperMouse64) Treiber ist hier noch nicht vorhanden.

Bitte sicherstellen das der neueste Snapshot verwendet wurde. Der Code ist schon seit dem Fix im SourceCode enthalten. Der P/S-Editor aus dem D64 funktioniert hier auch nach einer kompletten Neu-Installation. Auszug aus dem SourceCode:

Bei einer Neuinstallation auch die Frage ob der neue Maustreiber installiert werden soll unbedingt bestätigen. Sonst wird ggf. ein alter Treiber beibehalten und unter GDOS64 weiterverwendet...

Wer sichergehen will das er das neueste Update installiert hat: Nach der (vollständigen) Installation in GeoDesk <F1> drücken... -> Was ist neu? -> Hier sollte als Datum "14-OKT-2022" angezeigt werden. Wer die Hilfe nicht installiert hat: Dateidatum der Systemdateien testen...

Der Maustreiber wurde in der Hilfe/WhatsNew nicht aufgeführt weil der Fehler ja über den Fix bereits korrigiert wurde.

Ich hab hier noch ein paar Verbesserungen in der Warteschleife... aktuell sitze ich aber an der Überarbeitung des MegaAssembler-Handbuches. Das macht aktuell mehr Spaß und daher geht es hier nur langsam voran. Das GDOS64-Update ist aber ein direktes Ergebnis der Handbuch-Überarbeitung, denn mich hat es schon länger gestört das Icons in den Register-Menüs keine Rückmeldung geben ob angeklickt oder nicht. Das hat mich schon an MP3 gestört und bei Gelegenheit werde ich einen Backport für MP3 umsetzen, wenn möglich. Unter MP128 sind da noch knapp 128Bytes frei, das könnte reichen. Es ist ja nur eine zusätzliche Sleep-Schleife und ein paar Invert-Befehle die man einbauen muss.

Auch hier gibt es einen neuen Snapshot, der allerdings nur kleinere Änderungen bringt:

* Für Programmierer das sysVersion-Byte in $c011

* Dateiauswahlbox verwendet jetzt die korrekte Farbe für System-Icons

* In GD.CONFIG/Bildschirm wurde die aktuelle Farbeinstellung bisher zweifach aktualisiert.

* Kleinere Anpassungen im Quelltext.

Ein Update ist nicht unbedingt erforderlich, sollten aber Anwendungen künftig das sysVersion-Byte abfragen, dann könnten Anwendungen unter älteren Snapshots nicht mehr funktionieren. Bei der Anzahl an neuen Programmen zwar eher unwahrscheinlich, daher nur zur Info.

Wenn man aktualisiert sollte man ggf. sein Farbprofil (auch GeoDesk.col) überprüfen: Für System-Icons in einer Dateiauswahlbox sollte die Farbe Schwarz/Weiß sein. Das ist jetzt der Standard.

Quote from Juergen Johannes

Werde den Snapshot dann mal zwischen den Tagen installieren.

Nicht notwendig... behebt nur ein Problem mit BootGEOS, also dem schnellen Neustart von GEOS aus BASIC heraus, nachdem zuvor GEOS über "BASIC" beendet wurde. Das nutze vermutlich nur ich selbst...

Genauso wie bei MP3 gibt es aktuell nichts neues, nur Fehlerkorrekturen. Den Bug mit BootGEOS hab ich mit einigem Aufwand in GDOS behoben, wird aber in MP3 als "Known Bug" verbleiben, weil es vermutlich eh keiner nutzt.

In MP3/128 gibt es aber noch mehr Bugs... einen hab ich heute behoben, war sogar in GEOS128 enthalten... Nach dem commit hab ich dann den nächsten Bug in MP3/128 gefunden, der Routinen inkompatibel zu GEOS128 macht. Ich werde das allerdings nur noch dokumentieren, aber nicht mehr beheben. Solche Fehler lohnen den Aufwand nicht mehr.

Also Grundsätzlich: Wer testen will, der darf testen. Es gibt aber aktuell nur sehr spezielle Fehlerkorrekturen die bei der normalen Anwendung gar nicht getestet werden. Ich empfehle die Feiertage sinnvoller zu nutzen...

Randnotiz: Der "Official GEOS programmers reference guide" hat ein paar zusätzliche Infos, aber genauso viele Copy+Paste Fehler wie das MegaAssembler-Handbuch. Der "Hitchhikers Guide to GEOS" ist aber lesenswert, vor allem die Anmerkungen. Hätten das die Autoren des Handbuchs damals lesen können (die PDF-Version im WebArchiv ist als "CONFIDENTIAL" gestempelt), dann wäre die Aussage, das NormalizeX auch für 8-Bit-Werte gilt (S.243), wohl nicht mit in das Handbuch aufgenommen worden:

Und wenn man sich die weitere Beschreibung durchließt wird einem auch klar warum. Mir hat der Abschnitt dann geholfen den Bug in MP128 zu beheben, auch wenn der Bug wohl in der realen Welt niemals auftreten wird. Aber wenn ich von einem Fehler weiß, dann muss ich den korrigieren. Der aktuelle Sourcecode hat den Fix, einen Snapshot gibt es vorerst nicht (weil nicht relevant).

Den Fehler in ColorCard/ColorPoint kann ich nicht korrigieren, ohne evtl. existierende Anwendungen patchen zu müssen. Daher wird Teil D des Handbuchs nur einen Hinweis auf den Fehler in MP128 enthalten.