Sollte jetzt nicht so klingen, als wenn ich drängel... ich denke nur nebenbei mit.
Ich habe mal die Beine des VDG etwas sortiert:
- Stromversorgung
- CLK (In) - Takt 3,579545 MHz
- Videosignal (alle Out)
- Ausgänge zu einem externen Character ROM
- /RP
- /HS
- /FS - FieldSync - solange low, kann MCU das externe SRAM nutzen
- 8bit Datenbus (In)
- 13bit Adressbus (Out)
- /MS - Eingang, low zwingt den Adressbus auf tristate
- Displaymodi (In)
- /A,G -alphanumerisch, graphisch
- /A,S - alphanumerisch, semigraphisch
- GM2..0 - Graphikmodus 0..7
- /INT,EXT - interner, externer Character ROM
- Farben (In)
- INV - invertiert die Farbdarstellung im alphanumerischen Mode
- CSS - ColorSetSelect, wählt zwischen 2 Farben (alphanum. Modi) bzw 2 Farbsets (graph. Modi)
Normalerweise legt der VDG also über den Adressbus fest, welches Byte der SRAM auf den Datenbus ausgeben soll, dieses landet dann im VDG, und wird als Codenummer für den internen Character-ROM oder als direkte Graphikinfo interpretiert. Aber bei Verwendung eines externen Character-ROM wird der Datenbus zwischen SRAM und VDG umgeleitet, es wird das externe Character-ROM dazwischen geschaltet. Das erfordert also 2 zusätzliche externe 8bit-"Schalter". (Figure 23 rechts unten).
Der interne Character-ROM verwendet nur 6bit-Daten, der semigraphische Modus 7bit. Folglich kann Bit7 des SRAM-Data-Out auch auf den /A,S-Eingang gelegt werden (/A,G wählt zwischen echter Grafik oder (alpha, semigraphik), wenn alpha oder semigraphik, entscheidet Bit7.
Bit6 kann zusätzlich auf INV gelegt werden - dieser Eingang wird nur in den alphanum. Modi ausgewertet, und invertiert ggf die Farben (Figure 17a).
So, nun zu den potentiellen Stolpersteinen:
Der externe SRAM soll natürlich den Inhalt der adressierten (Adressbus) Speicherzelle ausgeben können (Datenbus) - andererseits soll er über den Datenbus beschrieben werden können. Er verfügt also über einen Write-Strobe-Eingang. Da er beim beschreiben selbst nichts auf den Datenbus legen darf außerdem über einen Output-Enable-Eingang. Diese beiden Signale sollten Durch den AVR bedient werden, wenn der VDG (immer lesend) darauf zugreift (also immer ausserhalb des /FS-Fensters), muß der Output (durch den AVR) enabled bleiben (komme später darauf zurück).
Da innerhalb des Fensters der AVR, ausserhalb des Fensters der VDG den Adressbus bedienen, müssen beide ihre Adress-Pins tristate schalten können. Beim VDG erzwingt man das über /MS. Der AVR kann seine Pins natürlich auch tristate schalten, bei Verwendung des Interfaces für den externen SRAM lauert aber auch hier ein Stolperstein.
Wenn man im AVR das Interface für den externen SRAM enabled, werden die entsprechenden Pins mit dem internen Daten- oder Adressbus verbunden, das Interface übernimmt die Kontrolle über die Pins. Also /RD, /WR, ALE und die Datenbus-Pins (die außerdem mit dem unteren Byte des Adressbusses gemultiplext sind), und die verwendeten Pins des oberen Adressbus-Bytes.
Stolperstein 1: Durch das Multiplexing (Adressbus7..0, Datenbus7..0) wird ein externer 8fach-Latch benötigt. dieser puffert das zuerst angelegte Adress-Byte auf den Adress-Bus, danach wird (mit ALE) auf der latch "getrennt", und im AVR auf den internen Datenbus umgeschaltet. Das macht das Interface automatisch, wo ist der Stolperstein? Durch zeitweise deaktivierung des Interfaces (SRE) kannst Du zwar die AVR-Beine tristate schalten, aber der 8fach-Latch hängt weiterhin am unteren Byte des Datenbusses, legt da irgendwas drauf. Du benötigst also einen Octal Latch mit (möglichem) tristate-Output. Sowas wie zB den 74AHC(T)573.
Stolperstein 2: Im AVR sind die Rechenregister, die Standard-I/O-Register und die Extended-I/O-Register vor den internen SRAM "eingeblendet", danach der interne SRAM. Selbst bei Aktivierung des externen Interfaces adressieren Speicherzugriffe (LD, LDS, LDD, ST, STS, STD, PUSH, POP) die Interna. Die ersten 0x0500 können also im externen SRAM so nicht adressiert werden. Der VDG legt aber mit seinem 13bit-Adressbus immer untere 13-Bit fest. Mein Vorschlag war wie gesagt, mit den oberen 3 Bits 8 8K-Bereiche zu "teilen", den ersten quasi wegzulassen und den AVR auch ausserhalb des Fensters auf einen der oberen 7-Frames festzulegen. Die kann der AVR problemlos vollständig adressieren, der VDG "weiß nichts" von den unterschiedlichen Frames, bekommt also einen der oberen 7 vorgesetzt, und darf darin jezt die unteren 13 Adressbits bedienen.
Inwiefern Zugriffe mit IN und OUT (auf den standard I/O), direkte Bitzugriffe (auf die ersten 0x1F standard I/Os) und direkte Bit-Zugriffe auf die Rechenregister (SBRC,SBRS) die externen Busse beeinflussen, ist mir auch nicht klar...
Stolperstein 3: Ist das externe Interface im AVR aktiviert, dienen die entsprechenden Beine dem Interface bzw unterliegen dessen Kontrolle. Zu Zugriffen auf den internen Speicher (inklusive (extended)I/O) findet sich der Hinweis, daß dann die /RD- und /WR-Strobes inactive sind. Das bedeutet mMn(!!) aber, daß dann trotzdem die Pins mit den Daten- und Adressleitungen sowie ALE zappeln - es wird eben nur nicht extern gelatcht. Das darf aber ausserhalb des FSync-Fensters nicht geschehen. Deswegen sollte generell ausserhalb des Fensters generell das externe Speicherinterface abgeschaltet werden. Dadurch werden die PORT- und DDR-Register der verwendeten Beine sofort wieder wirksam (/OE zum externen SRAM könnte da also automatisch gesetzt werden), der /OE des Octal-Latches (Adressbus-Datenbus) muß dann dessen Ausgänge auch auf tristate zwingen. Alle Pins, die direkt an einem der Busse hängen sollen dann automatisch tristate gehen. Achtung! auch Subroutinen-aufrufe und Interrupts verwenden für ihre Rücksprungadressen Speicherzugriffe (Stack)!
Ich bin mir nicht sicher, ob man auf das Schliessen des Fensters (steigende /FS-Flanke) hinreichend schnell reagieren kann, möglicherweise sollte man besser einen Timer im Hintergrund nutzen.
