Our New Machine, Pandora

[quasist]

I think additional analog controller would be great for simulation/cad programs.

 

[cappuchok]

I will say I'm not entirely sure of the appeal of a keyboard. (I realize this is in direct contravention to my nickname. ) It would be useful for apps like web browsers, IM clients and email when near a wireless AP, but that's not likely to be very often for a LOT of users.

I would be inclined to prefer a physical keyboard over a virtual one on the touchscreen, because

1) the device will have WiFi and that means I'll probably be using it as a quick-boot no-bulk alternative to my computer if I just want to make a quick lookup on something on the web or have an IM client available without having to put up with the noise of the "big" computer.

2) a physical keyboard will probably add greatly to the ease of use and usability of various emulators, in particular those emulating computers, such as UAE, DOSbox and VICE or Frodo. A virtual keyboard would possibly detract from the emulation experience in these cases, at least that's my humble opinion.

3) it will make the shell far more accessible than having to telnet into the device.

Of course there are also compelling arguments for having a virtual keyboard available as well (especially for easily accessing non-US layouts).

 

[goobers]

I think additional analog controller would be great for simulation/cad programs.

Yeah, I'd like to see one so that FPS games will be more playable, but the general feeling seems to be that there won't. I'm hoping that the machine will be able to accept external devices so that an analog control cradle could be made.

 

[quartercast]

telcolou should come and give you both a good smacking with a large trout.

How did you know I like seafood?



I posted this a while back on the old thread, but nobody seemed to take notice (maybe because it was a dud suggestion.) What do you guys think about giving the unit an expansion slot? Kinda like the NDS, i'm sure some hackers would come up with crazy hardware add-ons, bringing uses to the system that we would never have imagined otherwise.

Things that come to mind:
- Motion detector
- Light sensor
- Mic
- Next-gen wifi chipsets

 

[Creature XL]

Only 160px of horizontal screen real estate would be lost, which is certainly forgivable.

If the GUI of emulators are designed with this device in mind, the additional 160px could be well used for giving quick access to certain functions of the emulator (savestates and the like), or just a nice bezel-type graphic.

I like this idea really. Keeping in mind we are having a touchscreen, it is possible with one quick touch on the screen to make/ load savestates or change some aspects of the emulation (SNES: translucency on/off, ...). I would go a little bit further to think about any possible standards for this. So, that in all emus (at least for the classic consoles/ computers which use 4:3 ratio) the save/load savestate "button" is the same.

One thing against it: Playing the gp2x, I find myself often touching the sides of the screen with my palm. This could be very annoying


@KeyboardCowboy:
There are a lot of posts from you (which I find very interesting) but they have almost all the same contents. For me it would be more iteresting if you take the time and add some numbers. Just stating the Freescale SoC needs less power would be more interesting if oyu can compare it with the MMSP2+. BUT I think the SoC is choosen anyway.


@all:
I did not checked if the ARM v5 has division ( the ARM v4 has not). And I wanna know if the the signal processing instructions are available (in the MMSP2+ data sheet is spoekn of 926j which means not AFAIK).
Has anybody more insight into this?

 

[cappuchok]

Things that come to mind:
- Motion detector
- Light sensor
- Mic
- Next-gen wifi chipsets

One thing I've noticed is that the SoC's we've been mentioning as possible choices so far all have the ability to compress MPEG-4 on-the-fly. That's pretty cool. Some (most?) also have H.264 decoding which probably says a lot about how powerful they must be.


EDIT:
For TV-out, if it's implemented outside the SoC (required if we want RGB signals) I can really only find one chip that is supposed to output RGB signals from a mobile device, and that's the Chrontel CH7023/7024. However Chrontel's website seems to give diverging information, the product list page says it does output RGB SCART, one page only says it outputs S-video and CVBS (it doesn't say it doesn't output RGB though), and the datasheets don't mention anything about RGB-out either. Can anyone provide some insight on this?

 

[goobers]

telcolou should come and give you both a good smacking with a large trout.

How did you know I like seafood?



I posted this a while back on the old thread, but nobody seemed to take notice (maybe because it was a dud suggestion.) What do you guys think about giving the unit an expansion slot? Kinda like the NDS, i'm sure some hackers would come up with crazy hardware add-ons, bringing uses to the system that we would never have imagined otherwise.

