Craigix Discloses Information On New Gp2x?


Status
Not open for further replies.
Another interesting question about the screen (besides image quality and reaction time) would be:
HAS THE SCREEEN ANTI_REFLECTION? Or does he glare like the GP2X which gets annoying if you want to use it on fresh air especially when Sun is shining. ^^
I don't know much about touchscreens and possible anti-reflection surfaces but would be cool, if the new Handheld Screen wouldn't be shine like a pocket Mirror. :)
 
Would a swivel for the keyboard work? Seems like such a simple solution. Or is that patented too?

swivelyf5.gif


Edit: added image

dpadvy3.jpg


Edit2: Added image of a new take at a dpad. Hopefully not patented...
 
Eolair said:
Would a swivel for the keyboard work? Seems like such a simple solution. Or is that patented too?
That's pretty cool!
I'm sure everything has a patent that is at least similar to the idea (as there are hundreds of devices with similar ideas), including the "miniature notebook computer" hinge. Somehow all these devices do manage to get built, often at very low prices for low spec devices... but navigating those legal waters is probably a nightmare.
 
Last edited by a moderator:
Squidge said:
There was no steep learning curve on the mmsp2. Anyone could download a compiler and immediately write a game or emulator in a very short amount of time, as everything was available to do so.

The curve I referred to was that of fully utilizing the more advanced features of the MMSP2, where the most capability lies. For example, use of the 940T coprocessor, effective use of the blitting unit, etc. A program that runs on only the main processor with software blitting, for example simple puzzle games produced early in the GP2X's lifespan used inordinate amounts of the machine's resources for what they were, but did run. To use an analogy, a similar game written for the Nintendo DS or Sony PSP that did not utilize any of the machines' more advanced capabilities, such as (NDS): NDS-Side Video hardware, ARM7 Coprocessor and GBA-Side audio/video hardware, or (PSP): MIPS Coprocessor, Vector processor unit, GPU -- would not be very impressive and exhibit very poor performance.

Making available proper libraries and documentation such that it is simple to unlock the full capability of the chipset the device utilizes is critical to the production of software that truly exploits the machine's ability. Otherwise, the end result will be only a few 'killer apps' (most likely emulators) from developers who have essentially reverse-engineered the machine to get it to perform as they wish, and a dramatically larger majority of developers who utilize less than 10% of the machine's true capability for running game software. This is quite the situation the GP2X ended up in, and it would be best avoided if the machine is to have decent appeal.
 
Last edited by a moderator:
jmetal88 said:
Eolair said:
Would a swivel for the keyboard work? Seems like such a simple solution. Or is that patented too?

swivelyf5.gif


Edit: added image
Now that's pretty nifty.

thats awesome!! its should be like that and i would buy that in a heartbeat and it doesnt looked cramped...

btw who is KeyboardCowboy?? He/she came out of nowhere and is "preaching" his/her news
 
Last edited by a moderator:
KeyboardCowboy said:
The curve I referred to was that of fully utilizing the more advanced features of the MMSP2, where the most capability lies. For example, use of the 940T coprocessor, effective use of the blitting unit, etc.
Luckily there are a lot of gp2x devs who are finally used to referring to the MagicEyes databook for the MMSP2. When I first started playing with the gp2x I couldn't make heads or tails out of it, but I learned as time went on and now believe it will not be difficult to get up to speed on the MMSP2+. And there's dozens of other devs like me who could adapt equally quickly. Maybe I'm being optimistic on that front, and nothing ever goes as smoothly as you'd hope, but I'm not too worried.

It would be "nice" to have documentation like is available for the i.mx31, but assuming the databook will be freely available (it is not right now), that should be good enough for this tinkerer crowd. For example, I would predict that a version of SDL making good use of the acceleration features of the MMSP2+ will be available much more quickly on a new machine than it was on the gp2x.

I'm all for free speech and criticism, but if development is far enough along it is probably not too helpful to argue so strenuously for reversal of decisions that are apparently made.

I hope you stick around beyond the initial revelations; you're obviously quite well informed and intelligent, and could be a big asset in puzzling through the capabilities of a new device.
 
