News zur Ultimate 1541 II+ und Geos

New build:

https://github.com/xahmol/GeoU…ols-v01-20230416-1351.zip

Changes:

https://github.com/xahmol/GeoU…82c8b6e455bfc916e1cc7ac47

Explanation of changes:

- GeoUMount: Fixed the maxlength check being wrong for a byte because of forgotting the attribute byte

- GeoUTime: Changed HMS time setting to setting it to the CIA clock. Now works under MP3 128 on my end

- Disk images now show proper year under GEOS in file info of the files on the image (at least on my end)

Quote from wweicht

... und das funktioniert?

Beispiel: geoWrite128 . Arbeitet nur auf 80-Zeichen, also 2 MHz. Woher weiß bzw. wer sagt geoWrite, daß es wieder auf 2 MHz umschalten soll/kann???

Ich laß mich mal überraschen, was da so kommt ....

Gideons Mesage war, dass das Einfrieren per Knopf an der U2)+) nicht geht und auch bis auf weiteres nicht gehen wird, wenn der C128 im 2 Mhz Modus ist. Seine Idee: Eine am C128 gestartete Software soll dann das Einfrieren übernehmen.

Also im konkreten Beispiel: Ein Button in GeoUMount oder ein Desk Accessory in Geos. Welches dafür extra zu programjieren ist... Da kommt nichts von Gideon, entweder macht da wer was oder es macht keiner was.

Quote from xahmol

Was ich noch überprüfen möchte: der ultimate Lib-Code, den ich mir ausgeliehen habe (ursprünglich von Scott Hutter geschrieben), verwendet einen sehr großen Datenpuffer von zweimal 896 Bytes. Gibt es einen Grund dafür, dass er so groß sein muss?

Ich hab eine der ersten Versionen von geoUMount ja reassembliert um zu sehen was der CC65 aus C-Code am C64 macht. Der Puffer mit 2x896 Bytes wird ja an verschiedenen Stellen verwendet, das längste was empfangen wird dürften aber Datei- und Verzeichnisnamen sein.

Quote from xahmol

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.

Mir ist das ja bei reassemblieren schon aufgefallen. Ich würde mal sagen 70% des Speichern den GeoUMount als Programm belegt wird durch die C-Aufrufe und Bibliotheken belegt. Das ist schon sehr umständlich und da ist es kein Wunder das Dir da der Speicher ausgeht.

VLIR wäre da ein Ausweg, aber die benötigten Verwaltungsroutinen brauchen auch wieder Platz. Ich befürchte dann kratzt das Programm bald an den 100 Blocks.

Quote from xahmol

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.

Wenn jetzt alles funktioniert besteht ja kein Grund daran was zu ändern. Nachdem aktuell mein U64 zum testen hier rumsteht hab ich mal alle DOS-Befehle unter BASIC getestet und würde da eine Assembler-Bibliothek zusammenstellen, die andere dann als Grundlage für solche Programme in Assembler verwenden können. Mir fehlt da auch etwas die Zeit, aber evtl. gibt es dann eine Lösung falls Du doch mal in Assembler programmieren willst...

Quote from xahmol

Einen Fehlerbericht veröffentlicht:

https://github.com/M3wP/GEOSBuild/issues/3

Quote from markusC64

Also im konkreten Beispiel: Ein Button in GeoUMount oder ein Desk Accessory in Geos. Welches dafür extra zu programjieren ist... Da kommt nichts von Gideon, entweder macht da wer was oder es macht keiner was.

Also per Software freezen, ich hab den Befehl in der DOS-Beschreibung gesehen aber noch nicht getestet... wenn ich an der ULib für GEOS arbeite kann ich da ja mal testen. Aber muss dazu der 40Z-Modus aktiviert werden? Oder reicht es im 80Z-Modus einfach "Freeze" an das UCI zu senden?

Quote from darkvision

Aber muss dazu der 40Z-Modus aktiviert werden? Oder reicht es im 80Z-Modus einfach "Freeze" an das UCI zu senden?

Muss nicht. Aber auf 1 MHz muss man kommen - das ist beim C128 unabhängig schaltbar. Wenn ich das richtig in Erinnerung habe, ist das 1 Bit in $D030, welches festlegt, ob 1 oder 2 MHz. Und weil der C64 VIC da nichts hat, kann man den Code dazu auch auf den C64 ausführen.

Denn der VIC kann im 2 MHz Modus keine vernünftige Bilddarstellung machen, weil ihm die Zugriffszeiten auf den Speicher durch die CPU genommen werden. Und somit müsste man das Menü der Ultimate dann blind bedienen - kein gute Idee.

Alten Wert des Bits merken und wiederherstellen reicht dafür. Ein Wechsel auf den 40 Zeichen Modus, so dass GEOS das weiß, ist nicht norwendig.

Edit: Vielleicht noch Interrupts sperren, damit garantiert niemand auf die Idee kommt, den 2 MHz Modus wieder anzuschalten bevor es sein darf.

