News zur Ultimate 1541 II+ und Geos

Quote from wweicht

Es sieht so aus, als ob GeoUMount keine leeren Verzeichnisse mag . In /Flash habe ich mal ein D64 erzeugt. Jetzt kann ich den Ordner /Flash öffnen (zeigt aber nichts an ) und wieder schließen. Auf meinem USB-Stick (Usb0) habe ich mal 2 leere Ordner erzeugt. Bingo , das Prg stürzt hier ab, sobald ein leeres Verzeichnis geöffnet wird...

Dann muss ich dies schon nicht mehr testen

Quote from xahmol

Toll zu sehen, dass scheinbar Interesse besteht und mitgedacht wird.

Ein tolles Programm, das vor allem den C128-User (GEOS/MP3 128) das Leben leichter macht

Quote from xahmol

Heute liege ich nur noch krank im Bett, weshalb ich erst später nachvollziehen kann, warum GeoUMount mit leerem Verzeichnis abstürzt.

Wünsche gute Besserung.

Gesundheit ist das Wichtigste, das Programm kann warten.

Quote from xahmol

aber auch aus meiner eigenen Frustration heraus, dass das Ändern von Disk-Images im GEOS128 GEOS-Modus nur über Telnet möglich war.

Oder immer über den Weg zuerst auf 40-Zeichen umzustellen, Image wechseln und wieder zurück in den 80-Zeichen-Modus.

Quote from markusC64

Mit diesem Firmwarefix https://github.com/markusC64/1…0f6fce3ff12348bfc91c6ffc3 sollte das jetzt die korrekte ID zurückgeben, nämlich die momentane Software ID.

Da das jetzt gehen sollte, werde ich den Fix noch finetunen, so dass der Aufrufer explizit die Hardware ID haben kann - also die ID, die per DIP Schalter eingestellt ist, wenn man das mal mit der echten 1541 II vergleicht.

Steh grade auf dem Schlauch.

Wir GeoUMount eine falsche ID (Geräteadresse) geliefert, als die welche eingestellt ist und von Basic und MP3 erkannt wird?

Gruss C=Mac.

Quote from C=Mac

Wir GeoUMount eine falsche ID (Geräteadresse) geliefert, als die welche eingestellt ist und von Basic und MP3 erkannt wird?

Ja, wenn Du das interne Laufwerk in der Ultimate unter MP3 als ein anderes Laufwerk konfigurierst. MP3/GEOS kann ja Adressen tauschen, das bekommt GeoUMount dann aber nicht mit. Ultimate meldet das erste Laufwerk hat die ID=9, unter MP3 wurde das Laufwerk dann aber als Laufwerk D: eingerichtet. GeoUMount würde das Laufwerk u.U. nicht erkennen. Mit dem Fix geht es, wenn man die neue Firmware hat.

Empfehlung also vorerst ID im Ultimate-Menü = ID unter GEOS.

Danke für die Erklärung.

Dann sollte ich eigentlich keine Probleme haben.

A - D entsprechen den Adressen 8 - 11.

Tausche da eigentlich nichts um und sonst ändere ich die Adresse vom Gerät (vor dem Booten).

Gruss C=Mac.

Kleine Aktualisierung:

- Der Fehler mit dem Absturz nach einem leeren Verzeichnis scheint behoben zu sein, zumindest bei mir, indem ich eine einfache Prüfung der Fehlerbehandlung hinzugefügt habe;

- Zusammenarbeit mit Markus, um das Einbinden in die RAM-Disk und das Speichern von der RAM-Disk in das Image zu implementieren. Das funktioniert fast, aber noch nicht ganz (das Einbinden des Images in die RAM-Disk ergibt plötzlich leeren Inhalt, wo es vorher zu funktionieren schien). Das erfordert also noch etwas Forschung.

Github Commit mit den vorgenommenen Änderungen:

https://github.com/xahmol/GeoU…1b782da10e29c234d9302cb39

Neuer Build:

https://github.com/xahmol/GeoU…ols-v01-20230414-1016.zip

Quote from wweicht

