letzter Beitrag von Juergen Johannes am
Auch hier wird die 1581 Emulation der Ultimate 2+ erkannt und unterstützt.
Nein, die aktuelle Firmware des U64/U2+ wird *NICHT UNTERSTÜTZT*.
Es mag funktionieren, aber die Firmware > HyperSpeed steht hier auf der schwarzen Liste. Es gibt also keine Unterstützung seitens MP3 für diesen experimentellen U64-Kernal/Firmware. Das wird sich auch von meiner Seite aus nicht mehr ändern.
Tja der C128 war schon immer ein schnelles Kerlchen
naja.. genauso schnell wie überflüssig 
Nein, die aktuelle Firmware des U64/U2+ wird *NICHT UNTERSTÜTZT*.
Es mag funktionieren, aber die Firmware > HyperSpeed steht hier auf der schwarzen Liste.
Für den U64 hast Du dafür nachvollziehbare Gründe genannt. Aber für die U2+ sehe ich die nicht - denn da hat sich an den möglichen Einstellunegn eigentliuch nichts geändert gegenüber den alten Versionen... und eine Turbomodus hat die auch nicht... in der neusten Version kann die zusätzliche Floppytypen emulieren, das ist alles. Alles andere konnte man in der alten Versionen (3.7 und älter, bei 3.8 1.33 kam im U64 der Turbo) auch schon falsch machen...
Vor dem Hintergrund ist das zumindest bisher als eine Aussage über die U64 Unterstützung (nur mit alter Firmawre) angekommen, nicht für diue 1541 Ultimate I / II / II+.
Okay. jetzt haben wir Klarheit.
Was ein Glück ist "3.3r9 final" noch nicht "final"... 
Es gibt einen Bug der nur in Verbindung mit einer RAMLink, GeoWrite, einigen bestimmten Positionen im Text und dem TaskManger auftritt. Ergebnis -> Crash...
Zuerst hatte ich die Laufwerkstreiber im Verdacht, dann die RAMLink-Emulation in VICE. Der Fehler trat mit dem gleichen geoWrite-Dokument aber auch bei realer Hardware auf. Allerdings nur wenn die SuperCPU64 deaktiviert war. Und nur wenn der Text an bestimmten Stellen steht...
Schlussendlich ist es geoWrite, welches diverse ZeroPage-Adressen verändert die auch von Kernal-I/O-Routinen verwendet werden.
GeoWrite selbst setzt die Bereich vor jedem I/O-Zugriff zurück und nach dem I/O-Zugriff werden wieder die geoWrite-Werte zurückgespeichert. Genauer gesagt werden die Werte von $0080 bis $00FF 2x getauscht.
Ursache ist hier die Adresse $0094, welche in geoWrite wohl die aktuelle Cursorposition im Text definiert. Diese wird aber auch von diversen Kernal-Routinen verwendet. Und da der TaskManager die BAM aktualisiert führen bestimmte Werte in $94 dazu das hier das RAMLink-ROM fälschlicherweise auf das Shadow-ROM umschaltet was dann zum Absturz führt.
Ich muss mir jetzt mal die Adressen von $0080-$00FF anschauen, welche da für I/O notwendig sind. Gesichert wird deren Inhalt schon, ich muss den Inhalt aber dann für neue Tasks bzw für den TaskManager selbst initialisieren. Und welche Werte es da braucht muss ich mir erst genauer anschauen. Ein Fix wird also kommen, aber kann etwas dauern...
Ursache ist hier die Adresse $0094, welche in geoWrite wohl die aktuelle Cursorposition im Text definiert. Diese wird aber auch von diversen Kernal-Routinen verwendet. Und da der TaskManager die BAM aktualisiert führen bestimmte Werte in $94 dazu das hier das RAMLink-ROM fälschlicherweise auf das Shadow-ROM umschaltet was dann zum Absturz führt.
Sehr interessanter Fehler! 
D.h. es ist unabhängig vom Text in geoWrite, es ist wohl "nur" die (aktuelle) Cursorposition in geoWrite entscheidend?
D.h. es ist unabhängig vom Text in geoWrite, es ist wohl "nur" die (aktuelle) Cursorposition in geoWrite entscheidend?
Ja... der Text ist egal... ich hab eben "1"er bis zu einer bestimmten Position erzeugt, danach führt der TaskManager hier zum Crash.
In meinem Fall ist es die Kernal-Routine "LISTEN" welche im RAMLink-Kernal diesen Code beinhaltet:
Direkt nach dem Start von GeoWrite zeigt $94/$95 auf $432b, also ist $94=$2b und damit POSITIV. Der Code ab $ED14 verzweigt zu $ED20 und der "STA $DF7E"-Befehl bei $ED23 schaltet das RAMLink-ROM um und danach steht bei $ED27:
Wenn die Adresse $94 >= $80 ist, dann wird $ED27 als Sub-Routine ab $ED19 aufgerufen, diese verändert ebenfalls $DF7E und dann steht ab $ED2B folgender Code:
Un in $DE34 steht hier immer $0000 -> Absturz.
Die Adresse $94 ist laut "C64 für Insider"
ZitatC3PO $0094 Flag serieller Bus: Zeichen in Puffer.
Hat also wirklich was mit dem seriellen Bus zu tun. Und auch bei der RAMLink gibt es im Treiber Zugriffe auf den seriellen Bus.
Ist innerhalb von GeoWrite kein Problem, das kopiert ja bei jedem Diskzugriff 128 Bytes in den Zwischenspeicher und hinterher wieder zurück. ZeroPage-Speicher war denen wohl wichtiger als CPU-Zyklen.
Der TaskManager ging bisher aber nicht davon aus das in den I/O-Adressen illegale Werte liegen können. Die Werte wurden zwar gesichert (daher kann man zwischen Write+Paint wechseln), aber das die Werte negativen Einfluss auf Kernal-I/O haben ist seit den letzten Releases wohl keinem aufgefallen. Nutzt wohl keiner 
Unter VICE mit einer SuperCPU+RAMLink tritt der Fehler auch nicht auf, passt also auch zur realer Hardware. Da wird ein indirekter Sprung zu $(D20A) ausgeführt, dort steht $F35A und das geht wohl problemlos.
Ich hab jetzt einen neuen SnapShot hochgeladen... Vorab "Sorry" falls eines der DiskImages nicht funktioniert. Sind 8 Versionen und dann noch D64/D71. Sind schon zwei Monate her seit dem letzten Update... und ich werde alt, da fängt man langsam an die Release-Schritte für so ein altes System zu vergessen
Der neue SnapShot sollte das Problem mit der RAMLink+GeoWrite+TaskManager beheben.
Bei MP128 bin ich mir nicht sicher ob das Problem dort auch existiert, ich hab keinen 128er (will ich auch nicht) und VICE unterstützt wohl das CART-System noch nicht (oder ich hab was verpasst).
Ich hab mir den Shadow/Trap-Kernal vom 2.01er ramlink.bin angteschaut, der Code ist ähnlich dem 64er-Kernal. Und GeoWrite128 nutzt auch die Adressen $94/95.
Ich hänge daher zum testen mal ein D81 mit einem GeoWrite-Text an:
- Dokument öffnen, Cursor am Anfang der Seite -> TaskManager startet über CBM+CTRL
- Cursor an das Ende des Textes/Zeile#2 setzen -> TaskManager crasht nach CBM+CTRL
Das Problem dürfte seit Nov.2020 enthalten sein, dort wurde im Laufwerkstreiber zusätzlicher Code zum abschalten des ser.Bus ergänzt. Das Problem tritt auch nur exklusiv mit RAMLink ohne SuperCPU auf. Reine RAM-Laufwerke wie RAM41 waren davon nicht betroffen, nur physische Laufwerke inkl. RAMLink.
Wer das also testen will entweder von D81 direkt oder von einem 1541/71/81/SD2IEC/FD/HD/RL-Laufwerk.
P.S. 3.3r8 sollte davon nicht betroffen sein. Zum testen braucht es einen älteren r9-Snapshot.
Ich hab jetzt einen neuen SnapShot hochgeladen...
Den beschriebenen Fehler habe ich nicht expizit nachgestellt , aber der neue Snapshot läuft hier problemlos (MP3-64 und MP3-128). Danke.
Ich möchte aber noch auf ein anderes Thema (MegaAssembler; siehe hier: MegaAssembler V3.7 im Quelltext verfügbar ) hinweisen. Ist da schon was passiert?
Gruß
Werner
Ich möchte aber noch auf ein anderes Thema (MegaAssembler; siehe hier: MegaAssembler V3.7 im Quelltext verfügbar ) hinweisen. Ist da schon was passiert?
Ja... ich nutze den 4.3 seit längerem Problemlos
Oder meinst Du den Code rausgeben? Falls letzteres, Sorry, hab ich vergessen... ich leg das mal für das WE auf den "Zu-erledigen"-Stapel... 
Oder meinst Du den Code rausgeben? Falls letzteres, Sorry, hab ich vergessen...
Jep ;-). Den verbesserten MegaAss gab es ja eh nur als SourceCode.
Deshalb die Erinnerung ...
Gruß
Werner
Gestern den neuen SnapShot Installiert, keinerlei Probleme festgestellt
Mann o Mann, ist mir noch nie aufgefallen, obwohl ich doch viel mit CMD Native mache. Man probiert, man testet und doch gibt's immer mal wieder einen kleinen Fehler, der noch keinem aufgefallen ist.
Aber wie bei allen Programmen, ein 100% tiges wird es nie geben. Aber von Fehler zu Fehler, hangelt man sich immer näher ran........
Wir freuen uns natürlich über jedes neue “Testfutter“.
Gruß Jojo
Hallo und vielen Dank erstmal an alle Beteiligten für all die Arbeit hier! Ich habe mit GEOS nie groß etwas zu tun gehabt, und habe vor kurzem ein FC3-Image mit englischem Geos-Kernel entdeckt.
Nun stellt sich mir als 1541U2-Nutzer die Frage, ob es rein theoretisch wohl möglich wäre, vom Mp3 wohl ein 'voll funktionsfähiges' .crt (EF?)-image zu erstellen... .
Nennt mich faul - aber es ist ziemlich anstrengend sich alles zusammen zu suchen, zu schauen ob es auch wirklich funktioniert, auf MP3 upzudaten...besonders bloß um da mal reinzuschnuppern. Da wäre ein funktionierendes Geos Mp3 als .crt schon eine willkommene Abwechslung.
Scheitert sowas aus Copyrightgründen/kann man das mit vertretbarem Aufwand mit irgendeinem Programm selbst? Oder scheitert das aus technischen Gründen? Gibt es sowas vielleicht gar schon? Vielen Dank schonmal für Infos
Nun stellt sich mir als 1541U2-Nutzer die Frage, ob es rein theoretisch wohl möglich wäre, vom Mp3 wohl ein 'voll funktionsfähiges' .crt (EF?)-image zu erstellen... .
Kurze Antwort: Nein.
Lange Antwort:
Das GEOS-crt das Du verwendest ist nur der pure GEOS-Kernal. Du brauchst ja noch eine Diskette mit Configure/Desktop. Und MP3 braucht da noch viel mehr Speicher als in ein crt passt.
In einem anderen Thread hatte ich mal das GEOS-crt mit einem GEOS64v2+SD2IEC+JiffyDOS verglichen. Fazit: Startet genauso schnell. Der Umweg über das crt ist also völlig sinnlos wenn man ein JiffyDOS-Laufwerk hat. Und ein Laufwerk muss man ja haben, sonst ist das crt erst recht sinnlos.
Man kann aber die REU in der U2 so vorbereiten das Du mit FBOOT von einer 1541-Disk MP3 aus der REU booten kannst. Du must dann halt den Inhalt der REU als Image in der U2 speichern und laden. Dann dürfte das in ein paar Sekunden starten. Evtl. kann man FBOOT auch vom Stick der U2 laden, keine Ahnung. Die Ultimate-Hardware ist nicht so meines.
Wenn Du aber schon GEOS nicht installieren willst rate ich Dir dringend davon ab... GEOS ist über 30Jahre alt und erfordert schon etwas "Grundwissen" und "Einarbeitsungszeit"... das ist kein Windows für den C64. Auch wenn das Video hier sowas vermuten lässt...
Ich sage mal so:
Früher war es noch etwas Komplizierter eine Geos-Kopie zu erstellen, man brauchte GeoMakeBoot. Aber in Heutigen Zeiten finde ich es Totalen Quatsch, sich mit dem FCIII eine Kopie zu erstellen, die dann ohne eine Diskette mit den Dazugehörigen Dateien nichtmal funktioniert.
Die Zeiten haben sich Geändert. Vieles ist Einfacher Geworden.
Es gibt in der Wolke fertige uninstallierte Geos-Images. Und so kompliziert ist die Geos-Installiation nicht, das der Aufwand Lohnen würde.
MP3, Unterstützt sogut wie Jede Hardware , Auch die Installiation von MP3 ist einfacher geworden.
Warum also so einen Umständlichen Weg??
Der MP3 ist in ein paar Sekunden Hochgefahren und Einsatzbereit.
Ich glaube nicht, das 2-3 Sek??. weniger solchen Aufwand Lohnen würden.
Aber das ist NUR meine Meinung........................
Der MP3 ist in ein paar Sekunden Hochgefahren und Einsatzbereit.
Ich glaube nicht, das 2-3 Sek??. weniger solchen Aufwand Lohnen würden.
Seh ich auch so... GEOS-CRT ist ein Relikt aus den 80/90ern... braucht heute kein Mensch... Leider hält sich das CRT aktuell hier im Forum wie eine Seuche... es kommt immer wieder nach oben.
bei MP3 setzte ich das mal auf die ToDo-Liste. Wird also evtl. einen weiteren SnapShot geben...
Hatte es schon vermutet... MP128 macht hier Probleme.
Hab den Fix in den Code eingebaut und MP128 lässt sich nicht mehr assemblieren.
MegaPatch ist ja eigentlich durch... der Fehler ist in den letzten 20Jahren keinem aufgefallen. Daher wird es wohl darauf hinauslaufen das es unter MP64 behoben wird und unter MP128 in die Rubrik "Bekannte Fehler" fällt.
Ich schau mir das nochmal an, für MP128 hab ich da aber wenig Hoffnung.
Selbstverständlich wäre es ganz toll, den MP3 aus einem Modul oder Eprom zu Laden,
Einschalten und fertig............
Aber ich denke, die Nachteile Überwiegen hier.
Wenn ich an die vielen Verbesserungen und Updates denke,
(für die wir auch alle Dankbar sind)
würde man mit Brennen Wohl niemals fertig werden.
(falls das von der Größe Überhaupt machbar wäre?? )
keine Ahnung, ist auch Irrelevant............für mich
Ich Denke, und da gibt mir wohl Jeder Recht. Wozu also???
Von Diskette laden macht hier wohl mehr Sinn....................
Noch einfacher gehts nun wirklich nicht mehr................
Gideon hat dazu eine pragmatische Idee - fragt sich bloß, in welcher Firmwareversion die auf der U2+ / U64 verwirklicht wird:
So eine Art Batch-Datei, mit der man eine Datei in die REU lädt [kein Geheimnis, dass die das gesamte MP3 als Ramdisk beinhaltet kann] und dann den FBOOT per DMA lädt und startet.
Voila, MP3 wäre gebootet...
Ich füge mal hinzu: Warum nicht dazu noch eine Autoexec Batch-Datei?!
Jedenfalls hätte man das dann - ohne Zeit in ein MP3 CRT Feature zu stecken - sondern man kommt mit generischen Funktionalitäten aus.