Unnötige Funktionen wurden entfernt, und, was noch wichtiger ist, die Puffergröße wurde auf 512 Byte reduziert.

Wichtigste Auswirkung: Die maximale Anzahl der Elemente beträgt jetzt 289. Sieht für mich ausreichend aus und bietet sogar noch etwas Platz, um weitere Funktionen hinzuzufügen.

Änderungen:

https://github.com/xahmol/GeoU…b4ed2abafe4fc6cce7673199b

Bauen:

https://github.com/xahmol/GeoU…ols-v01-20230416-1442.zip

Quote from wweicht

Konfiguration: A: SD2IEC 1581, B: RAM81, C:1571, D:FD4000 . Wenn ich jetzt GeoUmount starte, dann kann ich scheinbar auf A: ein D81-Image vom 1541UII+ mounten, obwohl A: ein SD2IEC ist. Das funktioniert natürlich nicht (es passiert garnichts, das Programm tut aber so, als hätte es getan).

Deshalb meine Frage. Eigentlich sollte das Programm nur Lfw. erkennen können, die auf dem 1541UII+ eingeschaltet/verfügbar sind. Wenn keine da sind, sollte es auch keine "fremden" Lfw. erkennen .....

Hintergrund: Ich plane das 1541UII+ als D: 1581 zu betreiben. Wenn ich aber theoretisch bei meiner Konfiguration (siehe oben) für D: die 1581 der 1541UII benutze, zeigt mir das Prg A:1581, C:1571 und D:1581 an. Ich würde es gut finden, wenn nur (in diesem Fall) D: angezeigt wird ......

Nun, das ist definitiv ein Fehler und wird wahrscheinlich durch die Tatsache verursacht, dass der DEVINFO-Befehl, den ich zur Erkennung gültiger Laufwerksziele verwende, die Hardware-ID der Laufwerke zurückgibt, nicht die Software-ID.

Ich nehme an, daß die Geräte-ID 8 auf ein UII+-Laufwerk als Hardware-ID eingestellt ist, während das SD2IEC die Software-ID 8 in Ihrer GEOS-Konfiguration erhält?

Dieses Problem sollte mit dem Firmware-Fix von MarkusC64 gelöst werden, der aber noch nicht in der veröffentlichten Firmware enthalten ist.

Quote from xahmol

Dieses Problem sollte mit dem Firmware-Fix von MarkusC64 gelöst werden, der aber noch nicht in der veröffentlichten Firmware enthalten ist.

Vielleicht lohnt es sich, Gideon hier https://github.com/GideonZ/1541ultimate/pull/315 eine positive Nachricht darüber zu hinterlassen, damit er es wirklich als Last-Minute-Fix noch in die Firmware aufnimmt. Ich habe vernommen, dass eine Release unmittelbar bevorsteht.

https://github.com/GideonZ/1541ultimate/pull/316 würde GeoUMount voll funktionsfähig machen.

https://github.com/GideonZ/1541ultimate/pull/317 ist auch noch offen, ein Rename in DNP Dateien macht der Ultimate derzeit Probleme... letzteres ist quasi risikolos, weil es derzeit eh nicht recht geht.

Quote from markusC64

Ich habe vernommen, dass eine Release unmittelbar bevorsteht.

Unterstützt die Merge-Anfrage auf GitHub.

Habe übrigens erfahren, dass in letzter Minute noch ein ziemlich fieser Fehler in der +L-Version der neuen Firmware entdeckt wurde, den sie jetzt beheben. Also ist die Veröffentlichung weniger unmittelbar bevorstehend als erhofft.

Quote from wweicht

Das Ganze ist bei mir noch in der Experimentier-Phase. Habe momentan noch keine Möglichkeit das 1541UII+ als Laufwerk zu nutzen. Deshalb sind die Laufwerke auf dem 1541UII+ beide noch ausgeschaltet.

Eine Kombination, die wir eigentlich mal ausprobieren könnten... Ist quasi der Extremfall von "nur ein Laufwerk eingeschaltet", hat aber den Vorteil, dass es kombinatorisch weniger Fälle gibt.

Überseh ich was?

Da wird doch ggf. die ID auch mit abgeschalteten Laufwerken der Ultimate verglichen, oder? Die Antwort der Ultimate hat doch auch noch ein Byte, welches angibt, ob das Laufwerk überhaupt eingeschaltet ist.

Edit: Habe nachgeschaut. In dem Byte hinter der ID steht jeweils, ob das Gerät eingeschaltet ist (=1) oder ausgeschaltet (=0). In dem Byte vor der ID steht der Laufwerkstyp, falls man den mal benötigt.

Ja, natürlich.

Ich dachte, es sei nicht nötig, den Energiestatus der Ultimate-Laufwerke zu überprüfen, da sie im ausgeschalteten Zustand auch keine GEOS-Laufwerke sein können.

Aber die Kombination von anderen Laufwerk auf dieser ID und aus kann natürlich....

Ok, ich werde versuchen, das zu beheben. Heute nicht mehr alleine, jetzt kochen.

