Posts by markusC64

    Das klappt leider nur für CRTs, die kein EEPROM beinhalten. Die aktuelle 1541 Ultimate II(+) / Ultimate 64 Firmware ergänzt jedoch das EEPROM beim Speichern, so dass der Weg zumindest bei den CRTs aus der Ultimate nicht funktioniert.

    Erkennt man daran, dass die BIN-Datei dann 514k groß wird.


    In dem Fall: https://csdb.dk/release/?id=207012

    Usage:

    gmod2crt -f flash.bin [-e eeprom.bin] [-n name] [-o cart.crt]

    Creates CRT file containing flash and optionally eeprom data.


    gmod2crt -c cart.crt

    Extracts flash.bin and eeprom.bin from CRT file.



    Edit: Darüber hinaus ist das Flashtool auch ohne eine solche Cartridge gut verwendbar. Man kann von Original GMOD2 Modul das EEPROM backupen und damit den Spielstand. Und das dann im Emulator ins EEPROM schreiben lassen. Oder umgekehrt. :-)

    Ich würde dann vorschlagen, dass du wenn du eine vorgelötete Cartridge wünscht, das Formular auf der Website verwendet und in den Kommentaren angebet, dass du die Cartridge gelötet kaufen möchtet.

    Würde ja gerne, aber



    erhalte ich nach dem Abschicken des Formulares und dem anschließenden reCAPTCHA.



    Ist es ok, wenn ich Dir die entsprechenden Angaben aus dem Formular ersatzweise per Konversation hier sende? Oder findest Du das Problem schnell?

    Oder gilt das nur für das nicht Elite Board? Oder geht es da ums direkte speichern auf dem U64, wenn ich ohne physisches EF3 Modul speichern möchte?

    Ja. Und für den Fall kann ich den Bug in der 1541 Ultimate II(+) / U64 Firmware ab Version 3.10 auch bestätigen.


    Wobei es mit dem von mir modifizierten WinVICE einen Workaround gibt: In den Easyflash Settings das Optimieren des CRTs abschalten. Dann das CRT einladen und über die Settings von WinVICE sofort manuell speichern lassen. Das so abgeänderte CRT triggert dann nicht mehr den Firmwarebug, so dass das Speichern funktioniert.

    us Operation Mode in den U64 Settings auf Dynamic Writes gesetzt? Wenn nicht, machen bei mir einige EF's das Speichern nicht mit. Hatte den Tip damals von Gideon.

    Das kann aktuell nicht klappen, da es noch einen Bug im U64 gibt bzg. des Handling der Speicherslots des EF Modus. Ggf. kommt Gideon am WE dazu das zu fixen, es kann zumindest ohne Manipulation des Spiels mit dem U64/U2+ aktuell nicht funktionieren. Bitte bis zum Fix die Spielstaende auf Diskette speichern.

    Ich habe den Tipp so interpretiert, dass er für das Anschließen eines echten Easyflash 3 am Expansionsport des Ultimate 64 ist. In der Interpretation ist der Tipp völlig korrekt und meiner Erfahrung nach auch notwendig. Und ja, mit einem externen Easyflash klappt das auch am U64 - mit Verqwenduing des Tipps. Ohne Verwendung des Tipps klappt bereits das Flashen des CRTs nicht.

    Mir war nur bekannt, dass Vice mittlerweile die SCPU beherrscht. Aber dann wird das bestimmt auch bald kommen :):emojiSmiley-106:

    https://sourceforge.net/p/vice-emu/feature-requests/133/ endet auf "Any technical information that could help with making the feature requested is appreciated, the more information we have, the higher the chance that it will be made."


    Und ich werde das Gefühl nicht los, dass Du zumindest nach Analyse der Platine dann am meisten Infos hast zur Funktionsweise der SCPU 128 v2 auf echter Hardware.

    Bei der SCPU läuft der 65816 auf 20MHz und diese lässt sich in Vice komplett emulieren.

    Dem muss ich widersprechen. C128 mit SuperCPU, das kann Vice nicht. Und als ich im Vice die SuperCPU am emulierten C64 ausprobiert habe, so stürzte Vice ab, wenn die REU verwendet werden soll - ob letzteres noch immer, entzieht sich gerade meiner Kenntnis. C128 mit SuperCPU, das ist jedenfalls noch aktuell, dass das im Vice nicht geht.

    Die Bilder bei Beitrag #80 zeigen, dass es wohl einseitige Disketten sind: Seiten-Einkerbung nur auf einer Seite und die dort ebenfalls vorhandene Darstellung der Informationen auf den Floppies zeigt dementsprechend, dass auf den Rückseiten (B-Seiten) keine Nutzdaten enthalten sind.

    Ich seh doch deutlich auf den Bildern die Syncmarkierkungen auf der Rückseite... das müsste man sich noch einmal genauer ansehen.

    Juergen Johannes

    Dem ist nichts hinzuzufügen


    toms01 Eine fantastische Leistung. Wegen der Ultimate 2+ Kompatibilität mach Dir keinen Kopf. Das wird schon wer austesten. Und falls es da Probleme gibt, so wäre doch eher die Ultimate 2+ anzupassen. Was vermutlich möglich ist, wenn Gideon (der Schöpfer der Ultimate 2+) mit Details zur Funktionsweise der SuperCPU versorgt wird. Ob er es dann macht und wenn ja, wann - ja, das ist freilich eine andere Frage.

    Edit: Vielleicht geht das Menü dann zwar nur in 1 MHz Modus - aber vor dem Menüaufruf der Ultimate könnte man die SuperCPU ja problemlos heruntertakten.

    Daher macht es dann für mich schon mehr Sinn die 128er-Version unter x64 zu assemblieren als andersherum. Über eine Stunde kann ich da nicht warten. Bei 8 Versionen sind das ja fast 10h 8|


    Trotzdem Danke für die Vergleichswerte.

    Da geht natürlich sehr stark die Leistungsfähigkeit der eigenen CPU ein... daher bin ich jetzt beim Mitlesen vorsichtig und vergleiche nicht Deine Werte (x64) mit Werners (x128).

    Was mich wundert: Der 128er ist nur ca. 15% schneller als der C64 ? Ich dachte der hat 2MHz ?

    Aber ich glaube bei den ganzen RAM-Zugriffen schaltet die REU auf 1MHz, und da hier fast die ganze Zeit auf Disk zugegriffen wird kommen die 2MHz nicht voll zur Geltung. Hast Du eine CREU verwendet ?

    Davon gehe ich auch aus. Und der Zugriff auf die FD1581 dürfte auch nur mit 1 MHz erfolgen...


    PS: Werner hat bestimmt eine 1541 Ultimate II+ für die REU Emulation benutzt. Aber auch die nutzt nur 1 MHz für die REU.

    Eventuell nur interessant, wenn man das P64 auf eine echte Disk zurückschreibt, wobei dann wohl besser das entsprechende Tool diesen Ausgleich beim Schreibvorgang vornehmen sollte.

    Davon gehe ich auch aus ("das entsprechende Tool diesen Ausgleich beim Schreibvorgang vornehmen sollte") - denn das selbe Tool wird beim Einlesen ja gespeichert haben, wie die Flux anscheinend liegen und nicht, wie sie wirklich liegen.


    Gut, auch wenn die Emulatoren und Konvertierungstools das nicht brauchen: Es wäre schon mal interessant zu wissen, wie man damals tatsächlich kompensiert hat...

    - Write Precompensation fehlt noch (dient der Langlebigkeit echter Disketten)

    Um Bit Shifting auf den inneren Tracks zu verhindern und somit die Langlebigkeit der Disks zu erhöhen, verwendet der Controller Write Precompensation.

    Hierbei wird der Flusswechsel je nach eingehendem Bitmuster um 128 nano nach recht oder links verschoben.

    Muss man das überhaupt emulieren?


    Ich habe dazu mal etwas recherchiert: Die Write-Compensation dient dazu, den physikalischen Peak-Shift-Effekt auszugleichen. Kurz zusammengefasst sorgt der Effekt dafür, dass die gemessene Position der Flusswechsel nicht der physikalischen Position auf dem Datenträher entspricht. Damit die gemessene Position der entspricht, die man gerne auf den Datenträger haben will, schreibt man leicht anders.


    Nun ist es aber so, dass in einer P64 Datei geschriebene und gelesene Position übereinstimmt. Wenn man dann aus praktischen Gründen annimmt, dass P64 Dateien immer die Position enthalten, die beim Lesen festgestellt würde, so gibt es nichts zu korrigieren beim Schreiben, wenn die Korrektur bei der echten Hardware 100% wäre. Ist die WPcom dagegen nur in etwa passend, so bräuchte es umfangreiche Messungen an original Hardware, um überhaupt die Unterschiede zwischen mit WPcom geschriebenen und anschließend gelesenen Daten festzustellen.


    Kurz: Die kann man so einfach gar nicht emulieren, und braucht es vermutlich auch nicht.


    Literatur: https://books.google.de/books?…20sektor%20aufbau&f=false