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.

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. Somit haben wir 3 TTL-ICs durch einen GAL ersetzt und wieder Platz auf dem Steckbrett geschaffen. Und das Beste: Änderungen an der Dekodierungslogik laufen ab sofort minimalinvasiv.

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. A15 würde den Chip mit den unteren 62256 selektieren, um alles oberhalb würde sich ein kleines TTL-Grab kümmern, denn irgendwo muss ja noch ein Bereich für verschiedene IO-Bausteine hin.

… 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. Für’s erste sollte es ein TMS9929 sein, weil der tatächlich noch zu beschaffen ist und dazu auch noch im DIP-Gehäuse daherkommt. Der -29 ist für den europäischen Markt gebaut worden, um diese an PAL-Fernsehgeräte anschließen zu können. Hier eine kleiner Auszug  der technischen Fähigkeiten, die im Jahre 1980 wahrscheinlich gigantisch wirkten.

Damit sich ein “Steckschwein” nicht so einsam fühlt, haben wir das ganze nochmal geklont. Jetzt hat jeder sein eigenes Steckschwein und kann daran rumschrauben oder besser gesagt rumstecken.

Da wir das Tooling “leichtgewichtig” halten wollen, gabs auch gleich ein kleines Problem zu lösen. Die Dekoder-Logik für den GAL wurde bisher in VHDL definiert und mit dem Hersteller-Produkt http://www.latticesemi.com/ispleverclassic ein entsprechendes JEDEC-File erzeugt. Das war uns dann doch viel zu unhandlich und wir haben uns nach Alternativen umgetan. Die Wahl fiel auf https://github.com/daveho/GALasm, ein kleines aber feines Tool mit dem aus einigen booleschen Ausdrücken für die Dekoder-Logik genauso gut ein JEDEC-File erzeugt werden kann.

Nachdem uns nach einiger Zeit dann doch langweilig wurde, den Prozessor beim NOPs ausführen zu beobachten musste der nächste Kick her: Es soll Code ausführen! Also ein wenig Code geschrieben (dieser ist leider nicht überliefert, enthielt lediglich einige NOPs und JMPs, gerade genug also, um uns in blanke Verzückung zu versetzen), auf ein 27128 EPROM gebrannt und an Adress- und Datenbus angeschlossen. /OE und /CS des EPROM wurden einfach auf Masse gelegt. Adressleitungen A0-A12 des EPROM wurden mit dem Adressbus des Prozessors verbunden, die verbliebenen Adressleitungen des Prozessors blieben frei. Also haben wir nun 8k ROM, die sich innerhalb der 64k Adressraum des 65c02 8 mal wiederholen.