Hallo, ich habe mir in den Kopf gesetzt so etwas wie ein Retro Spielkonsole ala C64/Amiga/AtariVCS zu entwickeln. Dabei soll das Hauptaugenmerk auf einem günstigen Preis, einfacher Verarbeitung, Verwendung und Spieleentwicklung liegen. Damit das ganze auch Spaß macht und "Einsteiger" nicht schnell frustriert sind. Als technische Details habe ich mir überlegt: 8-16Bit Audio ca. 320x240 non interlaced RGB PAL Video Ausgabe Scrollbare Hintergründe Sprites Der "Hauptcontroller" soll so intelligent wie möglich sein und schon genügend Funktionen mitbringen für z.B. bitblitting für Grafiken, Sprites, scrollen der Hintergründe, möglicherweise auch Audio manipulation z.B. pitch etc. In ihm soll auch ein einfacher Interpreter für die Spieleprogrammiersprache sein, denn ich möchte niemandem zumuten Spiele mit einer art Assembler programmieren zu müssen. Das wird dann durch ein PC programm dem compiler, von einfacher Scriptsprache zu von der Konsole interpretierbarem maschienencode, gemacht. Die Spiele sollen dann als Binärdatei auf ner Speicherkarte liegen. Hatte auch an sowas wie ein "AtariVCS Modul" mit nem großen eeprom gedacht, weil ich die Dinger einfach cool finde, aber ich glaube eine Speicherkarte ist da zeitgemäßer. Was würde man da für einen controller benötigen? Ich denke mal unter ARM7/9 braucht man da garnicht erst anfangen, was ich persöhnlich schade finde da die alten "Kisten" ja auch nur 1-8 MHz schnell ware aber die hatten ja auch Spezialchips welche die Hauptarbeit übernommen haben. Was für einen Speicher könnte man verwenden? Ein normales statisches RAM (55-70ns) würde zwar für die Videoausgabe völlig ausreichen (bei der Auflösung ca. 150ns pixelclock) aber ist wohl für Funktionen wie bitblitting, scrollen etc. einfach zu langsam. Vielleicht ginge es ja auch ein paar Dinge wie z.B. die Video- oder Soundausgabe in einen CPLD auszulagern um den Hauptcontroller zu entlasten, lasse mich da gerne belehren. MfG HansFranz
Parallax Propeller, eindeutig. Schon allein, weil er Video ausgeben kann.
... an den propeller hatte ich auch schon gedacht, weil der auch ziemlich günstig ist für die features die er hat, aber der könnte vielleicht zu wenig IOs haben alleine für den Speicher würden ja schon ca. 28 draufgehen, dann gibts noch keinen sound, die inputs von den gamepads müssen auch noch irgendwie rein, könnte zuknapp werden.
Speicher? ROM oder RAM? Seriell ansprechen ist beim Propeller da die einzug sinnvolle Lösung, obwohl man notfalls vielleicht Portleitungen multiplexen könnte. Wenn man die Sache liebert durch rohe Rechenleistung als durch raffiniertes Design erschlagen will, LPC2378. Der kann einen externen 8-Bit-Datenbus benutzen, obwohl er eine interne 32-Bit Architektur hat. Lohnt sich auch preislich, da in industrieüblichen Stückzahlen fast unschlagbar billig, aber man muß entweder direkt auf der Hardware aufsetzen oder ein RTOS benutzen: Richtiges Linux geht erst mit ARM9, z.B. dem RM9200 von Atmel. Die Komplexität der Hardware steigt dann aber erheblich, und das Layout wird auch nicht mehr trivial mit dem SDRAM.
Speicher = RAM also da wo die Daten zur videoausgabe hinterlegt und manipuliert werden. Seriell wäre eine möglichkeit, aber ein erheblicher Geschwindigkeitsverlust. Hatte auch schon an sowas wie einen Bus gedacht, ala der controller haut 4 bytes raus, 18 oder 19 bit addresse + rest als Kommando (lesen/schreiben), 1 byte Daten + eine Leitung für jetzt Daten vom Bus übernehmen. Das ganze geht dann auf eine Art busarbiter (CPLD oder mikrocontroller) der dann halt das RAM steuert. Damit könnte ich ja theoretisch mit 8 Takten + write/read cycle Zeit des RAMS darauf zugreifen, was aber auch immer noch sehr langsam ist. Es bleibt ja nur die Zeit die für den PAL retrace bzw. die sontigen PAL Steuerzeilen übrig ist um Daten im RAM zu verändern, irgendwas um die 80-100 Zeilen a 64µs habs jetzt nicht genau im Kopf.
Wenn du einen "double buffer" als video ram nimmst, hast du doch genug Zeit ...
mitderflachenhandvordiestirnklatsch...double buffer... ist auch ne gute Idee, daran hatte ich noch gar nicht gedacht!!! Vielleicht finde ich ja auch irgendwo noch n schnelleres sram als mein 55ns 512x8 von reichelt z.B. ein CY7C1049D-10VXIT 10ns 512x8 damit könnte man eigentlich intern rumkopieren soviel man lustig ist, groß genug für scrollbare hintergründe ist es und die spritedaten kann man auch noch drin ablegen. Dafür muss dann halt nur der controller schnell genug sein, der propeller schafft glaub ich max 80MHz wenn man die performance nicht auf mehrere cogs aufteilt. Schade das in cplds nicht genug platz ist um dort solche Aufgaben wie das bitblitting unterzubringen, davon hab ich hier noch welche rumfliegen XC9572 15ns, XL95144 10ns.
Zwar völlig OT, kommt mir aber gerade in den Sinn: Warum keine aktuelle billig Grafikkarte nehmen und Software schreiben die innerhalb der GPU läuft? Davon habe ich noch nie gehört...
Mein Langzeitprojektziel ist aktuell ähnlich. Ich wollte auch eine Art Spielekonsole basteln, aber weniger auf Retro. Bis jetzt habe ich einen Display (PSP Display) Controller in VHDL der auch schon läuft, auf nem selbstgemachten CPLD Board. Jetzt arbeite ich an einem ARM Board mit einem AT91SAM9XE, das ist n 200MHz ARM9. Sollen 64MB RAM und 128MB NAND Flash drauf. Das Grobe ist auch schon fertig, fehlen nurnoch so Kleinigkeiten (die dauern immer am längsten). Letztendlich soll eben eine Platine mit einem FPGA und dem ARM entstehen, wobei der FPGA als GPU und der ARM als CPU werkelt. Ich weiß, das ist hoch gegriffen, aber man muss sich doch große Ziele stecken. Ich habe zwar ein anderes Motiv als du (bei mir ist es zeigen, dass ich das kann, und dass man auch noch Sachen selber machen kann, statt immer nur SoCs nutzen) aber wenn du magst kann man sich ja trozdem mal zusammensetzen.
Vielleicht interessant für ein paar Anregungen: hive-project.de
...soo habe mich mal ein wenig mit dem Propeller beschäftigt, scheint leider nicht sooooo gut für meine Zwecke geeignet zu sein. Das "integrierte" Video interface finde ich schonmal nicht so dolle, zu kleine Auflösung, zu wenig Farben wenn man nicht den VGA modus nutzt. Und selbst wenn man den Videoteil von Hand machen würde, kommt mir das alles zu langsam vor mit dieser ganzen Spin geschichte und 8 Kernen die nacheinander auf die IOs zugreifen wollen etc. gut, Assembler wäre da auch möglich und schneller als Spin, aber alleine der Fakt das ein Zugriff auf dio IOs zwischen 8 und 23 Takten liegen kann jenachdem wann und wie er geschieht missfällt mir doch sehr. Ein einfacher risc controller wie z.B. ein Mega32 mit >60Mips ohne viel Schnickschnack dran wie 3 spis oder 4 uarts oder 12 ADC Kanäle, usb etc. wäre mir viel viel lieber. Ich denke mal ich schau mir die FPGA fraktion mal an, danach kommen dann die ARMs. In der Richtung muss doch irgendwas vorhanden sein mit >32 IOs, >60Mips in einem noch "vernünftig" für den hobbybastler verarbeitbarem Gehäuse, keine BGAs oder sowas, DIL wirds wohl nicht geben :(
HansFranz schrieb: > zu kleine Auflösung, zu wenig Farben wenn man nicht den VGA modus nutzt. Dann nutz ihn doch einfach ;-) HansFranz schrieb: > Zugriff auf dio IOs zwischen 8 und 23 Takten liegen kann Nö. Die IOs sind fixer. Nur der 'große' RAM-Bereich ist von dieser Einschränkung betroffen. Die IOs finden sich in den Registern eines jeden Cogs und können dort direkt angesprochen werden. Gruß Jobst
na kein VGA, es soll ja ans TV angeschlossen werden und nicht an nen Monitor. Besitze auch leider kein LCD TV mit VGA anschluss und kann das auch nicht von allen anderen erwarten, also kein VGA. > Nö. Die IOs sind fixer. Nur der 'große' RAM-Bereich ist von dieser > Einschränkung betroffen. Die IOs finden sich in den Registern eines > jeden Cogs und können dort direkt angesprochen werden. sorry dann hab ich das wohl mit dem hub verwechselt! hmm ok dann ist er wohl doch noch n zweiten und dritten blick wert
HansFranz schrieb: > na kein VGA, es soll ja ans TV angeschlossen werden und nicht an nen > Monitor. Besitze auch leider kein LCD TV mit VGA anschluss und kann das > auch nicht von allen anderen erwarten, also kein VGA. Dann ist aber nicht der Propeller der limitierende Faktor, sondern das Ausgabegerät! HansFranz schrieb: > sorry dann hab ich das wohl mit dem hub verwechselt! hmm ok dann ist er > wohl doch noch n zweiten und dritten blick wert Ist er. Das einzige, was wirklich komisch ist, ist, daß das Ding erst mal in einem Interpreter-Modus (Spin) startet, aus dem man sich befreien muß, wenn man Assembler programmieren möchte :-/ Mit Spin ist das Ding verhältnismässig lahm ... Gruß Jobst
...hmm der propeller will mir trotzdem nicht so wirklich gefallen... schade das der SX abgekündigt wurde, der wäre echt gut geeignet. Momentan liebäugele ich mit einem kleinen PIC32MX320 Tqfp64 läßt sich irgendwie noch verarbeiten, IO toggling bis zu 80MHz, 64K flash, 16K sram, 53 IOs, klingt fast zu gut um wahr zu sein. Hat mit dem vielleicht schonmal jemand gespielt?
mal O.T. kann man tqfp 0.5mm pitch mit nem heißluftfön anlöten oder besser nicht? Habe da schon die unterschiedlichsten Meinungen zu gehört, mein erster Plan wäre die pads auf der Platine dünn verzinnen, das Bauteil dann mit Stückchen Klebe (Pr*t Stift) in Position bringen und etwas antrocknen lassen, dann die Heißluft auf die erste Reihe Beinchen halten, abkühlen lassen, dann 2. Reihe, abkühlen etc.. Vielleicht das IC selbst noch mit nem Stück Metall beschweren, diehnt dann auch etwas der Hitze abfuhr... oder halt das ganze von der Unterseite der Platine mit Heißluft befeuern bis das ic fest ist, halte ich aber eher für die schlechtere Lösung...
TQFP mit 0,5mm Pitch mit Heissluftfön ist kein Problem.. Schon 1000-Fach gemacht und keine Ausfälle. Stencil-Maske nehmen und mit Lötpaste löten!
Alternativ geht wohl auch die Methode, einfach mit dem Lötkolben und Lötzinn einen Schwung über die ganze Pinreihe zu machen, dann mit Entlötlitze die Zinnbrücken und allgemein überschüssiges Lötzinn zu entfernen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.