Posts by ZAK256

    Ich hatte mich auch mal ein wenig mit dem Hardware block beschäftigt.

    Und bin dabei auch auf die Diskrepanz bei der maximalen Anzahl der benutzbaren Geräte gestoßen.

    Ja, mich interessieren immer nur die Extreme :-)

    Eigentlich müsste die CMD-HD mit 56 Geräten (in der Regel Festplatten) umgehen können.

    (SCSI Device 0-6 with SCSI-LUN 0-7 -> total of 56 devices)

    Der Hardware block kann aber nur mit 55 Geräten umgehen.

    Die Frage die ich mir Stelle ist, welche SCSI-Device/SCSI-LUN Kombination fehlt?

    Also welche SCSI-Device/SCSI-LUN Kombination wird von der CMD-HD einfach nicht an gesprochen?

    Oder kann man einfach nur 55 Geräte mit "ADD Drive" hinzufügen und dann ist Schluss?

    Ich habe leider noch ein weiteres Problem bei der Emulation eines RAMLinks gefunden.

    Wird ein RAMLink zusammen mit der SuperCPU und einer REU emuliert, führt das zum Absturz des Emulators.


    Den Test habe ich mit der Version GTK3VICE-3.5-win64-r39719 durchgeführt.

    Bei den Kombinationen SuperCPU + REU, SuperCPU + RAMLink, RAMLink + REU ließ sich der Emulator normal starten:

    Dazu müsste man m.M.n. das RAMLinkOS patchen... die Routine war nie für 16mb ausgelegt und hat daher keine passende Abbruchbedingung...

    Ja, das glaube bzw. hoffe ich auch. Hauptsache der Emulator funktioniert erst einmal korrekt.

    Und ich bin superglücklich das sogar die 8 MB gehen. :)


    So komme ich meinem Emulationsziel wieder ein Stück näher. :)


    Sieht doch schon gut aus:



    Als nächstes kommt die SuperRAMCard an die Reihe, da gibt es leider auch noch ein Problem ...

    Ich habe mal mit der WinVice Version (GTK3VICE-3.5-win64-r39702) getestet.


    Jeweils RAMLink + REU:

    reusize 128: Emulator startet :)

    reusize 256: Emulator startet :)

    reusize 512: Emulator startet :)

    reusize 1024: Emulator startet :)

    reusize 2048: Emulator startet :)

    reusize 4096: Emulator startet :)

    reusize 8192: Emulator startet :)

    reusize 16384: Emulator hängt beim Starten (wieder bei $8663) :|


    :thumbsup::ilikeit::thnks:


    Das Ergebnis mit RAMlink auf disabled und RAMlink auf direkt ergab bei 256 bzw. 2048 dasselbe Ergebnis (also dasselbe Bild)?

    Ganz ohne RAMLink hast du nicht getestet, oder?

    Darf ich die Bilder weitergeben?

    Interessant ist, dass der CCS64 V3.9.2 den Test fast immer besteht. Nur bei 16384 KB großer REU wird der Test nicht bestanden.


    Ich bin gespannt, wie sich die richtige 256 KB bzw. 2048 KB REU Hardware verhalten wird.


    128 - OK


    256 - OK


    512 - OK


    1024 - OK


    2048 - OK


    4096 - OK


    8192 - OK


    16384 - Fehler

    Ich habe mal mit der aktuellen WinVice Version (GTK3VICE-3.5-win64-r39662) getestet.


    Das Programm reuverify.prg verhält sich wie folgt bei 128, 256, 512, und 2048 KB großer REU:


    128 - OK


    256 - Fehler


    512 - OK


    2048 - Fehler

    habe neulich eine echte RL mit 1750XL gestartet. Lief. Allerdings habe ich nur ohne Ramcard und mit 12MB getestet. Nicht mit 16MB.


    Die XL wird mit 2MB erkannt und eingebunden.

    Super Test. Welche ROM Version hat deine RAMLink?

    2.01 what else ;)

    Könntest du bitte mal das Test-Programm (ramlink.zip) von gpz (VICE Team) laufen lassen? (siehe https://sourceforge.net/p/vice-emu/bugs/1425/#cdfe)

    Einmal mit 1750XL+RamLink und einmal nur 1750XL währe toll.

    Und du hast nicht zufällig noch eine 1764 (256k) rumliegen, um den Test auch damit durchzuführen?:)

    Ich kann da nicht mehr viel helfen... ich hab das jetzt aber für mich abgehakt, ich nutze unter VICE 16Mb RAMLink. Die paar MB einer REU bringen da nicht viel. Es sei denn man könnte die REU unabhängig von der RAMLink nutzen und nicht als Teil des Speichers der RAMCard.

    Vielen Dank für deine Arbeit. Ich bin guter Dinge, das das VICE Team das Problem gelöst bekommt.


    Ich verfolge immer noch das Ziel, den GEOS MegaPatch 3.X mit alle 4 Speicherarten (gleichzeitig) zu emulieren. Dies sollte (ein geeignetes Netzteil vorausgesetzt) auch mit realer Hardware funktionieren. RAMCard (16MB) + Super RamCard (16MB) + CMD 1750XL (2MB) + NeoRAM/BBGRAM (2MB)

    Bei 256Kb wird z.B. beim Auslesen der ersten nicht mehr vorhandenen Bank $FF zurückgeliefert. Das Byte kann die Routine aber dann nicht wiederherstellen und verfängt sich in einer Endlosschleife...

    Auch der Programmierer des Programms „REU-Checker“ berichtet von dem Verhalten von VICE, das bei einem Zugriff auf eine ungültige Bank der Wert $FF zurückgegeben wird.

    Siehe https://www.retro-programming.…-know/reu-programmierung/ im Abschnitt „Traue keiner Emulation“.

    In dem Abschnitt steht auch, dass sich der TC64 und eine originale REU anders verhalten.

    Vielleicht ist das schon das ganze Problem von VICE.

    Habe ich das richtig verstanden?

    Es kommt zu Problemen, wenn man versucht Daten von der REU zu lesen (oder geben Falls zu schreiben) und dabei die 512 KB Grenze überschritten wird.

    Also wenn der Lesevorgang (Schreibvorgang) vor der 512 KB Grenze beginnt und nach der Grenze endet.

    Dieses Problem kann ja nur bei Speichererweiterungen > 512 KB auftreten.

    Könnte es sein, das dieses Problem nur bei Speicherweiterungen auftritt, welche umgebaut also nachträglich aufgerüstet wurden???

    Könnte es sein, das der Commodore REC Chip nur mit 512 KB korrekt arbeitet?

    Bei Umbauten auf 1 MB mit dem Commodore REC Chip würde er dann in den ERSTEN 512 KB oder in den ZWEITEN 512 KB korrekt arbeiten! Oder?

    Die 1750XL von CMD hat auch einen REC Chip.

    Ich vermute mal, das dieser REC Chip von CMD ein anderer ist, welcher bis 2 MB korrekt arbeitet.

    Das könnte auch der Grund sein, warum es "damals" keine REUs >2MB geben hat.

    Es war wohl einfach zu aufwendig einen entsprechenden REC Chip zu verbauen.

    Erst die Hardware emulierten REUs (Ultimate und Co.) bieten REUs mit bis zu 16 MB an.

    Und ich vermute mal stark, das diese Hardware emulierten REUs einen entsprechenden REC Chip emulieren.


    Ich habe mir die Test-Routine im ROM (V2.01) des RAMLinks einmal angesehen.

    Leider ist diese für mich doch sehr schwierig zu verstehen.

    Aber ich glaube nicht, das das Problem des ROMs mit dem 512 KB Grenzproblem zu tun hat.

    Die Grenzen der RAM-Bänke werden dabei, glaube ich, gar nicht überschritten.

    Es wird, glaube ich zumindest, immer nur innerhalb der 64 KB großen RAM-Bänke gearbeitet.

    Die Test-Routine im ROM (V2.01) des RAMLinks hat vor allem auch schon ein Problem bei einer 256 KB großen emulierten REU.

    Ich vermute, das das Problem durch VICE verursacht wird.

    Beim Zugriff auf nicht vorhandene RAM-Bänke stimmt die Emulation nicht mit der Realität überein. (Ist nur eine Vermutung!)


    Hier mal meine laienhafte Analyse des ROM (V2.01) des RAMLinks:

    Ich hab mal versucht eine REU zusammen mit einer RAMLink zu emulieren.

    Für die RAMLink Emulation habe ich ein V2.01 (CRC32: 00BE1BE4) ROM verwendet und eine 16 MB RAMCard emuliert.

    Dann habe ich versucht zusätzlich eine REU mit 128, 256, 512, 1024, 2048, 4096, 8192, 16384 zu emulieren.

    Die Tests habe ich einmal mit ramlinkmode = 0 und einmal mit ramlinkmode = 1 durchgeführt.

    Es zeigte sich, das nur die REU Größen vom 128 und 512 zu einem Start des emulierten C64 führten.

    Bei allen anderen Größenangaben blieb der Rechner vor dem Startbildschirm hängen.

    Meine Tests bestätigt also genau die Aussage aus dem vice.pdf "The latest RAMLink firmware (2.01) can not handle

    REU sizes other than 128 and 512 KiB, or GEORAM sizes beyond 2 MiB in VICE, as the

    firmware will hang on size detection.".


    Das würde bedeuten, dass eine Commodore REU Modell 1764 oder eine CMD 1750XL nicht mit einem RAMLink mit 2.01 ROM laufen würden.

    In der Anleitung zur RAMLink steht, das mindestens auch die 1764 funktionieren müsste. Zu 2 MB Versionen steht in der Anleitung nur, das diese wohl zu Überlastungen des Computers führen können.


    Soll das V2.01 ROM wirklich so kaputt sein?


    Leider bekomme ich die Emulation der RAMLink mit einer Firmware V1.40 nicht zum laufen, ansonsten würde ich es damit auch noch einmal testen.


    Test mit GTK3VICE-3.5-win64-r39570

    Start_x64sc_ramlink_reu_ramlinkmode_0.bat

    Start_x64sc_ramlink_reu_ramlinkmode_1.bat

    Problem:

    So ich will mal versuchen eine Antworten auf die 3 Fragen "Welche Laufwerke werden emuliert?", "Von welchem Laufwerk wird gebootet?", "Welche Geräteadresse bekommen diese Laufwerke?" für eine Beispielkonfiguration zu finden.


    Alle Laufwerke müssen eine eindeutige Geräteadresse zugeordnet bekommen.

    Diese Geräteadresse ist durch das jeweilige Gerät fest vorgegeben (DIP-Schalter, Systempartition).

    Die feste Geräteadresse kann aber durch Software temporär geändert werden.

    Der MegaPatch64 kann die Geräteadresse 8-19 verarbeiten.

    Unter GEOS werden die Laufwerke mit A, B, C, D bezeichnet.

    Dabei entspricht die Geräteadresse 8 dem Laufwerk A, Geräteadresse 9 dem Laufwerk B, Geräteadresse 10 dem Laufwerk C, Geräteadresse 11 dem Laufwerk D.

    Die festen Geräteadressen von 8-19 werden durch MegaPatch64 temporär auf die Geräteadresse 8-11 geändert (A=8, B=9, C=10, D=11).

    Der MegaPatch64 kann von den Laufwerken 8-11 gestartet werden.

    Das Startlaufwerk bildet eine Ausnahme, da die feste Geräteadresse für das Startlaufwerk nicht geändert werden kann.

    Das heißt wird der MagaPatch z.B. vom Laufwerk 11 gestartet so muss das Laufwerk zum GEOS-Laufwerk D werden.

    GEOS Applikationen, welche nicht an den MegaPatch angepasst sind funktionieren, glaube ich, nur mit den GEOS-Laufwerken A und B korrekt.

    Dies würde bedeuten, das für die Datenpartition und für die Applikationspartition nur die Laufwerke A=8 und B=9 in Betracht kommen.

    Wenn jetzt die Daten bzw. die Applikationen auf dem Startlaufwerk gespeichert werden sollen, muss das Startlaufwerk eine festete Geräteadresse 8 oder 9 bekommen.

    Somit wäre das Startlaufwerk auf die festete Geräteadresse 8 oder 9 begrenzt.

    Im Normalfall will man seine 1541/1571 auf der festen Geräteadresse 8 lassen, um jegliche Spiele und nicht GEOS Programme davon zu starten.

    Dann bleibt für das Startlaufwerk nur noch die Geräteadresse 9 übrig.

    Als Startlaufwerk kommt meines Erachtens nur eine RAMLink Partition in Betracht, da nur diese einen Autostart Mechanismus (am C64) zur Verfügung stellt.

    So würde eine RAMLink Partition mit der festen Geräteadresse 9 zum Start des MegraPatch dienen, welche dann das GEOS-Laufwerk B darstellt.

    Die Startpartition würde ich gleichzeitig für die Ablage der GEOS-Applikationen nutzen.

    Das GEOS-Laufwerk A würde ich zur Ablage von erstellten GEOS-Dateien (Dokumenten) nutzen.

    Dazu würde ich eine CMD-HD Native Partition verwenden.

    Die CMD-HD würde die festen Geräteadresse 10 bekommen, welche durch den MegaPatch auf die temporäre Geräteadresse 8 geändert wird.

    Ich glaube VICE lässt momentan nur die festen Geräteadresse 8-11 für das HD Laufwerk zu.

    Jetzt sind also noch die GEOS-Laufwerke C und D frei.

    Das Laufwerk C würde ich mit einem 1571 Laufwerk versehen, so das man einen Zugriff auf alle 5,25" Disketten/Images hat.

    Dieses Laufwerk würde die festen Geräteadresse 8 bekommen, welche durch den MegaPatch auf die temporäre Geräteadresse 10 geändert wird.

    Das Laufwerk D würde ich mit einem FD-4000 Laufwerk versehen, so das man einen Zugriff auf alle 3,5" Disketten/Images hat.

    Dieses Laufwerk würde die festen Geräteadresse 11 bekommen.

    Für ein reines RAM Laufwerk ist jetzt leider kein GEOS-Laufwerksbuchstabe mehr frei.

    Wenn ein RAM Laufwerk benötigt wird, müsste man bei Bedarf eins der Diskettenlaufwerke in C oder D dafür opfern.


    So ich habe die emulierten Laufwerke mit den jeweiligen Geräteadressen und der Angabe des Startlaufwerks in einer Tabelle zusammengefasst:

    Gerät BOOT Feste Geräteadresse Temporäre Geräteadresse GEOS-Laufwerk Laufwerkstreiber Art
    1571 8 10 C C=1541, C=1571 Dateiaustausch 5,25"
    RAMLink X 9 9 B CMD RL Native, (CMDRL 1541),(CMD RL1571),(CMDRL 1581) Systempartition, Applikationspartition
    HD 10 8 A HD Native, (HD 1541),(HD1571),(HD1581) Datenpartition
    FD-4000 11 11 D FD 1541,FD1571, FD 1581, FD Native, FDPCDOS Dateiaustausch 3,5"


    Ich hoffe, das wenigstens einige meiner Aussagen und Annahmen korrekt sind.

    Die neue Version 3.5 vom Emulator VICE bietet endlich die Möglichkeit, noch mehr Hardware für die Verwendung von GEOS/MP3 zu emulieren. So kann jetzt eine CMD-HD und auch ein CMD-RAMLink emuliert werden.


    Jetzt stellt sich mir die Frage, was ist die beste Konfiguration von VICE für die Verwendung von GEOS/MegaPatch64/GeoDesk64?


    Folgende Anforderungen würde ich mal anstreben:

    die Konfiguration soll auch mir realer Hardware umsetzbar sein
    automatischer Start von GEOS/MP3 beim Starten des C64
    GEOS/MP3 soll sehr schnell geladen werden
    alle GEOS Programme sollen schnell und einfach gestartet werden können
    die GEOS Standardapplikationen sollen auf alle Laufwerke zugreifen können
    es sollen viele Schriftarten zur Verfügung stehen
    es sollen viele Dateien permanent abspeichert werden können
    es soll ein Drucker zur Verfügung stehen mit dem schnell gedruckt werden kann
    es soll ein großer Drucker-Spooler zur Verfügung stehen
    es sollen zwischen vielen Programmen schnell gewechselt werden können
    der Zugriff auf alle möglichen 5,25" Disketten soll möglich sein
    der Zugriff auf alle möglichen 3,5" Disketten soll möglich sein
    es soll eine Möglichkeit für die Ablage von temporäre Daten zur Verfügung stehen
    eine Sicherung aller Daten und Einstellung soll möglich sein
    die Uhrzeit des Systems soll aktuell sein
    es soll eine schnelle RS 232 Schnittstelle zur Verfügung stehen


    Die ersten Fragen, die ich mir stelle, um die angestrebten Anforderungen zu erfüllen, sind:

    • Welche Laufwerke werden emuliert?
    • Welche Geräteadresse bekommen diese Laufwerke?
    • Welche Speichererweiterungen werden emuliert?
    • Wofür wird welche Speichererweiterung genutzt?
    • Also wo kommt z.B. der DACC hin?
    • Von welchem Laufwerk wird gebootet?

    Der Post #115 von darkvision hat mich dazu inspiriert.


    Ich wollte soviel Informationen über meine Einstellungen mitgeben wie nur möglich.

    Deshalb wollte ich nur mit Kommandozeilenparametern arbeiten und komplett auf eine vice.ini verzichten.

    Leider sieht das immer echt blöd aus, wenn man alle Kommandozeilenparametern in eine Zeile hintereinanderschreibt.

    So bin ich auf die BAT-Dateien gekommen. Und ja ich verwende Windows.

    In den BAT Dateien kann man Zeilenumbrüche mit einem ^ Zeichen innerhalb von Kommandozeilen einfügen. Unter Linux ist das wohl das \ Zeichen.


    Somit kann man pro Parameter eine neue Zeile verwenden, was die Übersichtlichkeit stark verbessert.


    So sieht die BAT Datei im Editor aus:

    Um diese auszuführen reicht unter Windows ein Doppelklick.


    Die BAT Datei befindet sich direkt im VICE Ordner:


    Ich verwende dann noch die 2 Ordner _OTHER und _DATA.

    Der Ordner _OTHER enthält unveränderliche Dateien wie ROM-Images und Disk-Images (welche nicht verändert werden sollen).

    Ach ja, zu meinen verwendeten ROM-Images und Disk-Images ist im Namen immer eine CRC32 Prüfsumme ersichtlich.


    Der Ordner _DATA enthält die veränderlichen Dateien wie z.B. die DHD-Images.


    Wenn eine neue Version von VICE erscheint muss ich nur die beiden Ordner und meine BAT Dateien in den neuen VICE Ordner kopieren und kann wieder testen.

    Neuer Test mit meiner Wunsch-Konfiguration SuperCPU+RAMLink+HD:


    Getestet habe ich mit der Version GTK3VICE-3.5-win64-r39490.


    Zum Starten habe ich folgende BAT Datei verwendet:

    7_Start_xscpu64_jiffy_on_ramlink_empty_system_partition.bat

    bin\xscpu64.exe ^

    -default ^

    -ramlink ^

    -ramlinksize 16 ^

    -ramlinkimagerw ^

    -ramlinkimage "_DATA\ZAK256_expansion_ramlink_xscpu64.ram" ^

    -cartramlink "_OTHER\ZAK256_CMD_RAMLINK_DOS_V2.01_CRC32_00BE1BE4.bin" ^

    -scpu64 "_OTHER\ZAK256_CMD_SUPERCPU_DOS_V2.04_CRC32_F4151454.bin" ^

    -drive8type 1542 ^

    -8 "_OTHER\ZAK256_HDUTILS_HDDOS_V1.92_CRC32_907F3178.d64" ^

    -dosCMDHD "_OTHER\ZAK256_CMD_HD_BOOTROM_V2.80_CRC32_DA68435D.bin" ^

    -drive9type 4844 ^

    -9 "_DATA\7_xscpu64_jiffy_on_ramlink_empty_system_partition.dhd"


    Die Datei 7_xscpu64_jiffy_on_ramlink_empty_system_partition.dhd ist 0 Bytes lang.


    Start 1


    In der vice.log stand:

    CMDHD: RAMLink detected. Drive 9 'parallel cable' set to 'standard'.

    CMDHD: Image size too small, starting up in installation mode.

    CMDHD: Drive 9 'parallel cable' set to none. Set it back to 'standard' when

    CMDHD: HDDOS installation is complete.



    Die Datei 7_xscpu64_jiffy_on_ramlink_empty_system_partition.dhd ist 270.336 Bytes lang.


    Start 2


    In der vice.log stand:

    CMDHD: RAMLink detected. Drive 9 'parallel cable' set to 'standard'.



    Die Datei 7_xscpu64_jiffy_on_ramlink_empty_system_partition.dhd ist 279.552 Bytes lang.


    Start 3


    In der vice.log stand:

    CMDHD: RAMLink detected. Drive 9 'parallel cable' set to 'standard'.



    :thumbsup::thumbsup::thumbsup::thumbsup::thumbsup::thumbsup::thumbsup::thumbsup::thumbsup: