Our New Machine, Pandora

[Orkie]

I won't be supporting my stuff for a long time after it's released either, just bug fixes and any improvements somebody else comes up with for Open2x (when it's released). It seems silly to carry on supporting hardware which I find a bit of a pain to work with (I don't like the joystick) unless the release is more generic (i.e. Open2x, which is develop via serial and on my PC).

I couldn't guess exactly how many people will stop working on the GP2X, but I doubt it'll be just a "few exceptions" .

 

[X-Code]

I guess that I'll continue... I like the machine .

Leaving that aside, we don't even know how good this new machine will really be, so don't make plans too soon B).

 

[Squidge]

The price of the MMSP2+ is clearly less than that of the i.MX31. Even if that doubled the cost of the MMSP2+, it would be a small increase considering it encompasses the majority of the system's hardware. One doesn't need to know the exact ratio of the prices when either one will be so inexpensive.

I wouldn't call $25 for a SoC inexpensive.

 

[predatorramboxxx]

I have to say that I need a laptop more than I need a gaming console (not to mention that a laptop like the EEE pc is going to do a better job of emulating or even full-on PC gaming than any handheld, it has specs to play Halo for Chrissake's, and at under 2LBs it is a real choice. If I transform it into a Tablet and integrate a D-Pad into it won't it be a handheld??)

The EEE PC does not have "specs to run Halo". That title ran poorly on PCs with 1.5 GHz+ processors, 1GB of RAM or more, and GF5/equivalent Radeon series GPUs. That system utilizes simple onboard Intel graphics meant for basic productivity/business use and not much else. Generally Intel onboard graphics are only about as powerful as a GeForce 2 and therefore not suited to modern games.

Even a 2lb. handheld would be extremely cumbersome. In fact 1lb. will still make your hands tired very quickly. The original Nintendo DS didn't weigh a full pound to my recollection, yet it was extremely uncomfortable to hold for any extended length of time.

This really isn't the matter up for discussion though; we're not talking about a PC, so I'm just going to drop it.

I ran halo on an old hp with 256ram,intregrated graphics,1.8ghz,win xp and it ran fine with me.

well running the benchmark program not made by intel says the actual speed and they realy do get 500-624mhz. No handhelds have essentially real dualcore processors iam kinda of tired of hearing about all these processors that they are dual core and so if it is 250 it is really 500 it is NOT a common misconception.

The chips do truly run at those frequencies and are not dual-core parts. However, at say, 624 Mhz the chips perform only as fast as a 312 MHz ARM9 processor. A decent analogy would be if you hired 2 employees, one worked longer hours and got less work done (624 MHz XScale) vs. one who works half a day but gets twice the work done (ARM).


Ok but isn't very hard to use the second proccessor like hardly any programs for the gp2x use it so why not just stick with the single processor.

 

[Orkie]

Because when you use an off the shelf part, you get what it has. If it has 2 processors, so be it.

 

[KeyboardCowboy]

