Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins Willkommen Gast! RSS

Robotrontechnik-Forum » Technische Diskussionen » RAM-Testsoftware » Themenansicht

Autor Thread - Seiten: -1-
000
31.01.2008, 17:52 Uhr
Ralph



Hallo Leute.... Ralph mal wieder mit einem Problem..

jetzt suche ich ein Speichertestprogramm für den AC1 bzw. CPM Kompatibel.
Warum ich dass brauche ??.. ja unter http://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=2652&highlight=K1520
hatten wir mal ein Problem beschrieben/gelöst. Allerdings besteht offensichtlich noch immer ein Problem, denn bestimmte Programme (Assembler) machen Fehler/Probleme und das obwohl das Speichertestprogramm bisher ohne Fehler läuft.

Meine Hoffnung ist, dass mit einem Testprogramm herauszufinden.. :-)

Gruß Ralph
--
Es geht alles erst richtig los !

Dieser Beitrag wurde am 31.01.2008 um 17:54 Uhr von Ralph editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
001
31.01.2008, 18:29 Uhr
Rüdiger
Administrator
Avatar von Rüdiger


Zitat:
Ralph schrieb
jetzt suche ich ein Speichertestprogramm für den AC1 bzw. CPM Kompatibel.

Rassmussen Memory Test.
Schicke ich Dir per Mail.
--
Kernel panic: Out of swap space.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
002
31.01.2008, 19:09 Uhr
Deff



Für alle anderen Interessenten am RAM-Testproggi von Rasmussen!

Hier ist der Link zum Donwload.

Einen CPU-Test hat Rasmussen auch vorgesehen. Dazu ist dieser Link!

Viel Spass!
--
Die Politik ist ein Versuch der Politiker, zusammen mit dem Volk mit den Problemen fertig zu werden, die das Volk ohne die Politiker niemals gehabt hätte. (Dieter Hildebrandt)

Dieser Beitrag wurde am 31.01.2008 um 19:11 Uhr von Deff editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
003
31.01.2008, 19:21 Uhr
Enrico
Default Group and Edit


Wird beim CPU-Test auch auch der Dhrystone-Wert angezeigt?
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
004
31.01.2008, 19:39 Uhr
Deff



Dhrystone?

Whetstone?

Und nun zur Gegenfrage: Was bitte soll Dir diese Angabe bringen?
--
Die Politik ist ein Versuch der Politiker, zusammen mit dem Volk mit den Problemen fertig zu werden, die das Volk ohne die Politiker niemals gehabt hätte. (Dieter Hildebrandt)
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
005
31.01.2008, 20:02 Uhr
marko_oette



Na vielleicht will man die Leistung der Rechner vergleichen ...

Unter CP/M+ bzw. SCP3 geht das RAM/CPUTEST Programm aber nicht oder?

Auf meinem 1715W tut sich nicht viel, nach dem Start.

Gruß

Marko

PS: Deff, hast Post.
--
Bitte - wenn nötig - Kontakt via Email, ich bin selten im Forum.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
006
31.01.2008, 20:49 Uhr
Heiko_P



@Ralph,

nachdem ich den Thread http://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=2652&highlight=K1520 gelesen habe, kamen bei mir Erinnerungen hoch. Ein ähnliches Problem hatte ich auch mal, allerdings lief mein AC1 vorher lange Zeit störungsfrei und ich hatte nichts daran verändert. Nachdem ich (fast) alle hier beschriebenen Maßnahmen ohne Erfolg ausprobiert und praktisch die gesamte Rückverdrahtung erneuert hatte, fand ich nach wochenlanger Fehlersuche einen defekten Bustreiber (DS8286) UND einen defekten RAM (U2164) auf unterschiedlichen Leiterplatten. Beide Bauteile liefen "kalt" erst eine Weile fehlerfrei und fingen dann unreproduzierbar an zu mucken. Geholfen hat mir bei der Fehlersuche letztlich ausschließlich der AC1-Monitor, viel Geduld und etwas Glück. Dieses wünsche ich Dir auch, ich fühle mit...

Viele Grüße

Heiko
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
007
31.01.2008, 21:35 Uhr
Ralph



