Announcement

Collapse
No announcement yet.

GCW Zero: Another Linux Game Console Attempt

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • zear
    replied
    Originally posted by crazycheese View Post
    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

    Leave a comment:


  • crazycheese
    replied
    Originally posted by mthuurne View Post
    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.

    Leave a comment:


  • AJSB
    replied
    Originally posted by zear View Post
    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

    Leave a comment:


  • mthuurne
    replied
    Originally posted by plonoma View Post
    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.

    Leave a comment:


  • mthuurne
    replied
    Originally posted by crazycheese View Post
    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.

    Originally posted by crazycheese View Post
    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.

    Originally posted by crazycheese View Post
    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.

    Originally posted by crazycheese View Post
    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

    Leave a comment:


  • mthuurne
    replied
    Originally posted by sandy8925 View Post
    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.

    Originally posted by sandy8925 View Post
    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.

    Leave a comment:


  • plonoma
    replied
    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.

    Leave a comment:


  • crazycheese
    replied
    Originally posted by TAXI View Post
    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.
    Last edited by crazycheese; 14 January 2013, 12:42 PM.

    Leave a comment:


  • V10lator
    replied
    Originally posted by sandy8925 View Post
    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?
    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.

    The Wi-Fi module itself uses binary firmware, but the driver that runs on the MIPS CPU is open source. Every other driver we are using is fully open source and that source will be published on github as soon as the first unit?s ship.

    Leave a comment:


  • mum1989
    replied
    Originally posted by sandy8925 View Post
    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.

    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?
    Some anwers on thier website :
    Why did you choose a 3.5″ LCD over 5″ LCD any why a resolution of 320x240?

    A bigger screen on the GCW Zero = less battery life / more work on the
    CPU / less fps in emulation / blurry, rescaled graphics and a higher
    manufacturing cost...

    The reason behind choosing a 320x240 display isn't just monetary. Of
    course, a larger display would have raised the final price of the
    device, but it also has many other cons for a device aimed at retro
    gaming. First of all, a higher resolution is not needed because most
    retro games we support run at 320x240 at most. A larger screen would
    require everything to be rescaled, so the CPU would have an extra load
    of work and this would result in worse gaming performance and less
    battery life.
    Why did you choose mini-USB over micro-USB?

    Mini-USB allows you to plug extra peripherals much better than
    micro-USB. With micro-USB, we were afraid that the port would not
    survive a heavy weight attached to it.

    GCW Zero was designed so you can attach extra peripherals such as game
    controllers or keyboard/mouse combo of your choice and use them
    together with HDMI/analog video out.

    Here is an example in this link with a USB Bluetooth dongle:

    Leave a comment:

Working...
X