Tester für ST-RAM-Testprogramm gesucht

[czietz]

Ein Refreshtest für TT/Alt-RAM wäre nett.

Hast Du einen Vorschlag, wie lange man dort auf Bitkipper warten muss? Ich habe von Zeiten von bis zu einer halben Stunde gelesen.

[Arne]

Hast Du einen Vorschlag, wie lange man dort auf Bitkipper warten muss? Ich habe von Zeiten von bis zu einer halben Stunde gelesen.

http://www.memtest86.com/technical.htm#algorithm unter Test 10 steht was von "a few minutes".
Wenn ich bei meiner Karte den Refresh abschalte, wird vermutlich gar kein TT-RAM bei GEMDOS angemeldet.

[goetz @ 3rz]

Das stimmt. Was ist das empfohlene Vorgehen, um zu testen, dass man nicht auf einem ST(E)/MegaST(E) ist? TOS-Version >= 3? _MCH-Cookie?

_MCH-Cookie -- bitte nicht auf TOS-Versionen testen.

Ich denke, es überfordert den Nutzer nicht, je nach Maschine das eine oder andere Programm anzuklicken.

Sicher nicht, v.a. wenn noch eine klare Fehlermeldung ausgegeben wird.

[1ST1]

Das stimmt. Was ist das empfohlene Vorgehen, um zu testen, dass man nicht auf einem ST(E)/MegaST(E) ist? TOS-Version >= 3? _MCH-Cookie?

_MCH-Cookie -- bitte nicht auf TOS-Versionen testen.

Cookies gibts aber erst ab TOS 3.0x/2.0x. Ohne Cookies muss man die TOS-Version abfragen, also bei TOS 1.xx..

[czietz]

Ich hätte jetzt gesagt: Wenn kein _MCH-Cookie oder gar kein Cookie-Jar vorhanden ist, habe ich's mit TOS 1.xx zu tun, also ist der Rechner ein (Mega)ST oder ein STE. Wenn ein _MCH-Cookie vorhanden und das obere Wort 0 oder 1 ist, ist es ein (Mega)ST bzw. (Mega)STE. In allen anderen Fällen würde YAART.TOS dann abbrechen.

[ari.tao]

  Vielleicht fällt mir etwas ein, mit geringem Aufwand zumindest in YAARTTT.TOS gescrollte Meldungen einzubauen... 

Wenn man nicht die BIOS-IO (und erst recht nicht die via VDI) benutzt, sondern die Text-IO des GEMDOS, dann geht das dank des im (originalen) TOS (auch noch in 4.04) eingebauten VT52-Emulators per Ln/Lf automatisch! Und zusätzlich kann man dann die IO-Umleitung des GEMDOS nutzen (mittels Start von YAART*.TOS in einem geeigneten CLI wie zB. MUPFEL oder MCMD oder GULÄM oder...), um die Ergebnisse in eine Datei schreiben zu lassen.
Der Aufwand ist also wirklich gering! (Austausch weniger Funktionen, ibs. kein Zwischenspeicher nötig!).

Kann man nicht beide Tests in ein Programm zusammenführen?   

Auch ich fände das besser.

...gerade weil YAARTTT.TOS nicht den Speicher testen kann, den es selbst schon belegt.

Zusammen gerade mal 13k - das ist doch wirklich klein & niedlich!

[KarlMüller]

Cookies gibts aber erst ab TOS 3.0x/2.0x.

Ab TOS 1.06.

[czietz]

Wenn man nicht die BIOS-IO (und erst recht nicht die via VDI) benutzt, sondern die Text-IO des GEMDOS, dann geht das dank des im (originalen) TOS (auch noch in 4.04) eingebauten VT52-Emulators per Ln/Lf automatisch! Und zusätzlich kann man dann die IO-Umleitung des GEMDOS nutzen (mittels Start von YAART*.TOS in einem geeigneten CLI wie zB. MUPFEL oder MCMD oder GULÄM oder...), um die Ergebnisse in eine Datei schreiben zu lassen.
Der Aufwand ist also wirklich gering! (Austausch weniger Funktionen, ibs. kein Zwischenspeicher nötig!).

Ich nutze auch jetzt schon GEMDOS (vielmehr printf nutzt es), sodass eine Umleitung in eine Datei auch jetzt schon möglich ist. Man muss YAART*.TOS dann nur blind bedienen, weil eben alle Meldungen umgeleitet werden.

Die Schwierigkeit sehe ich eher an anderer Stelle: Du möchtest gescrollte Fehlermeldungen in YAARTTT.TOS, ich möchte aber zumidnest eine fixe Zeile mit der Anzahl der Durchläufe etc. Wie sage ich der VT52-Emulation, dass sie diese Zeile nicht scrollen soll? Eben. Und das noch mit möglichst wenig Unterschieden in der Ausgaberoutine zwischen YAART.TOS und dem "Nebenprodukt" YAARTTT.TOS, für das ich keine komplett neuen Lösungen erfinden möchte.

