mikrocontroller.net

Forum: Projekte & Code 8Bit Grafikkarte für µC


Autor: Uli (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Hier mal eine einfache Grafikkarte für µC. Aufgebaut wurde diese mit
3ICs. Einem CPLD von Xilinx XC9572PC84 und zwei Cache-Bausteinen aus
einen alten Mainbord. Die Grafikkarte hat eine Aufösung von
256x256Pixel und 32Farben. Den ProgrammierAdapter für den Xilinx Findet
ihr auf meiner HP. Die Software Webpack gibt es auf der HP von Xilinx.
Die Grafikkarte hat mich keine 10€ gekostet. Der CPLD kann auch durch
den größeren XC95108PC84 ausgetauscht werden. Ein kleines Testprogramm
für den Atmel ist dabei.

Mfg Ulrich

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lassen sich die beiden fehlenden Bits aus dem 8bit Speicher einfach so
ausgeben, oder werden die für was anderes verwendet ?
Ich habe nämlich noch einige RAMDACs aus ISA Grafikkarten rumliegen,
und die haben eine Farbtabelle eingebaut um 256Farben aus insgesamt
262144 Farben auswählen zu können.

Welchen Zweck haben eigentlich die Tristate Ausänge für die RGB Signale
?

Autor: Uli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Die 2Bits liegen brach und konnen noch für andere Dinge verwendet
werden. Allerdings sind die Makrozellen vom XC9572 verbraucht. Also
einen XC95108 verwenden. Ich werde wenn mein XC95108 da ist noch einen
TextModus einführen.

Mfg Ulrich

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Uli,

Tolle Sache. Eine Frage haette ich allerdings:

-in der Readme steht etwas von einer Aufloesung 640*480
 mit 70Hz wenn ein 40MHz Quarz angeschlossen ist.
 Vermutlich ist es doch nicht damit getan einen anderen
 Quarz anzuschliessen, wo muesste man da noch dran drehen?

Jens

Autor: Uli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jens,

Es reicht einfach einen anderen Quarz anschließen (32Mhz oder 40Mhz).

Mfg Ulrich

Autor: Hagen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
32 Farben ? Wenn du 6 Bits benutzt hast du doch 64 Farben, oder ?

Anbei mal mein akademischer Versuch einer 640x480x64 Grafikkarte. Sie
benutzt einen 10-15ns 512Kb SRAM, und wird mit 32MHz getaktet. Der AVR
wird über das XMEM Interface direkt mit dem CPLD verbunden und kann
quasi parallel zum CPLD auf den SRAM zugreifen (lesend und schreibend).
Dazu implementiert der CPLD auch einen Memory Bank Controller und einen
Addressdekoder. Es können also 3 zusätzliche Memory Mapped Geräte am
Bus angeschlossen werden. Es ergibt sich eine
Bildschirmwiederholfrequenz von ca. 70Hz.
Natürlich bisher alles ohne es in real auf einem Steckbrett zu testen,
eben akademischer Natur.

Zur Zeit versuche ich eine FSM=finite state Machine als VGA Karte zu
bauen. Diese soll dann ihr VGA-Timing und Bildschirmaddressen aus dem
SRAM lesen können. Dadurch wird es möglich das komplette VGA Timing per
AVR zu steuern und ergo kann man sich dann selber die Pixelauflösungen
dynamisch festlegen.

Auf Grund der höheren Anforderungen benötigt man schon einen XC95144XL
in TQPF100. Das obige Design erreicht einen maximalen Takt von 187Mhz,
sprich beim 5ns CPLD den fast maximalen Durchsatz. Da der AVR über das
XMEM Interface direkt auf den SRAM ohne Waitstates zugreifen kann,
benötigt man zum Lesen oder Setzen eines Pixel nur 3 Taktzyklen.

Ich hatte schon eine Version getestet die verschiedene Farbmodis bei
640x480 Pixel ermöglichte (133 Makrozellen). Es wurden 64 Farben 1
Pixel pr Byte, 16 Farben mit 2 Pixel pro Byte, 4 Graustufen mit 4 Pixel
pro Byte und Monochrom mit 8 Pixel pro Byte unterstützt. Diese Modus
konnte man durch den AVR einstellen. Allerdings habe ich das wieder
verworfen weil man es im Grunde nicht braucht. Wichtiger wäre die
dynamische Wahl der Pixelauflösungen.

Die Idee einer Textorientierten GraKa finde ich super. Hast du dir
schon Gedanken gemacht wie du das umsetzen willst ? Ich frage weil die
Dekodierung des Text-Bildschirmbuffers über den Zeichensatz im SRAM
eine ziemlich komplizierte Angelegenheit wird.


Gruß Hagen

Autor: Uli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Hast recht ich weiß auch nicht wieder wie ich auf 32Farben komme
natürlich 64Farben. Das kommt weil ich auch noch an an der neuen
Grafikkarte arbeite (bin ja so zerstreut sehe nur noch Latchs ;-)

Mfg Ulrich

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Ulrich,

warum arbeitest du mit den Schematics ? Ich komme damit überhaupt nicht
zurecht und finde VHDL eigentlich viel einfacher :)

