Video Display Controller MC6847

[DJLinux]

Habe heute für mein "Retro-Schätzchen" einen AL422B aus China bekommen.

Dieser Baustein ist auch für viele andere MC's interresant.

An den 8-bit Eingängen kann bis zu 50 MHz seine Bytes in einen 384K FiFo RAM rein takten und der Schreibaddress-Pointer bewegt sich um N geschriebene Bytes weiter.

An den 8-bit Ausgängen kann man nun den FiFo wesentlich langsamer raus takten und der Leseaddress-Pointer bewegt sich um N gelesene Bytes weiter.

Was diesen recht großen FiFo (z.B. 720x480 Pixel) von manch Anderen unterscheidet ist die Tatsache das sich Schreib- und Lese- Pointer getrent von einander "Resetten" läst.

Einschränkung 1:
Der Lese-Pointer muss immer mindestens 128 Bytes Abstand zum Schreib-Pointer haben. (Egal ob vor oder hinter dem Schreib-Pointer)
(Denke das eine RAM Zeile aus 128 Byte besteht und man kann eine Zeile entweder lesen oder schreiben muss ich aber noch im Datenblatt nachlesen.)

Einschränkung 2:
Schreib- und Lese-Takt darf nicht unter 1 MHz. fallen sonst droht Datenverlust. (kann man aber auch zum einfachen löschen benutzen)
(Denke das liegt daran das der Takt auch zum RAM-Refresch benutzt wird muss ich aber noch im Datenblatt nachlesen.)

Natürlich kann man den FiFo auch langsam füllen und mit bis zu 50Mhz in einem Rutsch wieder lesen.

Mögliche Anwendungen:

Mit 2 Chips 16-Kanal 50MHz Logic Analyser.
50 Mhz Rechteck Generator oder mit DA Wandler am den Ausgängen auch Sinus, Dreieck ...
Schnelle USB-Streams mit viel zu langsammeren MC's.
Schnelles Video Capturing und lansameres Lesen.
Schnelle MC <-> PC Kommunikation
Lan <-> MC's


Jetzt fehlen nur noch die Quarzoszillatoren aus England und einige freie Tage ab nächster Woche und es kann los gehen.

Taktvolle Grüße

DJ

 

[unilein]

Habe heute für mein "Retro-Schätzchen" einen AL422B aus China bekommenDJ

Was hast Du denn mit dem Teil vor? Willst Du damit den MC6847 füttern?

 

[DJLinux]

Was hast Du denn mit dem Teil vor? Willst Du damit den MC6847 füttern?

Nö dient als Bufferspeicher am Expansionsport.
Jetzt habe ich alle bestellten Teile bekommen und auch eigentlich Zeit für erste MC6847 Experimente
aber wie das Leben halt mal so spielt habe ich mir einen Bandscheibenvorfall beim Laubpfegen "geleistet".
Sitzen, stehen und liegen alles Sch.... im Moment.

Melde mich aber wenn ich wieder fitt bin.

Grüße DJ

 

[unilein]

Hallo zusammen,

hier soll es nun endlich mal weiter gehen. Ich war zwischenzeitlich nicht untätig, hatte aber berufs- und krankheitsbedingt ein paar Zwangspausen. Diese kombiniert mit zeitweiser Unlust haben dazu geführt, dass hier nix weiter ging.

Inzwischen habe ich aber am Projekt gearbeitet und dabei einige Hürden festgestellt, die ich bislang nur teilweise umschiffen konnte. Bei meinen Überlegungen zum Schaltungsdesign sind mir folgende Dinge aufgefallen, die unbedingt gegeben sein müssen, da sonst nix geht:

Der aktuelle Schaltplan ist beigefügt (und keineswegs vollständig!)