Most SoCs with a single processor don't have a more powerful one to compensate; i.e. you'll probably be making a choice between 2 SoCs, with either 1 sub-400 MHz processor or 2. And they're going to be pretty similar parts, in most cases, unless it's a DSP instead of a coprocessor. (In the case of most ARM VFPUs they're just standard processors with a different purpose.)

 

[A_SN]

Most SoCs with a single processor don't have a more powerful one to compensate; i.e. you'll probably be making a choice between 2 SoCs, with either 1 sub-400 MHz processor or 2. And they're going to be pretty similar parts, in most cases, unless it's a DSP instead of a coprocessor. (In the case of most ARM VFPUs they're just standard processors with a different purpose.)

Here's what I don't get, what will we be able to do with that pseudo FPU we'll get?

 

[Squidge]

Here's what I don't get, what will we be able to do with that pseudo FPU we'll get?

Well, if the MMSP2+ is chosen, you'll be able to upload your fpu code and arguments to the processor, it'll run through the code and give you the result. You got the usual stuff like floating point add / divide / multiply / reciprocal / square root / etc.

 

[KeyboardCowboy]

Have you managed to confirm that the VFPU in the 3D accelerator block is usable as a general purpose coprocessor, or is that conjecture? MagicEyes' documentation does not specify any standalone VFPU block.

 

[Zeladin]

Here's what I don't get, what will we be able to do with that pseudo FPU we'll get?

Well, if the MMSP2+ is chosen, you'll be able to upload your fpu code and arguments to the processor, it'll run through the code and give you the result. You got the usual stuff like floating point add / divide / multiply / reciprocal / square root / etc.
Its part of the 3d graphics though isn't it. I'm going to ask a question without really knowing a whole lot (have done nothing on computer architecture yet on my course). But will the result of this calculation have to be sent back to the main memory before it can be used in other calculations or can the main cpu directly communicate with the 3d processor?

Really what I'm wondering is will it be as efficient as a 'normal' FPU? I'm going to assume though whatever, it will likely be somewhat better than doing FP through software only.

Btw @KeyboardCowboy, on the 130nm vs 90nm, generally yes lower power, and probably in this case too, but there are exceptions, and more to manufacturing processes than simply that. It's not evidence as per such of better energy efficiency. For example Amd have cpus that are lower power on 90nm than equivalent Intel cpus on 65nm (They still top energy efficiency charts). Also check out Amd's 2100+ low power sempron... not a solution for a console yet but promising.

Edit, some clarification.. +spelling

 

[A_SN]

Here's what I don't get, what will we be able to do with that pseudo FPU we'll get?

Well, if the MMSP2+ is chosen, you'll be able to upload your fpu code and arguments to the processor, it'll run through the code and give you the result. You got the usual stuff like floating point add / divide / multiply / reciprocal / square root / etc.


Oh, yeepee! Does it mean it could practically used to compute your physics with floats and such?

 

[kanzlr]

it definitely sounds like that.

but i do wonder if a DSP (and its a DSP, right?) can be as fast as a dedicated FPU. but on the other hand...why not

 

[Squidge]

Have you managed to confirm that the VFPU in the 3D accelerator block is usable as a general purpose coprocessor, or is that conjecture? MagicEyes' documentation does not specify any standalone VFPU block.

As far as I can see, it's a general purpose co-processor, but not a co-processor in the arm sense, as you can't use the arm co-processor instructions. Instead, you write to registers and read the result from registers (or you can have the result directly sent to the 3d engine)

QUOTE
Really what I'm wondering is will it be as efficient as a 'normal' FPU? I'm going to assume though whatever, it will likely be somewhat better than doing FP through software only.


If your writing an floating point program yourself, it could quite possibly be, special the more dedicated functions such as square root. However, if your thinking of emulating a systems fpu by using it, then I'd forget about it, unless your thinking of a dynarec fpu.

QUOTE

Oh, yeepee! Does it mean it could practically used to compute your physics with floats and such?



Well, it is meant for 3D stuff after all. I think it's main aim is for transforming, but there's nothing stopping you uploading other code.

 

[fusion_power]

Wow, this could be the thread with the longest texts in posts :lol:

A non-MMSP2+ chipset wouldn't limit the appeal to the GP2X community, it would only add the possibility for a more feature-rich device with greater programmer appeal and put a significant dent in power consumption. However the MMSP2+ would be fine so long as the engineers are very careful to alleviate the bottlenecks encountered in the GP2X's MMSP2 implementation.

Well, the most important question is, what is easier to port from GP2X software to the new console: porting stuff just from an MMSP2 machine to the MMSP2+ chipset or porting stuff from an MMSP2 to these strange i.MX31 ?
What do the devs here think?

I had some thoughts about the screensize. First I wasn't very happy with the big res into the compared tiny screen size. But if this thing can manage scaling via hardware, independent of software (so nobody have to code an scaling feature to it's software) the res could be nict to fit various apps in. here for example, the GBA screen (240x160) would fit nearly perfect in with 3x scaling (720x480) so I think it would look much better than on the GP2X screen

Oh, because some people seems to be fascinated with this EEE Laptop, do you know, that the battery time is just 3 Hours? 3 HOURS? :lol: Come on, this is nothing, less than nothing I think. Well, for me it would be more than useless and I think the real battery time will be less than 3 Hours. This is not mobile enough for a device like this.

 

[kanzlr]

Well, the most important question is, what is easier to port from GP2X software to the new console: porting stuff just from an MMSP2 machine to the MMSP2+ chipset or porting stuff from an MMSP2 to these strange i.MX31 ? wink.gif

they are both arm CPUs and both (would) use linux + sdl on top, so there isn't much difference, especially as craigix pointed out that the MMSP2+ is very different from the MMSP2.

you wouldn't ask if it is easier to port games from a Pentium3 to a Pentium4 architecture instead of porting it to AMD systems.

 

[animal]

i dont know alot about costum hardware like the ARM9 or the MMSP2+ but just wondering....

http://gumstix.com/index.html

would this be of use?
i

 

[Dzz]

Well, the most important question is, what is easier to port from GP2X software to the new console: porting stuff just from an MMSP2 machine to the MMSP2+ chipset or porting stuff from an MMSP2 to these strange i.MX31 ?
What do the devs here think?

Assuming that the MMSP2+ register definitions and general operation methods are similar to the MMSP2 (which seems likely) and also assuming that Craig et al are working from the Open2X kernel effort (which seems possible), it would probably be a fair bit easier to work with the MMSP2+ than the i.mx31.

Most games use higher level libraries and don't access the gp2x hardware much. So assuming that a nice (compatible) SDL exists for the new machine, it won't make much difference to most developers which chip is underneath.

Some games and utilities do bash on the hardware registers directly. Those would be more difficult to port if either the MMSP2+ works very differently from the MMSP2 or if a different processor is used. I am in this category myself, but many of us in that category think puzzling that stuff out is fun so although it may be harder, it's not to be feared.

 

[dgame]

I won't be supporting my stuff for a long time after it's released either, just bug fixes and any improvements somebody else comes up with for Open2x (when it's released). It seems silly to carry on supporting hardware which I find a bit of a pain to work with (I don't like the joystick) unless the release is more generic (i.e. Open2x, which is develop via serial and on my PC).
...

If this new/phantom device was just a gp2x compatible clone with a better joystick/d-pad I would buy it. I have moved from the 'joystick is okay once you get used to it' crowd to the official 'needs a d-pad whiners' group.

If this new/phantom device is not gp2x compatible and wont have any software when released I would wait.

If this new/phantom device is not gp2x compatible and had a decent MAME port I would buy it.

If this new/phantom device got our favorite gp2x developers excited I would buy it.

Whoever is behind this new/phantom device please make sure the controls can handle actual mid-80s to late 90s style of game play. This means from Pac Man to Street Fighter ][ from basic four way stick motion to intricate semi-circle combos. If the gp2x had better controls I could have personally influenced the sale of perhaps hundreds of them. I just can't recommend it to die-hard gamers because of the sloppy controls. So to beat this dead Zebra to death, please make nice controls. Thanks.

 

[Squidge]

Well, the most important question is, what is easier to port from GP2X software to the new console: porting stuff just from an MMSP2 machine to the MMSP2+ chipset or porting stuff from an MMSP2 to these strange i.MX31 ?
What do the devs here think?

It would be a moot point, it would take about 5 minutes to port an application like Squidgesnes to either platform. For those applications written using sdl, it would most likely be just a recompile.

From your wink, it would seem that you assume porting from mmsp2 to mmsp2+ would be simpler. If this is the case, you would assume wrong

 

[lubidog]

It would be great to read a post from Exophase, saying that he is happy and excited to develop for this, knowing the specs as he does!

Also, posts from Franxis and Reesy and Zzottd as to what they estimate they could do with this baby would be good.