EDIT: Wenn ich mir das so angucke, sind komplett gescrollte Meldungen (also auch die "Pass x: Test ..."-Meldungen werden gescrollt) auch ganz OK und vor allem mit sehr wenig Aufwand in YAARTTT.TOS einzubauen. Sobald ich die nächste Version verteile, kannst Du mir ja sagen, ob Du Dir das so vorgestellt hast.

[pakman]

Schaltest Du für diesen Test beim 68030 den CPU-Cache explizit aus?

[czietz]

Schaltest Du für diesen Test beim 68030 den CPU-Cache explizit aus?

Nein.

a) Was ist der portabelste Weg das zu tun? Es muss auf allen TOS-Versionen funktionieren, die den 68030 unterstützen. Und: Der Code darf dabei nicht abstürzen, wenn er auf einem 68000 ausgeführt wird.
b) Hatte ich schon erwähnt, dass ich eigentlich keine Zeit in Extra-Features für YAARTTT stecken wollte? Mittlerweile denke ich fast, ich hätte diese Version gar nicht erst veröffentlichen sollen. Jetzt ist die Mehrzahl der Feature-Requests aber für diese Version, ich habe nur Arbeit damit und -- mangels TT -- weder einen Vorteil davon noch eine Möglichkeit, das überhaupt richtig zu testen.
c) Das Zugriffspattern des Moving-Inversions-Algorithmus sorgt dafür, dass kaum Zugriffe aus dem Cache bedient werden können, sodass selbst mit aktivem Cache die meisten Fehler gefunden werden sollten.

[Lynxman]

Ruhm und Ehre sind Dir sicher!

Auf jeden Fall meine Dankbarkeit, denn ich kann so ein Testprogramm sehr gut brauchen!

Ich persönlich sehe das mit dem Cache nicht als so kritisch, ich schalte vor einem Speichertest beim Falcon bisher auch immer den CPU-Cache aus.

Leider kann ich mangels funktionierendem Falcon immer noch nicht testen. 

Auf jeden Fall kann ich schon verstehen was Du damit meinst das Du ausser Arbeit nichts davon hast und es noch nicht mal selber testen kannst.
So was mache ich zur Zeit auch, ist eine Hardwaregeschichte, da baue ich was nach, muss da auch noch was anpassen, die Teile besorgen, die Leiterplatte und irgendwann dann noch zusammenlöten, einpacken und zur Post bringen. Testen und selber anwenden kann ich das auch nicht. Auf jeden Fall hilfts der Atari-Gemeinde und das ist mir dank genug.

Von daher ist das mit der Dankbarkeit auch ernst gemeint und ich finde es großartig was Du da gemacht hast. Egal ob Du die Features noch einbaust oder nicht.

[pakman]

a) Was ist der portabelste Weg das zu tun? Es muss auf allen TOS-Versionen funktionieren, die den 68030 unterstützen. Und: Der Code darf dabei nicht abstürzen, wenn er auf einem 68000 ausgeführt wird.

Die beste Strategie ist:

1. Grundsätzlich den Cache an lassen (sonst schaltest Du auch den Burst Mode mit ab..)

2. _CPU Cookie checken: Falls ein 68030 vorhanden ist: Write Allocation abschalten (damit nicht schon beim Schreibzugriff ein Eintrag im Cache erfolgt)

3. Darauf achten, dass nur der erste Lesezugriff die Daten aus dem RAM holt, jeder weitere aber auf den Cache zugreift. Falls man auf eine Adresse mehrfach hintereinander lesend zugreifen will, dann sollte man dazwischen jeweils einen Dummy-Lesezugriff auf Adresse + 256 machen. Das überschreibt den Cache dann mit den Dummy-Daten, so dass die Daten von der Zieladresse immer wieder neu geholt werden müssen.

Ach ja: Das mit Ruhm und Ehre unterschreibe ich auch!!

[czietz]

Beta-Version v.0.1.7.

Neu:

• Allgemein: Tests beschleunigt, z.B. braucht ein Test auf einem ST mit 4 MiB RAM nun gut eine Minute weniger pro komplettem Durchlauf.
• Allgemein: Die Meldungen während des Tests können per Ausgabeumleitung in eine Datei geschrieben werden. (Das ging vorher ja auch schon, nun kommen aber die Prompts immer auf den Bildschirm und nur die Testmeldungen in die Datei.)
• YAART.TOS: Gibt nun eine Fehlermeldung aus, wenn es nicht auf einem ST läuft.
• YAARTTT.TOS: Gescrollte Meldungen, besonders sinnvoll, wenn man sie in eine Datei schreiben lässt, siehe oben.
• YAARTTT.TOS: Auf einem 68030 wird nun "Write Allocation" des Caches abgeschaltet, wie von @pakman vorgeschlagen. Die Lesezugriffe finden so statt, dass sie nicht aus dem Cache bedient werden sollten.

PS: Wenn nun endlich mal jemand einen echten RAM-Fehler damit  finden würde... 

