Wir haben vor, eine neue Revision der Steckschwein-Prototyp-Platinen herzustellen. Den Anfang macht ein neues CPU-Board mit einigen Bugfixes und den in Chiptuning beschriebenen zusätzlichen GAL als Waitstate-Generator, sowie einem geändertem Stromanschluss: In Zukunft wird es möglich sein, das Steckschwein mit nur 5V per USB, über einen Rundstecker oder wie gehabt über einen Pin-Header zu versorgen. Die Layouts sind schon fertig:
Bestückungsseite
Lötseite
An den Heimcomputern von “damals” gemessen ist das Steckschwein mit 4 MHz durchaus einer der schnelleren 6502-Rechner. Damals waren zumeist Taktraten von 1 MHz üblich. Einige wenige hatten deutlich mehr, wie z.B. der Apple IIgs (65816) mit 2.8 MHz. Einen 4 MHz-65(C)02-Heimcomputer hat es damals nach unserem Informationsstand nicht gegeben.
Nun ist es aber so, dass aktuell erhältliche 65c02-CPUs von WDC offiziell mit bis zu 14MHz getaktet werden können, inoffiziell wurden schon problemlos Taktraten von 20 MHz erreicht. Da ist also noch Raum für eine Prise Größenwahn. Den Takt des Steckschweins pauschal zu erhöhen funktioniert nicht. Zu viele Bausteine kommen dann nicht mehr mit. Das verwendete Atmel 28c256 EEPROM hat eine Zugriffszeit von 150ns. Im WDC-Datenblatt ist tACC des Prozessors bei 4MHz mit 145ns angegeben. Also ist das stand jetzt schon etwas eng. Schneller takten geht also schon allein deswegen auf keinen Fall. Für den Videochip TMS9929 und den Soundchip gilt ähnliches. Das SRAM hingegen läßt sich problemlos gegen Bausteine von Alliance Memory mit 55ns Zugriffzeit austauschen. Damit sollten Taktraten von um die 10 MHz möglich sein.
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.
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.