Neuer Handheld taucht bald auf

[he1n2]

Oder DOSBox, wenn ich endlich "ToonStruck" auch unterwegs zocken kann:

das geme ist einfach lol und schick; beste Alternative zu MonkeyIsland; Tentacle und co

 

[Adrammelech]

sieh ja freaky aus, kenn ich gar nich

 

[he1n2]

sieh ja freaky aus, kenn ich gar nich

hab mal kurz gegoooooooglllllt
http://www.adventure-archiv.de/t2/toonstruckreview.htm
Trailer: http://www.youtube.com/watch?v=jj_3_AjZIW8

Wers gespielt hat, will es unterwegs nicht missen

 

[Commander-Keen]

Das Spiel is einfach GENIAL!!!!! nur leider finde ich nur noch die erste cd

 

[Adrammelech]

sieht abgefahren aus, mit chris lloyd als charakter

 

[Devaux]

Oder DOSBox, wenn ich endlich "ToonStruck" auch unterwegs zocken kann:

das geme ist einfach lol und schick; beste Alternative zu MonkeyIsland; Tentacle und co

Hach, das ist so lange her, dass ich mich nur noch wage an den Spielablauf erinnern kann. Aber es hat maechtig Spass gemacht, das weiss ich noch

 

[he1n2]

sieht abgefahren aus, mit chris lloyd als charakter

Jop und das spiel ist filmreif, ich finde spiel und videosequenzen perfekt abgestimmt habs mal in solch "Gold Games" sammel box ding drinnen gehabt und hab noch beide cd´s ; sond ist die sammlung fast komplett verloren gegangen

 

[Adrammelech]

muss mir erstmal dosbox ziehen, vorher geht ja gar nix

 

[StarG]

wieviel ram?

128MB, mehr unterstützen so kleine Prozessoren net.

Darüber lässt sich hervoragend streiten, denn hier gibt es zB ein Board das bis zu 256MB DDR unterstützt:

http://ftp.phytec.de/phytec/32-bit_module/phycore-i.mx31.html

Zwei getrennte Speicherkanäle (wenn möglich) würden sich der Speicherbandbreite sicher hilfreich zeigen und angesichts der niedrigen Kosten von DDR Speicher würden *mehr* Speicher sicher nicht weh tun, dafür aber der Portierung von Speicherhungrigen PC Spielen (z.B. Battle for Wesnoth) sehr helfen Abgesehn davon ist das sicher ein prima Marketingargument 8)

Ich denke, die Probleme der MMSP+ Familie sind eher die nicht effizent nutzbare Dual Core Implementierung und mangelnde FPU Unterstützung.

Woher erschließt du diese Information ? Meines Erachtens nutzt z.B. der Videoplayer & Payback den 2ten Kern gut aus. Andere Emulatoren wie zB Picodrive nutzen ihn zwar nur rudimentär als Audio-DSP - für diese Rolle ist er aber (u.a. wegen der geringen Cachegröße) gut geeignet. Für Emulatoren sind mehrere Kerne im Moment schwierig zu betreiben. Dafür müssten die Programme wohl von Grunde auf neu geschrieben werden. Im Prinzip wird der 2te Kern beim GP2X irgendwann relativ effizient zum Abschieben von Grafik & Soundverarbeitung herangezogen. Darin bin ich mir sicher. Allerdings muss dafür eine Schnittstelle á la X11 geschaffen werden die nur mit Nachrichten auskommt.

Ja, die Dual Core Implementierung ist ein anderes Problem. Der um die MMU abgespeckte zweite Core erschwert dessen Programmierung ungemein. Ansonsten würde nämlich ein ganz normaler Linux SMP-Kernel funktionieren und man könnte ganz einfach über einen neuen Prozess bzw. Thread den zweiten Core z.B. für Grafik oder Sound nutzen.

