Diese Schaltung ermöglicht die Darstellung von Farbbildern auf einem TV.

Das beste daran: Die Software läuft auf einem AVR, der noch etwa 30-40%
Rechenleistung frei hat um z.B. das Bild aufzubauen oder andere Sachen
zu erledigen. Die Bildausgabe läuft im Hintergrund. Abgesehen von den
64kB SRAM kommt die Schaltung nur mit billigen HCMOS ICs aus.

Und die Software ist in ein AVR-GCC Programm eingebunden, das ganze
lässt sich also bequem in C programmieren...
Dieses Bild ist als Beispielprogramm dabei.

Hier noch ein Video das eine Oszilloskopsimulation zeigt. Das ganze kann
schneller laufen, aber ich war faul und berechne den Sinus in jedem Bild
mittels float, und das dauert halt.

Hallo

als SRAM könnte ich doch auch 62LV1027PCB-70 von Reichelt nehmen, oder
?
Der hat eben den doppelten Speicher , einen 64k hat Reichet leider
nicht.

Die 70ns sind etwas langsam, 55ns sollte das SRAM auf jedenfall haben.

Dann bleibt nur noch der K6T4008C1B-DB55.

Das Video kann ich leider nicht sehen, aber aus dem Teil könnte man
doch ideal ein Oszi bauen. Noch einen parallelen A/D Wandler mit 8 bit.
an PortD. und fertig

Ich mach gerade ne Platine, weil zum verdrahten auf Steckbrett ist mir
das zu fett. Hat evtl noch jemand interesse daran?

also ich wär an einer kompletten funktionellen platine mit einem avr und
den anderen bauteilen bereit. müsste aber  eine
spannungsquelleneinspeisung von 7- ca 10 volt haben ohne das ich genau
5v abgreifen muss für dei platine.

mfg

wenn es los geht, sag es. der preis spielt erst einmal eine
untergeordnete rolle.

Was anderes: Ich habe irgendwie noch im Hinterkopf, dass nur die
sauteuren TV eine RGB-Schnittstelle haben. Die meisten verwenden auch
über SCART nur FBAS. Oder Hast sich da mittlerweile was getan..?

Wenn auf dem Stand von 1980 lebst stimmt deine Aussage.
Jeder heutige TV hat eine RGB fähige Scartbuchse wenn er nicht gerade
20 Jahre alt ist, oder 19,95€ im super-billig-spar Markt gekostet hat.

RGB liefert ein sehr viel besseres Bild, vor allem bei bunten Grafiken
mit scharfen Farbübergängen, wie hier.

Ja jeder TV hat das heute glaub ich. Sag mal ich versteh nix von C, aber
könnte man eine software bauen, die dass so ein bisschen OSD mäßig
gestaltet, so mit SPI oder so? Hintergrund ist folgender: Ich plane auf
die Platine noch nen MEGA128 zu machen, der dann den Video-Controller
ansteuert. Wenn man beispielsweise Daten loggen will, wird der MEGA128
diese Aufgabe übernehmen können...

@Benedikt

kannst du mal ein neues / funktionierendesd Video reinstellen? Ich komm
da auch nicht drauf/dran

mit Kaffeine unter Knoppix konnte ich es anschauen, der Windows
Mediaplayer kannte es nicht und sucht ein DivX-Codec

such mal bei google nach mega codec pack oder lad dir bei
www.mplayerhq.hu nen windows build der spielt so ziemlich alles

Dieses Tool hier kann es auch problemlos anzeigen:

http://www.videolan.org/

@Sebastian
SPI ist möglich, aber ungünstig, da der AVR worst case nur alle 60us
dazu kommt ein byte aus dem Empfangspuffer abzuholen. Mehr als 100kHz
Datenrate darf man also nicht verwenden.


Das Video ist ganz normales DivX, ich muss mal schauen ob ich noch
einen mpeg Encoder installiert habe, das ist vielleicht etwas einfacher
abzuspielen.

