Announcement: there is an English version of this forum on Da mein Testbild ect. nun funzt, dachte ich mir das man nun auch mal ein Spiel entwickeln könnte. Immerhin muss man dies blöde Pong mit dem scheiss PIC ja endlich mal zeigen wo der Hammer hängt :-) http://mitglied.lycos.de/polyxos/tv12.jpg http://mitglied.lycos.de/polyxos/tv13.jpg
Hi! Habe Deinen Thread und auch den externen beobachtet und Du hast das Testbild im Main-Prog mit Warteschleifen gemacht! Meinen gehörigen Respeckt dafür aber hast Du das mittlerweile per Timer-Interrupt umgestellt? Das würde die "Einbindung" des Spieles in das Programm vereinfachen da ja schon ein paar Dinge wie Figurensteuerung, Tastenabfrage, Kollisionstest (Figurpositionen) etc. noch hinzukommen. Hatte einen anderen Thread mit nen Mega32 gesehen wo die TV-Ausgabe über den Timer-ISR funxionierte. MfG Andi
Das mit dem Timer kann man wohl vergessen, da man die Unterroutinen nicht exakt bestimmen kann und der Timer gnadenlos zuschlagen könnte. Desweiteren wüsst ich nicht wozu der Timer da sein sollte (Hsync) ? Ich mach es einfach so, Ich habe für alles kleine Unterroutinen geschrieben welche in einem Hauptfenster aufgerufen werden können. Also 308 Zeilen.ich habe pro Zeile sogesehen immer 824 Takte zur freien verfügung. Also mach ich in Zeilen wo nichts kommt einfach meine Unterroutinen rein. Z.B. Steuerung, Punktewertung, Kollesionsabfrage ect.... Durch verzerrungen im Bild sehe ich dann schon ob die Routinen perfekt getimt sind. Wenn jetzt der Hsync vom Timer kommen würde, wüsst ich ja nie ob eine Unterroutine wirklich schon abgearbeitet wurde ect. Und ein teiler bei 16MHz zu finden für 52µs ist glaube ich nicht möglich....
Dann benutze doch einen anderen Quarz wie z. B. 18,irgendwas. Irgend einer müßte doch zu finden sein. Vom Ablauf her dachte ich an Main-Prog mit dem Spiel und abfrage von V-Sync für das "Neuzeichnen" der Ausgabegrafik etc. Die Timer-ISR soll dann immer eine ganze Grafikzeile ausgeben (mittels Zeilenzähler) und wenn die Zeile ausgegeben ist, den Strahl auf 0 stellen und dann raus aus dem Timer. In dieser Dunkelphase läuft das Main-Prog weiter und kann dann verschiedene Berechnungen machen. In 820 Takten je Zeile läßt sich ja einiges machen. Das interne V-Sync kann die Timer-ISR liefern wenn die letzte Zeile ausgegeben wurde. Das Main-Prog erzeugt die Grafik im internen SRAM des AVR (Mega32 mit 2KB) wobei die Auflösung leider nicht sehr hoch sein kann (128x96, 1 Bit). Man kann ja noch externen SRAM anbinden und vielleicht in Farbe senden. MfG Andi
Na wenn ich nur die Dunkelphase nutzen soll für das Hauptprogramm, bleibt ja gar nichts mehr über. Da nutze ich doch lieber komplette Dunkelzeilen um meine Routinen da unter zu bekommen. Zumal es dann schön nach einem Baukastenprinzip aufgebaut ist und man die Module wechseln kann ohne probleme.
Das habe ich doch beschrieben. Jedes mal, nach dem eine Zeile im Timer ausgegeben wurde, kann das Main-Prog weiter arbeiten. Also nicht nur im V-Sync. Mit einem internen V-Sync nach Ausgabe der letzten Zeile läßt sich vom Main feststellen, wann das neue Bild (1/50el) beginnt und die Grafik im SRAM neu setzen, oder nur Teilbereiche. Die Zeilenausgabe ist doch sehr Zeitkritisch und mit nen Timer wird sichergestellt, das jede Zeile im richtigen Moment ausgegeben wird. Im Main-Prog kann dann sein was will und man braucht keine Takte im Main abzuzählen. Es sollte ja nur ein Wink sein um es geschickter zu machen. MfG Andi
Ist das Problem des IRQs nicht das, dass er unterschiedlich lang braucht, um aufgerufen zu werden? Abhängig vom gerade bearbeiteten Befehl?
@kryon2000: Ja, es gibt schon was reallisiertes. Habe hier vor Monaten mal was gesehen, such mal nach mega32 und TV oder so was. @Andi: Klar, wenn der Timer bei einen Befehl mit 2 Takten nach dem 1. Tackt kommt verschiebt es das natürlich bei 16MHz um 0,062µS. Ob das was aus macht, weis ich nicht, denke aber nicht. MfG Andi
Also alle Links die ich bis jetzt dazu gesehen habe waren eher lächerlich. Die kamen nie auf die Grafikpower die dieses Projekt besitzt. Aber wenn es doch was dazu gibt bin ich für jeden Link dankbar..... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Klar, wenn der Timer bei einen Befehl mit 2 Takten nach dem 1. Tackt kommt verschiebt es das natürlich bei 16MHz um 0,062µS. Ob das was aus macht, weis ich nicht, denke aber nicht. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Oha.....hast du eine Ahnung was selbst 1 Takt für eine Auswirkung hat. siehe hier: http://mitglied.lycos.de/polyxos/tv2.jpg Das sollten normal nur rechtecke sein, ein Takt verkehrt und das kommt dabei raus ;)
PS: Also die hauptroutine bei mein Pacman sieht z.Z. so aus: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ video: vid2: ;----start Videosignalerzeugung------------------------------------ rcall vsync ldi r18, 0x8a ;416 takte ( halbe Zeile) sh21: dec r18 brne sh21 nop nop rcall hsync ;------------------------------------------------------- ;------------ Bildaufbau ------------------------------ ldi r17, 0x03 pau1: dec r17 brne pau1 ldi r18, 0x30 rcall linecl nop nop nop rcall pacman nop ;-------------------------- 0x12 ldi YH, High(logo * 2) ldi YL, LOW(logo * 2) rcall textfeld nop nop ldi r18, 0x0e rcall linecl nop ldi YH, 0x04 ldi YL, 0x00 rcall ghost nop ldi YH, 0x04 ldi YL, 0x08 rcall ghost nop ldi YH, 0x04 ldi YL, 0x10 rcall ghost nop ldi YH, 0x04 ldi YL, 0x18 rcall ghost nop ;-------------------------- 0x80 ldi YH, 0x02 ldi YL, 0x00 rcall spielfeld nop nop ldi r18, 0x10 rcall linecl nop ;-------------------------- 0xb ldi YH, 0x00 ldi YL, 0x60 rcall ktextfeld nop nop ldi r18, 0x4 rcall linecl nop nop nop rcall time nop ;-------------------------- 0xb ldi YH, 0x00 ldi YL, 0x80 rcall ktextfeld nop nop ldi r18, 0x35 rcall linecl rjmp video ;------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Also schön in seine Module aufgeteilt. linecl = leere zeilen (r18=anzahl) ktextfeld = Ausgabe einer 32 Zeichen Zeile YH YL = adresse im RAM textfeld = Ausgabe einer 32 Zeichen doppelte höhe Zeile YH YL = adresse im Flash spielfeld = Ausgabe des 128x128 pixel Spielfeldes ghost = Bewegung des geistes YH YL = Speicher der Koordinaten der geister pacman = abfrage der steuerung und setzen von Pacman
Na ja, läßt sich theoretisch geschickt per Software ausgleichen in dem man in der Timer-ISR vor Ausgabe einer Zeile den Timer-Wert ausliest. Z. B. wenn der Timer mit dem µC-Takt mit läuft den Timer auf verschiedene Werte prüfen und, im Sinne der max. Timer-Aufruf-Verzögerung, je nach Timer-Wert 1, 2 NOP´s einfügen oder keins. MfG Andi
aber verschwendet man durch den check dann nicht auch wertvolle zeit in der man vielleicht schon was zeichnen sollte? :)
Zumal anhand welcher werte soll der Timer wissen ob er nun genau richtig unterbrochen hat oder ein paar takte später ? Dies könne er nur durch ein 2 Timer der wiederum werte irgendwo rein schreibt überprüfen, und auch dieser weiss nicht ob er genau richtig unterbrochen hat usw usw..... Ein link zu solch einem Projekt würde klarheit verschaffen, aber anscheinend existiert sowas ja nicht ;-) Naja, was solls, anstatt hier darüber zu Phillosophieren ob Timer ja oder nein, nähert sich mein Pacman dem Ende zu. Noch ein paar Bugs beheben und dann ist es fertig :-))))))
Hier gibt es hunderte an Projekten, alle mit einem AVR und einem TV als Ausgabe. Die fertigen Ausgabe Routinen in Assembler gibt es hier, der Rest des Programms lässt sich in C schreiben. http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/
Naja, allsamt baut es auf den Cornell University Electrical Engineering 476 Video Generation Code auf. Was soll man davon halten. Desweiteren sind diese Games unsauber Programmiert. Wenn man sich die Videos anschaut kommt es bei Screenwechsel zu Sync ausfall. Sowas sollte man ja nun auf jedenfall vermeiden.
Wenn Du meinst, Du schaffst es, einen Spielablauf zusammen mit der Zeilenausgabe zu mischen, dann nur zu. In einem vom Benutzer steuerbaren Programm (Spiel) gibt es X-Beliebig verschiedene Situationen die dann beachtet werden müssen. Zum einen muss immer ein Teil des Spielfeldes ausgegeben werden welches sich auch verändert. Mal ist ein Punkt an einer Stelle, mal ist keiner (Weggefressen vom PacMan). Mal ist in einer Zeile nur der PacMan, mal ist noch 1 Geist auf gleicher Höhe und mal vielleicht sogar alle 4 und der PacMan. Du mußt dann alle verschiedenen Möglichkeiten bei jeder Ausgabezeile mit einbeziehen und dabei darf es keinen Takt zuviel oder zuwenig werden. Die Steuerung kommt auch noch dazu wobei das in der V-Sync-Phase behandelt werden kann. Wenn Du das ohne irgend einem Interrupt hinbekommst und dann noch in 8 Graustufen, RESPEKT! Vielleicht noch mit Sound-Ausgabe mit der Zeilenfrequenz? MfG Andi
Hallo, das Problem beim Timing von Interupts beim AVR ist, das der beim Interupt gerade laufende Befehl noch zu Ende abgearbeitet wird. Das kann dann 1, 2 oder 3 Takte dauern. Das habe ich in einem Video-Projekt mal folgendermassen gelöst. Man kann die Timerinterupts auf zwei Arten betreiben: Einmal so, das der Int ausgelöst wird, wenn der Timer bis max gezählt hat und überläuft (Timer OVF), und einmal so, das der Int auslöst wenn der Timer einen bestimmten Wert erreicht hat(Timer Compare Match). Dafür gibt es zwei unterschiedliche Int-Service Adressen. Das habe ich kombiniert. Um z.B exact 52us zu bekommen, setze ich den Timer zunächst so, das er nach 46us überläuft und einen "Vor-Int" auslöst. (OVF-INT) Der reisst den AVR asyncron aus dem Hauptprogramm, der Timer läuft inzwischen weiter über Null hinaus vorwärts weiter. In der Int-Service Routine schalte ich die Timer Betriebsart um, so das noch ein Int ausgelöst wird, beim Erreichen des Wertes, der 52us entspricht. (Comp-Match-Int) Dann gebe ich die Interupts wieder frei und laufe in eine Kette aus NOPs, die alle genau einen Takt lang sind. (kein reti!!) Bei 52us wird diese Kette unterbrochen, und es wird die andere Timer Int-Routinte aufgerufen. Diese muss jetzt den Timer wieder neu setzen und umschalten und - ganz wichtig - die "falsche" INT-Rücksprungadresse vom Stack "poppen", damit die erste "richtige" Rücksprungadresse wieder wirksam wird. Der "Trick" beruht darauf, das der Timer weiterläuft, egal ob der "Vor-Int" nach 1 2 oder 3 Takten ausgelöst wird, und das der zweite INT aus der NOP-Kette immer zum nächsten Takt ausgelöst wird. Ich hoffe, das ist einigermassen verständlich. Mfg Willi
@andi Lass dich überraschen ;) Das Spiel läuft schon super sauber und das beste, egal wieviele Geister ich hinzaubere (kann man nacher bei jedem level selber deffenieren) ist kein einziger verzug zu sehen. Alles ist perfekt getimt. Dank der Modularen bauweise. Kommt ein geist hinzu, wird eben eine Zeile weg genommen (linecl) und mit dem Modul GHOST belegt. Ich kämpfe jetzt nur noch mit dem Problem des Spielablaufs. Wie z.B. Schwirigkeitsgrad. Ich wollte es erst per Regelwiederstand lösen, so dass man wärend des Spiels den Grad erhöhen oder erniedrigen kann, jedoch werde ich dies wohl wieder verwerfen. Nebenbei, Ich nehme keine Graustufen, es wird also nur ein Pixelwert geben. Die Graustufen sind nur für den Modus TESTBILD. @Willi Gute Lösung, respekt. Jedoch werde ich sowas nie nutzen, da ich bei einem Screenwechsel keine Sync Unterbrechung haben will, und bei Hsync über Timer wird es wohl darauf hinauslaufen denke ich.
Hi kryon2000! Na dann viel Erfolg mit Deinem Spiel. Ich hoffe, Du machst es gleich gescheit, also die Figuren als so ne Art Sprites bzw. Shapes welche Pixelweise über den Screen bewegt werden. MfG Andi
@kryon2000: Auch von mir höchsten Respekt vor dieser Leistung, ich beschäftige mich auch ein wenig mit dieser Thematik, allerdings nur für ein OSD-Display mit etwa 24 Zeilen zu 40 Zeichen und "abgedunkeltem" Hintergrundbild. Von daher trau ich mich abzuschätzen welch Aufwand hinter deinem Projekt steht und wie "lahm" die avrs sind ;-) @willi: Dein Ansatz ist schon fast perfekt, die Unsauberkeit mit den verdrehten Rücksprungadressen hast du ja selbst erwähnt. Ich habe das Problem dadurch gelöst dass ich den avr kurz (ca. 1us) vor dem nächsten Zeilenbeginn schlafen schicke, damit kommt der nächste Int. bzw. Syncbeginn mit einer konstanten Verzögerung. @all: weiter oben wurde in Frage gestellt ob man die unterschiedlichen Int.Aufrufzeiten im Videobild sieht? -> Ja, die 62.5ns sind auf einem mittelgroßen Monitor fast ein halber Millimeter Pixelbreite. Grüße leo9
@andi Na das mit den Sprites war doch wohl eher ein Witz. Immerhin reden wir hier von einem kleinen Mikrocontroller und nicht von einem Homecomputer ;-). Die Spielfläche ist zwar 128x128 pixel gross, aber denoch werden die Figuren des spieles wegen bei mir in 16x16 ASCII RAM gespeichert. @leo Bei den OSD Geschichten gibt es einen ganz grossen Vorteil, diese haben einen internen Speicher und man kann deshalb seine Routinen Zeitunkritisch gestalten und muss sich nicht noch auf die Bildausgabe konzentrieren. @all Also wenn einer hier dabei ist und sich die Schaltung auch gebaut hat (kosten ca. 10,-) den kann ich ja mal ne BETA Version zukommen lassen.
Das mit den "Sprites" war völlig ernst gemeint. Man müßte halt eine "Sprite-Line" eines Register in 3 Zellen/Register aufteilen und je nach Y-Position eine von 16 verschiedenen Laden, also jedes Ghost-Objekt wäre dann 16 mal vorhanden. Immerhin war es mir damals möglich, mehrere 16x16 Pixel Sprites auf nen AtariST darzstellen und zu steuern. Der MC68000 war zwar ein 32-Bitter lief dort aber auch nur mit 8MHz und die kleinste Ausführungszeit eines Befehles waren 2 Takte. Es sollte ja auch nur ein Anreiz sein. MfG Andi
Sorry, meinte natürlich, das jedes "Ghost-Objekt" 8 mal vorhanden sein müsste für eine Pixelweise-Verschiebung in der Horizontalen ohne großartige Bitschiebereien. Ach ja, mir ist schon klar, das beim damaligen AtariST die Bildausgabe was anderes übernommen hatte. MfG Andi
>> Bei den OSD Geschichten gibt es einen ganz grossen Vorteil
.. da hast du mich falsch verstanden, ich verwende den avr für die
gesamte Videogenerierung. OSD ist "nur" meine Anwendung, ich gebe
halt Text und keine Testbilder, Spielflächen aus.
Einen weiteren Vorteil des interrupt gesteuerten Timings ist die
(relativ) einfache Syncronisierbarkeit auf externe Videosignale. Ist
aber auch nur bei der OSD-Applikationen relevant. Spiele und Testbilder
werden wohl meist freilaufend verwendet.
grüße leo9
kryon2000, überlege Dir trotzdem mal das mit den Sprites! So lahm sind 16MHz nun auch wieder nicht. MfG
@leo Achso, ich dachte du parkst die Sachen extern irgendwo ;) 40x24 Zeichen ist echt super. Sind die Zeichen bei dir auch 5x7 Pixel ? Oder doch nur 3x5 ? Meine Zeichen sind alle 5x7 und da könnte ich glaube ich nicht auf 40 Zeichen pro Zeile kommen. Ich habe da nur 32 Zeichen. Siehe hier: http://mitglied.lycos.de/polyxos/tv7.jpg Das ganze Projekt dazu ist hier: http://mitglied.lycos.de/polyxos/video.htm Aber bei OSD mit ext. Sync Signalen ist es ja auch einfacher, man kann da ja jede Zeile auslaufen lassen und fängt einfach bei dem neuen sync Takt an. Sogesehen ext. Interrupt. OSD würde mich in dieser form auch mal interresieren. Hast du da eine Seite ???
@Andi K.: Beim Atari ST musste die CPU ja auch schließlich nicht das Timing für das Videosignal generieren.
So, nun kann es mit der ersten BETA mal los gehen, schnell noch den Steuerknüppel anlöten und dann mal testen. Da sitzt man immer stundenlang vor einem Problem und sieht den Wald vor lauter Bäumen nicht. Ich habe mich immer gewundert das nach einer Kollesion mit einem Geist das Rücksetzen der Figuren nie klappte. Und siehe da, mein häufigster Fehler den ich anscheinend immer wieder mache war es. ld r17, Z anstatt lpm r17, Z benutzt. Ich bekomme es wohl nie auf der Reihe zwischen Flash und RAM zu unterscheiden :-))))))) Habt ihr auch immer solche Standartfehler die ihr unbewusst immer wieder mal macht ?
Hallo kryon2000, Ich habe ein paar Fragen an dich: Hast du deine Seite per "Hand" geschrieben oder Hast du ein Programm dazu benutzt, wenn ja welches? Warum täuscht du vor, dass du auf deiner Seite mit einem Script eine .HEX-Datei erstellen kannst? cu
Nein, nein, er täuscht nix vor.
Hier ein Ausschnitt aus dem Java-Script zum einbinden der Laufschrift
und berechnen der Checksumme:
document.bestellung.card.value+=":100A6000000013E01A950000E9F746DD2A9531
F001\n";
document.bestellung.card.value+=":0E0A700013E01A95F1F700000000E1CF0895A1
\n";
for(rrr=0;rrr<60;rrr++){
a=0;document.bestellung.card.value+=":";
for(i=(rrr*20);i<(rrr*20+20);i++){dechex(i1key[i]);a+=i1key[i];document.
bestellung.card.value+=hexddd}
a&=0xFF;a=0x100-a;dechex(a);document.bestellung.card.value+=hexddd+"\n";
}
for(rrr=0;rrr<16;rrr++){
a=0;document.bestellung.card.value+=":";
for(i=(rrr*20);i<(rrr*20+20);i++){dechex(llauf[i]);a+=llauf[i];document.
bestellung.card.value+=hexddd}
a&=0xFF;a=0x100-a;dechex(a);document.bestellung.card.value+=hexddd+"\n";
}
document.bestellung.card.value+=":101E0000000000000000000020202020200020
0012\n";
document.bestellung.card.value+=":101E100050500000000000000050F85050F850
00F2\n";
document.bestellung.card.value+=":101E20002070A0702870200000881020408800
00DA\n";
document.bestellung.card.value+=":101E30006090A040A890680010200000000000
0002\n";
document.bestellung.card.value+=":101E4000182040404020180060100808081060
006A\n";
document.bestellung.card.value+=":101E500000A870F870A800000010107C101000
009E\n";
document.bestellung.card.value+=":101E60000000000010102000000000F8000000
003A\n";
document.bestellung.card.value+=":101E7000000000000000200000081020408000
004A\n";
document.bestellung.card.value+=":101E8000708898A8C888700020602020202070
00EA\n";
document.bestellung.card.value+=":101E9000708808304080F80070880830088870
002A\n";
document.bestellung.card.value+=":101EA00080809090F8101000F880F008088870
008A\n";
MfG
Andi
@fran2i Für meine HTML Seite benutze ich das kostenlose Programm NOTEPAD. Damit erstelle ich sowohl meine HTML, PHP und ASM Programme ;-) Ich täuche dort auch nichts vor, die Texte müssen ja in das HEX File rein und deshalb müssen die ASCII ersteinmal in ASCII-HEX gewandelt werden um dann in das HEX File integriert werden zu können. Und die HEX Files verlangen am ende eine Checksumme. Auch dies muss durch das Java Script generiert werden. Der erste und letzte Teil ist natürlich schon vordeffeniert und wird einfach ausgegeben.
Ich hab da ne kleine Frage ;) Gibst du den Quelltext noch frei? Will das auch mal ausprobiern.
Naja, ob dir mein Quelltext was bringt ??? Es stehen kaum kommentare drinn, eigentlich nur Takte hinter jedem Befehl.... Wie z.B: ;######### wandele Pointer Hex -> ASCII######################## pointer_ha: lds temp2, 0x00a0 ;2 lds temp1, 0x00a1 ;2 rcall bin16 ;424 ldi YH, 0x00 ;1 ldi YL, 0x16 ;1 ldi XH, 0x00 ;1 ldi XL, 0x67 ;1--- ti4: ld r0, -Y ;2 st X+, r0 ;2 35 cpi XL, 0x6C ;1 brne ti4 ;2--- ldi r17, 0x77 ;-------------- ti3: dec r17 ; pause 358 brne ti3 nop ;1------------ rcall hsync ;75 nop ;1 nop ;1 nop ;1 ret ;################################################################## Ob du da draus schlau wirst ? So, nun ist die BETA fertig: http://mitglied.lycos.de/polyxos/tv15.jpg http://mitglied.lycos.de/polyxos/tv14.jpg Jetzt muss ich noch ein paar Levels erstellen. Ein Level brauch 0x44 (68) Byte. Ich denke mal das ich 20 Level dort einbauen werde. Aber ersteinmal werde ich auch Sound einbinden. Das sollte ja einfach sein.
Kannst du mal ein Video drehen? Eine eigene Konsole gebaut haben sicher nicht soo viele. :-) P.S.: Zum Speed-> Kann man die AVRs oder wenigstens einige davon nicht auch bei 20Mhz laufen lassen? Bei deiner Programmierung wäre das Portieren auf einen schnelleren AVR etwas schwierig, oder?
Hier mal ein Video: http://mitglied.lycos.de/polyxos/pacman.avi RECHTSKLICK....ZIEL SPEICHERN UNTER.... (sonst kommt lycos Error Page !!!) Natürlich kann man es auch mit 20MHz machen. Gibt ja AVR's die das können. Man muss nur die Routine dann anpassen.
Und da ist doch genau der Haken an Deiner Methode. Nicht, daß ich Dein Erfolgserlebnis schmälern möchte, ist schon interessant, was Du da auf die Beine stellst. Aber bei Deiner Methode mußt Du den Code komplett durchackern, mit allen Fehlerquellen, die dabei entstehen, bei der Timermethode muß (theoretisch) nur der Timer umprogrammiert werden. Solange man schneller wird, machts kein Problem. Mal was anderes: Warum bei Farbe das komplizierte FBAS-Signal verwenden? Bei ebay gibts TFT-Monitore teilweise schon für 100 Euro - soviel zahlt man bereits für ein 240x128 s/w LCD... RGB sollte ja nicht das große Thema sein, da gibts schon einige Projekte, die das verwirklicht haben. Ist nur die Frage, welche Auflösung man schafft bzw. ob die 1024x768 Panels 512*384 sauber runterrechnen. Mit zwei Bit pro Farbe kriegt man auch schon eine ansehnliche Farbpalette.
@thkais Zuerst mal was zu den Timer bzw. taktfrequenz. Ich brauch sogesehen nur 1 Routine dafür ändern. Die HSYNC !!!! Mehr nicht !!!!!! Und wo ist das Problem ? Hier mal die HSYNC: ;#####( Horizontale Synchronimpuls 189 takte)############################ ; 4µs sync low (4*16 = 64 takte bei 16 MHz) ; 8µs Blackscreen (8*16 = 128 takte bei 16 MHz) ; +3 vom rcall ; +4 vom return ; +192 vom programm hsync: cbi PORTB, sync ;2 ;sync cbi PORTD, pixel ;2 ldi r17, 0x15 ;63 hs: dec r17 brne hs nop ;1 sbi PORTB, sync ;2 ldi r17, 0x29 ;123 ;blackscreen hs3: dec r17 brne hs3 ret ;4 ;####################################################################### Wird es nun 20MHz kommt vorne und hinten jeweils eine kleine Schleife rein. Fertig ist es. Genau so als würde ich es auf NTSC umstellen, da wird die Hsync geändert und ein paar Leerzeilen verschwinden und fertig ist man damit. zu den Fehlerquellen --------------------- Wenn eine Unterroutine ersteinmal fertig ist braucht man diese nacher nicht mehr checken ob sich da ein fehler eingeschlichen hat. Man arbeitet sich sogesehen Modul für Modul durch. Die Fehlereingrenzung ist somit auf Modulebene begrenzt. Man muss also nicht mehr das ganze Programm durchhacken ;-) Zu deinem Vorschlag mit der Farbe --------------------------------- Hallo, wir wollten billig bleiben !!! Wenn ich mir jetzt noch ein TFT holen müsste kann ich mir gleich ein PC hinstellen und dort PacMan drauf programmieren ? Wo ist da der Sinn ? Ein TV besitzt jeder. Also baue ich doch nur ein Modul welches man dann an jedes GÄNGIGE Gerät anschliessen kann. Sollte ich jetzt so ein TFT Modul kaufen müsste jeder das selbe zulegen, damit es mit den Protokollen ect. überein stimmt.
@kryon2000: Ich verstehe deine Aversion gegen Timer nicht. Du verschwendest Rechenzeit pur, wenn du keinen Timer benutzt. Es sagt zwar keiner, dass es mit nem Timer einfacher ist als mit deiner Lösung, aber du hast wesentlich mehr Zeit, um andere Dinge zu berechnen. (Klar kann es die Programmiererei etwas komplexer machen, aber wir sind ja alle gute Denker. :) ) Mit Timer solle auch ein Graustufen-PacMan drin sein.
Na dann zeigt doch mal eure Lösungen mit Timer, dass was ich bis jetzt gesehen habe ist der Misst von: http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/ Cornell University Electrical Engineering 476 Video Generation Solche Low Grafik ist ja nun echt nicht der Hit. Bevor ihr euch auf Timer ect. festlegt und Graustufen, solltet ihr ersteinmal selber versuchen eine Grafik auf dem TV dar zu stellen, dann erst werdet ihr merken welche Probleme sich da so auftun. Wer will kann ja mal den Kurs besuchen den ich gerade dafür halte: http://www.4freeboard.to/board/thread.php?threadid=26313&threadview=0&hilight=&hilightuser=0&page=1 Aber wie gesagt, ich bin über eure Lösungen betreffs Timer immer sehr dankbar, stellt doch mal eure Lösungen dazu hier rein (Screenshots, video ect...)
@Michi Klar haben EINIGE TV's den Euroscart auch mit RGB belegt, aber nicht alle. Gerade billige TV's haben dies nicht, desweiteren kann man sein Signal nicht per HF raus geben, da die HF Module leider nur Composit als input haben wollen. Ein billiges RGB -> PAL Modul könnte da abhilfe schaffen, jedoch existieren solche billigen IC's nicht. Mein Projekt beruht auf dem Motto, EINFACH und BILLIG.
>>EINFACH und BILLIG JA, bleib dabei, das macht es ja interessant. Mit genug techn. Aufwand kann man ja gleich 'ne Playstation nachzubauen versuchen. Sinnlos ist das Ganze ja allemal, wer braucht ein Pacman-Game auf TV? Der Zweck liegt doch darin , ASM zu lernen, und darzustellen was mit einem simplen AVR so möglich ist. Ich hab vor einigen Monaten in einem anderen Forum ein AVR-Videoterminal programmiert. Mit einem Atmega8 mit 8 MHz und zwei Widerständen. Nix weiter. Nicht mal ein Quarz. Komplett Interruptgesteuert, übrigens. Da ging es mir auch darum, das so einfach wie möglich zu machen, und meine Kenntnisse in ASM auf AVR zu verbessern. Also mach weiter so - EINFACH und BILLIG Ich verfolge das mit Interesse. Allerdings, den Source-Code solltest du schon kommentieren und hier einstellen, damit auch andere davon lernen können. Finde ich. Mfg Willi
Hast du noch Quellen, wie das ganze eigentlich mit FBAS etc funktioniert? Oder nen paar Stichwörter zum googeln. Kann man da überhaupt Farbe integrieren, bei der Anschlussart? VGA hat doch 3 Farben und HSYNC+VSYNC..
Angehängte Dateien:
-
spiel.gif
132 Bytes
@willi Ohne externen Quarz ? So wie ich es feststellen musste, sind die internen 8MHz nicht sehr stabil. Bei mir schwam das Bild dann immer. @all Da ich 20 levels einbauen will und auch gerne eure Ideen da einbauen möchte könnt ihr mir ja ein paar Vorschläge zusenden. Oben im Anhang ist so ein Beispiel. Macht einfach mal ein 16x16 pixel grosses Bild wo ihr das Feld einzeichnet. Platziert dann mit grün die Startposition der Geister (1 bis max. 4) und mit rot die Startposition vom PacMan.
"Ohne externen Quarz ? So wie ich es feststellen musste, sind die internen 8MHz nicht sehr stabil. Bei mir schwam das Bild dann immer." Nee, kein Problem, das Bild steht wie eine Eins. Kannst die das Programm ja im Roboternetz-Downloadbereich unter AVR-Codeschnipsel runterladen und ausprobieren. Für die Bildstabilität ist ja auch nur die Frequenzstabilität in einem kurzen Zeitraum wichtig. Wenn der RC-Oscillator z.B. wegen Temperaturänderung langsam wegdriftet, so bleib das TV-Bild trotzdem stabil. Die absolute Genauigkeit ist beim TV-Signal sowieso nicht so wichtig. Die Bildzeile z.B. muss nicht genau 64us lang sein. 63us oder 65us geht auch. Aber jede Zeile muss genau gleich lang sein, das ist wichtig. Bei Schwankungen gibts hässliche Verzerrungen. MfG Willi
GEISTESBLITZ +++++++++++++++++++++++++++++++ Ich glaube ich weiss nun wie wir das mit der FARBE hin bekommen könnten. Zuerst bauen wir uns ein Quarzoszilator mit den berühmten 4,4....MHz (aus alten TV ausbauen) Diesen werden wir dann über einen Port vom Atmel entweder zuschalten oder auch nicht. Und da 16MHz überhaupt nicht durch 4,4 teilbar sind müssten wir schöne farbverschiebungen hin bekommen. leider weiss ich nun im Vorraus nicht welche farben da entstehen, jedoch irgendwie BUNT wird es schon werden (glaube ich). also benötigen wir als zusätzl. Hardware ein Quarz (4,4...MHz) ein NAND Gatter (74xx00) als Generator und ein Wiederstand. Möge mich jetzt noch einer schnell berichtigen ansonsten baue ich den scheiss gleich mal.....
@kryon2000: Der Grund, weshalb ich mit einem TFT arbeiten möchte, ist folgender: Ich arbeite gerade an einem Projekt, in dem ich viele Werte und einige Grafiken visualisieren will. Momentan benutze ich ein 240x128 LCD. Durch Dein Projekt bekam ich den Anstoß, es auf eine andere Art zu realisieren. PC fällt von vornherein aus (braucht viel zu viel Strom für eine 24/7 - Anwendung). Vom Preis/Leistungs-Verhältnis her ist ein TFT nicht schlecht. Und dann noch bunt... und mit exakt vorhersehbaren farben ;)
@thkais: Dafür gibts bessere Lösungen, z.B. die von www.ulrichradig.de (Startseite->CPLD->Graka). Markus
@thkais: Du solltest Dir mal den Beitrag von Benedikt aus der Codesammlung ansehen - der steuert dort ein schwarzweißes STN-Display mit VGA-Auflösung an. Das ist zwar kein TFT, aber einige Grundkonzepte ließen sich auch auf ein TFT übertragen. http://www.mikrocontroller.net/forum/read-4-160854.html#new
Habe ich eigentlich schon erwähnt, daß es mir um das Feature Farbe geht ? Mit CLPDs kann ich nicht viel anfangen. Mal sehen, wenn eines meiner 1000 anderen Projekte endlich mal fertig wird, gehe ich das mal an. (Nur noch 28 Jahre bis zur Rente g)
So, habe nun eben meine Bastelkiste nach Quarzen abgesucht. Und was soll ich sagen. TV ausschlachten hat sich wohl gelohnt. Ich habe 2 17,73447 MHz Quarze gefunden. Jetzt meine Idee Ein 4er Teiler kommt bei den 17 MHz dran der durch den atmel geresetet werden kann. Somit haben wir nach dem BURST eine genaue grundlage um den Teiler zu reseten. Da 16MHz und 4,433 MHz keinen Teiler besitzen können wir durch ausgewähle resets am Teiler eine deffenierte Phasenverschiebung zum BURST durchführen. Jetzt muss ich mal nach einem teiler suchen...das war doch so ein 74xx194 oder.....
Also, ein wenig Bunt wurde es: http://mitglied.lycos.de/polyxos/tv16.jpg 50:50 war das Resultat. Das lag im grossen und ganzen daran, das ich den BURST nie Phasenverschoben hatte. Also er war in jeder Zeile gleich. Jetzt weiss ich nicht wie die Phasenverschiebung sein müsste, 90° oder 180°. Überall liesst man was anderes.
So nebenbei-> Besorge dir mal anderen Space. Wie www.cybton.de oder so. Irgendwas, wo man die Bilder auch sehen kann. Das mit lycos ist nämlich etwas lästig... Als Ersatz ist es sicher gut, aber sonst. Es gibt sicher noch viel besseren, welcher auch kostenlos ist, aber mir fällt nichts ein.
So, habe noch etwas rumgespelt an der V-Sync und versucht ein wenig Sound dort rein zu bringen. Sieht nun so aus: http://mitglied.lycos.de/polyxos/tv17.jpg Und diese Punktzahl gilt es zu schlagen ;) http://mitglied.lycos.de/polyxos/tv18.jpg Im Anhang das Schaltbild + HEX File.... Mit dem Drehregler lässt sich die Spielgeschwindigkeit einstellen, je schneller um so mehr Punkte bekommt man auch für einen Keks ;).
>http://www.volkssturm.net/TMS_rang/pac.avi
Such mal nach anderem Speicherplatz - 3,5KB/s macht bei 11MB keinen
Spaß. :-(
ik würd mal was in den Raum werfen. man könnte doch "Gamedisks" mit 2 oder 3 EEproms nehmen, 1 mit spielablauf, 1 mit Grafik und eins mit Sound. es gibt dann halt 2 Atmels, einer Grafik, einer Spielablauf und Ton, welche die EEProms auslesen. So wären, da der Grafikchip wirklich nur die grafik machen müsste auch super-farben und klarer stereosound möglich.
@Hannibal: Bevor ich anfangen würde EEProms an einen AVR zu packen, würde ich erstmal einen AVR mit mehr Flash nehmen. Zumal entweder serielle EEProms zu langsam wären oder aber parallele EEProms wegen den vielen Pins bereits größere AVRs benötigen würden. Zwei AVRs zusammen wären aber durchaus interessant.
Zur Kommunikation wäre dann aber ein Speicher gut, in dem das Bild 2x hineinpasst und welcher gleichzeitig gelesen und beschrieben werden kann. Das führt dann dazu, dass man doublebuffering hat und dass sich ein AVR nur um das Malen kümmern kann und dass der andere den kompletten Ablauf übernehmen kann.
Dualport-RAM wäre gut nur viel zu teuer. Oder ein sehr schnelles SRAM das man multiplext.
1. naja ich meinte, dass die Games auf EEproms gespeichert werden, zu beginn in den RAM geladen werden und dann gestartet wird. so wäre es möglich mehrere Games an der "Konsole" zum laufen zu kriegen. Während des Ladens könnte ja ein Logo eingeblendet werden oder an einer Festgelegten position auf dem EEProm ist ein wird geladenbild was als erstes geladen und während des Ladevorganges angezeigt wird. 2. Desweiterenm könnte man ja auch 2 Rams nehmen. Der hauptchip schreibt auch den ext. RAM1 während der Grafikchip von RAM2 liest. Danach wird geswitcht. (Dat meinest du doch mit muliplex oder?) 3. Wenn man dasb so mit den EEProms macht, müsste man am besten noch ein SDK rausbringen mit dem Leute gaaannz einfach Games machen können. vielleicht sogar Click`n`Play.(SDK für Basic & C) Mfg Lukes Vader
@Hannibal: Dein Vorschlag ist mit AVRs unmöglich, da Programme nur aus dem Flash ausgeführt werden könne. Also könnten nur Daten von einem EEProm geladen werden oder es muss ein (lahmer) Interpreter geschrieben werden. Alternative: Kein AVR verwenden.
@Hannibal: Das ist prinzipiell das gleiche :-) Man braucht nur eine Steuerleitung, welche im Richtigen Moment umschaltet. Woher bekommt man solchen Ram? Ich würde 2x 500kb nehmen. Das reicht auch, wenn man irgendwann was schnelleres machen kann mit voller auflösung und 8bit.
http://www.reichelt.de/inhalt.html?SID=14QAl30dS4AQ4AAFGRm%40c7f25b93de0eff217c8d737c3d702701c;ACTION=3;LASTACTION=2;SORT=preis;GRUPPE=A34;WG=0;SUCHE=Ram;ARTIKEL=628128-70;START=0;END=16;STATIC=0;FC=669;PROVID=0;TITEL=0 Wie groß ist dieser Baustein? Ist der 1MB groß oder 128KB?
Ich persönlich würde vielleicht doch einen 64Kb baustein nehmen. Die warscheinlichkeit, dass man irgendeinen superchip als Grafikeinheit nimmt ist doch sehr gering.
Ich habe noch eine Frage: Kann man den externen Ram eigentlich irgendwie auf den internen Ram mappen, damit man sich die zusätzlichen LESE und SCHREIB-Routinen sparen kann?
also isch hab noch nie mit Atmels gearbeitet(bitte haut mich nich) aber viel in Foren gelesen. Eigentlich müsste ja nur der Hauptchip Programme laden können da Grafik u. Sound eine Firmware haben könnten. Und für standart berechnungen reichen doch 10mhz. Bei Reichelt ham sie solche komischen Prozis. Und sonst nimmt man nen 486;-) Und nochwas. Ich hab mehrere Ramriegel rumliegen. PS/2 oder so. Könnte man die Chips davon fürs Grafikspeichern nehmen. Würde auch welche verschenke(gegen Porto)
@Hannibal: Ok, da du es nicht weißt, AVRs können Architektur bedingt keine Programme aus dem RAM ausführen. ARM, oder MSP würden es aber können. @Freak5: Externen RAM in den internen RAM mappen geht nur bei manchen AVRs. Der ATMEGA8 kanns nicht (würde auch zu viele Pins benötigen). AT90S8515, ATMEGA64, ATMEGA128 fallen mir gerade ein, die es können. Genaueres erzählt dir das Datenblatt.
Das mit dem Ausführen wusste ich schon. Mit Prozis meinte ich keine Atmels sondern solche ZiLOG oder Ähnliche.
Das mit dem Ausführen wusste ich schon. Mit Prozis meinte ich keine Atmels sondern solche ZiLOG oder Ähnliche. Und ich finde für Hauptarbeit(Kollision, Dialoge usw.) usw. würden auch Interpreter reichen. Ich weiß das das langsamer is aber für kleinere Berechnungen reicht es, da die Grafik ja das Schlimmste ist.
so hab noch eine! frage kann man programme vom flash ausführen, denn dann kann man ja mit bootloader EEProminhalt auf flash kopieren. und dann von der Stelle ausführen. mfg Lukes Vader
Theoretisch könnte ein Bootloader erstmal ein Programm aus einem externen EEProm in den Flash kopieren. Aber: Flash ist nur begrenzt neu beschreibbar. ATMEL garantiert bei den ATMEGA 10000 mal. Das mag zwar reichen, aber ich würde andere Lösungen vorziehen. PS: Bastel mir selber gerade eine "Spielebox" mit nem ATMEGA32 und LED Display.
@Malte: AT90S8515 der ist nicht Pinkompitabel zu den ATmegas wie ATmega16 usw. Kann man den denn mit dem ISP programmieren??? P.S.: Für dieses einmappen des externen Rams, was ist der Fachbegriff dafür(ich möchte mal wissen, ob die Atmegas im Dil - Gehäuse wie Atmega 16 und ATmega32 das auch nicht können)
Der AT90S8515 ist nicht mit den ATMEGA16/32 Pin-kompatibel. Kompatibel wäre der AT90S8535, der aber keinen externen RAM unterstützt. Beim ATMEGA128 heißt es "External Memory Interface", hab ich aber noch nicht mit gearbeitet (kommt noch),
Die Idee mit 2 AVRs finde ich nicht so schlecht wenn andere auch das Gegenteil behaupten. Ein externes SRAM als Videospeicher darauf greifen 2 AVR. Eine liest aus und erzeugt das Bild und der andere baut das Bild auf und schreibt es ins SRAM. Ist die Idee blöd?
ganau! Bloß eine Frage, wie kann man mit wenig mitteln Programme laden ohne meine Flash-idee.
Na ja, der eine AVR muß ja nur Daten lesen und ausgeben und sollte nicht dabei gestört werden. Der 2. AVR muß zum Grafikaufbau nicht nur schreiben, sondern bei Bitverknüpfungen (OR, AND) für einzelne zu setzende Pixel, auch mal vom SRAM lesen. Ansonsten kann man keine gescheite Grafiken erzeugen wie Pixelweises Scrolling, verknüpfen von mehreren Objekten teilweise übereinander etc. Mit Klötzchengrafik braucht man sich gar nicht erst die Mühe machen. MfG Andi
1. Ahm Weinachtsmann. Hast du mich letztes mal vergessen gehabt. Ich warte immer noch auf Geschenke =). 2. Ich meinte 2 RAMS wobei sich die 2 Chips immer abwechseln. Schritt 1) 1.liest auf RAM1 2.schreibt auf RAM2 Schritt 2) 1. liest von RAM2 2. schreibt auf RAM1 Schritt 2) ... mfg Lukes Vader
Hi Hannibal Habe wohl dieses Jahr den Sack voll AVR für dich vergessen, aber vielleicht dieses Jahr wenn du nett bist. Mit 2 RAMs könnte man es sicher machen. Aber dachte an eine andere Herausforderung indem man nur 1 RAM nimmt aber abwechslungsweise beschreibt und liesst. Das muss natürlich sehr schnell geschehen und auch das Timing muss stimmen. Aber die Schalung wäre einfacher.
ja schon aber 2 RAMs sind einfacher und unkritischer vom Timing her. Ich werd mir jetz erstmal ein paar AVRs bestellen. Alte RAMs hab ich ja noch da. Muss mal gucken was sich machen lässt. Also wenn ich mal was vorschlagen darf. Ich find das man es Ähnlich einem N64 mit den Modulen machen kann. Um Sound werd ich mich dann mal kümmern und vielleicht mach ich dann noch nen Interpreter.
Mein Gott - habe nicht alles gelesen - aber wer hat denn soviel Zeit zu vertun? Das Ergebnis bleibt doch letztendlich unbrauchbar, vor 20 Jahren hätte man damit was reissen können, aber heute?? Nur um zu beweisen, dass es irgendwie geht, und das eine schlechte Lösung besser ist als eine ganz schlechte?
@crazy horse: Nu laß sie doch, letztenendes kommen dabei auch kreative Ideen heraus, von denen wir alle etwas haben, so als Denkanstoß für künftige Projekte...
Ob es Sinn oder kein Sinn mache ist ein anderes Thema. Ich glaube nich dass einer damit das grosse Geschäft machen will. Sondern einfach selber was umsetzen und Erfahrungen sammeln. Das macht Spass deshalb finde ich das Projekt interessant.
Hi Na da habt ihr das Thema wieder mal von ganz unten hoch geholt ;-). In diesem Forum wird richtig dran gearbeitet: http://www.4freeboard.to/board/thread.php?postid=165963 farbe ist z.Z. angesagt.
Na ja mit der Aussage "ich mach jetzt erst mal Urlaub" glaub ich nicht dass da so "richtig" daran gearbeitet wird :-)
@CrazyHorse "Mein Gott - habe nicht alles gelesen - aber wer hat denn soviel Zeit zu vertun? " Nun ja, es gibt auch Bastler, welche sich die Mühe machen, aus einem AVR chip einen MP3 Player zu bauen. Auch da kann man argumentieren: Geh in den nächsten Elektronikmarkt, und kauf dir einen fertigen Player für 15 EUR .. Aber auch da ist "der Weg das Ziel", und nicht, einen neuen MP3 Player gebaut zu haben, der mehr oder besser funktioniert alles alles was derzeit im Laden zu kaufen ist. Ich finde die Idee sehr pfiffig, den AVR quasi als Videocontroller zu nutzen. Mein Lob und Hochachtung an MasterCrd (Krypon 2000/ mister_crd) für seine fachlichen Kenntnisse und Fähigkeiten, und sein Engagement in der Sache. Wenn ich eine Stelle in der Elektronik-Entwicklung anzubieten hätte würde ich sie ihm gene geben. Der Mann keann sich in Dinge ziemlich tief reinfressen...
Ich lese schon eine ganze Zeitlang diesen Thread, da ich auch viel mit Videobildern und AVR machen, und eins kann ich sagen: Die Idee mit den 2 SRAMs ist zwar machbar, nur viel zu aufwendig. Wie wollt ihr die SRAMs umschalten ? Dazu muss man 8bit Daten und mindestens 16bit Adressen umschalten, dann noch die Steuerleitungen. Macht insgesamt 24bit und das sind pro SRAM 4x 74HC245, also insgesamt 8x 74HC245. Viel Spaß beim Aufbauen... Die einzige realistische Idee ist ein schnelles SRAM und ein CPLD, der schnell genug zwischen beiden AVRs umschaltet, also ein Pseudo Dualport RAM.
Es gibt doch sicher sinnvollere zeitkritische Anwendungen, an denen man sich so richtig auslassen kann. Den Igor-Plug beispielsweise finde ich Klasse, das war sicher auch nicht gerade ein Kinderspiel. Für mich wäre es jedenfalls kein Einstellungsargument, dass sich jemand 100e von Stunden in ein Projekt reinhängen kann, bei dem man schon im Vorfeld erkennen kann, dass es nichts Sinnvolles ergibt. Eine Vorabbetrachtung gehört zwingend dazu, und da kann man leicht erkennen, dass ein MC dieser Grössenklasse nicht das geeignete Mittel ist, ein Videospiel zu realisieren. Unabhängig davon, ob man es irgendwie und mehr schlecht als recht doch hinbekommt.
@crazy horse: Hast du noch nie etwas von den 256b Demos gehört? Das hier ist sozusagen, die Extremversion davon. :-)
@crazy horse Was ist an dem Igor-Plug sinnvoll ? Man nimmt den FT232, hat eine hohe Baudrate und kann den AVR für was sinnvollen einsetzen...
"Was ist an dem Igor-Plug sinnvoll?" Man kann tatsächlich damit was machen, und ein FT232 kostet um die 6Euro...
@crazy horse: Ich habe mal für dich gesucht. Gefunden habe ich das hier. Recht beeindruckend eine unter XP laufende Demo zu programmieren mit 3D und nur 256bytes http://www.256b.com/download/381 Und hier ist die Addresse: http://www.256b.com/demo/374 Der Name der Demo, dessen Direktlink ich gepostet habe ist übrigens GridRunner. Ich finde das beeindruckend :-) In diesem Fall ist so eine Art zu Proggen ja sogar nötig. Ihr könnt doch auch mal so ein "3D" mit dem ATmega erzeugen :-)
http://www.256b.com/demo/138 Die ist auch gut. Dabei muss ich sagen, dass ich die eine oder andere Demo selbst leicht übertreffen könnte. Damit meine ich die, wo nur ein einziger Punkt gezeigt wird g Aber einige sind verdammt genial
Hallo thkais, wenn schwarzweiss genügt und dir eine Ein-Chip-Lösung (DIL 28) nicht zu aufwändig ist, dann schau mal hier: http://www.tvterminal.de/index.html#TVT-MBKD Habe die Farbversion (incl. Evaluation Board) auf der diesjährigen HAM RADIO gekauft und bin sehr zufrieden. achatz
Also, ich hatte auch überlegt. Ein Chip liest Bilder von EEProm in RAM. Anderer AVR sendet Befehl mit Bildnummer u. Position an GrafikAVR. GrafikAVR fügt Bild ein und zeigt an. Bsp. Befehl: 1011010-111111-101010-1 BildNR.-Pos.X -Pos.Y -Tranzparenz?
@Apostolos Chatziapostolou Was ist denn das für ein Chip auf diesem Bausatz?
Was das für ein Chip ist ? Na dann schaut euch mal die Anschlussbelegung an. Ich tippe mal auf den ATmega8 oder den ATmega168.
Auf dem Chip steht: TVT-MBKD-11. Von der Belegung der Anschlüsse tippe ich auch auf einen ATMEGA. Fliege heute abend endlich in den ersehnten Urlaub :) Viele Grüsse achatz
Ich bin gerade dabei dieses feature für unsere Schaltung zu übernemen. Aber ein wenig mehr RAM würde dabei echt nicht schaden.
auch abo und: kryon2000: Ich find das ja echt eine super Leistung und bin wirklich begeistert was du zustande gebracht hast ABER wieso machst du nicht eine gescheite Seite wo dein Projekt Schritt für Schritt erklärt wird anstatt von einem Forum ins Andere zu hüpfen? Das würde, so finde ich, dann auch an Seriosität gewinnen.
Ganz einfach, es ist ja kein Projekt in dem Sinne, sondern eigentlich nur eine Lektion damit andere was lernen. Ich gehe ja im anderen Board auf die Fragen und Wünsche der einzelnen Teilnemer ein. Deshalb ist es eben keine eigenständige Seite. Hier habe ich nur so aus Just for Info gepostet, da es ja ein tolles Nachschlagewerk für alle MC Bastler ist.
So langsam glaube ich das die Jungs hier: http://www.tvterminal.de/index.html#TVT-MBKD die Käufer bescheissen. Das es sich bei dem Chip um ein ATmega8, 48, 88 oder 168 handeln muss ist klar, jedoch besitzen alle nur 1024 Byte SRAM. Damit ist es deffenitiev nicht möglich alle Daten im SRAM zu speichern. Entweder die speichern alles ins Flash (was die Lebenszeit sehr stark beeinträchtigt) oder die haben ein eigenen Chip in Auftrag gegeben. Was natürlich die Frage aufwirft, ab welcher Stückzahl produziert eigentlich ATMEL ein Chip mit mehr SRAM. Und was kostet sowas ? Ich glaube letzteres haben die nicht gemacht. So ein Flash ist ja nur bis 10 000 mal beschreibbar. Wer hat den schon alles bei den sowas bestellt ? Läuft der "TV-Chip" immer noch ?
.
"Das es sich bei dem Chip um ein ATmega8, 48, 88
oder 168 handeln muss ist klar,"
Frage: Woran machst Du das fest?
Es sei denn du kannst mir ein anderen Chip zeigen wo XTAL, GND Vcc AVcc PORTx0 in einem DIL28 genau so angeordnet sind.
Habe sowas schonmal auf ner amerikanischen seite gesehen, die haben sowas mit nem mega128 glaube ich gemacht, und auch bilder darstellen können (bitmaps)
Hmm. Das kann natürlich sein. Warum glaubst Du, daß das mit 1 KByte RAM nicht hinzubekommen ist? 50*18 = 900 Bytes "Bildschirmspeicher"; nirgendwo wird behauptet, daß das Teil einen vollständigen 8-Bit-Zeichensatz benutzt. Also lässt sich das eine Attributbit (Grau statt weiß) auch im "Bildschirmspeicher" unterbringen. Diese Balkengraphik ist ja keine frei programmierbare Graphik, sondern ausschließlich Balkengraphik, die wird also nicht so sonderlich viel RAM benötigen. Hab' ich irgendwas übersehen?
Ja , hast du. 50*18 Zeichen sind genau 900 Byte. Um eine Zeile mit 50 Zeichen in einer Zeile mit 8 Linien auf den TV zu bringen müssen 50 * 8 Bytes verbraucht werden. Das mach allem in allem genau 1300 Byte. Viel kürzen kann man dabei auch nicht, da alles sehr schnell berechnet werden muss. Das mit grau und weiss als Vorzeichen für eine Zeile lassen wir ruhig dabei mal ausser acht. Deffenitiev muss 400 Byte für Videoram reserviert werden im SRAM. Nun kann man sich überlegen wo er den Bildschirm-ASCII Cash (50*18) speichert...... Ach ja, und ganze 1024 Bytes hat er ja auch nicht zur Verfügung, ziehen wir nochmal 4 Bytes für den Stack ab.
Und falls du es nicht glaubst, dann schau doch mal im Board nach wo ich den Source Code für die 50*12 Ausgabe abgelegt habe. Wenn du es noch effektiver hin bekommst dann poste es mal. Würde mich interresieren.
Hallo, Ich glaube auch, das das geht. Es handelt sich hier um einen 5*7 Zeichensatz, also nur 5 Bytes/Zeichen macht 250 Bytes Bildspeicher für eine Zeile. Wenn die 50*18 6-Bit-ASCII-Zeichen sind, und mit 6 Bit pro Zeichen gespeichert werden, dann sind das 675 Bytes als Zeichenspeicher. Mach bis jetzt insgesamt 925 Bytes. Das Attribut "hell"/"grau" funktioniert offensichtlich nur Zeilenweise. dafür braucht man also max. 18 Bits oder drei Bytes. Wo Balkengrafik ist, braucht man keinen Platz im Zeichenspeicher. Also, da ist noch jede Menge Luft, und ein Mega8 mit 16MHz leistet mehr als man denkt, effektive Programmierung vorausgesetzt. Mein ASCII-Terminal mit 28*24 Zeichen läuft auf einem Mega-8 mit 8Mhz. Gruß Jan
Mußt Du alle 8 Bildschirmzeilen einer Textzeile auf einmal zwischenspeichern? Reicht die Zeit nicht, um immer nur eine Bildschirmzeile vorzubereiten?
@Jan: Das mit dem 6Bit-Alphabet kann eigentlich nicht sein, da im Beispiel Groß- und Kleinbuchstaben (mit Umlauten), Ziffern und ein paar Sonderzeichen zu sehen sind. Das macht 29*2+10+x=68+x Zeichen. Wenn man davon ausgeht, daß die Balkengrafik auch aus Zeichen besteht, dann sind es sogar noch mehr Zeichen.
Hallo, >>Mußt Du alle 8 Bildschirmzeilen einer Textzeile auf einmal >>zwischenspeichern? Reicht die Zeit nicht, um immer nur eine >>Bildschirmzeile vorzubereiten? Es sind 7 Zeilen. :-) Nee, das ist zu knapp, glaube ich, bei 50 Zeichen pro Zeile allemal. Das würde ich mit meinem jetzigen Kenntnisstand nicht hinkriegen. Aber bestimmt gibt es noch ein paar Tricks, auf die ich noch nicht gekommen bin... Kennst du einen ?? Gruß Jan
>>Das macht 29*2+10+x=68+x Zeichen.
Jou, da hast du recht, dann wird das eng.
Aber bestimmt kann man noch irgendwo sparen,
wenn man sich richtig damit beschäftigt.
Vielleicht hat der Programmierer es ja auch geschafft
nur eine Bildschirmzeile als Bildspeicher zu halten,
wie Markus es vorgeschlagen hat. Wer weiss.
Da spart man gleich 200 Bytes.
Hier hat sich bestimmt jemand richtig Mühe gegeben
und alles aus dem Mega8 rausgequetscht.
Und jetzt will er das gern verkaufen, und ein paar Euro damit machen.
Ist doch Okay. Und der Preis ist auch moderat.
Verkauft allerdings nur Bausätze, keine Fertigteile.
Jaja, die Produkthaftung, CE, EMV undwasweisichnochalles...
Gruß Jan
Vorneweg: nein, ich habe das leider weder selbst aufgebaut noch kann ich ein entsprechendes Programm vorweisen, bin also auch nur ein Theoretiker in dieser Sache und muß mir ggf. ein "dann mach es doch!" anhören. Trotzdem riskiere ich meinen Ansatz: keinen Zeilenpuffer, nicht einmal für eine einzelne Zeile. Für jede Spalte haben wir rund 1 µs Zeit, bei 18 MHz und 6 Pixeln Spaltenbreite (5 Zeichenbreite + 1 Pixel Abstand) sind das also 3 Takte pro Pixel. In der Lücke soll jeweils das nächste Bitmuster geladen werden. Wenn ich davon ausgehe, daß ich am Anfang des Zeichens in einem Register die 5 horizontalen Bits für dieses Zeichen stehen habe, mache ich also 5 mal z.B. OUT, LSL, NOP. Beim fünften Pixel höre ich nach dem OUT auf und lade mit einem LD rd,X+ das nächste Zeichen der Zeile ins Z-Register. Das sind zwei Takte, ersetzt also genau das LSL+NOP. Dann kommt ein OUT von einem leeren Register, damit die Lücke schwarz wird. Mit einem LPM hole ich mir jetzt die Bitmap der entsprechenden Zeile des Zeichens in ein Register, dann geht es wie oben weiter. Das heißt dann, daß die Lücke 4 statt 3 Takte dauert, aber das darf ja eigentlich nichts ausmachen, oder? Das gesamte Zeichen kommt auf 19 Takte, also muß man den den µC doch etwas schneller takten, sonst verschwindet das letzte Zeichen am rechten Bildschirmrand. Müßte das nicht gehen?
Ich glaube, daß genau hier
"und lade mit einem LD rd,X+ das nächste Zeichen der Zeile"
ein Problem liegt. Was Du so lädst, ist ja darzustellende Zeichen,
nicht aber das dieses Zeichen repräsentierende Bitmuster ...
oder meinst Du, daß in der Austastlücke ausreichend Zeit ist, um alle
Bitmusterzeilen der einzelnen darzustellenden Zeichen in einen
Pixelzeilenpuffer geladen werden können?
Dazu muss für jedes Zeichen in der Zeichendefinitionstabelle an der
durch die Scanzeile vorgegebenen Position ein Wert extrahiert werden;
diese Operation muss folglich 50mal erfolgen.
In C-Notation:
for (i = 0; i < 50; i++)
{
Pixelzeilenpuffer[i] = Zeichentabelle[(Zeilenpuffer[i] * 8) +
Zeilenoffset];
}
(die 8 sei die Höhe der Zeichenmatrix)
Reicht dafür die zur Verfügung stehende Zeit aus?
Ich würde die Daten hier etwas anders anordnen: Erst die 1. Zeile aller Zeichen, dann die 2. Zeile aller Zeichen usw. usf. Damit muß man pro Zeile nur einmal die Zeile auswählen (ins ZH) und kann dann den ASCII-Wert direkt ins ZL schreiben. Das Problem ist aber wohl, daß der lpm volle 3 Takte braucht, man im HSync aber nur etwa 4 Takte pro Pixel zur Verfügung hat (bei 16MHz). Man kann damit die 50 Zeichen sicher nicht aus dem ROM holen. Markus
Sollte "4 Takte pro Zeichen" heißen. Der HSync hat 12µs = 192 Takte 200Take / 50 Zeichen = 4 Takte/Zeichen
Schaut euch mein Sourcecode an, der ist nun wirklich Zeitoptimiert und deshalb sehr lang, Man kann die Bitmuster nicht wärend einer Ausgabe erst berechnen und laden. Das muss vorher geschehen. Bei der Zeilenausgabe muss jedes Pixel im RAM vorliegen damit es sehr schnell raus gehen kann. Und noch mal für alle, schaut euch die Screenshots von diesem CHIP an, ES SIND 8 ZEILEN, am besten zu sehen bei q p y und Komma ect. Bei 7 Zeilen würde ich ja auch 50 Byte SRAM für Videocash sparen. Hier im Anhang ist nochmal der ASM code für meine Routine, falls ihr den link weiter oben nicht gefunden habt. http://www.4freeboard.to/board/thread.php?goto=lastpost&threadid=26409 Ach ja, und es sind 6 Pixel breite Spalten, zu sehen an der durchgezogene Linie im Textfeld. Und nochmal für die Theoretiker unter uns, Wenn ich 300 Pixel (50*6) raus jagen will pro Zeilenehm ich pro Pixel 2 Takte und nach jedem Zeichen einen zusätzlichen, somit habe ich 650 Takte. Im sichtbaren Bildschirmbereich würden ca. 750 Takte angezeigt werden können. Und Phillip, wir haben hier 16MHz, das macht pro 1µs = 16 takte ;-). Ein Pixel demzufolge 2 Takte = 0,125µs oder 125ns. Und der Zeichenvorrat bei ihm wird wohl auch 64 Zeichen betragen.
@Marcus bei dieser Anordnung verschenkst du doch sau viel Flash speicherplatz.
@kryon: Klar braucht die Methode viel Speicher, aber solange man nicht auch noch Bilder darstellen will sollte das kein Problem sein. Wie ich oben vorgerechnet habe, ist sein Zeichensatz wohl größer als 64 Zeichen. bye Markus (mit "k")
@Rufus: Da habe ich mich wohl undeutlich ausgedrückt. Wie Markus schon richtig interpretiert hat, lade ich den ASCII-Wert des Zeichens aus dem RAM ins ZL, um dann das Bitmuster über LPM zu laden (am Anfang der Zeile muß also das ZH auf einen von acht Werten gesetzt werden, entsprechend der Zeile innerhalb des Zeichens). Und nein: ich will ausdrücklich keinen Puffer, auch nicht für eine Zeile. Der beschriebene Ablauf erfolgt für jedes Zeichen: LD ZL,X+ ;2 OUT Nullreg ;1 Takt 3 Lückenbit LPM r16, (Z) ;3 OUT r16 ;1 Takt 7 1. Bit LSL r16 ;1 NOP ;1 OUT r16 ;1 Takt 10 2. Bit LSL r16 ;1 NOP ;1 OUT r16 ;1 Takt 13 3. Bit ...usw. Also drei Takte pro Pixel, nur die Lücke hat vier. Beim Zeilenwechsel können also andere Sachen gemacht werden. @Kryon: Um das Bitmuster zu laden brauchst Du zwei Takte für das LD und drei für das LPM anstatt eines Shift-Befehls. Also vier zusätzliche Takte. Ich meine, die kann man zumutbar in der Lücke zwischen zwei Zeichen unterbringen. In den 300 Pixeln sind bei mir die Lücken schon drin (5 Pixel zeichenbreite + 1 Pixel Zwischenraum). Und ich schrieb selbst, daß 18 MHz für 50 zeichen knapp nicht ausreichen. Wenn man die NOPs wegläßt, geht es natürlich schon, aber dann wird der letzte Pixel eines Zeichens leicht breiter (was evtl. blöd aussieht) und der Abstand zwischen zwei Zeichen breiter (was wohl weniger stört). Wir haben dann 15 Takte pro Zeichen, dann geht es auch mit 16 MHz. Und das würde selbst mit 256 Zeichen funktionieren. Im Flash geht man tatsächlich großzügig mit dem Platz um: in einem Byte werden nur fünf Bits benutzt. Da ist dann entscheidend, wie viel Code man insgesamt unterbringen muß. Noch eine andere Idee: kann man über eine synchrone serielle etwas mit halbem µC-Takt rausschieben lassen? Dann wäre dazwischen reichlich Luft zum Laden!
Hallo, ich wurde von einem Anwender von TV-Terminal auf dieses Forum aufmerksam gemacht. Um irgendwelchen Gerüchten den Boden zu enziehen: Beim TV-Terminal werden alle dynamischen Daten ausschliesslich in einen beliebig oft beschreibbaren SRAM-Speicher geschrieben und nicht etwa in Flash- oder EEPROM-Speicher. Die auf der Seite www.tvterminal.de herunterladbaren Videos entsprechen dem abgefilmten Bildschirminhalt. Es wurde nichts herausgeschnitten oder sonst irgendwie getrickst. Dass sich solche Manöver von selbst verbieten, sollte klar sein. Das TV-Terminal ist ein stabiles und ausgereiftes Produkt, kein schneller Hack. Sein Design und seine Realisierung sind das Ergebnis der Umsetzung einer Vielzahl eigener Ideen. Mit freundlichen Grüssen Axel Viebig
Einen kleinen Denkfehler gibt es da schon, wir haben 128 Zeichen. Wenn wir also ein High Byte für die Zeile nehmen, haben wir nur 256 Byte für die Zeichenmatrix. 256/8 = 32 Zeichen. Das langt wohl nicht.
@Kryon: Wie ich oben schrieb: Man legt alle ersten Zeilen aller Zeichen hintereinander, dann erst alle zweiten Zeilen aller Zeichen usw. usf. Also z.B. Zeile 1: $2100-21ff Zeile 2: $2200-22ff Zeile 3: $2300-23ff usw. usf. Man braucht damit natürlich 2KB Speicher für den gesamten Zeichensatz (bei 8Zeilen hohen Zeichen), der dabei zwangsläufig 256 Zeichen umfasst. Markus
ups...sorry...Gedankenfehler ;-) Hier mal mit Input: http://www.4freeboard.to/board/thread.php?threadid=26409 Ok, dann haben die eben den ATmega168 genommen, mit 16K Flash ist alles drinn. Ich werde wohl dazu übergehen nur 7 Zeilen zu benutzen, die 8. Zeile bemerkt man eh nie.
@Axel Viebig Bitte schreib doch mal welchen Atmel du nun dafür benutzt hast.
meint ihr es wäre möglich ein farbsignal rein rechnerisch, ohne externe schieber etc zu erzeugen, wenn man sich auf weiss/blau und schwarz beschränkt!?
wiss nicht? es gibt ja auch osd chips die das können. die kommen mit 4x farbträger aus. also mit 16 oder 20 mhz ist doch ausreichend spiel, wenn man sich auf eins zwei farben festlegt, oder?
Hallo. Ich bin relativ jungfräulich, was AVR's angeht ;-) habe das Pollin Eval.Board 2.0 aufgebaut, ein paar Bascom Progrämmchen geschrieben und alles funktioniert sogar.. Ich möchte das Pacman - ATmega8 Projekt jetzt gerne bauen und habe ein paar, wahrscheinlich blöde Fragen: Was für ein Videosignal/Ausgang ist das, bzw. was kann/muss ich da anschließen? BAS-Monitor? Scart-Anschluß? Zum aller ersten Test (Einschaltbild/Intro-Screen), dürfte es reichen: 1. das HEX-File mit PonyProg in den ATmega8 zu flaschen. 2. die Fuse-bits so zu setzen, das der externe 16MHz Quartz genutzt wird. 3. die beiden Widerstände und das Videokabel abzuschließen. Die 'Joystick-Schalter' kann ich, nachdem ich ersteinmal ein Bild habe, ja immer noch nachrüsten.. Ist das so korrekt? Danke für die Hilfe, Peter
Hurra!!! Siehe hier: http://puppylinux.abcde.biz/c/?AVR:Pacman_mit_ATmega8 Um vernünftigen Credit für die Entwiklung zu geben, bitte ich den Authoren von AVR Pacmania, sich mit mir in Verbindung zu setzen! Vielen Dank!! Super Sachen!! Peter
Thread beobachten
Seitenaufteilung abschalten
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.