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.WizardStan said:
Didn't think of it that way. I was just pointing out where I saw the discussion happening. Sorry.Akabei said: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.
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 ).WizardStan said:Didn't think of it that way. I was just pointing out where I saw the discussion happening. Sorry.
Pleng said: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:
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.
- 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).
flatmush said: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.
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 said: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.
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.Exophase said: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).Exophase said:Fair enough - does this require chrooting a different kernel then?
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.Exophase said:Nonetheless, compatibility with GP2X and Wiz is at least as big of an advantage as compatibility with Dingoo.