Things that come to mind:
- Motion detector
- Light sensor
- Mic
- Next-gen wifi chipsets


I think that if it has USB or serial in, it would be pretty easy to add support for these devices- SparkFun electronics has some nice 3 axis accelerometer boards, and my arduino has a serial to USB chip on it- if i can get the drivers to work on arm linux, it should be no problem at all to work something like that into it. I'm well up for having a go when the device comes out. I think that it's strength will lie in the things that you can add.

 

[zacaj]

Is it possible to add an FPU or 3D graphics card to an ARM processor?

 

[quartercast]

telcolou should come and give you both a good smacking with a large trout.

How did you know I like seafood?



I posted this a while back on the old thread, but nobody seemed to take notice (maybe because it was a dud suggestion.) What do you guys think about giving the unit an expansion slot? Kinda like the NDS, i'm sure some hackers would come up with crazy hardware add-ons, bringing uses to the system that we would never have imagined otherwise.

Things that come to mind:
- Motion detector
- Light sensor
- Mic
- Next-gen wifi chipsets


I think that if it has USB or serial in, it would be pretty easy to add support for these devices- SparkFun electronics has some nice 3 axis accelerometer boards, and my arduino has a serial to USB chip on it- if i can get the drivers to work on arm linux, it should be no problem at all to work something like that into it. I'm well up for having a go when the device comes out. I think that it's strength will lie in the things that you can add.


For these boards, would they be dongle-style addons? I was thinking more of a "gaping-hole" style expansion port where additional cartridges could slot in a la NDS/handheld dictionary devices. Of course the initial cost in designing and fabricating these carts would be higher than that of a USB dongle-style implementation, but it would be more portable and aesthetically pleasing.

 

[goobers]

For these boards, would they be dongle-style addons? I was thinking more of a "gaping-hole" style expansion port where additional cartridges could slot in a la NDS/handheld dictionary devices. Of course the initial cost in designing and fabricating these carts would be higher than that of a USB dongle-style implementation, but it would be more portable and aesthetically pleasing.



I would doubt it, although depending on the design it might be possible to create jackets (like the ones you can get for ipaqs) for it to slot into. We'll have to see I guess.

 

[fusion_power]

Only 160px of horizontal screen real estate would be lost, which is certainly forgivable.

If the GUI of emulators are designed with this device in mind, the additional 160px could be well used for giving quick access to certain functions of the emulator (savestates and the like), or just a nice bezel-type graphic.

I like this idea really. Keeping in mind we are having a touchscreen, it is possible with one quick touch on the screen to make/ load savestates or change some aspects of the emulation (SNES: translucency on/off, ...). I would go a little bit further to think about any possible standards for this. So, that in all emus (at least for the classic consoles/ computers which use 4:3 ratio) the save/load savestate "button" is the same.



Problem would be, the left and right screen areas are close to the D-Pad and the action buttons, so you have to make sure, that you dount touch the screen if you just controlling the game in wild action.

 

[quartercast]

For these boards, would they be dongle-style addons? I was thinking more of a "gaping-hole" style expansion port where additional cartridges could slot in a la NDS/handheld dictionary devices. Of course the initial cost in designing and fabricating these carts would be higher than that of a USB dongle-style implementation, but it would be more portable and aesthetically pleasing.



I would doubt it, although depending on the design it might be possible to create jackets (like the ones you can get for ipaqs) for it to slot into. We'll have to see I guess.


Doesn't the PSP have battery jackets too? I think the keyboard design would probably be too hindered by a jacket add-on.

 

[Exophase]

And zodttd has already indicated PSX is also running fullspeed with sound as well.

No he hasn't.

 

[KeyboardCowboy]

I like this idea really. Keeping in mind we are having a touchscreen, it is possible with one quick touch on the screen to make/ load savestates or change some aspects of the emulation (SNES: translucency on/off, ...).

I too like it. Just a sidenote though that since with a true 2D GPU, there would be no need to implement transparency in software, rather in hardware, so it wouldn't cost CPU time and properly implemented, work without slowing down emulation one iota. CPU workload would impact emulation of non-graphical elements like emulation of the SNES' (fairly weak and thus not very stressful) 65c816 CPU and audio sampling, control handling, application mechanics, interface, etc. I'm going off-topic here, but this does shed some light on the kinds of benefits a properly implemented GPU with its own memory can yield, in addition to just a faster CPU.