Kann man das RGB nicht zu einem FBAS mischen?
Meine TV Karte z.B. hat nru nen FBAS Eingang kein SCART (Wäre ja auch
Platztechnisch etwas enge ;) )

Wegen dem Video: Mein Winamp hats ohne maulen gespielt.

hier mal das file als mpeg1

rs232 wär aber auch nicht schlecht.

@läubi, evtl pack ich nen rgb->fbas encoder mit drauf. ist ja nur 1 ic
mit peripherie.

Könnte jemand die implementierung eines befelssatzes vornehmen? das man
text einfach ositionieren kann und farben wählen etc?

Oder wär es denkbar die routine in bascom einzubinden? dann könnte ich
es selber machen

An welche Art Befehlssatz denkst du, und welche Schnittstelle ?
Was ist das für ein RGB-FBAS Konverter verwendest du ?

Ach was ganz einfaches ZB:

&H1 &H1 &H1 &H1 jetzt kommt ein komplettes bild

&H14 + XXXYYY  text cursor to pos x
&H15 + XXX textfarbe
&H16 + XXX texthintergrund
&H17 + STRINGSTRINGSTRING text bis nochmal &H15 kommt
&H18 löschen

&H2 pixel bei XXXYYY setzen (pixelcursor)
&H3 Pixelfarbe
&H4 auslesen eines pixel
&H5 Bild löschen (alles wird mit aktueller pixelfarbe überschrieben)

&H6 +XXXYYY linie in aktueller pixelfarbe von x nach y

evtl noch so standardfunktionen circle, frame

xxx wäre dann zb en gesendetes byte also &H65 (ein A wird gesendet, das
beschleunigt die übertragung)

Und welche Schnittstelle ?
Der UART wäre dank der internen Doppelpufferung am einfachsten. Mit SPI
wüsste ich jetzt nicht wie ich das realisieren könnte.

uart ist voll okay das macht die ganze sache viel zugänglicher...

Respekt!

Ich selbst programmiere auch "nur" mit BASCOM. Von daher bringt mir
der C-Code auch nicht viel. Eine UART-Anbindung wäre schon sehr
hilfreich. Und dann den Code als fertige HEX.

Ich frage mich nur, wie man damit wohl Bilder darstellen könnte?

Das bild könntest du vorher speichern, oder errechnen, zB könnte man
später wenn das ganze richtig läuft ein bildfenster einstellen, und man
kann einzelne buttons darstellen, die man dann ändern kann.

Es gibt für jeden Pixel auf dem TV Bild ein Byte im Speicher.
Dieses kann man direkt beschreiben um so Bilder oder andere fertige
Grafiken zu senden, oder man kann die verschiedensten Befehle nutzen
die dann diese Bytes beschreiben, um Linien, Rechtecke oder andere
einfache Formen zu zeichen.
Texte sind auch möglich mit getrennten Vorder/Hintergrundfarben und
transparentem Hintergrund.
Mit Spezialfunktionen wie dem Füllen einer beliebigen Form habe ich
bisher noch nie gearbeitet, da solche relativ viel Speicher benötigen
und aufwendig sind. Die erste Version (vermutlich Ende der Woche) wird
daher nur Text und Pixel/Liniengrafik enthalten.

Bei Texten versteh ich das ganze ja noch.
Einen Code senden um anzugeben, ob jetzt Steuerzeichen oder Textzeichen
kommen. So kann man eine bunten Text schreiben.
Linien oder einfache Formen mit Circle, Line, Box, ... in Farbe und
evtl noch ausgefüllt kann ich mir auch noch vorstellen.

Aber ich dachte jetzt ich nehme mir ein Bild, ändere die Größe auf
256X252 Pixel und speichere es als 8Bit-BMP wieder ab. Ohne jetzt den
Rechner zu starten sehe ich schon so, das es (für einen µC) viele Bytes
sind. Aber ich denke, einfacher geht es wohl nicht?

