atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: czietz am Di 05.07.2016, 22:29:57
-
Hallo,
an den bislang für den ST verfügbaren Speichertestprogrammen stört mich, dass sie meist sehr simpel gestrickt sind. Sie finden natürlich offensichtliche Probleme mit dem RAM, aber keine subtilen Fehler, die nur nach vielen Durchläufen oder mit bestimmten Testmustern auftreten. Für den PC gibt's mit Memtest86 ja Software, deren Testalgorithmen speziell optimiert wurden, um auch solche Fehler zu finden.
Ich habe mich nun daran gemacht, einen Teil dieser Algorithmen in einem Testprogramm für den Atari ST umzusetzen. Leider -- nein, eigentlich glücklicherweise -- habe ich aber keinen Atari mit Speicherfehlern, sodass ich das Programm nicht richtig testen kann. (Ich kann natürlich in Steem Fehler provozieren, aber ich wüsste schon gerne, dass das Programm auch "echte" Fehler findet.)
Also: Hat hier jemand einen ST (wirklich einen ST, TT-RAM oder Altram wird derzeit nämlich nicht getestet) mit bereits bekanntem Speicherfehler und möchte mein Programm darauf loslassen?
-
Habe keinen ST von dem ich wüsste das er einen Speicherfehler hat.
Könnte aber das Proggi brauchen um meine Speichererweiterungen zu testen.
Auch für TT-Ram würde ich so was gerne haben. (Magnum Falcon, Magnum ST)
Ich wäre Dir sehr dankbar wenn Du das Programm irgendwann mal freigibst.
-
Schau Dir mal den Thread an:
http://atari-forum.com/viewtopic.php?f=15&t=30080&start=25
Evtl. wäre das Testprogramm ja auch was für exxos.
Der hat auf jeden Fall gerade einen STE mit einem Speicherproblem.
-
Evtl. wäre das Testprogramm ja auch was für exxos.
Der hat auf jeden Fall gerade einen STE mit einem Speicherproblem.
Rat mal, wer "czietz" in jenem Thread ist, der exxos dort ein Speichertestprogramm programmiert hat. :D Leider ist ihm sein betroffener STE wohl beim Basteln kaputt gegangen...
-
Haha, tja, schnell geklickt und den Thread nicht mehr durchgegangen. :D
-
Ich habe auch großes Interesse an dem Programm ...
Habe einen Mega ST4 mit PS/2 Simm Sockel aber leider kein schadhaftes Simm zum Probieren. Wenn du mir sagst wie ich so ein 4MB Simm kaputt machen kann so das der ST noch läuft ?
-
Danke, Frank, für das Angebot. Leider fällt mir kein Weg ein, ein SIMM so zu beschädigen, dass der ST noch läuft (und ein Bild anzeigt). Ich habe aber unterdessen wagemutig in meinem ST über einen Widerstand und ein Kabel kurzzeitig RAM-Pins z.B. auf 5V gezogen und damit Fehler provoziert. Falls der Atari dabei nicht gleich ganz abgestürzt ist, hat mein Programm diese Fehler auch gefunden.
Jemanden mit ST mit echten RAM-Fehlern hätte ich als Testkandidaten aber trotzdem gerne...
-
Hallo,
Mein ste hat hin und wieder Macken die auf ramfehler deuten, könnte es ja mal testen aber würde erst am Wochenende dazu kommen.
-
Ich stelle mal mein YAART.TOS (Yet Another Atari RAM Test) in der Beta-Version v.0.1 der Öffentlichkeit zur Verfügung. Von der Testtiefe halte ich es jetzt schon für besser als viele andere Atari-RAM-Testprogramme.
Bitte beachtet folgendes, da ich noch keine Anleitung geschrieben habe:
- Es handelt sich, wie gesagt, um eine Beta-Version. Ich konnte sie nur mit künstlich erzeugten RAM-Fehlern testen. Es ist nicht garantiert, dass sie (alle) echten RAM-Fehler findet. Ebenso können andere Bugs enthalten sein.
- YAART ist wirklich nur für STs und STEs geeignet und testet ST-RAM. Eine Version, die Alt-RAM oder TT-RAM testet, ist noch in Arbeit.
- YAART möchte natürlich möglichst viel RAM testen können. RAM-Disks, Treiber oder sonstige AUTO-Start-Programme, die selbst Speicher belegen, verhindern das. Wenn YAART keine Konfiguration findet, die einen Test erlaubt, meldet es das und stoppt. Ich empfehle, YAART auf eine Diskette zu kopieren, den ST ohne Festplatte usw. neuzustarten und dann YAART auszuführen, ggf. sogar als YAART.PRG im AUTO-Ordner der Diskette.
- Genau wie das Diagnose-Cartridge und anders als alle anderen Testprogramme, die ich für den Atari kenne, kann YAART auch den eigentlich vom TOS belegten Speicher testen. Dieser "low memory"-Test findet aber nur einmalig beim Programmstart statt und hat eine deutlich geringere Testtiefe als der Test des freien RAMs, weil TOS es verständlicherweise nicht mag, wenn man zu lange in seinen Datenstrukturen herumschreibt.
- Nach einem Tastendruck folgt der eigentliche RAM-Test mit einem Teil der sehr gut testenden Algorithmen aus Memtest86. Zusammen mit dem "low memory"-Test wird damit fast der komplette Speicher des ST getestet, bis auf ca. 8 kByte, die YAART selbst belegt und ca. 3,5 kByte Videospeicher, der für die Statuszeile verwendet wird. Dieser Test läuft in einer Endlosschleife, auf dem Bildschirm werden die Anzahl der Durchläufe, der derzeitige Test und die Anzahl der Fehler angezeigt, im Fehlerfall auch die Fehleradresse. Zum Abbruch muss die ALT-Taste gedrückt und gehalten werden, bis sich YAART beendet.
Viel Spaß und gebt mir bitte Feedback.
-
Super das Du es zur Verfügung stellst.
Habe mir jetzt ein USB-Disketten bestellt weil ich eben entdeckt habe das ich ja gar keine Floppy mehr im PC habe... :o und anders bekomm ichs nicht in meine STs...
-
Hier das Update auf die Beta-Version v.0.1.5 von Yet Another Atari RAM Test, einer Umsetzung besonders tauglicher RAM-Testalgorithmen für Atari.
Neu:
- Es gibt jetzt YAARTTT.TOS, eine Version, die auch TT-RAM und Alt-RAM testen kann und nicht nur auf STs, sondern auf jedem Atari-System ((Mega)ST(E), TT, Falcon) laufen sollte. Sie ist auch für ST-Besitzer interessant, die Alt-RAM in Form einer Aufrüstung (Monster, Magnum) haben. Im Gegensatz zur reinen ST-Version fehlt YAARTTT.TOS aber der "low memory"-Test und es kann nur den freien Speicher testen, den es von GEMDOS anfordern kann.
Fazit: ST/STE/MegaST(E)-Besitzer nehmen weiterhin YAART.TOS, es sei denn, sie müssen Alt-RAM testen. - Der "low memory"-Test der reinen ST(E)-Version kann jetzt auch den Speicher testen, den YAART.TOS selbst belegt. Damit wird nun der komplette ST-RAM getestet bis auf ca. 3,5 kByte ganz am oberen Ende des Video-RAM. Allerdings gilt weiterhin: Der freie Speicher wird gründlicher getestet als der von TOS u.a. belegte, es sollte also so wenig RAM wie möglich durch RAM-Disks, Treiber usw. belegt sein. Am besten von Floppy starten.
- Weiterhin handelt es sich um eine Beta-Version, insbesondere kann ich YAARTTT.TOS mangels TT nur in der Hatari-Emulation testen. Ich brauche daher weiter Euer Feedback.
-
Wird sofort im TT getestet, da kann ich unsere FRAK testen.
-
Habe mal yaart auf meinem Falcon in ST-Hi von Diskette gestartet. Ergebnis:
ERROR: Screen Memory is not in the topmost 32k of RAM!
Remove all Video Drivers, resident programs etc.
Es gab aber nix, wirklich gar nichts außer yaart im Speicher.
-
Habe mal yaart auf meinem Falcon in ST-Hi von Diskette gestartet. Ergebnis:
ERROR: Screen Memory is not in the topmost 32k of RAM!
Remove all Video Drivers, resident programs etc.
Tritt auch auf, wenn man auf hatari_falcon V1.9.0 (TOS 4.04, 8MB STRAM, kein TTRAM) YAART.TOS startet.
Da ich in der Firma einen Speichertest implementieren muss, der durch die VDE Prüfung nach IEC60730-1H kommt, habe ich mir einige Testverfahren angeschaut. MarchC scheint akzeptiert zu sein, aber ich probiere auch mal den Test von M.Barr aus.
Den memtest86 Sourcecode hatte ich mir auch mal vor längerem angeschaut. Mich hats nur noch geschaudert:
- wilder Zugriff auf globale Variablen
- keine sprechenden Variablennamen
- krude Typdeklarationen (ulong, unsigned long obwohl stdint.h im Paket drin ist)
- Makros (msr.h) mit inline-asm werden angelegt, dann aber doch nicht benutzt, sondern wieder ausprogrammiert usw. usf.
Ein teil-defektes 16MB PS/2 SIMM habe ich zuhause, könnte es am TT/F030 testen oder ein paar Fehler in den VHDL Teil einbauen.
Kannst Du in Pseudoprogrammiersprache beschreiben, wie Deine Tests im einzelnen ablaufen? Würde u.U. bei der Fehlersuche helfen. Genial wäre m.E. eine Doku mit PAPDesigner erstellt.
Welche Muster werden (auf/absteigend) geschrieben? Wird direkt nach dem Schreiben eines Wortes gelesen oder wird blockweise gearbeitet?
Ein Refreshtest für TT/Alt-RAM wäre nett.
-
Habe mal yaart auf meinem Falcon in ST-Hi von Diskette gestartet. Ergebnis:
ERROR: Screen Memory is not in the topmost 32k of RAM!
Remove all Video Drivers, resident programs etc.
Kein Wunder, ein Falcon ist ja auch kein ST. Nochmal: YAART.TOS ist die reine ST-Version, die dort mehr testen kann. Für andere Atari-Computer muss YAARTTT.TOS genommen werden.
-
Kannst Du in Pseudoprogrammiersprache beschreiben, wie Deine Tests im einzelnen ablaufen?
Die Tests funktionieren so, wie hier beschrieben: http://www.memtest86.com/technical.htm#algorithm (http://www.memtest86.com/technical.htm#algorithm). In der Nomenklatur, die wohl für Speichertests gängig ist, wären die "Moving Inversions" übrigens ↕(w0) ↑(r0,w1) ↓(r1). Wie Du siehst, wird der Speicher nach dem gelesenen Wort ("r0") sofort umgeschrieben.
Die anderen Tests für den Atari schreiben nur blockweise ein Pattern und lesen es dann wieder: ↕(w0) ↕(r0).
-
yaart.tos macht jetzt überhaupt keine Meldung mehr auf dem Falcon; verabschiedet sich ohne jeglichen Mucks; sollte doch wenigstens einen Hinweis geben.
yaarttt.tos läuft gerade auf meinem Falcon; derzeitige Meldung am unteren Bildrand:
Pass: 7. Test #3: Moving inversions, 8 bit. Pattern = 4040
Errors: 0.
Ich hätte auch keine Errors erwartet.
Etwas unglücklich, daß die Meldungen überschrieben werden (anstatt gescrollt).
-----
So, nach 20 Tests ohne Error hab´ ich mal abgebrochen.
-
Kann man nicht beide Tests in ein Programm zusammenführen? Es sollte ja problemlos möglich sein, erstmal grundsätzlich festzustellen, welche Art RAM vorhanden ist, und dann auch (nur) das zu testen. Was den Bildspeicher angeht, auch den kann man vollständig testen ohne sich die Bildausgabe zu versauen, in dem man den Bildspeicher einfach in einen schon getesteten RAM-Bereich verschiebt.
-
Eine Vorbemerkung: Die auf allen Atari-Systemen (also auch TT/Falcon) lauffähige Version YAARTTT.TOS ist nur ein Nebenprodukt meines RAM-Tests. Da ich mangels TT oder Falcon weder eine echte Testmöglichkeit noch Bedarf für einen RAM-Test dort habe, möchte ich nur wenig Zeit dafür investieren. Zumal YAARTTT.TOS, das auf direkte Hardwarezugriffe und sonstige "low level"-Programmierung verzichtet und den Speicher brav bei GEMDOS anfordert, prinzipbedingt etwas schlechter testen kann als die viel hardwarenäher programmierte ST-Version YAART.TOS.
yaart.tos macht jetzt überhaupt keine Meldung mehr auf dem Falcon; verabschiedet sich ohne jeglichen Mucks; sollte doch wenigstens einen Hinweis geben.
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?
Etwas unglücklich, daß die Meldungen überschrieben werden (anstatt gescrollt).
Das ist ein Nebenwirkung dessen, dass ich (siehe oben) nicht so viel Zeit in YAARTTT.TOS investiere. In der ST-Version ist kein Platz für gescrollte Meldungen, weil ich zur Zeit (siehe auch unten) den größten Teil des Bildschirmspeichers auch mit Testpattern überschreibe. Vielleicht fällt mir etwas ein, mit geringem Aufwand zumindest in YAARTTT.TOS gescrollte Meldungen einzubauen...
Kann man nicht beide Tests in ein Programm zusammenführen? Es sollte ja problemlos möglich sein, erstmal grundsätzlich festzustellen, welche Art RAM vorhanden ist, und dann auch (nur) das zu testen.
Wie schon angedeutet, unterscheidet sich YAART.TOS nicht nur darin, dass es nur ST-RAM testet. Es greift auch direkt auf die Hardware zu, z.B. um gezielt die Adressleitungen der im jeweiligen ST vorhandenen RAM-Bänke zu testen. Es ist also einiges an zusätzlichem Code vorhanden, der die ST-Version schärfer testen lässt. Natürlich könnte man diesen Code auf dem TT/Falcon einfach nicht ausführen.
Ich wollte aber die Programme selbst möglichst klein bekommen, gerade weil YAARTTT.TOS nicht den Speicher testen kann, den es selbst schon belegt. Daher gibt es zwei separate Programme mit dem unterschiedlichen Funktionsumfang.
Ich denke, es überfordert den Nutzer nicht, je nach Maschine das eine oder andere Programm anzuklicken.
Was den Bildspeicher angeht, auch den kann man vollständig testen ohne sich die Bildausgabe zu versauen, in dem man den Bildspeicher einfach in einen schon getesteten RAM-Bereich verschiebt.
Ich schreib's mal für später auf die Todo-Liste, wenngleich es für das Finden von RAM-Fehlern besser ist, möglichst viel Speicher auf einmal zu testen und nicht erst nur den "normalen" Speicher und dann den Bildschirmspeicher separat.
-
Auf unserer TT Frak läuft es super durch, werde mal schauen ob ich ein defektes Ram Modul finde. Welches wirklich einen Fehler Produziert, auch wenn unsere Karte schnell ist dauert der Test doch eine ganze weile. Hab schon extra nur ein 16Mb Modul genommen.
-
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.
-
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 (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.
-
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.
-
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..
-
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.
-
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!
-
Cookies gibts aber erst ab TOS 3.0x/2.0x.
Ab TOS 1.06.
-
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.
-
Schaltest Du für diesen Test beim 68030 den CPU-Cache explizit aus?
-
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.
-
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.
-
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!!
-
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... :D
-
PS: Wenn nun endlich mal jemand einen echten RAM-Fehler damit finden würde... :D
(http://www2.pic-upload.de/thumb/31170082/IMG_0615.jpg) (http://www.pic-upload.de/view-31170082/IMG_0615.jpg.html)
Zufrieden? ;)
-
Zufrieden? ;)
Ja, kaputt! ;D Danke!
-
Beta-Version v.0.1.7.
PS: Wenn nun endlich mal jemand einen echten RAM-Fehler damit finden würde... :D
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..)
-
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...
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.
-
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.
-
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.
-
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?
-
Die Fehler kommen generell mir beiden Simms bestückt.
Mit einem Simm steigt V. 1.1.7 aus und 1.1.5 läuft einwandfrei durch.
-
Lasse die Programme doch mal in eine Datei schreiben und poste das dann hier ...
-
Was heißt denn "steigt aus" nun? Hängt sich auf? Fehlermeldung? Beendet sich einfach?
-
@ditto & @pakman: Ich habe jetzt drei Testversionen YTEST1-YTEST3 von YAARTTT.TOS erstellt, in denen ich selektiv jeweils immer nur eine der Änderungen von v.0.1.5 auf v.0.1.7 rückgängig gemacht habe. Damit ließe sich hoffentlich herausfinden, welches die problematische Änderung war.
Wenn Ihr sie bitte einmal alle drei testen könntet, um mir zu sagen, welche nun bei Euch laufen, welche abstürzen? (Und wie genau abstürzen: Aufhängen, Fehlemeldung, Bomben etc.?)
Vielen Dank.
-
PS: Probiert bitte als erstes YTEST3.TOS aus. Nach stundenlangem Herumprobieren in Hatari glaube ich, dass die deaktivierte "Write Allocation" das Problem ist -- und die ist in YTEST3.TOS wieder aktiv.
Was hast Du mir da bloß empfohlen, @pakman? ;)
-
Testbericht:
YTEST1:
- Ausgabe in der untersten Zeile
- Läuft durch, wie Version 0.1.5
- in Pass2 mit Alt abgebrochen
YTEST2:
- Ausgabe scrollt
- Bei Pass1 Test#2 nach rund 290 Fehlern Absturz mit 2 Bomben
- reproduzierbar
YTEST3:
- Ausgabe scrollt
- Läuft durch, siehe Screenshot
- Irgendwann in Pass3 mit Alt abgebrochen
- Was bedeutet eigentlich (ffff!=0000)? Das kommt ja fast immer, auch wenn das Pattern ganz anders aussieht..
YAARTTT 0.1.7
- Ausgabe scrollt
- Bei Pass1 Test#2 beim Auftreten des ersten Fehlers hängt der Rechner, siehe Screenshot
- Cursor blinkt im Sekundentakt, aber keine Reaktion auf Alt-Taste
(..und vielen Dank für Deinen Einsatz)
-
Auf meinem TT stürzt YTEST2 beim Pass 1 Test 2 / 2.Muster mit 2 Bomben ab; reproduzierbar.
Auf dem Falcon bleibt YTEST2 nach einigen Tests hängen, AlfaCursor blinkt nicht mehr, MausCursor läuft noch, aber hat keine Wirkung; Reset nötig.
Ansonsten unauffällig. 0 Errors.
Toi, toi, toi!
-
Danke Euch für die Tests!
Damit habe ich genug Information, um eine Version (mit scrollenden Meldungen) zu erstellen, die auf dem 68030er nicht abstürzt.
-
Trotzdem will ich noch kurz meine Tests mitteilen.
Bestückt mit einem 64mb Simm und HDDriver laufen alle drei Varianten bei mir einwandfrei durch, bis ich sie beende.
Trotzdem steigt die "alte Version 1.1.7" bei mir wie schon beschrieben einfach aus. Das heißt, sobald Test #3 erscheint, lande ich auf dem Desktop und kann normal weiterarbeiten.
Was mir eben noch auffiel, mein TT hängt an zwei Monitoren. Einen zum Booten, der andere an der CrazyDots.
Der Boot-Monitor zeigt mir nach dem Aussteigen des Programms 2 Bomben an.
-
Lasse die Programme doch mal in eine Datei schreiben und poste das dann hier ...
Ich habe keinen blassen Schimmer davon, wie ich das machen kann. Mit Shells habe ich mich noch nie befasst und müsste mich ersteinmal mit den Befehlen und der Syntax auseinandersetzen.
-
Das geht ganz einfach, brauchste keine ´Auseinandersetzung´, siehe Bild:
1) Shell starten
2) Hinter dem Prompter das Prg. eintippen (mit vollst. Pfad)
3) io umleiten durch ´>´ und Zieldatei (mit vollst, Pfad), Return
4) ´s´ ...... irgendwann ´ALT´
5) Shell beenden (meist per ´exit´)
Das geht für so ziemlich alle Shells gleich! zB. MCMD (aus der MagiC-Distribution),
die MUPFEL (aus der Gemini-Distribution), GULÄM oder welche auch immer...
-
- Was bedeutet eigentlich (ffff!=0000)? Das kommt ja fast immer, auch wenn das Pattern ganz anders aussieht..
Das ist falsches vs. richtiges Datenwort im letzten Fehlerfall. Wie Du in Deinen Screenshots siehst, gab es in Test #3 keine weiteren Fehler, der Error-Zähler ist gleich geblieben. Somit siehst Du weitergin das Fehlerbild/die Fehlermeldung aus Test #2, wo das Pattern ja zwischen 0xffff und 0x0000 welchselt.
-
@ari.tao
Besten Dank für deine Erläuterung. Ich habe Mupfel genommen.
Die Ausgabe in eine Datei hat gut funktioniert, allerdings nicht, bei der Konfiguration, in der das Testprogramm aussteigt.
Zum Gegentest habe ich eine funktionierende Version ausprobiert und konnte nach beenden des Tests alles in der Textdatei nachlesen.
Naja, Versuch macht kluch! ;)
-
So, in der Version v.0.1.8 (angehängt) ist YAARTTT.TOS dank Eurer Mithilfe (hoffentlich) gefixt, dass es nicht mehr auf TT oder Falcon abstürzt oder hängen bleibt.
-
Vielen Dank (mal wieder) ;) für deine Mühen und deine Zeit, uns ein tolles Test-Programmm zur Verfügung zu stellen.
-
Ich kann jetzt übrigens auf Anfrage eine Version von YAART zur Verfügung stellen, die beim Booten des ST von einem Cartridge startet. So muss kein Laufwerk funktionsfähig sein, um den RAM zu testen. Oder evtl. hilfreich, wenn der ST schon beim Booten bombt.
-
Ein Testmodul damit wäre Klasse. Passt doch bestimmt in zwei 27C256 Eproms, oder ?
Habe auch die Tage ein Romport Testmodul bekommen mit zwei 27C080 drauf, das hat jene Menge freie Slots ...
-
Ich kann's ja auch anhängen. Hier also YAART als 64 KiB Binärfile für ein ROM-Port-Cartridge und als Intel-Hex-File für die glücklichen Käufer meines vom PC programmierbaren Cartridges.
Startet direkt beim Booten. Es ist nicht vorgesehen, diese Version zu beenden, außer durch Abschalten des ST.
-
Vielen Dank von mir ...
Also das STC teile ich in zwei 32kB Teile jeweils Hi und Lo und dann ab in die Eproms, richtig ?
-
Also das STC teile ich in zwei 32kB Teile jeweils Hi und Lo und dann ab in die Eproms, richtig ?
Genau.
-
Gerade mal in zwei 27C256 Eproms gebrannt und ab in mein original Atari Testmodul und läuft, sehr schön ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=13002.0;attach=11724;image)
Die Kommado Datei für Rommix
# Kommandodatei fr ROMMIX:
# erstellen von 4 Eprom-Files fr 27010
# 1 TOS-3.06-IMG wird auf 4 Eproms aufgeteilt
# von Udo Overath @ KR
# (das geht auch direkt mit Pinatubo --- ms)
# Puffergre setzen
bufsize 64k
# Directory setzen
chdir a:\
load yaart_ca.img 0 64k all -> 0 all
save high.img 32k <- 0 high
save low.img 32k <- 0 low
-
@czietz ... die Ram Konfigurationen der verschiedenen Atari ST Modelle sind ja bekannt. Kann man bei einem Fehler im Ram festmachen in welchem Ram Baustein der Fehler auftritt ?
Die Ram Bausteine hängen ja jeweils getrennt/einzeln oder in Gruppen zu vier an D0 bis D15 (MDATA) ...
-
Ja, man kann schon den mutmaßlich betroffenen Chip identifizieren.
Zuerst gilt es, die Speicherbank herauszufinden. Bei Ausstattung mit 512 kiB oder 2 MiB ist es einfach, dort ist nur eine Bank bestückt. Bei 1 MiB sind die Adressen 0x000000 – 0x07FFFF in der unteren Bank (mit RAS0 und CAS0 verbunden) und die Adressen 0x080000 – 0x0FFFFF in der oberen Bank (mit RAS1/CAS1 verbunden). Bei 4 MiB ist die Aufteilung entsprechend 0x000000 – 0x1FFFFF bzw. 0x200000 – 0x3FFFFF.
Jedes Speicher-IC bedient alle Adressen innerhalb einer Bank, aber nicht alle Bits. Anhand des vom Fehler betroffenen Bits kannst Du also den genauen RAM-IC ausmachen. Wie Du schon schreibst, gibt es Modelle mit 16 Chips pro Bank (jede Datenleitung ein eigener Chip) und mit 4 Chips pro Bank (jeweils 4 Datenleitungen pro Chip).
Wenn Du Fehler bei unterschiedlichen Bits siehst, die sich periodisch im Adressraum wiederholen, kann auch der Treiber für die jeweilige Adressleitung MADx beschädigt sein.
-
Wäre es denn sehr aufwändig die Fehler im Programm aufzuarbeiten und Tipps abzugeben welcher Baustein in welcher Bank betroffen wäre in Form einer kleinen Tabelle oder eines Log File auf Diskette ?
Es gibt ja nur 2 Bänke mit 512kB oder 2MB pro Bank und 256kBx1, 256kBx4, 1MBx1 oder eben 1MBx4 Bausteinen.
Es gibt zwar mit Tricks auch 3MB Rechner aber die läßt man besser aussen vor ...
-
Das halte ich aus verschiedenen Gründen für nicht so sinnvoll: 1. Man kann per Software nicht bestimmen, ob ein Rechner mit x1 oder x4 RAM bestückt ist. 2. Je nach Computertyp und Board-Revision haben die Bausteine verschiedene Bezeichnungen. Somit wird YAART nie ausgeben können "IC0815 ist kaputt", sondern bestenfalls "Der RAM-Chip, der in Bank 0 für Datenleitung 13 zuständig ist, ist evtl. kaputt."
Diese Aussage enthält nicht mehr Information als der Benutzer auch jetzt schon aus der Fehlermeldung entnehmen kann, wie ich im vorigen Posting geschildert habe.
Außerdem muss ohnehin ein kundiger Benutzer die Fehlermeldungen interpretieren, um schlusszufolgern ob wirklich ein RAM-Chip oder nicht vielleicht z.B. ein Treiberbaustein defekt ist. Das kann ein Algorithmus nur schwer leisten, vor allem, wenn er nicht einmal weiß, wie der Speicher tatsächlich organisiert ist, s. oben.
-
... sondern bestenfalls "Der RAM-Chip, der in Bank 0 für Datenleitung 13 zuständig ist, ist evtl. kaputt."
Ja genau, das reicht doch !
Da weiss man schonmal besser wo man anfangen soll mit suchen. Ich habe es nicht so mit den ganzen Adressen und so ...
Auf den Atari Mainboards sind die ganzen MData Daten Signale wohl sortiert.
-
Ich wurde per E-Mail noch auf einen Bug in der ROM-Cartridge-Version hingewiesen. Sie lief nicht an einem Farbmonitor, weil der Atari dort in der von YAART nicht unterstützten niedrigen Auflösung bootet. Ist jetzt gefixt.
-
Neue Version 0.2.0 von YAART ist angehängt.
Größte Neuerung: Ein (halb-)versteckter manueller Modus zur Adresseingabe für Experten im Programm YAARTTT.TOS. Damit lässt sich Speicher testen, der nicht bei GEMDOS angemeldet ist, z.B. Videospeicher einer Grafikkarte oder anderer Speicher auf Addon-Karten. Nähere Infos in der im Download enthaltenen Textdatei.
-
Wenn du Lust und Zeit hast schreibe doch mal eine Anleitung dazu ...
Wie ist denn die Idee wenn man den Test unbeaufsichtigt laufen lässt das YAART ein Log auf Diskette schreibt ?
-
YAART.TXT in dem Archiv reicht nicht? Was fehlt Dir denn bzgl. Anleitung, damit ich es ergänzen kann?
Du kannst auch jetzt schon die Ausgaben in eine Datei loggen, bekommst sie dann allerdings nicht mehr auf dem Bildschirm zu sehen. Ausgabeumleitung ist das Stichwort, wie im letzten Satz von YAART.TXT kurz erwähnt.
-
Mein Fehler, ich sollte mal die Anleitung lesen ...
-
Na ja über eine externe Shell ist mir das ehrlich gesagt zu kompliziert. Wüsste auch nicht wie ich das anstellen sollte.
So eine ASCII Mitschrift auf Diskette direkt aus dem Programm heraus wäre schon schön ...
-
A:\> YAARTTT.TOS > LOG.TXT
-
mu!
-> Antwort #50
-
Danke ...
-
YAART(TT) Version 0.2.1 ist jetzt online: https://www.chzsoft.de/site/hardware/diverse-kleinigkeiten-fur-den-atari-st/#ram-test-software-yaart
Neuerung: Die Ausgabe von Fehlermeldungen wird angehalten, solange die Shift-Taste gedrückt ist.
-
Vielen Dank für dieses nützliche Update!
-
Endlich die Muse und vor allem die Anwendung um mir das Testproggi mal anzuschauen und zu nutzen!
Vielen Dank, sieht sehr gut aus!
Mein STE läuft seit Stunden um mein Simm-Layout zu checken.
Morgen darf der MEGA ran und die roten Platinchen testen. :)
Bei YAART.TOS hätte ich einen Vorschlag für das nächste Update.
Für die STs und STEs wäre es toll wenn man gezielt eine Bank zum testen aussuchen könnte.
Die Bänke können beim ST auch unterschiedlich groß sein (vor IMP Chipsatz) und da wäre es nett wenn man dem Programm sagen könnte welche Bank man testen will ohne erst mal aufschrauben zu müssen um nachzusehen wie die Bänke angeschlossen sind. Der Computer weis ja welche Bank wie groß ist.
In meinem Fall mit dem STE könnte ich ihn bei 4MB lassen, das Proggi läuft in den unteren 2MB, den Bildschirm dort hinschieben und dann die oberen 2MB komplett durchtesten.
Nachtrag: 250 durchgänge und immer noch alles OK. :)
Jetzt darf der MEGA testen...
-
Ich merk mir Deine Wünsche mal; allerdings bedeutet gerade das Hin- und Herkopieren des Bildschirmspeichers eine größere Änderung, sodass ich sicherlich nicht in den nächsten Tagen mit diesem Feature um die Ecke kommen werde.
Das mit den Bänken ist sicherlich machbar, allerdings eher was für die Profis...
Die Bänke können beim ST auch unterschiedlich groß sein (vor IMP Chipsatz)
Ich weiß; ich habe die ST-MMU umfangreich reverse-engineered für Hatari und EmuTOS. Detail am Rande: Auch die MMU im STE könnte von der Hardwareseite grundsätzlich verschieden große Bänke verwalten, mit der Einschränkung Bank0 >= Bank1. Nur kommt TOS dann durcheinander. (In EmuTOS geht es.)
-
Gestern habe ich bei einem ST den Speicher getestet.
Der hat 4MB mit 8 Stk. 1Mx4.
YAART führt zum Reset wenn es geladen ist.
YAARTTT testet nur die ersten 2MB.
Das Diagnose Modul 4.41 findet 4MB und beim Test Fehler.
(http://forum.atari-home.de/index.php?action=dlattach;topic=13002.0;attach=13692)
Ich habe den IC der für Bit 0 - 3 zuständig ist ausgetauscht und der Rechner funktioniert jetzt wieder wie er sollte. 4MB, gefunden von TOS, YAART, YAARTTT und vom Diagnose Modul und als OK getestet.
Evtl. kannst Du damit etwas anfangen?
Ich habe den Chip aufgehoben und werde ihn auf eine Simm-Platine löten und mit dem Elektor-Simm-Tester testen. OK, der ist leider nicht so toll, aber er hat ab und zu schon einen Fehler gefunden. :)
Ich kann Dir das Simm bei Interesse gerne zukommen lassen falls Du es testen willst.
Auf 1MB 30pol oder 4MB 72pol, da habe ich Simms hier. Du hast einen STE, oder?
-
Oh, abstürzen sollte YAART nicht -- das ist ein spannender Fehler. Wenn Du mir den Baustein auf einem 30-poligen SIMM (also passend für meinen STE) leihweise zukommen lassen kannst, würde ich ihn gerne testen, um herauszufinden, wie ich YAART in dieser Hinsicht verbessern kann.
Dass YAARTTT nur 2 MB testet, liegt vermutlich daran, dass es den Speicher von TOS anfordert und TOS beim Booten die oberen 2 MB als defekt erkannt hat und nicht an Programme vergibt.
-
Gerne, schick mir bitte Deine Adresse per PM oder Email.