Last edited by a moderator:
Xmoon said:
All tv have rca video in.
Most tv's have s-video, you need an euroconector/rgb adapter.
Actually I've owned several TV sets which has had proper RGB SCART but no RCA or S-video inputs whatsoever. So I guess in Europe, SCART really is the most common connector (bar regular RF-in) and it does offer superior quality over S-video and CVBS (if used with a proper RGB signal, but it can handle all of the "worse-quality" signals too if need be) so I can see why there'd be no need for RCA or S-video inputs here.

Personally, I do my best to ensure all equipment that will be hooked up to my TV set outputs proper RGB suitable for SCART. Even with my TV set being a regular standard-definition CRT, using RGB instead of S-video dramatically increases the picture quality (S-video, Composite and RF are virtually impossible to tell apart for me as they all look crappy on my particular TV, at least after I've now become so accustomed to the quality of RGB).


As for the internal screen of the new device, I just want to mention the viewing angle. I'm fairly pleased with my GP2X Mk2's screen, it's crisp and shows no problems with interlacing, white borders and other things commonly affecting First Edition and Mk1 screens. However I have to be rather particular about the angle at which I hold the device in order for the picture not to be washed out. So perhaps that's something for the designers of this new unit to be aware of. Also the high-gloss finish of the screen may be annoying at times (producing glare) but it does seem to be the way screens are commonly designed these days (just look at all high-end laptops for instance) so I'm not complaining about that (some might, though).


Eolair said:
Would a swivel for the keyboard work? Seems like such a simple solution. Or is that patented too?

swivelyf5.gif


Edit: added image
That looks very slick, but I'd think such a solution would be less than durable, and a sturdy design is very important in a pocketable or portable device.
 
Last edited by a moderator:
cappuchok said:
Xmoon said:
All tv have rca video in.
Most tv's have s-video, you need an euroconector/rgb adapter.
Actually I've owned several TV sets which has had proper RGB SCART but no RCA or S-video inputs whatsoever. So I guess in Europe, SCART really is the most common connector (bar regular RF-in) and it does offer superior quality over S-video and CVBS (if used with a proper RGB signal, but it can handle all of the "worse-quality" signals too if need be) so I can see why there'd be no need for RCA or S-video inputs here.

Personally, I do my best to ensure all equipment that will be hooked up to my TV set outputs proper RGB suitable for SCART. Even with my TV set being a regular standard-definition CRT, using RGB instead of S-video dramatically increases the picture quality (S-video, Composite and RF are virtually impossible to tell apart for me as they all look crappy on my particular TV, at least after I've now become so accustomed to the quality of RGB).

I have never seen an SCART connector on a TV in the US, and I didn't own a TV with S-Video until two years ago. If the console has RGB out, that's fine, as long as there's a good cheap way of getting composite or S-video out of it too.
 
Last edited by a moderator:
Exophase said:
For A_SN: it won't have an FPU coprocessor
* A_SN flies to the North Pole
* A_SN yells out "WHYYY THEEE FUUUCK NOOOT!!!!!"

:angry:

I for one welcome the next few years of fixed point arithmetic programming :(

What am I gonna be told next? That it won't have a clock?

KeyboardCowboy said:
It is a moot point to discuss if the machine should be capable of 3D or not. A serious deficiency of the GP2X design is the fact that it lacks any real 2D/3D acceleration hardware. There is a blitter, yes, but due to faults in the MMSP2 design, it does not provide any significant advantage over software blitting of graphics.

The designers of this system, whomever they may be, have expressed interest in building a general purpose device, much like a PDA or mobile communications device, that is also capable of comfortable gameplay. In order to keep up with the curve of technology (as well as maintain compatibility with the widest range of pre-existing software), a modern SoC using an ARM-series processor, ideally ARM11 (but ARM9 would work as well) would be the logical route to take. They have also expressed interest in multi-CPU architecture. SoCs from Samsung or Texas Instruments' OMAP series would more than fit this need. The ideal choice, I believe, would be the Freescale i.MX31, but a number of products could fit the bill nicely.

The point is, all of these products provide 2D and 3D acceleration, because in modern SoCs, the two are one and the same. The most common graphics implementation, because it is ARM's reference standard, is PowerVR's MBX architecture. This provides powerful 2D acceleration for very intensive 2D games, enabling enormous gains over software blitting and additional effects very useful for homebrew titles as well as intensive emulation, such as alpha blending, scaling, rotation; as well as a full host of 3D features, high fill rates, and impressive maximum polygon counts (>1 Million).

Such SoCs also implement Vector-FPUs which would be more than suitable for accelerating 3D transform math, or could be implemented for use in intensive emulation, many applications of which require or would be able to make use of a proper FPU. Many modern SoCs also include a programmable DSP with a limitless array of possibilities for its use.

This is in addition to a powerful CPU, often in excess of 500 MHz, which still draws minimal amounts of power. The dual 200 MHz CPUs in the GP2X's MMSP2 chipset give a poor estimation of proper power consumption, as the MagicEyes-designed implementation is primitive, breaks ARM's reference standards, and uses a very old fabrication process, all of which result in excessive energy waste. A properly-designed mobile device utilizing a 533 MHz ARM11 processor, VFPU and MBX 2D/3D accelerator-integrated SoC would not have difficulty attaining a battery life of over 4 hours under typical use, and this is a conservative figure. It's not uncommon to see PDAs attain the same. Use of a WiFi radio would of course decrease this life, as in any device and exact battery life will depend on the capacity of the LiIon battery included. This power draw could be further reduced by implementing software controls to adjust WiFi transmitter power as well as clockrate of major SoC blocks (CPU, Secondary CPU, VFPU, Graphics Subsystem). Modern ARM architecture includes numerous power saving facilities that are not utilized by the GP2X's ARM920T or ARM940T.

If there is anything the GP2X has proven, however, it is that the smallest mistake can cripple a machine if it impacts how the unit is controlled. It is imperative any machine meant to correct the GP2X's faults do away with the issue of nonstandard and cumbersome controls first and foremost.
Boy that was insightful and informative!

epitaph said:
You've been banned several times. Take the hint and don't come back.
So far the guy's made quite some pertinent posts in this thread, so leave him alone, plus nothing shows he's Epicenter.

Alex. said:
You admitted that some great GP2X software got released, so what seems to be your problem?
Getting hardware that has a limited performance over what it could easily have had? We could have had quite better for the same price, that's what his point is, once stripped of technical arguments, I believe.

Surely the MMSP2+ is cheaper than the rest of the concurrence, and performs better than the MMSP2, but is it the compromise we want, I ask you? How much more do other better performing cost? How much would you be ready to put in for a better performing console?

Here's an idea, Keyboard Cowboy, make a market survey. Estimate the price difference between a console with a MMSP2+ and a console with the SoC you think would be best, accessorily make sure with craigix you got it right, then explain to people how it would make a difference in raw performance, drive for devs to work with the two CPU cores, battery life, etc.. and make a poll asking whether or not you (the buyers) would be ready to pay for the extra cost of the better SoC, and let craigix meditate on the results. Oh did I say "meditate"? I meant "tell you that it's too late to change" ;)

fusion_power said:
Another interesting question about the screen (besides image quality and reaction time) would be:
HAS THE SCREEEN ANTI_REFLECTION? Or does he glare like the GP2X which gets annoying if you want to use it on fresh air especially when Sun is shining. ^^
I don't know much about touchscreens and possible anti-reflection surfaces but would be cool, if the new Handheld Screen wouldn't be shine like a pocket Mirror. :)
Agreed, it's annoying to see my face pop in in the place of every black screen ;)
 
Last edited by a moderator:
Wow, if those tid bits of info come true it looks like it will be an uber GP3X!! I would certainly buy one!
 
KeyboardCowboy said:
I was hoping for an official response on chipset selection for this machine, however, that might be off the table at this point in time. I would however greatly appreciate someone pointing me in the direction of an official comment stating the MMSP2+ has been finalized as an aspect of the design.

While the MMSP2+ provides much needed improvements over the MMSP2, I do have concerns. The MMSP2 had "2D Acceleration", however due to DMA, bus contention and memory management issues within the chip itself, it performed no better than/sometimes worse than software blitting. The exact same would be true if the MMSP2+ has the same design flaws, rendering any 2D/3D acceleration hardware fully useless.

That the secondary processor included in the MMSP2+ again has no MMU will make it impractical for most developers to bother using it at all. I suspect it will be the same case as with the MMSP2- a small handful of developers will make effective use of it, but it will only be practical for a few specific tasks, when a secondary CPU implementation that did NOT break ARM's reference standard would have been useful for nearly any task.

The MMSP2's 130nm process will mean high power consumption and dramatically reduced battery life over its counterparts, a lack of any hardware FPU will be limiting in 3D applications (despite the inclusion of a 3D accelerator), and MagicEyes' documentation shortcomings will make it very difficult to unlock this chipset's potential.

By comparison, more powerful chipsets from other companies (e.g. Texas Instruments, Samsung, Freescale) are more powerful, extremely well-documented and well-supported, consume less power, and are still fully compatible with a Linux OS and therefore existing software.

I'm sure the MMSP2+ is the cheaper option, but I would strongly urge the designers of this machine to make the more rational choice.

For me it is totally irrelevant what Epicenter has done to most of you. But I want one question answerd ONLY from Squidge. As it seems he has coded for teh MMSP2+. I have this link found in this thread:

http://www.mesdigital.com/english/Products...duct_mmsp2p.asp.

There we see two ARM cores: 926ej and 946e. A short google gives those two links directly to ARM so they may be correct:

http://www.arm.com/products/CPUs/ARM926EJ-S.html
http://www.arm.com/products/CPUs/ARM946E-S.html

On the block diagram we see MMUs fro the 926 and MPU 946. The MPU is the same thing which is in the GP2x's MMSP2 and. yes, the same thing as every coder who want to use the 2nd core effectively ( and as we heard LiNUX needs MMU to accept it as a second core). So, why is now everybody so convinced that Epicenter (KeyboardCowboy) is totally wrong and the idea to take the MMSP2+ is teh only right decission?
Or did I get anything wrong? If so please tell me I will be alright. But teh facts above state that the concerns of KeyboardCowboy are real.

And again, if the decission for teh MMSP2+ is simply it is cheaper, I am alright with that. But then please stop talking bullshit about KeyboardCowboys arguments. For me (technical skilled person) they make absolute sense adn most here are NOT that technical skilled (not talking bout Squidge and all teh other well know coders). that is the reason I want this question answerd by any of those coders (Squidge prefefferd)

And if you want to flame me now cause I am trying to understand the problems KeyboardCowboys has then go ahead. Just concerning THIS thread, I give not much of most of the opinions here.

For example teh talk about analoug stick. Why a stick? We want it slim and tiny. OMG!

Upps I almost forgot: The 2nd core has just 4Kb cache. That was the 2nd point every coder is angry bout the MMSP2.
 
Last edited by a moderator:
1. Audio in port, for micro music, games, and for taking note's, maybe even some type skype or team speak type app.
2. solid state Acceleration Sensor/ motion sensor/ no moving parts. You can get them for $3 each or less in bulk.
3. I hope the letter on the keyboard are printed with good paint/ink, I don't wona end up re-draw the letter. I can see lot's of people bitching about it for years.

I'd rather not have a built in keyboard, I'd rather it just be a brushed aluminium rectangle with cover like a calculator. I just dont like any kind of hinge on a hand held.
 
Hi forum,

I don't know if Craigix is still reading wishlists, but I have some things I'd like to see that haven't been brought up yet (if it's not too late and I'm not asking for the moon).

Here we go:
- The 3D acceleration features should be accessible from an OpenGL-compatible (real OGL, not ES) library (which should come on the disc that comes with the unit)
- it should be able to combine a fragment's colour with texel colour so we can have shaded and textured tris at the same time
- it would be awesome if the library implemented NV_POINT_SPRITE
- it would be even more awesome if the library implemented ARB_RENDER_TO_TEXTURE
- in the built-in video player, if there is going to be one, please have MPEG1 support (it has always annoyed me that the gp2x couldn't play back the simplest movie format, but would attempt to tackle nonstandard .AVIs)
- if wifi does end up in the final product (and I really hope it does), please implement support for both WEP and WPA
- any program functionality that can be punted onto a second core/vector units/etc should have an abstraction layer available to it so those who know how to program, but are inexperienced with programming more 'exotic' stuff can still get as much power out of the machine as possible
- there should be a library available for assisting word entry from the joypad, similar to the autocomplete feature in OpenOffice or the T-9 feature found on some cell phones, and it should have switchable dictionaries.

...and to add to things that have already been wished for:

- a realtime clock is kind of a 'must-have' feature, along with some way to set an alarm time to wake the machine up and perform an action
- some kind of to-do-list and phonebook app would be nice (although optional - if the manufacturers don't want to do this, I am sure 3rd party ones will appear in due time)
- I actually don't like sidekick-style keyboards all that much; I seriously think the base unit would be better off without the added weight, cost and (breakable) moving parts of such a thing

And that's my $0.02... :)


Oh, one last question: does it have to be MagicEyes? They aren't the only SoC manufacturer that makes stuff that'd be useful for a handheld game machine - it seems to me Samsung had some pretty juiced ARM-based SoCs with an fpu, sound, USB, an RTC, wifi and 3D (around 1M tris/sec) with the main cpu speed of around 300 MHz for sale a year or two ago (looking for part number as we speak).
 
i don't like the idea of the keyboard behind the screen, because it means the keyboard has to be that much smaller.

also sam, i know what you mean about the touch screen being a substitute for analog nub. and yeah, in some cases it is. but in many it is not. kind of like how the touch screen could handle a virtual keyboard, but that doesn't mean a real one isn't better.

but if it's not there then it's not there. still disappointed though.


there needs to be an RTC...if they go to the trouble of including a keyboard but leave out a real time clock, then count me out.
 
One thing I'd like to have answered by the dev team if possible:
We've established that the device will have USB host capabilities just like the GP2X, that's nice. But will we finally get USB 2.0 host (then I'd be totally sold on this device)?
 
I don't find it surprising that many persons in this community are excited about the prospect of proverbially being able to squeeze every drop of performance possible out of this machine, whatever core hardware it contains. This is the greatest strength of the GP2X's lifetime; the ability to push a limited platform to its limits.

This was not immediate or planned-upon, however. At the launch of the GP2X, there was much dissent when it was learned that the system's actual capabilities did not live up to the originally-published specifications, and other features were not useful in real-world conditions as they were publicized during pre-ordering. However skilled programmers learned to "make do" and produce quality software. Even so, an extremely small minority had the skills necessary to make effective use of the machine's abilities, as most programmers opted to write games in C/SDL and were not skilled enough/familiar enough with working "against the metal" in pure ASM, writing to registers, etc. to make any sort of effective use of the 940T coprocessor, non-bottlenecked use of the 2D blitter, so forth.

Given these circumstances, why then is there such ambition to accept any proposed design blindly, seeming to ASK for limitation and compromise, rather than push for a platform that will show tremendous promise from the very start? This will result, after the elapsed amount of time it took the GP2X to gain effective killer-apps, in a period during which the hardware will be pushed even further beyond initial assertions of its ability. However the tools of producing software that tests the system's strengths will be open to a wider range of developers, and the inherent feature-set and capability, as well as flexibility and quality (as one example: power consumption) will be vastly improved. Other aspects such as standards-compliance, reference-adherence, quality and thoroughness of documentation, etc. will be higher and not waver throughout the lifespan of the device. This is well worth a slightly increased initial investment, especially if the product is to survive for longer than 2 years.

I digress since it has thoroughly been pointed out that no degree of rational argument will change that it is likely "too late to change anything" and divergent opinions will fall on deaf ears. However I would like to hear at least one official statement that the MMSP2+ has been selected irreversibly as the system's chipset, that it might be determined if any more time should be spent discussing this aspect or if the time is better invested on other issues.
 
kc, please stop using the news of a new console design to sneak in your criticisms of the gp2x. if nothing else, it's simply not practical.

but i agree with you that adherence to standards is key. it is the best thing about the gp2x, it has encouraged much of the great software we have. i would also add that it may be as or more important than which SoC is used.

also, the fact that a small minority discovered some ways to bring out more of the gp2x's potential is not as relevant as you make it out to be, since the nature of the gp2x is such that they gladly shared their methods with others.

if you have plans to make commercial software for this then you probably want the documentation complete and you want it early. but why not just wait a bit and see what happens?
 
Status
Not open for further replies.
Back
Top