Angepinnt Minimales Speichertestprogramm


  • Mac Bacon
  • 8580 Aufrufe 71 Antworten

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Gerrit schrieb:

    Fröhn schrieb:


    Meistens ist aber nicht nur ein Bit defekt, sondern gleich eine ganze RAM-Zeile nicht erreichbar, was bedeutet: In jeder Page (256 Byte) ist dann das entsprechende Bit nicht erreichbar.


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


    Aber der einzige Fehler (neben kalter Lötstellen), den ich bisher bewundern durfte.

    Gerade bei RAM-Fehlern macht wirklich nur ein Cartridge Sinn. Das Retro Replay z.B. eignet sich dafür hervorragend.
  • 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.
    ────────────────────────────────────────────────────────────
    Time of Silence - Time of Silence 2 Development Blog
    ────────────────────────────────────────────────────────────
  • woop schrieb:

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

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

    Gerrit schrieb:

    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...
    Yes, I'm the guy responsible for the ACME cross assembler
  • Mac Bacon schrieb:


    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.


    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.
  • Gerrit schrieb:

    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...
    Yes, I'm the guy responsible for the ACME cross assembler
  • 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.
    Vollmond war gestern!
  • Is ja nett, seltsamerweise hab ich auch die Tage einen RAM-Test geschrieben, und mich mit der MMU vom C128 beschäftigt :)

    EDIT: Ist aber noch nicht ganz fertig, aber wenn ich die Arbeit hier schon sehe, lohnt sich das ja fast nicht mehr. Egal, eine Übung war es alle Mal...
    Wer die Ironie findet, darf sie behalten ^^
  • hoogo schrieb:

    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.
    Yes, I'm the guy responsible for the ACME cross assembler
  • Fröhn schrieb:

    Ich hab noch nie einen C64 erlebt, bei dem das RESET-Bit in $D016 irgendeine Funktion hat.

    ich auch nicht, aber es gab da auch anderweitige beobachtungen... das wurde vor einem gefühlten jahrtausend mal auf comp.sys.cbm diskutiert, ich bin allerdings zu dumm/faul/alt um da grad nen link zu finden :/