Ich stelle mir das so vor, das man ein paar Thumbs hat und mit einer
Box umranden kann und somit schonmal ein Menü hat.
Aber wie schnell wird da wohl der Bildaufbau sein? 1-2 Sek wären ja
locker zu verkraften. Es handelt sich ja nur um einen AVR.

Lässt sich das so einfach realisieren?

Also ich finde das Projekt sehr gut! Soetwas suche ich schon lange.
Wenn ich irgendwie helfen kann, einfach bescheid sagen.

(Jetzt fehlt mir noch noch eine (BASCOM-)Routiene um (fast) jeden
IR-Code einer Fernbedienung zu erkennen)

Jetzt haben sich unsere Beiträge überschnitten.
Ich könnte also aus einem externen EEPROM oder SD/MMC-Karte
"irgendwie" die Bytes direkt in den 64k-Speicher laden und dein
Programm kümmert sich dann um die TV-Ausgabe?

Somit würde der Umweg über UART ja schonmal wegfallen, wa wieder Zeit
sparen würde.

Das ist doch völlig ausreichend. Nur um eins vorweg zu nehmen, ich
versuch grad ähnliches, allerdings mit 2 externem angesteuerten 128kb
sram, da kannst du den einen in ruhe beschreiben, und dann einfach
umschalten. da ich allerdings keine ahnung von CPLD hab wird das ganze
vorerst in nem TTL grab enden.... :-))

Das programm macht ja nur sync und sram hochzählen - ansich eigentlich
nicht viel. soweit ich den schaltplan von benedikt gesehen hab müsstest
du dann die prots vom avr open schalten, damit du im prinzip "extern"
darauf zu greifen kannst. für diese zeit hast du keinen bildaufbau.
deshalb finde ich den weg über die uart des avr eigentlich am
elegantesten. evtl könnte man noch ne data request output haben, dass
man sieht, wenn der avr grad zu tun hat....

Direkt in der Speicher laden kann nur der AVR der das TV Bild erzeugt.
Das Auslesen einer SD ist aufwendiger als der Empfang über den UART.
Ich werde einen 256Bytes Empfangpuffer einbauen, um hohe Datenraten zu
ermöglichen (ich denke so an 100kBaud aufwärts). Damit sollte sich ein
Vollbild innerhalb von etwa 1s aufbauen lassen. Ich werde eine
Grafikfenesterfunktion einbauen, um schnell Bilder zu laden:
Man sendet die Koordinaten des Fensters und muss dann die
entsprechenden Bilddaten dafür senden. Dies ermöglicht das schnelle
Schreiben von Bildern ohne viel Overhead an Befehlen.
Dass man damit keine Fullscreen Filme darstellen kann, sollte klar
sein, aber einfache Menüs, Grafiken, oder kleinere, langsame
Animationen (so in der Richtung von Icons, also 32x32 Pixel) sollten
ruckelfrei möglich sein.
Immerhin hat ein Vollbild ja 64kByte, die auch erstmal erzeugt werden
müssen (falls diese nicht nur dumm aus einem Speicher geladen werden).

Hier eine erste Testversion. Diese hat mit Sicherheit noch eine Menge
Fehler, aber viele der Funktionen funktionieren bereits.
Baudrate ist 19200Baud, Quarz: 16MHz.

Hier noch der Befehlssatz.

Ansich würd mir persönlich eine Parallele anbindung alà HD4478 bzw.
ähnlich am besten gefallen. Wobei hier wahrscheinlich eher etwas anderes
herhalten muss weils Bunt und per Pixelel ist;)

naja rs232 kann jeder und so kannst du es auch an den pc anschließen...

Naja parallel, find ich persönlich leichter als Seriell, aber das ist
Geschmackssache.

Und am PC brauch ich nicht nen Fernseher als Display da hab ich schon
was
besseres mit höherer Auflösung dran hängen ;)

