Ich verstehe diese Zeile aus Gideons Code nicht:
https://github.com/GideonZ/154…ftware/6502/eapi.tas#L381
Wohin geht "beq ++" genau - ich finde kein solches Label. Jedenfalls vermute ich da den Fehler.
Beiträge von markusC64
-
-
Die Tatsache, dass das CRT mit Spielstand auf vielen Systemen nicht lädt, deutet drauf hin, dass irgendwo mal der falsche Speicherbereich überschrieben worden ist.
Nun ist ja leider nicht dokumentiert, wo in dem CRT die Savegames liegen, ansonsten könnte man mal einen File Compare machen und schauen, ob wirklich nur die Unterschiede dort sind, wo die Savegames liegen sollten.
Die Ultimate verwendet übrigens diese EAPI https://github.com/GideonZ/154…er/software/6502/eapi.tas für den Easyflash. Zusdammen mit einer darauf angepassten (virtuellen) Hardware.
Gerade in meinen E-Mails gesehen: https://github.com/GideonZ/1541ultimate/issues/495
Es ist also in etwa genau das, was ich vermutet habe...
-
Wo wir uns gerade Tipps zu passenden Netzteilen / Ladegeräten geben - für die Fans eines ultrakompakten Netzteils kann ich
https://www.amazon.de/Baseus-L…chwarz/dp/B0DG5JZ99P?th=1
empfehlen. Gerade per USB PD Trigger ausgelesen, was das wirklich kann: 5V 3A, 9V 3A, 12V 3A, 15V 3A, 20V 2.25A, PPS 3.3V-11V 3A, PPS 3.3V-16V 3A.
Edit: Vielleicht sollte ich einen Testbericht dazu verlinken?! https://techtest.org/das-kompa…et-im-test-baseus-picogo/
-
Wenn man die Cartridge, ohne vorher einen Spielstand zu speichern, auf dem U64 sichert, dann ist diese CRT Datei bis auf 2 vertauschte Bytes an einigen Stellen mit der originalen CRT Datei identisch.
Wenn ich mich in https://vice-emu.sourceforge.io/vice_17.html nicht mit den Spalten in Deinem Hexdump verzählt habe, so sind die Unterschiede:
* Total packet length: Benutzt der Ladevorgang eh nicht(?) - dennoch solte man mal schauen, woher die ABweichung kommt
* Bank nummer (sic!), das gefällt mir nicht so gut. Muss aber nichts heißen, die Banks könnten in einer anderen Reihenfolge gespeichert sein - und duplizierten Inhalt aus technischen Gründen enthalten, so dass es nicht auffällt.
-
So lässt sich nicht direkt sehen, ob da vom U64 vielleicht Programmdaten vom Savegame überschrieben wurden.
Streategischer Fehler, man muss es mittels Cartconv (liegt bei Vice dabei) in eine BIN-Datei umwandeln, damit man sinnvoll vergleichen kann.
Und das eigentliche Problem vermute ich, wenn der Savegame-Bereich aufgebraucht ist und der im Hintergrund automatisch gelöscht wird. Wäre es nämlich anders, müsste es bereits sehr früh schiefgehen, tat es aber offenbar nicht.
-
Naja aber irgendwas muss ja bei dem oben angehängten CRT schon nicht stimmen
So ist es, und im #23 habe ich dazu auch eine Hypothese geäußert, und in #27 den Quelltext nachgereicht. Da eine andere EAPÜI vom C64 ausgeführt wird, besteht die Möglichkeit, dass so was passiert.
Auch wenn mir aktuell kein Schlupfloch bekannt ist, wie das passiert. Das Ergbenis haben wir ja, dass wir ein nicht funktionierendes CRT haben...
-
Die Ultimate verwendet übrigens diese EAPI https://github.com/GideonZ/154…er/software/6502/eapi.tas für den Easyflash. Zusdammen mit einer darauf angepassten (virtuellen) Hardware.
-
Die Tatsache, dass das CRT mit Spielstand auf vielen Systemen nicht lädt, deutet drauf hin, dass irgendwo mal der falsche Speicherbereich überschrieben worden ist.
Nun ist ja leider nicht dokumentiert, wo in dem CRT die Savegames liegen, ansonsten könnte man mal einen File Compare machen und schauen, ob wirklich nur die Unterschiede dort sind, wo die Savegames liegen sollten.
-
[Externes Medium: https://www.youtube.com/watch?v=ehsIO6Gp3Is]
PS: Angesehen habe ich das selber noch nicht, aber es beantwortet immerhin die Frage, wie man das mit einer 1541 Ultimate II* oder einem Ultimate 64 als Modem einrichtet. -
Irgendwie bin ich über Dein Posting hinweggekommen. Nun ja, besser eine späte Antwort als keine.
Das liegt daran, dass der LFN Code in den SD2IEC Code nur reingehackt ist. Und der erkennt in der Situation nicht, dass er einen LFN hätte machen sollen, um die Kleinbuchstaben darstellen zu können. Sobald da enthaltene Zeichen, Anzahl Punkte oder Länge den LFN erzwingen, klappt es.
Naja, fast, heute gab es da einen Fehler zu suchen:
@"xe2
new
10 print"hello world"
←".file12345.m"
geht vermutlich bei allen Releasefirmwareversionen gründlich schief. -
Poldi There's obviously a new compiler for the sd2iec firmware on ubuntu. Github fails to compile the XS-1541:
from src/d64ops.h:29,
from src/doscmd.c:31:
src/doscmd.c: In function ‘parse_doscommand’:
src/doscmd.c:1577:55: error: array subscript is above array bounds [-Werror=array-bounds]
fast_get_byte = (fastloader_rx_t)pgm_read_word(&(fl_rxtx_table[index].rxfunc));
^
src/doscmd.c:1578:55: error: array subscript is above array bounds [-Werror=array-bounds]
fast_send_byte = (fastloader_tx_t)pgm_read_word(&(fl_rxtx_table[index].txfunc));
^
make[1]: *** [scripts/Makefile.main:370: obj-m644p-XS-1541/src/doscmd.o] Error 1
-
Als jemand der keine Ahnung von Technik hat, muss ich mal fragen was das für eine steckbare Karte/Modul ist?
Sehe ich es richtig, dass das der eigentliche Computer ist, der den C64 nachbildet?
Falls ja, warum ist das steckbar und somit austauschbar?
Lassen wir Gideon doch mal auf die Frage antworten:
The board function has been split in a base board with mostly connectors for C64-I/O, like keyboard, joysticks, cartridge port, serial port, analog video. Of course the Ultimate64 ports are also there; USB, Ethernet and HDMI. The 'brains' of the solution is placed on a separate board, which is only 7x7 cm in size. This allows different form factors in the future, using the same FPGA module.
Und wenn wir schon dabei sind, übersetzen wir das gleich noch maschinell:
Die Funktion des Boards wurde in eine Basisplatine mit den meisten Anschlüssen für C64-I/O aufgeteilt, wie z.B. Tastatur, Joysticks, Cartridge Port, serieller Port, analoges Video. Natürlich sind auch die Ultimate64-Anschlüsse vorhanden: USB, Ethernet und HDMI. Das 'Gehirn' der Lösung ist auf einer separaten Platine untergebracht, die nur 7x7 cm groß ist. Dies ermöglicht in Zukunft verschiedene Formfaktoren unter Verwendung desselben FPGA-Moduls.
-
Ich zitiere das hier nicht - aber Du hast im Github Antwort bekommen. Die Kurzfassung: Es ist genau so, wie wir uns gedacht haben.
-
Na, das erklärt doch einiges.
Abhilfe schafft hier "RAMDisk bei jedem System-Neustart löschen" im GEOS.Editor wenn man die RAMDisk installiert
Oder man coded sich ein C64 Programm, welches die komplette REU löscht (d. h. mit $00 überschreibt). Das kann man dann vorher starten. Ist sowieso manchmal nützlich.
-
Der Inhalt eines D64/G64 wird doch auch irgendwo in den Flash-Speicher gelesen, oder? Kann es da Überschneidungen mit dem Speicher für die REU geben?
Eine berechtigte Frage. Eigentlich sollte Gideon das Memory Management passend haben. Jedoch kann man ja einfach mal Diskimages einladen und dann den REU Speicher abspeichern lassen. Wenn es da was wäre, müsste es im REU Speicher ja auftauchen.
Ersetze Gideon durch meinen Namen und GEOS durch Ultimate
Logisch.
Naja... zumindest ramBase steht bei einer B:RAM81 auf $01 was für Bank#1 stehen würde, das wäre also so wie unter GEOSv2/MP3 auch. Wheels könnte also gehen...
Weil man per Ultimate auf den C64 Speicher nur sehgr erschwert zugreifen kann, wird statt dessen der Speicher in der REU zur Erkennung genommen. Wegen rboot etc. wird der Teil ja in der REU auch gespeichert damit daraus für rboot der entsprechende Teil wiederhergestellt werden kann. Und jetzt kommt das ABER: Ändert man was an den REU Block, der dazu genommen wird, ist das auf einmal wo anders. Da reicht schon selbe Offsets in anderen REU Block.
Unter gateWay steht dort $ff,$ff,$ff,$fe... wenn das die Firmware als "Startadresse" innerhalb der REU interpretiert, dann kann das laden nicht funktionieren. Sieht eher nach einer Art Bank-Tabelle aus, jedes Bit steht für 64k. 1=Belegt.
Was belegt, dass dort mehr geändert ist...
warum MP3 beim laden des DeskTop aus dem Cache abstürzt (es wird nur der erste Block geladen, die Link-Bytes sind nach der Initialisierung = 00,00).
Zu viele Ungewissheiten. Wir können ja nicht jede irgendwie verfügbare Version von configure durchprobieren. Wenn da eine von auch nur minimal anders in die REU schreibt, könnte der Absturz ja wiederum entfallen.
Ich stimme Dir zu: Es braucht mehr Details. Sowohl im Text als auch meinetwegen im Anhang, die Diskimages könnte der User ja beifügen, damit man über die nicht rätseln muss. Es ist zwar nicht immer ganz einfach zu sagen, was da dann wirklich drin ist, insb. wen/falls gecrackte Versionen beteidigt sind. Aber ok. muss man vielleicht auch nicht. Wenn man es nachstellen kann, kann man Zwischenstände von RAM und REU prüfen etc.
-
Gateway != MP3/GEOS2.x, auf den ersten Blick scheint ramBase anders genutzt zu werden. Man kann daraus also nicht schließen wo im GEOS-DACC die RAMDisk liegt. Irgendwie muss der Treiber das ja aber wissen, müsste sich jemand genauer anschauen...
Nun ja, den Teil lassen wir erst mal außen vor, der hat mehr von einem Feature Request als von einem Bug. Durch den Klammervermerk "(MP3)" schreibt der User ja selbst, dass das Feature eigentlich für MP3 ist.
Wenn wer Gateway sagt, kommt als nächstes die Frage nach Wheels (geht das eigentlich? Ich fürchte nicht).
-
Ich habe mich schon gefragt, ob da Typ 1541 Shadow irgendwie reinspielen kann. Das dürfte zwar prinzipell unvollstädig sein, weil man in der Regel doch nicht alles lädt, aber solche Kandidaten wie Desktop und Directory sollte man schnell im Shadow haben. Allerdings hast Du Recht durch Geos laden allein könnte das evtl. nicht passiert sein.
Und ob der User jeden Dateiinhalt kontrolliert hat, das wage ich zu bezweifeln.
Allerdings reichen meine Geos-Kenntnisse nicht aus, um die Möglichkeit zu Ende zu prüfen. Bei Fragem, was wo in der REU landet, damit es anschließend ein anderes Programm wieder findet, da spielt ja doch ziemlich viel rein.
So wenig, wie in dem Bug Report steht, kann man zumindest nicht ausschließen, dass der Benutzer "1541 Shadow" verwenden könnte.
Und jetzt stell Dir das Ganze mal aus Sicht von Gideon vor, der sich mit GEOS überhaupt nicht auskennt.
Und sowieso: Wie unvollständig ist der Issue eigentlich? Firmwareversion? Unbekannt. Geos Konfigurationsdetails? Unbekannt! Eventuelle weitere Autostarts auf der Startdiskette? Wer weiß, der Issue Leser jedoch bestimmt nicht.
-
Hallo zusammen,
auf https://github.com/GideonZ/1541ultimate/issues/487 habe ich gefunden:
The content of previously mounted 5.25" disk appears in Geos MegaPatch 3 RAM1541 (Issue #487)Reproduction step;
I set the configuration in U2+:
- DriveA 1541, DriveB OFF
- REU2MB
I load System Geos 2.0 in the configuration: DriveA 1541, DriveB RAM1541.
I change the configuration in U2+ to:
- DriveA 1581, DriveB OFF
- REU 16MB
I load Geos MegaPatch3.3 in the configuration: DriveA 1581, DriveB RAM1541....
....and suddenly Desk Top 2.0 from Geos2.0 appears because the contents of the System Geos 2.0 disk appear in RAM1541. 🎉
When using Geos 2.0 we can change the disk in DriveA to another one in U2+, then it will appear in RAM1541.
All with JiffyDOS, but that doesn't matter, I guess.
As for the option of saving to file and loading from file for RAM Disk (MP3) implemented in #316
It works for me correctly for both, Geos 2.0 and MegaPatch 3.3.
It does not work correctly for CMD gateWay.
Ich habe den Eindruck, Gideon kann damit nicht allzu vuiel anzufangen wissen... Können wir ihn mal unterstützen und herausfinden, was es damit auf sich hat? Erster Eindruck ist jedenfalls: Wird wohl kein Fehler sein. -
-
Halber Punkt für Dich. Die Floppy schließt den Kanal, der C64 hat den in seinen Datenstrukturen noch offen.
