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
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 ?
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
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
Hallo Jens, Es reicht einfach einen anderen Quarz anschließen (32Mhz oder 40Mhz). Mfg Ulrich
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
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
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
@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
@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
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
Hallo, Hier noch die neue Doku, noch ein Demo für den Atmel, und ein Bild von der Farbpalette. Mfg Ulrich
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 ?
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
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
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
@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
Hallo, Habe ich doch schon in der GraKaDoku gemacht! Mehr brauch man doch nun wirklich nicht oder? Mfg Ulrich
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,
1 | ;SetzeBildPunkt |
2 | Sbp: |
3 | ld r0,#Adr_h |
4 | ld r1,#Adr_l |
5 | ldc @rr0,X |
6 | incw rr0 |
7 | ldc @rr0,Y |
8 | incw rr0 |
9 | ldc @rr0,Farbe |
10 | ret |
11 | |
12 | ;BildSchirmLöschen |
13 | Bsl: |
14 | clr X |
15 | clr Y |
16 | ;ld X,#%ff |
17 | ;ld Y,#%ff |
18 | Bsl_w1: |
19 | call Sbp |
20 | djnz X,Bsl_w1 |
21 | djnz Y,Bsl_w1 |
22 | ret |
wie Ihr unschwer erkennen könnt. Gibt trotzdem noch eine Möglichkeit, die ganze Sache zu beschleunigen? Danke.
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.
1 | ;BildSchirmLöschen+ |
2 | Bsl_plus: |
3 | ld r0,#Adr_h |
4 | clr X |
5 | clr Y |
6 | Bsl_plus_w1: |
7 | ;Anfang SBP |
8 | ld r1,#Adr_l |
9 | ldc @rr0,X |
10 | inc r1 |
11 | ldc @rr0,Y |
12 | inc r1 |
13 | ldc @rr0,Farbe |
14 | ;Ende SBP |
15 | djnz X,Bsl_plus_w1 |
16 | djnz Y,Bsl_plus_w1 |
17 | ret |
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.