* Der VDC muss STÄNDIG auf den Speicher zugreifen können, um Videodaten auszulesen. Deshalb ist es erforderlich, dass der Speicherbaustein, der die Videodaten enthält, auch STÄNDIG verfügbar ist. Somit müssen /CS und /OE dieses Chips STÄNDIG auf low
* Der VDC legt STÄNDIG Adressen auf den Bus um den Videospeicher auszulesen. Wenn der andere Speicherchip aktiv ist, bekommt dieser die Adressen vom VDC auch mit, was für den Atmega natürlich störend ist
* Umgekehrt legt der Atmega Adressen auf den Bus, die der zweite Speicherchip mitbekommt, da dieser ja STÄNDIG aktiv ist. Das kann so nicht gut geht.
* Dasselbe passiert mit dem Datenbus, wenn der Atmega dort Daten drauf legt. Diese bekommt der VDC UND der zweite Speicherchip mit. (Hier habe ich eine Lösung mit einem SN74HC245 Octal Bus Tranceiver, die das verhindern soll)

wie habe ich versucht, die Probleme zu lösen?

Das letze Problem mit dem Datenbus habe ich mit dem 74HC245 gelöst. Der Baustein ist wie eine umschaltbare Einbahnstraße und das funktioniert auch.

Das Chipselect-Problem habe ich nur teilweise gelöst. Mein Plan ist, das Chipselect-Signal manuell mit dem Atmega zu steuern. Wenn ich auf den ersten (linken) Speicherbaustein zugreifen will, bekommt dieser manuell ein /CS verpasst. Ich würde dazu Pin PC7 des Atmega verwenden, da ich nur 32 KB adressieren muss. Wie ich derweil den zeiten Baustein abkoppeln kann, erschließt sich mir nicht. Klar ist mir aber, dass ich so eine Art Bankswitching hätte und beide Speicherbausteine denselben Adressbereich belegen würden (Was aus meiner Sicht nicht schlimm wäre, denn ich würde den zweiten Baustein aus der Sicht des Atmega nur in der Austastlücke beschreiben wollen, also wenn /FS auf low geht)

Nun noch das Adressenproblem. Ein Ansatz wäre, den Adressbus des Video-Teils auch mit 74HC245 abzukoppeln. Ich würde dann den Adressbus des zweiten Speicherchips nur dann mit dem Atmega verbinden, wenn PC7 auf High ist. Allerdings hätte ich dann das bislang gedanklich ungelöste Problem, dass ich vom Atmega aus nur mit erheblichem Aufwand den zweiten Videospeicher auslesen kann.

Ich hoffe, ich habe die Thematik einigermaßen verständlich beschrieben und bin guter Dinge, dass Ihr mir gedanklich ein wenig auf die Sprünge helfen könnt.

Beste Grüße,
Uni

 

[LotadaC]

...
* Der VDC muss STÄNDIG auf den Speicher zugreifen können, um Videodaten auszulesen. Deshalb ist es erforderlich, dass der Speicherbaustein, der die Videodaten enthält, auch STÄNDIG verfügbar ist. Somit müssen /CS und /OE dieses Chips STÄNDIG auf low
* Der VDC legt STÄNDIG Adressen auf den Bus um den Videospeicher auszulesen. Wenn der andere Speicherchip aktiv ist, bekommt dieser die Adressen vom VDC auch mit, was für den Atmega natürlich störend ist
...

Erklär mal genauer (ich steck ja da auch nicht mehr so drin)...

