Nachtrag: Mein Testprogramm ist gerade abgeschmiert.
Irgend Etwas, oder irgend Jemand hat den Code zur Laufzeit verändert (s.u.).
forum64.de/gallery/index.php?image/5088/
Muss noch checken, ob es die STASH/FETCH Kommandos waren, oder ob mein 128er nicht evtl. ein Problem mit dem RAM-, bzw. der Stromversorgung hat...
EDIT: Den Fehler seht Ihr hinter der Zeile 2190, bzw. 2330.
Ich denke, es gibt auf jeden Fall eine Lösung mit den Timings oder eine Ursache bei diesem C128D. Da ich denjenigen kenne, der das betreffende RAD gelötet und getestet hat, schließe ich aus, dass die RAD-Platine nicht korrekt funktioniert.
Mit Geduld werden wir da weiterkommen.
Wir haben damals vor der Veröffentlichung von RAD im Testerkreis mit allen möglichen C64-Varianten und C128-Varianten getestet. Ich habe hier als Beleg ein unveröffentlichtes Testvideo aus dem November 2022, wo links mein C128DCR (PAL) mit RAD läuft. Also, damals ging das jedenfalls bei mir am C128DCR. Einen C128D habe ich leider nicht, aber es wurde ja schon gesagt, dass eventuell ein individuelles Timing für einen individuellen C128D gefunden werden muss.
In dem Video läuft auch der REU-Checker mal komplett geün durch.
https://www.youtube.com/live/YN4h_FDUYB0?si=rKSitZTtaKr44WIO
emulaThor Jo! Auch ich denke, dass das Modul OK ist... => DON'T PANIC
Detlev siehe RAD Expansion Unit (Fragen, Aufbau, Lösungen, ...)
Erstmal mit den Werten im Menu interaktiv explorieren, dann mit dem REU-Checker schauen, ob es läuft. Ggf. noch die Overclocking Einstellungen anschauen/erhöhen (config.txt). Und im Zweifel immer mit externer Stromversorgung.
Hi Frenetic ,
bei meinem Board geht leider nichts mit dem PI Zero 2 W. 
Zwar habe ich es einmalig(!) geschafft, den Test grün zu bekommen, jedoch war das Ergebnis nicht reproduzierbar.
forum64.de/gallery/index.php?image/5089/
Im Schnitt habe ich ungefähr 15 fehlerhafte Bänke, teilweise auch deutlich mehr, wenn ich das Testprogramm durchlaufen lasse. Die eingestellten Werte-, sowohl das Overclocking, als auch die Timings, seht Ihr, wenn Ihr auf das Bild klickt...
Der PI ist mit dem Overclocking übrigens so weit ausgereizt, dass er so eben noch nicht stehen bleibt. Blöd beim Zero 2 W ist, dass das DRAM-Timing implizit mit an der Core Frequenz (also der GPU Taktfrequenz) hängt. Dies bedeutet, dass man diesen Wert mit hochstellen muss, obwohl man die GPU eigentlich garnicht benötigt.
Sehr schade.
Eine letzte Idee habe ich noch:
Mit etwas Glück ändert sich das Taktverhältnis zwischen DRAM und GPU, wenn ich die Core Frequenz deutlich senke. Das werde ich heute allerdings nicht mehr testen, da ich zuerst herausfinden möchte, ob das so ist und was ich dazu ggf. zusätzlich noch konfigurieren muss.
Detlev: Bevor ich Dir das RAD geschickt habe, habe ich ja diesen REU-Test am C128 hier durchgeführt (PAL, flacher C128) mit Zero 2W. Der Test war immer grün, Timings musste ich bei mir leicht anpassen für den Nuvie-Player. Das heißt, das Ding wurde am C128 erfolgreich getestet und für den C128D müssen wir es nur leicht tweaken, aber das Schwierige ist, die richtige Schraube zu finden, wo man drehen muss.
Ich denke nicht, dass der overclockte Raspi nun zu lahm ist für Deinen C128D. Wie Frenetic schon geschrieben hat, sollte man mit externer Stromversorgung nochmal in Ruhe testen.
Deine Aussage "Leider ist der PI zu schwach." stimmt sachlich nicht, und es macht die Diskussion nicht übersichtlicher, wenn die Details in der Bildergalerie weiter diskutiert werden. 
Ich bin auch an der Problemursache interessiert, aber zwei Dinge hindern mich an einem lokalen Test:
1) Ich habe keinen C128D
2) Ich habe ein 5 Monate altes Baby hier.
Das mit der Ruhe habe ich heute den ganzen Tag gemacht. - Bin aktuell "out of order", kann also nicht vor die Tür. Entsprechend hatte ich viel Zeit.
Ich habe im Bereich des minimalen noch grafisch fehlerfreien Bereichs für WAIT_ENABLE_RW_ADDRLATCH und dem Maximalen in 10er Schritten probiert und dabei WAIT_ENABLE_DATA_WRITING und WAIT_RW_BEFORE_ADDR so lange verändert, bis ich das beste Ergebnis hatte.
Sah es vielversprechend aus, hab' ich noch in kleinen Schritten weitergetestet. Leider waren die meisten Ergebnisse "total erratisch". Es ist vorgekommen, dass ich zwei Mal nur 10 fehlerhafte RAM Bänke hatte und anschließend mehr als 80.
Nur die Werte, die ich bei dem Bild verlinkt habe, führen zu Ergebnisse, die meistens weniger als 30 defekte Bänke haben.
Kein Problem, wenn Du keine Zeit hast. - Wie würdest Du mir auch helfen wollen? 
@Baby: Herzlichen Glückwunsch, bzw. mein Beileid... - Wie groß sind die Ringe unter den Augen?! 
Detlev vielleicht steht es in den vorangegangen Posts und mir fehlt die Zeit die Information zusammenzutragen: wie bist Du beim Testen vorgegangen? Netzteil immer dran? Hast Du den alten verlinkten Post gelesen, welcher Wert kritischer ist? Oft gibt es 2 Einstellungen die funktionieren (bei Problemboards nur eine), die die Bedingungen (Abstände zw. Timings) aus dem verlinkten Post erfüllen. Solange das Menu nicht absolut Artefakt frei ist (und bleibt!), brauchst Du den REU-Checker nicht anwerfen (und da ist auch nicht aussagekräftig wie viele Blöcke rot werden).
Frenetic ja, ich habe die Posts gelesen und bin den Tipps gefolgt.
Meine besten Ergebnisse waren mit ca. 490 und um die 700, wobei interessanterweise die Latenz kaum eine Rolle gespielt hat. Bei niedrigeren Werten so um die 10 hatte ich die wenigsten Fehler.
Auf die Bildschirmausgabe habe ich natürlich auch geachtet.
Im "Originaltrimm" konnte ich bis ca. 525/725 einstellen. - Diese Werte habe ich irgendwo hier im Thread gesehen. Hier sah das Ergebnis teilweise besser aus, war jedoch nicht stabil. Mit aktivem Overclocking hat das Bild ab ca. 700 Artefakte, fängt also an zu flackern...
Ausgehend von den Default Werten habe ich in etwa in 25er Schritten (inkl. des Abstands von 200) rumprobiert. Habe ich etwas gefunden, das nach wenigen Fehlern aussah, habe ich mit der Latenz variiert um einen guten Wert zu finden. Danach habe ich versucht kleinschrittiger (zuerst in 5er, danach in 2er Schritten) den Sweetspot zu finden um dan weiter mit der Latenz zu experimentieren. - War ganz schön langwierig das.
Als alles nicht half, habe ich die Overclocking Einstellungen geändert. Mein Zero 2 W schafft "gerade so" die Werte des 3B. Mit dieser Einstellung wurden die Werte etwas stabiler. Im Originaltrimm, ich glaube die config.txt steht auf 1400MHz CPU Takt, waren die Ergebnisse total erratisch. Mal hat man einen relativ guten Lauf hin bekommen
Ein einziges Mal habe ich einen grünen RAM Test bei einer 16MB REU hinbekommen.
Mir scheint, als hätte ich ein wirklich zickiges Board...
Nachtrag: Die Ursache für das erratische Verhalten, also weshalb die Timings nicht einstellbar sind, könnte übrigens der 128er selbst sein. Ich habe den Eindruck, dass der Fehler thermisch bedingt ist.
Habe inzwischen ein Setting gefunden, in dem die RAD im Kaltzustand zu 90% grün läuft, auch mit 16MB.
Werde, die Tage, mal 'nen Frequenzzähler an den Quarz hängen. Vielleicht verändert sich ja die Taktfrequenz abhängig von der Betriebstemperatur. Alternativ könnten es auch - wie üblich quasi - die Elkos des Netzteils sein. Die sollte ich wohl auch mal tauschen...
Jood ,
danke für die Info. Mein Netzteil fühlt sich auch noch sehr gut an und der Rechner läuft ohne Probleme.
Dann schau' ich mir den Quarz mal genauer an. - Du hast Deinen 128er (auch-) noch nicht am Laufen?
Edit: Ich bekomme, die Tage, noch einen C128D CR zum Vergleich. Der sollte - hoffentlich - nicht ganz so zickig sein.
Vielleicht kann ich so ermitteln was die Ursache für das Problem ist.
Vielleicht kann ich ja Uns Beide-, bzw. Unsere C128D (Plastik) retten, was das RAD betrifft...
P.S.: Hast Du das SideKick64 mal an Deinen Plastik 128er gesteckt? - Dieses Modul läuft bei mir nämlich ohne Probleme...
P².S.: Eigentlich wollte ich ja nur 'ne REU für die SCHALLPLATTE - "Hi!" emulaThor 
- und alles wäre gut gewesen...
(So iss' aber besser, weil ich 'was zum Schrauben hab... - Wie schön, dass Retro Computer so viele Probleme machen... - Was könnte man sonst an dem Zeug so schrauben? )
Mein SideKick64 Zero scheint zu 100% zu laufen.
Der C128 und der C128D haben, so wie ich das gelesen habe, das gleiche Board. => Sollten das Timing Probleme sein, weil die Taktfrequenz läuft, kann ich evtl. "lösen" und Du bekommst auch Deinen Rechner mit dem RAD Modul ans Laufen.
Hallo ,
ich hatte mal versucht mit dem RAD ( Raspberry 3A+ ) mit TAP Writer eine
Cassette zu beschreiben , ging nicht.
https://csdb.dk/release/?id=96477&show=notes#notes
Verstehe ich das richtig, das Programm funkioniert nur mit 1541 Ultimate ?
Ich hatte das dann Alternativ mit ptap und einem DOS Rechner gemacht,
das hat funktioniert.
Display MoreHallo ,
ich hatte mal versucht mit dem RAD ( Raspberry 3A+ ) mit TAP Writer eine
Cassette zu beschreiben , ging nicht.
Ich bilde mir immer ein, ich selbst würde die abgedrehsten Use-Cases für eine REU in der csdb finden, aber das geht ja direkt auf Top#1. Ich würde es glatt ausprobieren, wenn ich doch nur Zeit hätte!
Nun, ich wollte eine Alternative zum XM 1541 Kabel ,
das hatte ich mir mal gelötet .
Damit kann man eine Datei über ptap auf die Datasette
schreiben. Eigentlich wollte ich das installieren von DOS
auf einen "Retro PC" vermeiden.
Da ich mir keine 1541 Ultimate oder ähnliches kaufen wollte,
musste eine Alterative her.
Außer dem Easy Flash 3 ( damit geht es nicht ) , hatte ich bei der Suche
das Programm gefunden. Da es mit dem Original 17xx Ram Extention nicht
geht ( hätte ich da ) , dachte ich mir , ich könnte das RAD so einstellen,
das es geht ( z.B. mehr RAM zuordnen ) . Ging nicht ( oder ich bin zu Blöd )
, also DOS und Parallelport.
