GCW Zero: Another Linux Game Console Attempt

[crazycheese]

Is also answered:

Another thing that we are still working on is the OpenGL driver. Unfortunately, we will not be able to release this as open source. People who only want a fully open source system can simply leave out the OpenGL driver though; the 2D graphics system (Linux framebuffer) works fine without it.

This is ultra-stupid.
Its like saying "opensource console", yet its GFX system is proprietary and even wifi hardware needs a blobby driver.
You could find a blob-free hardware.
And what the problem with MESA?

So now, by supporting the project, people will pay for closed source blob to wifi provider and to your closed source opengl provider/license issuer.
Which is basically supporting closed source companies.

By the way you were running closed-source games (no problem here, but you false advertised - "opensource games")

Corrected this for developer:
People who only want a fully open source system can simply leave out the project.

With such attitude, its no different than Android projects and this will shift into fight with them. You killed one part of uniquess, compact size is still here.

[plonoma]

I'm hoping for a game console that doesn't try to do special software.
It breaks compatibility and often is detrimental to the experience anyway.
(If you want to have a custom GUI it's better to be using a default desktop environment and develop a theme for that.)

I want software with as little modifications from upstream as possible. GCW Zero developers. Please work with upstream, when done right it's more efficient and allows the maintenance of everything to be shared along you and upstream.

The 320x240 resolution of the display is on the low side, even for a console like this.

[mthuurne]

I have the same question that most other people here have - why limit resolution to 320x240? 640x480 or 800x600 would be much better. Also, is there any USB port or bluetooth, so a keyboard, mouse or joystick might be used with the device? 256 MB RAM is also quite limiting, atleast 512 MB would be better.

320x240 is a good fit for retro gaming. Of course 640x480 would be good too since even if the application outputs 320x240 you can just scale up the image, but that would have made the unit more expensive.

The USB port supports USB OTG, so it should be possible to attach USB input devices via a USB hub. We don't have support for this in the kernel yet though, so I cannot say how well it works.

Since we run a pretty light embedded Linux, 256 MB total memory means about 240 MB available for applications. I haven't seen any application get near that kind of memory use; I think we could run everything in 64 MB if we had to. Most of the memory is used for caching data from the SD because it is not in use by anything else.

Regarding the software, how many of the drivers are open source? Are you planning to use the recently announced etnaviv open source driver, or a proprietary driver for the Vivante GPU?

Everything in our current kernel is open source; you can find the source at github: https://github.com/gcwnow/linux. The current kernel doesn't do GL ES yet, only framebuffer graphics, which is handled by just the LCD controller and doesn't use the GPU.

As for the GPU, for the short term we're trying to get the proprietary driver working. We prefer open source for everything though, so for the long term we're certainly going to look at etnaviv.

Another piece that we don't have source code for is the WiFi firmware that runs on the WiFi module itself (this is an internal USB device). This firmware does not run on the MIPS CPU and does not have access to main memory, so in my opinion it doesn't matter that it's not open source, but some people have stricter demands than I do so I thought I should mention it.

[mthuurne]

This is ultra-stupid.
Its like saying "opensource console", yet its GFX system is proprietary and even wifi hardware needs a blobby driver.
You could find a blob-free hardware.
And what the problem with MESA?

About WiFi: the part that runs in the kernel is open source, it's only the part that runs on the WiFi module's microcontroller that is a blob.

The console is perfectly usable without any blobs in the kernel, but it won't have accelerated rendering then (and no WiFi if you consider uploaded firmware blobs taboo). Since 320x240 is not that many pixels, software rendering will go a long way, so most applications will run smoothly even without hardware accelerated rendering.

So now, by supporting the project, people will pay for closed source blob to wifi provider and to your closed source opengl provider/license issuer.
Which is basically supporting closed source companies.

We don't pay specifically for the blobs, they are included in the cost of the hardware. In the case of embedded graphics, I'm not aware of any company that offers open source drivers for their GPU. In the case of WiFi, there might be some that are fully open, but by far the most common arrangement is an open driver with a blob running on the WiFi card itself. As I said before all the WiFi code that runs as part of the kernel is already open, which is the most important aspect: no mystery blobs that could cause instability, nothing to prevent us from upgrading our kernel even if the internal kernel interfaces change.

By the way you were running closed-source games (no problem here, but you false advertised - "opensource games")

Yes, this was a mistake in the script for the video. We corrected it in the FAQ on Kickstarter.

Corrected this for developer:
People who only want a fully open source system can simply leave out the project.

With such attitude, its no different than Android projects and this will shift into fight with them. You killed one part of uniquess, compact size is still here.

I too would love to see a mobile system with fully open source GPU drivers, but if we want to deliver that, we'd either have to design our own hardware or wait with releasing the console until we have fully reverse engineered the GPU. I think the former is not realistic and the latter is not an improvement over our current plan.

What I wanted to express with the original "People who only want a fully open source system can simply leave out the OpenGL driver though" line is that the console is not crippled without the GPU driver; in fact every GCW Zero video you can find on YouTube was done without using the GPU. A certain popular embedded Linux board won't even boot without the proprietary GPU driver

[mthuurne]

I want software with as little modifications from upstream as possible. GCW Zero developers. Please work with upstream, when done right it's more efficient and allows the maintenance of everything to be shared along you and upstream.

This is one of our goals: to use standard interfaces and stay close to upstream.

Our preferred way for applications to interact with the hardware is through SDL, which is highly portable. We already submitted a few patches to SDL, for example to fix wait-for-vsync and an option to not wipe the framebuffer when an application exits (so our loading screen remains visible until the application takes over).

On the kernel side, I'm removing a lot of the custom interfaces that Ingenic used in their kernel, to replace them with standard Linux interfaces. Also, in the drivers we try to use generic in-kernel mechanisms as much as possible, for example we use the generic gpio-keys driver and the new generic pwm framework.

As I wrote in the original mail to Michael, we keep up with upstream releases, which is unfortunately rare in the embedded world. This allows us to reduce the amount of customizations we need, when upstream accepts either our patches or other people's solutions to the same problem.

[AJSB]

So you are asking whether it will be possible to compile natively on the device instead of resorting to cross-compilation from x86 Linux?
We have not thought of it. The device has no keyboard, so coding on it is a bit pointless. On the other hand, you could always plug it into the tv and connect a keyboard via usb-otg. Or you could just log into the device via SSH/Telnet and try to invoke the compiler. So perhaps this isn't such a stupid idea. We will think of it

Yes, my idea was precisely that, connect a keyboard to it via USB-OTG and connect console to TV....if the dev tools are buildin, then we could dev directly in the device....it will not only be a console but a full blown dev tool

[crazycheese]

About WiFi: the part that runs in the kernel is open source, it's only the part that runs on the WiFi module's microcontroller that is a blob.

The console is perfectly usable without any blobs in the kernel, but it won't have accelerated rendering then (and no WiFi if you consider uploaded firmware blobs taboo). Since 320x240 is not that many pixels, software rendering will go a long way, so most applications will run smoothly even without hardware accelerated rendering.

Thanks for the answers!
No, I do not consider firmware to be taboo, except this firmware takes on more functions than firmware should do.
I bet WiFi needs government approved backdoors.

Shame about GPU :/

Sorry, didn't mean to scare you off guys... Btw, regarding Commander Keen. Its source code has been lost. Yeah, proprietary as usual.

[zear]

Thanks for the answers!
Btw, regarding Commander Keen. Its source code has been lost. Yeah, proprietary as usual.

For Commander Keen we are using an engine reimplementation called Commander Genius. So CK in the video is running natively.
Unfortunatelly the person shooting the video messed with the settings and triggered a glitch where a 320x240 output would be software-"stretched" to a smaller window, which resulted in high frame drop. So you will have to believe me that in reality Commander Genius on GCW Zero runs on full 60fps on 320x240

[log0]

I dunno, but 320x240 is bit too retro for my liking.

Why should one prefer it over an android phone + gamepad for example? How much more expensive would at least a 640x480 screen be? Why packing a GLES2 GPU and 512MB RAM into it, if price and battery life are such an issue?

Sorry if I sound too negative. I am sure it will find its buyers.

[zear]

Why packing a GLES2 GPU and 512MB RAM into it, if price and battery life are such an issue?

The GPU is part of the jz4770 SoC we are using. We had a 256 -> 512MB RAM upgrade mainly because that was largely requested by people ever since our KS project starter. Personally I think 256MB RAM is enough, but I guess it's the today world where bigger numbers == more sales.

Why should one prefer it over an android phone + gamepad for example?

This is solely a personal preference, so I won't comment on that.