Dieser Bug wurde schon auf Facebook angesprochen - schon blöd, dass ihn Gideon selbst in der V1.21 nicht behoben hat.
Hallo Besucher, der Thread wurde 58k mal aufgerufen und enthält 449 Antworten
letzter Beitrag von eisdielenbiker am
Ultimate 64 Boards, der "das läuft noch nicht"-Thread
-
-
Ich poste es nochmal hier rein, da ich ad hoc den anderen Thread, in dem ich das Problem schonmal angesprochen hatte, nicht wiederfinde:
Und zwar gehen Medien grösser als 32 GB ständig korrupt - habe sowohl eine SD-Karte im Reader als auch einen USB-Stick mit 64GB probiert. Zunächst dachte ich, es passiert nur beim Beschreiben weiterer Daten via FTP auf diese Medien.
Nun habe ich den gut befüllten Stick absichtlich in Ruhe gelassen - und wieder ist es passiert, dass der "CSDB"-Ordner des Assembly Downloads völlig hinüber ist.
Die Ordnerbezeichnungen sind nur noch Datensalat.
Der Stick steckt am inneren USB Port.Geht Euch das auch so? Hab ich Pech? Hat vielleicht der Anschluss 'ne Macke?
Am externen Port mit 32GB Medien ist das bisher nicht passiert.
Klar, jetzt kann man argumentieren, reichen Dir die 32GB nicht?
Prinzipiell natürlich, aber mein Traum wäre gewesen, eben ALLES was ich habe plus Luft für künftige Assemblydownloads alle intern zu haben...
Aber irgendwie wird das nix. -
Dieser Bug wurde schon auf Facebook angesprochen - schon blöd, dass ihn Gideon selbst in der V1.21 nicht behoben hat.
Und hier ist schon mal der Quellcodefix: https://github.com/GideonZ/1541ultimate/pull/97 - der Fix aus der Version 3.4c passt noch immer.
Und zwar gehen Medien grösser als 32 GB ständig korrupt - habe sowohl eine SD-Karte im Reader als auch einen USB-Stick mit 64GB probiert.
Hm, um das weiter einzugrenzen, müsste man mal die größere Clustersize, die FAT32 eben auf solchen Medien verlangt, auf kleineren Medien ausprobieren.
Idee: Dann weiß man, ob es die Mediengröße oder die Clustersize ist. -
Idee: Dann weiß man, ob es die Mediengröße oder die Clustersize ist.
Und wie kann man das Ändern? Ich weiss auch nicht, ob das Problem ggfls. erst nach einem Füllstand X passiert. Und den Stick immer wieder so voll zu kopieren dauert wirklich eeeeeewig. -
Mit einem geeigneten Windows-Programm zum Formatieren: https://github.com/0xbadfca11/fat32format
(Linuxbenutzer werden eh wissen, dass das normale "mkfs.fat32" dafür Optionen bietet, daher keine Infos dazu.)
-
Und wie kann man das Ändern? Ich weiss auch nicht, ob das Problem ggfls. erst nach einem Füllstand X passiert. Und den Stick immer wieder so voll zu kopieren dauert wirklich eeeeeewig.
Wenn alles auf dem Stick ist einfach ein Image davon ziehen (z.B. mit Win32DiskImager oder Etcher). Das Image zurückschreiben geht sicher schneller als zigtausende von kleinen Dateien einzeln zu schreiben.
-
Edit: Obiges, falls Du das Modul geflashed hast. Ansonsten kannst Du Module auch aus dem Dateibrowser heraus direkt starten, ohne jene zu flashen.
Vor diesem Hintergrund verstehe ich die 16k-Aussage nicht.
Flashen funktioniert gar nicht - gibt eine Fehlermeldung. Und auch das direkte starten eines .CRT tut es nicht - zumindest ist ein AR6, Action Power,.. nicht lauffähig.
Deswegen habe ich das gar nicht mit erwähnt gehabt diese Optionen.Anm.: Normale 8K, 16K Game Cartridges laufen dagegen sicherlich und auch Zeugs für Easy Flash.
Ich meine einzig diese Freezer Cartridges Images wollen mit dem U64 nicht richtig laufen. -
Ich meine einzig diese Freezer Cartridges Images wollen mit dem U64 nicht richtig laufen.
Weiß da eigentlich endlich 'mal jemand, ob denn das überhaupt machbar ist ? --> da diese Cartridges ja z.T. ein eigenes Ram (das Action Power hat 32KB Ram zum 32 KB Rom oder so in etwa verbaut) verbaut haben. (Das Ram wird dazu genutzt, damit der eingebaute Assembler etc. keinen Speicherplatz im / des C64 selbst verbraucht, und auch der Schnellader nicht.)
Dieses Ram müsste ja dann auch erstmal emuliert/simuliert werden vom U64, damit das geladene Rom dieses auch sieht und damit arbeiten kann. Tut das das U64 ? Wenn nicht, dann kein Wunder dass diese nicht laufen.Aber wie hat Gideon das dann mit dem Cyberpunkx Rom und auch den AR 4 + AR 6 Rom gemacht, welche das U64 schon mitbringt ? Inwiefern sind diese für die U64 Hardware angepasst worden, lauffähig gemacht worden ? Denn diese laufen ja.. . Also wird das Ram eines AR6 durchaus emuliert ?
-
Da das U64 auch eine REU simulieren kann (soweit ich weiss), denke ich, dass RAM an der Stelle keine Mangelware sein sollte
-
Ja, nur muss es auch genauso wie beim original Modul eingebunden und "verdrahtet" sein. An selber Speicherstelle und vlt. noch mehr. Nur (das im Übermaß vorhandene) Ram dranklatschen reicht nicht, damit läuft noch gar nichts.
Wenn nicht, dann kein Wunder dass diese nicht laufen.
Allerdings hat das reale Modul dieses ja alles und selbst das läuft nicht am U64 Expansion Port (siehe Post 414). Aber immerhin schonmal bis zum Startbildschirm-Menü des Action Power läuft es.
Wie macht sich ein reales Action Replay 5 oder Action Replay 6 Modul am U64 Expansion Port, läuft das denn oder ebenfalls nicht ? Kann das 'mal jemand testen ? Interessiert mich nur 'mal.. . -
Also die Images von Action Replay VI, die hier auch als gepatchte Varianten unterwegs sind, die sofort in den Speedloader springen anstatt das Menu zu zeigen, kann man auch nutzen anstatt das von Gideon eingebaute Modul - diese Images lassen sich auch direkt aus dem Filebrowser heraus starten und müssen nicht extra geflashed werden.
Ein echtes MK VI verhält sich auch so, wie es soll. Es kommt hin und wieder jedoch zu Problemen beim Freeze, dass sich das U64 dabei aufhängt. Da vermag ich aber nicht zu sagen, ob das generell ein Problem mit dem Freezen ist (also passiert auch mit den emulierten Cartridges) oder ob sich in manchen der Fälle auch ein originaler 64er abgeschossen hätte - meine mich zu erinnern, dass das Freezen öfters mal daneben ging...
Die Action Power V8.1 Cartridge bekomme ich aber auch nicht ans Laufen, crasht das U64.
Im Anhang einmal ein Capture mit originalem Action Replay VI und einmal mit einem aktivierten und gepatchten ROM.
-
Danke für's Testen. Dann scheint das Problem ja nur diese (meine gewohte und u.a. daher favorisierte) Action Power Cartridge zu betreffen. Melde das trotzdem 'mal jemand Gideon !
(Falls er denn so eine Cartridge zum Testen herumfliegen hat bei sich.)
Ich meine mich zu erinnern, dass da ggf. nochmal etwas besonderes/anders mit war - hardwareseitig im Modul, als beim AR6. Oder auch nicht.Mal ein Nordic Replay, oder Retro Replay mit diversen (u.a. Action Power) Roms zum Testen zur Hand jemand ?
Die AR6 Images die ich so habe laufen aber alle nicht im U64, im Gegensatz zu bei dir. Aber das ist jetzt damit nicht mehr so wichtig.
-
Finde bei der Menge an Threads auch grad wieder nicht den wieder, wo die gepatchten ROMs ursprünglich released wurden.Hier ist mein kleines Archiv, was ich mir selber angelegt hab - auch inkl. des Modul-Manuals.
P.S. Sorry für das Brett an Anhängen, aber gibt leider ein Filesize-Limit bei 500kb.
-
Hab' ich soeben heruntergeladen und entpackt. Thx !
-
gestern mal meinen C64G komplettiert und das Demo laufen lassen - läuft,
[Externes Medium: https://youtu.be/wwDR0lR3NP4]Mit dem Ultimate64 läuft die Musik durch, aber der Rand flackert nur rot. Die 1541 läuft am C64 an und lädt die Grafiken. Das U64 lädt weder von der realen 1541, noch vom Stick nach.
-
Mit dem Ultimate64 läuft die Musik durch, aber der Rand flackert nur rot. Die 1541 läuft am C64 an und lädt die Grafiken. Das U64 lädt weder von der realen 1541, noch vom Stick nach.
Ab welchem Part tritt der Fehler auf?Ah, konnte den Fehler reproduzieren. Bitte deaktiviere das zweite Laufwerk. Der Loader verträgt sich nur mit einem Drive. Wenn Drive B deaktiviert ist, läuft es bei mir problemlos.
-
Muss ich nachher mal testen, Da habe ich mal wieder den Wald vor lauter Bäumen mich gesehen.
Vielen Dank.
Edit: yeahhh! Geht! Danke nochmal.
-
Bei mir mag die Demo auch nicht ein Jiffy-DOS als alternatives Kernel für die 1541-II. Dann kommt auch das rote Flackern.
-
Kernel C64: Original
Kernel 1541: Original
1541 ist einziges Gerät am IEC-Bus
Interne Laufwerke des U64 sind inaktiv
Damit sollte es gehen.
-
Kernel C64: Gepatched
Kernel 1541: Original
1541 Emulation ist einziges Gerät am IEC-Bus
Kein echtes Drive am Bus*.
(*Übrigens: Wie ich ganz zu Anfang mit dem U64 feststellen musste (und es wohl auch bei vielen Originalboards so ist: Es genügt schon, wenn das Datenkabel steckt. Ob eine echte Floppy dahinter ist und ausgeschaltet ist, ist egal...)
Wollte mit meinem vorherigen Post eigentlich nur sagen, dass es mit dem von mir verwendeten Jiffy-Kernal in der 1541-Emulation auch nicht hin haut und das Original-Kernal eingestellt sein muss/sollte.