Parallel ist nur dann leichter, wenn man diesen als Hardwarebus zur
Verfügung hat. Da ich aber einen 8bit Bus Slave einbauen müsste (was in
Software absolut unmöglich ist mit einigermaßen gutem Timing), müsste
man einen Hardware Puffer mit Handshaking (= ein 1Byte großes FIFO)
einbauen, aber das erfordert zusätzliche Hardware die ich vermeiden
wollte.

Ok das mit dem Timing klappt in diesen Falle wahrscheinlich nicht so
gut, ansonsten wären die ext.-INT sicherlich für ein gutes Timing zu
missbrauchen.

An sich ja, aber:
Der ext Interrupt löst nur den Interrupt aus. Wann der AVR aber wirklich
dazu kommt, die Daten abzuholen weiß man nicht.
Man muss also entweder die Zeiten so langsam machen, dass der AVR auf
jedenfall dazu kommt die Daten zu laden, oder man baut Busy Flags ein.
Worst Case wird der Daten sendende AVR hier für 60uS ausgebremst, das
sind bei 16MHz immerhin fast 1000 Takte die verloren gehen. Da bei der
Grafikberechnung immer viel Rechenleistung notwendig ist, bremst sowas
unnötig aus.

Ich hatte bei meinem 640x480 LCD Controller anfangs mit diesem Interface
gespielt, aber es hat mehr gebremst als es genützt hätte.

Hat eigentlich irgendjemand mal eine fertige Platine davon
zusammengestellt? Ich wäre sehr daran interessiert mir eine zu
ätzen/kaufen!

Ich war dabei, habe aber einiges um die ohren zur zeit. Deshalb ist es
noch nicht ganz fertig...

Hallo,

ich habe Interesse das Projekt nachzubauen. Trotz Schaltplan habe ich
leider keine Stückliste gefunden.

Eigentlich fehlt mir nur die SRAM Bezeichnung. Außerdem wird ein zweites
SRAM erwähnt. Wo muss das denn hin?

Hat irgendjemand vieleicht eine Platine entworfen? Weiter unten im
Thread wurde etwas erwähnt aber scheinbar nicht weiterverfolgt.

Danke für die Hilfe.

Das SRAM ist ein normales 64kByte SRAM mit einer Zugriffszeit von <55ns.
Da man sowas nur schwer bekommt, verwende ich 2x 32kByte, bei denen alle
Pins direkt verbunden sind, außer CS\.
Da diese SRAMs nicht mehr hergestellt werden, habe ich keine
Bezeichnungen angegeben. Eine Alternative sind gößere SRAMs (z.B. die
55ns 512kB von Reichelt. Die sind etwas groß und werden großteils nicht
genutzt, aber dafür sind die noch zu bekommen. Die 55ns sind aber an der
Grenz. Meistens funktioniert das, manchmal kann es aber zu Problemen
kommen.)

Erst einmal vielen Dank für die schnelle, hilfreiche Information. Ich
werde mir die Teile jetzt mal zusammenbestellen und die Schaltung
nachbauen.

Wahrscheinlich wird da noch die eine oder andere Frage auftauchen. Mal
sehen :-)

Hi there,

I just built the GraKa, however, I am having troubles to get it run.
Could somebody please help with connecting it to SCART connector? I have
connected:
 - 5, 9, 13, 17, 18, 21 to ground
 - 7, 11, 15 to RGB outputs of the GraKa
 - 16 to 2.5V (switch TV to RGB mode)
 - 19 to Composite SYNC via 470 ohm resistor

(I use scart "female" connector and a regular SCART cable to connect to
TV set).

The screen shows some noise when the circuit is switched on and then it
goes blue like no signal is present.

I will be very grateful for any help.

Jakub

Composite Sync should be connected to pin 20 (video in).

Hallo zusammen,

habe mir alles genau durchgelesen und habe noch eine Frage wegen dem
SRam.

Habe zuhause noch zwei IS61C256AH-15N gefunden, im Datenblatt steht
32K x 8 Low Voltage CMOS Static Ram.

Jetzt meine Frage, hat der nun 256k oder nur 32k.

Besten Dank zum voraus für eure Hilfe.

Beat

32kByte * 8 = 256kBit.
Hersteller geben gerne die Bits an, da das nach mehr ausschaut.

Danke erstmals,

Das bedeutet ich müsste auch 2 vom Typ IS61C256AH-15N nehmen das es
Funktioniert.

Ja, genau.

Danke vielmals für deine schnelle Antwort.

Hier meine Umsetzung der Grafikkarte.
Da ich keine Lust hatte das ganze auf Lochraster oder sowas aufzubauen
und auch keinen DIL 8515 mahr da hatte hab ich mal schnell ne kleine
Platine für gemacht. Funzt soweit auch 1a, gibt nur irgendwie noch nen
kleinen Bug in der Farbwiedergabe. Die Wiederstände hab ich mittlerweile
mehrfach kontrolliert. Vllt hat einer von euch ne Idee wo der Fehler
stecken könnte.

Bild2

Bild3

und Bild4.
Hier ist auch gut zu sehen das die Farben nicht ganz passen.
Die Farben der Schrift oben im Bild sollten von dunkel nach hell gehen.
Irgendwie scheint in der Mitte aber ein Sprung zu sein!?

Ich sehe gerade: In der Schaltung habe ich zwei Widerstände vertauscht:
R7 und R8.
Die Widerstände müssen jeweils von oben nach unten 1,3k, 660, 330 sein.
Das dürfte die Fehler bei den roten Farben erklären.

Hmm, ich glaub da muss noch irgendwo ein Fehler sein. Wiederstände
getauscht aber immernoch sehr komische Farben. Hab jetzt testweise mal
immer nur eine Farbe angeklemmt. Achso, anstelle der 660 Ohm hab ich 680
genommen. Aber so extrem sollte sich das nicht auswirken, oder?
Irgendwie scheints mir das ein Bit von grün mit in die anderen Farben
reinspielt.

grün

blau

Hier noch der Schaltplan.

und Layout.

Ersetze mal in der tv.h die #define RGB Zeile durch das hier:
#define RGB(R,G,B)  ((R/64)|((G&224)/8)|(B&224))

Prima :)
Mal abgesehen davon das R jetzt anscheinend 2 und B dafür 3 Bit hat,
schaut das auf jeden Fall besser aus.

Ist das Commando 16 "Bild laden an Position" schon eingebaut? Weil
irgendwie kommt da nix :(
Könntest du evtl. den Source mit der Seriellen Geschichte
"veröffentlichen"?

Trotzdem an dieser stelle nochmal. Danke, prima Projekt :)

Hier ist die ganze Software. Wenn ich mir den Quellcode anschaue, dann
sollte es eigentlich funktionieren.

@Benedikt:

Was denkst du auf wieviel mann die Baudrate hochstellen kann? Bei
Versuchen 1M kahm nur noch Datenmüll an :) 38,4k scheint auf jeden Fall
noch anständig zu laufen. Wäre ersatzweise eine übertragung über SPI
oder vllt. Parallel (wie bei deinem LCD Controller) denkbar? Auf was
liesse sich die Datenrate ca. maximal hochschrauben?

Das Problem bei hohen Geschwindigkeite ist, dass der AVR bei komplexeren
Operationen (löschen, Linien Zeichnen usw.) dann nicht nachkommt.
Man müsste dann ein Busy Flag einbauen.
SPI sollte ähnlich wie der UART laufen, aber man benötigt halt auch ein
Busy Flag.
Für parallel mache ich das meist so wie im Anhang.
Linke Seite ist der Eingang, die rechte geht zum AVR. Das ganze ist ein
1 Byte FIFO. Da kann man Daten reinschreiben, und der AVR kann sich die
abholen. Solange das Byte noch nicht gelesen wurde, ist BUSY high und
man darf keine weiteren Daten schreiben.

