Video Display Controller MC6847

Moin,

mal sehen, ob ich das zu früher Stunde und bislang ohne Koffein schon richtig deuten kann.

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.

Das habe ich anders interpretiert, denn /OE des Videospeichers muss immer auf low sein, da der VDC ja ständig lesen muss. /OE des Videospeichers ist daher fest mit GND verbunden. Geht /WR auch auf low, darf man trotzdem schreiben. Das RAM geht auf Tristate, wenn sowohl /OE als auch /WR auf high sind (und der Chip über /CS aktiv ist). So verstehe ich das Datenblatt des HY6264 (http://pdf1.alldatasheet.com/datasheet-pdf/view/65364/HYNIX/HY6264.html)

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ß.

Hier bin ich insofern bei Dir, dass es wohl sinnvoller ist, nur dann die Switche zu öffnen, wenn seitens des Atmega wirklich ein Zugriff auf das Video-RAM erfolgen muss. Der Zugriff erfolgt dann trotzdem im /FS-Fenster, wenn es ohne Bildstörungen ablaufen soll.

Ich bin aber nicht sicher, ob es sinnvoll ist, /WR und /RD auch über die Switche laufen zu lassen. Hier könnte ein Timingproblem entstehen. Vielleicht tatsächlich über Waitstates lösbar (die kann man pro Speicherbank ja getrennt einstellen). Das schaue ich mir nochmal an.

Und was den Speicherzugriff des VDG auf das erste RAM betrifft: Never Ever! Der VDG lässt die Finger vom ersten RAM!

Grüße,
Uni
 
...Das habe ich anders interpretiert, denn /OE des Videospeichers muss immer auf low sein, da der VDC ja ständig lesen muss. /OE des Videospeichers ist daher fest mit GND verbunden. Geht /WR auch auf low, darf man trotzdem schreiben. Das RAM geht auf Tristate, wenn sowohl /OE als auch /WR auf high sind (und der Chip über /CS aktiv ist)...
Jain...
/OE kann beim Speicher dauerhaft low bleiben, /CS ebenso (bzw der 2te CS ohne "/" zusätzlich high).
ABER wenn /WR low geht, werden die Datenpins EINGÄNGE, und sind logischerweise tristate (S.5 Write Cycle 2) - wenn Du also ausserhalb des Fensters auf den ersten RAM schreibst, legt /WR auch die Ausgabe des 2ten RAM lahm...
Du mußt also /WR irgendwie abkoppeln, wenn Du ausserhalb des Fensters das erste RAM beschreiben können willst...
...Und was den Speicherzugriff des VDG auf das erste RAM betrifft: Never Ever! Der VDG lässt die Finger vom ersten RAM!...
Warum willst Du dann die Richtung von U6 und U7 (also den Adressbus-Switchen) über E0 einstellen können - wenn es nur die Richtung vom AVR zu U8 gibt (oder eben getrennt mit /MS=high)?

Der Datenbus-Switch soll bidirektional sein (und auch nur dann, wenn der AVR (im Fenster) aus U8 lesen können soll).
 
Warum willst Du dann die Richtung von U6 und U7 (also den Adressbus-Switchen) über E0 einstellen können - wenn es nur die Richtung vom AVR zu U8 gibt (oder eben getrennt mit /MS=high)?

Das ist natürlich Blödsinn!

Gestern und heute habe ich den Atmega-Teil und den Video-Teil jeweils auf Streifenrasterplatinen aufgelötet. Beide Teile funktionieren. Jetzt muss ich die beiden Teile nur noch zusammenbringen. Auf beiden Platinen sind zusätzliche Steckleisten angebracht, damit ich sie problemlos verbinden kann.

Ein wenig chaotisch anzusehen, aber auf Streifenrasten nicht wirklich besser umsetzbar.

c9b403b367e233027ad9f0081b0215f7.jpg fc678e81d4b5c2c8c8f737966b16e3c7.jpg

Die "Hochzeit" will ich evtl morgen vornehmen. Auf dem rechten Bild fehlen noch die Octal-Switches in den Fassungen. Die sind aber inzwischen eingebaut.
Tja, wir werden sehen :D


Gruß,
Uni
 
Hast Du den ICs keine Kerkos spendiert?? (oder sind die in/unter den Sockeln?)
Ich würde direkt zwischen den Versorgungspins eines jeden ICs 'n 100nF-Kerko packen, und auf jede der Platinen 'n (low ESR) Elko mit 100µF oder so...

Ansonsten viel Erfolg morgen...
 
Die Kerkos befinden sich auf der Lötseite. Zwei Elkos habe ich noch nachgerüstet. Bislang habe ich die Schaltung immer mit Akkus betrieben, da braucht's keine Sieb-Elkos. Aber für die Zukunft ist das sicher besser.

Ich bin leider noch nicht dazu gekommen, die beiden Platinen zu verbinden. Beruflich turbulente Tage raubten mir die Motivation. Es geht aber ganz sicher bald weiter.

Grüße
Uni
 
Alles klar, aber:
...Bislang habe ich die Schaltung immer mit Akkus betrieben, da braucht's keine Sieb-Elkos...
die Akkus haben doch auch'n Innenwiderstand (der größer als der der Elkos sein sollte), folglich bricht die Spannung eventuell ein, wenn die ICs auf der Platine kräftig umschalten. Die induktiven/resistiven Effekte der Stromversorgungsleiterbahnen zwischen den Platinen sind da sicher nicht hilfreich. Und so'n 100nF is schnell leer...

Ansonsten ist das ja Dein Projekt, also laß Dich nicht drängeln;)
 
Die Akkus haben ordentlich Wums, da bricht nix ein. ;)

Inzwischen habe ich die beiden Platinen verbunden. Leider funktioniert nun fast nix mehr.
Folgendes habe ich bereits festgestellt:

  • auf A8 - A15 kommen gar keine Adressen an. Tausche des Atmega hat nix gebracht. Kann ja dann eigentlich nur ein Programmfehler sein.... Finden tu ich aber momentan nix
  • Ich benutze A15 um /LE der Switches auf Low zu bringen (über einen Inverter). Da auf A15 nix ankommt, kommt auch an /LE nix an.
  • Die Verbindungskabel (Flachbandkabel) erzeugen ziemliche Interferenzen.

Ich würde die Adressleitungen per Pulldown auf Masse legen. Was wäre ein geeigneter Widerstand? Sind 10K OK? Oder ist die Idee schon grundsätzlich schlecht?

Die Frage nach den Daten auf A8-A15 stellt sich erst, wenn ich den Analyzer dran hatte und verstehe, was da ankommt. Dazu nehme ich die Switches aus den Fassungen und entkoppele so den Videoteil vom Prozessorteil.

Gruß
Uni
 
OK, ich habe mich an einer Stelle verlötet. Ich habe eine Fassung um einen Pin versetzt eingelötet.
Jetzt ist auch klar, warum die Adressierung nicht funktioniert hat :mad:

Die Platine ist hin, das kann ich leider dort nicht mehr korrigieren. Ich löte das nochmal neu auf.
 
Auch wenn es jetzt ein bisschen OffTopic ist...

Darf ich mal fragen warum überhaupt das ganze?
Ich mein ich bin selber auch ein bissl Nostalgie Fan, daher verfolge ich diesen Thread auch. Immerhin war ein Schneider CPC464 mein erster PC. Noch schön mit Datasette ^^

Ich meine nur, ich habe schon Lösungen gesehen wo ein AVR nur mit ein paar Widerständen ein gutes NTSC (umschaltbar auf PAL) Signal herstellt, ohne weitere Komponenten. Ich persönlich habe es mangels analogen Bildanzeigegerät noch nicht probiert. Man könnte den Display-AVR ja z. B. auch via SPI mit neuen Daten befeuern.

Daher frag ich mich (für mein rein privates Interesse): Ist es bei dir eher Nostalgie oder möchtest du es wirklich produktiv einsetzen?
 
Auch wenn es jetzt ein bisschen OffTopic ist...

Darf ich mal fragen warum überhaupt das ganze?
Ich mein ich bin selber auch ein bissl Nostalgie Fan, daher verfolge ich diesen Thread auch. Immerhin war ein Schneider CPC464 mein erster PC. Noch schön mit Datasette ^^

Oh das ist ganz einfach zu beantworten: Einfach weil ich Bock darauf habe.

Und wenn es dann endlich funktioniert, dann habe ich einen AVR, der NULL Leistung für den Bildschirmaufbau verbraucht, und sich voll und ganz anderen Aufgaben widmen kann. Zum Beispiel einem kleinen Betriebssystem oder einem Basic-Interpreter (Auch nur aus Spaß an der Freud'). Und nebenbei kann der VDC auch noch 256 x 192 Punkte darstellen, sodass auch noch echte Grafik möglich wäre.

Außerdem lerne ich dabei jede Menge.

Der Nutzen für die Menschheit? Der liegt vermutlich bei NULL :)
 
Wie die Zeit vergeht....

