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

letzter Beitrag von 64erGrufti am

Minimales Speichertestprogramm

    Mal eine allgemeine Anmerkung: Ich finde es reichlich unfair, wie hier Kritik abgeladen wird (da schließe ich jetzt mal konstruktive Kritik mit weiteren Ideen natürlich aus). Ein Speichertestprogamm wird immer eine unvollkommene Sache bleiben, ganz einfach weil das Programm auch nur eine "abstrakte" Sicht auf die möglichen elektronischen Probleme hat. Dazu gehört natürlich auch die Problemstellung, dass man um auf dem möglicherweise defekten System testen zu können natürlich ein teilweise funktionierendes System braucht. Auch Cartridges sind da nicht DIE Lösung. Das hier vorgestellte Programm ist jedenfalls ein sehr guter Ansatz, um möglichst viel RAM rein software-basiert zu testen. :thumbup:

    Zitat von Mac Bacon


    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.


    Der VIC führt einen kompletten 256 Zyklen Refresh alle 4ms durch (5 Zyklen pro Scanline). Marginales RAM welchem das nicht mehr ausreicht solltest du nach ein paar Sekunden schon erkennen können. Wobei man natürlich zweimal testen muss, einmal mit $FF und einmal mit $00 da eine volle DRAM-Zelle je nach Position in der Matrix und DRAM-Hersteller als 0 oder 1 gewertet wird. Zumindest bei den C64 mit 8 RAMs braucht man keine weiteren Muster testen da jedes RAM nur für 1 Bit zuständig ist und damit gegenseitige Beeinflussung innerhalb der RAMs ausgeschlossen ist. Bei den 41464 könnte das anders sein da hier immer 4 Bits in einem IC zu finden sind.


    Viel wichtiger ist es dafür zu sorgen, daß weder CPU noch VIC durch ihre Zugriffe für weitere Refreshes sorgen. Auch musst du mindestens 2 Endlosschleifen haben weil jeder JMP auf sich selbst 3 Bytes lang ist und damit 3 DRAM-Zeilen dauerhaft mit Refresh versorgt. Gleiches gilt für die Dummy-Reads des VIC, aber das war nur eine Speicherstelle, oder? ($3FFF?).

    Zitat von hoogo

    Sollte ohne RAM-Refresh nicht zumindest bei den älteren 64ern dann ganz schnell der Speicher kaputt sein?


    DRAMs gehen ohne Refresh nicht kaputt. Ohne Refresh verlieren sie nach kurzer Zeit nur die gespeicherten Daten, mehr nicht.


    Nach allem was ich bisher finden konnte, kann man beim VIC den Refresh nicht abschalten. Das erwähnte Reset-Bit hat bei den 6567/6569 keine Funktion. Es gibt Leute die das auf den Die-Shots nachverfolgt haben.

    Besteht eine Möglichkeit diesen Test für den C128 im nativen 128er Modus umzusetzen? Da meine Maschine im 128er-Modus häufiger abschmiert vermute ich dass es mit der erhöhten Taktfrequenz zu tun haben könnte. Daher wäre ein Test "highspeed" sehr interessant :)

    Den Testalgorithmus selbst auf den 128er-Modus umzustricken, wäre keine große Sache, da müsste ich eigentlich nur die Initialisierung ändern (da das Ausblenden von ROMs und I/O-Chips bei C64 und C128 unterschiedlich gemacht wird).
    Alternativ könnte man auch im 64er-Modus bleiben und von dort aus auf 2 MHz schalten.
    Das Problem wäre aber, dass man im FAST-Modus den Output nicht mehr sehen kann, denn das Programm schreibt das aktuelle Ergebnis ja direkt in Speicherstelle 1024 (HOME-Position auf dem VIC-Screen), und bei 2-MHz-Betrieb ist die VIC-Bilderzeugung deaktiviert.
    Hm, ich könnte natürlich beim Auftreten des ersten Fehlers auf 1 MHz zurückschalten oder so...


    Schauen wir doch erstmal, ob wir Wizball im 64er-Modus zum Laufen bekommen - sollte es an einem RAM-Defekt in der Zeropage liegen, können 64er- und 128er-Modus durchaus unterschiedliche Fehlerbilder aufweisen.

    Hi!


    Ich hab jetzt noch ein bisschen dran rumgefrickelt und eine neue Version gemacht: Die beiden Heartbeats sind verschwunden (man sieht ja eh, dass da irgendwas passiert), dafür wird jetzt auf den Kleinbuchstaben-Zeichensatz umgeschaltet (das sollte das Erkennen des Resultats erleichtern) und das erste Zeichen eingefärbt (für den Fall, dass ein ganz alter Kernal läuft, der das nicht selber tut).
    Und wo ich eh schonmal dabei war, hab ich die Größe von 97 auf 86 Bytes reduziert. Unglaublich, wie ich vorher mit dem Speicher rumgeaast habe... :whistling:
    Laden, starten und Betrieb laufen wie gehabt:

    Wie vorher gilt: Das Ergebnis wird an der HOME-Position angezeigt; das Zeichen '@' steht für "kein Fehler gefunden", alle anderen Zeichen (auch ein reverses '@'!) geben über ihren Screencode die defekten RAM-Chips an (mir ist inzwischen allerdings eingefallen, dass die Codes für Space, Shift-Space und CBM-G/H/N/M leider nicht eindeutig sind - naja, Arbeit für Version 3).
    Die letzten beiden Zeichen vor dem Testbereich zählen die Programmdurchläufe mit.


    Der Source ist jetzt etwas ausführlicher kommentiert, ich übernehme allerdings keine Verantwortung für Haarausfall, Muskelschwund oder andere Leiden, die beim Betrachten des Quellcodes evtl. auftreten könnten...

    Jetzt muß ich doch meine erste Version auch mal präsentieren.


    Man sieht schon, du hast eine ganz andere Art zu programmieren :)


    EDIT: Die erste Version war buggy, da war noch Testcode mit drin. Jetzt passts...

    Zitat von Gerrit

    Viel wichtiger ist es dafür zu sorgen, daß weder CPU noch VIC durch ihre Zugriffe für weitere Refreshes sorgen. Auch musst du mindestens 2 Endlosschleifen haben weil jeder JMP auf sich selbst 3 Bytes lang ist und damit 3 DRAM-Zeilen dauerhaft mit Refresh versorgt. Gleiches gilt für die Dummy-Reads des VIC, aber das war nur eine Speicherstelle, oder? ($3FFF?).


    Die Endlosschleife der CPU müsste man sogar auch ganz ohne DRAM-Refreshes hinbekommen - ich denke da an einen zusammenhängenden Bereich von siebzehn Bytes im I/O-Space... :whistling:


    Zitat von kbr

    Man sieht schon, du hast eine ganz andere Art zu programmieren :)


    Jein - es macht mitunter schon einen enormen Unterschied, ob man auf Geschwindigkeit optimiert oder auf Größe. Und der Verzicht auf JSR/RTS tut in diesem Fall sein Übriges. ;)

    Zitat von Mac Bacon


    Die Endlosschleife der CPU müsste man sogar auch ganz ohne DRAM-Refreshes hinbekommen - ich denke da an einen zusammenhängenden Bereich von siebzehn Bytes im I/O-Space... :whistling:


    Nein, das geht nicht. VIC erzeugt pro Taktzyklus zwei komplette _RAS/_CAS-Zyken. Einmal für die CPU (PHI0 HIGH) und einmal für sich selbst (PHI0 LOW). _RAS ist direkt mit dem RAM verbunden und damit wird das RAM pro Takt zweimal aufgeweckt und bekommt eine Zeilenadresse übergeben. Das alleine reicht schon um die Zeile im DRAM auszulesen und damit muss sie zurückgeschrieben werden. Das passiert sobald _RAS wieder HIGH geht. Deshalb muss _RAS eine bestimmte Zeit HIGH sein bevor es wieder nach LOW wechseln darf.


    Ob das RAM jetzt wirklich angesprochen wird oder nicht wird per _CAS entschieden (welches deshalb durch die PLA geht), aber für einen Refresh reicht _RAS. Das Wort dafür ist 'RAS-only-Refresh'.


    Egal wo dein Code steht (könnte im ROM sein!), das RAM bekommt pro Taktzyklus zwei Refreshzyklen ab. Welche Zeile die refreshen hängt von A0 bis A7 der CPU bzw. des VIC ab. Es gibt keine Möglichkeit das abzuwürgen. Man kann mit der erwähnten Endlosschleife nur den Bereich minimieren.

    Hi!


    Ich gebe zu, drei Versionen in vier Tagen sind schon irgendwie albern. Aber mir ist eine signifikante Verbesserung des Algorithmus eingefallen, und wenn man schon von der Muse geküsst wird, wäre es doch schade um die Inspiration... :whistling:


    Die vorigen Versionen haben den Speicher abwechselnd gefüllt und getestet. Veränderungen durch Speicherdefekte konnten aber natürlich nur gefunden werden, wenn sie zwischen dem Füllen und dem Testen auftraten. Traten sie hingegen zwischen dem Testen und dem nächsten Füllen auf, so blieb das unbemerkt; d.h. das Programm hat den Speicher nur für rund die Hälfte der Laufzeit wirklich überwacht.
    Der neue Algorithmus dagegen beschreibt eine Speicherzelle direkt nach dem Test auf ihren Sollwert bereits mit dem Sollwert für den nächsten Durchgang, d.h. effektiv wird der Speicher jetzt die ganze Laufzeit überwacht und die Leistung des Programms somit um knapp 100% gesteigert. ;)


    Sonstige Änderungen: Werden Fehler gefunden, so wird dies nicht mehr nur in der HOME-Position angezeigt, sondern jetzt auch direkt rechts daneben, allerdings dort mit komplett invertiertem Bitmuster. Dies löst das Problem mit den nicht 100%ig unterscheidbaren Screencodes, das ich beim Release von Version 2 erwähnt hatte. Diese Anzeige mag nicht sonderlich komfortabel sein, aber Komfort würde das Programm nur unnötig aufblähen...


    EDIT: Das zweite Zeichen ist nur gültig, wenn das erste Zeichen kein Klammeraffe ('@') mehr ist!


    Ach ja, und wo ich schon einmal dabei war, hab ich die Größe von 86 auf 84 Bytes reduziert. Unglaublich, wie ich vorher mit dem Speicher rumgeaast habe... :whistling:
    Laden, starten und Betrieb laufen wie gehabt:


    Have fun!


    P.S. Nächste Woche gibt es dann die 42-Byte-Version. Okay, das war jetzt gelogen.

    Nicht schlecht. Die Kürzungen am Anfang könnten Probleme bei alternativen Kernals machen (oder Datassettennutzer ärgen), aber der ISC-Trick ist schick. In der Hinsicht (Illegals) fehlt mir schlicht die Übung/Erfahrung.
    Wenn das Ergebnis nicht in $0400 stehen muss bzw. das Programm nicht ab dem ersten Byte ausführbar sein muss, könnte man natürlich auch noch was einsparen, aber da wollte ich vom einmal etablierten Weg nicht abweichen. ;)