GCW Zero - Open Source Gaming Handheld


Thanks for the break down Exophase as I said before there is no reason to compare the Pandora or Yinlips or JXD to the GCW-Zero they all have diffferent compnents/processors etc and different purposes/OS.

True. I do however have a question - why is that Ingenic, or maybe other very low end SoC makers, seems to always be the default choice for a homebrew handheld? Is a ~$100 price point really that sacred?


All of these handhelds seem to be pretty incremental improvements off of each other. I appreciate that improvement really does exist, and even Ingenic has been moving forward, and in a lot of ways it's better to move up while staying at the low end than sit with the same thing for several years that maybe once was mid or high end. And I understand the advantage of sticking with Chinese manufacturers and distributors for the most significant BOM items. But when it comes to SoCs things have been moving faster with other Chinese vendors. Something like Rockchip RK3066 is light years ahead of Ingenic JZ4770, and since it's showing up in tablets that are well under $300 (I'm seeing one pre-order source at $219) I doubt designs using it are that much more expensive. These new SoCs offer a great opportunity because unlike the leading edge from big vendors like TI, nVidia, Qualcomm, or Samsung, there's a realistic chance of procuring them in more modest volumes for reasonable prices. Or so I've been led to believe, please correct me if this is not the case.


It's not just specs either, you're really better off sticking with ARM. True, with MIPS you can at least try to salvage the PSP emulators, and this might help for N64, but it's still a ton of work over what you get with the ARM optimized emulators.


I feel that there's a lot of potential for the mid to high range for these devices these days, that can offer a lot more than what looks like a moderately upgraded Dingoo or Caanoo. Pandora was supposed to serve this market with a $300 price-point years ago, but that turned into $500 and is looking like it'll go up to $600, all while sticking with mostly the same hardware. I can definitely see something at a $300 or less price point giving Pandora a run for its money, especially if you decide to include a keyboard.
 
At $300 it would have to compete with the Pandora. At that point the question would be why not just get one of those. With no current gp32/dingoo devices in this power range I think it fills the niche nicely.
 
It's not just specs either, you're really better off sticking with ARM. True, with MIPS you can at least try to salvage the PSP emulators, and this might help for N64, but it's still a ton of work over what you get with the ARM optimized emulators.

I thought the whole idea behind the Zero was to make it an updated budget homebrew handheld running OpenDingux? Justin (GCW) is a dingoo distributor (DDUSA) and most of the devs working on it are over at Dingoonity, but you probably already know this.
 
I thought the whole idea behind the Zero was to make it an updated budget homebrew handheld running OpenDingux? Justin (GCW) is a dingoo distributor (DDUSA) and most of the devs working on it are over at Dingoonity, but you probably already know this.

Maybe, but I don't think there's an awful lot of intrinsic attraction to sticking with the same set of software just because that's what you've sold before. Sure, if you have something MIPS based you're best off using OpenDingux but is it really better than a good ARM OS that can run either Android software or Pandora software, or at least can have ARM ASM heavy emulators easily ported to it?

At $300 it would have to compete with the Pandora. At that point the question would be why not just get one of those. With no current gp32/dingoo devices in this power range I think it fills the niche nicely.

Because:


1) Pandora is in reality $500 and sounds like it'll eventually be $600, putting it in a much different price ballpark than $200-300. Asking "why not just get one" is no more valid for a $600 device over a $300 one than it is for a $300 one over a $100 one.


2) A lot of Pandora's design is pretty out of date even with the upgraded RAM and SoC (for instance no digital TV-out, no software support for even 720p, much less 1080p video, etc)


3) Pandoras are in very limited supply and difficult to obtain, and if you do get one heaven help you if it breaks


4) There's lots of possible alternatives to Pandora's design/form factor/etc that could appeal to others on a subjective basis - variety is good


In the category this handheld is playing in there are MANY competitors. This may well edge out many in features and/or price, but it's not really that pronounced. I don't know how the logic of wanting a "current Dingoo" works better than wanting a "current Pandora." On the flip side, I don't think the cycle of constantly buying a new $100-150 console with minor updated specs is that much of a better value proposition than buying a $250-300 less routinely.
 