Dann kommen wir mal zu einem Schönheits-Problem . Der Dialog "Credits" verhält sich nicht wie eine normale Geos-DialogBox . Ich rufe "Credits" auf und klicke dann irgendwo in der angezeigten Box (nicht auf das OK-Icon). Da wird etwas in der Box invertiert und ein Teil der DB verschwindet vom Bildschirm. Allerdings kann man den rechten Teil des Dialoges nur los werden, wenn man dann auf "OK" klickt.

Die Dialog-Box darf nur verlassen werden, wenn auf OK geklickt wird ......

Danke! Das hört sich so an, als hätte ich vergessen, die Mausklick-Behandlung des Dateibrowsers zu deaktivieren, wenn der Credits Bildschirm aktiv ist (ich verwende dort keinen Standard-Dialog-Bildschirm, sondern eine eigene Routine).

Auch das sollte leicht zu beheben sein. Ich werde mich an die Arbeit machen.

Der Fehler, dass der Dateibrowser reagiert, wenn das Dialogfeld Credits aktiv ist, sollte nun behoben sein.

Siehe:

https://github.com/xahmol/GeoU…8c006c858f367bf6a226d6955

Neue Version:

https://github.com/xahmol/GeoU…ols-v01-20230414-1447.zip

Quote from xahmol

- Zusammenarbeit mit Markus, um das Einbinden in die RAM-Disk und das Speichern von der RAM-Disk in das Image zu implementieren. Das funktioniert fast, aber noch nicht ganz (das Einbinden des Images in die RAM-Disk ergibt plötzlich leeren Inhalt, wo es vorher zu funktionieren schien). Das erfordert also noch etwas Forschung.

Ist gefunden, ein kleiner Tippfehler in der neuen Firmwarebuild...

Ich compilliere gerade eine korrigierte Firmware (VHDL compillieren dauert immer relativ lange) - dann wird sich zeigen, ob jetzt alles passt.

Haben wir hier jemanden, der das auf einer Ultimate 2+ (nicht die neue Ultimate 2+L) ausprobieren möchte? Wäre vielleicht von Vorteil, wenn wir das noch schnell ein bisschen getestet bekommen, bevor ich Gideon die beiden Patches zum Mergen gebe.

Quote from wweicht

Programme steht jeweils $7b für das Jahr. Das ergibt 123 als Jahreszahl. Wenn ich jetzt den Info-Block unter MP3 anschaue, sehe ich bei der Jahreszahl 19123. Die 19 ist im Prinzip vom System vorgegeben aber statt $7b sollte dort $17 stehen, was dem Jahr 23 entspricht ...

Mir war auch aufgefallen, dass Jahr 123 liefert, ich dachte, das sei eine Jahr-2000-Lösung oder so.

Ich werde es mir ansehen. Auf den ersten Blick nicht genau verstehen, warum dies geschieht, weil mein Code sollte nur konvertieren die Zeichenfolge 23 auf die Zahl 23 und nicht plötzlich hinzufügen 100 zu ihm.

Vielleicht findet in der CC65-GEOSlib mit den Zeitvariablen irgendwo eine unerwartete Jahr-2000-Lösung statt.

Ich werde das überprüfen und, falls nötig, die GEOS-Systemvariablen direkt anpassen, anstatt die CC65-Funktion zu verwenden.

Behebungen:

- Die OK-Schaltfläche in der Credits-Dialogbox ist jetzt im VDC-Modus doppelt so breit wie im Rest der GEOS-GUI (das Doppelattribut wurde vergessen);

- In GeoUTime wurde die Zeiteinstellung geändert, da sie irgendwie zu einem Jahr 123 von 23 führte.

Außerdem:

- Mit der neuesten Firmware von MarkusC64 scheint bei mir das Mounten von Bildern auf die RAM-Disk und das Speichern von RAM-Disk-Inhalten in ein Bild in GeoUMount voll zu funktionieren.

Immer noch ein Problem:

- Das Einstellen des Datums funktioniert in MP3 128 mit Topdesk, aber irgendwie nicht das Einstellen der Zeit, während es unter normalem GEOS 128 funktioniert.

