Um dem Ziel eines “richtigen” Computers näher zu kommen, brauchen wir nicht nur einen Videochip, wir brauchen auch Eingabegeräte und Massenspeicher.

Zwar soll unser Rechner so retro sein, dass es ihn damals, zur Hochzeit der 8bit-Heimcomputer, durchaus hätte geben können, realistischerweise wollen wir ihn jedoch mit durchaus modernen Schnittstellen ausstatten. Die 8bit-Rechner aus “unserer Zeit” haben IO-Chips wie den 6526 oder 6522 benutzt, um Tastatur (Matrix), Joysticks und Massenspeicher anzusteuern. Das haben wir auch vor. Nur etwas anders. Wir verwenden eine 65c22 VIA, und machen sie zu einem SPI “Master”. Damit wollen wir einen wesentlichen Teil der Peripherie anbinden.

Im Rahmen unserer Reihe “Kleine Verbesserungen an der Architektur” ist heute der Adressdekoder dran. Dieser entscheidet bekanntlich anhand der am Adressbus anliegenden Adresse (oder genauergesagt deren höheren 8bit), welcher Baustein an der entsprechenden Adresse eingeblendet werden soll. Durch den Umstand, dass die oberen 8k dem ROM gehören, lassen sich die darunterliegenden 8k RAM nicht ohne weiteres nutzen. Die für die Selektierung des ROMs und der oberen 32k RAM sehen folgendermaßen aus:

Wir sind jetzt also fast in der Lage, das RAM unter dem ROM zu nutzen. Hineinschreiben geht, lesen noch nicht. Da ist das ROM noch im Weg. Wir müssen also einen Weg finden, die GAL-Logik von außen zu beeinflussen. Unser GAL hat noch genügend Eingänge, sodass wir einen Pin zum ROM-Ein-/Ausschalter machen wollen. Lesezugriffe nach $e000-$ffff sollen also nur noch dann im ROM landen, wenn es “eingeschaltet” ist. Sonst wollen wir ins RAM. Die wiederum erweiterte Logik im GAL sieht jetzt so aus:

So langsam geht es weiter mit der Steckschweinentwicklung.

Die Timingprobleme mit dem VDP bedürfen einer eingehenden Prüfung und Messung, um genau zu verstehen, wo was nicht passt. Unsere Ideen mit Puffern und/oder versetzten Taktsignalen, um den VDP früher “kommen” zu lassen stellen wir zurück, bis wir gesicherte Erkenntnisse haben. Ein Herumdoktern aufgrund von Vermutungen halten wir nicht für zielführend. Vorher ist es auch nicht sinnvoll, irgendwelche Platinen zu löten.

Stattdessen stecken wir ein wenig Hirnschmalz ins aktuelle Design. Die Anbindung des UART fällt negativ auf. Hier wurde der Ansatz von Andre Fachat quasi 1:1 kopiert, sodass der GAL die Signale /RD und /WR für den UART abhängig von PHI2 und der angelegten Adresse erzeugt, während PHI2 ausserdem an CS1 des UART anliegt. Das funktioniert, fügt sich aber nicht ganz in unser Design ein.

Nach dem VCFe ist erstmal nicht viel aktive Entwicklung passiert. Vielmehr haben wir die Erkenntnis, dass wir ein grundsätzliches Timing-Problem haben (danke nochmal an Udo Möller) ein klein wenig sacken lassen. Im Grunde genommen ist es so, wie es sich aus dem vorletzten Post schon herauslesen läßt. Der WDC 65c02 hat eine Data Hold Time von 10ns, während der TMS9929 30ns braucht, sein Zeug vom Bus zu holen. Die verwendeten 16550er UARTs auch. Eine klassische Hold Time Violation also. Ein bisschen muss man sich da schon wundern, dass das Zeug überhaupt funktioniert und so erklärt sich auch der ein oder andere staunende Blick auf dem VCFe. Simon schlägt vor, das Projekt “Bumblebee” zu nennen, da Hummeln bekanntlich rein physikalisch gar nicht fliegen können, es aber dennoch tun, weil ihnen Physik total egal ist.

Nachdem das Timing vom Steckschwein grundsätzlich passt, sind auf einmal auch sämtliche Voodoo-Fehler verschwunden.

Jetzt lässt sich der VDP auch besser ansprechen, allerdings gibt es schon noch ein paar Probleme zu lösen, bspw. ist das DRAM sehr instabil irgendwie flackert ständig der Screen oder die Zeichen “Nullen” sich aus. Wir untersuchen das Steckbrett und die Spannungsversorgung. Wir beschließen, die Steckbrettkabel durch kurze blanke Drahtbrücken zu ersetzen und platzieren direkt am Vcc der einzelnen DRAMs die Abblock-Kondensatoren mit 100nF. Genauso die Spannungsversorgung des VDPs, hier auch nochmal kurze Drahtbrücken verwenden und einen Abblock-Kondensator direkt an Vcc vorsehen.