Announcement: there is an English version of this forum on Hallo, eigentlich ist das Folgende eher eine Projektvorstellung, aber da es für sowas ja kein Board gibt und ich auch Code habe, poste ich's mal hier. Das Ganze soll, wenn es fertig ist, mal so eine Art selbst-gebastelter Gameboy (Your Own Do-it-yourself Avr Handheld :) ) werden, das vorliegende Tetris (http://paranoidsoftware.de/yodah.jpg) ist eher ein Prototyp. Hardware ist ein AtMega8, der mit 8 Mhz läuft, fünf Kurzhubtaster und ein Grafikdisplay (128x64) von Pollin (Best. Nr. 120 292) Schaltpläne habe ich leider noch keine gemacht, aber was wo rankommt ist eigentlich aus dem Code ersichtlich. Apropos Code, das Ganze ist sehr unaufgeräumt, weil es an einem Tag und bis kurz vor Mitternacht entstanden ist... Ein Video gibts hier: http://paranoidsoftware.de/yodah.avi Beste Grüße, Bartl
Ich find das Projekt Geil! Doof das ich grad bei Pollin bestellt hatte, sosnt hätt ichs glatt mal nachgebaut :(
tetris ist toll, hab ich schonmal mit nem ARM und dem S65 display gemacht. eigentlich gibt es bei tetris aber nur blöcke aus 4 Klötzchen. Wenn du es richtig machen willst solltest du die spiele auswechselbar machen. ein modulschacht im 2,54mm raster wäre eine möglichkeit, auf den modulen sitzt dann ein flash speicher der an das externe memory interface eines AVRs angeschlossen ist. Aber ich glaube man kann keinen code im externen speicher ausführen, dann müsstest du eine virtuelle maschine bauen - ein art Java interpreter wäre cool :) ich hatte das ganze mal mit nem großen ARM controller, einem SRAM und SD-Karte vor, bin aber zu unmotiviert :(
@Lupin: Da kannste dir auch nen GamePark 32 kaufen. Der besteht aus nem ARM mit SDRAM, Farb-TFT und SD-Card-Slot :) Und lässt sich wohl auch relativ einfach selber programmieren. Oder du wartest auf den Nachfolger (kann sein, dass der auch schon da ist. Habe mich schon länger nicht mehr informiert.)
>>Apropos Code, das Ganze ist >>sehr unaufgeräumt, weil es an einem Tag und bis kurz vor Mitternacht >>entstanden ist... Also soviel Code an nur einem Tag zu hacken ist nicht schlecht! Du solltest mal zu einem Programmierwttbewerb auf Zeit gehen und den 1. PLatz belegen :) Tolles Projekt! Gruss Tobias
> Aber ich glaube man kann keinen > code im externen speicher ausführen, dann müsstest du eine virtuelle > maschine bauen - ein art Java interpreter wäre cool :) Ich hatte mir einen Bootloader vorgestellt, der Spiele von einer SD Karte liest, aber da wäre halt das Problem, das a) der SD Zugriff zu aufwendig für einen Bootloader ist und b) man nur 10000 mal das Spiel wechseln könnte. Aber stimmt schon, eleganter wäre es allemal von einem externen Speichermedium. > Oder du wartest auf den Nachfolger (kann sein, dass der auch schon > da ist. Habe mich schon länger nicht mehr informiert.) Ja, den gibts auch schon. Heißt GP2X, aber kostet halt soviel wie ne PSP, was ich doch ziemlich teuer finde. Vielen Dank für die netten Kommentare und beste Grüße, Bartl
Sehr cool :). Will dieses Display demnächst auch ansteuern mit nem Mega8. Vielleicht aber seriell. Aber irgndwie weiss ich nicht wie schnell das Display daten empfangen kann, der controller da läuft ja nur mit 33khz. Ich selbst dachte da so an Snake, oder auch ein langsames oszi^^
Wenn jemand bei Pollin bestellt, kann er mir dan ne kleine Nachricht zukommen lassen? Würde dann ggf ein Display mitbestellen :)
@Steven Kienast Aus dem Datenblatt geht hervor, dass um das serielle Interface zu benutzen der Pin P/S auf 0 gelegt werden muss. Da dieser Pin vom Modul aber garnicht nach ausen gefuehrt wird nehme ich mal an, dass man es auch nur im 8bit Betrieb verwenden kann. Gruss Tobias
Achso, verdammt ^^. Der Controller ist auch für größere Displays (132*35) wenn ich das richtig sehe. Fängt das vom pollin nun auch ganz vorn an und bei 128 is schluss?
wie hast du das display denn angeschlossen? im bild sieht man zwar ein paar kabel aber das ding hat ja eigentlich einen Folientecker für den man ja eine Platine braucht :(
Angehängte Dateien:
-
pollinlcd.jpg
160 KB
Hi, man kann den Folienstecker auch direkt auf eine Platine loeten. Das habe ich gestern mal gemacht und es funktioniert im Prinzip auch. Leider habe ich aber die Folie wohl zu oft in der Naehe des Steckers gebogen und jezt hat sie dort einen Wackelkontakt... Das naechstemal werde ich vorsichtiger sein, wenn ich den Kunststoffstreifen entferne, der dem Ende mehr Stabilitaet geben soll, aber der Hitze beim Loeten nicht stand haellt. Gruss Tobias
Ich hab den Folienstecker jetzt einfach abgezogen und werd da morgen nen Flachbandkabel dranlöten :)
Optimal wäre natürlich so ein Steckverbinder wie er auf der Adapterplatine drauf ist, wie sit die eigentlich beschaltet? Könnte man nicht die Adapterplatine sozusagen als Steckverbinder nutzen?
Ich seh gerade das das nen Bausatz ist.. also im Prinzip optimal um an so einen Stecker zu kommen, die Platine kann sogar recht leicht als Adapter umgebaut werden.
beim durchlesen fand ich das interessant, als ich das bild gesehen hab fand ich es toll ;). Und nachdem ich das video gesehen hab bin ich recht begeistert! wirklich ne schöne sache geworden, ich bin vor allem überrascht wie stabil das ganze mit dem wenigen code schon läuft! was mich aber hauptsächlich interessiert ist die ansteuerung des displays am mega8. ich hab das gleiche gekauft weil ich hier mal den code dazu gefunden hab, allerdings benutzte derjenige die ganze platine von pollin und ziemlich viele ports. ich hab das nie zum laufen gebracht. deine ansteuerung sieht ziemlich einfach aus, nur 5 ports dran und es geht. ich würd das jetzt sofort testen aber dieses blöde display hat diesen folienstecker, wie zum teufel krieg ich da kabel oder sowas dran? vielen dank :)
achja noch ne frage, wenn ich das kompiliere ist die main.hex 20kb groß, wie passt denn das in den mega8 rein?
@Philipp Dir ist wohl nicht aufgefallen, dass der komplette PORTB fuer D0-D7 verwendet wird und die restlichen 5 PINs nur zusaetzliche Steuerleitungen sind. Gruss Tobias
oh, natürlich nicht... dann komm ich damit auch nicht so ganz weiter, danke für den tipp ;). meine platine belegt nämlich leider die PB6/7.
@Display anlöten: > Ich hab den Folienstecker jetzt einfach abgezogen und werd da morgen > nen Flachbandkabel dranlöten :) Hab ich auch gemacht. War ein bisschen fummelig, weil mein Flachbandkabel nen zu großes Rastermaß hatte, aber mit 0.8mm und nem feinen Lötkolben sollte es eigentlich gut gehen. > oh, natürlich nicht... dann komm ich damit auch nicht so ganz > weiter, danke für den tipp ;). meine platine belegt nämlich leider > die PB6/7. Du kannst natürlich beliebige Portpins für die Steuerleitungen nehmen, insbesondere wenn du keine Daten vom Display lesen willst, kommst du auch mit zwei Steuerleitungen (A0 und E) und den acht Datenleitungen aus. Wenn du für die Datenleitungen einen kompletten Port nimmst hat das allerdings den Vorteil, dass du ein Byte ohne Overhead an das Display schicken kannst. Andernfalls musst du das Datenbyte eben auf die verschiedenen Ports aufteilen. Allgemein ist die Ansteuerung vom Display wirklich simpel, beim Download von Pollin (http://www.pollin.de/shop/downloads/D120292D.RAR) sind Datenblätter vom Controller und dem Display sowie ein Beispielprogramm in Delphi dabei. > achja noch ne frage, wenn ich das kompiliere ist die main.hex 20kb > groß, wie passt denn das in den mega8 rein? Bei mir (avr-gcc 3.4.3, -Os [auf Größe optimieren]) sieht's so aus: Program: 7484 bytes (91.4% Full) (.text + .data + .bootloader) Kann mir eigentlich nur vorstellen, dass es an der Optimierung liegt. > Aber ich glaube man kann keinen code im externen speicher ausführen, > dann müsstest du eine virtuelle maschine bauen - ein art Java > interpreter wäre cool :) Über die Idee hab' ich nochmal nachgedacht und eigentlich ist sie nichtmal abwegig. NanoVM ist denke ich für diese Zwecke etwas zu langsam und eigentlich auch überdimensioniert. Ich hätte an LUA gedacht, aber die ist auch nicht kleiner. Kennt jemand von euch eine einfache Scriptsprache mit C als Host, die sich für einen uC anpassen ließe? Beste Grüße, Bartl
>achja noch ne frage, wenn ich das kompiliere ist die main.hex 20kb >groß, >wie passt denn das in den mega8 rein? >Program: 7484 bytes (91.4% Full) >(.text + .data + .bootloader) >Kann mir eigentlich nur vorstellen, dass es an der Optimierung >liegt. Ihr redet über verschiedene Dinge. Die main.hex ist 20kb, *.hex ist aber kein Binärfotmat. BTW, schönes Projekt. Gruß Matthias
Irgendjemand hat oben gesagt, wenn man das Programm jedesmal über einen bootloader vom externen Flash in den MC lädt, kann man nur 10.000 mal Spiel wechseln. Ich bin jetzt grad zu faul rauszusuchen wer's gesagt hat. Aber meint ihr nicht auch, dass bei 10.000 Spielewechseln der Stecker schon längst aufgegeben hat? Ausserdem hatte ich irgendwie sowas von 100.000 mal programmierbar im Kopf beim Flash. Kann sein dass ich mich irre, aber wenn nicht, dann gibt ziemlich sicher erst der Stecker auf. Oder du verlagerst gleich einen Teil der Intelligenz auf das Speil. Im Gerät selbst wird nur noch das Display angesteuert, die Tasten ausgewertet und und der Ton produziert. Jedes Spiel hat dann seinen eigenen MC der das eigentliche Spiel laufen lässt und nur noch Bild und Ton info an den anderen MC schickt und die Tastenbefehle von ihm empfängt. Ansonsten natürlich: Respekt vor so einer Leistung. Hast du das Programm komplett von der Pike auf an einem Tag geschrieben, oder standen teile (z.B. die Displayansteuerung) schon vorher? Sebastian
> Irgendjemand hat oben gesagt, wenn man das Programm jedesmal über > einen bootloader vom externen Flash in den MC lädt, kann man nur > 10.000 mal Spiel wechseln. > Ich bin jetzt grad zu faul rauszusuchen wer's gesagt hat. Das hab ich gesagt :) > Ausserdem hatte ich irgendwie sowas von 100.000 mal programmierbar im > Kopf beim Flash. 100000 mal ist beim EEPROM. Aber ich denke eigentlich, das die Kontakte 10.000 mal stecken schon aushalten sollten, außerdem könnte ein SD-Karte ja im Slot bleiben und es würde nur das gewählte Spiel geladen. > Oder du verlagerst gleich einen Teil der Intelligenz auf das Speil. Das hab ich mir inzwischen auch gedacht. Ich hab mich mal ein wenig umgesehen und ich denke die einfachste Möglichkeit wäre eine sog. "stack machine" auf dem uC (http://www.gamasutra.com/features/19971003/huebner_01.htm, muss man sich leider kostenlos anmelden) und ein einfacher Compiler mit FLEX/BISON auf der PC-Seite. Das sollte auch einigermaßen schnell sein, da der uC direkt Opcodes bekommt, von denen nur sehr wenige benötigt werden. Hat von euch schonmal jemand sowas gemacht, bzw. wie stark unterschätze ich den Aufwand? :) > Hast du das Programm komplett von der Pike auf an einem Tag > geschrieben, oder standen teile (z.B. die Displayansteuerung) schon > vorher? Die Tastenentprellung war schon fertig (was man ihr auch ansieht, für das Tetris ist sie eigentlich ziemlich unpassend) und die Displayansteuerung war vom Abend davor, aber mit dem ganzen Material vom Pollin hat das Anlöten vom Display länger gedauert als das ansteuern. Beste Grüße, Bartl
hab jetzt auch das display... ich habe mal versucht zu lesen, dazu habe ich das gleiche gemacht wie beim schreiben auf das display nur das ich RW high gemacht habe und danach das PIN register eingelesen habe - ist doch richtig oder? Aber da kommt nix sinnvolles bei raus. Dein code ist außerdem sehr gut, ich glaube du solltest aber die PGM funktionen benutzen um vom flash zu lesen. Was passiert eigentlich wenn man die Daten nicht mit PROGMEM definiert? Gehen die dann ins RAM (da passt das ja gar nicht hin)?
> hab jetzt auch das display... ich habe mal versucht zu lesen, dazu > habe ich das gleiche gemacht wie beim schreiben auf das display nur > das ich RW high gemacht habe und danach das PIN register eingelesen > habe - ist doch richtig oder? Lesen habe ich noch nicht ausprobiert, allerdings musst du vorher den Port als Eingang schalten (DDRX) und das Display liefert, nachdem du eine bestimmte Speicherstelle ausgewählt hast, erst beim zweiten Lesebefehl sinnvolle Daten ("Dummyread", siehe Datenblatt vom SED). > ich glaube du solltest aber die PGM funktionen benutzen um vom flash > zu lesen. Kann gut sein. Allerdings funktioniert meine jetzige Lösung gut und die PGM Funktionen tun soweit ich weiß auch nichts groß anderes. > Was passiert eigentlich wenn man die Daten nicht mit PROGMEM > definiert? Gehen die dann ins RAM (da passt das ja gar nicht hin)? Ja, genau. Wobei man sich den Demobildschirm natürlich sparen könnte, aber bisschen flashig soll's auch sein ;) Falls du deinen eigenen Titelschirm haben willst, kann ich dir das Delphiprogramm zum Konvertieren mailen. Beste Grüße, Bartl
Hallo, gratuliere zu diesem Code. Kannst Du mir bitte das Programm zum konvertieren mailen? info@verbrennerheli.de Gruß Michael
Ich hab' das Programm mal auf meine Webspace geladen: http://paranoidsoftware.de/bmp2crle.zip (Quelltext ist enthalten) Das Programm ließt Windows-Bitmaps, die möglichst n*8 Pixel hoch sein sollten. Ausgegeben wird eine .h-Datei, in der das Bild als char array abgelegt ist, so dass es direkt an das Display geschickt werden kann. Das erste Byte ist hierbei die Breite des Bilds, die der AVR-Code aber bisher nicht benötigt, muss also noch entfernt werden. Wahlweise kann die ausgegebene Datei noch Run-Length enkodiert werden (kA wie das in deutsch heißt), das dekodieren ist aber auf dem AVR noch nicht implementiert. Beste Grüße, Bartl
hat einer von euch schonmal versucht eine putpixel funktion für dieses display zu schreiben? ich versuche das gerade mit den einzelnen pixelspalten gestaltet sich das aber etwas schwieriger..
Hab ich bisher noch nicht gebraucht und ist auch meiner Meinung nach von der Performance her nicht sinnvoll. Aber im Prinzip musst du doch nur den entsprechenden Pixelblock laden (siehe Zeug aus dem RAM lesen, Datenblatt), den Pixel verändern und den Block wieder schreiben. Das Problem dabei ist meiner Meinung nach der Overhead: Du musst dem Display sagen, welchen Block du willst, dann einen Dummyread machen, dann den richtigen Wert lesen und bearbeiten dem Display dann nochmal den Block mitteilen (weil der Controller ja eine Spalte weiter rückt, wenn du den Wert ließt) und dann den neuen Wert schreiben. Falls du die Funktion unbedingt brauchst, würde ich einen größer µC nehmen einen Backbuffer im RAM lassen. Für was bräuchtest du die Funktion denn? Beste Grüße, Bartl
jo das mit dem backbuffer hab ich mir auch gedacht, könnte man aber rein theoretisch auch mit nem mega32 hinkriegen. Ich glaub ich probier das mal, hab nur irgendwie angst dass es total lahm ist ;).
so hab das ganze jetzt mit einem backbuffer auf dem mega32 realisiert!
Klappt super, ich finds auch nicht lahm :). Im Anhang ist der code!
Ein beispiel könnte so aussehen:
int main()
{
lcd_init();
glcdinitscreen();
while(1) {
glcdclearscreen();
glcdprintf(0,0,"Das ist ein Test!");
int x=rand()%128;
int y=rand()%64;
glcdputpixel(x,y);
glcdrefresh();
}
return 0;
}
Es wird die Font aus dem anderen Beitrag über dieses Display in der
Codesammlung benötigt! Viel Spaß.
Wie groß ist eigentlich die (sichtbare" Größe des Displays? Bei Pollin ist soweit ich gesehen hab ja nur die gesammtgröße angegeben. Weil ichwollte mir auch son Display holen udn ggf in nen Rahmen einseztenaber deswegen wärs mal gut zu wissen wieviel "Rand" das teil hat (nen Fertigen passenden Rahmen wirds ja warscheinlich nicht geben)
achja und vorsicht beim löten des flachbandkabelsteckers wenn man sich die platine holt, die übrigens SEHR nützlich ist. Das ding hat leider SMD größe. Graue haare vorprogrammiert :(.
Ich habe mal gesehen dass jmd einen AVR in nem CPLD nachgebaut hat. vielleicht könnte man die sources verwenden und so nen AVR mit externem speicher "bauen"
Wäre eventuell eine Option, aber einerseits müsste ich mich dann mit CPLDs auseinander setzen, was finanziell und auch sonst ein Riesenaufwand ist und außerdem wenn man schon eine Maschine emuliert, kann man ja auch eine einfache Stack-Maschine auf dem AVR laufen lassen. Ich bin momentan ein bisschen mit Abi und dem zugehörigen Spiel beschäftigt, aber in zwei Wochen ist alles vorbei, dann schau ich mal weiter. Beste Grüße, Bartl
Hi Bartholomäus, ich hab ein paar Fragen zu dem Program/Display - bin totaller Newbie. 1.Bei Textausgabe: memcpy_P(&temp, &font[charx*5+x], 1); LCD_Write(1,temp); warum nicht einfach LCD_Write(1, font[charx*5+x]); 2. Du schreibst: SIGNAL(SIG_OVERFLOW2) und packst hier die Tastaturabfrage 'rein. Ich hab nirgends gefunden was "SIG_OVERFLOW2" bedeutet. Ist evtl. nicht so schlimm, ich schau halt wie ich das auf meinem AVR Butterfly dann machen muss - aber wo kann ich über signal/interrupts lesen. Und was ist der Unterschied? 3. Gibt es key-bouncing noch, also wenn ich Taste drück', dass dann eine Flut von 1-0-1-0-1-1-1-1-1 kommt, bis der Taster wirklich unten ist? Und: reicht da ein "SIGNAL" Abstand dazu aus (Keys[i].delay) um das zu kompensieren? 4.Das Display steuerst Du in x-richtung per Pixel an, in y-Richtung per "zeile" also 1/8 mit je 8px Höhe. Seh' ich das Richtig? 5.Wenn ich einen Pixel setzen will, kann ich das Display modifizieren, und dann einen Befehl schichen "jetzt den Speicher darstellen", oder wird die Änderung sofort übernommen - sprich: brauche ich meinen eigenen Display-Speicher zum "wursteln" und schick den dann komplett geändert zum Display? 6. Wenn ich das byte (0x01) an das Display schicke, ist das dann der obere, oder der untere Pixel der Zeile den ich setze? 7.Wie schnell wäre ein kompletter 1024byte transfer zum Display? Ich bau' dann mal eine linien und per-pixel-grafik engine für das Display. Poste ich dann hier, dass es alle haben können.
Wegen Spiel aus dem Speicher laden: Könnte man nicht einen Bootloader mit fester Größe machen, der dann erstmal prüft ob der Flash schon mit der MMC übereinstimmt, und wenn nicht dann eben diesen in den Flash Speicher nach dem Bootloader reinpackt und ausführt? Man müsste das Programm dann irgendwie so schreiben, dass der Bootloader evtl immer mit drin sein muss... oder so.
Wäre auch eine Option, aber ich finde eine kompakte virtuelle Maschine (z.B. eine Stack Machine) momentan verlockender. Zumal eben der FAT Code schon relativ groß ist, womit dann der Bootloader auch wieder sehr groß werden würde und für das eigentliche Programm kaum noch Platz wäre. Bei einer virtuellen Maschine wäre die Größe des ausgeführten Programms eigentlich nur durch den Adressraum begrenzt, d.h. 64 kByte wären drin, soviel kann sonst kein AVR. Beste Grüße, Bartl
diese begrenzung muss aber nicht sein. Kann man natürlich so programmieren, dass beliebig viel addressiert werden kann. Hast das LPC2103 bzw LPC2124 board im shop gesehen, die sind jetzt sehr günstig? Damit könntest du deiner virtuelle maschine etwas mehr leistung verpassen
Also "beliebig viel" halte ich für unmöglich :) Die Sache ist halt die, dass eine 32-Bit Adressierung wahrscheinlich die Sache recht langsam macht. Und 64 kByte ist immerhin noch acht mal soviel wie ein Mega8, ich denke des sollte für die meisten Spiele schon reichen. Insbesondere wenn FAT-Funktionen zur Verfügung stehen, sodass Daten nicht in das Programm mit rein müssen. Der LPC210x sieht wirklich sehr schick aus. Ist halt nicht gerade schön zum Löten, aber den werde ich mir in jeden Fall bei Gelegenheit mal genauer zu Gemüte führen. Allerdings wäre bei soviel Rechenpower schon fast ein besseres Display eine schöne Sache... Viele Grüße, Bartl
problem ist nur, dass deren serielles interface zu lahm ist um ein besseres display schnell genug zu füttern. Bei meinem Tetris mit dem S65 display hab ich bei minimalen rechenaufwand nur 17 FPS geschafft (war der LPC2106). Dafür sind die atmel ARMe besser geeignet (finde ich allgemein besser) Momentan entwerfe ich ein board mit einem atmel ARM, hatte erst das 3310 display im sinn werde mich aber wohl um entscheiden auf das gute alte S65 display ;)
Was hat das S65 Display denn eigentlich für Daten? So groß dürfte die Auflösung da ja auch nicht sein, oder? Und mir fallen halt auf einem 128x64 Pixel S/W Display nicht so viele Spielekonzepte ein, die soviel Rechenleistung wirklich brauchen.
Bartl, kannst Du das mal anschauen? Ich hab' mal ein Win32 Projekt gemacht, das man schnell in ein ATmega programm umschreiben kann. Ich hab' leider noch keinen Prozessor für mein Display. Könnest Du mal schauen, ob der Code grobe Fehler hat, oder ob das so geht? Evtl. mal auf deinem Yodah probieren? Such einfach nach #NEED, das ist wo man was ändern müsste.
Im großen und ganzen siehts gut aus auf den ersten Blick. Bei > int avr_main(int argc, char* argv[]) > { > char dir; sollte "char dir;" aber eins eingerückt sein ;) Die Textausgabefunktionen solltest du 1:1 aus meinem Code übernehmen können. "In echt" kann ich's leider gerade nicht ausprobieren, weil die untere Hälfte von meinem Display seit einiger Zeit nix mehr anzeigt (Pollin halt...) und ich noch nicht dazu gekommen bin, das zu reparieren oder ein neues Display ranzulöten. Beste Grüße, Bartl
Falls es noch irgendwen interessiert: Ich hab' noch eine neue Version gemacht, die einige Bugs behebt und außerdem die Möglichkeit vorsieht, eine Highscore im eeprom zu speichern und -ganz wie '70- drei Initialen zu hinterlassen. Beste Grüße, Bartl
;-) cooles Gameprojekt. Ich hätte da schon das zweite Game zu dem noch nicht vorhandenen GameAVR ;-) schauts euch mal an: Download hinweise: Werbung wegklicken, dann auf Download Button klicken. http://www1.file-upload.net/download_10.06.06/n2ihqg.rar.html
Snake - coole idee. Verbesserung: Du hast ja 2 Bildschirme, also kann st Du immer die Schlange des Gegners rastern(also Schachbrettartig füllen), damit man die Beiden unterscheiden kann. Das wär' auch interessant für das Frogger-Spiel. Man könnte machen, dass man auf die andere Seite kommen muss und somit auch dem anderen im Weg stehen kann....
Hallo. Das genannte Display ist mit der Bestellnr. bei Pollin nicht mehr verfügbar.. Es gibt aber mind. andere mit 128x64 und KS 107/8 kompatiblem Kontroller: LCD-Modul TG12864B-03/05/13 - Bestellnr. 120424/5/3 Ist dieses kompatibel? Kann ich es so direkt am ATmega8 für dieses Tetris verwenden? Peter
Ob die Beschaltung 100% gleich ist, kann ich nicht sagen. Allerdings sollte das Display, falls es sich einen kompatiblen Controller hat, mit minimalen Hard- und Softwareänderungen anbauen lassen. Ansonsten sollten sich die Grafikroutinen eigentlich für fast alle Grafikdisplays anpassen lassen. Das Ganze ist in jedem Fall was für Bastler, wer nur ein mobiles Tetris will, ist mit einem Gameboy sicher besser beraten :) Beste Grüße, Bartl
ok. Im Sourcecode steht leider kein Display/Controlertyp drin.. Ich habe weiter oben einen Pollin-Link gefunden, der auch noch funktioniert. Dort ist von einem SED1565 Controler die Rede. Die aktuellen Pollin Display haben aber einen KS0107/8 kompatiblen Controler... passt wohl also nicht.. Danke trotzdem ersteinmal.. mach mich mal auf die Suche nach einem SED1565 Display.. Peter
Wie gesagt, der ganze Quellcode ist abscheulich zusammengehackt und war auch eigentlich nur als Proof of Concept gedacht. Die Ansteuerung von den Displays ist aber im Großen und Ganzen nicht sehr schwer, wenn du also Spaß am Basteln hast (wovon ich mal ausgehe, wenn du hier postest), nimm das erstbeste Display was du kriegen kannst (am besten mit eigener Konstrastspannungsversorgung, spart Arbeit) und schreibe die Grafikroutinen oder das ganze Spiel neu.
Hallo. Ach da hab ich schon viieell schlechtere Programme gesehen ;-) Es scheint als wenn z.Zeit solche Display einen KS0107/8 oder kompatiblen Kontroler einsetzen.. Ja ich weiß, das man das umsetzen kann.. mit der nötigen Zeit, Erfahrung, Ausdauer.. etc. mal sehen, evtl. was für die Winterzeit.. Z.Zeit baue ich ersteinmal Pacman mit TV-Ausgang nach... Trotzdem. Großes Lob! Dieses Tetrisprojekt ist einfach super! Gruß, Peter
Im Vergleich zu Pacman mit TV-Ausgang ist das Tetris wirklich simpel. Aber freut mich, wenn es dir gefällt.
Angehängte Dateien:
-
IMG_0299.jpg
55 KB
und noch ein tetris projekt atmega128/siemens s65 display tetris portiert von c# (nettrix, Beginning .NET Game Programming in C#, apress) nach c gruss
Ganz nett... gert du machst aber nicht für jeden frame einen kompletten redraw oder? wohl eher nur die Tiles, die sich verändert haben - so hab ich das jedenfalls gemacht. Ich denke das Problem beim S65 Display ist die Daten schnell genug rüber zu schaufeln...
hi bin auf 16mhz und den spi auf douple speed - geht recht flott ja es wird nur der block immer neu gezeichnet - ausser es gibt volle zeilen, dann das ganze gamefield der c# code ist aus 'Beginning .NET Game Programming in C# - nettrix' - downloadbar bei apress danke
Mal ne Frage, weiß wer wo man (zu aktzeptable preisen) sowas wie ne Gameboxkartrige (+Connector) beziehen kann? Muß keien Orginal sein aber ich such schon ewig sowas in der Art, hat jemand ne Idee?
Ich hab mir das PinPong Spiel von Conrad geholt. Kostet 5Euronen und mit ner Schnittstelle und nem quarz drauf kann man tolle sachen mit machen. Hab dafür jetz auch erstma tetris gemacht :)
Hallo ich bin neu hier im Forum und wollte mal Frage ob du ein Schaltplan rein posten kannst, bin noch anfänger im bereich elektronik ich such schon seid langem so ein Thread da ich noch am C++ lernen bin weiß ich auch nicht genau aus dem code wie ich das ganze aufbauen soll. Außerdem kann ich acuh ein anderes Display verwenden z.B. Pollin BestellNr. 120 245. Es ist echt ein faszinierendes Projekt, ich freue mich über alle Antworten. Mfg Korhan
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.