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
@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.
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.
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.
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.
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:
1 | DDRE=(1 << PE1)|(1 << PE0); |
2 | 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 auf andern Pins. Das ALE ist bei Atmega128 auf PG2, WR auf PG0 und RD auf PG1. Bei ALE gibt es den richtigen Steuertakt. Nur ist bei WR und RD kein Siganl zu erkennen. Und bei dem Vsync bei PB6 auch nichts richtiges. Im Anhang ist der modifizierte Quellcode für den Atmega128 enthalten. Es währe sehr nett, wenn sich jemand den Quellcode durchsieht. Mfg Daniel
in tv.c: const fram pixel = (fram)0x0400; durch const fram pixel = (fram)0x1100; ersetzen. Ansonsten fällt mir jetzt erstmal nichts auf.
Hallo Kann es sein, dass ich im tvgen.S etwas noch bezüglich der Ports etwas ändern sollte? Assembler kann ich noch nicht so gut programmieren. Was bedeutet:
1 | cbi _SFR_IO_ADDR(PORTE), 0 |
und
1 | sbi _SFR_IO_ADDR(PORTE),0 |
Mfg Daniel
PortE Bit 0 auf 0 und PortE Bit 0 auf 1 Wobei dies nur das Blanking Signal ist. Interessant ist eigentlich nur das CSync Signal am Ausgang OCR1B
Was ich noch als Frage hätte: Mir ist aufgefalle, dass auf deinem Schaltplan PA7 über den latch mit A0 des SRAM verbunden ist. Sollte das nicht PA7 mit A7 verbunden werden? Das gilt auch für die anderen pins. PC7 ist auch so umgekehrt angeschlossen. Mich verwundert das, weil der eine (bunte) Schaltplan, der hier aufgetreten ist, wieder anders beschalten ist. Mfg Daniel
Ich versuchs mal so zu erklären: Wo du dein Auto auf dem Parkplatz parkst ist egal, solange du am Ende wieder mit dem richtigen heimfährst. Wo die Daten im RAM gespeichert werde ist vollkommen egal, solange sie nur wieder richtig ausgelesen werden.
Danke für die Antwort, Ich werde mich heute noch einmal hinsetzen und die Datenblätter bezüglich der PWM und der Timer vergleichen. Vielleicht finde ich noch Unterschiede. Mfg Daniel
Hi Benedikt, eine Frage: Wie konvertierst du die Bilder, dass die Farben mit der Widerstandsmatrix übereinstimmen?
Welche Bilder? Die Darstellungen sind alle auf dem AVR berechnet. Das TV Signal habe ich dann mit einer TV Karte aufgezeichnet.
@Benedikt K. da ja jemand den Thread rausgekramt hat und ich ein paar Rams rumliegen habe.... Ein paar Sachen verstehe ich mal wieder nicht: Im Infotext aus FarbTV_HL_Source.zip schreibst Du: in der nächsten Version.. wird die Firmware noch verbessert? in Graphikc benutzt Du #include "s1d13506.h" warum? was mach ich mit dem Busy Flag? Schön wäre noch mal eine aktuelle Schaltung. Beanke mich mal schon für Deine Mühe. Wigbert
Wigbert Picht-dl1atw wrote: > Ein paar Sachen verstehe ich mal wieder nicht: > Im Infotext aus FarbTV_HL_Source.zip schreibst Du: in der nächsten > Version.. > wird die Firmware noch verbessert? Momentan habe ich das Projekt etwas aus Eis gelegt, da ich mittlerweile etliche richtige LCD/CRT Controller habe. Und 800x600 mit 16bpp sieht doch gleich viel schöner aus, als 256x250 Pixel bei 8bpp. > in Graphikc benutzt Du #include "s1d13506.h" warum? Ist ein Fehler. Ich habe die Grafikroutinen von einem Projekt mit dem S1D13506 genommen, und vergessen den Header zu entfernen. > was mach ich mit dem Busy Flag? Abfragen bevor du einen Befehl sendest. Busy wird gesetzt, wenn der Befehlsbuffer fast voll ist.
Wieso wird ein 100 Ohm Widerstand parallel zum TV-internen 75 Ohm Widerstand geschaltet? Könnte man diesen weglassen, wenn man die Widerstände an den Ausgängen des 74HC574 entsprechend anpasst (z.B. 681, 1430 für blau)? Oder dient der 100 Ohm Widerstand nicht bloss zur Einstellung der korrekten Spannung? Vielen Dank im voraus.
Ich denke mal, der Widerstand zieht den Farbkanal auf GND. Würde man ihn weglassen und IC1 Hochohmig schalten, wäre der Pegel nicht definiert.
Klingt plausibel. Vielen Dank für die Antwort!
Hey Leute! Ich habe das Projekt jetzt selber mal nachgebaut und bin echt beeindruckt. Ich hab aber noch ein paar Fragen. Wie sieht das ganze aus wenn man ne zweite CPU mit einbindet? Also quasi das ganze Projekt als "GPU" verwendet.Wie könnten diese beiden am schnellsten kommunizieren? Und wie kompliziert wäre es.. Tiles und Sprites zu realisieren? Wäre es besser die GPU würde das selber machen..Also das sie nur ne Art Tilenummer bekommt und auf ne Tiledatenbank zugreifen muss oder sollte dies Pixel für Pixel über die CPU gehen?.. Schon mal Danke im Voraus MfG Georg
Hey, Ich versuch das ganze gerade an ne Scart Female Buchse anzulöten... Die 1-3V RGB Steuerspannung hab ich versucht durch nen Spannungsteiler anzulegen. Zwei 680 ohm Wid. in Serie.Es liegen schöne 2.5V im Mittelpunkt an. Der Eingangswid beträgt ja 75ohm.. also müsste doch bei Belastung bisschen mehr als 2.5V anliegen. Tut es aber nicht... Liegen diese 75ohm in serie oder parallel zur Masse? Ich nehm an parallel.. Ist dieser Aufbau legitim oder hab ich nen Denkfehler gemacht? Der 470ohm Widerstand liegt in Serie in der Synchleitung und bildet dann mit dem Eingangswiderstand(75ohm) einen Spannungsteiler. Stimmt das so? Wenn ich jetzt mit einem Multimeter diese Spannungen messe bekomme ich dann diese errechneten Spannungen oder wird das Ergebnis verfälscht weil noch andere Bauteile im Fernseher die Spannung beeinflussen? Der Grund warum ich frage ist, das ich einfach nichts am Fernseher sehe.. und verzweifelt auf Fehlersuche bin... Kein Flimmern oder sonst irgendwas.. so als würde kein Signal anliegen.
Salut, ich wollte mal "Danke" sagen! Ich habe diesen alten Thread gefunden, weil ich für ein Projekt eine einfache und belastbare Grafiklösung suchte. Es geht dabei um eine AVR-Testlösung auf Basis der Elektronik-Experimentierkästen, die in den 80er Jahren von Philips und Schuco verkauft wurden. Ich wollte einmal sehen, wie man so eine Exoerimentierlösung mit aktueller Technik verbindet, und herausgekommen ist eine Kombination aus der hier vorgestellten Grafiklösung und eines Touchscreen-Displays. Ich habe die Grafik dazu etwas weiterentwickelt - sie ermöglicht bei mir das einfache Darstellen von Touch-Tastaturen, Menüs, Mess- und Zeichenfunktionen. Ich habe auch einen größeren RAM-Baustein eingesetzt und damit eine Umschaltung mehrerer Grafikseiten eingebaut. Damit kann man beispielsweise während der Messwerterfassung eine Dialogbox zeigen, ohne dass der Bildinhalt verloren geht. Der genutzte resistive Touchscreen nutzt die Codes, die bei Atmel verfügbar sind. Er wird aber von der Grafik mit Informationen versorgt und berechnet bereits Felder, wenn die Grafik Schaltflächen darstellt. Er sendet dann serielle Kommandos an den eigentlichen Experimentier-Prozessor. Ich stelle hier einmal die Sourcecodes für Grafik, Touchscreen und das von mir geschriebene Demoprogramm ein - sie basieren ja teilweise auf dem hier vorgestellten Projekt. Ein paar mehr Fotos gibt's auf meiner Blog-Webseite unter www.53cent.de/Elektronik. Bei Interesse berichte ich gern mehr davon. Grüße, JL7
Hallo Frank MENSCH! Tolles Retro-Projekt! Ich schwelge in Erinnerungen. Ich habe diesen Philips-Kram geliebt, obwohl ich nur die originalen Transistoren-Platinchen hatte, die auch nie lange überlebt haben (aus der vor-avr-zeit) Gruß Markus
Benedikt schrieb: > Diese Schaltung ermöglicht die Darstellung von Farbbildern auf einem TV. Hi Benedikt, das ist genau das, was ich gerne hätte! Super Idee und Arbeit, dein Bild vom Display und das Video sind der Kracher! Sorry für das Aufwärmen des Threads, aber ich verstehe halt nicht alles, deswegen, hoffe Du magst helfen, bin neu in der Materie. Mein Ziel: Ich möchte gerne von einem Master aus einen Slave benutzen, um auf einem Fernseher farblich Texte und Grafiken darzustellen, Bildschirmschoner. Die Ansteuerungs-Frequenz hierbei ist ein Lachsack, ich will einfach von einer Fernbedienung aus den Fernseher als Display nutzen, so netter C64 oder Amiga-Style. Deine Bilder sind top. Mein Problem: Ich habe mir deine Projektdaten runtergeladen, im ersten Archiv ist ein Schaltbild, aber ich sehe nicht, wie ich den Controller über UART ansteuern kann. Später kommt dann ein super vielversprechendes PDF für die Ansteuerbefehle. Ich weiß halt nicht, wie die vollständige Platine aussieht.. Meine Bitte: Hast Du einen vollständigen Schaltplan, ein Layout - und deine aktuellen Sourcen? Ich nutze gerade Atmel Studio 6.0, aber das dürfte wurscht sein, das krieg ich schon hin. Nur beim Schaltbild habe ich die Fragezeichen, und vielleicht hast ja auch noch nen Tipp für die Bestückung, ist ja paar Jahre her. Danke und liebe Grüße, Jens
Benedikt K. schrieb: Seltsam, ich wollte auf deinen Thread was schreiben, aber da stand noch "Gast", daher hat jetzt "Benedikt" was geschrieben, lieb schief, also nochmal, den anderen kannst löschen: > Diese Schaltung ermöglicht die Darstellung von Farbbildern auf einem TV. Hi Benedikt, das ist genau das, was ich gerne hätte! Super Idee und Arbeit, dein Bild vom Display und das Video sind der Kracher! Sorry für das Aufwärmen des Threads, aber ich verstehe halt nicht alles, deswegen, hoffe Du magst helfen, bin neu in der Materie. Mein Ziel: Ich möchte gerne von einem Master aus einen Slave benutzen, um auf einem Fernseher farblich Texte und Grafiken darzustellen, Bildschirmschoner. Die Ansteuerungs-Frequenz hierbei ist ein Lachsack, ich will einfach von einer Fernbedienung aus den Fernseher als Display nutzen, so netter C64 oder Amiga-Style. Deine Bilder sind top. Mein Problem: Ich habe mir deine Projektdaten runtergeladen, im ersten Archiv ist ein Schaltbild, aber ich sehe nicht, wie ich den Controller über UART ansteuern kann. Später kommt dann ein super vielversprechendes PDF für die Ansteuerbefehle. Ich weiß halt nicht, wie die vollständige Platine aussieht.. Meine Bitte: Hast Du einen vollständigen Schaltplan, ein Layout - und deine aktuellen Sourcen? Ich nutze gerade Atmel Studio 6.0, aber das dürfte wurscht sein, das krieg ich schon hin. Nur beim Schaltbild habe ich die Fragezeichen, und vielleicht hast ja auch noch nen Tipp für die Bestückung, ist ja paar Jahre her. Danke und liebe Grüße, Jens
Salut Jens, da ich wahrscheinlich der zeitlich letzte bin, der sich mit dem Projekt auseinandergesetzt hat, kannst Du auch meine Sourcen (siehe oben) anschauen. Ich habe auch Schaltplan und Ansteuerung für Dich. Melde dich, wenn Du Interesse hast. Grüße, JL7
Hey Frank, habe Dir schon eine E-Mail geschickt, klar, definitives Interesse! LG, Jens
Frank Brennecke schrieb: > Melde dich, wenn Du Interesse hast. > > Grüße, JL7 Hey JL7, Du hast sicher alles mögliche zu tun, aber magst mir die Daten noch geben? Danke im Voraus! LG, Jens
Hi Jens, hast ne Mail von mir bekommen. Für alle anderen: Detaillierte Infos über die Funktionen und was sie können, findest man hier: http://www.brennecke.org/?page_id=2396 und speziell zu den weiterentwickelten Funktionen: http://www.brennecke.org/?page_id=2524 Grüße, Frank
Bitte 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.