Forum64

Quoted

Original von sauhund
LOL. was ein unsinn. alter schwede

Wenn du es nicht selbst machen kannst, mache ich dir die ASM-Programme. Du assemblierst sie SELBST bei dir, schaust dir das vorher an, läßt sie laufen *NICHT AUF EINEM EMU*, sondern auf einer richtigen Maschine und schaust dir das Ergebnis an. Punkt. Wir brauchen darüber nicht zu disktuieren. Ich weiss, dass es unglaublich klingt, aber das ist etwas, was jeder selbst machen kann. Keine Notwendigkeit für Diskussion. Überprüfen und selbst messen.

Zuverlässig erklären kann ich dir das nicht, meine beste Erklärung ist die durch das oben genannte Geburtstagsparadoxon, sprich die Gesetze der Wahrscheinlichkeit. Aber es ist ein messbares Ergebnis. Kein Platz für Glaube oder Aberglaube.

Quoted

Original von foobar
ich lege hanno mal das studium von $01 an die hand...

SEI natuerlich nicht vergessen

regards
foobar

*gähn* SEI *lach*

Solange ich hier rumcode können diejenigen, die es nicht glauben wollen ja mal den erstbesten Monitor nehmen, F 1000 FFFF 00 machen, danach nach irgendwas suchen, was nicht null ist usw. Das funktioniert auch, nicht abhängig von meinen Programmen. Ich sage ja: das hat nichts mit Glauben oder Unglauben zu tun. Sondern allein mit Gesetzen der Wahrscheinlichkeit und der damals zur Verfügung stehenden Hardware. Heutige Chips laufen deutlich sicherer, aber die werden auch nicht von unzuverlässigen VICs mittels Speicherrefreshzyklen aufgepusht.

Aber lass uns mal nicht drüber reden, ich bring euch gleich das Programm. Ich hoffe, irgendwer fährt noch Originalhardware und nicht nur Emus, ja? Die aktuellen Computer sind *sehr* viel speichersicherer als die damaligen.

Auf die Idee für diesen Test bin ich übrigens nicht ganz von selbst gekommen. Da gabs an der Uni einen Schnupperstudientag und die haben vorgetragen, wie sicher Rechner arbeiten und dass Fehler durchaus Wahrscheinlich sind. Wir haben mit dem selben Unglauben reagiert wie ihr jetzt. Dann bin ich nach Haus gegangen, habs nachprogrammiert und ... Tja. Die Methoden der Wissenschaft.

Hahaha, sehr unterhaltsam. Aber ich will jetzt wirklich mal das Programm sehen, statt hanebüchene Behauptungen und irgendwelche absolut unpassenden Vergleiche wie das mit dem Geburtstagsparadoxon lesen zu müssen.

Quoted

Original von Krill
Hahaha, sehr unterhaltsam. Aber ich will jetzt wirklich mal das Programm sehen, statt hanebüchene Behauptungen und irgendwelche absolut unpassenden Vergleiche wie das mit dem Geburtstagsparadoxon lesen zu müssen.

So, hier das versprochene memtest.s, als memtest-1.0.tar. Enthalten der Source (ASM für as65/cc65) sowie das lauffähige Programm und die .o Linkdatei.

Geladen wirds ganz normal, gestartet mit RUN und dann geht er von $1000 bis $FFFF durch den Speicher, mit den Folgen 00, FF, 55, AA und beginnt das wieder von vorn, bis zum St. Nimmerleinstag. Sollte ein oder mehrere Bits falsch sein, schreibt er bei dem entsprechenden Durchgang: "fehlerbits: {ANZAHL}" wobei er in {ANZAHL} die gefundenen Bitfehler des Durchgangs summiert hat.

Da es von C=64 zu C=64 unterschiedlich lange dauern kann, bis die ersten Fehler auftauchen (bei jüngeren Kisten seltener...), müsst ihr das schon eine Weile laufen lassen.

Auf einem Emu ergibt das nichts weiter als eine lange Reihe ".". Der Punkt wird bei jedem fehlerlosen Durchgang ausgegeben. Wer keine Punkte haben möchte, poke den LDA #$0d einfach auf LDA #$00 um. Poke 2118,0 müsste das stoppen, POKE 2118,asc(".") wieder aktivieren.

Meldet mal, wie sich eure C=64 verhalten, meiner spuckt nach ein paar Minuten tatsächlich Fehler aus. Auf dem Vice-Emu läuft das seit einer Viertelstunde fehlerfrei.

Zum Anhang: ein "tar" ist ein Unix-Archiv, genau das selbe wie ZIP oder RAR oder sonstige Archiver. Winzip, Winrar usw. können das entpacken.


Nachtrag: zum Geburtstagsparadoxon

Das Beispiel passt nicht ganz, aber die Mathematik dahinter ist die selbe. Die Wahrscheinlichkeit für das zufällige Zusammentreffen von zwei unglücklichen Ereignissen steigt exponentiell zur Anzahl der teilnehmenden Personen (in diesem Falle sind die Personen die möglichen Ereignisse im Ereignisraum). Das kann ich genauer ausführen, aber wer das Geburtstagsparadoxon nicht kennt und nicht versteht, für den halte ich keine Vorlesung, wer es versteht, begreift, warum die Situation ähnlich ist.

