In den Posts http://8bit-gefriemel.blogspot.de/2014/03/murphy.html und http://8bit-gefriemel.blogspot.de/2014/04/murphy-ii.html sind einige merkwürdige Phänomene und deren Lösungsversuche geschildert. Wie sich heute gezeigt hat, konnten wir gar nicht weiter daneben liegen.

Alles Quatsch. Die Fehlersuche nach dem “K”-Problem. Stack und so. Alles super. Klar, das mit dem Initialisieren des Stackpointers war natürlich richtig und wichtig, und dass die uart_tx routine besser funktioniert wenn man auf Stack-Operationen verzichtet, hätte uns eigentlich eher stutzig machen sollen. Aber der Reihe nach.

Damit Klarheit darüber herrscht, worum es überhaupt geht, haben wir den Schaltplan in die einzelnen Gruppen (Prozessor+ Freunde, Speicher, UART) zerlegt.

Die aktuelle Stückliste liest sich laut Eagle folgendermaßen:

Der 65c02-Prozessor nebst Oszillator und RESET-Schaltung, welche aus dem Commodore-PET übernommen wurde und dem GAL, der zu Dekodierung des Adressbereichs von $8000 bis $ffff dient. Nicht zu sehen ist der Pull-Up-Widerstand für die BE (Bus Enable)-Leitung der WDC-Variante des 65x02, ohne den der Prozessor in einen Tri-State-Zustand geht und sich vom Bus abkoppelt.

Die Programmierung eines Computers, der nur aus einer gesteckten Schaltung besteht und weder Tastatur noch Speichermöglichkeit hat, ist eine mühsame Angelegenheit. Die allerersten Experimente bekamen ihr Futter auf einem 27128-EPROM serviert. Bekanntlich wollen diese vor dem Beschreiben mit neuem Code mit UV-Licht gelöscht werden. Also wurde für jedes Update ein EPROM mit neuem Code gebrannt, um die EPROMS anschließend in 10er-Packen ins Löschgerät zu schieben. 15 Minuten Kaffeepause.

Überhaupt, Code: Für die ersten Experimente hat es genügt, die reinen Hexcodes in einen Hexeditor zu tippen und die Daten dann zu brennen. Dies war vertretbar, da die ersten Programme etwa so aussahen: EA EA EA EA EA EA EA EA C9 C9 C9 C9 C9 C9 C9 C9 4C 00 0E

Flugs also ein ROM gebrannt mit der memtest-routine, in die nach der Reset-Routine eingesprungen wird. Gleiches Ergebnis. Beim ersten Auftreten des “K statt OK”-Fehlers ist erstmal die doch etwas windig anmutende Verdrahtung der Adressleitungen zwischen Prozessor, den RAM-Bausteinen und dem ROM mit “richtigen” Steckbrettstrippen statt Klingeldraht nachverdrahtet worden. Das war vermutlich etwas voreilig, schließlich hats vorher ja auch schon funktioniert. Schließlich stellt sich heraus, dass sich hier in der Tat ein paar Fehler eingeschlichen haben, die auch beim Durchklingeln der einzelnen Adressleitungen nicht aufgefallen sind: Kurzschlüsse.  Nachdem diese behoben wurden, läuft unser Speichertest auch wieder komplett durch.  Zeit also, sich dem eigentlichen Problem anzunehmen. Wo bleibt das “O”? Interessanterweise scheint das Empfangen von Daten nicht betroffen zu sein, denn die memtest-Routine funktioniert hochgeladen genauso wie aus dem ROM.  Also schaue ich mir die Routine an, die Daten (bytes) über den UART sendet.

Neben all den ermutigenden Experimenten gibt es natürlich auch immer mal wieder Rückschläge. Mittlerweile haben wir schon ein durchaus komplexes Gebilde auf dem Steckbrett, welches ja per se nicht die ideale Plattform ist, um so etwas zu bauen.

So wie aktuell gerade mein “Steckschwein” ein sehr merkwürdiges Verhalten an den Tag legt, ohne dass an der Schaltung etwas geändert worden wäre (Marko ist Zeuge).

Vorab nochmal der Ablauf unserer Upload-Routine, mit der wir das Steckschwein via RS232 mit Code befüttern:

Die 65x51 ACIA erschien uns als die am tiefsten hängende Frucht, um eine RS232 Schnittstelle zu implementieren, nachdem wir Bit Banging nach C64 Vorbild ziemlich schnell verworfen hatten.
Auch programmiertechnisch mach die ACIA einen simplen Eindruck, ganze drei Register wollen beherrscht werden.
Die rs232-Schnittstelle ermöglicht uns, Code auf den Steckbrettrechner zu laden, ohne jedesmal das EEPROM neu brennen zu müssen. Eine gewaltige Erleichterung.

Aber - wir haben es bereits erwähnt - die ACIA hat keine Zukunft bei uns. Die uns vorliegenden Chips können mit bis zu 2 MHz getaktet werden. Wir aber wollen hoch hinaus. Mit den aktuellen 65cXX-Chips von WDC sind schließlich bis zu 14MHz möglich.
Darüberhinaus sind mit der ACIA ohne Hacks nur 19200 baud möglich, und selbst hochgezüchtet sind mehr als 38400 baud nicht drin. Dazu kommt, dass es keinen Puffer gibt und für jedes empfangene Byte ein Interrupt ausgelöst werden müßte.