Murphy

Inzwischen sind die 74F00 eingetroffen und der 74HCT00 durch einen ebensolchen ersetzt. Das Oszilloskopbild sieht gleich deutlich besser aus:

gelb: /WE, blau: A9

Der Schreibvorgang wird also jetzt zumindest abgeschlossen, bevor sich die Adresse auf dem Adressbus ändert. Das ist schonmal viel sauberer.

Nur leider hat es das Problem nicht gelöst, das Steckschwein läuft mit den “richtigen” RAMs immer noch instabil, was sich insbesondere bei BASIC-Programmen bemerkbar macht:

Auf dem VCFe 18.0 gab es Dank Nick Müller die Möglichkeit, das Steckschwein mal mit einem Logic Analyzer “für große Jungs” zu untersuchen. Unsere USB-Logic-Analyzer sind zwar für vieles gut, aber um komplett Adress- und Datenbus sowie einschlägiger Steuerleitungen abzuhorchen, fehlen einfach Kanäle, und selbst dann wären sie nicht schnell genug.

Das Steckschwein am Logic Analyzer. im Hintergrund Nicks Finger.

Die Gelegenheit, ein solches Höllengerät (genauer: ein HP 1652B) und mit Nick auch noch jemanden greifbar zu haben, der selbiges beherrscht, gibt uns die Chance, ein merkwürdiges Problem zu untersuchen, welches schon länger Rätsel aufgibt: Die aktuell verwendeten Hyundai-SRAMs sind mit einer Zugriffszeit von 100ns eigentlich viel zu langsam für 8MHz, zumal der 6502 ja nur die 2. Takthälfte für Buszugriffe nutzt. Diese ist nur 62,5ns lang. Von dieser Zeit geht ausserdem noch die Durchlaufzeit der Adressdekodierung und weiterer Glue-Logik ab. Eigens angeschaffte neue SRAMs von Alliance Memory mit 55ns Zugriffszeit sollten also ganz knapp schnell genug sein. Trotzdem treten mit diesen immer wieder merkwürdig zufällige Abstürze auf, die 100ns-Chips laufen dagegen problemlos.

In den Posts http://8bit-gefriemel.blogspot.de/2014/03/murphy.html und http://8bit-gefriemel.blogspot.de/2014/04/murphy-ii.html sind einige merkwürdige Phänomene und deren Lösungsversuche geschildert. Wie sich heute gezeigt hat, konnten wir gar nicht weiter daneben liegen.

Alles Quatsch. Die Fehlersuche nach dem “K”-Problem. Stack und so. Alles super. Klar, das mit dem Initialisieren des Stackpointers war natürlich richtig und wichtig, und dass die uart_tx routine besser funktioniert wenn man auf Stack-Operationen verzichtet, hätte uns eigentlich eher stutzig machen sollen. Aber der Reihe nach.

Flugs also ein ROM gebrannt mit der memtest-routine, in die nach der Reset-Routine eingesprungen wird. Gleiches Ergebnis. Beim ersten Auftreten des “K statt OK”-Fehlers ist erstmal die doch etwas windig anmutende Verdrahtung der Adressleitungen zwischen Prozessor, den RAM-Bausteinen und dem ROM mit “richtigen” Steckbrettstrippen statt Klingeldraht nachverdrahtet worden. Das war vermutlich etwas voreilig, schließlich hats vorher ja auch schon funktioniert. Schließlich stellt sich heraus, dass sich hier in der Tat ein paar Fehler eingeschlichen haben, die auch beim Durchklingeln der einzelnen Adressleitungen nicht aufgefallen sind: Kurzschlüsse.  Nachdem diese behoben wurden, läuft unser Speichertest auch wieder komplett durch.  Zeit also, sich dem eigentlichen Problem anzunehmen. Wo bleibt das “O”? Interessanterweise scheint das Empfangen von Daten nicht betroffen zu sein, denn die memtest-Routine funktioniert hochgeladen genauso wie aus dem ROM.  Also schaue ich mir die Routine an, die Daten (bytes) über den UART sendet.

Neben all den ermutigenden Experimenten gibt es natürlich auch immer mal wieder Rückschläge. Mittlerweile haben wir schon ein durchaus komplexes Gebilde auf dem Steckbrett, welches ja per se nicht die ideale Plattform ist, um so etwas zu bauen.

So wie aktuell gerade mein “Steckschwein” ein sehr merkwürdiges Verhalten an den Tag legt, ohne dass an der Schaltung etwas geändert worden wäre (Marko ist Zeuge).

Vorab nochmal der Ablauf unserer Upload-Routine, mit der wir das Steckschwein via RS232 mit Code befüttern: