Video Display Controller MC6847

In Zeile 35 hast du ein "<" vergessen. Im Moment ist dort ein Vergleich, das Ergebnis wird immer eine 1 liefern und PE0 setzen.
ldi temp, (0<PE1)
out PORTE, temp

Das löst zwar sicher nicht das Problem, aber sowas übersieht man schnell mal :)

Verwende am besten sbi und cbi, das macht den Code übersichtlicher.

Dirk :ciao:
 
ja ja :yes4:

Du hast ja Recht Dirk. Komme gerade vom wöchentlichen Einkauf zurück und meine Frau hat gesagt, ich dürfe jetzt basteln gehen. Ich werde also das kleine Testprogramm mal vernünftig herrichten und dann mal wieder intensiv nach der Funktionsabweichung suchen. Dank des Versuchs gestern ist das Problem ja soweit eingekreist. Kann eigentlich nix großes sein.

Das Testprogramm poste ich später zusammen mit neuen Erkenntnissen.

Uni :good3:
 
Zum Glück regnet es heute mal! ;)

Das Programm habe ich mal korrigiert und es funktioniert auch:



CodeBox Assembler

                    // Dem Rest der Schaltung ein paar Zyklen Zeit geben um aktiv zu werden
                    ldi temp,    $FF
    l1:                dec temp
                    brne        l1



                    // Address-Ports + ALE auf Ausgabe
                    ldi temp,    $ff
                    out DDRA,    temp
                    out DDRC,    temp
                    out DDRD,    temp
                    out DDRE,    temp

                    // Datenrichtung vom Datenswitch A-->B
                    cbi    PORTE,    0
                   
                    // MC6847 auf TriState
                    cbi PORTD,    0            ; MS6847 weg vom Speicher

                    // /WR auf High
                    sbi PORTD,    6            ; /WR high

                    // $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
                    sbi PORTE, 1            ; Latch enabled
                   
                    ldi temp,    $41
    l2:                dec temp
                    brne        l2


                    cbi PORTE,    1            ; Latch disabled


                    // Daten für die Speicherstelle $8001
                    cbi PORTD,    0            ; Schreiben = /WR Low
                    ldi temp,    $41            ; "A"
                    out PORTA,    temp        ; ausgeben
                    sbi PORTD,    6            ; Nicht mehr schreiben = /WR High


                    // Adresse 0 auf Port A + C, und Ports auf Eingang
                    ldi temp,    $00
                    out PORTA,    temp
                    out PORTC,    temp
                    out DDRA,    temp
                    out DDRC,    temp

                    // MC6847 online
                    sbi PORTD,    0            ; MC6847 online!

always:                jmp always



Gestern hatte ich beschrieben, dass das Testprogramm auch tatsächlich den Buchstaben "A" ausgibt, die Schaltung diese Ausgabe jedoch vervielfacht und den ganzen Bildschirm füllt. Dieser Effekt entsteht auch, wenn ich den Videospeicher aus der Schaltung entferne. Der Rückschluss, dass dann wohl das Datenbyte auf dem Bus bleibt und bei der Reaktivierung des MC6847, der dann ja Adressen auf den Adressbus legt, munter durch die Gegend geschleudert wird, scheint sich zu bestätigen.

Ich bin mir ziemlich sicher, dass mein grundsätzliches Schaltungsdesign in Ordnung ist und Programm und Schaltung grundsätzlich funktionieren (müssten). Die Tests zeigen aber, dass hier irgendwo ein Pegelproblem besteht, weil (mindestens) der Datenbus des AVR nicht ordentlich vom Videospeicher und dem MC6847 abgekoppelt wird.

Ich habe in dem Zusammenhang das Datenblatt des Octal-Switch 74HC245 gewälzt und ein wenig gegoogelt und bin dabei auf den Artikel zum Thema TriState bei WikiPedia gestoßen. Dort wird beschrieben, dass wenigstens ein Ausgang mit einem Pulldownwiderstand auf ein definiertes Potenzial gelegt werden muss. Der Octal-Switch kann mit einem Low-Pegel an Pin 19 auf TriState gestellt werde, was ich tue, um den Adress- und Datenbus des AVR vom Videospeicher und dem MC6847 zu trennen. Meine Schaltung sieht an dieser Stelle keinen Pulldownwiderstand vor, da ich der Meinung war, dass es genügt, einen definierten Pegel an den Eingängen der Switche zu haben. Interpretiere ich nun den Artikel auf Wikipedia falsch? Oder muss ich meine Schaltung tatsächlich um mindestens einen Pulldownwiderstand pro Octal-Switch erweitern?

Wenn die Octal-Switche in der aktuellen Schaltung tatsächlich nicht richtig auf TriState gehen, dann muss ich mich wohl nicht wundern, warum da so einiges nicht funktioniert.

Schon mal recht herzlichen Dank für Eure Einschätzung.

Uni
 
Hi,

TriState heißt ja hochohmig. Wenn du nun überall CMOS einsetzt, dann sind die Gates der Eingänge evtl noch geladen und werden wegen der hochohmigen Ausgänge im Pegel nicht geändert.

Gruß
Dino
 
Hallo zusammen,

Lange ist es her.....

Und ich habe den alten Ansatz mit den Octal Switches über Bord geworfen und von vorne angefangen. Lediglich einer ist übrig geblieben.
Die Schaltung ist bereits auf eine Platine gelötet. Den Schaltplan habe ich beigefügt. Außerdem habe ich den Schaltplan beigefügt, der mich
zum Neuansatz inspiriert hat.

Gruß
Uni

AVR-Laser-V11.png
 

Anhänge

  • VZ200.png
    273,2 KB · Aufrufe: 5
Hallo Forengemeinde,

ich bin gerade ein wenig verzweifelt. In meinem letzten Beitrag habe ich meine überarbeitete Schaltung vorgestellt und dafür auch ein PCB erstellen lassen (Wen es interessiert: ich habe die Schaltung online auf http://www.easyeda.com entwickelt, mit der Autoroute-Funktion ein PCB erstellt und dieses dann auch über EasyEda bestellt.) Nachdem ich meine Komponenten (Mit Fassungen) auf der Platine verewigt hatte und ich meine ersten Tests durchführen wollte, stellte ich fest, dass die Platine wie eine Antenne ist. Wenn ich auch nur meine Hand in die Nähe bringe, spielt die Schaltung verrückt (Chaos auf dem Bildschirm, wechselnde Bildschirmmodi usw.).

Ok, mein PCB hat keine Massefläche sondern nur einfache Leiterbahnen für GND. Das dürfte ein Fehler sein und EIN Grund für die Probleme sein. Darüber hinaus überlege ich, ob ich, und so wurde das weit vorne in diesem Thread bereits mal vorgeschlagen, ein paar Pins mit Pulldown-Widerständen zu versehen. Jetzt bin ich aber unsicher, ob das Sinn macht (das Schaltbild, welches mir als Beispiel diente, hat keine) und wenn es doch Sinn macht, welche Pins ziehe ich gegen Masse? Alle Adressleitungen und alle Datenleitungen? Oder nur die Adressleitungen? Vielleicht hat jemand von Euch einen Tipp oder eine Einschätzung für mich.

Übrigens: Alle IC's verfügen über Abblockkondensatoren auf der Unterseite meines PCB. Im Schaltplan sind diese nicht eingezeichnet.

Vielen Dank schon mal für Eure Unterstützung.

Gruß
Uni
 
Hallo Uni,

ja, es könnte unter anderem am Massekonzept liegen. Was mir "nicht so gefällt", das sind die 6k8Ohm Widerstände in den Adressleitungen. Vielleicht hast du nun zu lange Leitungen und Probleme mit dem Timing. Versuche einmal Steuersignale zu RAM und Displaycontroller zu verzögern, also einfach ein paar NOPs in die Software einbauen, mach das mal überall wo es möglich ist. Ansonsten habe ich im Moment keine Ideen.

Dirk :ciao:
 
Hi,

wenn man alleine durch das in die Nähe bringen der Hand die Schaltung aus dem Konzept bringt, dann sieht das für mich eher nach offenen CMOS-Eingängen aus. Wenn da irgendwo ein 50-100k PullUp oder PullDown an der Leitung hängt, dann sollte das eigentlich schon nicht mehr passieren. Oder du hast sehr starke Störfelder in der Umgebung.

Gruß
Dino
 
Hallo Dirk,

danke für Deine Einschätzung. Wie komme ich zu den 6,8K Widerständen? Ganz einfach: Ich habe mich am Schaltplan des VZ200 orientiert (Siehe mein vorletzter Eintrag). Dort wird mit diesem Konzept eine Trennung der Signale auf dem Adressbus erreicht. Einfach nach dem Motto: Solange der MC6847 aktiv ist, gewinnen dessen Signale auf dem Adressbus. Sobald der MC6847 auf Tristate geht, was ja in der aktuellen Schaltung bei Ansprache von Adressen oberhalb von $7FFF seitens des Atmega passiert, gewinnen die Signale des AVR. Der Datenbus wird mittels eines Octal-Switch zu- bzw. abgeschaltet, auch in Abhängigkeit vom angesprochenen Adressbereich.

Das NOP-Thema probiere ich trotzdem mal.

Uni :)
 