Aber es war doch irgendwie so, daß es da am Ende eines jeden Einzelbildes 'n Fenster gab, wo der VDG eben nicht den Speicher liest (konkret gesagt nicht das was auf dem Datenbus bei ihm ankommt darstellt).
Dieses Fenster hat er mit irgend'ner Leitung (/FS ??) signalisiert, der Controller kann darauf reagieren.
Außerdem gab es noch einen Eingang (des VDG), mit dem man dessen Adressbus-Ausgänge auf Tristate zwingen konnte (um in dieser Lücke dann die Bilddaten durch den AVR in den Speicher zu schieben. (/MS ?? )

Warum muß jetzt der VDG plötzlich ständig(!) den Adressbus festlegen und Daten auf dem Datenbus empfangen?

 

[unilein]

Hallo Lotadac,

ja, Du hast Recht. In der Austastlücke, angezeigt durch /FS, kann man /MS auf low legen und den VDC auf tristate zwingen. Dann wäre er "weg vom Speicher".
Da hätte ich dann 2,4 ms Zeit um den Videospeicher zu manipulieren.

Aber: Wenn der VDC auf den Videospeicher zugreift, muss /CS (zusammen mit /OE) auf low, da er sonst nicht lesen kann. In dieser Zeit darf dann der Atmega nicht auf den anderen Speicherbaustein zugreifen, da dessen /CS dann auf high müsste.

Wenn der Atmega sich also mit dem Speicher beschäftigen wollte (egal mit welchem), dann hätte er grundsätzlich nur 2,4 ms Zeit dafür, da in der restlichen Zeit der VDC Herr über den Bus wäre (Oder denke ich da falsch??). Da ich natürlich gerne möchte, dass der Atmega STÄNDIG auf den ersten Speicher und der VDC STÄNDIG auf den zweiten Speicher zugreifen kann, brauche ich eine andere Lösung.

Und da dachte ich an:

* /CS und /OE des Videospeichers immer auf low und somit Speicher für den VDC immer verfügbar
* Trennung des Atmega und des VDC durch SN74HC245, sowohl Daten- als auch Adressbus
* Nur in der Austastlücke darf der Atmega auf den Videospeicher (da würde ich die SN74HC245 für 2,4 ms aufmachen, den VDC auf tristate zwingen und Schreiben oder Lesen)
* Speicherbaustein 1 ständig für den Atmega verfügbar (32KB).

Das Bankswitching würde ich manuell machen. Und zwar wenn /FS auf low geht und der Atmega über INT0 in der Interupt Service Routine den Speicherbaustein umschaltet und am Ende wieder zurück schaltet (Eben durch Manipulation der SN74HC245). Nutzen könnte ich PC7 (dieser ist, da nur 32 KB adressiert werden müssen, frei) und, falls notwendig, noch einen weiteren Pin um die Steuerung zu realisieren.

Die ursprüngliche Idee, wie damals mal hier im Thread besprochen, kann meiner Meinung nach nicht funktionieren, da der Atmega die volle Kontrolle über die Speicherbausteine hätte, solange Signale auf den Ports A und C liegen, sowie an RD und WR. Schalte ich im Atmega den externen Speicher einfach ab, habe ich dort beliebige Signale liegen, die dem VDC und dem 2. Speicherbaustein präsentiert werden, sobald dessen /CS und /WR (oder auch /OE) aktiv sind. Die Daten auf dem Bus würden dann einfach in den Speicher übernommen. Der VDC würde derweil munter die Adressen weiter zählen und Schrott anzeigen.

Wie gesagt.... Das sind meine Überlegungen (und teilweise die Erfahrung aus zwischenzeitlich aufgebauten Tests). Aktuell habe ich die Version vom Schaltplan auf dem Breadboard. Diese liefert ein Stabiles und störungsfreies Bild über den VDC. Aber da der Adressbus zwischen Atmega und VDC noch ohne Schranke ist, führen Speichermanipulationen zum Chaos. In meinen Testprogrämmchen nehme ich momentan aber auch noch keine Rücksicht auf Austastlücke und Ähnliches. Ich wäre schon froh, wenn meine Daten auf der richtigen Speicheradresse im richtigen Baustein landen würden.

Beste Grüße
Uni

 

[LotadaC]

Ok, Du willst also einen zweiten Speicherbaustein am AVR verwenden können, der unabhängig vom ersten (Videospeicher) ist, und auf den unabhängig vom "Fensterstatus" zugegriffen werden kann.
Wegen der "Fensterstatusunabhängigkeit" ist dann zwingend notig, daß sowohl Daten- als auch Adressbus des AVR komplett von den entsprechenden Bussen VDG--Videospeicher abgekoppelt werden können müssen. Tristate. Soll der AVR außerdem (im Fenster) aus dem Videospeicher lesen können, muß der Datenbus-Switch bidirektional sein.

Wenn das XMEM-Interface die höheren Bits für den 2ten Speicher verwenden können soll, können diese nicht für ein eventuelles Bank-Switching beim Videospeicher verwendet werden, auch klar.
Außerdem können /OE und /CS des Videospeichers nicht mehr aus den XMEM-Beinen mitbedient werden - ob /OE allerdings fest auf Gnd darf wenn der AVR Daten in den Videospeicher schreiben soll, ist mir grad nicht ganz klar...

Hmm... WR (/WE) und RD (/OE) könntest Du doch für den Videospeicher mit über Adress-Trenn-Switch legen, oder? Videoseitig dann mit entsprechenden Pull-Widerständen für den VDG-Betrieb.

Vielleicht kannst Du den Plan übersichtlicher zeichnen, indem Du dort entsprechende Leitungen zu Bussen bündelst (und klingende Busnamen vergibst/dazuschreibst)?

U7 ist ein serielles Schieberegister (mit latch?), mit dem Du den Modus usw des VDG festlegst? /A,S und INV würde ich stattdessen auf den Datenbus legen (wie auch in dem einen Datenblatt), hatte ich in #14 bereits angedeutet

 

[unilein]

Hallo Lotadac,

alles was Du sagst, ist richtig. Das Schieberegister U7 soll in der aktuellen Version die Modi steuern. Aber das ist aktuell nur Makulatur. Erst wenn ich das Timing und das Speicherthema im Griff habe, beschäftige ich mich mit den anderen Möglichkeiten des VDC. Deine Idee, das über den Datenbus zu lösen ist natürlich keine schlechte. Ich werde mich auf jeden Fall mit dem Vorschlag beschäftigen.

Diesem Beitrag habe ich eine "Kompaktversion" des Schaltplans beigefügt. Zwei Orange-farbige Rahmen zeigen die "Trennung" der Bereich auf. Wie im Schaltplan vermerkt sind grüne Leitungen Adressbus, blaue Leitungen Datenbus, Lila Leitungen Steuersignale.

In der aktuelle Version ist die Idee, den Adressbus mit ICs vom Typ SN74HC245 zu trennen noch NICHT umgesetzt. Dazu fehlte mir die Zeit. Wenn aber nix dazwischen kommt, werde ich das heute Abend aber noch umsetzen und evtl auch auf dem Steckbrett zusammen stecken (sofern ich noch genügend Drahtbrücken habe )

Beste Grüße
Uni

 

[LotadaC]

Das war natürlich nicht meine Idee, das stand so im Datenblatt des VDG (Figure 17a, Seite 15)...

Du willst jetzt über U4 zwischen den beiden Orangenen Bereichen einen weiteren Bus-Trenn-IC einbauen, korrekt?
Über den kann dann auch die WE-Leitung getrennt werden.

Unklar ist mir aber im Moment noch das Schreib-Timing - der AVR würde ja erst die Adressen auf den Bus legen (und mit seinem Latch halten), dann mit ALE auf Daten umschalten, und die Daten auf den Bus (und U4) legen, und dann den WE aktivieren, oder?

Wenn der AVR aus dem VRAM lesen können soll, muß U4 in beide Richtungen wirken können, dann müßte man ausschließen, daß der VRAM Daten auf den Datenbus und über U4 auch an den AVR legt, während dieser auf seiner Seite gerade die Daten die erschreiben will vorbereitet (also die Datenleitungen bereits gesetzt sind, der WE-Strobe aber noch nicht erfolgte...)

Und Du hast immer noch das Problem, daß Du eigentlich in beiden Speichern die untersten Adressen nicht adressieren kannst... hmm... allerdings kann das XMEM-Interface ja selbst 16bit also 64k adressieren. Das MSB adressiert einfach U5, dann liegen dessen 32k für den AVR im adressierbaren Bereich zwischen 32k und 64k. Den Zugriff auf den 8k-VRAM mußt Du ja manuell mit dem Fenster kontrollieren, da legst Du im AVR einfach zB den Adressbereich zwischen 24k und 32k fest. Die oberen 3 Leitungen sind nicht mit dem VRAM verdrahtet, die unteren 13 adressieren dann die 8k des VRAM.

Auf Die Adressen ab 32k kannst Du also immer zugreifen, für den VRAM mußt Du auf das Fenster warten, deinerseits die getrennten Busse durchschalten und dann eben zwischen 24k und 32k adressieren.

Allerdings müßte man sich dazu die Datenblätter der beteiligten ICs nochmal genauer ansehen, um konkreter auf die CS- und OEs einzugehen...

 

[LotadaC]

Hab das mal etwas konkretisiert, und auf'n Zeitungsrand gekritzelt. Wären dann insgesamt 3 Oktal-Switche (2 für den Adressbus und die Read/Write-Strobes, einer für den Datenbus) nötig. Elegant wäre noch ein NOT-Gatter (ggf mit'nem Transistor selbst gestrickt)...quark

 