@Heiko_P.. Danke für den Hinweis.. ich werde das mal überdenken, komme allerdings nicht umhin zu bemerken, dass das Teil stundenlang vollkommen Problemlos läuft, sogar das ansonsten sehr Fehleranfällige GrafiksoundBasic schmiert nicht ab... nur der Edas macht bei Quellcodeänderungen plötzlich Fehler...
Ich werde mal die Platinen wieder rausnehmen und außerhalb des Gehäuses nochmal testen, mal sehen was das bringt... Nen Bustreiber hatte ich aber auch schon im Gedanken. na mal sehen... erst Mal danke für das "Mitgefühl" :-) wir kriegen das schon hin !
Danke auch an Rüdiger & Deff für das Programm...

Gruß Ralph
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
008
31.01.2008, 22:02 Uhr
marko_oette



Das Problem bei RAM-Test Software ist ja auch, dass diese einerseits nicht den kompletten RAM Testen können (Der schon zB. durch das Betriebssystem belegte Speicher kann nicht getestet werden) andererseits muss der Fehler nicht zwangsläufig gleich beim ersten Durchgang auftreten, sodass man diese Programme über längere Zeit laufen lassen muss.
--
Bitte - wenn nötig - Kontakt via Email, ich bin selten im Forum.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
009
31.01.2008, 22:38 Uhr
Ralph



..ja Marko.. da hast Du Recht.... aber ich denke so 24h sollten schon langen ??

Gruß Ralph
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
010
01.02.2008, 08:23 Uhr
marko_oette



Hallo Ralph!

Na ja eigentlich reicht die Zeit, nach der dein AC1 sonst zu spinnen anfängt.

Welcher Art sind deine beobachteten Fehler denn?
--
Bitte - wenn nötig - Kontakt via Email, ich bin selten im Forum.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
011
01.02.2008, 09:15 Uhr
Ralph



@Marko.. also ich hab gestern abend schon was entdeckt.. und zwar liegt der Fehler eindeutig im 64K Ram der Präcitronik 256KRamFloppy (MP3/87).. Das ist an beiden AC1 reproduzierbar.
Der Speicher läuft mit 4Mhz und auch mit nur 2Mhz in allen lauffähigen Ramtestprogrammen ohne irgendwelche Probleme...
Allerdings macht der AC1 Edas Probleme beim Verschieben/Einfügen/Löschen von Quellcodezeilen. Der Code wird ungültig, weil z.B. eine einzufügende Zeile nicht an die richtige Stelle eingefügt wird und damit den Quellcode zerstört.
Diesen Fehler macht der Edas nicht mit einem anderen RAM ("das gelöste Problem 64KSRAM" aus einem anderen Thread) und auch mein "alter" 64dRam geht prima.

Ich hab noch keinen Plan, zumal der Edas offensichtlich funktioniert, wenn der Quellcode bis max 6fff liegt (also liegt wohl ab da das Problem..)..aber welches..
Gruß Ralph
--
Es geht alles erst richtig los !

Dieser Beitrag wurde am 01.02.2008 um 11:51 Uhr von Ralph editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
012
01.02.2008, 18:44 Uhr
marko_oette



Die Zeile wird nicht an der richtigen Stelle eingefügt? Sondern? In eine andere Zeile oder nur an einer anderen Position?

Wenn dem so wäre, klingt das eigentlich nicht, nach einem RAM Problem...
--
Bitte - wenn nötig - Kontakt via Email, ich bin selten im Forum.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
013
01.02.2008, 21:58 Uhr
Ralph



@Marko.. also die Zeile wird an einer vollkommen anderen Stelle, meist sogar in mitten der betreffenden Quellcodezeile angezeigt... aber der quellcode ist dann verstümmelt...
ABer ich denk schon das es am Speicher liegt, denn die beiden andern Speicher LP machen das ja nicht, bei ansonsten gleicher Umgebung (2 versch. AC1)

Gruß Ralph
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
014
02.02.2008, 12:01 Uhr
marko_oette



Wird dabei eine Zeile überschrieben, also ist deren Inhalt dann weg, oder wird die Zeile dann aufgeteilt und verschoben?

Im ersten Fall (Überschreibung) denke ich, handelt es sich eher um ein Adressierungsproblem.

Kenne mich aber mit der Hardware des AC1 nun überhaupt nicht aus. Wie wird dort denn die Adressierung gelöst? - Wo ist der Adressdecoder untergebracht, wenn es denn einen gibt?
--
Bitte - wenn nötig - Kontakt via Email, ich bin selten im Forum.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
015
02.02.2008, 14:19 Uhr
Ralph



