Posts

Eine batteriegepufferte Echtzeituhr gehört ja heutzutage schon zur Serienausstattung, auch bei Retro-Rechnern. Das Steckschwein soll also auch eine bekommen. Chris Ward’s Design, welches uns zu Anfang als Grundlage gedient hat (mittlerweile ist davon nicht mehr viel übrig geblieben) verwendet eine DS1687, deren Intel-mäßiges Businterface über ein wenig Glue-Logik direkt an den Datenbus des 6502 angelegt ist und damit auch Platz im IO-Bereich benötigt.

Wir wollen das mit dem Steckschwein anders angehen. Unsere Echtzeituhr soll via SPI angebunden werden. Und auch ansonsten sind unsere Anforderungen eher bescheiden: - Einen Interrupt-Pin soll sie haben - Ein paar Bytes batteriegepuffertes RAM wären toll. - DIL-Gehäuse, sonst passts nicht aufs Steckbrett :-)

Von unserem Plan, einen AVR-µC als PS/2-Tastaturcontroller als SPI-Slave einzusetzen, haben wir ja schon in der Vergangenheit  berichtet. Damals hieß es: “Bequemerweise gibt es zahlreiche fertige Lösungen, die z.B. am anderen Ende rs232 sprechen. Wir wollen aber nur wegen einer Tastatur keinen zweiten UART verbauen. Fehlt also nur eine kleine Anpassung auf SPI.”

Hiermit sollte das Schicksal seinen Lauf nehmen. Der kühne Griff in die Bastelkiste sollte einen ATtiny2313 zu Tage fördern, welcher der zugedachten Aufgabe durchaus gewachsen zu sein schien.

Nachdem wir also mit dem Adressdecoder durchaus zufrieden sind, müssen wir uns noch einen Weg überlegen, die /ROMOFF-Leitung per Software steuerbar zu machen. Wenn es schon beim BIOS-Update Test äußerst nützlich ist einfach nur eine Brücke umzustecken und damit das ROM zu deaktivieren, wie praktisch muss es erst sein, dies einfach durch Beschreiben einer Speicherstelle zu tun.

Was wir also brauchen, ist ein IO-Pin, der die /ROMOFF-Leitung steuert. Zusätzlich muss dieser Pin beim Einschalten des Systems einen definierten Zustand haben, damit sichergestellt ist, daß zu diesem Zeitpunkt das ROM eingeblendet ist. Passende Pins finden wir an der VIA und am UART. Die Portpins der VIA beispielsweise sind initial als Eingänge geschaltet und per internem Pullup high. Auch die OUT1 und OUT2-Pins des UART sind initial high. Gegen den UART-Ansatz spricht, dass sich diese Pins  nur über ein Write-Only-Register setzen lassen und es keine Möglichkeit gibt, den Zustand dieser Pins über irgendein UART-Register abzufragen.

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.

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. Am 1084-S geht aber nur RGB+H/V, d.h. das horizontale und vertikale Sync-Signal muss getrennt vorliegen. Wir haben aber nur ein Composite-Sync mit dem RGB+S vorliegen. Wir brauchen einen Sync-Separator. Genau das macht der LM1881 und kompatible.

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.