[unilein]

Ich habe die neue Idee am Wochenende einfach mal flott auf ein Steckbrett gesteckt und bin gescheitert. Das wird auf dem Steckbrett inzwischen zu unübersichtlich und mir gehen auch die Steckbrücken aus *gg*. Ich könnte ein Bild beifügen, wie so etwas dann auf dem Board aussieht, aber das lasse ich wohl besser; da bekomme ich nämlich sicher Ärger wegen der Funkwellen, die das Teil ausstrahlt


Ich überlege aber gerade, ob ich Teile der Schaltung einfach mal auf Streifenraster-Platinen löte und die dann mit entsprechenden "Schnittstellen" versehe, um sie am Steckbrett weiter nutzen zu können.

Mir dafür extra eine Platine ätzen zu lassen, ist mir zu teuer, da ich ja noch nicht einmal weiß, ob das Design überhaupt funktionieren kann (einige Designs wurden ja inzwischen auch schon wieder verworfen).



PS: Ich habe das Bild jetzt doch eingefügt. Auf dem Bild sind die drei Octal-switche noch NICHT verbaut.

 

[LotadaC]

Wahh.... Geil...

irgendwie sowas in der Art hätte ich erwartet...
(erinnert ein wenig an Dinos Fädeldrahtereien - Thomas hat das dann mal irgendwo dinomässig nachgemacht, glaub ich...)

