There are 449 replies in this Thread which has previously been viewed 76,029 times. The latest Post (
Es genügt schon, wenn das Datenkabel steckt. Ob eine echte Floppy dahinter ist und ausgeschaltet ist, ist egal...)
genügt schon ? wofür ?
wenn keine Floppy dahinter hängt, soll ein "nacktes Kabel" irgendwas verändern ?
habe ich leider nicht ganz verstanden... danke für auf die Sprünge helfen...
wenn keine Floppy dahinter hängt, soll ein "nacktes Kabel" irgendwas verändern ?
Ein nacktes, unterminiertes Kabel bewirkt und veraendert bei einem Bus ganz viel. 
Ich hatte das zu Anfang auch mit einigen Demos, die Trackloader einsetzen.
Da war meine Konfig Drive 8 emuliert, Drive 9 physikalisch. Und selbst wenn dann die Floppy angesteckt war (so war die Aussage gemeint) und ausgeschaltet war, hat trotzdem die Demo nicht funktioniert. Das Kabel muss abgesteckt werden.
Sowas passert auch am echten C64, vlt. nur nicht im gleichen Szenario, wenn ich bei mir neben der Floppy noch ein SD2IEC angestöpselt habe. Dann laufen (Trackloader ?-)Fastloader wie der m. Giana Sissters org. Diskette nicht immer ohne Bitfehler durch. So dass es Fehler gibt (Titelbild leicht kaputt, Aufhängen beim Versuch per Space dan weiterzuladen). Deswegen habe ich seit je her ich das erkannt habe immer nur noch ein Gerät 'gleichzeitig' am IEC Bus dran. Das ist / läuft dann sicher(er).
das ist aber auch erst seit 2008 (oder wann kam die erste 1541U?) bekannt, das man, sollte etwas nicht funktionieren, erstmal alles andere deaktiviert (alt. Kernal, Module, 2 IEC Gerät etc) bevor man es postet
Wenn man sich seit 2008 mit dem Thema schon beschäftigt hat... Soll aber auch tatsächlich die geben, die mal wieder nach jahrelanger Pause (oder nur 1-Floppy-Betrieb) damit in Kontakt kommen und sich wundern.
Für mich als Nicht-Programmierer ist es sowieso unverständlich, wieso sich ein Trackloader darum schert, dass noch ein weiteres Laufwerk da ist.
evtl. sollte man Please login to see this link. in auch in dem U64 Bereich sticky machen
Erstmal vorab , ich habe eine berufsbedingte leichte Update-Orgien-Aversion. Das kenne ich zur Genüge von moderner Anwendungssoftware, die nur alte Fehler durch neue ersetzt und meine Zeit verschwendet, ohne dass ich was lerne.
Das Problem sind zwei ältere REU-Demos, die Grafikbugs haben , x ander REU-Demos laufen problemlos:
Das wäre der Sollzustand der 2 Demos in Bildern
Please login to see this attachment. 'Freud' von HOAXERS (2016)
Diese BOB-Routine funktioniert bei mir nicht, es eiert nur eine Kugel herum und oben am BS-Rand flimmert's.
Please login to see this attachment. 'REUTASTIC' von CHRISTOPHERJAM (2015)
Bei mir ist der Hintergrund zerfleddert und flimmert auch.
Das sind ja nun Fehler, die mit der DMA-Copy der REU zu tun haben und möglicherweise Timingprobleme ?
Kann man sowas per Konfig (Timing, RAM-Größe der REU) einfangen,da gibt es ja einiges im Menü des U64 ?
Kann jemand mit aktuellerer Firmware die Funktionsfähigkeit bitte checken ?
Ich habe ein Ultimate64 mit Version 1.18 und mir schon mal das 3.10j heruntergeladen. Aber bevor ich mir da wieder alle meine mühseligen restlichen Konfigs zerschieße, wollte ich gerne fragen. Sonst habe ich keinerlei Softwareprobleme mit dem U64, höchstens funktionierendes LAN wäre mal eine nette Neuerung.....nice-to-have, ist ja keine Kernkompetenz des C64....
Danke!
Ohne jetzt die konkreten Beispiele geprüft zu haben: manche dieser Demos funktionieren tatsächlich nur mit einer REU in „originaler“ Größe, also z.B. 512 k. Die Info dürfte in der CSDb zu finden sein oder womöglich auch im jeweiligen Intro der Demo.
Hab's mal mit 521K REU versucht: tatsächlich laufen beide Demos jetzt sauber, vorher mit 16MB REU dann nicht. TOO-MUCH-MEMORY-ERROR 
Also ist 512K erstmal mein neuer Standard.
Ich habe übrigens doch die V1.41 / 3.10a . Da ist 3.10j doch nicht soweit weg und behebt sicher einige kleine Nervigkeiten. Ich entsinne mich da der unsauberen PAL/NTS-Erkennung des RetroReplay-Moduls bei mir und einiger genereller Firmware-Diskussionen damals(TM).
