Alte Gamekonsole: Wie schaffen die das?

> Die alten Gamekonsolen haben alle einen Videoprozessor, meistens
> funktionieren die nur mit Sprites. Man ist also nicht darauf angewiesen,
> immer das ganze Bild im Speicher zu haben.

Ja, aber die Sprites müssen ja auch irgendwo gespeichert werden - zählt 
dieser Speicher etwa nicht zum Videoram? Die 64 beim NES darstellbaren 
Sprites belegen immerhin auch schon ungefähr 5 kB.

Und für dieses Bild braucht man wohl definitiv mehr als 64 dargestellte 
Sprites: http://forum.romov.net/files/yo__noid_nes_screenshot2_311.jpg

Oder auch so etwas:
http://www.nesgames.co.uk/images/screeny_nes_mario1.gif

Kennt jemand eigentlich einige Links zu selbst gebauten Spielkonsolen?

Mir ist aufgefallen das eigenbau Spielkonsolen mit wechselbaren Spielen 
doch sehr selten sind. Hat das einen grund?

Habe mal ein Systhem gesehen was 3 spiele eingebaut hatte, aber das 
waren nur diese "Ping Pong Strich Spiele" (soll nicht abwertend gemeind 
sein, ist bestimmt sehr schwer sowas zu bauen und zu programmieren)

Ein besonders eindrucksvoller Vertreter der Kategorie "Ping Ping Strich 
Spiele" ist auf http://www.cyberniklas.de/pongmechanik/ zu sehen. Man 
beachte, daß es ganz ohne Prozessor, Speicher oder andere 
Halbleiterelemente auskommt.

> Kennt jemand eigentlich einige Links zu selbst gebauten Spielkonsolen?

Hab selbst mal was gebastelt: 
http://www.thinkcool.ch/index.php?content=cgen;id=32;team=technik (Doku 
ist ziemlich ausführlich)

Zurzeit arbeite ich an einer Farbgrafik-fähigen Konsole - genau deswegen 
bin ich ja auch auf den Thread hier gekommen. Hab mal ein bisschen die 
alten Gamekonsolen mit meinem groben Entwurf verglichen, und kam mir 
dann ein bisschen dumm vor :-)

Naja, mal sehen, was ich von den angesprochenen Ideen so alles in mein 
CPLD kriege...

> Leg mal das Gitter auf das Bild, dann kannst Du sehen wie wenig
> (verschiedene) Kacheln da eigentlich sind.

Ja schon - aber es sind sicherlich mehr als 64 gleichzeitig dargestellt. 
Und z.B. für Textausgabe werden es dann doch einige verschiedene. Und 
kann der Grafikprozessor tatsächlich in Echtzeit aus den Sprites und 
ihren Koordinaten ein Videobild zusammenschustern? Also die CPU mit 1.77 
MHz schafft das bei einem Pixeltakt von knapp 5 MHz auf gar keinen Fall 
auch nur ansatzweise!

sowas hier?

http://www.embeddedartists.com/products/boards/lpc2104_pro002.php

.. hätte da fast mitgemacht :-)

nochmal eine andere console (ziemlich genial, da mit propeller-chip, dh. 
8 cores):

http://en.wikipedia.org/wiki/Hydra_Console
http://www.parallax.com/detail.asp?product_id=32360
http://www.xgamestation.com/

:-)

> Wobei man sich dann imho schon fragen muss, warum man nicht einfach
> einen 486er vom Schrottplatz programmiert, der kann das Gleiche, kostet
> nix und ein größeres Publikum für die Spiele hat man auch.

Naja, dann am besten gleich DirectX oder Flash, dann kanns jeder auf 
beliebiger Hardware spielen...

Dieses Frage muss sich jeder in einem technisch-kreativen Hobby mal 
stellen: Was will ich selbst tun, wo will ich Eigenleistung erbringen 
und was kaufe ich mir eben. Alles schafft man nicht - weder vom 
Know-How, noch von der Zeit. In meinem Fall geht es darum eine einfache 
Game-Hardware zu entwickeln - nicht jedoch darum, ein Game zu schreiben 
und zu verbreiten.

Im Hobby ist ja alles erlaubt, aber ich frage mich desöfteren, warum man 
sich so einer Materie widmen sollte.

(Sorry vorab an jene, deren Schlips gleich Fußspuren aufweist)

Der Aufwand, Hardware zu realisieren die bei weitem nicht mit einem 
modernen Handy mithalten kann ist enorm - ohne daß dabei etwas wirklich 
neues realisiert wird...

...im Gegenteil - voller Stolz weiden sich die Augen des Entwicklers an 
der entstandenen Grafik, die 1981 (wohlgemerkt vor 26 Jahren) 
Spielhöllenstandard war.