Inzwischen habe ich von meinem Schaltplan über http://www.easyeda.com 5 PCB's erstellen lassen. Diese habe ich Anfang Juni bekommen. Ich habe meine Schaltung sogleich aufgebaut und angeschlossen. Und siehe da: Sie funktioniert und zeigt ein störungsfreies Bild. Leider fand ich im Laufe meiner Versuche dann doch noch 2 kleine Fehler auf dem PCB, diese ließen sich jedoch leicht mit dem Auftrennen zweier Verbindungen beheben.

Trotzdem verzweifele ich gerade: Wenn ich Daten an das Video-RAM schicke, ist der VDC auf tristate und hält sich vom Adress- und Datenbus fern. Nach dem Schreibvorgang lasse ich den VDC dann wieder ran. Soweit die Theorie. Praktisch sieht es anders aus. Wenn ich ein Zeichen ins Video-RAM schreibe, landet das nicht nur auf der Zieladresse, sondern überall im Video-RAM. Also ein Zeichen füllt den kompletten Bildschirm. Für mich sieht das so aus, als würde der VDC wieder aktiv sein und fleißig Adressen auf den Adressbus legen, gleichzeitig liegt aber auf dem Datenbus noch das alte Zeichen an.

Also funktioniert die Trennung des Atmega vom Video-RAM nicht.oder mein Octalswitch geht nicht auf Tristate, wenn ich es will.

So, das ist jetzt nur mal eine Erklärung der Situation. Ich habe das noch nicht im Detail untersucht. Das werde ich demnächst dann mit dem Logik-Analyzer tun.

Grüße
Uni
 
Zeig mal nochmal'n aktuellen Schaltplan (inklusive der beiden Korrekturen) - oder ist das noch der aus #79?
Für mich sieht das so aus, als würde der VDC wieder aktiv sein und fleißig Adressen auf den Adressbus legen, gleichzeitig liegt aber auf dem Datenbus noch das alte Zeichen an.
Oder der Daten-Switch schaltet nicht odentlich ab, und übersteuert den Video-RAM wenn der VDG wieder drann ist.
Was es von beidem ist, sollte Dir der LA sagen...
nein, das war Quatsch
 
[S schrieb:
Oder der Daten-Switch schaltet nicht odentlich ab, und übersteuert den Video-RAM wenn der VDG wieder drann ist.
Was es von beidem ist, sollte Dir der LA sagen...[/S] nein, das war Quatsch

Ehrlich gesagt ist das genau das, was ich auch vermute. Aber mal sehen, was der LA sagt.
 
Wenn der Switch "enabled" ist, und damit eigentlich transparent durchleitet, gilt das nicht für einen tristate-Zustand vom AVR her.

Was erscheint, wenn Du einmal korrekt im Fenster ein Zeichen überträgst, und dann außerhalb des Fensters andere Zeichen auf den Datenbus legst? Also bei eigentlich getrenntem Datenswitch...
 
Vor ziemlich genau einem Jahr habe ich angefangen über dieses Projekt nachzudenken.

Inzwischen habe ich es verwirklicht, wenn auch nur leidlich erfolgreich. Auch nach stundenlangen Analysen habe ich keinen Ansatz zur Behebung des Bus-Problems gefunden. Ich steige nicht dahinter.

Ich weiß, ich sollte meinen den Schaltplan mal posten und dazu den Code. Aber das lasse ich im Moment mal sein. Ich muss das Projekt vorerst ad acta legen. Wie jedes Jahr um diese Zeit habe ich ein TS16949 Audit. Das verlangt mir mehr ab, als ich eigentlich leisten kann. Da habe ich dann keinen Kopf mehr für Bus-Probleme.

Eure Anregungen haben mich aber in vielerlei Hinsicht weiter gebracht. Dafür danke ich Euch.

Das Projekt werde ich zu einem späteren Zeitpunkt wieder starten.

Beste Grüße
Uni
 
Hallo Unilein,

ich wünsche dir viel Erfolg bei dem Audit ... und mache dir nicht zu viel Stress :)

Das Projekt werde ich zu einem späteren Zeitpunkt wieder starten

Das wäre super!

Dirk :ciao:
 
Es lässt mir doch keine Ruhe. Verd*mmt! ;)

Heute kam mir die Idee, dass ich die Steuerung mal komplett manuell machen könnte. Also externe Speicherschnittstelle aus, Interrupt aus usw.
Die Ports manuell angesteuert, eine Adresse auf den Bus, ALE aktiv setzen, kurz warten, ALE aus. Schreibmodus an, Daten auf den Bus, Schreibmodus aus.
Und dann mal schauen was passiert....

Kleiner Code-Auszug:


