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:
Wäre auch zu einfach gewesen.
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.
Damit Klarheit darüber herrscht, worum es überhaupt geht, haben wir den Schaltplan in die einzelnen Gruppen (Prozessor+ Freunde, Speicher, UART) zerlegt.
Die aktuelle Stückliste liest sich laut Eagle folgendermaßen:
Part Value Device C1 100n C5/3 C3 1n C-EU025-025X050 C4 10n C-EU025-025X050 C5 10µF CPOL-EUE2,5-6E C6 100n C5/3 C7 100n C5/3 C8 100n C5/3 C12 1µF CPOL-EUE2,5-6E C13 100n C5/3 C14 100n C5/3 C15 100n C5/3 C16 1µF CPOL-EUE2,5-6E C17 1µF CPOL-EUE2,5-6E C18 1µF CPOL-EUE2,5-6E C19 1µF CPOL-EUE2,5-6E IC1 CY62256LL-PC CY62256LL-PC IC3 CY62256LL-PC CY62256LL-PC IC4 NE555 NE555 IC5 28c64 2864 IC6 16550 UART XR-16C550P IC8 74LS06N 74LS06N IC9 GAL22V10 22V10 IC10 MAX232 MAX232 QG1 2MHz XO-14 QG2 1.