Gcw Zero - Discussions

[Pleng]

Does anybody know anything about this?. Any info on who's doing it? Is it legit?

 

[WizardStan]

We've got some major discussion going on with the developers over at the other boards

 

[Akabei]

We've got some major discussion going on with the developers over at the other boards

So, you(as a moderator here) are saying, that it's useless to watch this forum for news about an open handheld and register for a commercial forum, instead? Well, I guess, this was the final call here.

 

[erico]

I would not think that way.
It is just that the thing got posted there first time and a discussion is already going on it. It may be a good read.
It is also at the GLB boards too.

 

[WizardStan]

So, you(as a moderator here) are saying, that it's useless to watch this forum for news about an open handheld and register for a commercial forum, instead? Well, I guess, this was the final call here.

Didn't think of it that way. I was just pointing out where I saw the discussion happening. Sorry.

 

[Akabei]

Didn't think of it that way. I was just pointing out where I saw the discussion happening. Sorry.

Whatever, the discussion here immediately stopped. Not only, that this forum certainly needs some new impulses, I even think a discussion about the GCW would fit much better in this place(or maybe I should say: would have fitted ).

 

[erico]

I agree with you Akabei, we sure need more impulse around and the GCW, being an open handheld, deserves an extended discussion.

I do own a caanoo and look around here for my prime sources on it. I have been doing stuff for it and I intend to release here.
Don´t leave, You do a great job on your front!

 

[Akabei]

I don't plan to leave, though my caanoo is almost dead(analog control is broken, so only touchscreen programs work).
So, ok. Back to topic. I can't really say much about the Zero, as I've just seen qbert's videos. The case looks a lot like the Dingoo, which is much better, than all those chinese PSP-clones. I have absolutely no idea about the performance of the cpu/gpu. I wonder, why they didn't use the Arm/Mali combo, plugged in all the chinese android handhelds(ok, Opendingux implementation might be too hard/impossible). Did anyone here preorder the device?

 

[Pleng]

I haven't ordered and don't really have much more than a passing interest in the device. I agree with Exophases comment on the other board; it would be good for a company to target the more mid-range market, now Pandora's prices have sky rocketed.

I also find it most odd that there's only a fleeting mention of the issue of the prorder units having twice as much ram as retail units. The way I see it is it could go three ways, none of them beneficial:

