Bekanntlich dekodiert unser GAL die oberen 8bit des Adressbus, um den Bereich $8000-$ffff unter RAM, IO-Bereich und ROM einzuteilen. Die unteren 32k werden am Decoder vorbei direkt von der Adressleitung A15 selektiert. Das Memory-Mapping, das sich daraus ergibt, ist - zur Wiederholung - wie folgt:
Bereich Was $0000 - $7fff RAM $8000 - $cfff RAM $d000 - $dfff IO-Bereich $e000 - $ffff ROM Die letzte Änderung am Decoder war, das ROM bei Bedarf ausblendbar zu machen.
Damit Dommas nicht langweilig wird und auch in den Gfx-Genuss kommt muss natürlich eine Lösung her. Er hat momentan keine Möglichkeit das Steckschwein mit Grafik an seinem geliebten Commodore 1084-S Monitor zu betreiben. Was ist also zu tun?
Wir haben ja im Post … beschrieben wie wir aus dem YRyBy des TMS9929 ein brauchbares RGB+Sync (BAS) Signal erzeugen können. Das funktioniert auch wunderbar an allen derzeit gängigen CRT-Fernsehern und auch an allen neuzeitlichen Flat-Screens wenn diese noch einen SCART-Anschluss oder ebend RGB+Sync (PAL-RGB) Eingänge besitzen.
Es gibt verschiedene Ansätze, einem 6502-basierten System SPI beizubiegen. Daryl Rictor hat z.B. einen CPLD-basierten SPI-Controller mit passendem Businterface entwickelt. Meist jedoch wird eine 6522 VIA hergenommen und SPI per Bit Banging implementiert. Auch hier gibt es verschiedenen Ansätze, Andre Fachat hat es mit ein wenig externer Logik sogar geschafft, das Schieberegister der VIA im für SD-Karten nötigen SPI Mode 0 zu betreiben. Normalerweise geht das ja nicht, das das Schieberegister der VIA die Daten nicht vor dem ersten Taktimpuls anlegen kann.
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.
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.
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: