Hello, Guest the thread was viewed35k times and contains 557 replies

last post from wweicht at the

News zur Ultimate 1541 II+ und Geos

    Quote from xahmol

    Schön zu hören, dass es jetzt auch unter Wheels128 funktioniert. Dann kann die Benachrichtigung von Github verschwinden. Die Aktualisierung der Dokumentation und der Versionshinweise ist in der Tat noch eine Aufgabe, aber ich wollte warten, bis die offizielle neue UII+-Firmware da ist.

    Ist schon ein bisschen her, dass ich das unter Wheels 64 ausprobiert habe (ein paar Prereleases von GeoUMount). Wie auch immer, da war das Ergebnis, dass die RAM-Ladefunktion dort nicht evrfügbar ist, weil die RAMDisks nicht erkannt werden.

    Da ich anderseits von RAM-Laufwerken im Zusammenhang mit Wheels nichts lese, habe ich gerade mal die Vermutung, dass es unter Wheels 128 ebenso sein wird.


    Vielleicht für die README relevant...

    Quote from markusC64

    Ist schon ein bisschen her, dass ich das unter Wheels 64 ausprobiert habe (ein paar Prereleases von GeoUMount). Wie auch immer, da war das Ergebnis, dass die RAM-Ladefunktion dort nicht evrfügbar ist, weil die RAMDisks nicht erkannt werden.

    Da ich anderseits von RAM-Laufwerken im Zusammenhang mit Wheels nichts lese, habe ich gerade mal die Vermutung, dass es unter Wheels 128 ebenso sein wird.


    Vielleicht für die README relevant...

    Danke! Werde morgen wieder mit Wheels128 testen.

    Und wenn das tatsächlich auch unter Wheels128 der Fall ist, wäre das definitiv etwas für die Readme.

    Hallo,


    hoffe, Du kontest Dich ein wenig erholen ;-) .


    Quote from xahmol

    dass dann sowieso eine Prüfung eingebaut werden muss, ob das Disk-Image, von dem GeoUMount gestartet wurde, noch gemountet ist.

    so lange GeoUMount nicht VLIR ist, ist das nicht nötig.

    Da wird lediglich beim Start des Prg. einmal der Info-Block gelesen und der Wert ins Programm im RAM des Rechners kopiert. Als SEQ befindet sich das komplette Prg. im Speicher.


    Quote from xahmol

    die Diskussion um DNP-Images kurz überflogen, konnte aber keine unmittelbaren Maßnahmen für mich erkennen.

    Nein, da liegt ein Problem in der 1541UII+ - Firmware vor. Die DNPs, die GeoUMount erzeugt (RAM speichern) sind völlig i.O.

    Die im Menü der 1541UII+ (F5 - Create - DNP) erstellten DNPs haben einen Fehler.

    Quote from wweicht

    ... (da sind 2 Bytes ab Offset $0207 vertauscht). ...

    Gruß

    Werner


    PS:

    Unter Wheels 128 V5.4 werden die RAM-Lfw. auch nicht erkannt. : No target

    Ist in Wheels leider so. Einzelheiten wie die einzelnen Laufwerke und Treiber unter Wheels organisiert sind sind mir nicht bekannt. Sicher ist, es ist anders als bei Geos oder MP3...

    Quote from wweicht

    so lange GeoUMount nicht VLIR ist, ist das nicht nötig.

    Da wird lediglich beim Start des Prg. einmal der Info-Block gelesen und der Wert ins Programm im RAM des Rechners kopiert. Als SEQ befindet sich das komplette Prg. im Speicher.

    Für das Laden dieser Einstellungen verstehe ich das. Aber um diese Einstellungen zu speichern, muss doch das Bild mit GeoUMount aktiv sein, oder?


    Wenn Sie die Einstellungen von GeoUMount auf der Grundlage des zuletzt aktiven Bildes speichern möchten, müssen Sie wirklich in der GeoUMount-Datei speichern, wie mir scheint.


    Oder habe ich etwas übersehen?

    Quote from wweicht

    PS:

    Unter Wheels 128 V5.4 werden die RAM-Lfw. auch nicht erkannt. : No target

    Ist in Wheels leider so. Einzelheiten wie die einzelnen Laufwerke und Treiber unter Wheels organisiert sind sind mir nicht bekannt. Sicher ist, es ist anders als bei Geos oder MP3...

    Zumindest der Teil, der in der REU ist - denn die Ultimate Firmware schaut sich aus technischen Gründen nur den REU Inhalt an.

    Ich bin jedoch schon mal froh, dass es keine Fehlerkennung gibt, die dann den REU Inhalt zerstört beim Einladen eines Images oder Müll speichert.

    Quote from xahmol

    Für das Laden dieser Einstellungen verstehe ich das. Aber um diese Einstellungen zu speichern,

    Du brauchst nichts zu speichern. Die Einstellung steht im Info-Block des Programms und kann so einfach vom Anwender angepaßt werden.

    Festgelegt werden muß nur das Format und die Stelle wo es im Info-Text stehen muß (hier würde sich Offset $a0, das 1. Byte des Info-Textes anbieten). Beim Programmstart wird diese Stelle gelesen und an eine Speicherstelle innerhalb des Programms im Speicher des Rechners geschrieben und kann solange das Programm läuft benutzt werden.

    Ist sowas wie selbstmodifizierender Code ;-) .


    Als Format (z.B. 1, 8, A oder was auch immer) kann man das wählen, was im Programm ohne große Umwandlungen benutzt werden kann.


    Gruß

    Werner

    Quote from wweicht

    Unter Wheels 128 V5.4 werden die RAM-Lfw. auch nicht erkannt. : No target

    Ist in Wheels leider so. Einzelheiten wie die einzelnen Laufwerke und Treiber unter Wheels organisiert sind sind mir nicht bekannt. Sicher ist, es ist anders als bei Geos oder MP3...

    Das die Treiber anders organisiert sind mag richtig sein, aber unter Wheels64 kann ich eine RAMDisk von der U64 laden... zumindest D64... Grundsätzlich funktioniert das... auch direkt während des Boot-Vorgangs wenn die RAMDisk beim booten formatiert wird.


    Wenn geoUMount das Target nicht erkennt, dann ist das ein Problem der Firmware oder von geoUMount. Eine RAMDisk erkennt man auch in Wheels an :driveType und die Startadresse liegt ab :ramBase. Sonst wäre Wheels auch inkompatibel zu vielen bestehenden Programmen gewesen... und sonst würde mein Testprogramm da auch nicht funktionieren.

    Quote from wweicht

    Und wie soll der reine (normale) Anwender diesen Bereich ändern können? Darum gehts ja ....


    Es geht ja auch darum möglichst viel Speicher einzusparen (GeoUMount). Den Info-Text ab $a0 kann jeder Ändern. Und schon fällt eine Speicher-Routine des Wertes ab $87... weg ....

    Dafür braucht es dann eine Testroutine welche die Werte auf Gültigkeit überprüft...


    P.S. Nicht falsch verstehen... ich mach das bei meinen Testprogrammen ja auch so (Konfiguration im Klartext im Infotext ablegen). Für Eine Anwendung halte ich es nur für Sinnvoller das in dem anderen Bereich abzulegen, vor allem wenn man zukünftig vielleicht noch mehr Konfigurationswerte speichern will...

    Naja... wenn das Programm die Werte selbst ablegt muss man nur auf $00 = Nicht definiert testen (z.B. beim Programmstart) ;)

    War aber nur ein Vorschlag...


    Man sollte aber bedenken, wenn man ggf. noch mehr Werte ablegen will: Dashboard erlaubt einem nur sehr begrenzt die Werte im Infotext zu bearbeiten. Ich wollte bei meinem Testprogramm das erste Zeichen im Infotext ändern und musste den ganzen Text löschen. Da bieten andere Programme mehr komfort als Wheels/Dashboard... Überhaupt die fehlende EDIT-Funktion bei Texteingaben (GetString) von MP3 würde mir unter Wheels am meisten fehlen...


    xahmol :

    Der Infoblock von geoUmount liegt direkt nach dem Programmstart ab $8100=fileHeader im Speicher. Der Wird von GEOS beim laden von Programm automatisch eingelesen. Wenn der Anwender im Infotext als erstes Zeichen z.B. ein D eingetragen hat, dann findet sich dieses Zeichen ab $81a0 im Speicher.

    Dann wäre das D = Laufwerk D: die Konfiguration für geoUMount und der Anwender trägt das selbst über die Datei/Info-Funktion des DeskTop in den Infotext ein. Also speichert nicht geoUMount die Konfiguration sondern der Anwender trägt die Vorgabe selbst in das Programm bzw. dessen Infotext ein.

    Man muss dann aber auf A/B/C/D testen denn der Anwender könnte ja auch was völlig falsches eintragen.

    Quote from darkvision

    Wenn geoUMount das Target nicht erkennt, dann ist das ein Problem der Firmware oder von geoUMount. Eine RAMDisk erkennt man auch in Wheels an :driveType und die Startadresse liegt ab :ramBase. Sonst wäre Wheels auch inkompatibel zu vielen bestehenden Programmen gewesen... und sonst würde mein Testprogramm da auch nicht funktionieren.

    Dein Testprogramm arbeitet ja auch mit den C64 / C128 Speicher. :driveType und ähnliche werden aber für RBOOT auch in der REU gespiegelt. Geos 64 / 128 / MP3 benutzen dazu alle dasselbe Verfahren (innerhalb der ersten 64K).

    Wheels dagegen benutzt irgendein anderes, per gespeicherten REU Inhalt und suche im Hexeditor habe ich den einzigen Kandidaten dazu fast am Ende der REU gefunden statt so ziemlich am Anfang.


    Deswegen bekommt die Firmware das nicht erkannt - die ist auf die Spiegelungen in der REU angewiesen. Denn wir wissen: C128 einfrieren geht nicht im 2 MHz Modus, er müsste aber eingefroren werden, um per DMA in den Speicherinhalt zu schauen. Und selbst das wäre unzuverlässlich, weil man keine Ahnung hat, was denn gerade die aktuelel Bank ist...sprich: Per DMA so ziemlich hoffnungslos am C128... das vergessen wir also besser, weil es eh nicht richtig funktionieren würde. Am C64 würde das klappen können, wir wollen aber eine Lösung, die für beides klappt.

    Quote from darkvision

    Der Infoblock von geoUmount liegt direkt nach dem Programmstart ab $8100=fileHeader im Speicher. Der Wird von GEOS beim laden von Programm automatisch eingelesen. Wenn der Anwender im Infotext als erstes Zeichen z.B. ein D eingetragen hat, dann findet sich dieses Zeichen ab $81a0 im Speicher.

    Dann wäre das D = Laufwerk D: die Konfiguration für geoUMount und der Anwender trägt das selbst über die Datei/Info-Funktion des DeskTop in den Infotext ein. Also speichert nicht geoUMount die Konfiguration sondern der Anwender trägt die Vorgabe selbst in das Programm bzw. dessen Infotext ein.

    Man muss dann aber auf A/B/C/D testen denn der Anwender könnte ja auch was völlig falsches eintragen.

    Ah, jetzt verstehe ich, was Sie meinen.


    Ich hatte verstanden, dass sich der Dateikopf nach dem Laden im Speicher befindet und dass er dort natürlich sowohl gelesen als auch geändert werden kann. Danke auch für die Angabe der genauen Adresse, das spart wieder Recherche.


    Was ich bis jetzt nicht verstanden habe, ist, wie diese Einstellung für den nächsten Programmstart gespeichert wird. Ich gehe davon aus, dass man dazu den geänderten Dateiheader aus dem Speicher wieder auf die Festplatte speichern muss, sonst ist die Einstellung beim nächsten Programmstart wieder so, wie sie vorher war.


    Nun meinen Sie aber, dass der Benutzer die Einstellung im Datei-Header-Block selbst ändern kann. Das ist mir klar. Ich finde es nur nicht sehr elegant. Es funktioniert, aber es fehlt eine Benutzeroberfläche mit einer Erklärung.

    Viel eleganter wäre es, wenn man den geänderten Dateikopf auch aus GeoUMount selbst heraus speichern könnte.


    Ich denke, ich werde jetzt erst einmal etwas anderes machen. Ich habe bereits GeoUTimeCfg. Wenn ich daraus ein generisches GeoUConfig mache, kann ich damit die Einstellungen sowohl für GeoUMount als auch für GeoUTime in der Konfigurationsdatei ändern, die ich bereits für GeoUTime habe.

    Das sollte recht einfach zu bewerkstelligen sein.

    Was ich dann sofort tun kann, ist das Problem für ältere Firmwares zu lösen, dass die Geräteerkennung nicht funktioniert: Ich kann auch bei älteren Firmwares den Benutzer entscheiden lassen, welche Laufwerke für ihn gültige Ziele sind. Dann schlage ich zwei Fliegen mit einer Klappe.


    Die Speicherung all dieser Konfigurationsdaten in der Kopfzeile der Datei anstelle einer separaten Konfigurationsdatei ist ziemlich elegant. Vielleicht werde ich mir also ansehen, wie man das macht. Aber ich denke, ich werde es in einer zukünftigen Version tun.

    Quote from markusC64

    das vergessen wir also besser, weil es eh nicht richtig funktionieren würde.

    Ich hab nirgendwo geschrieben das man das ändern soll... nur das es kein Problem von Wheels ist was Du ja bestätigt hast.


    Wenn Du die Adresse in Bank#0 findest lässt sich die Firmware ja daraufhin anpassen... ich hab da unter VICE nur den Speicherbereich von $082d bis $0af5 untersucht, dort scheint Wheels eine Konfiguration zu speichern, die dann in der REU ab $4000 in bank#7 (bei einer 512K REU) abgelegt wird... ab $4078 in der Bank scheint sich dann die Konfiguration finden zu lassen...


    P.S. Das ist aber nicht die GEOS-Konfiguration, sondern die Konfiguration die Dashboard64 in seinem Konfigurationsbereich abgelegt hat.

    Quote from xahmol

    Viel eleganter wäre es, wenn man den geänderten Dateikopf auch aus GeoUMount selbst heraus speichern könnte.

    Das wäre in der Tat eleganter, aber benötigt mehr Speicher. Vom Prinzip her:


    * Auf dem Laufwerk von dem geoUMount gestartet wurde nach dem Verzeichniseintrag "geoUMount" suchen (z.B. über die GEOS-Funktion FindFTypes und FindFile). Der Eintrag liegt dann ab $8400 im Speicher.

    * Aus den Bytes 19+20 im Verzeichniseintrag den Infoblock über die GEOS-Routine GetBlock nach $8100 (fileHeader) einlesen.

    * Die Konfiguration entweder nach $8187 bis $819f schreiben oder im ASCII-Format nach $81a0... (max. 95 Zeichen+NULL)

    * Den Block wieder auf Disk schreiben (über PutBlock).


    P.S. GetBlock und PutBlock benötigen in r1L/r1H den Track/Sektor des Blocks und in r4 die Speicheradresse im RAM für die Daten. Vor PutBlock muss man also sicherstellen das in r1L/r1H/r4 die richtigen Werte liegen.

    Quote from darkvision

    Wenn Du die Adresse in Bank#0 findest lässt sich die Firmware ja daraufhin anpassen...

    Wenn es so einfach wäre, die Adresse ist ganz offenbar nicht mehr in Bank 0, sondern in einer Bank, die je nach REU Größe gar nicht existieren muss - irgendwie also dynamisch...


    Hast Recht, kein direktes Problem von Wheels. Natürlich will niemand leugnen, dass Wheels sich anders als die anderen Geos-Versionen verhält, aber der Teil ist auch niemals dokumentiertes Verhalten gewesen.

    Quote from xahmol

    Was ich dann sofort tun kann, ist das Problem für ältere Firmwares zu lösen, dass die Geräteerkennung nicht funktioniert: Ich kann auch bei älteren Firmwares den Benutzer entscheiden lassen, welche Laufwerke für ihn gültige Ziele sind. Dann schlage ich zwei Fliegen mit einer Klappe.

    Das wird nichts helfen, denn für die Speicherstelle, wo der Disketteninahlt in der REU denn wirklich ist, gilt die selbe Feststellung: Auch deren Mirror ist in der REU ganz wo anders zu finden...



    Ob man das in der Firmware unterstützen muss? Weiß nicht so recht, die meisten hier im Forum nutzen es ja nicht... Ich denke, ich mache das davon abhängig. pn wer durcjh disassmblierten Code dabei hilft, die REU Speicherstellen zu finden - damit wir das dynamische Verhaölten wirklich korrekt einbinden können. Das wird nämlich nur wer machen, wenn er einen Bedarf sieht.

    Quote from markusC64

    Das wird nichts helfen, denn für die Speicherstelle, wo der Disketteninahlt in der REU denn wirklich ist, gilt die selbe Feststellung: Auch deren Mirror ist in der REU ganz wo anders zu finden...

    Dass das mit älteren Firmwares für RAM-Disks nicht funktioniert, ist richtig. Aber zumindest sollte es dann mit älteren Firmwares auf den emulierten Laufwerken A und B der Ultimate funktionieren.

    Ich kann gerade nicht folgen...


    a) Bei älteren Firmwareversionen hatten wir ja das Problem, dass er die Hardware-Geräte-ID abgefragt hat statt der Software-Geräte-ID. Die haben also für die emulierten Laufwerken A und B der Ultimate gewisse Einschränkungen.

    b) Die aktuelle Firmware funktioniert mit Wheels teilweise: Laufwerke A und B der Ultimate tun es natürlich, jetzt auch mit der Software-Geräte-ID.

    c) RAM Laufwerke und Wheels: Da kann die aktuelle Firmware aus den zuvor beschriebenen Gründen nicht helfen. Auch die Erkennung weglassen und dann nur LOAD / SAVE aufrufen nützt nichts.

    Abhilfe gibt es nur bei Bedarf UND disassemblierten RLOAD äquivalent, so dass man sehen kann, wo es in der REU gestanden haben muss...