(Referenz: DonkeyKong 
http://www.klov.com/game_detail.php?letter=&game_id=7610)


Natürlich ziehe ich meinen Hut vor jedem, der solches aus einem 
Mikrocontroller herausholt, aber gleichzeitig nähert sich mein 
kreisender Zeigerfinger der freigewordenen Fläche ;-)

> Im Hobby ist ja alles erlaubt, aber ich frage mich desöfteren, warum man
> sich so einer Materie widmen sollte.

Irgendwie hast du schon recht, manchmal fragt man sich, was man da tut. 
Warum man nächtelang debuggend vor dem Computer sitzt und warum man sich 
Gerätschaften und Material kauft, für deren Preis man das Endprodukt 
auch bekommen könnte. Manchmal fragt man sich, warum man das tut - ist 
es wirklich nur das Interesse und die Freude an der Materie? Oder spielt 
auch das Gefühl von "Macht-und-Kontrolle" über die Technik mit? 
Selbstbestätigung? Selbstverwirklichung?

> Der Aufwand, Hardware zu realisieren die bei weitem nicht mit einem
> modernen Handy mithalten kann ist enorm - ohne daß dabei etwas wirklich
> neues realisiert wird...

Das stimmt. Man findet z.B. im Deutschprachigen Raum nur einige wenige 
Projekte, die sich beispielsweise mit Farbgrafik befassen. Eines mit 
Echtzeit-Farbgrafik wäre mir nichtmal bekannt.

> ...im Gegenteil - voller Stolz weiden sich die Augen des Entwicklers an
> der entstandenen Grafik, die 1981 (wohlgemerkt vor 26 Jahren)
> Spielhöllenstandard war.

Wobei man sagen muss, dass damals ganze Teams von ausgewachsenen 
Ingenieuren mit siebenstelligen Budgets, umfassender Ausrüstung und als 
Fulltimejob am Werk war, während ich beispielsweise gerade mal ein 
einzelner lumpiger Student bin mit einem Budget von jährlich maximal 
einigen hundert Euro, mit meiner Lötausrüstung auf DIL-Packages 
angewiesen und nicht mal ein Oszi besitze und kaum über 10 Stunden pro 
Woche zum Basteln komme...

>Manchmal fragt man sich, warum man das tut - ist es wirklich nur das
>Interesse und die Freude an der Materie?

Da ich selber bastele (Synthesizer etc.) und es nur als Hobby neben dem 
Studium laufen lasse, kenne ich den Gedankengang gut.
Allerdings bin ich der Meinung, daß es sinnvoller ist sich gerade bei 
der Elektronik mit Neuem zu beschäftigen.

Das Gebiet Grafikprogrammierung ist extrem ausgelutscht - selbst die 
"Bibel" dieses Bereiches (Foley, van Damme) behandelt Themen, die von 
einer Realisierung mit Mikrocontrollern noch weit entfernt ist.

...und wenn dann der tausendste Voxelgrafik-, Bresenham-, Raycasting-, 
Spritealgorithmus implementiert wird, muß ich mich einfach nach dem Sinn 
fragen.

Was ich (persönlich) interessanter finde, sind Bereiche in denen noch 
was "zu löten ist" (Heimautomatisierung, Prozeßsteuerung, verteilte 
Systeme, Audio/Synthese) - und wenn der tausendste Roboter nicht schon 
wieder ein Linienfolger ist, schaue ich mir auch diesen gerne an.

Aber wie dem auch sei, eine Konsole zu bauen ist immer noch sinnvoller, 
als dieselbe Zeit mit zocken zu verschwenden :-)



>@antworter:
>  Schon mal folgenden Spruch gehört? : "Der Weg ist das Ziel"

Kommt mir bekannt vor, aber wenn das Ziel der uralt-Spieleautomat auf 
dem Dachboden ist, ist der Weg ziemlich vorhersagbar ;-)

> Das Gebiet Grafikprogrammierung ist extrem ausgelutscht - selbst die
> "Bibel" dieses Bereiches (Foley, van Damme) behandelt Themen, die von
> einer Realisierung mit Mikrocontrollern noch weit entfernt ist.

> ...und wenn dann der tausendste Voxelgrafik-, Bresenham-, Raycasting-,
> Spritealgorithmus implementiert wird, muß ich mich einfach nach dem Sinn
> fragen.

Es ist zwar tatsächlich ein umfassend abgehandeltes Gebiet, aber die 
meisten Projekte setzen auf bestehender Hardware auf - mir geht es eben 
gerade um den low-level Teil, d.h. um die nötige Hardware um eben 
anspruchsvolle Grafik ausgeben zu können. Und irgendwie hat mich die 
Digitaltechnik seit der entsprechenden Vorlesung an der Uni einfach 
gepackt :-)

