Minimales Speichertestprogramm

Hi!

Ich habe soeben ein C64-Speichertestprogramm aus dem Ärmel geschüttelt. Features:
-sehr klein (97 Byte), damit möglichst viel Speicher getestet werden kann
-benutzt nicht den Stack (damit dieser getestet werden kann)
-liegt im Bildschirmspeicher (da man diesen Speicher schon durch Hinsehen bzw. mit dem Cursor selbst testen kann)
-läuft endlos, damit man verdächtige Maschinen auch z.B. die Nacht hindurch testen kann.

Docs:
Laden mit LOAD"MEMTEST",8,1
Starten mit SYS1024
An der Home-Position werden die fehlerhaften Bits aufgeODERt, d.h. der Klammeraffe '@' zeigt an, dass alles in Ordnung ist (da er Screencode Null hat).

EDIT: Man sieht also nicht, welche Adressen fehlerhaft sind - die Hardwaremenschen hier können einem aber anhand des ersten Zeichens sofort sagen, welche Chips getauscht werden müssen.

Die nächsten beiden Bytes dienen als "Heartbeat", an ihnen sieht man, dass noch etwas passiert. Die restlichen zweieinhalb Zeilen sind das Programm, direkt dahinter beginnt der getestete Bereich. Dort sollte sich das Muster regelmäßig ändern.
Die *letzten* beiden Zeichen vor dem getesteten Bereich sind der Pass-Counter; daran sieht man die Anzahl der bisher erfolgten Durchläufe. Mit "Durchlauf" ist hier gemeint, dass der komplette Speicher mit allen 256 möglichen Bytewerten getestet wurde(!), d.h. ein Pass dauert schon ein paar Minuten.

Wer die zwei Bänke eines C128 testen will, kann das Programm mit diesem hier kombinieren.

Have fun!

2nd EDIT: Finger weg von der RESTORE-Taste! Der IRQ ist zwar maskiert, aber den NMI hab ich nicht lahmgelegt...

_____________________________________________________________________

<EDIT>Die aktuelle Version ist V3 und kann in Post #58 gefunden werden.
Eine Eintippversion davon gibt es hier.
Versionen für C16 und Plus/4 gibt es in diesem Thread.
_____________________________________________________________________

Zitat von enTHUSi

Was muss denn alles gehen, damit das Programm ueberhaupt startet?
Jede Menge ROM+RAM+Stack...
Ein absolut minimales CRT waere schoener finde ich.
Also so wenig init wie moeglich und dann Dein Code (der dann im ROM auch groesser sein darf ja).

Klar, auf sehr kaputten Rechnern bekommt man das Programm nicht einmal geladen und kann es somit nicht einsetzen. Es ist eher für "verdächtige" Maschinen gedacht (wie z.B. aktuell BladeRunners 128er), oder als zusätzlicher Test nach Austausch anderer defekter Komponenten.
Test-Cartridges sind auch nicht zu verachten, haben aber den Nachteil, dass man sie haben muss (wenn dem so ist, kann man damit natürlich noch viel mehr anfangen).
Code aus dem ROM laufen lassen verhindert das Problem, dass Fehler im Programmspeicher vorliegen könnten - dafür hat man dann das neue Problem, dass man das RAM unter diesem ROM nicht bzw. nur über ebenfalls problematische Umwege testen kann.

Gerade eben ist mir noch eingefallen, dass man, wenn ich einen Screenshot des Anfangszustands erstellen würde, das Programm nicht einmal laden muss, sondern auch selbst auf den Screen "malen" könnte. Dann braucht man natürlich immer noch ein funktionierendes Kernal, Basic, etc., aber es könnte demjenigen helfen, bei dem Speicherstelle $ba kaputt ist.
Aber ich glaube, für den Zweck mache ich eine Version 2.0 und spare noch ein paar Bytes ein...

Da ich es im Ursprungspost nicht explizit erwähnt habe: Die Zeropage wird vom Programm ebenfalls nicht benutzt und gehört somit zum getesteten Speicher. Abgesehen von den Adressen 0 und 1 (Prozessorport) und den 97 Bytes im Bildschirmspeicher wird also das komplette RAM getestet.

Zitat von Count Zer0

Ich hatte sowas 2008 auch mal verbrochen: ART - DAS Speichertestprogramm für den C64

Cool, in dem Thread wird vieles angemerkt, was mir gestern abend auch eingefallen ist. Mein einziger Beleg dafür, dass ich den Thread vorher nicht gelesen habe, wäre jetzt, dass ich die alte Kernalversion nicht bedacht habe.
Auf jeden Fall sollte eines der Programme hier als Sticky-Thread markiert werden, damit man bei Reparaturanfragen gleich darauf verweisen kann...

Zitat von enTHUSi

Tools ohne cart finde ich nur sinnvoll wenn man einen dem Anschein nach funktionierenden C64 nochmal auf Herz & Nieren testen will.
Dann darf das tool aber auch so gross sein wie es will und selbst Stack/ZP benutzen.

Wieso? Je größer das Programm, desto größer die Wahrscheinlichkeit, dass ein defektes Bit nicht erkannt wird - weil es vom Programm belegt ist und rein zufällig den "richtigen" Wert hat, das gilt für den Code selbst genauso wie für Stack und ZP. Wenn ein Programm sich deshalb selbst woanders hin kopiert, besteht aber wiederum die Gefahr, dass das Original schon kaputtgegangen ist, und zwar so, dass es keine Fehler mehr erkennt. Unwahrscheinlich, aber defekter Speicher war noch nie nett.

Zitat von FXXS

ART ist im 8 Informationen die ich haben sollte bevor ich frage verlinkt.

Oh, das hätte ich allerdings merken sollen. Danke für den Zusatzlink!