@Marko.. lieb das Du helfen willst, aber nun pass mal auf..
1. läuft bisher sämtliche Software !! (außer Edas) --ergo kein Adressproblem
2. laufen zig Ramtesttools ohne Fehler.. --ergo auch kein Adressproblem
3. ist der RAM (bei MRQ) immer aktiviert und wird nur mittels MEMDI bei EPROM oder BWS deaktiviert...
4. wenn Du obiges gelesen hast, weist Du das der "neue " Code in eine bestehende Zeile geschreiben wird... allerdings ziemlich wahllos wo...es wird nix gelöscht, aber die betreffenden Quellzeilennummer zeigen dann unsinnige Werte an (ist ja auch klar wenn Müll im Ram steht)
5. (nicht persönlich nehmen)..bin ich auch kein blutiger Laie ... --ergo kein Adressproblem

Also kann es kein Adressierungsproblem sein... ich denk eher an ein Problem mit einem evl. vom Edas ausgeführten Blocktransferbefehl, denn er muss ja bei Einfügen den Quellcode nach hinten verschieben... allerdings ist komisch, dass die einzufügende Zeile bisher immer viel zu weit hinten eingefügt wurde als sie eigentlich sein sollte.. Leider ist mir aber das Ramhandling des Edas unbekannt. Ich bin jedoch sehr sicher das es NICHT am Edas selbst liegt, denn mit nem anderem Ram und geht es ja und an einem anderen AC1 tritt der gleiche Fehler auf !!

Gruß Ralph
--
Es geht alles erst richtig los !

Dieser Beitrag wurde am 02.02.2008 um 14:22 Uhr von Ralph editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
016
02.02.2008, 15:15 Uhr
Enrico
Default Group and Edit


Ich finde es zwar gerade nicht wieder, aber schriebst Du nicht irgendwo, dass dieser 64k D-RAM keinen Refresh kriegt?

Wenn das Speichertestprogramm ständig auf diesem RAM rumackert, kann das schon sein, dass kein Fehler erkannt wird. Edas greift auf diesen RAM ja nur irgendwann mal zu. Der Speichererhalt ist bei den D-RAMs ja nicht besonders lang...
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
017
02.02.2008, 15:48 Uhr
Ralph



@Enrico...ja das checke ich grade, aber es geht offensichtlich....muss es ja eigentlich auch, denn 1. hab ich ein Testprogramm der auch den Referesh testet und 2. laufen ja alle anderen Programme (zumindest soweit ich das sehe)..
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
018
02.02.2008, 20:15 Uhr
Ralph



@alle ... also bis jetzt hat er noch kein Byte vergessen, obwohl der AC1 nun die ganze Zeit nur auf ne Tastatureingabe wartet... Refresh sollte es also nicht sein...
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
019
03.02.2008, 16:45 Uhr
marko_oette



Hallo Ralph,

ich glaube wir haben aneinander vorbei geschrieben.

Ein RAM Test Programm schreibt doch lediglich bestimmte Bit Muster in den Speicher und liest diese wieder. Wie will es da eine Verschiebung die innerhalb der Byte-Ausrichtungsgrenzen liegt feststellen?

Ein echter Speicherfehler (also innerhalb eines RAM-ICs) äußert sich durch Entladung der entsprechenden Zellen und der damit zusammenhängenden Korruption der binären Werte.

Bei dir sind doch aber ... wenn ich obiges richtig verstehe ... keine einzelnen Bits gekippt sondern ganze Byte(-Blöcke) verschoben / überschrieben?
--
Bitte - wenn nötig - Kontakt via Email, ich bin selten im Forum.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
020
03.02.2008, 17:22 Uhr
Ralph



@Marko... ja, OK, habs verstanden, aber .... ich glaub das mit den Byteblöcken nicht so recht, weil ja sonst der Ram absolut identisch arbeitet. Also wenn ich versch. Bytes hinkopiere und mit dem Ziel vergleiche, geht alles...auch andere Programme in dem Bereich schein zu laufen....
Nur der Edas macht die Fehler und ich glaub fast noch was anderes, nämlich das irgendeine IO Konfiguration in die Quere kommt.. mal sehen..
Ich denke das keine Byteblöcke umgekippt sind, sondern der Edas bei raussuchen der Stelle wo der Code einzufügen ist, Fehler macht...

