Rom

The 28C256 EEPROM, which holds the BIOS, has been our go-to choice since the early breadboard days. Before that, we relied on EPROMs, which required UV erasure before every upgrade—a time-consuming and inconvenient process. Switching to an EEPROM significantly improved our workflow, reducing turnaround time.

However, the 28C256 has a couple of drawbacks:

• It cannot be written in-circuit since it requires a 12V programming voltage, which the Steckschwein does not provide.
• It is slow, with an access time of 150ns, forcing us to introduce wait states to slow down the CPU when accessing the BIOS.

Because of these limitations, using ROM routines isn’t ideal from a performance standpoint. As a result, the BIOS’s sole function is to load the steckOS bootloader from an SD card into RAM and start it.

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:

Die letzte Änderung am Decoder war, das ROM bei Bedarf ausblendbar zu machen. Dieser Mechanismus hat sich beim Test von BIOS-Updates als pures Gold erwiesen, da man ums neu Brennen des EEPROM herumkommt. Das spart Zeit und schont Material.

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:

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:

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: