Hello, Guest the thread was viewed90k times and contains 777 replies

last post from uwe1972 at the

GDOS64

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

  • Kurzer Zwischenbericht (Realsystem)........


    C128DCR (64er Modus) + SCPU128 (16 MB Ram)

    LW08 CMDHD (parallel verbunden)

    LW09 CMDRL (parallel verbunden)

    LW10 SD2IEC

    LW11 RAMNATIVE zum Borderblock testen


    Gdos vom 20.08.22 installiert auf RL1581 Partition und auch auf CMDHD 1581 Partition.


    Um es vorweg zu nehmen, weder bei der Installation, noch beim Freigeben der Module traten Fehler auf. Auch die neuen Futures funktionierten bei mir ohne Probleme.:thumbsup:


    Die Probleme mit der "Geodos" Partitionsauswahl sind beseitigt. In Vice werde ich das später auch noch mal probieren.:thumbup:


    Verzeichnisse im DOS Fenster ("C"+rechte Maustaste auf ein aktives Fenster) lassen sich jetzt mit der "Spacetaste" Stück für Stück anzeigen.:thumbup:


    Das Menü zum Umbennen der Partitionen finde ich Super gelungen und ging auf Anhieb.:thumbup:


    Auch das Testen mit den Borderblock Programmen klappte reibungslos. :thumbup:


    Hierzu hätte ich noch eine Idee, wenn überhaupt umsetztbar.......

    Ich habe vor langer Zeit den Doubledesk128 (mit Gateway128 erstellt) der Bachmänner mitgetestet.

    Da gab es auch die Möglichkeit Randdateien auszuwählen.

    Bei diesen Dateien wurde der Name der markierten Borderblockdatei Kursiv dargestellt (sonst alles gleich). So konnte man immer zwischen "Hauptdatei" und "Borderdatei" unterscheiden. Fand ich irgendwie hilfreich.:)


    Bin mal wieder Happy mit welchen Ideen darkvision sein Programm füttert. Einfach genial......:thumbsup:


    Liebe Grüße,

    Jojo

  • Auch bei mir so. :)


    Installation auf Real System, CMD RL und CMD HD. Auch auf WinVice die gleiche Prozedur. Alles ohne Probleme. :thumbup:


    Zum Probieren der Neuerungen bin ich leider heute nicht mehr gekommen.


    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.:)


    Weiteres folgt........


    Liebe Grüße,

    Jojo

  • Tach, Cool, das du da bist..........


    Hab bis jetzt am neuen GD Update gebastelt, ABSOLUT COOL, Das !!!


    Man kann jetzt versch.Systemicons austauschen

    Gel.Dateien, Unterordner, Arbeitsplatz usw.

    Etwas Gewöhnungsbedürftig, aber ganz Super !!!


    So, für heute ist schluß, will noch einen Film schauen


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

    (Bin aber noch nicht ganz fertig geworden)


    Viele Grüße und Gute Nacht :zzz:

  • 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 ;)


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


    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.

  • Guten Abend,


    habe gerade den neuen Snapshot vom 14.10.22 auf mein CMD RL (1581er Part.) installiert.

    Verlief alles reibungslos. :thumbup:


    Die neuen Dinge muß ich mir dann anschauen.....


    Kleine Anmerkung:

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

    Nach dem Austauschen mit dem gefixten SuperMouse64 Treiber aus Posting #210 funktionierte der P/S-Editor ohne Probleme.:)


    Allen ein schönes Wochenende und den ps-editorv3 zum ausprobieren........


    Liebe Grüße,

    Jojo

  • Kleine Anmerkung:

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

    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:

    Code
    1. ;--- Hinweis:
    2. ;Nur Bit %7 setzen! Der Wert $FF ist
    3. ;nicht definiert und führt bei einigen
    4. ;Programmen zu Problemen, z.B. bei
    5. ;P/S-Editor aus dem GEOS-MegaPack2.
    6. :SetKeyOff   lda #%10000000 ;Flag "Keine Maustaste gedrückt".
    7.                 b $2c
    8. :SetKeyOn lda #%00000000 ;Flag "Maustaste gedrückt".
    9. sta mouseData ;Modus für Maustaste setzen.

    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.

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


    Du hast recht, genau daran hat's gelegen. Hatte beim installieren noch gar nicht an den geänderten Maustreiber gedacht und so den alten übernommen. Später beim ausprobieren einfach nicht mehr auf dem Schirm gehabt.


    SORRY, mein Fehler. :whistling:


    Liebe Grüße,

    Jojo

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

  • Neuer GDos64 Snapshot.........:)


    https://bitbucket.org/mkgit64/area6510/src/master/usr/


    Vielen Dank mal wieder, dass wir mit ausprobieren können.

    Ist was für die Feiertage. In diesem Sinne ruhige, besinnliche Weihnachten und ein gesundes Neues Jahr.:thumbup:


    Werde den Snapshot dann mal zwischen den Tagen installieren.


    Liebe Grüße,

    Jojo

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

  • Ähnlich wie im MP3 Tread (mit dem neuen MP3 Update )

    habe ich Probleme mit der neuen GD Version (03012023)

    Keinerlei Probleme unter Vice, aber auf realer HW funktioniert das nicht.

    Das Setup läuft durch, dann kurz vor dem Ende, wenn die Startdisk konfiguriert werden soll bleibt alles Hängen, Booten klappt auch nicht hinterher.

    Hab die Setupdisk mehrmals neu gezogen, selbiges Ergebnis

    A: FD 2000 N

    B: Reu 16MB

    C: SD2iec N

    D: 1581 (RamLW)


    Setup auf Reu kopiert und gestartet, Installiation in Ram D

    1581 Dateien anschließend auf Neue, leere Disk kopiert.

    Hat bis jetzt immer funktioniert...................