Posts by markusC64

  • FPGASID im Ultimate 64

    Quote from Bulli_

    Konfiguriert habe ich den FPGASID mit ConfiGuru. Nur so konnte ich Modus A und B einstellen. Die UltiSIDs habe ich ganz deaktiviert.

    Modus A ist bei mir SID1 8580 D400 und SID2 6581 D400.

    Modus B ist bei mir SID1 8580 D400 und SID2 8580 D420.

    Darauf würde ich mich nicht verlassen wollen. Die Ultimate 64 Firmware schreibt bei bestimmten Gelegenheiten eine neue Konfiguration in den FPGASID (speichert sie aber nicht als A oder B ab) - nämlich die Konfiguration, die per Konfiguration des U64 eingestellt ist.


    Ansonsten hast Du das aber perfekt angeschlossen, die Adapterplatine von dukestah macht (wenn ich nichts übersehe) auch nichts anderes (edit: außer dass die P7 weglässt). Ich würde es auch nicht anders machen, wenn ich einen(!) FPGASID einbauen möchte. Nur möchte ich zwei FPGASIDs einbauen...


    Würde mich mal interessieren: Erkennt die Firmware diese Anschlussvariante zuverlässig als "FPGASID dukestah"? Edit: Müsste sie eigentlich.

  • Woran erkennt man Action Replay v6 ?

    Eigentlich unterscheiden sich die AR Module ab Version 4.2 nur durch den Inhalt des PROMs, welcher problemlos durch ein 27256 Eprom ersetzt werden kann. So könntest Du ein Modul zur Not upgraden.


    Ich bin noch nicht dazu gekommen, folgendes auszuprobieren. Jedoch ist es lt. Doku möglich, ein "Nordic Replay" zu nehmen (gibt es neu bei icomp) und darauf einfach ein Action Replay 6 ROM zu flashen. Und schon hat man ein AR 6 Nachbau. Eventuell auch eine Alternative, die es zu bedenken gilt.

  • 1541 "Ultimate" Infos & Fragen

    So weit, so gut. jedoch wäre es doch sinnvoll, wenn die Logik im FPGA dann, wenn nichts auszugeben ist, den besseren Zustand herbeiführt, den Du beobachtet hast bei auf 0 gestellter Lautstärke?


    Ich denke schon, dass das sinnvoll wäre.

  • Quellcode mit unbekannter Syntax

    Quote from Endurion

    Die grundlegenden Sachen sind ja wirklich einfach.

    Dachte ich auch mal - und dann sind mir (im letzten Jahr?) die original Commodore Quelltexte üner den Weg gelaufen. Deren Assembler, der auf einen PET ausgeführt werden muss, erlaubt wohl Labels, die mit einer Ziffer beginnen. Solche Details sind es, die eine Konvertierung aufwendig machen.

  • 16k bzw. 24k Kernal

    Quote from FeralChild

    attaching a CRT means he can't attach any more cartridges, right

    That's something to fix in a later firmware relase - currently for 16k kernals the memory reserved for cartridge ROM is used - kernal area has been too small. So up to recent, that (crt usage) was no restriction, because cartridge ram was allocated anyway.


    And Gideon plans to resolve that problem in the next but one firmware. The kernal ROM area has been enlarged already. The area in the flash has to be enlarged, it is not done yet.


    But this would require flash reorganisation and the user to flash roms again - just in order to realize that the firmware update following would require to do that again.

    But you are right - in order to be able to flash the kernals, I prefer .bin or .rom files, too. They do not need conflict resolution with cartridges.


    I think we can understand why Gideon avoids that two successive firmware versions require reflasing of all roms.

  • 16k bzw. 24k Kernal

    Yes, after making it output via $00, of cause.


    And no, that is not the solution I would prefer - but the classical 64'er DOS v4 kernal is written for that bank switching logic.


    Gideon announced a rewrite of module handling. I think that larger kernal handling will be part of that.


    PS: Current firmware release for U2 and U2+ can handle 16k kernals, but have a bug: RAM behind kernal is switched with bank switching, too. The new commit fixes that bug and also prepares for 24k kernals, i. e. everything except bank switching logic is already done. As written, from CRT only supported.


    PPS: It is easier for the user to load a CRT - because it is configurationless. Just loading CRT is sufficient. But creating such CRT is harder, that is true.

  • 16k bzw. 24k Kernal

    No, 16k kernal use the classic switching logic from 64'er magazine from last century. That is the datasette sense line.


    For 24k kernal, we need a decision, that is true.


    And you are right - NMI (or IRQ if not masked) can make that magic sequence not being recognised depending on the implementation.



    I state (without discussion) that the classic variant has to be supported in addition to what we decide here. And up to now I found no way to include the information in CRT type EXOS if classic or new variant to be chosen, so the new variant mmight only apply to 24k kernals - which is no problem. You can duplicate a bank in the CRT if you like a 16k kernal to be used wirh to new bank switching.

  • Ultimate 64 Fragen zur Firmware - neue Releases

    Genauso, wie Du ein D64 oder G64 lädst: Die Datei im Filebowser suchen und per RETURN auswählen. Gor wird ein Menüpunkt zum Installieren des Updates vefügba sein, den Du wirklich nicht verfehlen kannst - ich muss jetzt den exakten Text nicht aussuchen.


    Edit Daraus ergibt sich natürlich, dass die Datei irgendwo gepsiche sein darf. Der Name ist auch egal, solange die Endung passt.

  • EasyFlash-Save-Funktion mit 1541U2?

    Hm, der Vergleich hinkt zwar etwas, aber nicht viel. Wir emulieren im Moment den Flash-Speicher des Easyflash ausschließlich im RAM, also flüchtigen Speicher. Und eine CRT-Datei ist nichts anderes als ein Dump der Speicherbausteine mit ein paar Header. Übrigens nicht nur bei Easyflash, aber nur für Easyflash ist das Abepcihern des CRTs implementiert. Denn bei Modulen, wo sich der Inhalt eh nicht ändert, macht das ja keinen echten Sinn.


    Deswegen kann man jederzeit ein solches CRT abspeichern - wenn der C64 zwischendurch den Easyflash Inhalt geändert hat, macht das ja genau das, was man will.


    Beim U64 muss ich Gideon mal fragen, da könnte man ja auf die Idee kommen, den Overlaymodus (kennt man ja vom Menü) zu benutzen, umm zu signalisieren, das derzeit gespeichert wird. Wenn man das dann sieht, wird man schon nicht abschalten oder die Software beenden, sondern erst das Speichern abwarten. Lieber eine auf U64 eingeschräkte Lösung als gar keine... Für die U2(+) haben wir ja die vorhandene...

  • EasyFlash-Save-Funktion mit 1541U2?

    Quote from eTron73

    Ein direktes speichern in die jeweilige Easyflash-Crt wäre aber schön sehr cool ... 😬😬

    In der Tat...


    Im Moment macht mir dabei allerdings die Tatsache Sorgen, dass ein Abspeichern eines Easyflash CRT schon etwas dauert. Und nur den geänderten Bereich abzuspeichern klappt auch nicht immer, da manche Easyflash CRT die leeren Bereiche gar nicht im CRT aufgenommen haben - naturgemäß wird aber oft in einem leeren Bereich gespeichert.

    Und wenn man ein längeres Speichern im Hintergrund hat und davon nichts mitbekommt (wir wollen natürlich nicht für jedes Byte das CRT synchron neu speichern, sondern das im Hintergrund machen), dann bestünde eine reale Gefahr, dass man bereits zu früh das System abschaltet.


    Ist also gar nicht so einfach, wie es im ersten Moment scheinen mag. Aus diesem Grund ist noch immer die manuelle Variante aktuell.