Wenn man mit 3*2Bit DACs arbeitet kann man insgesamt 4 verschiedene
Farbmodis erzielen, einfach durch Umkodierung der Pixeldaten pro Byte.
Es sind ohne extra Hardware so 64/16 Farben, 4 Graustufen und
Monochrome möglich.

Falls es dich interessiert kann ich ja nochmal tiefer auf den von mir
geplanten FSM-VGA Algorithmus eingehen. Dieser soll in der ersten
Version nur Grafikmodis unterstützen, dafür aber vershiedene
Auflösungen indem man das VGA Timing selber definieren kann. Realiseren
will ich das über 2 ladbare Down-Counter. Für das Horizintale und
Vertikale Timing werden als jeweils 4 * 16 Bit "Register" im SRAM
gespeichert. Der CPLD lädt je nach Statemachine diese Werte in den
Horz./Vert. Counter und erzeugt so das Timing.

Problematisch, bzw. unpraktikabel sind diese "HiRes" Garfikmodis aber
denoch. Bei 640x480x64 muß der AVR 300Kb an Displaybuffer befüllen.
Deshalb wäre eigentlich eine Textgrafikkarte viel interessanter. Zwei
bytes im Displaybuffer definieren zb. 8x8 Pixel auf dem Display. Das
erste Byte enthält in den 2 Nibbles die Vordergund-/Hintergrundfarbe
des Zeichens. 1 Byte enthält das ACSII Zeichen und muß im CPLD als
Index in die Zeichsatztabelle benutzt werden. Der Vorteil ist das man
nun mit einem 32-64Kb SRAM arbeiten kann und der AVR nur noch 9Kb
beackern muß.

Gruß Hagen, HaReddmann AT T-Online DOT de

Autor: stromi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@uli
Hast du schon Beispiele mit Ausgabe als JPG da? Sieht doch bestimmt
super aus?
Textmodus ist geplant? Wie muss ich mir das vorstellen:
Asci-Zeichen-Satz der aufgerufen wird?
Alle Achtung super gemacht, was ich besonders schätze: alles ist
dokumentiert!
Danke dafür.
Tschaui

Autor: stromi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@uli
Kannst du bitte für nicht "C-Kundige" die Parameterübergabe
beschreiben?

Das Teil kann man so besser in Bascomaplikationen oder auch in  ASM als
Ausgabemedium benutzen.
Tschaui

Autor: Uli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Timing und Beispielgrafiken gibt es morgen. Muß jetzt erstmal arbeiten.
Der Textmodus sieht so aus das es einen Speicherbereich gibt indem der
Zeichensatz geladen wird. In einen anderen Speicherbereich brauch man
nur noch ein ASCII Wert Speichern, das gewünschte Zeichen wird dann
dargestellt. Allerdings benötigt man dann ein XC95108PC84(108
Makrozellen) der Pinkompatibel zum XC9572PC84(72Makrozellen) ist. Aber
bis dahin kann es noch etwas dauern. Aber erst nach meinem Winterurlaub
im April.

Mfg Ulrich

Autor: Uli (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Hier noch die neue Doku, noch ein Demo für den Atmel, und ein Bild von
der Farbpalette.

Mfg Ulrich

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wird die Textmode Grafikkarte auch dieselbe Platine verwenden ?
Ich versuche nämlich gerade die Schaltung auf 256 Farben mit einem
RAMDAC zu erweitern, und es wäre dumm wenn ich fertig wäre, aber die
neue Software dann nicht mehr zu meiner Hardware passen würde...

PS: Mit welchem Programm hast du das Timing Diagramm erstellt ?

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Ulrich,

Wie bist du bei den 640x480 Modis ausgehend von einem Pixeltakt bei
32MHz auf 61Hz, respektive 75Hz gekommen ? Müssten es nicht 77Hz bzw.
93Hz sein.

Desweiteren ist mir aufgefallen das deine Farbpalette aufgeteilt auf
die Bits im Byte vertauscht sind. Müssten die nicht MSB->LSB == R->G->B
== 2 Bits frei, Hellrot, Dunkelrot, Hellgrün, Dunkelgrün, Hellblau,
Dunkelblau sein ?

Bei einem Timing von 125ns pro ~WR muß man ja mit Waitstates bei 16MHz
Takt am AVR arbeiten.

Gruß Hagen

Autor: Uli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

@Hagen:
Der Clock liegt bei 61Hz und bei 75,xxHz, dieses zeigt zumindest meine
beiden Monitore und mein DigitalScope an. In der letzten Doku ist die
Farbpalette zu Sehen von 1 - 64 zu sehen 1 = Rot, 2 = Dunkelrot, 3 =
Hellrot usw.

>>Bei einem Timing von 125ns pro ~WR muß man ja mit Waitstates bei
>>16MHz Takt am AVR arbeiten.
Das ist Richtig!

@Benedikt:
Ist ein eigenes VB Programm, aber noch nicht Fertig für die
Veröffentlichung, welches mir Timings als .BMP Dateien erstellt.

Mfg Ulrich

Autor: Uli (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Habe an meiner Grafikkarte und an dem AVR eine GameBoy Camera
angeschlossen. Die GameBoy Camera macht eine Auflösung von
128x128Pixel. Der SourceCode und 3Bilder sind im Anhang.

Mfg Ulrich

Autor: stromi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@uli
Bitte dich noch einmal wegen der Grafikausgabe::

Kannst du bitte für nicht "C-Kundige" die Parameterübergabe
beschreiben?

Das Teil kann man so besser in Bascomaplikationen oder auch in  ASM als
Ausgabemedium benutzen.
MFG

Autor: Uli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Habe ich doch schon in der GraKaDoku gemacht! Mehr brauch man doch nun
wirklich nicht oder?

Mfg Ulrich

Autor: nummernschalter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

habe das Teil an ein µP Bussystem angeschlossen. So kann ich die Karte 
wie ein Stück Speicher beschreiben. Allerdings braucht das System zum 
kompletten Bildschirmfüllen etwa 2-3 Sekunden. Eine Erhöhung der 
Taktraten ist nicht möglich und auch das Speicherschreiben hat keine 
überflüssigen Befehle,
;SetzeBildPunkt
Sbp:
  ld  r0,#Adr_h
  ld  r1,#Adr_l
  ldc  @rr0,X
  incw  rr0  
  ldc  @rr0,Y
  incw  rr0  
  ldc  @rr0,Farbe
  ret

;BildSchirmLöschen
Bsl:
  clr  X
  clr  Y
  ;ld  X,#%ff
  ;ld  Y,#%ff
Bsl_w1:
  call Sbp
  djnz  X,Bsl_w1
  djnz  Y,Bsl_w1
  ret
wie Ihr unschwer erkennen könnt. Gibt trotzdem noch eine Möglichkeit, 
die ganze Sache zu beschleunigen?

Danke.

Autor: nummernschalter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal!

Auch wenn es keinen zu interessieren scheint, hier eine optimierte 
Lösung, welche die Durchlaufzeit auf etwas unter 1 Sekunde verkürzt. 
Achso, Prozessor ist ein Z8 ausgelegt für 8 aber mit 10MHz laufend.
;BildSchirmLöschen+
Bsl_plus:
  ld  r0,#Adr_h
  clr  X  
  clr  Y  
Bsl_plus_w1:
  ;Anfang SBP
  ld  r1,#Adr_l
  ldc  @rr0,X
  inc  r1
  ldc  @rr0,Y
  inc  r1
  ldc  @rr0,Farbe
  ;Ende SBP
  djnz  X,Bsl_plus_w1
  djnz  Y,Bsl_plus_w1
  ret

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.