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.

Vor geraumer Zeit hatten wir ja bereits EhBASIC auf dem Steckschwein zum Laufen gebracht. Diese Version war im Wesentlichen eine Machbarkeitsstudie. Diese setzte auch noch nicht auf unseren SteckOS-Kernel auf, sondern auf BIOS-Routinen. Hier lag also noch ein wenig Arbeit vor uns.

Die EhBASIC-Dokumentation setzt bei einem potentiellen Portierungsziel nicht sehr viel voraus, und dies sind schon die “Preferred requirements”:

1. 6502 or better processor (65c02, CCU3000, M38xx).
2. 10k ROM or RAM for the interpreter code.
3. RAM from $0000 to $BFFF (more with changes).
4. Any character based I/O (e.g. RS232, LCD/keyboard etc).

Punkte 1 und 2 sind schnell abgehakt. Einen 65c02 hat das Steckschwein ja. 10k ROM haben wir nicht am Stück, jedoch wollen wir das Basic ja als Programm im RAM ausführen, und davon haben wir 64k. Alles klar.

Es ist mal wieder recht still ums Schwein. Und mal wieder ist das kein Indiz dafür, dass nicht gewerkelt wird. In den letzten Wochen wurden BIOS und der SteckOS-Kernel auf Basis des Assemblers ca65 neu gebaut. Dessen nachgelagerter Linker erlaubt eine übersichtlichere Strukturierung der Codebasis.

In den FAT32-Code wird aktuell ebenfalls einiges an Hirnschmalz investiert, um endlich Cluster Chain lookups und Schreib-Support bauen zu können.

Darüberhinaus kam letzte Woche der Geistesblitz, die Kommunikation des Tastaturcontrollers ATmega8 mit der Tastatur über dessen eingebauten USART zu machen, anstatt “Zu Fuß” in Software. Hier wird aktuell also auch geforscht. Wenn das klappt, dann wird dies auf jeden Fall in das Redesign des IO-Boards einfließen.