Es ist manchmal schon sehr mühselig bereits kleinere Probleme mit Assembler lösen zu müssen. Was uns für das Steckschwein fehlt ist eine einfache Sprache mit der man kleine Dinge erledigen und zeigen kann.

Also, warum nicht ein einfaches Basic für das Steckschwein portieren? Die Auswahl an guten Basic-Implementierungen ist überschaubar und unsere Wahl fiel in dem Fall auf EhBasic von LeeDavison. Warum? Nun, es hat sich gezeigt, dass EhBasic von vielen Homebrew-Projekten verwendet wird, die eine 6502-CPU-Basis benutzen. Darüber hinaus scheint EhBasic sogar eine sehr gute Implementierung zu sein, weil die Performance und Erweiterbarkeit gegenüber anderen Basics für diese Zielplattform herausragend ist.

Vor einer Weile haben wir im Beitrag eine-fantastische-reise den Weg zu unserem aktuellen Tastaturcontroller beschrieben.

Wer nicht nochmal nachlesen möchte: Ein ATmega8 dient als SPI Slave als Interface zwischen PS/2-Protokoll, Tastaturmapping und Puffer. Als Basis dient eine angepasste Version des Codes aus AVR Application Note 313, die als Ausgabeschnittstelle den USART des ATmega8 vorsieht. Dies haben wir durch das SPI-Interface des AVR ersetzt.

Steckschwein-Seitig haben wir die Tastaturabfrage immer im Blank-Interrupt des Videochips vorgenommen, genauer gesagt, jeden zweiten Blank. Damit wurde der AVR auf SPI-Seite relativ wenig gestresst.

Im Chrome Browser gibt es einen netten Zeitvertreib in Form des Games “Dinosaur”. Das Spiel wird immer dann eingeblendet, wenn keine Internet-Verbindung verfügbar ist. Das Spiel ist sehr einfach aufgebaut, kann aber leicht süchtig machen und ist ein netter Zeitvertreib bis die Verbindung wieder verfügbar ist. Genau diese Einfachheit der Grafik und des Gameplays brachte mich auf die Idee das Spiel für das Steckschwein umzusetzen. Wie ich dabei vorgegangen bin, möchte ich Euch hier schildern.

Als Abfallprodukt der letzten Debugging-Session bezüglich SD-Karten und dessen, was von ihnen gelesen wird, hat die Shell ein kleines Hexdump-Feature bekommen, mit dem sich Speicherinhalte ähnlich wie beim “M”-Kommando bei diversen Maschinensprachemonitoren ausgeben lassen.

Die Handhabung ist entsprechend bekannt: “dump “, abgebrochen werden kann mit Ctrl-C. Als Abfallprodukt hiervon gilt das jetzt auch für Directory-Listings.

Damit hat die SteckShell nunmehr die Versionsnummer 0.10.

Unser “Standard”-Massenspeicher SD-Karte funktioniert zwar an und für sehr gut, Sorgenkind war aber immer die Initialisierungs-Routine. Bisher ließen sich damit nur günstige Class4-Karten initialisieren, bei “höherwertigen” Karten schlug die Initialisierung immer fehl, sodass nur etwa 3 von 5 Karten nutzbar waren.

Initialisierungs-Ablauf nach elm-chan.org

Das hat uns schon etwas gewurmt, denn irgendwie hatte dieser Stand ein Geschmäckle von “Funktioniert aus Versehen”. Also mussten wir da nochmal ran. Der Initialisierungs-Flow entspricht im Wesentlichen dem, was auf der bekannten Seite http://elm-chan.org/docs/mmc/mmc_e.html dokumentiert ist. In den letzten Tagen haben wir diesen unter die Lupe genommen, und tatsächlich ist etwas aufgefallen. Vor dem Senden eines Kommandos muss sichergestellt werden, dass die Karte bereit ist. Hierzu sendet man solange $ff an die Karte, bis diese auch $ff zurücksendet. Dann ist die Karte bereit, ein Kommando zu empfangen. In unserer Initialisierungsroutine wurde dies zwischen CMD55 und ACMD41 (näheres bitte dem Link entnehmen) schlichtweg nicht gemacht. Plötzlich lassen sich fast alle vorhandenen Karten initialisieren. Dass dies mit den Class4-Karten trotzdem funktionierte, war also gewissermaßen tatsächlich aus Versehen.

In der letzten Zeit war es hier etwas still ums Steckschwein, was aber nicht als Indiz für Untätigkeit gelten soll. Hauptsächlich haben wir uns auf das Schreiben von Code konzentriert, die Shell wurde weiterentwickelt, etc. Darüberhinaus gab es erste Experimente mit CPLDs. Auf dieser Basis sollen ja zukünftige Verbesserungen der Hardware entstehen, begonnen bei einem eigenständigen SPI-Controller bis hin zur Zusammenfassung der bestehenden Glue-Logik rund um die Adressdekodierung. Da ich mir zu diesem Zweck testhalber solche CPLD-Entwicklungsplatinchen auf Basis des XilinX XC9572XL habe kommen lassen, stellte sich also als erstes die Frage, wie sich dessen 3.3V-basierte Logik mit dem 5V-Steckschwein vertragen würde. Zum CPLD hin wären ja keine Probleme zu erwarten, denn die IO-Pins des XC9572XL sind 5V-tolerant. Die Richtung vom CPLD zum Steckschwein bedarf also besonderer Betrachtung, denn es muss sichergestellt werden, dass alle Bausteine am Bus, die mit dem CPLD verbunden sind, dessen 3.3V-Logikpegel zuverlässig erkennen. Als einzige wirklich problematische Komponente stellte sich hier - wieder mal - der auf meinem Steckschwein eingesetzte (Marko nutzt einen 65c02 von Rockwell) WDC 65c02 heraus. Das Datenblatt gibt als “Input High Voltage”, also die Spannung, ab der auf der entsprechenden Leitung (BE, D0 -D7, RDY, /SO, /IRQ, /NMI, PHI2, /RES) eine logische 1 erkannt wird, mit “VDD*0.7” an. Bei einer Betriebsspannung von 5V also 3,5V. Mit 3.3V-Pegeln also schonmal nicht kompatibel. Geschweige denn mit TTL-Pegeln. Die leider so ziemlich alle auf dem Datenbus liegenden Bausteine verwenden, mit Ausnahme der WDC 65c22 VIA.  Alle anderen Bausteine geben im Datenblatt als “High Level Output Voltage” Werte von 2.4-2.7V an.  Kann also gar nicht passen. Dass das Steckschwein trotzdem mit dem WDC funktioniert ist ganz offenbar Glück bzw. der Tatsache geschuldet, dass der Chip dann doch toleranter ist als das Datenblatt uns glauben machen will.  Trotzdem nicht sauber. In zukünftigen Revisionen müssen wir also zwischen CPU und Datenbus einen 74HCT245-Buffer eindesignen, der durch TTL-kompatible Eingänge und CMOS-Ausgänge die Pegelunterschiede ausbügelt. Gleiches gilt auch für weitere Experimente mit dem 3.3V-CPLD. Oder auch mit dessen 5V-Vorgänger XC9572.  Zusammenfassend also noch einmal die Besonderheiten des 65c02 von WDC: