Für die 1541 UII+ habe ich die Routine nicht testen können,und werde das auch nicht, weil ich diese Hardware nicht besitze.
Ich habe vor etwa einer
Stunde im Lemon64 Forum gelesen, dass sich die UII+ nicht immer so verhält, wie die echte Hardware. Vorallem, wenn es um die Detection dieser geht.
Warum das so ist konnte dort auch keiner sagen. Einer meinte sogar, dass es halt ein Nachbau ist, und wie das so ist mit Nachbauten, haben diese mehr oder weniger Macken..
Ich habe auf die Schnelle mal ein mit 512kb bestücktes NeoRAM (remix) probiert. Das scheint korrekt erkannt zu werden:
1 - 7 - 2 - 0 - 3 - 0
Gleich im Anschluss dann eines mit 2mb, das liefert ein paar merkwürdige Werte:
1 - 31 - 255 - 255 - 0 - 0
Das gibst doch nicht. Der Emu liefert falsch Werte, von bigby seiner Hardware kommen auch falsche Werte, die 1541 UII+ liefert wieder andere Werte. Alles kuddelmuddel. Irgendwer hält sich da nicht an Standarts.
Ich werde jetzt Markus seinen Code einbauen und dann ganz rustikal die GeoRam und REU mit einem Texte in bestimmte Bänke beschreiben, diesen dann auslesen und vergleichen. So habe ich das auch mit der
SCPU Erkennung gemacht. Das wird dann alles vom Code etwas länger aber was solls, die Routine wird ja nach der erfolgreichen Erkennung sowieso überschrieben.
Wie jetzt eine 255 an der Stelle steht, wo eigentlich nur eine 2 stehen kann, was anderes ist nicht möglich, ist mir ein echtes Rätsel. Ich werde das morgen mal genauer untesuchen.
Wieso funktioniert die Routine mit dem WinVice v3.2 X64 zu 100% und mit echter Hardware, sei es der Nachbau oder die Original Hardware überhaupt nicht? Das kappiere ich nicht.
Was mich da so richtig ärgert ist, dass mindestens 3 Stunden coderei umsonst waren. Naja, ich nehme es mal als Lehrstunde so für mich an.
Den Code habe ich mir noch nicht anschauen können. Aber das zweite Ergebnis konnte ich auch mit einem „original“ NeoRAM mit 2mb reproduzieren.
Den Code habe ich mir noch nicht anschauen können. Aber das zweite Ergebnis konnte ich auch mit einem „original“ NeoRAM mit 2mb reproduzieren.
Ich glaube dir das. Mir ist das aber jetzt ein noch größeres Rätsel. Der Bereich wird beim Programmstart sogar mit $00 Bytes gelöscht, um Zufallswerte beim Einschalten zu verhindern.
Schaue dir doch Bitte mal den Quellcode an, wenn du Zeit dafür hast. So groß ist dieser nicht. Ich begebe mich mal auf die Bugsuche. 
PS, der Wert #$31 ist richtig. Das ist Hex $1f und steht für 2MB. Die REU-Werte "255,255" kann man vernachlässigen, weil keine vorhanden war. Vielleicht funktioniert meine Routine ja doch.
hier nochmal die Werte
--------------------------
kenn2 = $cf01 ; ---- georam verfügbares ram. #$00 = kein ram, #$03 = 256kb, #$07 = 512kb, #0f = 1mb, #$1f = 2mb, #$3f = 4mb
kenn3 = $cf02 ; ---- reu kennung = #$02
kenn4 = $cf03 ; ---- reu verfügbares ram. #$00 = kein ram, #$01 = 128kb, #$03 = 256kb, #$07 = 512kb, #0f = 1mb, #$1f = 2mb
Was mich da so richtig ärgert ist, dass mindestens 3 Stunden coderei umsonst waren.
Dann erspare bitte anderen diesen Ärger, indem Du Deine Erkenntnisse in den VICE-Bugtracker schreibst, idealerweise mit einem minimalen Programm, das sich auf VICE und echter Hardware unterschiedlich verhält.
Ich habe das Teil gelöscht und damit ist die Sache für mich erledigt.
Soviel dazu! 
Ne sorry, ich war gestern ein wenig angepisst. Ich habe meine eingeschweißte Hardware ausgepackt und fange nochmal von vorne an.
Ich erstelle eine ganz einfache, rustikale Routine. Es wird nichtmal auf das Vorhandensein einer GeoRAM oder einer REU getestet. Es werden
einfache bestimmte Bänke mit eine Folge aus insgesammt 256 Bytes beschreiben, diese wird auslesen und vergleichen. So kann man ganz
einfach dass Vorhandensein und die Größe der RAM-Erweiterung feststellen. Achja, um bekannten Problemen aus dem Weg zugehen, wird
von der höchsten Bank runter zur niedrigsten Bank getestet.
Es war ja zum Teil meine Schuld, dass die Routine nicht funktionierte. Immer auf echte Hardware testen, wenn es dann zu 100% funktioniert, habe ich mein Bestes getan.
Ne sorry, ich war gestern ein wenig angepisst.
Ich kann Deinen Frust verstehen... geht mir manchmal auch so, gerade wenn es negative Rückmeldungen von 128er-Anwendern gibt, die ich nicht nachstellen kann (hab ich keinen). Gott sei Dank funktioniert die RAM-Erkennung in allen Größen bei mir mit realer Hardware und mit VICE schon seit längerem. Aber vielleicht beschwert sich auch nur keiner
Und WinVICE kenne ich nicht, ich bleib beim "Original" VICE
Wenn Du den Code neu schreiben willst und dann was neues hast, gerne hier wieder einstellen. Ich teste und melde dann nur zurück was funktioniert
Display MoreWinVICE verhält sich anders als das Turbo Chameleon 64 oder eine echte REU.
Es werden bei der Bankwahl nur die Bits beachtet, die zur Speichergröße passen.
Greift man z. B. bei 512KB auf die nicht vorhandene Bank 11 zu, dann wird die
4.Bank verwendet (11 = %00001011 da nur drei Bits für 512KB nötig sind, wird
auf %00000011 = 3 zugegriffen, die Zählung beginnt bei 0!). Also liefert meine
Routine hier eine 3 beim TC64 und einer originalen REU, unter WinVICE aber #$ff.
Bei 1MB kommen nur noch total wirre Werte zurück.
Ist notiert. Ich schaue mal nach, was die U2(+) / U64 machen. Und zumindest mit den Anzahl der verwendeten Bits prüfe ich mal den VICE Quelltext...
Edit: Im Moment habe ich aber noch eine andere Sache in der Queue - weiter vorne stehend.
ich hätte mal eine Frage bezüglich Winvice und einer REU, mit der eingestellten Größe von 1MB.
Ich kopiere Daten vom C64-RAM $1000-$CFFF in die REU ab Bank $07 offset $C000.
Starte ich die Routine mit den unten angegebenen Parameter, werden die Daten bis $07FFFF in die REU übertragen, der Rest, also $8000 Bytes landet in Bank $00 der REU
und nicht in Bank $08. Ist das ein normales Verhalten? Mir ist das heute zum ersten mal aufgefallen. Sachen gibt es.
$DF02 = $00
$DF03 = $10
$DF04 = $00
$DF05 = $C0
$DF06 = $07
$DF07 = $00
$DF08 = $C0
Starte ich die Routine mit den unten angegebenen Parameter, werden die Daten bis $07FFFF in die REU übertragen, der Rest, also $8000 Bytes landet in Bank $00 der REU
und nicht in Bank $08. Ist das ein normales Verhalten?
Ja, denn der REC in einer echten Commodore-REU kennt ja nur maximal acht Bänke. Die diversen Umbauanleitungen für mehr als 512 KiB Speicher legen zusätzliche Adressleitungen zum RAM, aber der beim Überlauf hochgezählte Bank-Zähler innerhalb des REC ist halt nur drei Bit breit.
Man könnte auch sagen: Der REC adressiert maximal 512 KiB. Ein REU-Umbau für mehr Speicher erhöht die Anzahl dieser 512-KiB-Blöcke, aber der REC benutzt in jeder Operation immer nur einen dieser Blöcke.
Vielen Danke! Gut dass ich das jetzt gemerkt habe und nicht erst Tage später, nachdem vieles der Arbeit getan ist.
Ich habe die Routine dahingehend geändert, dass bei dem Laden der 800KB Datei, keine Bankübergreifenen Aktionen ausgeführt werden.
Ich hatte nicht schlecht gestaunt, als ein Teil der Daten plötzlich in Bank $00 auftauchten, und mir das interne REU-Direchtory überschrieben hatten.
Das Problem war mir auch bis heute völlig unbekannt.
PS: Geänderten Code gerade getestet. Funktioniert jetzt perfekt.
War mir auch neu, ich hatte immer gedacht, die Entwickler wären Experten genug um das auszugleichen. Könnte man zb. die 3 Bit ausklammern und mit einem TTL ersetzen so änlich wie in der Geo-Ram.
Was meinst du, wie ich gestaunt hatte 
, als die Daten plötzllich in Bank $00 waren. Die, die eigentlich in Bank $08 beheimatet seine sollten.
Ich habe die REU-Ramdisk für Spieleanpassungen dahingehend überarbeitet, dass ich die REU nur noch mit 32kb Parts befülle. Beim Laden der Files, durch die Ramdisk
gibt es keine Dateien, die von Bank $07 bis in die Bank $08 reichen. Das mal ein paar Spiele größer als $512kb sind, kommt auch recht selten vor. Aber ich bin gewarnt,
was passiert, wenn die 512kb überschritten werden und habe die REU-Routine angepasst.
Könnte man zb. die 3 Bit ausklammern und mit einem TTL ersetzen so änlich wie in der Geo-Ram.
Was?!
Es geht um das, was im DMA-Controller passiert. Das kann man nicht "so ähnlich wie in der GeoRAM" machen, denn die hat ja gar keinen.