Last edited by a moderator:
3) is no issue anymore, we've started selling from stock a few days ago and could easily spice up production to 250 per week when the demand is there (and even higher if we REALLY need to).


But yeah, the rest is totally plausible. Thanks to CC we're behind with the hardware, even though the user experience is usually better compared to devices using the same old SoC (N900 OS feels a lot more sluggish).


How I wished there was a pin-compatible CortexA9, but that's not existing. So it seems the A15 will be next :)


I'm not sure about those Rockchip / etc. chips from China, but based on my experience, it's getting harder and harder to get stuff in low numbers from China (low numbers for them is about 10,000).


Also, the quality seems to be an issue. From what I heard, there are a lot more failures with Rockchips than you get with OMAPs.


I haven't had a single broken OMAP yet - they all seem to be tested.


And they also don't fail after a while - seeing those JXD forums, it seems quite a few of the working ones break after a while of usage.


From internal informations I got from GC, they had experienced a lot of quality issues with Chinese SoCs. One had a failure rate of 25%. It was no Rockchip (forgot which brand it was). I don't know exactly how it is with the Rockchip, but it could be similar here.


Usually you won't find out that the SoC is broken unless it's populated. So you either throw the PCB away or remove it and put another one on.


Most Chinese tablets and PMPs seem to have SoCs with minimal other hardware components around them, so they probably just throw away the PCB when it doesn't work.


Given their high output rate, throwing away that PCB will probably cost 10-15 USD.


With the Pandora, that would be a loss of 140 EUR per PCB, so not feasable.
 
I think this device is more of a souped up Dingoo A320 more than anything, rather like what the Wiz/Caanoo were to the GP2X. The Wiz didn't bring that much more over the GP2X because latter got much support and some very optimised emu's and Wiz wasn't a lot more powerful and just ended getting the GP2X ports. I hope this will not be the case here and we see a lot of support and emu's developed specifically for it.


Exophase are you going to support the GCW?
 
Thanks to CC we're behind with the hardware

I seem to remember CC having to wait a long time for parts to be supplied towards the beginning of the project, and lots of delays/changes from OP's side. You guys seemed to be communicating quite well then it deteriorated. Was that partially OP's fault? Not that that has anything to do w/ gcw!
 
Thanks to CC we're behind with the hardware
I seem to remember CC having to wait a long time for parts to be supplied towards the beginning of the project, and lots of delays/changes from OP's side. You guys seemed to be communicating quite well then it deteriorated. Was that partially OP's fault? Not that that has anything to do w/ gcw!