• No software is made to make use of the extra ram (most likely)
• Software is made to make use of the additional ram, and there's only 100 units worldwide that can use this software (least likely)
• Software is made to make use of the additional ram, and all subsequent batches include the additional RAM, leaving a small quantity of customers (who didn't preorder but purchased from the first available retail batch) with units that can't make use of a certain percentage of the software (second most/least likely).

I would have concentrated on maximising the internal storage for pre-orders (though they're already giving 16Gb, which is pretty generous), which is useful, but doesn't potentially impede other users.

 

[flatmush]

I haven't ordered and don't really have much more than a passing interest in the device. I agree with Exophases comment on the other board; it would be good for a company to target the more mid-range market, now Pandora's prices have sky rocketed.

I also find it most odd that there's only a fleeting mention of the issue of the prorder units having twice as much ram as retail units. The way I see it is it could go three ways, none of them beneficial:

• No software is made to make use of the extra ram (most likely)
• Software is made to make use of the additional ram, and there's only 100 units worldwide that can use this software (least likely)
• Software is made to make use of the additional ram, and all subsequent batches include the additional RAM, leaving a small quantity of customers (who didn't preorder but purchased from the first available retail batch) with units that can't make use of a certain percentage of the software (second most/least likely).

I would have concentrated on maximising the internal storage for pre-orders (though they're already giving 16Gb, which is pretty generous), which is useful, but doesn't potentially impede other users.

Since the system is running linux and the emulators it uses are all fairly low on memory usage the majority of the RAM will simply be used for caching disk accesses anyhow so it should make little difference most of the time and when it does make a difference will be a speed increase accessing larger files such as ISOs.

As for the reason with sticking with Ingenic there are a few:
1. Performance for price Ingenic always seem to win over ARM probably due to licensing fees.
2. Ingenic chips are pretty well documented meaning that it's easier to run a custom OS (Dingux) on it.
3. It's a spiritual successor to the Dingoo and using an Ingenic chip means it can maintain some level of backwards compatibility.

I personally prefer Ingenic stuff in terms of documentation and speed.

 

[Exophase]

As for the reason with sticking with Ingenic there are a few:
1. Performance for price Ingenic always seem to win over ARM probably due to licensing fees.
2. Ingenic chips are pretty well documented meaning that it's easier to run a custom OS (Dingux) on it.
3. It's a spiritual successor to the Dingoo and using an Ingenic chip means it can maintain some level of backwards compatibility.

I personally prefer Ingenic stuff in terms of documentation and speed.

Some interesting points of view, but I don't know.. My thoughts/comments:

1. Do you have any data points you can share for this? From what I've seen the most differentiating factor is that the SoCs are made in China using cheap processes, not being MIPS instead of ARM. For instance prices I've heard for amlogic and Allwinner SoCs with Cortex-A8 and Cortex-A9 were similar to the prices for this Ingenic SoC. The licensing costs for lower end hard macros are probably not that high, and all of the companies still end up licensing GPU technology and probably video encode/decode.

2. I've seen datasheets for Chinese ARM SoCs and they're all pretty much the same quality as the Ingenic one (so-so).. ones for western SoCs like those made by TI, Freescale and Samsung are very thorough. Others like nVidia's may be hard to obtain, but for the most part I don't think Ingenic has any real advantage - certainly not for SoCs that you can actually purchase in moderate volume.

The real difference, where using Ingenic is a big disadvantage, is the documentation for the CPU. The ARM CPU architecture is very well documented, and most ARM designed CPUs (ie, not those by Qualcomm for instance, but those would probably not be in consideration) have publicly available TRMs that give at least some level of timing information. Ingenic tells you close to nothing about the CPU design and doesn't even have a good document for their ISA extensions. So if you're writing assembly you have no idea how to best optimize for performance, and for these low end in-order processors it really helps to be able to do this.

3. True, but on the flip side having ARM + Linux would give you easy ports from other ARM handhelds and probably allow a port of something like GINGE for direct compatibility (good luck trying to get notaz to do that for Dingoo compatibility on GCW). And IMO this is a bigger win because ARM devices had more emulators and typically better optimized ones; a lot of the more popular Dingux emulators are using C cores where the GP2X/Wiz ones used ASM.

Especially perplexed by your comment that you prefer them based on speed.. as far as I can tell Ingenic is quite behind many other offerings, having only a single-issue in-order core it's not even up to Cortex-A8 level, not to mention weak SIMD support. A lot of other cheap ARM offerings seem much better to me. Have you done any performance comparisons that make you feel differently?

 

[zear_]

3. True, but on the flip side having ARM + Linux would give you easy ports from other ARM handhelds and probably allow a port of something like GINGE for direct compatibility (good luck trying to get notaz to do that for Dingoo compatibility on GCW). And IMO this is a bigger win because ARM devices had more emulators and typically better optimized ones; a lot of the more popular Dingux emulators are using C cores where the GP2X/Wiz ones used ASM.

I don't know if you follow the Dingoo scene, but GCW is already backwards compatible with the Dingoo A320, because they both use the same distribution (OpenDingux). I am running Dingoo A320 binaries on GCW as we speak. We'll probably deviate a little bit in the future, since GCW has analog joystick and g-sensor, so it's a good idea to move from keyboard input to joystick input. However backwards compatibility with the Dingoo at that point will be just a matter of translating the joystick input into keyboard input and using the soft-float Dingoo rootfs instead of the hard-float GCW rootfs (export LD_LIBRARY_PATH).

 

[Exophase]

Fair enough - does this require chrooting a different kernel then? Nonetheless, compatibility with GP2X and Wiz is at least as big of an advantage as compatibility with Dingoo.

 

[zear_]

Fair enough - does this require chrooting a different kernel then?

Not at all. Both platforms are binary compatible (Dingoo A320 having jz4740, while GCW jz4770 cpu), and since they use the same distribution, a fair amount of Dingoo A320 OpenDingux software runs on top of GCW OpenDingux kernel.

 

[mth]

Fair enough - does this require chrooting a different kernel then?

No kexec or chroot will be required, just an adjustment of library search paths. The issue is that because the JZ4740 in the Dingoo A320 has no hardware floating point support and floating point emulation in the kernel is super slow, the A320 toolchain and rootfs are built with softfloat support. This works fine on the GCW Zero as well. However, the JZ4770 does have hardware float support and that is faster than softfloat, so we want to support hardware floats. That might require a second set of libraries compiled with softfloat support turned off, since the calling conventions are different (you can't pass values in floating point registers if your CPU doesn't have them).

Nonetheless, compatibility with GP2X and Wiz is at least as big of an advantage as compatibility with Dingoo.

As far as I know there isn't really a cheap and open ARM console at the moment though. The Pandora is a great device but it is in a different price category.

In any case, what we're aiming for with OpenDingux is maximum source compatibility by using standard Linux interfaces wherever possible. Ideally the effort to bring software from one device to the next is just a recompile. This won't work for every application of course: if you have an emulator with a JIT compiler, porting will still be a significant effort, but many simpler applications wouldn't need code changes.