Quote from xahmol

Ich dachte, es sei nicht nötig, den Energiestatus der Ultimate-Laufwerke zu überprüfen, da sie im ausgeschalteten Zustand auch keine GEOS-Laufwerke sein können.

Tröste Dich, ich habe gerade exakt den selben Fehler in der Ultimate Firmware gefunden, da wird auch mal die ID vom ausgeschalteten Laufwerk genommen.

Mit dem Wissen konnte ich prompt die Situation herstellen, dass im falschen Laufwerk (nämlich im ausgeschalteten) gemounted wird.

Quote from wweicht

Mache ich doch tag täglich. Bis jetzt zeigt mir das Programm allerdings das SD2IEC (8; wenn es 1581 ist) und die echte 1571 (10) als Lfw. an. Eigentlich dürfte es überhaupt kein Lfw. zeigen ...

Wunderbar.

Ich habe den Pullrequest für die DRIVEINFO Korrektur un die weitere Korrektur der Drivezuordnung ergänzt - in der Ultimate Firmware ist wie gesagt der selbe Bug wie im GeoUMount vorhanden. Das ist das, was wirklich dringend ist, denn das sollte idealerweise in der bald kommenden Firmware rein.

Bis zur korrigierten Firmware ist ein Workaround, die ausgeschalteten Laufwerke auf einer ID einzustellen, keinen Konflikt mit den mountbaren Laufwerken auslöst...

Quote from markusC64

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

ich habe jedenfalls den Compiler auf die Korrektur der Firmware gerade angeworfen.

Sorry kam am Wochenende nicht zum testen, vielleicht komme ich heute dazu.

Quote from xahmol

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

Das war ich.

Danke für die Erklärung.

Benutze halt die ganze Möglichkeit von lange Image-Namen, um genauer zu beschreiben was im Image ist.

Habe sie in der Zwischenzeit gekürzt

Quote from markusC64

Werner würde Dir vermutlich genau das Gegenteil erzählen - er will nämlich bekannterweise nicht auf den 40 Zeichen Bildschirm wechseln müssen. Und das muss man mit GeoUMount auch nicht.

Nicht nur Werner, sonder auch ich.

Mit GeoUMount kann ich ohne hin und her wechseln des Bildschirmmodus ein Image wechseln.

Da ein Zugriff auf den VDC nicht vom Expansionsport möglich ist (hat Gideon mal in FB erklärt), muss immer auf den 40-Zeichen-Modus umgeschaltet werden und das ist mühsam.

Ob ein Umschaltet in den 1 MHz-Modus einwandfrei funktionieren würde und Programme (wie MP3 128) nicht trotzdem carshen ist eine andere Frage.

Quote from markusC64

Gideons Mesage war, dass das Einfrieren per Knopf an der U2)+) nicht geht und auch bis auf weiteres nicht gehen wird, wenn der C128 im 2 Mhz Modus ist. Seine Idee: Eine am C128 gestartete Software soll dann das Einfrieren übernehmen.

Also ein zusätzliches Programm starten um die Taste an der Ultimate zu benutzen? Oder stehe ich jetzt grade auf dem Schlauch?

Da kann ich gleich GeoUMount benutzen.

Gruss C=Mac.

Quote from C=Mac

Also ein zusätzliches Programm starten um die Taste an der Ultimate zu benutzen? Oder stehe ich jetzt grade auf dem Schlauch?

Zusätzliches Programm statt der Taste.

Quote from C=Mac

Da kann ich gleich GeoUMount benutzen.

Stimmt... mit einer Einschänkung. Wenn einem einfällt, dass man was anderes als Image einbinden einstellen will, zum Beispiel eine Einstellung des emulierten Druckers, dann ist eine solche Funktion zumindest nicht überflüssig. Denn von TopDesk beispielsweise ein Etwas zu starten, welches einen den Wechsel auf den 40 Zeichen Bildschirm überhaupt erst ermöglicht, dann die Taste benutzen und am Ende aus all dem wieder herauszukommen ist am Ende noch mehr Aufwand.

Neue Version:

https://github.com/xahmol/GeoU…ols-v01-20230417-1011.zip

Änderungen:

https://github.com/xahmol/GeoU…42ed450976247d953cc10400d

Behebungen:

- Überprüfung, ob das Laufwerk eingeschaltet ist, wurde hinzugefügt, um zu entscheiden, ob das Laufwerk ein gültiges Ziel ist. Es war schwierig, dies hier zu testen (GEOS / MP3 mag es nicht, wenn man ein Laufwerk ausschaltet....), daher hoffe ich, dass es funktioniert.

- Es wurde eine "Was-wäre-wenn"-Prüfung für DNPs hinzugefügt, die auf der Funktionalität im MarkusC64-Zusatz zur Firmware basiert. Ich habe mich dafür entschieden, die Prüfung beim Ausdrucken des aktuellen Dir-Eintrags auf dem Bildschirm durchzuführen. Wenn die Größe nicht stimmt, ändert sich der Typ in !IS für die falsche Größe.