Offene Leitungen gab es am Inverter. Der ist als CMOS-Baustein mit TTL-Pegel ausgelegt. Ich habe die offenen Eingänge jetzt auf High gelegt.
Ansonsten gibt es keine offenen Leitungen.

Auf jeden Fall erstelle ich mal noch ein neues PCB mit entsprechender Massefläche.
 
So,

dann wollen wir mal. Prinzipiell war mein letzter Entwurf der Schaltung der richtige Ansatz.
Folgende Bedingungen müssen erfüllt sein:
  • Der MC6847 benötigt einen eigenen Speicher (wenn man das SRAM des Atmega162 auch erweitern und nutzen möchte)
  • Der MC6847 benötigt zu jeder Zeit Zugriff auf den (Video)speicher
  • Der Datenbus des AtMega muss, solange dieser nicht auf den Videospeicher zugreift, abgekoppelt sein (74HCT245, Octal-Switch)
  • Der Verbindung der Adressbusse von ATMega und MC6847 werden mit Widerständen versehen, damit sie sich nicht in die Quere kommen.
  • /MS des MC6847 darf NICHT mit /FS des MC6847 verbunden werden. /MS wird manuell über PE0 von PORTE gesteuert.
  • Der ATMega kann theoretisch mit maximaler Frequenz betrieben werden, dann kommt es jedoch ab und zu zu Problemen mit den Speicherzugriffen und der MC6847 reagiert außerdem nicht schnell genug auf PE0 um auf TriState zu gehen.
  • Der ATMega wird aufgrund der zuvor beschrieben Problematik mit 3,579545 MHz betrieben und ist so im Gleichschritt mit dem MC6847
  • Der Videospeicher wird nur in der Austastlücke (Signal /FS vom MC6847) beschrieben!!
Wie man auf dem Bild in meinem letzten Beitrag sehen kann, kann der Videospeicher beschrieben werden und der MC6847 bringt es auf den Schirm. Der Beweis, dass der VDC MC6847 mit einem modernen ATMega162 zusammenarbeiten kann, ist somit erbracht (Das war ja die Ausgangsfrage).

Dennoch: Das Timing ist extrem empfindlich. Finden Schreibvorgänge außerhalb der Austastlücke statt, "schleift" der MC6847 das auf dem Datenbus liegende Byte mit und füllt im Schlimmsten Fall den gesamten Bildschirm damit.

Liegt ein Byte auf dem Datenbus und /WR des Videospeichers liegt auf Low, wird der gesamte Baustein mit dem Byte beschrieben, da der MC6847, sofern er nicht auf TriState ist, munter Adressen auf den Bus legt.

Es gelingt mir also momentan, gezeigten Text auf den Schirm zu legen, jedoch kommt es bei weiteren Schreibzugriffen momentan noch zu fehlerhaften Adressierungen, da der MC6847 offensichtlich etwas Zeit braucht, um auf TriState zu gehen. Zu lange darf der TriState-Modus allerdings auch nicht gehalten werden, da dann Artefakte auf dem Schirm erscheinen.

Nicht so einfach... :)

Letztendlich ist es also eine Frage des Timings und des grundsätzlichen Schaltungsdesigns gewesen.

Die Schaltung zieht übrigens (ohne den Bildschirn, aber mit dem Videosignalverstärker) 150 mA.

Im Anhang findet Ihr die nochmals leicht überarbeitete Schaltung (wegen /MS)

Gruß
Uni

AVR-Laser-V12.png
 
Hi,

Es gelingt mir also momentan, gezeigten Text auf den Schirm zu legen, jedoch kommt es bei weiteren Schreibzugriffen momentan noch zu fehlerhaften Adressierungen, da der MC6847 offensichtlich etwas Zeit braucht, um auf TriState zu gehen. Zu lange darf der TriState-Modus allerdings auch nicht gehalten werden, da dann Artefakte auf dem Schirm erscheinen.

Nicht so einfach... :)

Letztendlich ist es also eine Frage des Timings und des grundsätzlichen Schaltungsdesigns gewesen.

also wirst du das Datenblatt des 6847 wegen den genauen Zeiten noch etwas mehr unter die Lupe nehmen müssen.

Timing-Probleme sind immer toll :confused: siehe auch hier bei mir ... Analyzer für I2C/TWI und 1-Wire/microLAN - Beitrag #9
Da waren meine Transistoren zu langsam.

Gruß
Dino
 

Ü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)