Hat hier jemand einen Vorschlag, da das Einstellen der Zeit (HMS) über die Systemvariablen Stunde, Minuten, Sekunden ($8519, $851A und $851B) unter dem normalen GEOS128 funktioniert, aber anscheinend nicht unter MP3 128 mit dem neuesten Topdesk128?
(Und wie ich jetzt sehe, funktionierte es in meinen früheren Versionen auch unter MP3/TD nicht, also kein neu eingeführter Fehler)

Weitere Überlegungen:

Mir ist vorher nicht so viel aufgefallen, da ich normalerweise keine Verzeichnisse mit mehr als 100 Einträgen verwende (ich habe eigentlich nur ein einziges, das ich zu Testzwecken erstellt habe, eine Kopie der CSDb Demo Top 200), aber jede zusätzliche Codezeile frisst den für die Verzeichniseinträge verfügbaren Speicherplatz auf. Ich bin von 170 in meiner ersten veröffentlichten Alphaversion auf 115 gefallen, wie ich unter GEOS128 sehe. Und ich würde es hassen, auf den REU-Speicher zurückgreifen zu müssen, denn das würde auch eine erhebliche Umschreibung des Programms bedeuten. Zusammenfassend lässt sich also sagen, dass ich mit CC65 an die Grenzen dessen stoße, was ich speichertechnisch tun kann, da ich nicht unter 100 Einträge Speicherplatz fallen möchte.

Wenn ich also mehr hinzufügen möchte, muss ich entweder zu einer VLIR-Anwendung wechseln, bei der sich nicht der gesamte Code gleichzeitig im Speicher befindet (möglich, aber von begrenztem Nutzen, da ein Großteil des Codes für jede Funktion benötigt wird), ihn auf verschiedene Anwendungen aufteilen oder das Ganze in Assembler umschreiben. Letzteres wäre wahrscheinlich die bei weitem beste Lösung, aber dazu fühle ich mich derzeit weder in der Lage, noch habe ich die Zeit dafür.

Kurz gesagt: Ich bin geneigt, die derzeitige Version als vollständig zu bezeichnen, abgesehen von weiteren Fehlerkorrekturen, wo nötig. Oder haben Sie andere Ideen dazu?

Änderungen:

https://github.com/xahmol/GeoU…667778a90a44de799f58d5b53

https://github.com/xahmol/GeoU…591611045d4c83dd0a3c36bfc (kleine Fehlerkorrektur im vorherigen Build)

Letzter Build:

https://github.com/xahmol/GeoU…ols-v01-20230415-1415.zip

Übrigens: Irgendwo in diesem Thread habe ich die Frage gesehen, warum ich die Länge der Dateinamen auf die Anzeige beschränkt habe. Dies ist der Grund: Speicherbeschränkungen.

Ich habe mich für maximal 20 Positionen entschieden, einschließlich der vier der .dxx-Erweiterung, als Kompromiss zwischen Benutzerfreundlichkeit und der Anzahl der Elemente, die in den für CC65 unter GEOS verfügbaren Speicher passen, ohne auf REU-Speicher oder ähnliches zurückzugreifen oder die plattformübergreifende Kompatibilität zwischen C64 und C128 oder zwischen verschiedenen GEOS-Versionen zu verlieren.

Es geht vermutlich darum, dass das Programm von Xander das nicht hinbekommt. Das andere in dem D64 / D81, welches für die Zeit aus einem NTP-Server aus dem Internet zu nehmen.

Quote from xahmol

Immer noch ein Problem:

- Das Einstellen des Datums funktioniert in MP3 128 mit Topdesk, aber irgendwie nicht das Einstellen der Zeit, während es unter normalem GEOS 128 funktioniert.

Hat hier jemand einen Vorschlag, da das Einstellen der Zeit (HMS) über die Systemvariablen Stunde, Minuten, Sekunden ($8519, $851A und $851B) unter dem normalen GEOS128 funktioniert, aber anscheinend nicht unter MP3 128 mit dem neuesten Topdesk128?

