Neuer Handheld taucht bald auf

[he1n2]

Leider hab ich keine ahnung von FPU, MMSP2+ oder sonstiges

Darf ich mich auf nen N64 überhaupt noch freuen?(wäre halt mal was dolles Zelda Ocarina of Time unterwegs zu zocken)

Freu mich auf jedenfall über die neuen infos, ist ja mitlerweile schon 1 monat fast her, seit der 1.Meldung , wenn ich mich nicht täusche

Kann man sich auf ein kleines "Office Paketchen" freuen, meine, das ich dann auch z.b. kleinere präsentationen erstellen kann oder "große" von meinem PC aufm neuen packen und dann abspielen kann (für Schule) ?


PS.: inwiefern habt ihr euch von den ganzen Design vorschlägen beeinflussen lassen ? - Hab noch nen kleines Design Update vor

Naja man muss auch warten können, ist nur die sache ob es sich für mich lohnt jetzt schon zu sparen

 

[mick]

MMSP2+ oder imx31, sind beide im Benchmarktest gerade

Naja, der Vergleich ist ja nicht ganz fair:
360 MHz ARM9-CPU(s) gegen mit 400...533MHz wesentlich höher getaktete ARM11-CPU, die außerdem noch ein FPU und 128kB L2-Cache besitzt.
Da müssten beide T9xx Cores schon gemeinsam schuften

Es war fest, aber der MMSP2+ hat nen dicken Fehler:
Solange alles im Cache der CPU läuft, rast er. Sobald das Programm größer als der Cache ist, kommt der Flaschenhals: Die Geschwindigkeit bricht auf einen gp2x mit 280MHz runter. Und das bringt uns wenig...

Ja, die ARM-CPUs ab 200MHz aufwärts sind von der Geschwindigkeit her eher speicher-limitiert (ist bei aktuellen PCs auch nicht anders) . Stand ist wohl immer noch 100-133MHz SDR-RAM (imx31 kann auch DDR). Von solchen Sachen wie Dual-Channel keine Spur. Da helfen nur größere Caches, wie die 128kB L2 beim imx31, die allerdings dann wieder die Chips größer und teuerer machen und außerdem mehr Strom schlucken, was beim imx31 definitiv der Fall sein sollte

Noch ein paar andere technische Fragen zum neuen Gerät:

1. MMSP2+ kann doch auch MPEG-4 AVC / H.264-Video, wie die PSP oder? Allerdings wohl nur in 1/4 Pal-Aulösung?

2. Linux-Kernel: Endlich ein zeitgemäßer 2.6.x-Kernel mit
Powermanagement und wesentlich besserem Hardwaresupport?

3. Preis. Bin sehr skeptisch, wäre aber trotzdem positiv überrascht, wenn sich der angepeilte Preis von 250EUR trotz "Highend"-Mobilchip und "Hires"-Touchscreen sowie Tastatur(?) halten ließe. Zum Vergleich - ein Nokia N800 kostet bei vergleichbaren technischen Daten 100EUR mehr. Und Nokia sieht das N800 im Moment eher als "Geek-Device" und Zukunftsmarkt denn als lukratives Hardwaregeschäft, sonst würden die damit wesentlich mehr Werbung machen.

Gruß, Mick

 

[EvilDragon]

2. Linux-Kernel: Endlich ein zeitgemäßer 2.6.x-Kernel mit
Powermanagement und wesentlich besserem Hardwaresupport?

Ja, Kernel 2.6.x läuft auf beiden schon.

3. Preis. Bin sehr skeptisch, wäre aber trotzdem positiv überrascht, wenn sich der angepeilte Preis von 250EUR trotz "Highend"-Mobilchip und "Hires"-Touchscreen sowie Tastatur(?) halten ließe. Zum Vergleich - ein Nokia N800 kostet bei vergleichbaren technischen Daten 100EUR mehr. Und Nokia sieht das N800 im Moment eher als "Geek-Device" und Zukunftsmarkt denn als lukratives Hardwaregeschäft, sonst würden die damit wesentlich mehr Werbung machen.

Naja, der Unterschied ist, dass bei Nokia noch zig Zwischenhändler dazwischen sitzen, die alle auch was verdienen wollen.
Das ist hier ja nicht der Fall

 

[boeseronkel2k]

wird der handheld eine intigrierte w-lan antenne haben oder eine extern anschließbare über sma(reverse) anschluss?
wär natürlich noch besser wenn user, welche eine größere reichweite wünschen einfach eine bessere atenne dranstöpseln können (ist hier aufgrund von stahlbetonbauten in den meisten fällen einfach nötig)

 

[mick]