Gruß Ralph
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
021
03.02.2008, 17:44 Uhr
marko_oette



Hallo Ralph,

ich meinte dass deine Tests doch auch eher darauf hin deuten, dass der Speicher physisch soweit okay ist.

Leider kann ich dir aber wirklich mit meinem Allgemeinwissen nicht weiter helfen, denn die Transferbefehle sind ja Hardwarespezifisch implementiert. Und ich sagte ja schon, ich kenne die Hardware nicht.

Wünsche dir aber viel Erfolg und werde weiter mitlesen, man lernt ja nie aus.
--
Bitte - wenn nötig - Kontakt via Email, ich bin selten im Forum.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
022
03.02.2008, 17:58 Uhr
Ralph



@Marko.. Danke Dir :-) und wenn Dir noch was einfällt... schreibst Du hier !
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
023
03.02.2008, 20:09 Uhr
Wusel_1



Ralph,
ich würde ja sagen, du solltest mal das EDAS prüfen, ob da vielleicht was nicht stimmt. Wenn das i.O. ist, dann könnte es an den RAS/CAS Zyklus liegen, dass der bei Zugriff durch EDAS abgebremst wird und dadurch sich dann die Adressen im RAM verstellen. Mir ist nicht bekannt, ob du EDAS vom EPROM her arbeitest oder es vorher in den RAM transverierst, denn wenn du vom EPROM her arbeitest, dann kann es auch Zeitprobleme geben, was dir ein Tastprogramm nicht zeigt.
Dann solltest du prüfen, ob irgendwo zusätzliche WAIT-Zyklen herkommen, denn die verhindern auch den RAS/CAS-Zyklus und somit verstellen sich die Informationen in den einzelnen Zellen.

Vielleicht hilft dir das weiter - so al Ansatzpunkte zur Fehlereingrenzung.
MfG
--
Beste Grüße Andreas
______________________________________
DL9UNF ex Y22MF es Y35ZF
JO42VP - DOK: Y43 - LDK: CE

*** wer glaubt, hört auf zu denken ***
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
024
03.02.2008, 21:07 Uhr
Ralph



@Wusel_1... Danke... also ich hab den EDAS im RAM laufen und es kann es eigentlich nicht sein, denn mit anderen RAM Platinen geht es ja... (stand schon weiter oben),
Wait-Zyklen gibt es auch keine...denn der einzige Baustein bei mir der Wait's erzeugen könnte ist der FDC und der ist nicht dran... Ich vermute irgendeinen Programmbefehl der den RAM aus dem Tritt bringt, oder eine Datenkollision auf dem Bus bei nem speziellen Befehl im Programmcode des Edas... Was gibt es denn für Z80 Befehle, die den RAM extrem fordern ? Doch eigentlich nur der Blocktransfer ? oder auch Suchbefehle ?
Gruß Ralph
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
025
03.02.2008, 23:05 Uhr
Wusel_1



Ralph,
ich denke, dass es möglich ist, dass der RAM (zumindestens ein IC) bei größerer Belastung zu warm wird und anfängt nicht mehr sauber zu arbeiten. Ich hoffe, du hast die Dinger gesockelt. Dann würde ich mal einen nach dem anderen austauschen. Also erst den ersten und dann mit EADS arbeiten und wenns immernoch ist den nächsten nehmen. Einer wird sich dann schon zeigen der nicht sauber arbeitet. Das vielleicht als Tip - so würde ich es jedenfalls machen.
Vielleicht hilfts.

MfG
--
Beste Grüße Andreas
______________________________________
DL9UNF ex Y22MF es Y35ZF
JO42VP - DOK: Y43 - LDK: CE

*** wer glaubt, hört auf zu denken ***
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
026
03.02.2008, 23:24 Uhr
Rüdiger
Administrator
Avatar von Rüdiger


Zitat:
Wusel_1 schrieb
Also erst den ersten und dann mit EADS arbeiten

Die bauen große Flugzeuge.
www.eads.com
--
Kernel panic: Out of swap space.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
027
04.02.2008, 00:03 Uhr
Ralph