Die Uhrzeit wird nicht über $8519/1A/1B gesetzt, sondern direkt über die Systemuhr im CIA#1 ($DC08...$DC0B, BCD-12h-Format...)

Die Werte in hour/minutes/seconds sind READONLY und werden vom GEOS-Kernal über die Mainloop aus der System-Uhr erzeugt.

Datum kann man nach year/month/day schreiben, das wird vom GEOS-Kernal auch nicht verwendet, nur von Anwendungen.

Quote from darkvision

Die Uhrzeit wird nicht über $8519/1A/1B gesetzt, sondern direkt über die Systemuhr im CIA#1 ($DC08...$DC0B, BCD-12h-Format...)

Die Werte in hour/minutes/seconds sind READONLY und werden vom GEOS-Kernal über die Mainloop aus der System-Uhr erzeugt.

Datum kann man nach year/month/day schreiben, das wird vom GEOS-Kernal auch nicht verwendet,

Danke! Das erklärt eine Menge. Es funktionierte unter Standard-GEOS, Glück oder hat MP3 aus Gründen abgewichen?

Werde versuchen, das zu implementieren.

Quote from xahmol

Danke! Das erklärt eine Menge. Es funktionierte unter Standard-GEOS, Glück oder hat MP3 aus Gründen abgewichen?

Ich würde auf Zufall tippen, denn auch unter GEOS128 werden die Werte in hour/minutes/seconds durch die GEOS-Mainloop bei jedem Durchlauf aktualisiert, eben getestet. Evtl. hat DESKTOP die Uhrzeit aus hour/minutes/seconds nach dem Setzen über Dein Programm ausgelesen, bevor die Mainloop die Werte aktualisiert hat.

Quote from xahmol

Werde versuchen, das zu implementieren.

Es empfiehlt sich neben der Uhr in CIA#1 trotzdem auch die Werte in hour/minutes/seconds zu aktualisieren. Auch wenn die Werte durch die GEOS-Mainloop später überschrieben werden würde sonst nach dem Aufruf von ":EnterDeskTop" von DESKTOP zuerst noch die alte Uhrzeit angezeigt bis die Kontrolle an die Mainloop übergeben wird. Diese überschreibt dann die Werte in hour/minutes/seconds und erst beim nächsten Uhr-Prozess würde DESKTOP dann die Uhrzeit korrekt aktualisieren.

Ich hab eben meine eigenen Programme überprüft: MP3 mit dem Programm dualTop zeigt nach dem booten zuerst eine "Standard"-Uhrzeit an, erst nach ca. 1min wird die korrekte Uhrzeit aktualisiert. MP3 setzt die Werte in hour/minutes/seconds nicht nachdem die Uhrzeit aktualisiert wurde.

Meine anderen Programme aktualisieren neben der Uhrzeit auch hour/minutes/seconds und haben dieses "Problem" nicht.

Also kannst Du die alte Routine zum setzen der Uhrzeit in hour/minutes/seconds behalten, es muss nur zusätzlich noch die Systemuhr gesetzt werden.

Quote from wweicht

Da ist aber noch ein Bug (wurde hier schonmal weiter vorne erwähnt). Das betrifft wohl irgendwie das Build-System, denn das kann ich auch bei GeoUTime und GeoTimeCfg sehen. Im Dateieintrag für die 3 Programme steht jeweils $7b für das Jahr. Das ergibt 123 als Jahreszahl. Wenn ich jetzt den Info-Block unter MP3 anschaue, sehe ich bei der Jahreszahl 19123. Die 19 ist im Prinzip vom System vorgegeben aber statt $7b sollte dort $17 stehen, was dem Jahr 23 entspricht ...

Ist ein Bug im Buildsystem, in diesem Fall in GEOSBuild ( https://github.com/M3wP/GEOSBuild.git ). Wer kann noch ein bisschen Pascal?

Ja, genau, das ist der Bug, daher kommt das 123 für 2023.

Demzufolge ist natürlich auch im neusten Build das Jahr im Verzeichniseintrag noch falsch - kann ja nicht anders.