Die fehlende MMU ist unschön für blanke Portierungen aber das nackte Metall ist immer noch verfügbar: zwar nur in GP32 / GBA / DS Programmierart aber dennoch machbar. Nichsdestotrotz solltest du dir vor Augen halten das eine MMU trotzdem kostspielig ist. Jede zu übersetzende virtuelle Speicheradresse kostet nämlich dann noch 1 Speicherzugriff mehr. Und das sind bei typischen Speichern durchaus schonmal 13 CPU-zyklen. Diese Übersetzung muss dann natürlich beim 2ten Core auch nicht durchgeführt werden, was auch wieder Potential mit sich bringt. Die Zahlenangaben stammen übrigens von einem Pentium Prozessor afaik - wird bei dem ARM Prozi hier wohl abweichen wobei aber das Prinzip erhalten bleibt.

Und für 2D-Grafik, Audio und Video gibt es ja hochoptimierte Integer-basierte Bibliotheken (SDL, libmad, ffmpeg usw.), die macht auch keine FPU schneller. Dann eher schon eine SIMD-Erweiterung a la MMX/SSE.

Bleibt also noch noch 3D-Grafik, die allerdings mehr von 3D- bzw. Video-Hardware als von einer FPU profitieren könnte.

Viele PC Programme enthalten momentan FPU Code, werden diese 1:1 portiert sind diese Abschnitte sehr langsam, speziell Divisionen (die ja schon mit FPU schweinelangsam sind) werden äh nunja langsamer-als-schweinelangsam . Weiterhin muss man daran denken das eine FPU eine abgetrennte Funktionseinheit ist, diese kann unabhängig von den Integerecheneinheiten arbeiten und hat damit die Möglichkeit, die Integereinheiten entlasten, wenn der Programmier hier optimiert und es schafft möglichst viele Einheiten der CPU gleichmäßig zu belasten.

Die 3D Grafik benötigt u.a. Polygongeometriedaten. Genau für dessen Vorverarbeitung durch die Software wird aber letztendlich eine FPU benötigt. Ist diese nicht vorhanden muss sie wieder emuliert werden, oder arbeitet die PowerVR Logik etwa mit Festkommazahlen ?!

Der MMSP2+ nutzt auch DDR RAM über zwei getrennte Controller.

