VICE mit RAMLink-Unterstützung

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:

Zitat von ZAK256

Soll das V2.01 ROM wirklich so kaputt sein?

Ab $8654 steht:

Das Bit#5 ist hier =1 = AUTOLOAD.

Das ist bei der REU ein wohl bekanntes Problem bei bestimmten Größen, da wird der Zähler zwar hochgesetzt, aber nur bestimmte Bits. Das funktioniert wohl nur bis 512k. Das hat mir markusC64 mal so erklärt.

Der D7181Writer z.B. hat das gleiche Problem... der nutzt auch AUTOLOAD und von den 800K einer 1581 werden nur die ersten 512k korrekt geschrieben, der Rest wiederholt dann die ersten 288k weil AUTOLOAD über 512K nicht alle Bits hochsetzt. Ich hab dann AutoLoad durch manuelles hochzählen ersetzt und alles ist gut...

Ich hab das jetzt nicht weiter verfolgt, aber das könnte schon mal ein Problem sein. Kann mich aber auch irren.

Man müsste die Erkennungsroutine mal genauer prüfen und analysieren. Ich hab das unter VICE für mich aber abgehakt: 16Mb RL und kein REU/GEORAM...

Ich hab zwar eine RAMLink und eine CMD REUXL mit 2Mb... und ich glaub ich hab die auch mal zusammen genutzt, aber nicht als Ergänzung zum RAMLink RAM (das hat schon 16Mb). Kann aber auch sein das die CMD-REUXL den Bug nicht hat.

Im Prinzip hat darkvision völlig recht. Wenn man parallel dafür aber sorgt, dass nur die ersten 512k genutzt werden (oder nur die zweiten 512k, ...), so gibt es kein Problem. Problematisch ist der 512k Grenzenübergang. Und sei es, dass man an der 512k Grenze den Zähler verwerten will. In der Hinsicht muss man da nochmals genauer nachschauen.

Zitat von markusC64

Problematisch ist der 512k Grenzenübergang. Und sei es, dass man an der 512k Grenze den Zähler verwerten will.

Und ich vermute das ist hier das Problem... Der Grenzübergang. Ich glaube nicht das CMD hier die Größe der REU in 512kb Schritten ermittelt.

Gab es damals überhaupt REU > 512kb?

Zitat von darkvision

Gab es damals überhaupt REU > 512kb?

Lt. https://www.c64-wiki.de/wiki/REU#REU-Varianten pikanterweise ja, die CMD 1750XL, eine REU mit 2 MB, pikanterweise von CMD. So dass ich vermuten würde, die wissen in ihren ROMs damit umzugehen.

Zitat von markusC64

Lt. https://www.c64-wiki.de/wiki/REU#REU-Varianten pikanterweise ja, die CMD 1750XL, eine REU mit 2 MB, pikanterweise von CMD. So dass ich vermuten würde, die wissen in ihren ROMs damit umzugehen.

Die CMD REU XL?

Wie gesagt die hab ich... müsste beides nochmal auspacken, aber ich meine die haben zusammen funktioniert... beim letzten Testen der XL hatte ich aber Speicherprobleme, die lief nicht mehr Rund.

Naja... Wenn ich mal viel Zeit hab...

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:

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.

Hallo,

auch wenn ich von den technischen Hintergründen keine Ahnung habe:

Zitat von ZAK256

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?

Defiitiv nicht. Ich hatte damals eine 1 MB aufgerüstete CBM-REU. Da wurde (nicht von mir) der RAM aufgerüstet und kein REC-Chip getauscht. Und nur 512 kB-Schritte kann auch nicht sein. Arbeitete auch damals mit Geos und einer RAM1581. Das sind 800 kB

Zitat von ZAK256

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

Nein! Soweit ich mich erinnere, sind damals plötzlich eine Menge der REC-Chips aufgefunden worden. Daraus hat CMD die 2 REUs gemacht; eine mit 512 kB und eine mit 2 MB.

Achso, in der GUC-Geothek (F64-Wolke) ist auch die Aufrüstungs-Anleitung für CBM-REU enthalten, vielleicht da mal nachlesen ......

Gruß

Werner

Zitat von x1541

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?

Zitat von wweicht

Und nur 512 kB-Schritte kann auch nicht sein. Arbeitete auch damals mit Geos und einer RAM1581. Das sind 800 kB

Natürlich - auf eine Ramdisk wird sektorweise zugegriffen, also in 256 Byte Vielfachen. Da ergibt sich eine 512k Grenze ohen Überschreiten in einem Transfer von alleine.