Ich hatte bei was ähnlichem ja mal über alte ISA-Slots nachgedacht, quasi auf'ner Busplatine. Aber wenn'de mal versucht hast, die Dinger aus'nem MoBo auszulöten...
Besser wäre es, Deine Streifenrasterplatinchen via Hosenträger zu verbinden (wobei diese so kurz wie möglich gehalten sein sollten). War sicher bereits Deine Idee...

Bei den Platinen meinst Du aber die, wo immer nur 3 Löcher verbunden sind, oder?

Viel Erfolg trotzdem...

 

[TommyB]

(erinnert ein wenig an Dinos Fädeldrahtereien - Thomas hat das dann mal irgendwo dinomässig nachgemacht, glaub ich...)

Schuldig im Sinne der Anklage ^^

http://avr-praxis.de/forum/showthread.php?3500-Widerstandsdekade&p=35773&viewfull=1#post35773

Hübsches Kabelbäumchen aus (bis zu) 24 verdrillten Kupferlackdrähten.
Anhang anzeigen 6574

 

[LotadaC]

...Mir dafür extra eine Platine ätzen zu lassen, ist mir zu teuer, da ich ja noch nicht einmal weiß, ob das Design überhaupt funktionieren kann (einige Designs wurden ja inzwischen auch schon wieder verworfen)...

Grundsätzlich könnte ich Dir auch die Platine(n) zum Selbstkostenpreis ätzen. Wenn Du 'n halbwegs gares Layout erstellt hast...

 

[unilein]

Grundsätzlich könnte ich Dir auch die Platine(n) zum Selbstkostenpreis ätzen. Wenn Du 'n halbwegs gares Layout erstellt hast...

Das ist ein tolles Angebot! Ich komme gerne darauf zurück, wenn die Probleme nur noch in der Programmierung und nicht mehr im Schaltungsdesign liegen. Was würdest Du denn dazu von mir benötigen (Sorry, aber ich bin da eher unterbelichtet. Meine Schaltungen habe ich bislang immer auf Streifenrasterplatinen aufgebaut. Diese hatten allerdings nur mäßg viele Bauteile mit wenigen Beinchen . Ich erstelle meine Schaltpläne mit EasyEDA online. Da kann ich auch ein PCB erstellen.)

