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

last post from wweicht at the

News zur Ultimate 1541 II+ und Geos

  • Ach ja, der Bug... wo unverändert neucompillieren reicht, damit es geht - zur Verwunderung aller :-(


    Wahrscheinlich geht das bei mir, weil ich mit Ausnahme des FPGAs (der closed source ist) das neucompilliert habe.

  • Ich Denke es ist nur die Routine zum erstellen eines leeren DNP... das sind zwei unterschiedliche Dinge.

    Fast richtig - sieht so aus, als wäre genau hier der Bug: https://github.com/GideonZ/154…em/filesystem_d64.cc#L878 (Zeile 878).


    Also in der Format-Routine...

  • Ach ja, der Bug...

    Nun, selbst wenn das funktionieren würde, nützt das nicht viel.


    kannst Du mit Cursor-Rechts die wie ein Verzeicdhnis öffnen und den Inhalt betrachten und verändern.

    Ich arbeite ja nur mit MP3 (selten mit Geos) und das überwiegend im 80-Zeichenmodus. Da sind mir die Funktionen des 1541UII+Menüs nicht so geläufig. Brauche ich ja auch sogut wie nie ;-) .


    Problem hier: die Geschicht über "Software IEC Settings" wird wohl sehr langsam sein. und es bleibt dann immer noch das Problem, wie MP3 davon überzeugen, das zu öffnen. Da müßte dann ziemlich sicher ein neuer Treiber für Ultimate her (war ja beim SD2IEC-Native auch so). Ob sich dieser Aufwand lohnt, wage ich mal zu bezweifeln .....


    Gruß

    Werner

  • Problem hier: die Geschicht über "Software IEC Settings" wird wohl sehr langsam sein. und es bleibt dann immer noch das Problem, wie MP3 davon überzeugen, das zu öffnen. Da müßte dann ziemlich sicher ein neuer Treiber für Ultimate her (war ja beim SD2IEC-Native auch so). Ob sich dieser Aufwand lohnt, wage ich mal zu bezweifeln .....

    Richtig, denn:

    Das Laufwerk ist aber zu keinen einzigen Speeder, der über den IEC Bus läuft, kompatibel. Und bis zum Bugfix klappen U1 und U2 auch nur eingeschränkt. Sprich: Mit Geos wird das über dem Laufwerk nichts.

    In Zukunft, wenn das IEC Device kompatibler geworden ist, dann könnte man mal probieren und schauen, ob es mit der speziellen MP3 Version funktioniert, die Kernal I/O verwendet... damit sehe ich eine gewisse Chance für später.


    Aber davon abgesehen: Brauchen tue ich das IEC Device insb. für Geos nie und nimmer. Ich kann ja einfach Images in die RAMDISK laden, ist sowieso viel schneller. Und Dank GeoUMount das jetzt auch im 80 Zeichen Modus des C128 problemlos.

  • Mann oh, Mann ich werde wahnsinnig ... ;-)

    Problematisch finde ich nur, daß die ID der RAM-Disk nicht ins DNP übernommen wird. Hier wird einfach der Anfang des Dateinames verwendet (hier "reubn").

    Hatte ich geschrieben, ist aber Blödsinn ;-) . GeoUMount macht hier alles richtig. Sorry.


    Der Übeltäter ist das Programm, das ich zur schnellen Anzeige des DNP benutzt habe. Es ist ein alter Bekannter bezüglich Problemen : DirMaster V3.1.5 von https://style64.org/ . Sorry, keine Ahnung, warum das Prg die Disk ID nicht angezeigt bekommt....

    Hier fliegt das Teil jetzt endgültig und unwiderruflich von der Festplatte!


    Für heute ist Schluß. Jetzt muß nur noch mal probiert werden, was GeoUMount beim Zurückschreiben eines DNP macht, wenn das DNP kleiner oder größer ist als die Ziel-RAM-Native ...


    Gruß

    Werner

  • Hier bei mir funktioniert es am echten C128 DCR, wenn ich von der originalen GEOS128-BOOT-Diskette von der internen 1571 (Lfw. 8 ) boote, Geos128 verlasse und dann die von Commodore ab Werk vorhandene RESET-Taste am C128 kurz drücke. Geos 128 kommt wieder.

    Ich meinte, wenn ein Programm abstürzt oder einfriert komme ich mit einem Reset nicht mehr aus GEOS/MP3 raus, es bleibt nur abschalten.


    Bedeutet?

    Es ist möglich Dateien aus einem DNP zunehmen und in ein D64/71/81 zu kopieren um sie erreichbar zu machen?

    Als LfW ist DNP noch nicht möglich (vielleicht kommt ja mal die HD), hier ist das SD2IEC noch im Vorteil.



    Wegen der ganzen RAM (REU) speichern und wieder zurück schreiben Geschichte.

    Frage ich mich grade ob folgendes Möglich wäre.

    In der RAM befindet sich die Startdateien von MP3, das RAM wird gesichert und nach dem erneuten Einschalten des Rechners zurückgeschrieben und MP3 davon gestartet.

    Nur wie könnte ich MP3 starten?

    Aus Basic habe ich ja kein Zugriff auf die REU.


    Gruss C=Mac.

  • Frage ich mich grade ob folgendes Möglich wäre.

    Ja... unter MP64/GDOS64... für MP128 hatte ich bisher keinen Lust FBOOT anzupassen, weil das bestimmt nicht so einfach wird.


    Aber damit lade ich die REU mit einem DiskImage, starte FBOOT, das dann RBOOT ausführt und anschließend den Boot-Vorgang von der RAMDisk fortsetzt. Mein TC64 kann ich so einrichten das ich den C64 einschalte, Warte... GDOS64 ist da... ohne Tastendruck, ohne LOAD"*"...


    (P.S. Nicht falsch verstehen, das müsste auch mit Ultimate gehen... Preload REU gibt es ja... man muss dann nur ein Programm automatisch starten... ist nur nicht mein Spezialgebiet... aber FBOOT wurde für den Fall entwickelt aus dem RAM zu starten)

  • Die "defekten" DNPs funktionieren aber auf dem Ultimate im BASIC-Modus?

    Ja tun diese.

    Diese Aussage halte ich für hoch gefährlich!


    Fakt ist, diese DNPs sind korrupt. Also sollten sie nicht benutzt werden!


    Theoretische Aussage (ich werde das nicht probieren): Was passiert eigentlich im BASIC-Modus, wenn ich mit der 1541UII+ fleißig Dateien auf dieses korrupte DNP kopiere bis die Grenze des DNP überschritten ist (es ging ja um ein 191 Track-DNP). Wird es dann automatisch größer. Den einzigen Wert, wo man das ablesen (oder vergleichen) könnte existiert ja nicht. Und irgendwann ist das DNP dann größer als die in der DNP-Beschreibung genannten 16 MB?

    Nein, sowas ist korrupt und gehört gelöscht. Gut, daß MP3 und Co da aufpassen und eine Fehlermeldung bringen!


    Gruß

    Werner

  • Wird es dann automatisch größer. Den einzigen Wert, wo man das ablesen (oder vergleichen) könnte existiert ja nicht. Und irgendwann ist das DNP dann größer als die in der DNP-Beschreibung genannten 16 MB?

    Die BAM hat ja eine feste Größe, egal ob 1Mb oder 16Mb. Nicht verwendete Tracks sollten in der BAM mit "00" gefüllt sein, und das scheint in Deinem dnp der Fall zu sein. Auch ohne zu wissen wie viele Tracks existieren dürfte irgendwann das DOS keine freien Blocks mehr in der BAM finden -> Disk full.


    Also größer werden? Eher unwahrscheinlich...

  • Genau, da hat Darkvision recht. Außerdem hat man ja noch die Imagedateigröße zur Verfügung (im Gegensatz zu der Situation, wenn es in der REU eingeladen ist). Ich merke mir mal vor, dass ich nachschauen will, ob die zu einem Check, ob der Track valide ist, genutzt wird.

    Im Moment hat aber ein Crash beim Konvertieren von G64 nach D64 Vorrang, denn der hat für mich extremstes Nervpotenzial.

  • Für heute ist Schluß. Jetzt muß nur noch mal probiert werden, was GeoUMount beim Zurückschreiben eines DNP macht, wenn das DNP kleiner oder größer ist als die Ziel-RAM-Native ...

    Die aktuelle Version der Firmware lädt es nur ein, wenn die Größe genau passt. Ansonsten verweigert sie das Einladen mit einer Fehlermeldung.


    Bei einer größeren RAMDISK als die Imagegröße könnte man zwar drüber nachdenken, das Image beim Laden anzupassen - aber im Moment sehe ich zumindest dafür keine Notwendigkeit.

  • Die BAM hat ja eine feste Größe, egal ob 1Mb oder 16Mb. Nicht verwendete Tracks sollten in der BAM mit "00" gefüllt sein

    Ja, aber ich halte es trotzdem nicht für gut, solche DNPs zu benutzen. Sie entsprechen nicht dem DNP-Format und irgendwann gibt es etliche solche kaputten Dinger.

    Ja, wer weiß. was er tut kann das mit einem Diskeditor simple reparieren, aber wer macht sowas ;-) .


    Mir kann es aber egal sein, ich verwende DNP nur unter MP3 und das meldet bei so etwas zuverlässig Fehler!


    Die aktuelle Version der Firmware lädt es nur ein, wenn die Größe genau passt.

    Ja, wollte nur wissen, wie das in GeoUMount aussieht. Jetzt weiß ich es und es ist gut so. Die DNPs, die von der Größe her nicht passen, erhalten die Endung "!IS" und sind nicht anwählbar...

    Bei einer größeren RAMDISK als die Imagegröße könnte man zwar drüber nachdenken

    Ja, aber muß nicht unbedingt sein. Vielleicht irgendwann später mal.... ;-)


    Gruß

    Werner

  • Mal wieder was positives ;-) :


    Auf xahmol 's github-Seite steht nach wie vor, daß es unter Wheels Probleme gibt (ich weiß, das muß noch aktualisiert werden):

    Quote

    Freezes in Wheels. Needs further testing and investigation

    GeoUMount funktioniert hier bei mir am C128DCR unter Wheels 128 (soweit ich weiß sind hier bei mir alle bekannten Wheels-Updates und Patches enthalten) eigentlich ohne Probleme (40- und 80-Zeichen). Zumindest der Wechsel von D81 erfolgt zuverlässig.


    Daß der Diskname in Dashboard nicht sofort aktualisiert wird, ist ein Dashboard-Problem. Da muß dann nur das Laufwerksfenster neu geöffnet werden, dann stimmt wieder alles. Das ist z.B. beim SD2IEC (Native-Mode, HD unter Wheels) genauso.


    Gruß

    Werner

  • Hallo,


    habe heute eher zufällig eine Funktion im 1541UII+ entdeckt, die ich so noch nicht kannte (neu in der zurückgezogen neuen Firmware ??) . Man kann am C128 in BASIC im 80-Zeichenmodus die Menu-Taste drücken. Dann am Monitor den 40-Zeichenmodus aktivieren und das Menü ist da. Jetzt kann man ein Dxx mounten, das Menü verlassen und wieder auf 80-Zeichenbildschirm zurückschalten und dort dann z.B. Geos (MP3) laden. Man muß also nicht mehr im 40-Zeichenmodus laden.


    Das hat bei mir aber nur in BASIC funktioniert. Unter Geos ging das nicht: Absturz.


    Gruß

    Werner

  • Man kann am C128 in BASIC im 80-Zeichenmodus die Menu-Taste drücken. Dann am Monitor den 40-Zeichenmodus aktivieren und das Menü ist da.

    Eine Gelegenheit, die Wissenslücken aufzufüllen:


    PRINT PEEK(53296) AND 1

    in Basic eingegeben verrät einem, ob der C128 im 1 MHz Modus (Ergebnis 0) oder im 2 MHz Modus (Ergebnis 1) ist.
    Und siehe da: Führt man das im Basic 7.0 auf dem 80 Zeichen Bildschirm aus, so kommt eine 0 zurück.

    Die Befehle "FAST" und "SLOW" existieren in Basic 7.0 und ändern die Takrfrequenz, wie der obige Befehl belegt.



    Geos dagegen schaltet auch auf 2 MHz, wenn man im 80 Zeichen Bildschirm ist und deswegen klappt das Einfrieiren mit der Ultimate nicht. In Basic 7.0, ohne den Befehl "FAST" abgesetzt zu haben, klappt es dagegen, weil der C128 oft im 1 MHz ist (natürlich kann ein zuletzt gestartetes Programm das geändert haben, deswegen die vorsichtige Formulierung).

  • die ich so noch nicht kannte (neu in der zurückgezogen neuen Firmware ??)

    Nö ist nicht neu, war schon in den älteren Firmware so.

    Nur ein Programm welches im 80-Zeichen/2MHz-Modus läuft fliegt dabei gnadenlos auf die Schnauze. :rolleyes:


    Um wieder zu GeoUMount zurück zu kommen.

    Da ich heute wieder mit Wheels 128 rumgespielt habe, konnte ich die aktuelle Version probieren.

    Konnte ohne Probleme D64 wechseln, kein Absturz nix.


    Gruss C=Mac.

  • D81 konnte ich heute nicht wechseln, Wheels 128 blieb immer im gleichen Image.

    Womit?


    Auf 1541UII+ (ist hier Lfw. 11, eine 1581) funktioniert es bei mir. Habe GeoUMount vom 23.04.2023 15:42 (das ist die letzte Version). Möglicherweise liegt es auch an der Firmware. Ich habe hier schon die aktuellere 10f drauf, die aber offiziell zurückgezogen wurde...


    Gruß

    Werner

  • Wieder zurück aus dem Urlaub!


    Die Meldung, dass GeoUMount in Wheels128 abstürzt, stammt noch aus der Version 0.1, der ersten Alpha-Version. Das war die Version, bevor ich alle Fehler, die Sie gefunden haben, behoben habe und somit die Version, bei der es mehr Glück als Verstand war, dass es funktioniert hat ;-)

    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.


    Diese neue Firmware ist leider immer noch nicht offiziell, da 3.10f aufgrund von Fehlern mit dem SoftIEC zurückgezogen wurde.

    Inzwischen habe ich eine Testversion von 3.10g erhalten, die zumindest auf allen meinen Rechnern (C128 flat mit UII+L, C128DCR mit UII+ und C128D mit UII+) sehr stabil läuft. Daher habe ich vor, dieses Wochenende mit der Aktualisierung der Dokumentation zu beginnen.


    Ich denke, ich werde die Anforderung, sich die Präferenz für das Ziellaufwerk zu merken, auf später verschieben.


    Die Speicherung von Konfigurationsdaten in der Datei info klingt nach einer guten Lösung. Aber ich habe keine Ahnung, wie das zu tun, so dass einige Studie erfordert zunächst. Außerdem glaube ich nicht, dass das das Problem löst, dass dann sowieso eine Prüfung eingebaut werden muss, ob das Disk-Image, von dem GeoUMount gestartet wurde, noch gemountet ist.


    Ich sage nicht, dass ich das nicht tun werde, aber ich weiß nicht, ob das auf kurze Sicht meine Priorität ist.


    Haben Sie in den letzten zwei Wochen sonst noch etwas vermisst? Ich habe die Diskussion um DNP-Images kurz überflogen, konnte aber keine unmittelbaren Maßnahmen für mich erkennen.