Bei sequentiellen Zugriff dagegen ergibt es sich, wie wir am Beispiel des D71 D81 Writers gelernt haben, nicht von alleine. Aber auch da würde Geos die Routinen für einen sektorweisen Zugriff nutzen, so dass das auch passt.

Zitat von ZAK256

Zitat von x1541

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

Ich hab mal etwas weiter nachgeforscht... ohne sichtbaren Erfolg.

Meine Vermutung ist das bei 128Kb und 512Kb beim testen zufällig der Wert $00 zurückgeliefert wird was anzeigt das der Suchvorgang wieder bei Bank $00 angekommen ist -> Überlauf und man hat die REU-Größe erkannt. 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...

Ich hab die Routine mal gespeichert und dann mit VICE+REU ohne RAMLink geladen und mal durchlaufen lassen. Die Erkennung hängt dort dann ebenfalls bei 256Kb, allerdings auch bei 128Kb und 512Kb.

Wenn ich aber den Transferbereich von $DE00 nach $8000 verlege läuft die Routine durch und erkennt eine 512Kb REU mit 8x64Kb... 128Kb mit 2x64Kb... 256Kb geht aber auch nicht.

Am TC64v2 kann ich die Routine ausführen und die erkennt dann auch eine REU mit 1Mb...

Ich hänge mal die modifizierte Routine an... laden mit

Starten mit:

Wenn die Routine beenden wird, dann...

Gibt die Größe in KB aus...

Beim TC64v2 muss ich nach ändern der Größe in den Settings den gesamten Speicher löschen -> F2.

Die UI+ wird auch bis 8mb erkannt... 16mb sind für die Routine wohl auch ein Problem...

Ich hab auch ein älteres VICE nur mit REU getestet (r39122, da gab es noch keine RAMLink), da funktioniert die Erkennung auch nur mit 128Kb... 256Kb geht nicht...

Ich verstehe es nicht... evtl. findet jemand raus wo das Problem liegt... ich fürchte aber das hier VICE die RAMLink-Integration noch nicht perfektioniert hat. Ich glaub nicht das es was mit dem ROM zu tun hat. Es liegt eher an der Art wie CMD damals versucht hat die Größe der REU zu erkennen, das scheint nicht ganz kompatibel mit VICE zu sein (oder andersherum).

Vielleicht kann das jemand querprüfen... evtl. auch mal mit einer echten REU (ohne RAMLink). Evtl. kann man damit genügend Infos für einen Bugreport liefern...

Genug getestet...

Zitat von darkvision

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.

Zitat von ZAK256

Vielleicht ist das schon das ganze Problem von VICE.

Ich hab dazu mal einen Bug verfasst... warten wir mal was das VICE-Team dazu sagt. Mit 512K + RAMLink hab ich nach dem Einschalten jedenfalls zwei Native-Partitionen, 1x für die REU512K und 1x für den Rest der 16Mb. Laden und speichern scheint zu funktionieren... RAM-TOOLS zeigt auch beide Partitionen an.

Also beim REU-Problem braucht es wohl Tester mit realer Hardware (Ticket 1425)... aber das andere Problem mit dem Crash eines meiner Programme (das ich deswegen voreilig "gepatched" hatte) scheint wohl wirklich ein RAMLink-Problem gewesen zu sein... da soll es bald ein Update für geben (Ticket 1424)... Immerhin etwas

Zitat von ZAK256

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.

Kann ich ebenfalls bestätigen. Im Source-Code zu GoDots mod..REUTool (auf Github, siehe Signatur) ist das im Abschnitt "NewSize" nachzulesen.

Arndt

Zitat von gpz

i'd like to see this confirmed by a test program - i dont see this being true eg on a 256k REU that has empty RAM slots for another 256k, there you really have unconnected RAM slots that will be "read", no reason for the upper address bit being "ignored" (then you couldnt just solder in the other RAMs)

Zitat von Roberto Muscedere

I believe the vice documentation discusses this - see section 7.1.1.9. CMD's REU detection likely works on a real c64, but in vice the unavailable REU ram is pulled up all the time and this causes CMD's algorithm to fail. The CMD algorithm assumes it won't always be pulled up but floating which would occasionally return a 0 on some bits. The best to do right now is just avoid those sizes until the cart system can be made to be more realistic. We would need proper modeling from a real device to figure out exactly how to mimic it.

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.

Zitat von darkvision

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)

Zitat von x1541

Zitat von ZAK256

Zitat von x1541

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?