Posts by markusC64

Quote from Freak

der Bildschirm wird schwarz (vielleicht aufgrund der VIC2-Initialisierung ohne $D020 und $D021)

Das ist ein Feature, welches wir an anderer Stelle eingebaut haben: Bei einem Reset mit Rekonfiguration des Expansionsportes werden $D011 und $D020 beide per DMA auf 0 gesetzt. Damit Final Cartridge 3 einen Kaltstart erkennt statt einen Warmstart. Der Einfachheit halber bei jedem solchen Rekonfigurationsreset, nicht nur, wenn besagtes Modul emuliert werden soll.

Ist in https://github.com/GideonZ/154…er/software/io/c64/c64.cc Zeile 825 ff. Ich denke mal, genau das hast Du beobachtet.

Na gut, probiere ich später auch noch mal aus in Hinblick darauf, ob man am Abbruchstatus des Disketenimages, gespeichert als G64, irgendwas über den Fehler erkennen kann.

Im Moment hat aber eine andere Baustelle in der Firmware Vorrang: Es gibt G64, wo das Einladen und dann sofort als D64 abspeichern schiefgeht. Diesmal keine Regression, die älteren Firmwareversionen machen das auch nicht besser. Das mag ich nicht, also will ich das mal optimieren.

Quote from Lynx

Dafür kann man in der 3.10er nicht stabil D64 Images formatieren.

Ich habe das gerade mal nachgestellt - mit den Zusatzinfos aus https://github.com/GideonZ/1541ultimate/issues/243 die im Wesentlichen besagen: Um den Fehler zu reproduzieren, sollte ich Speeddos oder Dolphin DOS versuchen.

Ergebnis: Fehler tritt auf, aber ein vorheriger "@i" hilft.

Ich konnte im G64, welches ich abgespeichert habe, nachdem das d64 den fehler gemeldet hat (man kann ja das aktuelle Image als GCR speichern) entnehmen, dass die Tracks alle an falscher Stelle waren - offenbar waren das ROM und die Mechanik anderer Ansicht, wo der Schreib-/Lesekopf steht. Das @i liest die BAM ein und somit sind danach beide der selben Ansicht...

Trotzdem, so ganz passt das auch nicht... das, was im G64 dann steht, lässt sich nicht ganz erklären.

Mir wird wohl zwischendurch mal danach sein, das Programm auszuprobieren.

Tatsache ist aber, dass Geos MP3 vor meinen Patch von heute kein GeoRAM erkennt... sollte es ja auch nicht, wenn man es nicht angeschaltet bekommt.

Lynx Hast Du mal in Betracht gezogen, dass Dein möchte-gern-Georam.crt "zufällig" eine Hardware emuliert, die genau dort RAM hat, wo GeoRAM einen Block aus der Speichererweiterung einblendet?

Nach der Analyse des Quelltextes ist nämlich relativ sicher: GeoRAM kann die eigentlich nicht eingeschaltet haben.

Gute Nachricht: Nachdem ich mir das Anschalten von GeoRAM in die Firmware reingepatched habe, funktioniert GeoRAM einwandfrei. Was nicht selbstverständlich ist, denn offenbar konnte es niemand vorher testen seit dem Rewrite des Cartrdige-Systems.

Solange ich nichts gefunden habe, was das (durch Quelltext überprüfbar) einschaltet, halte ich Geos ausprobieren für verlorene Zeit. Nun gut, ich hoffe, ich bekomme bald Antwort von Gideon - evtl. auch nur, damit ich weiß, was er beabsichtigt hat.

Währenddessen patche ich mir gleich in die Firmware mal was rein, was das GeoRAM aktiviert. Dann kann ich auch Geos und anderes damit ausprobieren.

PS: Die $1F ist die FPGA interne ID, nicht die vom CRT File - ich bin noch nicht einmal sicher, ob es für GeoRAM überhaupt eine CRT-ID gibt... Beim letzten Mal, als ich nachgeschaut habe, gab es keine, aber das VICE-Team könnte ja inzwischen eine vergeben haben. Die Umsetrzung muss existieren, damit das funktionieren kann. Es gibt die aber offenbar nicht - oder ich übersehe die. Letzteres ist unwahrscheinlich, weil Gideon die Konstanten benutzen will für so etwas.

Genau das habe ch gestern Abend auch noch gedacht und daher nachgeschaut, ob ein Mapping der CRT-ID auf die FPGA interne ID stattfindet, ich habe keines gefunden. Weder mit der obigen Suche per "rg" noch bei einer Inspektion der fraglichen Dateien per Hand...

Mal sehen, was Gideon meint...

Hm, "rg" findet auch nichts - ich suche gerade im Quelltext:

$ rg CART_TYPE_GEORAM

software/io/c64/c64.h

143:#define CART_TYPE_GEORAM 0x1F

Eine Konstante ist da, die nirgends verwendet wird - das ist eher ein schlechtes Zeichen... aber die gute Nachricht: Im FPGA ist der GeoRAM drin, was auch immer es jetzt sein mag, es ist recht leicht korrigierbar.

Irgendwie muss ich gerade ein Brett vorm Kopf haben - ich suche in der 3.10 Firmware die Option, um die GeoRAM Speichererweiterung zu aktivieren und finde jene nicht...

Quote from Freak

Frage: Gibt es vielleicht doch eine Möglichkeit, diesen RAM-Bereich zu beschrieben?

So direkt nicht, weil DMA eingesetzt wird. Und DMA hat nunmal nicht Zugriff auf den 6510 Prozessorport, der den virtuellen Adressen 0 und 1 entspricht. Ja, die sind verschieden von den Adressen 0 und 1 im RAM, auf denen die 6510 nicht zugreift(*), das RAM jedoch selbstredend hat.