The delays with the cases at the beginning and the nub issue was basically our fault (CC couldn't do anything there).


However, after those two issues was resolved (which was December 2010), it was entirely CC who was unable to do the production.


At that time, parts, cases, etc. were all there.
 
I seem to remember CC having to wait a long time for parts to be supplied towards the beginning of the project, and lots of delays/changes from OP's side. You guys seemed to be communicating quite well then it deteriorated. Was that partially OP's fault? Not that that has anything to do w/ gcw!
Don't forget that, when the nub thing happened, CC said they were going to go ahead with populating all the boards so the nubs could just be dropped in and shipped. After a few months they even said the boards were done and waiting. Then when the nubs were ready, oops, absolutely none of that was true.
 
I seem to remember CC having to wait a long time for parts to be supplied towards the beginning of the project, and lots of delays/changes from OP's side. You guys seemed to be communicating quite well then it deteriorated. Was that partially OP's fault? Not that that has anything to do w/ gcw!
Don't forget that, when the nub thing happened, CC said they were going to go ahead with populating all the boards so the nubs could just be dropped in and shipped. After a few months they even said the boards were done and waiting. Then when the nubs were ready, oops, absolutely none of that was true.

True, so 4000 Pandoras should've been finished and delivered January 2010...
 
Had a good question asked today....OpenDingux, will I be able to build an app that was ported to OpenDingux (for the Dingoo A320) and install it on the GCW Zero?


Even though this is running Open Dingux you will have to use the new tool chain we are developing and recompile the source to make it run on the GCW-Zero. But we are working on porting most of the items on Open Dingux for you so it might already be on console when you get it.
 
I'm not sure about those Rockchip / etc. chips from China, but based on my experience, it's getting harder and harder to get stuff in low numbers from China (low numbers for them is about 10,000).
Also, the quality seems to be an issue. From what I heard, there are a lot more failures with Rockchips than you get with OMAPs.


I haven't had a single broken OMAP yet - they all seem to be tested.


And they also don't fail after a while - seeing those JXD forums, it seems quite a few of the working ones break after a while of usage.


From internal informations I got from GC, they had experienced a lot of quality issues with Chinese SoCs. One had a failure rate of 25%. It was no Rockchip (forgot which brand it was). I don't know exactly how it is with the Rockchip, but it could be similar here.

Many manufacturers make SoCs in China. It sounds like you're generalizing the entire country's production based on some anecdotal information. For instance JXD devices use a wide variety of SoCs, are you sure the ones you were referring to had Rockchip SoCs? And would an eventual console failure necessarily indicate an SoC failure (how many Pandoras have had to be sent back?)

Usually you won't find out that the SoC is broken unless it's populated. So you either throw the PCB away or remove it and put another one on.

Most Chinese tablets and PMPs seem to have SoCs with minimal other hardware components around them, so they probably just throw away the PCB when it doesn't work.


Given their high output rate, throwing away that PCB will probably cost 10-15 USD.


With the Pandora, that would be a loss of 140 EUR per PCB, so not feasable.

That's a good motivation to do the more complex core logic (SoC, RAM, power) on a separate PCB that sockets into another PCB which can be lower layer/complexity. Then you can test/replace separately, and more easily upgrade that part of the design in isolation. It may also cost less.


Do you actually have numbers on volume for any Chinese tablet? Given the huge variety sold isn't it hard to believe that there are runs in the millions or even hundreds of thousands? You say it often but I really don't see evidence that going from Pandora volume to 10x that needs to increases costs by 10x, distributor component pricing never follows a curve anywhere this drastic..

Had a good question asked today....OpenDingux, will I be able to build an app that was ported to OpenDingux (for the Dingoo A320) and install it on the GCW Zero?


Even though this is running Open Dingux you will have to use the new tool chain we are developing and recompile the source to make it run on the GCW-Zero. But we are working on porting most of the items on Open Dingux for you so it might already be on console when you get it.

Why won't this device support the old binaries natively?
 
Last edited by a moderator:
I seem to remember CC having to wait a long time for parts to be supplied towards the beginning of the project, and lots of delays/changes from OP's side. You guys seemed to be communicating quite well then it deteriorated. Was that partially OP's fault? Not that that has anything to do w/ gcw!
Don't forget that, when the nub thing happened, CC said they were going to go ahead with populating all the boards so the nubs could just be dropped in and shipped. After a few months they even said the boards were done and waiting. Then when the nubs were ready, oops, absolutely none of that was true.

I thought that CC had populated the boards but because of all the waiting the boards had oxidised? I'm not sure if its standard practice to semi-populate a board and then wait months for the last part to be 'dropped in'.
 
Why won't this device support the old binaries natively?


Let me rephrase that it will run them but they won't be as optimized or have all functions the new hardware provides without recompile...
 
Let me rephrase that it will run them but they won't be as optimized or have all functions the new hardware provides without recompile...

What new functions and performance will recompiling provide? The difference between instruction set (MIPS32 r1 and MIPS32 r2 afaik) is minimal and the compiler won't be able to interface with anything else on the SoC. Is it down to improvements on libraries that are being statically linked?
 
I thought that CC had populated the boards but because of all the waiting the boards had oxidised? I'm not sure if its standard practice to semi-populate a board and then wait months for the last part to be 'dropped in'.
No, they oxidized because they didn't solder any parts to them for months. It probably isn't standard practice to wait, as you say, because standard practice doesn't involve having to rebuilt key components from scratch. But standard practice or not, it was what they had promised to do and would have been the correct course of action to avoid the oxidation that we ended up with.


The oxidation itself caused major problems, and if CC had just been upfront about it then OPT could have just got more boards. Bare boards are relatively cheap, easy enough to replace. But CC insisted they could clean them, that it wasn't going to be a problem. 25% failure rate later...
 
I thought that CC had populated the boards but because of all the waiting the boards had oxidised? I'm not sure if its standard practice to semi-populate a board and then wait months for the last part to be 'dropped in'.

Nope, they didn't populate them, that was the issue.


The nubs are manually being soldered onto the PCBs, oxidized contacts wouldn't be a big deal when manually soldering them.


The oxidized contacts are an issue when the PCBs are NOT yet populated, as machine population with oxidized contacts leads to these issues (there are many very small pins below all the SMD chips, you can't see whether they're soldered properly or not).


As machine population and manual soldering (the nubs) are two completely different steps in the production process, it's pretty common to do the machine population a while before.


GC has 500 populated PCBs lying around that are just waiting to be populated with nubs and volume wheels.


Usually, you let the machine do a full run (as simply loading the machine for a PCB like the Pandora takes 8 hours) and then you do the manual steps depending on demand and manpower.

Many manufacturers make SoCs in China. It sounds like you're generalizing the entire country's production based on some anecdotal information. For instance JXD devices use a wide variety of SoCs, are you sure the ones you were referring to had Rockchip


SoCs? And would an eventual console failure necessarily indicate an SoC failure (how many Pandoras have had to be sent back?)

Well, except for the later batches from CC (where the boards became flakey because they oxidized), I have yet to see a single Pandora PCB that had issues after a while of usage.


There were some that had issues from the very beginning which haven't been tested (i.e. charging issues), but the ones that worked never came back.


The only PCBs I got back was nubs and LCD Cables, no suddenly non-working PCBs.


(Well, as said, except for later CC batches with bad contacts).


I don't know about what JXD used where, but I've spoken to different companies here and their experience, and I also had some experiences with Chinese companies already... over 10% of the Dingoos failed within 2 months when I shipped them.


Quite a few assembly houses told me they had a WAY higher failure rate when getting SoCs from China, regardless which SoCs.


This doesn't necessarily have something to do with the production company - often there are clones or refurbished version sold "as new", and these cause issues.


So you don't know what exactly you will get.


Most companies turn you down when you want to order in small quantities - they tell you to get the parts from a distributor... and then you might eventually have quality issues.


As mentioned, GC once stocked SoCs from a chinese distributor - and they had an 80% failure rate.


Getting the same SoC from a German distributor changed that to a 3% failure rate.


So yeah, it probably more or less are the distributors, not the production companies... though these don't care as much about that than non-chinese companies do.

Usually you won't find out that the SoC is broken unless it's populated. So you either throw the PCB away or remove it and put another one on.
Most Chinese tablets and PMPs seem to have SoCs with minimal other hardware components around them, so they probably just throw away the PCB when it doesn't work.


Given their high output rate, throwing away that PCB will probably cost 10-15 USD.


With the Pandora, that would be a loss of 140 EUR per PCB, so not feasable.

That's a good motivation to do the more complex core logic (SoC, RAM, power) on a separate PCB that sockets into another PCB which can be lower layer/complexity. Then you can test/replace separately, and more easily upgrade that part of the design in isolation. It may also cost less.

True, though that won't help us with Pandora 1 now ;)

Do you actually have numbers on volume for any Chinese tablet? Given the huge variety sold isn't it hard to believe that there are runs in the millions or even hundreds of thousands? You say it often but I really don't see evidence that going from Pandora volume to 10x that needs to increases costs by 10x, distributor component pricing never follows a curve anywhere this drastic..

Well, most distributors have a MOQ of 500 - 1000 if you want to order them for your shop.


Given the price and the number of people who are living in China, I bet they probably produce at least 100,000 of these.


Most of these tablets are aimed at the Chinese market.
 
OK thanks ED and WizStan, I understand better now. Sorry to derail the thread a bit there.
 
Back
Top