@Wusel... ich hab die Chips leider nicht gesockelt.. aber an ein thermisches Problem glaub ich auch nicht so recht, denn der Fehler tritt auf, egal ob der Rechner kalt ist oder stundenlang gelaufen ist.... Auch laufen ja alle Speichertesttools sauber durch...
Merkwürdig ist allerdings, dass der DRAM (außer dem Edas Problem) OHNE sämtliche Verzögerungskondensatoren in der RAS/CAS Kette (der MP3/88 Floppy) auch funktioniert!!! Ich hatte nämlich mal mit den Werten der 4 Kondis variiert, aber leider keine Änderungen erreicht...
Mittlerweile glaube ich aber fast, dass an meinem AC1 in der Speicherverwaltung ein Problem ist und unter bestimmten zeitkritischen Bedingungen (z.B.Blocktransfer) ein Datenkämpfen auftritt, oder der Bustreiber vom RAM ein Problem macht...
Gruß Ralph
--
Es geht alles erst richtig los !

Dieser Beitrag wurde am 04.02.2008 um 00:04 Uhr von Ralph editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
028
05.02.2008, 12:37 Uhr
Heiko_P



Hallo Ralph,

hier noch ein paar Hinweise zu meinem Problem, was Deinem sehr ähnlich war, es trat auch "nur" beim EDAS auf:
Das Speicherproblem zeigte sich dadurch, daß ein Bit (das von dem defekten Baustein) nach einiger Zeit von H nach L kippte. War das Bit zufällig mit L beschrieben, trat der Fehler natürlich nicht auf. Ich weiß nicht, wie Speichertestprogramme konkret arbeiten. Wenn sie den RAM immer wieder neu beschreiben, kann es sein, daß der Fehler nicht sichtbar wird, wenn er nicht sofort auftritt.

Gefunden habe ich den Fehler so: Den gesamten Speicher (mittels AC1-Monitor) mit FF und auch mit anderen Bitmustern beschrieben und dann den Speicher immer wieder ausgelesen. Kippt nach einiger Zeit immer das gleiche Bit um? Tritt der Fehler immer wieder an gleichen Adressen / Adressblöcken auf? Dann ist es mit großer Wahrscheinlichkeit ein RAM. Ich habe übrigens auch die RAM-Floppy aus MP 3/88.

Zum Beitrag 015: Das Adresshandling des EDAS kenne ich auch nicht im Detail. Wenn aber in einem der Zeiger ein Bit umkippt oder auch im Text selbst aus einem Buchstaben ein Steuerzeichen wird, reichte das bei mir aus, den ganzen Text zu schrotten.

Zum Problem Bustreiber: Nein, es muß nicht der vom RAM sein, weil ja alle ständig am Bus hängen. Hier ist die Fehlersuche ein Gedulds- und Glücksspiel.

Tip: Ich würde aus meiner Erfahrung heraus zuerst den RAM checken.
@Ralph, Du kannst mir auch eine Mail schicken, falls Du so nicht weiter kommst. Meine Fehlersuche zog sich über Monate hin...

Viele Grüße

Heiko
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
029
05.02.2008, 13:25 Uhr
Ralph



@Heiko... danke für die sehr wertvollen Hinweise :-) Ich habe alle möglichen Speichertestprogramme laufen gehabt, aber es kann ja tatsächlich sowas sein.. ich habs gleich mal getestet ... und siehe da... da ist was nicht korrektes aufgetreten. Ich hab den Speicher (p) gelöscht (mit FF gefüllt) und dann mit N die CRC Checksumme gebildet und genau die ändert sich ab und an ! Jetzt brauch ich nur ein Tool bastell, welches die nicht FF entahltenen Zellen anzeigt... Zur Zeit läuft der Refreshtest OHNE Ram um den Bus zu testen und störsignal von da auszuschließen. Übrigens änderte sich die CRC Summe beim Test auf den leeren Bus (also ohne RAM) nie!!

Gruß Ralph
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
030
05.02.2008, 13:28 Uhr
Rüdiger
Administrator
Avatar von Rüdiger


Zitat:
Heiko_P schrieb
Das Speicherproblem zeigte sich dadurch, daß ein Bit (das von dem defekten Baustein) nach einiger Zeit von H nach L kippte. War das Bit zufällig mit L beschrieben, trat der Fehler natürlich nicht auf. Ich weiß nicht, wie Speichertestprogramme konkret arbeiten. Wenn sie den RAM immer wieder neu beschreiben, kann es sein, daß der Fehler nicht sichtbar wird, wenn er nicht sofort auftritt.