Gestern Abend und vergangene Nacht habe ich nochmal über ein paar Dinge in der Schaltung nachgedacht. Ich muss mir auf jeden Fall das Timing der Speicherbausteine ansehen. Außerdem habe ich noch eine Idee zum Chipselect im Kopf (die ist noch nicht ganz gar). Aktuell klappt das Schreiben in den Speicher immer noch nicht (oder nicht sauber). Speziell der Zugriff auf den Videospeicher vom Atmega aus funktioniert überhaupt nicht. Da ich aber das ganze Gedöns auf dem Steckbrett habe, fürchte ich, dass ich mich irgendwo "versteckt" habe. Es sind ja immerhin inzwischen ca. 100 Steckbrücken und Kabel.

Wenn ich heute in der Frühstückspause oder der Mittagspause Zeit habe, werde ich den Schaltplan anpassen. Und heute Abend prüfe ich das Ganze wieder auf dem Breadboard.

Grüße,
Uni

 

[LotadaC]

Meine Idee war etwa so:
-vom AVR her hast Du erstmal den 8bit-Datenbus und (hinter dem Adress-Daten-Mux - da sollte ja alles klar sein...) den 15-bit-Adressbus. ALE an den MUX, denn noch /WR und /RD, die mit dem Adressbus mitlaufen. Der Anschluß an den 32k-SRAM sollte soweit klar sein.
Da Du den externen SRAM vom AVR adresstechnisch im Bereich von 32K..64k ansteuern willst (wegen dem internen SRAM), wirst Du wahrscheinlich das XMEM-Interface auf 16bit-Adressierung einstellen - auch wenn Du A15 dann nicht nutzt.

Vom VDG her das /FS an den AVR (Interrupt), und vom AVR zurück das /MS. Letzteres landet außerdem auf den /CS der drei BUs-Trenn-ICs, und ist mittels Pullup sicherheitshalber auf Vcc gezogen.
Ob Du /MS jetzt noch invertiert auf /CS des 32k-SRAM legst, oder diesem 'n eigenen spendierst, ist Deine Sache. ursprünglich dachte ich da sogar an A15 als /MS, aber das wird mMn timingtechnisch nicht passen.

So...
Mit /MS schaltest Du also die drei Trenn-ICs transparent, wenn das /FS-Fenster erkannt wurde (und Du auf den Videoram zugreifen willst) - sonst sind die tristate.

Bei den beiden, die den Adressbus und die /WR, /RD leiten ist die Richtung ja klar, beim Daten-Trenner machst Du das so:
hinter dem Bus-Trenn-IC muß das /RD-Signal ja eh auf Gnd gezogen werden, da es ja auf dem /OE des Videospeichers liegt, und der ja was an den VDG ausgeben soll, wenn der AVR nicht zugreift.
Dieses Signal legst Du auf den DIR-Eingang des Datenbus-Trenn ICs. Dann mußt Du nur noch entscheiden, auf welcher Seite des ICs der AVR, und auf welcher der Videospeicher liegen muß (da kram ich jetzt nicht das DB raus - bei /OE=Gnd sollen die Daten vom Speicher zum AVR, bei /OE=Vcc vom AVR zum Speicher.)

Natürlich nur 'ne Idee - also keine Garantie etc...

---

Zu den Platinen - ich erstelle meine Layouts immer mit Eagle, grundsätzlich ist das aber egal. Ich bräuchte lediglich 'ne gute Belichtingsvorlage. Letztendlich muß das ein korrekter deckender Ausdruck auf Folie sein, da mein Drucker daß i.A. nicht besonders gut schafft, drucke ich das üblicherweise auf Papier, und ziehe das dann durch'n Kopierer auf Folie. Allerdings bekommt man die auch mit'nem Kopierer nie wirklich deckend, wenns drauf ankommt, lasse ich mir hier Folien erstellen. Aufgrund der Mindestmenge dann ggf auch gleich mit Lötstoppmaske.

 