Hmm, im Produkt-FAQ steht nur etwas von der Unterstützung von zwei Speicherbänken und nichts über zwei getrennte Kanäle.
Und das Data-Sheet läßt sich leider ohne Registrierung nicht anschaeuen :-(
(...)
Gruß, M.

Es ist viel schlimmer: MESdigital ist nicht gerade freundlich den Entwicklern gegenüber. Sie geben z.B. Fremden kaum/keine tech. Daten. Ich bin registriert - habe aber keine Freigabe diese Dokumente zu sehen. Selbst diese spärlichen Dokumente die ins Netz abgesickert sind, sind nur die Spitze des Eisberges. Einige Dokumentationen sind scheinbar überhaupt nicht verfügbar. Für den 2D Teil des MMSP2 gibt es zwar WinCE Treiber aber die kann man auch nur als Binärtreiber kaufen (und dann gibts keinen Source). Das höchste der Gefühle sind wohl bei denen eine (bezahlte) Kooperation. Dank dieser restriktiven Politik sind wir auch heute nicht in der Lage das Potential des MMSP2 vollständig auszuschöpfen, u.a. ist die Videoausgabe und die 2D Engine davon betroffen. Ich kann nur bitten die Finger von dieser Firma zu lassen. Andere Firmen sind weitaus offenhertziger was derartiges angeht.

 

[sbock]

@StarG

Fakt ist nun einmal, das die effektive Dual Core Nutzung beim GP2x nur mit erheblichen Programmier und Optimierungsaufwand zu erreichen ist.
Natürlich läuft der Videoplayer sehr gut und PicoDrive ist eine Meisterleistung. Trotzdem sind hochgetaktete Singlecorelösungen programmiertechnisch sehr viel einfacher zu handhaben. Nicht jeder Programmier will und kann sein Programm auf die spezielle Dual Core Hardware anpassen. Und selbst wenn zieht nicht jedes Programm einen Nutzen daraus.
Beim MMSP2+ ist das prinzipell genauso der Fall. Es gibt zwar einige Designverbesserungen auf dem Papier, aber in der Realität scheint es laut ED ja nun doch wieder Probleme zu geben.
So wie der GP2x und das neue Handheld genutzt werden, profitieren sie kaum von einer Dual Core Architektur, selbst wenn sie optimal umgesetzt wurde, was ich aber bei der MMSP Serie mitlerweile in Frage stelle...

 

[mick]

Darüber lässt sich hervoragend streiten, denn hier gibt es zB ein Board das bis zu 256MB DDR unterstützt:

Das Problem ist eher der Stromverbrauch. DRAM verbraucht ständig Strom und muß auch immer wieder refreshed werden. CPUs kann man dagegen "schlafen" legen. Man könnte zwar die Spannung runtersetzen (wie bei DDR2), hilft aber trotzdem nur beschränkt. Bei PCs ist der DRAM Stromverbrauch kein Problem, bei mobilen Geräten schon.
Aus diesem Grund hatten auch die meisten PDAs nur 64MB und die 128MB-Version haben deutlich mehr Strom geschluckt.

Woher erschließt du diese Information ? Meines Erachtens nutzt z.B. der Videoplayer & Payback den 2ten Kern gut aus.

Der zweite Kern macht vermutlich nicht viel mehr als Daten aufzubereiten und zur Videohardware zu senden. Die komplette Dekodierung von MPEG-4 Video findet ja in der Hardware statt.
Frag doch mal die Leute, die sich damit beschäftigt haben, wie Gamepark den Code von mplayer "umbiegen" mußte, um die ganze Sache zu Laufen zu bekommen. Übrigens, für PC-Hardware sollte mplayer bzw. viele Dekodierroutinen in ffmpeg standardmäßig Dualcore/SMP-Support bieten.

Nichsdestotrotz solltest du dir vor Augen halten das eine MMU trotzdem kostspielig ist. Jede zu übersetzende virtuelle Speicheradresse kostet nämlich dann noch 1 Speicherzugriff mehr.

Soweit ich weiß, erfolgt die Umwandlung von virtueller in eine physische Adresse über einen TLB in der CPU, der beim System-/Programmstart geladen wird. Der Lookup benötigt daher standardmäßig keinen Speicherzugriff. Oder meinst Du eher einen zusätzlichen Taktzyklus? Da der TLB-Lookup parallel zum Cachezugriff erfolgt, sollte dies eigentlich nicht der Fall sein. Wenn doch mal ein Eintrag im TLB fehlt (im Bereich von 0,01...1%), dann muß meistens auch ein Cacheeintrag neu geladen werden und der Speicherzugriff muss sowieso erfolgen. Die MMU scheint also keine Performance zu kosten, sie nimmt nur Platz im Chip weg, der dann für andere Sachen fehlen könnte.

Viele PC Programme enthalten momentan FPU Code, werden diese 1:1 portiert sind diese Abschnitte sehr langsam, speziell Divisionen (die ja schon mit FPU schweinelangsam sind) werden äh nunja langsamer-als-schweinelangsam .

Ja, auch für int lernte man, Multiplikationen und besonders Divisionen komplett zu vermeiden und durch "Shift" (+ Addition/Subtraktion) zu ersetzen. Wobei die Multiplikation mittlerweile rasend schnell geworden ist , so daß es sich dafür nicht mehr lohnt.
Ich kenne zwei nach ARM portiere Programme (xpdf und timidity), die normalerweise kein FPU benötigen, bei denen floats aber für irgendwelche Nebensächlichkeiten verwendet wurden. Nach einfacher Ersetzung dieser paar Zeilen durch Festkomma-Arithmetik liefen die Programme auch ohne FPU performant.

Weiterhin muss man daran denken das eine FPU eine abgetrennte Funktionseinheit ist, diese kann unabhängig von den Integerecheneinheiten arbeiten und hat damit die Möglichkeit, die Integereinheiten entlasten, wenn der Programmier hier optimiert und es schafft möglichst viele Einheiten der CPU gleichmäßig zu belasten.

Optimierung auf FPU+Int war vielleicht vor fünf Jahren interessant. Heutzutage ist die normale (X86-)FPU veraltet. Sogar Intel empfiehlt, bisherigen FPU-Code auf auf SSE2+ zu portieren, um die Rechenleistung aktueller CPUs überhaupt nutzen zu können.

Die 3D Grafik benötigt u.a. Polygongeometriedaten. Genau für dessen Vorverarbeitung durch die Software wird aber letztendlich eine FPU benötigt. Ist diese nicht vorhanden muss sie wieder emuliert werden, oder arbeitet die PowerVR Logik etwa mit Festkommazahlen ?!

Die 3D- und Pixel-Koordinaten, speziell für solche Minidisplays wie beim GP2x müssen ja nicht besonders genau sein. Könnte mir durchaus vorstellen, daß Festkomma vollkommen ausreicht. Und der Z-Buffer ist meistens auch nur 16Bit Integer. Die 64bit/80bit der FPU sind da echt überflüssige Genauigkeit, die man eigentlich nur für wissenschaftliche Sachen braucht. Leider kann eine normale FPU dafür auch nicht gleichzeitig mit 2x 32bit float rechnen
Dann lieber gleich eine SIMD-Extension wie iwMMXt beim Xscale.
Für Software-3D optimal wären natürlich so etwas wie 3DNow bzw. SSE2+ für den GP2X.

Gruß, Mick

 

[fusion_power]

Wenn ich das hier so lese bin ich der MEinung, dass das Dev-Team vom neuen Handheld im Notfall sicher auf euch zurückgreifen könnte, falls Manpower in Sachen HArdware gebraucht wird. Angeblich gibts ja schon erste Dev-Boards und Squidge z.B. friemelt damit eifrig rum.

 

[kokoro]

Bis jetzt hört sich das Gerät wie mein Traumgerät an, auf dessen Suche ich schon seit Jahren bin.

Sozusagen mein Heiliger-Gral!

Wie schauts denn mit SDHC (SD 2.0) aus? Ist eine vollständige Unterstützung implementiert? Also werden auch die 32GB Karten darauf laufen?
Dann würd ich sagen Archos mit interner 30GB mini-HD *bye-bye*

Finde das Projekt sehr interessant und kann es kaum erwarten die ersten Bilder/Videos zu Gesicht zu bekommen.

 

[Glaeder]

Bis jetzt hört sich das Gerät wie mein Traumgerät an, auf dessen Suche ich schon seit Jahren bin.

Sozusagen mein Heiliger-Gral!

du hast den nagel auf den kopf getroffen

 

[he1n2]

Oder doch gleich Heiraten :lol:

Auf jedenfall wird das TeiL GeiL und will damit ScummVM zocken oder Playstation oooder Nintendo Entertainment System ooodeeerrr Super Nintendo Entertainment System oda ....
, da fällt mir ein, da gabs doch mal den "TigerGame.Com", da gabs Sonic und sogar Resident Evil 2 in Game Boy Optik, aber mit Touchscreen - wer schreibt die Emu

 

[boeseronkel2k]

am meisten freue ich mich dabei auf scummvm
mit touchscreen *sabber*
direkt dannach kommt snes
dann schon abiword

 

[kanzlr]

dann schon abiword

pervers pervers...arbeitet ihr im büro nicht schon genug, kinder?

 

[Glaeder]

was muss das teil den haben, damit da N64 emuliert werden kann? also flüssig.

 

[O-bake]

was muss das teil den haben, damit da N64 emuliert werden kann? also flüssig.

In aller erster Linie einen Programmierer, der sich viel Zeit nimmt um den Emulator zu portieren und zu optimieren.

 

[fusion_power]

Auf einem Touchscreen Gerät ist meiner Meinung nach auch ein Grafikprogramm pflicht. Muss nun nicht super komplex sein aber ein paar solide Funktionen um mal eben seine eigenen Icons zu basteln sollte es schon haben.