Ja, Kernel 2.6.x läuft auf beiden schon.

Laufen ist ja nicht das Problem. Mir geht es um die Binärtreiber
für Hardware-Grafik/Video, (3D), SDHC, WLAN usw., die ein Kernelupdate
ohne das der Hersteller mitzieht, fast unmöglich macht. Wird es noch einen Kernel 2.6 mit voller Hardwareunterstützung für den GP2X geben? Sind alle Treiber vom neuen Gerät für Kernel 2.6 Open Source?

Naja, der Unterschied ist, dass bei Nokia noch zig Zwischenhändler dazwischen sitzen, die alle auch was verdienen wollen.
Das ist hier ja nicht der Fall

Zwischenhändler? Beziehen das nicht Onlinehändler wie Amazon oder Cyberport direkt von Nokia? Ich sehe da keine Zwischenhändler.
Außerdem verkauft das Ding auch Nokia selbst. Zum höheren (Listen-)Preis versteht sich
Selbst wenn ihr nur 50 EUR unter dem N800 bleibt, wäre eure Preiskalkulation bei der anvisierten Hardware immer noch recht günstig, allerdings nicht mehr im Vergleich zum bisherigen GP2x
Wobei ich mich wundere, wie ihr die nötige Erststückzahl bei dem angestrebten Preis vorfinanzieren wollt. Habt ihr irgendeinen potenten Geld-/Kreditgeber/Firma im Hintergrund? ;-)
Gruß, M.

PS: Mein Vorschlag noch fürs neue Gerät, falls ihr das nicht sowieso geplant habt:
USB On-the-GO (OTG) als Standard USB-Anschluß. Je nach Kabel hat man entweder USB-Host oder nur USB-Device über den gleichen Anschluss.

 

[Psyko]

Wobei ich mich wundere, wie ihr die nötige Erststückzahl bei dem angestrebten Preis vorfinanzieren wollt. Habt ihr irgendeinen potenten Geld-/Kreditgeber/Firma im Hintergrund? ;-)

Wird wohl wie beim GP2X laufen, das man die erste Runde durch die Vorbestellung der Kunden (also wir) finanziert

 

[sbock]

Leider hab ich keine ahnung von FPU, MMSP2+ oder sonstiges

Darf ich mich auf nen N64 überhaupt noch freuen?(wäre halt mal was dolles Zelda Ocarina of Time unterwegs zu zocken)

Wenn der i.MX31 Chipsatz verwendet wird, ist brauchbare N64 Emulation meines Erachtens durchaus realistisch.

Ja, die ARM-CPUs ab 200MHz aufwärts sind von der Geschwindigkeit her eher speicher-limitiert (ist bei aktuellen PCs auch nicht anders) . Stand ist wohl immer noch 100-133MHz SDR-RAM (imx31 kann auch DDR). Von solchen Sachen wie Dual-Channel keine Spur.

Der MMSP2+ nutzt auch DDR RAM über zwei getrennte Controller. Ich denke, die Probleme der MMSP+ Familie sind eher die nicht effizent nutzbare Dual Core Implementierung und mangelnde FPU Unterstützung.

 

[EvilDragon]

Der MMSP2+ nutzt auch DDR RAM über zwei getrennte Controller. Ich denke, die Probleme der MMSP+ Familie sind eher die nicht effizent nutzbare Dual Core Implementierung und mangelnde FPU Unterstützung.

Nein, DualCore ist kein Problem, man kann jedem eigenen RAM geben (wäre beim MMSP2 übrigens auch schon gegangen), damit kein Problem.

Es ist tatsächlich der RAM - denn es ist nur 16bit DDR RAM. Und DDR läßt sich im Gegensatz zum SDRam nicht gut zusammenlegen, daher ist der gp2x bei Speichergeschichten tatsächlich schneller...

 

[Glaeder]

danke für die beantwortung ED

was mich noch interessiert, haben denn die entwickler schon interesse gezeigt, zugesagt zu porten oder sowas in der art? weil wenn das teil noch so gut von der hardware her wird, wenn keine vernünftigen emus etc laufen bringts ja auch nicht. ist die unterstützung der community da? ich mein jetzt speziell vom englischen board. wär natürlich am besten wenn der neue als nachfolger des gp2x, quasi als gp3x akzeptiert werden würde.

welche firma steht da jetzt dahinter, oder seit "ihr" das als privatpersonen?

 

