Die Zeit ist reif für ein Hardware-Update, und zwar für die IO-Platine 2.0. Vorgesehen war ja schon länger, den UART dort zu integrieren. Ausserdem war das Joystick–Interface noch unausgegoren, sodass auch hier etwas Neues entwickelt wurde.

Zum Schutz der VIA-Pins dienen nun keine Optokoppler, sondern simple Serienwiderstände sollen die Ports zumindest vor dem Fall schützen, dass man doch mal die Datenrichtung der Joystick-Pins auf Ausgang schaltet und dann die VIA grillt indem man den Joystick betätigt. Die Widerstände begrenzen den Strom auf 1mA. Das muss die VIA abkönnen. Zudem war im vorigen Design der Userport nicht wirklich nutzbar, weil immer noch die Joysticks daran hingen. Jetzt ist es so, dass jeder Joystick über Tri State Buffer an VIA Port A verbunden wird, und zwar grundsätzlich wahlweise. Ausserdem besteht die Möglichkeit, die Joyports komplett abzuschalten. Dies wird mit dem OUT1-Pin des UART bewerkstelligt. Somit läßt sich per Software konfigurieren, ob man Userport oder Joystick benutzen möchte.

Das Programmieren von Soundchips ist nicht trivial. Das habe ich damals auf dem C64 schon nicht kapiert. Mit dem Yamaha YM3812 oder auch OPL2 hat das Steckschwein einen weit komplexeren Chip als den SID, denn OPL2 kennt gleich ganze 9 Stimmen statt drei, und jede ist über eine Unzahl Parameter konfigurierbar.

Wie funktioniert der YM3812?

Wie kriegt man also einen Ton aus diesem Monstrum? Die beste Quelle zum Thema OPL2 ist wohl “Programming the AdLib/Sound Blaster FM Music Chips” von Jeffrey S. Lee. Zumindest wird einem hier schnell klar, was auf einen zukommt, will man auch nur einen einfachen Ton ausgeben. So hat der OPL2-Chip insgesamt 244 Register, die neben den Stimmen auch die integrierten Timer konfigurieren, und belegt 2 Portadressen. Konkret bedeutet das, dass man in Adresse 1 die Nummer des gewünschen Registers schreibt. Nach 3.3µs liegt an Adresse 2 das gewählte Register zum Beschreiben an. Lesen läßt sich nur das Statusregister. Hat man also das gewählte Register beschrieben, ist der Chip dann 23µs nicht ansprechbar.

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:

Kein VCFe ohne einen resümmierenden Post-VCFe-Post von uns.

Vorweg: Der neue Veranstaltungsort im Kulturzentrum Trudering ist hervorragend. Eine moderne Veranstaltungshalle, mehr Platz als in der alten ESV-Turnhalle, großzügiger Foyerbereich und ein deutlich größerer Vortragsraum. Die Nahrungsversorgung bestreitet im Kulturzentrum Trudering das integrierte indische Restaurant “Taj”, welches ebenso überzeugen konnte. Alles in allem ein großer Gewinn und allen Anzeichen nach wird das nächste VCFe auch wieder dort stattfinden.

Das Steckschwein auf dem VCFe 18.0

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.

Nachdem EhBasic brauchbar auf unserem SteckOS-Kernel läuft, fehlen noch 2 Kleinigkeiten für das vollkommene Glück. Denn noch lassen sich die geschriebenen BASIC-Kunstwerke nicht speichern. Dies stellt uns gleich vor 2 Herausforderungen:

1. Unsere FAT32-Implementierung beherrscht noch gar keinen Schreibzugriff. Genauer gesagt ist es noch nicht möglich, freie Cluster zu finden und Verzeichniseinträge zu erzeugen.
2. LOAD und SAVE existieren in EhBasic nur als Vektoren, an die bei Aufruf gesprungen wird. Was dort passieren soll, muss für die jeweilige Hardware selbst implementiert werden.

Fangen wir also ganz vorne an. Neue Dateien anlegen können wir noch nicht, da wir noch keine Operationen auf der FAT unterstützen, also auch keine freien Cluster finden können. Der Kunstgriff hier ist, diese Aufgaben von einem System erledigen zu lassen, das das schon kann. Dementsprechend werden einfach auf einem PC der Wahl auf der Karte Dateien FILE0000.DAT bis FILE0009.DAT angelegt. Diese sollen dann als unsere “Schreib-Slots” dienen. Vorhandene Dateien zu überschreiben und die Dateigröße im Directory mit der neuen Größe zu überschreiben, ist kein großes Problem.