Ich hatte mal einen kuriosen Speicherfehler: Byte X ließ sich fehlerfrei setzen und löschen, das ein Stück daneben liegende Byte Y lies sich fehlerfrei setzen und löschen. Habe ich Byte X geändert, schaltete Byte Y (genau gesagt ein Bit davon) fälschlicherweise auch mit um. Habe ich Byte Y geändert, änderte sich Byte X nicht. Speichertestprogramme haben das nicht gefunden.
Nachdem ich den Fehler zufällig im Hex-Editor entdeckt hatte, hatte ich mir für solche Fehler einen speziellen Speichertest selber geschrieben. Mehr als 1x habe ich diesen Fehler aber bis jetzt nicht entdeckt. Ursache war ein RAM-IC (U202).

Strategisch lassen sich solche Fehler finden, in dem man alle Bytes auf 00 setzt, 1 Byte auf FF und anschließend die Korrektheit aller Bytes prüft. Dann das FF-Byte eine Adresse weiter rücken. Wenn alle Adressen durch sind, das ganze nochmal, aber datenseitig negiert (Alle auf FF und einer auf 00).
--
Kernel panic: Out of swap space.

Dieser Beitrag wurde am 05.02.2008 um 13:38 Uhr von Rüdiger editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
031
05.02.2008, 13:35 Uhr
Ralph



@Rüdiger.. hast Du das Tool, ich mein den Speichertest, noch ? Also der Datenbus ist i.O. der zeigt keine Fehler oder Fehlschaltungen..
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
032
05.02.2008, 15:15 Uhr
Heiko_P



@Ralph,

das geht auch ohne spezielle Software, wenn der Fehler so deutlich ist:

Den Speicher mit FF füllen, dann mit d xxxx Hexdump anzeigen (nur mehrere beliebige Bereiche, nicht den gesamten Speicher), letzteres so lange wiederholen, bis andere Bytes als FF angezeigt werden. Wenn es nur ein defekter Speicherbaustein ist, können die Ausgaben sein: FE, FD, FB, F7, EF, DF, BF, 7F, immer das gleiche Byte an mehreren Stellen. Andere Ausgaben als diese deuten auf andere Ursachen oder auf mehr als einen defekten Speicherbaustein hin. Hast Du einen Bereich mit solchen fehlerhaften Ausgaben gefunden und fragst ihn wiederholt ab, kann an immer mehr Stellen dieses falsche Byte auftauchen. D.h. immer mehr Speicherzellen "kippen um". Wenn sich die Prüfsumme ändert, deutet es genau darauf hin. Sollte das Ergebnis so sein, lohnt sich der Aufwand auf jeden Fall, den entsprechenden Speicher zu tauschen (und ihn dann auf einen Sockel zu setzen).

@Rüdiger: Im konkreten Fall kann Deine Lösung möglicherweise nicht helfen, wenn die Speicherzellen nicht sofort umkippen sondern evtl. erst einige Minuten nach dem Beschreiben. Dazu prüft eine Software meist zu schnell.

Nachtrag @Ralph: In einem anderen Thread las ich Deine Frage zum Refresh. Das zu prüfen hab ich alles durch, es war eine Sackgasse. Die technische Erklärung ist: Der Refresh für den 64k-RAM wird direkt vom Prozessor über den Adressbus gesteuert. Die RAM-Floppy wird nicht direkt vom Adressbus sondern über E/A-Adressen angesteuert. Deshalb mußte hier der Refresh separat erzeugt werden. Ein Defekt an dieser Stelle wirkt sich nur auf die RAF aus, nicht auf den Hauptspeicher.

Viele Grüße

Heiko
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
033
05.02.2008, 19:57 Uhr
Ralph




Zitat:
Heiko...Nachtrag @Ralph: Der Refresh für den 64k-RAM wird direkt vom Prozessor über den Adressbus gesteuert.

Hm... alles recht merkwürdig, der 64KRAM bekommt doch KEINEN extra Refresh!! oder reicht es das das MRQ (auch bei RFSH?)aktiviert wird ?
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
034
05.02.2008, 20:01 Uhr
Ralph



und weiter zum Kernproblem....