[mick]

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 :-(

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

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.

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.

Gruß, M.

 

[boeseronkel2k]

aber allein fürs video dekodieren macht eine fpu durchaus sinn
der imx30 soc scheint ja ordentliche specs zu haben

 

[EvilDragon]

was mich noch interessiert, haben denn die entwickler schon interesse gezeigt, zugesagt zu porten oder sowas in der art?

Programmieren und portieren für wollen:
Squidge, DJWillis, Exophase, notaz, etc.

ist die unterstützung der community da? ich mein jetzt speziell vom englischen board. wär natürlich am besten wenn der neue als nachfolger des gp2x, quasi als gp3x akzeptiert werden würde.

Dank der katastrophalen Hardware-Probleme der ersten gp2xe sind sie etwas skeptisch, einige jammern, dass der gp2x damit tot ist, aber das gleiche war damals beim GP32 ja auchso.
Ich seh da kein Problem, die Community bleibt da, wo sie ist

welche firma steht da jetzt dahinter, oder seit "ihr" das als privatpersonen?

Hmm... hehe

 

[fusion_power]

Das Fehlen einer solchen Einheit wäre eines der größten Nachteile der neuen Maschine. Passable N64 Emulation wird dadurch z.B. sehr unwahrscheinlich und im Vergleich mit der PSP wird der Handheld bei vielen Rechenoperationen leider immer noch den kürzeren ziehen, obwohl die CPUs höher getaktet sind...
Gruß,
Stephan

Yo, man darf nur nie vergessen, das vorhandene Hardware allein noch keinen Emulator macht. Der Emu mus programmiert werden und vor allem muss die Hardware auch optimal ausgenutzt werden. Was nützt ne MMU, wenn die Coder sie nicht nutzen(können) ? Beim GP2X warn die Games soweit ich gelesen habe auch nicht wirklich dolle an die Hardware angepasst, man benutzt halt SDL zum coden, kompiliert sein Zeuch und fertich. Ob aus dem GP2X wirklich all das rausgeholt wurde, was bei perfekter Optimierung drinnen steckt, möchte ich auch mal gern wissen. Ist halt schwer herauszufinden, sowas dauert ja auch bei Kommerziellen Handhelds/Konsolen manchmal Jahre, wenn man die ersten Games und die letzten Games auf den Konsolen vergleicht. (Das erste Neo.Geo Game "nam 1975" z.B. sah ehr nach mittelmäßiger Megadrive Grafik aus und wenn man sich dann mal die Späteren Titel ansieht, ist das ein Unterschied wie Tag und Nacht ^^)
Ich hab gelesen, dass es nicht viel einfacher/schwerer werden soll, Programme für den neuen Handheld zu coden. Vieleicht heißt das ja, dass die Coder diese Hardware besser ausnutzen können als auf dem GP2X, kenn mich da nicht so gut aus, ideal währs natürlich.

? Meinst Du USB-Host? Ja, ist drin.

Also kann man theoretisch Maus+Tastatur direkt an das Gerät stöpseln? Währe cool auch wenn man das wegen dem Touchscreen ja nun kaum noch braucht. Setzt ja auch nen großen USB-Stecker voraus und die Handhelds haben ja immer nur den kleinen USB-Stecker, da passt direkt ja nix gescheits dran.

Es war fest, aber der MMSP2+ hat nen dicken Fehler:
Solange alles im Cache der CPU läuft, rast er. Sobald das Programm größer als der Cache ist, kommt der Flaschenhals: Die Geschwindigkeit bricht auf einen gp2x mit 280MHz runter.

Und das bringt uns wenig...

Und solche "unwichtigen" Kleinigkeiten verschweigt der Hersteller? oder ham die das noch gar nicht mitbekommen? :lol:

.
Es ist tatsächlich der RAM - denn es ist nur 16bit DDR RAM. Und DDR läßt sich im Gegensatz zum SDRam nicht gut zusammenlegen, daher ist der gp2x bei Speichergeschichten tatsächlich schneller...

Also währe Single Core in verbindung mit DDR-Ram die bessere Wahl?

@mick: du scheinst dich ja gut mit der Materie auszukennen

wird der handheld eine intigrierte w-lan antenne haben oder eine extern anschließbare über sma(reverse) anschluss?
wär natürlich noch besser wenn user, welche eine größere reichweite wünschen einfach eine bessere atenne dranstöpseln können (ist hier aufgrund von stahlbetonbauten in den meisten fällen einfach nötig)

Hm...

könnt lustig aussehn. ^^

 

[mick]

aber allein fürs video dekodieren macht eine fpu durchaus sinn der imx30 soc scheint ja ordentliche specs zu haben

Videodekodierung (am PC) wird heutzutage überwiegend mit Integer und optional MMX/SSE (Festkomma) gemacht. Schau mal in den Quellcode von ffmpeg-libavcodec, was u.a. für den Mplayer verwendet wird. Die (X86-) FPU bleibt da außen vor. FP bringt zwar theoretisch mehr Genauigkeit (u.a bei Rundungsfehlern) auf Kosten der Geschwindigkeit, die man aber bei den 8Bit bzw. 16Bit-Koeffizienten der Videosignale eigentlich nicht braucht oder sowieso nicht sieht.

Gruß, M.

 

[Dittboy]

welche firma steht da jetzt dahinter, oder seit "ihr" das als privatpersonen?

Hmm... hehe

Samsung?

 

[boeseronkel2k]

aber allein fürs video dekodieren macht eine fpu durchaus sinn der imx30 soc scheint ja ordentliche specs zu haben

Videodekodierung (am PC) wird heutzutage überwiegend mit Integer und optional MMX/SSE (Festkomma) gemacht. Schau mal in den Quellcode von ffmpeg-libavcodec, was u.a. für den Mplayer verwendet wird. Die (X86-) FPU bleibt da außen vor. FP bringt zwar theoretisch mehr Genauigkeit (u.a bei Rundungsfehlern) auf Kosten der Geschwindigkeit, die man aber bei den 8Bit bzw. 16Bit-Koeffizienten der Videosignale eigentlich nicht braucht oder sowieso nicht sieht.

Gruß, M.

nahezu außen vor stimme ich dir zu aber kmplett außen vor bleibt sie nicht, insbesondere bei erwiterten mpeg4 funktionen stichwort qpel

 

[mick]

qpel

<r><QUOTE author="boeseronkel2k"><s>

</s>
nahezu außen vor stimme ich dir zu aber kmplett außen vor bleibt sie nicht, insbesondere bei erwiterten mpeg4 funktionen stichwort qpel<e>

</e></QUOTE>
Hmm, bei den für Mplayer/libavcodec relevanten qpel-Funktionen (in dsputils.c ?) sehe ich für nur Integer als Parameter. Qpel (Quarter Pixel) läßt sich doch hervorragend als Festkomma-Berechnung implementieren, indem man aus jedem Pixel 16 Subpixel bildet und das Ergebnis nach der Qpel MC entsprechend wieder zusammenfasst. 4 Subpixel für 0.5 Pixel Genauigkeit bei der normalen MC muss man bei MPEG-4 sowieso schon machen. Schätze mal so ähnlich läuft das ab.<br/>
<br/>
Übrigens - <URL url="http://en.wikipedia.org/wiki/Qpel">http://en.wikipedia.org/wiki/Qpel</URL>:<br/>
"..Qpel requires up to twice as much processing power to encode, and 30-60% more processing power to decode.." <E</E><br/>
<br/>
Gruß, M.<br/>
<br/>
PS: Funktioniert Qpel eigentlich mit dem GP2x MPlayer bzw. der Hardware? Ich hatte es bisher beim Enkodieren deaktiviert.</r>

 

[he1n2]

Sorry, drifte mal kurz ab....

wollte hier irgendwas posten, dann stach mir DiabloII (liegt glei neben mir) ins auge, ... wäre das nich auf den neuen geil zu zocken, gibts ja sachen wie "Wine" (konnte ich noch nicht testen ;( ), womit man WinApps/Games auf linux zocken kann und es ist kein Windows Emu, die games laufen (fast) mit den gleichen systemvorraussetzungen wie in windows

- 233 mhz (najut, da steht Pentium233 oda vergleichbar); 64mb ram; 640*480 oda 800*600 auflösung
... Ist aber nicht powerfull genug, der neue dafür

Aber ist eine portierung von "Wine" für den "neuen" vorstellbar, meine dann aber für ältere windows spiele oder progs ???????

Wer von euch würde das auch begrüßen ?

 

[Adrammelech]

wahrscheinlich alle, aber zaubern können die entwickler auch nich

 

[ivanovic]

Aber ist eine portierung von "Wine" für den "neuen" vorstellbar, meine dann aber für ältere windows spiele oder progs ???????

Kurz und knapp:
Das ist unmöglich!

Etwas länger:
WINE ist kein collständiger Emulator, es "biegt" Systemaufrufe nur auf das Linux System um. Man braucht weiterhin die X86 kompatible Architektur dahinter, damit es klappen kann.

"Der Neue" ist dagegen nicht auf X86 sondern auf ARM basierend, das geht also nicht. Wenn dann müsste man schon ein komplettes X86 emulieren, was *viel* Leistung braucht, weit mehr, als "der Neue" zur Verfügung stellen kann. Allerdings wird Dosbox gehen, was ja auch eine komplette Emulation darstellt...