Hallo Besucher, der Thread wurde 40k mal aufgerufen und enthält 84 Antworten

letzter Beitrag von 64erGrufti am

Minimales Speichertestprogramm

    Kann ich nicht bestätigen. Mein Sperrmüllfund C64 hatte genau 2 kaputte Bits im gesamten Speicher und die auch noch in unterschiedlichen RAM-Bausteinen. Das ist aber bislang meine einzige Erfahrung mit Speicherdefekten.

    Zitat von woop

    Nur der Vollständigkeit halber, hier gabs nochmal sowas: Noch ein Speichertester...


    Auch nicht schlecht - wird Zeit für ne Compo. :D


    Zitat von Gerrit

    Das ist der typische Fehler der MT4264. Aber es ist nicht der einzige mögliche Fehler eines DRAM.


    Hm, wie wahrscheinlich ist denn, dass eine Speicherzelle ihren Inhalt erst nach einer gewissen Zeit verliert? Kann der Kondensator einer DRAM-Zelle an Kapazität verlieren?
    Ich frage, da mir beim Ansehen von Count Zeros Code aufgefallen ist, dass dort jede Speicherzelle erst beschrieben und dann sofort getestet wird, und das viermal hintereinander (mit vier verschiedenen Werten). Mein Programm dagegen beschreibt erst den kompletten Speicher mit dem aktuellen Testwert, und dann fängt es mit dem Vergleichen an, d.h. der Defekt einer Speicherzelle hätte statt nur vier Taktzyklen eher eine komplette Sekunde Zeit, um sich zu manifestieren.


    Wollte man diese Art von Defekt besonders genau überprüfen, müsste das Testprogramm eine einzige Schreibschleife absolvieren und dann in eine Endlos-Leseschleife münden. Dann bräuchte man natürlich separate Programmläufe für alle-Bits-auf-Null und alle-Bits-auf-Eins...

    Zitat von Mac Bacon


    Hm, wie wahrscheinlich ist denn, dass eine Speicherzelle ihren Inhalt erst nach einer gewissen Zeit verliert? Kann der Kondensator einer DRAM-Zelle an Kapazität verlieren?


    Ja, ist denkbar. Wobei der nächste Refreshzyklus schon nach ein paar ms vorbeischaut und der VIC auch den Speicher ausliest (und damit refreshed). Eigentlich müsste man zum Test das Bild abschalten damit der VIC Ruhe gibt und die CPU nach dem Beschreiben des RAMs in eine sehr kleine Endlosschleife schicken aus der sie dann der CIA-Timer per IRQ/NMI holt und mit dem Lesetest beginnt. Sonst kann es sein, daß du morsches RAM hast, aber die Aktivität von VIC und CPU ausreicht damit das MEIST nicht auffällt.


    Zitat


    Ich frage, da mir beim Ansehen von Count Zeros Code aufgefallen ist, dass dort jede Speicherzelle erst beschrieben und dann sofort getestet wird, und das viermal hintereinander (mit vier verschiedenen Werten). Mein Programm dagegen beschreibt erst den kompletten Speicher mit dem aktuellen Testwert, und dann fängt es mit dem Vergleichen an, d.h. der Defekt einer Speicherzelle hätte statt nur vier Taktzyklen eher eine komplette Sekunde Zeit, um sich zu manifestieren.


    Deine Idee ist besser, aber jeder Lesezugriff ist bei einem DRAM auch ein Schreibzugriff da der Inhalt einer DRAM-Zelle beim Lesen zerstört wird und zurückgeschrieben werden muss. Also muss man noch etwas mehr tun.

    Zitat von Gerrit

    Eigentlich müsste man zum Test das Bild abschalten damit der VIC Ruhe gibt und die CPU nach dem Beschreiben des RAMs in eine sehr kleine Endlosschleife schicken aus der sie dann der CIA-Timer per IRQ/NMI holt und mit dem Lesetest beginnt. Sonst kann es sein, daß du morsches RAM hast, aber die Aktivität von VIC und CPU ausreicht damit das MEIST nicht auffällt.
    [...]
    jeder Lesezugriff ist bei einem DRAM auch ein Schreibzugriff da der Inhalt einer DRAM-Zelle beim Lesen zerstört wird und zurückgeschrieben werden muss.


    :facepalm: Ok, letzteres hätte mir auch einfallen müssen; damit ist die Idee von 1-mal schreiben und dann nur noch lesen natürlich hinfällig.
    Statt eines CIA-Timers würde ich dann allerdings die Restore-Taste bevorzugen, damit die Dauer des Tests dem Benutzer überlassen bleibt:
    1. Der Benutzer startet das Programm, das Programm deaktiviert die Bilderzeugung und löscht den kompletten Speicher außer sich selbst und dem NMI-Vektor. Dann geht die CPU in eine "label: jmp label"-Endlosschleife.
    2. Der Benutzer fliegt zwei Wochen in Urlaub, das RAM gammelt vor sich hin und wird lediglich hin und wieder vom VIC refreshed.
    3. Der Benutzer kommt zurück, drückt Restore, der Test-Teil des Programms wird aktiv und überprüft, ob das RAM noch den gewünschten Inhalt hat. Fehler werden aufge-ODER-t, fertig.


    Das klingt doch mal nach einem Plan!


    ...danach muss der Benutzer aber noch ein zweites Mal in Urlaub, um auch den anderen möglichen Bitzustand zu überprüfen...

    Afaik ist das Refresh durch den VIC nicht abschaltbar. Das bezieht sich nicht auf die gerade vom VIC gelesenen Speicherstellen.
    Und wie sieht es mit Querbezügen einzelner Bits aus? Memtest86 hat ja eine ganze Palette verschiedener Pattern, um auch irgendwie duplizierte Bits entdecken zu können.

    Zitat von hoogo

    Afaik ist das Refresh durch den VIC nicht abschaltbar. Das bezieht sich nicht auf die gerade vom VIC gelesenen Speicherstellen.
    Und wie sieht es mit Querbezügen einzelner Bits aus? Memtest86 hat ja eine ganze Palette verschiedener Pattern, um auch irgendwie duplizierte Bits entdecken zu können.


    Die Bilderzeugung abzuschalten soll nur verhindern, dass ein vorhandener Fehler in z.B. den Spritepointern oder im Screen-RAM durch die in den Lesezugriffen versteckten Schreibzugriffe verdeckt wird - die normalen Refreshzyklen kommen natürlich trotzdem, klar.
    Querbezüge einzelner Bits sollten (tm) eher selten sein, da ja jedes Byte auf acht (bzw. zwei) Chips aufgeteilt ist. Ein wirklich guter Speichertest sollte sie natürlich überprüfen - als Algo fällt mir da ein, dass im ganzen Speicher nur ein einziges Bit gesetzt wird, und dann wird überprüft ob der restliche Speicher immer noch gelöscht ist. Dieses eine Bit über alle Positionen schieben, fertig. Macht also knapp 65536*8*65536 Lesezugriffe, und dann das Ganze nochmal invertiert...
    Dann gäbe es noch Fehler durch kurzgeschlossene oder unterbrochene Adressleitungen - dabei müsste mein Programm sich selbst überschreiben und abstürzen, so dass dieser Fall zumindest nicht ignoriert wird.
    Memtest86 hat außerdem noch die Eigenschaft, mit verschiedenen Adressierungsmodi auf den Speicher zuzugreifen - so wurde mal ein Cyrix-Prozessor bzw. ein Mainboard als Ursache für einen Fehler identifiziert, der ursprünglich dem RAM zugeordnet wurde.