[dino03]

Hallo zusammen,

irgendwie klingt das gewaltig nach Amiga. Fast-RAM und Video-RAM.
Beim Fast-RAM konnte nur die CPU zugreifen.
Beim Video-RAM hatte der Copper und die Videohardware die Oberhand und die CPU konnte dann dazwischen zugreifen.

Und es klingt auch irgendwie nach Dual-ported RAM.

Wenn ich mich recht entsinne haben sichbeim ZX81 / ZX Spectrum die ULA und die CPU auch das RAM geteilt.

Ich würde die Adressen mit ALE auf beiden Seiten (Atmel und VideoController) über die D-Latches komplett erzeugen lassen. Damit sollte das Timing etwas streßfreier ablaufen. Man hat zwar dadurch mehr Bustreiber zum Video-RAM aber bereits die Durchlaufzeiten der D-Latche für ALE hinter sich.

Für die Platinen würde ich eine komplette Einheit mit D-Latch und Bustreibern für den Video-Controller und eine für den Atmel aufbauen. Dann noch eine Einheit mit dem Videospeicher. Die drei Einheiten würde ich über einen Bus verbinden. Das sollte die Experimente etwas erleichtern und man muß bei Schaltungsproblemen nur den entsprechenden Teil anpacken.

Das "Fast-RAM" kann dann ja mit auf den Atmel-Block.

Außerdem sollte man sich Gedanken über die Durchlaufzeiten durch die D-Latches und Bustreiber machen. Das RAM sollte auch recht flott sein. Das gilt vor allem bei der Benutzung mit dem Atmel da der sonst einiges an Waitstates einfügen muß. Also mal nachsehen ob man 74ALSxxx oder 74FCTxxx oder andere Bauarten verwenden kann um ein paar (oder sogar zig) Nanosekunden zu sparen.

Gruß
Dino

 

[unilein]

Hallo zusammen,

irgendwie klingt das gewaltig nach Amiga. Fast-RAM und Video-RAM.
Beim Fast-RAM konnte nur die CPU zugreifen.
Beim Video-RAM hatte der Copper und die Videohardware die Oberhand und die CPU konnte dann dazwischen zugreifen.

Jo, stimmt! Ob die wohl ein ähnliches Design benutzt haben? :to_pick_ones_nose3:


Deine Idee, das modular auf verschiedene Platinen zu packen hatte ich auch schon. Sonst gibts knoten mit den vielen Verbindungen. In der vergangenen Nacht habe ich das auch schon geträumt.
Aber zunächst bekomme ich den Kram auf dem Breadboard zum laufen. Ich werde es einfach anders zusammenstecken. Dann passt das auch mit den Drahtbrücken. Ich sträube mich lediglich gegen den Gedanken, alles wieder runter zu reißen und von Vorne zu beginnen. Es braucht schon etwa 1,5 Stunden um das Zeug wieder zusammen zu stecken. Und dann nochmal eine Stunde um alles zu kontrollieren oder zu korrigieren.

Gruß
Uni

 

[unilein]

So Leute, da bin ich wieder.
Komplett überarbeiteten Schaltplan hab ich mit. Sieht auch gleich übersichtlicher aus:





Die U9 bitte mal nicht beachten. Der ist momentan unwichtig.
Octal-Switche sind nun mit integriert.


Folgende Steuerung habe ich nun im Plan:

• 16-Bit Adressierung für das XMEM-Interface des Atmega (also volle 64KB am Start, aber erstmal nur 40KB physisch angeschlossen)
• A15 des Atmega steuert /CS des ersten RAM (Das "Fastmem", wie Dino es nennt) --> Low auf /CS heißt Chip aktiv
• PE0 des Atmega steuert die Datenrichtung der Octal-Switche. DIR auf low heißt für den Atmega Lesemodus des zweiten RAM (dem "Chipmem"), DIR auf HIGH heißt Schreibmodus für den Atmega
• Das Chipmem liegt aus der Sicht des Atmega ab $8000, das Ansprechen der Adressen ab $8000 setzt A15 auf high und schaltet das erste RAM stumm
• /CS des zweiten RAM liegt zusammen mit /OE auf GND. Der Chip ist somit immer aktiv und im Lesemodus. Laut Datenblatt ist es im Schreibmodus egal, in welchem Zustand /OE sich befindet, wenn Daten geschrieben werden.
• /WE wird vom Atmega gesteuert (ganz regulär mit Pin PE1). Die RAM's benötigen High an /WE und Low auf /OE, wenn sie gelesen werden sollen. --> Sollte also klappen
• /FS des MC6847 geht in der Austastlücke auf Low und mach zweierlei: Es löst mit der fallenden Flanke INT0 des Atmega aus (Wird gebraucht um auf den 2. RAM zuzugreifen) und es legt den Enable-Pin (E) der Octal-Switche auf Low, was sie "durchlässig" macht. In der restlichen Zeit sind die Switche auf TriState (E=High)
• /MS des MC6847 liegt an PD0 des Atmega an. Mit PD0 wird der VDC in der Austastlücke auf TriState gebracht und lässt so die Finger vom Adress- und Datenbus. So wird ein (Bild)störungsfreier Zugriff gewährleistet. /MS kann vermutlich stattdessen auch mit /FS verbunden werden... Aber ich versuche das erstmal so.

Hab ich alles? Ich glaube ja.

Ich habe es noch nicht aufs Steckbrett gesteckt. Übrigens hatte ich für das zweite RAM in den vorigen Schaltplänen falsche Pin-Bezeichnungen. Was auf meinem Steckbrett natürlich zu falscher Beschaltung geführt hat (d'Oh!). Vielleicht hätte ich zumindest minimale Ergebnisse erzielen können, wenn dieser Fehler nicht gewesen wäre. Na egal, ich muss jetzt sowieso alles nochmal neu stecken. Das wird aber heute nicht mehr passieren

Bin gespannt auf Eure Meinung

Gruß
Uni

 

[LotadaC]

Nein, schau mal was ich in #76 geschrieben habe.
Derzeit kannst Du auch Deinen ersten SRAM nur im Fenster beschreiben - wenn Du nämlich außerhalb des Fensters schreibst, geht /WR low, und zwar auch für den Videospeicher. Dadurch werden dessen Datenpins Eingänge (tristate), wie Du richtig gesagt hast. Der VDG soll aber eigentlich da gerade lesen.

Wie gesagt, würde ich die Switche nicht über das /FS-Netz bedienen (/CS), sondern über das /MS Netz. Auf das Fenster reagierst Du nur, wenn Du in den Videospeicher schreiben/lesen willst. Sonst läßt Du /MS oben, und hast Zugriff auf den ersten SRAM. Außerdem /RD und /WR mit über U6 schicken. Da die bei /MS=high tristate sind, wird /RD hinter dem Switch (also eigentlich /OE) via Pulldown auf Gnd gezogen. Die Datenrichtung der Adress-Switche können fest verdrahtet sein (äh... oder soll der VDG auch irgendwas aus dem ersten SRAM (direkt) darstellen?) - die des Datenswitches wird dann über /OE festgelegt (müßte man dann nochmal wegen den Timings schauen, ggf. mit Waitstates..) Mußt dann nur schauen, was an der A-, und was an der B-Seite sein muß.

Außerdem kannst Du so im ersten SRAM die untersten 1280 Bytes so nicht adressieren, deswegen ja der Vorschlag, A15 offen zu lassen (aber den ersten SRAM trotzdem ganz oben zu adressieren (also über 32k bis 64k)) /CS dann entweder über einen separaten Pin, oder invertiert aus /MS. Wenn Du meinst, daß die Adresswahl den Speicher schnell genug enabled, kannst Du natürlich auch das invertierte A15 auf den /CS legen.
Den Videospeicher könntest Du dann direkt unter den 32k adressieren (also von 24..32k - A15 ist low, der Rest wird über /MS festgelegt).

Soweit klar?
Hab ich irgendwelche Fehler drin?