> Was ich (persönlich) interessanter finde, sind Bereiche in denen noch
> was "zu löten ist" (Heimautomatisierung, Prozeßsteuerung, verteilte
> Systeme, Audio/Synthese) - und wenn der tausendste Roboter nicht schon
> wieder ein Linienfolger ist, schaue ich mir auch diesen gerne an.

Also bei den Robotern gehts mir ähnlich... Jeder zweite im Roboternetz 
vorgestellte Robby kann (ausschliesslich oder als Hauptfunktion) Linien 
folgen und Hindernissen ausweichen. Für ein Einsteigerprojekt ne hübsche 
Sache, aber irgend wann hat man es gesehen :-)

Die Frage ist halt: Wo liegen noch Herausforderungen? Die Anforderungen 
an mögliche sind hoch: Sie müssen eine echte Herausforderung bieten, 
aber doch nicht zu schwer sein. Sie müssen sich mit einem (Teil-)gebiet 
befassen von dem man Ahnung hat und das einem interessiert. Sie sollen 
etwas hergeben, aber doch nicht Jahre dauern usw.

> Aber wie dem auch sei, eine Konsole zu bauen ist immer noch sinnvoller,
> als dieselbe Zeit mit zocken zu verschwenden :-)

> Sprites sind ja eigentlich auch nichts anderes als Datenfelder.
> Verknüpft man die per XOR mit dem Hintergrund, dann kann man sie setzen,
> noch eine XOR-Verknüpfung, und sie sind wieder weg.

Wie genau läuft das jetzt mit diesem XOR und den Sprites? Verstehe ich 
nicht ganz, kannst du das nochmals langsam zum mitschreiben? :-)

Hmmm...aber damit löse ich das Problem, dass mir die 'Sprites' jedes mal 
den Hintergrund zersudeln und ich ihn neu zeichnen muss, ja noch nicht. 
Bisher dachte ich daran, entweder der von den Sprites verschmutzte 
Hintergrund vorher zu sichern und danach wieder zurückzuschreiben 
(Blittering / BOBs) oder eben die Sprites erst in Echtzeit in das 
Bildsignal einzubauen, ohne den Bildspeicher zu berühren (echte 
Hardware-Sprites). Irgendwie fand ich das aber unelegant, aber nach dem 
Wikipediaartikel 
http://de.wikipedia.org/wiki/Sprite_%28Computergrafik%29 wird's genau so 
gemacht.

Werde eher einen Blitter / BOBs verwenden als Hardware-Sprites, das 
scheint mir ein bisschen einfacher. Wobei "einfach langsam" relativ 
wird. Mittlerweile habe ich ein CPLD als Speichercontroller, zwei 32k 
SRAMs als Videospeicher, einen Mega8 als Sync-Generator, einen 24 Bit 
breiten Bus für die Dateneingabe und jetzt möglicherweise noch ein 32k 
SRAM sowie einen Mikrocontroller für den Blitter.

Bauen kann man sowas (Wobei ich langsam Bedenken habe, ob hier 
Lochraster noch eine gute Idee ist, wegen den 40 MHz CPLD-Takt) - 
debuggen hingegen wird unglaublich schwer.

Vielleicht sollte ich doch lieber einen linienfolgenden Roboter bauen 
:-)

@antworter

du baust synthesizer und audio-zeugs ? was denn so ?
die rein analoge schiene ? (vco/vcf) ich selbst bin auch mit einem 
audio-system dran. wenn du magst können wir uns ja mal austauschen

gruß
rene

@TheMason

Mein letztes großes Projekt war ein (polyphoner) FM-Synthesizer mit 
digital gesteuerten analogen Filtern (Cutoff und Resonanz werden 
gesteuert).