Mein Vice ist nach etwa einem Bildschirm voller Punkte abgeschmiert. Also das C=64 Programm, nicht VICE. Daraufhin hab ich resettet und den SVS-Mon geladen. Und fand im Speicher, der durchgehend mit $FF beschrieben war, ab und zu Werte wie $55 oder $BA und zwar willenlos verteilt, mal hier mal da.

Das hätte meiner Meinung nach nicht sein dürfen. Zumindest hätte er mir da Fehler ausspucken sollen. Ich lasse jetzt noch einen Testlauf durchlaufen. So wie ich es sehe, ist das Programm okay. Das mit dem Fehlerzählen mit Bits habe ich nur oberflächlich getestet und für gut befunden.

Kann doch nicht sein, dass dieser Effekt auf *allen* meinen Computern und nur meinen stattfindet? Aber im Falle Vice hängt das wahrscheinlich damit zusammen, dass ich einen Runstop-Restore gemacht habe. Da ist der sicher beim NMI abgeschmiert und daher zählt das natürlich nicht. Trotzdem seltsam.

Ich hab hier nochmal eine neue Version beigefügt, die auch auf RUNSTOP reagiert und rausspringt. Der POKE hat sich damit auch geändert auf 2134,0

Quoted

Original von sauhund
das program läuft hier jetzt, wie erwartet ohne fehler, seit über einer stunde auf dem c64. nix mit geburtstag und so

Interessant. Welches Baujahr?

Irgendwann schlägt der Fehler zu. Aber wenn dein Rechner eine Stunde lang läuft, sieht das schon ganz gut aus. Auf PCs, deren Speicher ich getestet habe, sind die Speicherfehler mittels memtest86 oftmals erst nach Stunden aufgetaucht. Memtest86 testet allerdings auch unterschiedliche Schreibzugriffe und Lesezugriffe auf den Speicher und kombiniert diese.

Fehler treten dort natürlich auch auf, irgendwann. Aber nach einem Tag fehlerlosem Betrieb ist es normalerweise so, dass ich ein "Okay" gebe. Ist die Fehlerquote niedriger als ein Bit in 24h, ist die Diskussion über Bitfehler hinfällig. Tatsache ist - sie finden statt, auch auf aktuellen Systemen.

Meiner Vermutung nach haben alte Modelle mehr Speicherfehler als neue. Das wäre allerdings zu testen...

Meine bislang nicht statistisch signifikanten Untersuchungen beschränkten sich allein auf einige Modelle der Baujahrreihe '83 und '84. Sicher nicht mehr als zehn getestete Rechner.

Oh Mann.
Was fürn Mumpitz.

Hab mir das Proggy noch gar nicht gezogen.
Und ich glaube, ich tu's auch nicht.
Unnötig.

Weil:
1.
Wenn Crossbow saacht, "nix kippt " , dann kippt nix.

2.
Wenn Bits einfach mal so Geburtstag feiern gehn, wären sämtliche Rechner sowie ihre Programme zu Sinnlosigkeit verdammt.

3.
Kein Mensch hätte jemals Zeit genug gehabt, ein Game durchzuzocken, weil ein paar Bits während dem besten Ballern feiern gehn.
Und Ballern dauert ain paar Stunden...

4.
Mein C64 schon WOCHEN(!!!) am Stück durchlief.
Zum bersten voll mit Code.
Nix Absturz.Nix kippen.


Das Beste ist allerdings, dass der REFRESH, der die RAMs ja am LEBEN hält, jetzt auch gleichermasen der Sündenbock ist, dass die Bits sich umdrehen

Damit die dynamischen RAMs im C64 funktionieren, die Bits also NICHT KIPPEN, muss ein Refresh-Puls die internen Kondensatoren aufladen.
(naja...Kondensatörchen... )

"...die Bedeutung und Gewichtung eines einzelnen Bits ist als gar nicht so schwerwiegend zu erachten.."


Das hätte Bill Gates sagen können.

Oder die ganzen Penner, die mir tagtäglich um die Ohren hauen, dass man "..heute gar kein Lo-Level-Coding mehr machen müsste, weil das alles vom Betriebssystem und dem Treiber erledigt wird..."
ZUM KOTZEN.

Dabei ist ja nicht das schlimme, dass man es nicht mehr zu machen BRAUCHT, sondern dass man erst gar keine INFORMATIONEN mehr erhält, wenn man es machen WILL !

...demnächst werde ich ATI entern.....

SEI
LSR $D011
LDA #$00
Loop:
STA $D020
NOP
NOP
NOP
JMP $Loop

Ob's klappt, hängt von der VIC-Version ab, also n paar C64-Modelle testen.


Greetz to all, Caddy6510 aka CatWeazLe 6510.


PS.

Wenn ich mich doch entschliessen sollte, dass Proggy zu laden und zu testen, dann hoffe ich, dass nicht doch was passiert...Oh Gott...das wärs noch!

Greetz