also das mit den umkippenden Bytes kann offensichtlich nicht so sein, denn es läuft alles so wie es sein muss.. Ich hab den ganzen RAM mit FF gefüllt und in Abständen von 5...30min byteweise gelesen.. es trat nie ein einziges von FF abweichendes Byte auf!
Mein Posting 029 war durch einen Wackelkontakt auf der EPROMFloppy ausgelöst und daher die abweichende CRC Checksummen.. jetzt sind sie immer gleich....
Langsam weis ich jetzt auch nicht weiter, denn als ich jetzt mal den Edas getestet habe, trat das Problem sofort wieder auf!!

Gruß Ralph
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
035
05.02.2008, 23:29 Uhr
Enrico
Default Group and Edit



Zitat:
Ralph schrieb

Zitat:
Heiko...Nachtrag @Ralph: Der Refresh für den 64k-RAM wird direkt vom Prozessor über den Adressbus gesteuert.

Hm... alles recht merkwürdig, der 64KRAM bekommt doch KEINEN extra Refresh!! oder reicht es das das MRQ (auch bei RFSH?)aktiviert wird ?

Dann hast Du ja Refresh. Wenn /MREQ und /REFSH aktiv sind, wird auf auf dem Adressbus die Refreshadress hochgezählt. Das sind A0-A6.
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
036
05.02.2008, 23:44 Uhr
Ralph



@Enrico.. ja da hast Du recht, aaaaaaaaaber bei der Ramfloppy der MP3/88 ist eben KEIN MRQ und Refresh für die 64K Hauptspeicherbank verknüpft, nur für die RamDiskBänke....und es geht dennoch... das Refreshsignal hat keinerlei logische Verbindung zum Hauptspeicher...
Meine Frage war, ob der RAM auch nur mit MRQ (OHNE RFSH) refresht wird..
--
Es geht alles erst richtig los !

Dieser Beitrag wurde am 05.02.2008 um 23:53 Uhr von Ralph editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
037
05.02.2008, 23:51 Uhr
Ralph



@alle :-) *freu*, *aufdemtischtanz* und noch viel mehr....
Mein Problem ist keines mehr!!!! Es geht wieder und ihr werdet es nicht glauben..
Eine einfache Durchkontaktierung eines in der Ansteuerung des Bustreibers befindlichen DL hatte keinen Kontakt mehr (unter dem Stecker zum Bus) ...und damit war der MassePin des DL betroffen... so schwankte das Signal für die Umschaltung des Bustreibers sehr stark und das machte mich stutzig... gelötet und seither geht der Edas wieder so wie er soll ! *strahl*...

Ich danke Euch allen die geholfen haben..und auch denen die die Daumen gedrückt hielten!
Ein glücklicher Ralph lässt grüßen :-)
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
038
06.02.2008, 00:01 Uhr
Deff



@Ralph

Koste diese Sternenstunde in Deinem Elektronikerleben vollends aus und genehmige Dir zur Feier des Tages ein grosses Bier - meinen Glückwunsch zum Abschluss dieser Sysiphusarbeit!

Tipp:
Durch die nächsten Türen gehe vorerst mal seitlich durch, Dein Kreuz dürfte im Moment etwas Überbreite haben!
--
Die Politik ist ein Versuch der Politiker, zusammen mit dem Volk mit den Problemen fertig zu werden, die das Volk ohne die Politiker niemals gehabt hätte. (Dieter Hildebrandt)
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
039
06.02.2008, 11:21 Uhr
Heiko_P



@Ralph,

herzlichen Glückwunsch! Gestern war ich doch etwas ratlos, heute freu ich mich für Dich. Hoffentlich läuft dann auch bald der VGA-Bildschirm an Deinem AC1.

Viele Grüße

Heiko
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
040
06.02.2008, 17:19 Uhr
Enrico
Default Group and Edit



Zitat:
Deff schrieb
@Ralph

Koste diese Sternenstunde in Deinem Elektronikerleben vollends aus und genehmige Dir zur Feier des Tages ein grosses Bier - meinen Glückwunsch zum Abschluss dieser Sysiphusarbeit!

Tipp:
Durch die nächsten Türen gehe vorerst mal seitlich durch, Dein Kreuz dürfte im Moment etwas Überbreite haben!

Hornbach: "Man wächst mit seinen Aufgaben!".
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
041
06.02.2008, 21:41 Uhr
Ralph



@Enrico.. Du hats Recht, aber das war nicht der erste knifflige Fehler den ich gefunden habe. Glücklicherweise finde ich fast immer ne Lösung :-), auch wenn ich viel Frage, aber wir wissen ja... Wissen ist.. macht nix...
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
042
06.02.2008, 22:59 Uhr
Ralph