Momentan sitze ich an einem Sample-Player (Drumcomputer) - diesmal mit 
`nem ARM7 (vorher ATMega).

Welche Teile analog und welche digital sind, mache ich meist von 
Klangpotential und Aufwand abhängig.

Was willst Du denn machen ?

@antworter

ich hab hier (schon seit längerem) ein projekt auf under construction 
(genannt audio-projekt)das ein programmierbaren audio-prozessor 
basierend auf einem fpga darstellt. werde das teil auch bald hier 
reinstellen (muß nur noch was doku machen).
mit dem teil kann man filtern, mischen, routen, oszillatoren erstellen 
und delays bauen. also alles was man für einen synthesizer, mischpult, 
effektgerät und dergleichen braucht.
bin da auch noch auf der suche nach leuten, da das alleine schon recht 
mächtig ist (sitze da auch schon ne weile dran).
basis des ganzen ist ein fpga-board von xilinx (spartan 3), an den ich 
ein msp430 und 2 audio-codecs angeschlossen habe. das board selbst hat 
noch 1MB Ram das im moment nur für delays genutzt wird. evtl. kann man 
da noch einen sampleplayer mit bauen.
im späteren ausbau würde ich gerne (erstmal eine eigene platine daraus 
machen) und evtl. noch eine cf-card an den fpga anschließen um evtl. 
später auch hd-recording machen zu können.

hast du bock mit zu machen ?

@TheMason

Habe gerade gesehen, daß dazu schon viele Infos auf diesem Board 
rumschwirren - aber heute werde wohl nicht mehr dazu kommen, das alles 
durchzulesen.

Wie könnte ich Dich am besten kontaktieren, wenn es mir zusagt ?

schreib mir einfach eine email : reneboellhoff (at) gmx (dot) de

@antworter

wenn du mir deine email zukommen lässt, kann ich dir mal ein mp3-demo 
schicken wie ein synthesizer mit dem audio-prozessor klingt.

Hmm...so wies aussieht, muss ich das Projekt fallenlassen. Die 
Grafikausgabe an sich wäre kein allzugrosses Problem, allerdings fand 
ich keine Lösung für die Frage, wie ich die Daten für halbwegs 
brauchbare (NES/Gameboy-Stil) Animationen genügend schnell anliefern 
kann.

Hat irgend wer ne Idee, was man mit dem (bereits bestellten) CPLD doch 
noch anfangen könnte?

Oooder: Mit nem FPGA sollte es eigentlich gehen - aber gibts die 
irgendwo im hobbylötbaren Format?

@Frank: Ist alles bereits so geplant. Ich möchte die bewegten Grafiken 
als sogenannte BOBs 
http://de.wikipedia.org/wiki/BOB_%28Computergrafik%29 implementieren. 
Das Datenaufkommen ist aber immens.

Die andere Variante sind die echten Sprites, aber dort ist die Logik für 
die Einblendung relativ komplex - kaum etwas für ein CPLD.

http://darkwatcher.psxfanatics.com/console/

Hier findet man eine Übersicht über alte Konsolen, die ersten hatten 
noch weniger als 1 MHz CPU Frequenz und hatten trotzdem schon 
beeindruckende Spiele. Für solche alten Systeme zu entwickeln ist 
bestimmt ziemlich interessant (besonders der Intellivision interessiert 
mich)

> Es gibt durchaus FPGAs, die man auch noch selbst löten kann.
> Guck z.B. mal bei Altera bei den Cyclones (I oder II) . Gibts noch bis
> PQFP 244. Die Frage ist halt, wieviel Logikelemente du brauchst.

Muss ich mir mal ansehen. Allzuviel Logik brauch ich nicht, wenn ich das 
so überdenke, wäre es mit 2 CPLDs hinzukriegen. Vielleicht werde ich es 
dann doch so versuchen, denn bis ich in der Schweiz an FPGAs komme... 
:-S

> Hier findet man eine Übersicht über alte Konsolen, die ersten hatten
> noch weniger als 1 MHz CPU Frequenz und hatten trotzdem schon
> beeindruckende Spiele. Für solche alten Systeme zu entwickeln ist
> bestimmt ziemlich interessant (besonders der Intellivision interessiert
> mich)

Hmm...motiviert mich jetzt doch nochmals. Jedenfalls ist ein AVR den 
damaligen Prozessoren weit überlegen, und mit einem CPLD liessen sich 
zumindest einfache ASICs "ersetzen". Und der Speicher ist sowieso kein 
Thema.

@mr.chip:

Sind Dir die alten SIMMs (DRAMs) aus PC`s bekannt ?

Hier im Forum gab/gibt es mehrere Leute (mich eingeschlossen), die diese 
erfolgreich zum laufen gebracht haben - ist auch nicht sonderlich 
kompliziert.

(Du bekommst bis zu 4MByte pro Modul gratis, wenn Du einen PC zum 
Schlachten findest.)

Wenn Du dann für jedes neu generierte Bild (25 Bilder pro sek) die 
Sprites aus dem DRAM in Deinen Bildbuffer blittest, hättest Du ohne 
überlappende Sprites eine fest nach oben begrenzte Datenrate.

Der DRAM selbst könnte alle in dem Spielelevel vorhandenen Sprites 
enthalten.

Der CPLD würde dann das eigentliche Blitting übernehmen (Ansteuerung des 
DRAM-Moduls), und z.B. einfache Operationen wie z.B. Transparenz 
gegenüber dem Bild-Hintergrund ausführen.

Du kannst es ja mal durchrechnen mit einer typischen 
RAM-Random-Access-Zeit von 200ns (als Hausnummer).




Kopf hoch, IC runter und Lötkolben `drauf :-)