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.

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.

Sinn der Sache ist ja nicht, etwas 1:1 nachzubauen, sondern ein möglichst eigenes Design. Nachdem wir mit Chris’ Design - bzw. dessen, was wir davon übernommen haben (Adressdekodierung, ACIA, VIA) - genug herumgespielt hatten, galt es, “unser” Ding draus zu machen. Der erste Schritt war ein Sprung ins kalte Wasser in die uns bislang noch unbekannte Welt der Programmierbaren Logik. Dazu haben wir zunächst die Adressdekodierung bestehend aus 74ls138/74ls154 sowie etwas glue Logic in VHDL implementiert und auf ein GAL22V10D gebrannt.

Nachdem die vorangegangenen Spielereien sehr ermutigend verliefen, war der nächste Schritt klar. Wenn wir so weit kommen, kommen wir auch noch weiter. Das Ziel ist jetzt definitiv ein funktionierender 8bit-Rechner mit 64k RAM. Da der 6502 keinen DRAM-Refresh liefert und wir uns den Aufwand eines diskreten Refresh-Generators ersparen wollen, soll es ein SRAM-basiertes Design werden. Bei ein wenig Recherche beim Elektronik-Versenders unseres Vertrauens stellen wir fest, dass 2x32k*8 in Form von zwei 2 62256 eine komfortable Lösung sein würden.

… und zwar auf einem Bildschirm! Aber wie stellt man sowas an?! Nun, wir schauen uns um, was Ende der 70-er bzw. Anfang der 80-er Jahre Stand der Technik war und was sich mit überschaubarem Aufwand an eine 6502 CPU “anschließen” lässt. Die Auswahl ist leider überschaubar, denn es sollte irgendwas in DIP maximal noch SDIP sein und dazu noch irgendwie lieferbar - “new old stock”. Wir fanden die TMS9918/28/29-Serie und einige Nachfolger wie den TMS9938/58.