[Arne]

PS: Wenn nun endlich mal jemand einen echten RAM-Fehler damit  finden würde... 

Zufrieden? 

[czietz]

Zufrieden? 

Ja, kaputt!  Danke!

[pakman]

Beta-Version v.0.1.7.
PS: Wenn nun endlich mal jemand einen echten RAM-Fehler damit  finden würde... 

Erstmal Danke für die neue Version!

Sieht bei mir so aus, dass die Version 0.1.7 beim ersten Fehler hängen bleibt.
Die Version 0.1.5 zählte dagegen die Fehler korrekt weiter.

Konkret:
Pass 1, Test #1: Läuft ohne Fehler durch
Pass 1, Test #2: Etwa da, wo Version 0.1.5 den ersten Fehler meldete, springt bei 0.1.7 der Cursor plötzlich in die erste Spalte, blinkt weiter, aber sonst passiert nichts mehr (habe eine Halbzeit plus Nachspielzeit gewartet..)

[czietz]

Sieht bei mir so aus, dass die Version 0.1.7 beim ersten Fehler hängen bleibt.
Die Version 0.1.5 zählte dagegen die Fehler korrekt weiter.

Konkret:
Pass 1, Test #1: Läuft ohne Fehler durch
Pass 1, Test #2: Etwa da, wo Version 0.1.5 den ersten Fehler meldete, springt bei 0.1.7 der Cursor plötzlich in die erste Spalte, blinkt weiter, aber sonst passiert nichts mehr (habe eine Halbzeit plus Nachspielzeit gewartet..)

YAARTTT.TOS, nehme ich an? Das ist seltsam, ich habe zwischen 0.1.5 und 0.1.7 nichts geändert, das dieses Verhalten erklären könnte, insbesondere weil es nach Deiner Beschreibung so klingt, also ob das Programmen mitten in...

Code: [Auswählen]

printf("\r\nPass: %3ld. ", niter+1);... hängen bliebt. Dass das üblicherweise nicht passiert, zeigt ja der Screenshot von Arne.

Und der einzige funktionale Unterschied in den tatsächlichen Tests ist, dass nun, wie vorgeschlagen auf einem 68030 die Write Allocation abgeschaltet wird. Das kann doch auch nicht zum Absturz führen?

Das einzige, was ich mir vorstellen kann, ist, dass durch einen RAM-Fehler der Programmcode selbst im Speicher beschädigt wird und dann abstürzt. Das ließe sich testen, indem Du GEMDOS dazu bringst, YAARTTT.TOS an eine andere Stelle im Speicher zu laden. Z.B. startest Du YAARTTT.TOS aus einer Shell heraus, die ja selbst auch schon RAM belegt.

[ari.tao]

Von mir auch ein dickes Lob für Deine Arbeit!
Habe zwar zur Zeit keine Probleme mit dem RAM, aber vor einigen Jahren mal hätte ich gut jede Hilfe brauchen können.

Sobald ich die nächste Version verteile, kannst Du mir ja sagen, ob Du Dir das so vorgestellt hast.   

Jau, super!
Lediglich in YAART.TOS fehlt am Schluß noch eine Warteschleife, weil jetzt der Text verschwindet, bevor man ihn lesen kann.

[ditto]

So, nun bin ich auch endlich dazu gekommen, deinen Speichertest zu testen.
Bei mir verhalten sich zwei 64mb PS/2 Simms (50ns) etwas merkwürdig.
Jeder einzeln scheint zu funktionieren und verschiedene Speichertests geben auch keine Fehler aus.
Stecken beide zusammen in den Slots, werden nur etwa 75mb erkannt und es zeigen sich nur noch Fehler beim testen.
Eben habe ich nur einen der beiden getestet und deine neue Version 1.1.7 dazu verwendet.
Test #1 und Test #2 ohne Fehler. Sobald Test #3 (Test #3 Moving inversions, 8 bit, Pattern 0101) erscheint, steigt das Programm aus.
Ich habe es wiederholt mit Kaltstart des Rechners probiert, das Ergebnis war immer das selbe.
Die Version 1.1.5 läuft ohne Fehler durch.

[czietz]

Danke für's Testen. Leider macht es sich bemerkbar, dass ich keine echte Hardware zu testen von YAARTTT.TOS habe, sodass die Fehlersuche nahezu unmöglich wird.

Eben habe ich nur einen der beiden getestet und deine neue Version 1.1.7 dazu verwendet.
Test #1 und Test #2 ohne Fehler. Sobald Test #3 (Test #3 Moving inversions, 8 bit, Pattern 0101) erscheint, steigt das Programm aus.

Was genau meinst Du mit "steigt aus". Hängt sich auf, wie bei pakman? Beendet sich einfach ohne Meldung/Bomben?

Die Version 1.1.5 läuft ohne Fehler durch.

Naja, ohne Fehler sollte es dann ja auch nicht durchlaufen. Welcher Speichertest findet denn Fehler, wenn beide SIMMs installiert sind?