@alle... wisst ihr wie schön sauber jetzt der Edas mit 4Mhz läuft?? einfach herrlich... :-)
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
043
06.02.2008, 23:27 Uhr
Enrico
Default Group and Edit


Gratuliere!
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
044
06.02.2008, 23:34 Uhr
Ralph



@Enrico... Danke, aber was ist nun mit dem Refresh ? Erhält der RAM einen Refresh wenn nur mit dem MRQ auf den Speicher zugegriffen wird? (Ich meine ja, weis aber nicht wie und warum)
Also nochmal... es ist KEIN RFSH Signal im Spiel (MRQ=L wenn RFSH=L ??)
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
045
06.02.2008, 23:54 Uhr
Enrico
Default Group and Edit



Zitat:
Ralph schrieb
@Enrico... Danke, aber was ist nun mit dem Refresh ? Erhält der RAM einen Refresh wenn nur mit dem MRQ auf den Speicher zugegriffen wird? (Ich meine ja, weis aber nicht wie und warum)

Wenn ständig auf den RAM zugegriffen wird, hast Du auf die Art automatisch einen Refresh. Das muss aber häufig genug und mit alle Adressen geschehen. Da das normalerweise nicht ständig gegeben ist wird der Refresh normaleweise mit MREQ und RFSH gemacht.

Zitat:
Also nochmal... es ist KEIN RFSH Signal im Spiel (MRQ=L wenn RFSH=L ??)

Nein. Genau das ist der Refresh-Zyklus. Die CPU Signale sind L-aktiv.

Ich kenne mich mit dem AC1 da leider nicht aus. Kann schon sein, dass das das BS ein Software-Refresh macht. Die Schaltung kenne ich ja auch nicht...
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
046
06.02.2008, 23:54 Uhr
robbi
Default Group and Edit
Avatar von robbi

Mein Verständnis von der Sache:
CPU-Ausgang:
wenn Speicherabfrage --> /MREQ = 0, also aktiv
wenn Refresh --> /RFSH = 0, also aktiv
Das Refreshsignal kommt von der CPU. Sie startet einen Refresh-Zyklus spätestens alle 2 ms.
Verknüpft man /MREQ und /RFSH und die Adressen des Speicherbereiches, den man auffrischen will, zu /RAS, dann kann man den Speicher mit RAS-ONLY-REFRESH am Leben erhalten.
Das passiert dann sogar, wenn der RAM als Rambank im Hintergrund liegt.
Ansonsten wird ja /RAS zur Übernahme der Zeilenadressen benötigt.

Wie das genau beim AC1 gelöst ist, weiß ich nicht. Habe keine Schaltung von dem Teil.
--
Schreib wie du quatschst, dann schreibst du schlecht.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
047
07.02.2008, 00:01 Uhr
Ralph



@Jungs... hier geht es NICHT um den AC1 sondern um die Ramfloppy aus der MP3/87.
Die enthält eine 256K Ramfloppy UND einen 64K (von der Ramfloppy unabhängigen) Hauptspeicher... soweit erstmal.. und hier genau ist MEIN Problem.. für die RamFloppy wird RFSH mit MRQ verknüpft (das ist klar und im AC1 auch so), ABER im Hauptspeicher wird RFSH außen vor gelassen!!..und dennoch geht es... der Speicher merkt sich alles, auch wenn der Rechner nur Däumchen dreht und im Monitor (0..FFF) rumdümpelt....

Sorry, aber ich hoffe ihr habt das jetzt verstanden, wenn nich...dann weis ich auch nicht weiter..

@Edit... es wird nur MRQ, M1!! und RD & WR ausgewertet..und so langsam glaub ich, das der Refresh vom M1 Signal ausgelöst wird
--
Es geht alles erst richtig los !

Dieser Beitrag wurde am 07.02.2008 um 00:04 Uhr von Ralph editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
048
07.02.2008, 00:04 Uhr
Enrico
Default Group and Edit


Ach so. Na davon habe ich aber auch keinen Plan.
--
MFG
Enrico
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
Seiten: -1-     [ Technische Diskussionen ]  



Robotrontechnik-Forum

powered by ThWboard 3 Beta 2.84-php5
© by Paul Baecher & Felix Gonschorek