(*) Stimmt nicht ganz, hin und wieder sieht man die Adresse auf den Bus, aber dann wird das Ergebnis verworfen.

Quote from Freak

Frage: Gibt es vielleicht eine Möglichkeit über die Ethernet-Schnittstelle den Program Counter vom 6502 zu verbiegen und so den 6502 auf den eigenen Code umzulenken und diesen zu starten?

Nein, DMA hat keinen Zugriff auf den Prozessor, vgl. erste Frage. PS: Der C64 hat einen 6510

Quote from Freak

Wo finde ich im Repository den Programmteil (State Machine oder Code), der für die Auswertung, der über die Ethernet-Schnittstelle übertragenen Befehle zuständig ist?

Eine leichte Frage: https://github.com/GideonZ/154…are/network/socket_dma.cc

Wie Gideon beim DMA-Load via Menü doch hinbekommen hat, ist wie folgt: Modul einbinden, Reset ausführen. Speicherkonfiguration setzen und in der Zeropage (müsste nachschauen, wo - sollte aber irrelevant sein) ein Flag setzen, dass der Code soweit ist. Die Firmware merkt dies per DMA-Polling und überträgt die Software. Anschließend setzt die Firmware per DMA in der Zeropage ebenfalls ein Flag (könnte das selbe sein mit anderen Wert). Der Modulcode wartete darauf und macht dann weitere Ausgaben, deaktiviert das Modul und startet die Software.

Nach ein bisschen Rumprobieren bin ich gerade drauf gekommen, dass Du mittels "@8", "@9", ... das Laufwerk festlegen kannst, welches er für "$" verwendet. Alternativ tut es auch ein "POKE 186,nr".

Ja, die 3.10 mit dem neuen Hyperspeedkernal haben die Erfordernis nicht mehr, dass die U2(+) den Kernalersatz vornehmen muss.

Dafür braucht die 3.10 zwingend den geupdateten Hyperspeedkernal.

Jetzt, wo Du es schreibst - ich bin mir sicher, bei einer neueren Ankündigung etwas von der Umstellung auf WSL gelesen zu haben. Die Version 18.1 wa noch ohne WSL, sondern alles direkt unter Windows.

Ja, eine 20'er sollte es auch run, weil ja "nur" fertige FPGAs und eine fertige NIOS2-App übertragen wird. Da kommt es auf Compiler nicht an - der macht nämlich in der Tat in manchen Versionen Probleme.

Das ist relativ unkritisch mit der Version von Quartus. Gideon nimmt die 18.1, als ich das letzte Mal darauf zu sprechen kam - mit der Version macht man also nichts falsch. Ich bin mir aber sicher, dass ich zuerst mit der 15.1 das Ultimate 64 versorgt habe.

Wenn man von Gideon keine aktuelle Recovery Images da hat (was aktuell der Fall ist), nimmt man den FPGA Blob von der Version 1.29. Am einfachsten ist der Weg über die NIOS2-Kommandozeile. Damit kopiert den FPGA rüber mit

nios2-configure-sof u64.sof

und hält die Restore-Taste an der C64 Tastatur gedrückt, bis der FPGA vollständig übertragen ist. Das verhindert bei dem nicht mehr ganz aktuellen FPGA den Start der Applikation vom Flash, denn jene kann im Flash ja defekt sein.

Anschließend überträgt man die Applikation mit

nios2-download -g ultimate.elf

und wenn alles normal läuft, sollte danach das U64 wieder bedienbar sein, so dass man jetzt ganz normal die Firmware flashen muss. Ja, das ist notwendig, weil die zuvor genannten Schritte den Flashinhalt nicht anrühren - außer dass die Applikation eventuell die Konfig anfasst.

Die beiden Dateien "u64.sof" und "ultimate.elf" kannst Du von mir bekommen.

Das wird voraussichtlich länger - ich gönne uns mal einen eigenen Thread dafür.

Das Wiederherstellen an sich ist möglich, allerdings nicht ganz so einfach. Man braucht einen sog. "USB Blaster" dafür. Sowie die Software "Quartus Lite" von Altera/Intel (Intel hat Altera vor einigen Jahren aufgekauft).

Hast Du das zur Verfügung?

Edit: Und bitte nicht das Recovery aus Gideons Github "ultimate_releases" ungeprüft verwenden, das ist für U64 bis zur Hardwarerevision 1.3. Für neuere nicht verwendbar.

Quote from Thunderblade

Ist in der 1541U-Firmware eigentlich noch der MOD-Player enthalten?

Soweit ich wei0: Ja.

Quote from Thunderblade

In Zusammenarbeit mit dessen Autor, "Freshness", hatte ich allerhand nicht korrekt spielende MODs gefunden und er hat in viel Kleinarbeit rausgefunden woran das lag und den MOD-Player verbessert.

Irgendwie muss es doch möglich sein, die aktuelle Version da rein zu bekommen...

Quote from Thunderblade

Ist die neue Version in der neuen FW enthalten?

Ich habe zumindest davon kein Commit gesehen, also fürchte ich: Nein.

Quote from marty

Achtung, beim alten U2 musst Du zum downgraden ein Sprung auf eine ganz alte Version 3.06b machen und von dort kannst Du dann wieder auf die 3.7. markusC64 korrekt?

Korrekt. Oder die 3.9 Beta - Thunderblade hatte zwischendurch mal eine solche 3.9 Beta bekommen...

Mein SD2IEC hat dafür einen Tapeportanschluss. Aber ein SD2IEC mit USB Anschluss für Stromversorgung habe ich auch noch, das geht damit auch, nur habe ich das dort nicht angeschlossen.

Geht völlig problemlos, an meinem U64 habe ich ein SD2IEC permanent angeschlossen.