In preparation for the build of our new CPU-Board, we purchased two WDC 65c02 in PLCC44 package from some eBay vendor. On arrival, the first interesting thing is the way they were packaged. No anti esd packaging, only a plastic bag, which we found sketchy enough to post on Twitter.
Next, WDC reacted to that tweet, stating that these might be not genuine or be at least very old.
{{/< tweet user=“steckschwein” id=“1532446031127904256” >/}}
The biggest limitation of any 8 bit CPU such as our beloved 65C02 is the amount of memory that the CPU can address. With 16 address lines, the addressable memory is maxed out at 64k. All ROM and RAM has to be crammed into there. With the 6502 being a memory mapped architecture, IO devices need their addresses there, too.
In order to expand the amount of usable memory, some trickery is necessary. For example, the developers of the C64 came up with a rather clever hack to cram 20k of ROM and full 64k of RAM and IO area into 64k address space by introducing a register that enables the programmer to switch off the ROM, giving access to the underlying RAM. When the ROM is enabled, writes to the addresses go into the RAM below. We decided to mimic this behaviour in our current implementation of the Steckschwein glue logic.
The newly made boards made their way from China to Munich. Starting now, the multi board version of the Steckschwein is made up of 3 Boards: CPU/Memory, IO/UART and V9958-OPL2.
Da ist sie nun, die neuen Videoplatine. Nach einigen Umwegen hat der Packen Boards uns erreicht (die erste Lieferung ist versehentlich in Spanien gelandet, während wir die Platinen des spanischen Bastlers erhalten haben. Inzwischen hat jeder Ersatz erhalten).
Wir haben ja bekanntlich unsere Vorgehensweise geändert, indem wir schneller Platinen anfertigen lassen. Aber zu unserer großen Freude funktionierte die erste Platine nach Bestückung auf Anhieb. Selbstverständlich haben sich aber auch ein paar Patzer eingeschlichen.
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.