@Benedikt

Im Prinzip würde ich die "2D Beschleuniger" Funktionen garnicht
benötigen. Es  reicht das direkte schreiben in den Grafikspeicher, evtl
noch die Zeichenausgabe.
Wenn ich mir das recht überlege sollte eine Kombination aus Busy Flag
"Leiitung" und schneller serieller übertragung (1M?) auch funktionieren.
Ich denke schneller wäre das über Parallel dann auch nicht.

Hallo Leute

Gestern habe ich die Grafikkarte fertiggebaut. Nur hat sich wiederinemal
nichts getan. Ich habe alle Leitungen und Pins kontrolliert, und alles
passt.

Ich habe versucht das Prorgamm für den Atmega8515 auf den Atmega128
umzuschreiben. Eigantlich habe ich alles gelassen bis auf:

 DDRE=(1 << PE1)|(1 << PE0);
   DDRB=(1<<PB6); 
     

Da der PWM Ausgang bei dem 128 auf Port B6 ist.
Und bei Port e wollte ich nur die PE1 und PE2 als ausgang setzten, damit
ich die anden pins noch verwenden kann.

Bei durchschauen des Quellcodes ist mit aufegafalle, dass ich nirgendwo
den PortA und den PortC finde.

Kann mir jemand weiterhelfen?

Mfg Daniel

Das Problem am mega128 ist, dass dieser mehr internes RAM hat. Die
Auflösung reduziert sich daher auf 256x239.
U.a. muss
ldi ZH, 4
durch
ldi ZH, 17
in der TVGEN.S ersetzt werden, und
#define YSize    252
durch
#define YSize    239

Benedikt danke für deine Antwort.

Aber warum ist die Auflösung kleiner, wenn der Atmega128 mehr RAM hat?

Dann habe ich noch eine Frage bezüglich des makefile:

Der Atmega8515 habe ich auf Atmega128 umgeschrieben.
Dann habe ich geschaut ob alle C Dateinen eingebunden sind, das passt ja
auch.
Nur habe die die Assemblerdatei dort nirgndwo gefunden.
Jedesmal wenn ich die hineinschreibe verschwindet die?

Was stimmt dabei nicht?

Mfg Daniel

Daniel wrote:
> Aber warum ist die Auflösung kleiner, wenn der Atmega128 mehr RAM hat?

Die Software kann nur das externe RAM nutzen. Mehr internes RAM ->
weniger externes.

> Nur habe die die Assemblerdatei dort nirgndwo gefunden.
> Jedesmal wenn ich die hineinschreibe verschwindet die?
>
> Was stimmt dabei nicht?

Du schreibst das .S klein ?

Bei tvgen.S schreibe ich das S groß. Steht ja explitzit drinnen, dass
man es groß schreiben soll.

Die Ports habe ich so beschaltet gelassen, wie du es gemacht hast.
Passt das auch so bei den Atmega128?

Mfg Daniel

Keine Ahnung wiso die .S bei dir immer verschwindet.

Schau mal nach, ob die Timereinstellungen und die für das externe
Speichereinterface genauso sind wie beim mega8515.
Und in der tv.c/h muss jeweils auch noch die Bildgröße von 252 in 239
geändert werden.

Dann sollte es eigentlich funktionieren.

>Keine Ahnung wiso die .S bei dir immer verschwindet.

So ein AHA Erlebnis hatte ich auch gerade mit einem
eigenen Projekt.

Dateien mit name.S werden merkwürdigerweise einfach gelöscht.
Dateien mit name.s werden korrekt behandelt.

Muss wohl an der Compiler Version liegen. Meiner 20070525
In meinem makefile steht jedenfalls nichts was dies
tun würde. Zumindest finde ich nichts.

Hallo

Das mit dem Makefile hat sich schon erledigt.

Für den SRAM Ist der adress und datenbus der gleiche.
Nur ist ALE, WR, RD au