QUOTE
@KeyboardCowboy:
There are a lot of posts from you (which I find very interesting) but they have almost all the same contents. For me it would be more iteresting if you take the time and add some numbers. Just stating the Freescale SoC needs less power would be more interesting if oyu can compare it with the MMSP2+.

Certainly. Here's a document from Freescale detailing electrical specifications of the i.MX31. Page 2 reveals it is based on a 90-nanometer transistor process, while documentation from MagicEyes clearly states it utilizes a more primitive 130-nanometer process (presumably their fabrication facilities are considerably less robust than Freescale's, formerly a division of Motorola). Every transistor in a 130nm unit will utilize more power to operate and produce more heat.

Granted, a 130nm part of lower capability will likely use about the same amount of power as a 90nm part with much more. However a 90nm part could just as easily be scaled back, for example a 532 MHz ARM11 CPU core can be brought back to any number of lower clockrates to reduce power consumption, bringing it well below the norm operating at the same spec. The same power consumption with over twice the raw CPU horsepower, and full floating point capability provided is nothing to scoff at, though either. It is also worth mentioning TI, Freescale, Samsung etc. SoCs generally provide more robust power saving mechanisms than MagicEyes parts, but much of what matters is how it is integrated into devices and whether these features are properly utilized.

A common misconception is that say, an ARM11 core at 533 MHz will consume enormous amounts of power compared to say, a 200 MHz ARM9 part. The beauty of ARM's microarchitectures, however, is that they are able to achieve clockrates as high as 1 GHz in mobile chipsets while still only utilizing fractions of a watt of power; while an equivalent 1 GHz PC processor, while more powerful overall, would require over 60 watts at that speed. Other components in ARM's reference platforms (PowerVR MBX 2D/3D Accelerator units, VFP11 Vector-Floating Point coprocessors, of ARM's design, etc.) occupy similarly miniscule amounts of power; especially the VFP11 which would appear, at the lowest level, to be a specialized ARM11 core acting as a floating point unit slaved directly to the main ARM11 unit acting as an integer-only processor. (Due to this implementation and native execution of mixed Integer/Floating Point code in a program binary, it is not necessary to program specially for such a combination, a simple recompile should enable full-speed execution across both cores in floating-point-laden binaries.)

My apologies, that was a little wordier than I wanted it to end up.

 

[KeyboardCowboy]

Is it possible to add an FPU or 3D graphics card to an ARM processor?

Yes; the ARM architecture has provisions for it via the standard reference platform over the "AMBA" bus standard. However, it costs less, simplifies board design, system design and engineering time/effort, to opt for an SoC that pre-integrates a CPU/FPU/GPU solution as well as other controllers like audio, LCD control, I/O for buttons, USB, SD, what have you. In large numbers this is very inexpensive to do and why the GP2X had an MMSP2 rather than most handheld consoles having a number of specialized parts made inhouse that are rather expensive on their own. Adding components OUTSIDE an SoC is a much messier situation and not always possible, so it's better to choose an SoC from the start that integrates every component and controller you require at the outset.

 

[Squidge]

QUOTE

#1. A chipset from Samsung or TI's OMAP series, or Freescale's i.MX31 would be superior selections over the MagicEyes MMSP2+, providing dramatically better performance, easier utilization of secondary processors and graphics hardware, better documentation and lower power consumption for only a very small increase in price.



Source?

QUOTE

#2. If the MMSP2+ is used, it is critical each CPU Core and the 2D/3D accelerator blocks have their own discrete RAM and path to it. A memory bottleneck will cripple performance, potentially to the point of making any new machine perform just like a GP2X with higher clock speeds, and may negate all advantage of true graphical acceleration.



Agree, although I see the mmsp2+ has multiple memory controllers, so this shouldn't be an issue.

QUOTE

#3. The memory selected must also be MobileDDR rather than SDRAM, or performance will suffer dramatically, especially at high video resolution such as the proposed 800x480, due to the sheer amount of data traversing the bus every time the screen is redrawn (at the very least 60 times a second, potentially 100 or more). This will also require less voltage supplied to memory, and therefore reduced power consumption.



What are the advantages of MobileDDR compared to regular DDR, apart from the obvious power consumption savings such as PASR ?

 

[Dzz]

Just speculation, but I'd expect that we'll see separate memory banks for the two main processors, but no dedicated bank for the "GPU" -- I am not sure that's even possible.

The thing I'm burning with curiosity about is the OpenGL ES 1.1 implementation. In the marketing material we are allowed to see, it says "OpenGL ES 1.1 support (Limited)". If "Limited" means the "Lite" 1.1 specification, that would be great. It could also mean that certain features aren't supported and if that's true it would be cool to know which ones.

We will get the documentation someday I assume, and all will be clear!

 

[thumpgun]

i want a rubber coated back on it , so it doesn't slip when my fingers get sweaty ...that sounds awful ...lol....

 

[EvilDragon]

I'll restate my more important remarks due to the demise of the prior thread.
#1. A chipset from Samsung or TI's OMAP series, or Freescale's i.MX31 would be superior selections over the MagicEyes MMSP2+, providing dramatically better performance, easier utilization of secondary processors and graphics hardware, better documentation and lower power consumption for only a very small increase in price.

Umm... MagicEyes belongs to Samsung

 

[KeyboardCowboy]

@Squidge: There are quite a few sources- pricing of i.MX31 parts for example, was roughly $25 when purchased in a quantity appropriate for a device like the GP2X; this was per correspondence I was provided during talks with GamePark regarding development of the XGP series (before they went bottom up.)

As for improved performance, that bit should be evident due to the ARM11 architecture, higher clockrate (532 MHz vs. 360 MHz), presence of the VFP11 vector-floating point coprocessor. The 2D/3D acceleration components appear to be common between the MMSP2+ and i.MX31, as well as many other ARM-based SoCs, judging by the specifications provided being nearly identical (as little info is provided by MagicEyes regarding the graphical blocks of the MMSP2+. The publically available white paper for the chip is fairly minimal.)

I don't need to explain to you that the MMSP2+'s multiple memory controllers would only be useful if they are tied to multiple banks of memory, rather than one big 128MB RAM IC and one controller utilized, as an example. We'll just have to hope the designers of the machine make the most of the chipset and don't let useful features be wasted.

I stated MobileDDR for its power-saving properties rather than any other virtue. The most important aspect is the use of DDR over SDRAM though.

@Dzz: Reading I've done on the PowerVR MBX core utilized in the ARM reference standard indicates it can be tied to dedicated memory, though this is not strictly necessary. It would be recommendable if the screen resolution is to be 800x480 though, that it at the very least not be sharing a bus with that much traffic with a CPU core, let alone two, trying to communicate with their own RAM. I suspect they do mean "Lite" by "Limited"; MagicEyes likes to substitute odd synonyms in their datasheets in parts that are, otherwise, copy-and-paste from documents describing the integrated blocks themselves. Like the MMSP2 I'm sure there are vastly more detailed docs (though probably just as strangely worded.) However what sort of a business relationship is needed to coax them away from MagicEyes, I do not know, and if they are able to be publically released to a community of developers or if they're under some NDA... I'm unsure if the document that was made available within the GP2X community detailing specifics of the MMSP2's operation was an official release or someone just leaked it.

I'll restate my more important remarks due to the demise of the prior thread.
#1. A chipset from Samsung or TI's OMAP series, or Freescale's i.MX31 would be superior selections over the MagicEyes MMSP2+, providing dramatically better performance, easier utilization of secondary processors and graphics hardware, better documentation and lower power consumption for only a very small increase in price.

Umm... MagicEyes belongs to Samsung

However their product lines are quite dissimilar. They also do not appear to share fabrication facilities, since MagicEyes parts use a considerably older transistor process. If I had to make an educated guess about the nature of Samsung and MagicEyes' business, it would be that Samsung licenses SoC design technologies and intellectual property to MagicEyes, who produces SoCs in smaller quantities using more primitive fabrication for smaller customers. This would explain why their chips are somewhat behind Samsung's in terms of adapting to the curve of evolving technology, and why they market to such specific customers with SoCs designed for use in say, a handheld video player (which was adapted into the GP2X) or an arcade system. It would also explain their "Custom ASIC Service".