CodeBox Assembler

                    // Ports auf Ausgabe
                    ldi temp,    $ff
                    out DDRA,    temp
                    out DDRC,    temp
                    out DDRD,    temp
                    out DDRE,    temp

                    // Datenrichtung vom Datenswitch A-->B
                    ldi temp,    (1<<PE0)
                    out PORTE,    temp    ; High
                   
                    // /WR auf High
                    ldi temp,    (1<<PD6)
                    out PORTD,    temp    ; /WR High

                    // MC6847 auf TriState
                    ldi temp,    (0<<PD0)
                    out PORTD,    temp    ; MS6847 weg vom Speicher


                    // $8001 auf die Adress-Leitungen
                    ldi temp,    $80
                    ldi temp1,    $01
                    out PORTA,    temp1        ;Low-Byte der Adresse
                    out PORTC,  temp        ;High-Byte der Adresse

                    // ALE an, Adresse auf Bus und Latch
                    ldi temp,    (1<<PE1)
                    out PORTE, temp
                    nop
                    nop
                    nop
                    nop
                    nop
                    ldi temp,    (0<PE1)
                    out PORTE,    temp


                    // Daten für die Speicherstelle $8001
                    ldi temp,    (0<<PD6)
                    out PORTD,    temp    ; Schreiben = /WR Low
                    ldi temp,    $41            ; "A"
                    out PORTA,    temp        ; ausgeben
                    ldi temp,    (1<<PD6)
                    out PORTD,    temp        ; Nicht mehr schreiben = /WR High


                    // MC6847 online
                    ldi temp,    (1<<PD0)
                    out PORTD,    temp    ; MC6847 online!



der Code ist ungetestete Theorie. Ich habe momentan das Equipment für die Tests nicht parat. Dazu passend der Schaltplan, damit die Port-Angaben Sinn ergeben:

AVR-Laser-V9.png


Könnte das so gehen? Wie gesagt, nur Gedankenspiel!

Gruß
Uni
 
Hallo,

Heute kam mir die Idee, dass ich die Steuerung mal komplett manuell machen könnte. Also externe Speicherschnittstelle aus, Interrupt aus usw.
Die Ports manuell angesteuert, eine Adresse auf den Bus, ALE aktiv setzen, kurz warten, ALE aus. Schreibmodus an, Daten auf den Bus, Schreibmodus aus.
Und dann mal schauen was passiert....
...
Könnte das so gehen? Wie gesagt, nur Gedankenspiel!

das macht auf jeden Fall Sinn. Deinen Quellcode hab ich jetzt auf die Schnelle nicht durchgesehen. Aber die angeschlossene Hardware durch simulierte Abläufe zu testen ist immer eine gute Sache. Das mache ich auch oft wenn eine Schaltung steht. Dann ist man sicher das die Hardware das macht was sie soll. Man trennt Hardware- und Software-Bugs.

Gruß
Dino
 
Hallo Unilein,

bei den Steuersignalen ist es eventuell ungünstig, wenn du mit "out" ein ganzes Portregister änderst. Beispiel: Am Anfang setzt du PE0 (Datenrichtung A-->B), später "überschreibst" du dies bei der Änderung von PE1. Du kannst auch einzelne Bits setzen (sbi) oder löschen (cbi).

Dirk :ciao:
 
bei den Steuersignalen ist es eventuell ungünstig, wenn du mit "out" ein ganzes Portregister änderst. Beispiel: Am Anfang setzt du PE0 (Datenrichtung A-->B), später "überschreibst" du dies bei der Änderung von PE1. Du kannst auch einzelne Bits setzen (sbi) oder löschen (cbi).
Dirk :ciao:

Fraglos keine gute Idee, und leicht zu ändern. Das Programm funktioniert dennoch und gibt ein "A" auf dem Schirm aus. Allerdings nicht nur in Spalte 1 auf Zeile 1 sondern auf alle Zeilen und alle Spalten. Das Datenbyte hängt also auf dem Bus fest, während MC6847 (nachdem er wieder online ist) munter Adressen auf den Adressbus wirft um den Speicher zu lesen. An seinem Datenbus liegt offenbar die ganze Zeit das "A" an.

Da ich nicht sicher war, ob vielleicht auch das /WR-Signal des Videospeichers aktiv bleibt, habe ich den Baustein kurzerhand ausgebaut und den Versuch wiederholt. Zur Sicherheit mit einem "B". Und siehe da: Das "B" auf dem gesamten Schirm. Jetzt ist also klar, dass das Datenbyte auf dem Bus festhängt. Vermutlich doch der 74HC245, der da nicht richtig "schliesst".

Heute Abend habe ich keine Zeit mehr (eigentlich habe ich ja ÜBERHAUPT keine Zeit), aber wenn es morgen regnen sollte, werde ich das Thema ein wenig vertiefen.

Grüße
Uni
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)