Distant-Earth

The web log of a meandering nobody…
RSS icon Email icon Home icon
  • ScummVM: 1.0.0 “Shiny Logo” released for the GP2X and GP2XWiz

    Posted on November 16th, 2009 DJWillis No comments

    This is just a quick post is to announce the 1.0.0 releases of the ScummVM for both the GP2X and the GP2X Wiz following on from the official announcement.

    Please provide feedback on these releases and enjoy using them, this is a huge milestone for the ScummVM project and we are all very proud of this release.

    New features since the 1.0.0 RC1 for my backends:

    Below are the main features and fixes added with this new release from the earlier RC1 release.

    Both releases feature additional ARM assembly optimised routines and tweaks to the build system along with a myriad of small ‘nips and tucks’.

    There are also further tweaks to refine the use of the “Return to Launcher” and “Global Main Menu” features (remember that Left Trigger and Select/Home/Menu will bring up the Global Main Menu in any game).

    This is in addition to the hundreds (litterally) of bug fixes that have gone into the core and game engines for this release from the ScummVM development team.

    Supported engines:

    Both releases feature support for all the game engines that are due to be included with the 1.0.0 release.

    This includes support for high resolution games.

    Specific restrictions:

    Each of the releases has a small number of restrictions that have an affect on the games/engines you are able to use with each platform.

    GP2X: The biggest restriction with this platform is the overhead of the scaling when using 640*480 games on the 320*240 screen making such game perform poorly.

    GP2X Wiz:  The downscaling support is a recently added feature to the Wiz backend and as such some issues still remain with high resolution games exhibiting ‘tearing’ when updating the screen under some circumstances. Unfortunately this seems to be an exhibit of the Wiz screen tearing bug and while efforts have been taken to minimise it in this release it the problem has not totally gone away.

    Providing feedback:

    If you would like me to consider a feature or fix a bug help me to help you by ensuring the reports end up recorded in official places.

    Downloads:

    Regards,

    John

  • ScummVM: 1.0.0 “Preview 2” for the GP2X and GP2X Wiz.

    Posted on August 9th, 2009 DJWillis 2 comments

    This is just a quick post is to announce the “preview 2” test releases of the upcoming ScummVM 1.0.0 for both the GP2X and the GP2X Wiz.

    Note: Please don’t mirror or hotlink preview/test/alpha etc. releases or put them on download services but rather, direct people to this page. This helps me ensure that users always have the most recent versions.

    Please test and provide feedback on these releases as they will form the basis of the official 1.0.0 release candidate release for these platforms.

    New features since preview 1:

    Below are the main features and fixes added with this new release.

    Both releases feature additional ARM assembly optimised routines that offer performance increases in a number of games including “Sam and Max” and “The Curse of Monkey Island”. Both releases also feature tweaks to the default volume levels to cut down on sample clipping.

    There are also tweaks to refine the use of the “Return to Launcher” and “Global Main Menu” features (remember that Left Trigger and Select/Home/Menu will bring up the Global Main Menu in any game).

    GP2X: Lots of code cleanup and a few tweaks to lower memory usage. Disabling “Aspect Ratio Correction” now also works as expected rather then stretching the screen.

    GP2X Wiz: The biggest new feature is the addition of downscaling support using an optimised ARM assembly routine. This means the Wiz release now features support for the 64*4xx games such as Discworld 2, The Curse of Monkey Island etc. – It should also be mentioned that this seems to work well (better then I expected as I am not a fan of downscaling). Lots of my testers reported that the high resolution games are often extremely playable and look very nice on the Wiz’s OLED screen.

    There has also been substantial code clean up and fixes since the preview 1 release.

    Supported engines:

    Both releases feature support for all the game engines that are due to be included with the 1.0.0 release.

    This includes support for high resolution games.

    Specific restrictions:

    Each of the releases has a small number of restrictions that have an affect on the games/engines you are able to use with each platform.

    GP2X: The biggest restriction with this platform is the overhead of the scaling when using 640*480 games on the 320*240 screen making such game perform poorly.

    GP2X Wiz:  The downscaling support is a new feature to the Wiz backend and as such issues may still remain with some high resolution games. I have already spotted a minor issue where the screen is not totally cleaned when some types of screen movement occur.

    Providing feedback:

    If you would like me to consider a feature or fix a bug help me to help you by ensuring the reports end up recorded in official places.

    Note: Feature Requests for 1.0.0 are closed but any requests will be looked at for future releases.

    Downloads:

    Please ensure you download the correct version for your device.

    Extract the contents of the zip to a suitable folder on your SD card and launch “scummvm.gpe” to run.

    Review the README-GP2X for more information.

    Extract the contents of the zip to the game folder on your SD card, ensuring that you have a “scummvm.ini” in your game folder and the rest of ScummVM in a “scummvm” subfolder. Launch “ScummVM” from the main SD launcher menu to run.

    Review the README-GP2XWIZ for more information.

    Regards,

    John

  • ScummVM: 1.0.0 “Preview 1” for the GP2X and GP2X Wiz.

    Posted on July 27th, 2009 DJWillis No comments

    NOTE: This post is now out of date, please see the most recent posts for more info.

    This is just a quick post is to announce the “preview 1” test releases of the upcoming ScummVM 1.0.0 for both the GP2X and the GP2X Wiz.

    Note: Please don’t mirror preview/test/alpha etc. releases or put them on download services but rather, direct people to this page. This helps me ensure that users always have the most recent versions.

    Please test and provide feedback on these releases as they will form the basis of the official 1.0.0 release for these platforms.

    New features:

    Both the GP2X and the GP2X Wiz backends benefit from some long overdue code cleanup and general TLC in this release. Where possible both backends are using common/similar code to aid in there long term maintenance.

    Both releases also now feature support for the ScummVM virtual keyboard. This can be accessed by holding the left trigger and pressing the right trigger (the old ‘0’ for Monkey Island 2 copy protection key combination).

    The ScummVM virtual keyboard works well but it’s feature set is still maturing. If you have virtual keyboard specific feedback I would welcome that. It should be noted that the virtual keyboard works independently of the game engine and the running game is paused when it is in use.

    GP2X Wiz: If you have used the early alpha releases for the GP2X Wiz then you will be pleasantly surprised, all the known issues with saving, OGG Vorbis playback and volume control have been resolved along with loads of other minor fixes.

    Supported engines:

    Both releases feature support for all the game engines that are due to be included with the 1.0.0 release.

    Specific restrictions:

    Each of the releases has a small number of restrictions that have an affect on the games/engines you are able to use with each platform.

    GP2X: The biggest restriction with this platform is pure performance (some audio can be choppy) and the overhead of the scaling code when using 640*480 games on the 320*240 screen.

    This renders high resolution games such as Discworld 2 totally unusable on the device and games such as Curse of Monkey Island, Touché and the Broken Sword games very slow (to the point of unplayable IMHO but others disagree).

    GP2X Wiz: Whilst the Wiz is a more powerful console then the GP2X on paper there are still a number of features lacking compared to it’s older sibling. The most noteworthy is the complete lack of any down-scaling support in this release.

    This means that any games that have graphics higher then > 320*240 will fail to function on this release. Most/all 320*240 or lower resolution games run very well at full or near full speed on the device.

    Providing feedback:

    If you would like me to consider a feature or fix a bug help me to help you by ensuring the reports end up recorded in official places.

    Note: Feature Requests for 1.0.0 are closed but any requests will be looked at for future releases.

    Downloads:

    Please ensure you download the correct version for your device.

    Extract the contents of the zip to a suitable folder on your SD card and launch “scummvm.gpe” to run.

    Review the README-GP2X for more information.

    Extract the contents of the zip to the game folder on your SD card, ensuring that you have a “scummvm.ini” in your game folder and the rest of ScummVM in a “scummvm” subfolder. Launch “ScummVM” from the main SD launcher menu to run.

    Review the README-GP2XWIZ for more information.

  • ScummVM: A quick and dirty alpha release for the GP2X Wiz.

    Posted on June 1st, 2009 DJWillis 4 comments

    NOTE: This post is now out of date, please see the most recent posts for more info.

    As some people know I have been hacking around with the Wiz on and off for some time now (in addition to the Pandora) and while I got ScummVM running on the Wiz quite some time ago I have been holding off on a release so that I could get a little more time to fix issues with the Wiz backend.

    Well time has been rather cruel of late and I have not had as much time as I would like to clean up things and add funky features so rather then leave a half completed ScummVM backend languishing on my hard disk and rotting I decided to find a few hours to trim down the code, bring it up to date and put aside all the non working bits for now (mostly scaling support, OpenGLes parts, better controls, that sort of stuff) and get a ‘raw and ready’ ScummVM release out so people can start to give me feedback etc.

    This release is mostly untested and is built from mainline (HEAD) ScummVM revision 41101. Expect odd issues and things not to quite be working correctly yet. If your not happy with the odd crash and bit of unexpected behavior then this build is not for you.

    Anyway, onto what you get in this release and what you need to do to get it running.

    You can download the release here – Don’t forget to check the README-GP2XWIZ text file in the zip.

    As this is an early alpha release and is likely to get superseded quickly I would appreciate it if you did not mirror the download but rather pointed users back to this page.

    Once you have downloaded the release you need to extract the contents of the zip to the ‘game’ folder on your SD card. Once extracted you should have a ‘scummvm.ini’ file in the game folder and a separate ‘scummvm’ folder with all the actual files needed by the Wiz.

    Pop the SD card into your Wiz and select ScummVM from the SD games menu. If all goes well after a few seconds you should be greeted with the ScummVM game launcher. From this point it behaves very much like any other ScummVM release.

    Controls are very similar to the GP2X F200 release (including touchscreen support) with a few notable exceptions. Menu now brings up the game menu and Left trigger + Menu now brings up the global main menu for ScummVM.

    Other then that things pretty much match the layout of the GP2X F200 release. If you want to refresh yourself of the control mappings I have included full details in the README-GP2XWIZ text file in the zip.

    Known Issues:

    • No scaling support so only 320*xxx games run. Games that need a bigger screen then the Wiz will just crash ScummVM. Scaling support is on the TODO.
    • Save support may be erratic. Not quite sure of the cause yet but some of my testers had the odd issues with saves not writing correctly.
    • Speed. For most games speed is quite good but I have noticed a few points when performance really gets bad. Still looking into that.
    • OGG Vorbis support: One tester mentioned that games he used that had OGG Vorbis audio did not work. Still looking into that.

    Feedback on this release:

    The feedback avenues for the Wiz release are the same as the existing GP2X release.

    In order to help me keep track of requests, bugs etc. I am asking that people kindly report such issues to the correct places (or at least copy them there). I don’t spend all my time looking at forums and bug reports placed on random internet forums are never very helpful to me (i.e. they are very unlikely to get fixed or even read). The same applies to feature requests etc. etc.
    If you would like me to consider a feature or fix a bug help me to help you by ensuring the reports end up recorded in official places.

    Source Code:

    Source for this release will be up on a ScummVM patch tracker in the next few days (or, if the team view it as good enough, hopefully committed to SVN).

  • Hacking around with the Leapfrog Didj

    Posted on May 13th, 2009 DJWillis 1 comment

    In October of last year Leapfrog released a little gaming handheld called the Leapfrog Digi.

    On the surface this device is totally unremarkable (apart from the fact that Leapfrog have spent some serious money for software licenses including Pixar stuff and Star Wars) but once you start doing a little more research it becomes an all together more interesting little device.

    Some of the 1st things I discovered were that its ARM based (an ARM926) and that is it Linux based (with the board bring up done by Cozybit) with Leapfrogs bespoke ‘Brio’ software layer sitting on top. That was enough to get my attention and after a discussion with a fellow Didj hacker Claude Schwarz I decided that it was probably worth committing my findings so far to this blog so they don’t get lost.

    It is also fair to say that this device may be of interest to anyone hacking on the GP2X Wiz (more on that later) and with it’s very low cost (has been seen for $40) it may well appeal to a lot of the resourceful hardware hacking types I am so fond of ;-) .

    One other thing that sets this out from the crowd from a hacking perspective is availability. Leapfrog is a decent sized company and they are pretty good at getting there product out into the market (and keeping it out there) so there is a good chance this device may well out live the myriad of interesting but gone tomorrow Chinese devices. It is often much nicer to hack on something you can still buy in 3 months time.

    So here we have some of those findings.

    What are the high level specs?

    • 320*240 TFT LCD.
    • 393MHz ARM 926 CPU.
    • Partial OpenGL ES 1.1 support (told you it gets interesting).
    • Familiar DPad and button layout.
    • 2 Gigabit NAND (so 256 MegaBytes).
    • 32MB DDR Memory.
    • Custom cartridge for additional storage (no SD slot or the likes). Cartridge has UART on it and most things you may need for expansion it would seem. Still some unknown pins.

    What’s inside?

    I am not really that interested in the physical aspects of the device in this post, more the hardware aspects (what makes it tick, who made it etc.).

    Ok, so most importantly what SoC (system on chip) is used in this beast? It would seem that Leapfrog have there own unique ARM SoC called the LF-1000 used in the Didj.

    Now like most people I would not believe for a minute that Leapfrog have the resources to custom fab and design there own SoC for one device so this leads to the next question.

    Who’s existing SoC are there reusing (and rebranding?). As it happens finding this out was not very difficult at all and just took some resorting to sniffing the boot logs, checking the kernel code and a few simple tests and register pokes (if you want to know how to get a serial console out of the Didj cartridge connector check Claude Schwarz’s BLOG).

    And the SoC masquerading as the Leapfrog LF-1000 seems to be none other then a lower clocked version of the MagicEyes Pollux 3D SoC as used in the GP2X Wiz. It’s not clear right now if this is a genuinely lower clocked part that MagicEyes have made for Leapfrog or (much more likely) it is just a straight off the shelf Pollux SoC with different printing screened on.

    The chip seems to behave just as the MMSP2+/Pollux do with regards UART booting and poking appropriate registers seem to evoke the expected Pollux response.

    Where is the code?

    Leapfrog released a tarball consisting of the Linux kernel (2.6.20) used and several other supporting applications including the devices little boot loader (lightning boot) and some user space stuff and other misc code.

    Going forward this should be of great interest to any would be hackers and Claude has already brought the system up with a custom bootloader loaded over UART.

    Things to do?

    Right now, not a huge amount. It will have to drop down the pile as I want to finish off some GP2X Wiz stuff and the Pandora work is still eating a fair amount of my free time.

    Once/if that settles down I would love to start looking at what options we have to just bring up some form of simple removable storage on this thing in the form of a custom cartridge.

    I am leaning towards trying to get XD cards working as they are basically RAW NAND anyway but in a nice removable form factor so you could end up with a cartridge that converts to XD and then just use XD cards without the need to change the cart.

    If anyone is interested in the Didj or is doing anything cool with it please let me know.

    Other Didj sites (not all are that up to date):

  • A quick video demo of the Pandora using the PowerVR SGX core.

    Posted on February 15th, 2009 DJWillis 2 comments

    Whilst I have had PowerVR support working on the Pandora for some time now with the recent public release of the OMAP3 3.0.0.6 PowerVR SDK I now feel comfortable showing some demos using the 3D core.

    It is also worth mentioning that from today all the Angstrom file system images available to Pandora developers will also include the drivers for the PowerVR SGX (taken from the above SDK) so expect to see other developers pick this up and run with it (I hope). I’ll admit I am quite looking forward to people getting stuck into really giving the core and the drivers a good workout.

    As I am making this post it also seems worthwhile to give a little background on PowerVR support on the Pandora as it has frequently been a source of consternation.

    A little while ago TI released the 3.0.0.5 drivers for the OMAP3 PowerVR core and this lead to posts like this one that unfortunately created some misunderstandings.

    The 3.0.0.5 drivers TI released were basically old even at the time of release and required all manor of patching to even work on the Pandora/Beagle et al. They had been build for a 2.6.22 kernel paired with an old user space. Whilst they could be made to work on the Pandora they required dropping back to a quick port we did of TI’s 2.6.22 reference kernel and this was hardly an attractive prospect when everything else was fitting nicely with the 2.6.27 kernel we have lined up for the 1st release (don’t worry, we also keep our kernel current and stuck firmly to mainline Linux-OMAP).

    I think the confusion at the time came from the fact that 3D did work on the Pandora with our 2.6.27 kernel but required a combination of drivers that were, at the time, not distributable (even to other Pandora devs). With the 3.0.0.6 public release this all becomes a rather moot point.

    That is about all there is to it really. The PowerVR works well and we are working to sort the few remaining little snags (default clocks, wrappers etc.) in plenty of time for the release so you will be able to enjoy 3D on your freshly unpacked Pandora.

    I’ll apologize in advance for the really crappy video quality but all I can get my hands on is an old digicam that happens to also produce AVI’s ;) . I am sure Ed will produce some decent high res videos of the demos for the official page soon enough.

    Oh, and ignore the slight flicker in the bottom right, I had an optical mouse connected when I did the demo that likes to ‘twitch’.

  • ‘Mobile Broadband’ on the Pandora?

    Posted on February 12th, 2009 DJWillis 4 comments

    One of the little things I have been asked several times is can people use Mobile Broadband (GPRS/UMTS/HSDPA etc.) USB adaptors on the Pandora (in Europe we are lucky enough to have easy and fairly cheap access to cellular broadband tariffs).

    While the real answer to this is ‘most probably’ with some caveats about Linux support for your chosen adaptor, USB 2 device support etc. etc. I decided to try and get my own adaptor working on my Pandora development board and this is a post about that exercise.

    It is worth remembering that I am messing with the my own development images and this should not be considered anything ‘official’, it is just me having a hack about for the hell of it.

    What adaptor am I using?

    For this exercise I am using my Huawei E220. It has been upgraded with the 7.2Mbps firmware (version 11.117.09.04.00).

    Under Windows this will appear as a USB CDROM (well CDFS on a USB Mass Storage device for the pedantic) and then prompt you to install the included software to drive the modem side of the adaptor. It is all actually quite tidy to be honest and makes use of the device pretty painless on Windows.

    How is it connected?

    Unfortunately my USB stick is a USB 1.1 full speed (USB OHCI) device so connecting it straight to the Pandora gets us nowhere. Remember the USB host socket on the Pandora is an EHCI (i.e. USB2 high speed) host so it needs a hub inline to step down to USB 1.1 speeds.

    So out comes a USB hub and into a hub port goes the USB stick.

    What happened?

    Well, the first time I plugged it in (as you might imagine) not a lot happened other then the USB stack spitting out some info about the device and installing the mass storage side of things.

    usb 1-2.4: new full speed USB device using ehci-omap and address 7
    usb 1-2.4: configuration #1 chosen from 1 choice
    scsi4 : SCSI emulation for USB Mass Storage devices
    usb 1-2.4: New USB device found, idVendor=12d1, idProduct=1003
    usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
    usb 1-2.4: Product: HUAWEI Mobile
    usb 1-2.4: Manufacturer: HUAWEI Technologies
    usb-storage: device found at 7
    usb-storage: waiting for device to settle before scanning
    usb 1-2.4: USB disconnect, address 7
    usb 1-2.4: new full speed USB device using ehci-omap and address 8
    usb 1-2.4: configuration #1 chosen from 1 choice
    usb-storage: probe of 1-2.4:1.0 failed with error -5
    usb-storage: probe of 1-2.4:1.1 failed with error -5
    scsi7 : SCSI emulation for USB Mass Storage devices
    usb 1-2.4: New USB device found, idVendor=12d1, idProduct=1003
    usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
    usb 1-2.4: Product: HUAWEI Mobile
    usb 1-2.4: Manufacturer: HUAWEI Technologies
    usb-storage: device found at 8
    usb-storage: waiting for device to settle before scanning
    scsi 7:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
    sr0: scsi-1 drive
    sr 7:0:0:0: Attached scsi CD-ROM sr0
    sr 7:0:0:0: Attached scsi generic sg0 type 5
    usb-storage: device scan complete

    After a little bit of quick research it became obvious that the device is supported by the default usbserial.ko kernel module in 2.6.20>.
     

    Ok, a quick check of the shipped kernel modules shows that I forgot to build that into the image so off I trek back to my OpenEmbedded build system and after a quick edit to the defconfig for our kernel recipe and a bump of the kernel package revision I now have a nice usbserial.ko included in the image.

    After deploying the new image I plugged it in and things got a whole lot more interesting. A couple of /dev/ttyUSB devices had been created, just what every modem connection needs.

    usb 1-2.4: new full speed USB device using ehci-omap and address 4
    usb 1-2.4: configuration #1 chosen from 1 choice
    scsi1 : SCSI emulation for USB Mass Storage devices
    usb 1-2.4: New USB device found, idVendor=12d1, idProduct=1003
    usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
    usb 1-2.4: Product: HUAWEI Mobile
    usb 1-2.4: Manufacturer: HUAWEI Technologies
    usb-storage: device found at 4
    usb-storage: waiting for device to settle before scanning
    usb 1-2.4: USB disconnect, address 4
    usb 1-2.4: new full speed USB device using ehci-omap and address 5
    usb 1-2.4: configuration #1 chosen from 1 choice
    usb-storage: probe of 1-2.4:1.0 failed with error -5
    usb-storage: probe of 1-2.4:1.1 failed with error -5
    scsi4 : SCSI emulation for USB Mass Storage devices
    usb 1-2.4: New USB device found, idVendor=12d1, idProduct=1003
    usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
    usb 1-2.4: Product: HUAWEI Mobile
    usb 1-2.4: Manufacturer: HUAWEI Technologies
    usb-storage: device found at 5
    usb-storage: waiting for device to settle before scanning
    usbcore: registered new interface driver usbserial
    usbserial: USB Serial support registered for generic
    usbcore: registered new interface driver usbserial_generic
    usbserial: USB Serial Driver core
    usbserial: USB Serial support registered for GSM modem (1-port)
    option 1-2.4:1.0: GSM modem (1-port) converter detected
    usb 1-2.4: GSM modem (1-port) converter now attached to ttyUSB0
    option 1-2.4:1.1: GSM modem (1-port) converter detected
    usb 1-2.4: GSM modem (1-port) converter now attached to ttyUSB1
    usbcore: registered new interface driver option
    option: USB Driver for GSM modems: v0.7.2
    scsi 4:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
    scsi 4:0:0:0: Attached scsi generic sg1 type 5
    usb-storage: device scan complete
    Driver 'sr' needs updating - please use bus_type methods
    sr0: scsi-1 drive
    Uniform CD-ROM driver Revision: 3.20
    sr 4:0:0:0: Attached scsi CD-ROM sr0
    ISO 9660 Extensions: Microsoft Joliet Level 1
    ISOFS: changing to secondary root

    ls /dev/ttyUSB*

    /dev/ttyUSB0  /dev/ttyUSB1

    The first thing that jumps out at me is why the kernel has helpfully installed the Option driver when this it not an option card ‘option: USB Driver for GSM modems: v0.7.2’. That does not look right but lets give it a try anyway.

    After a quick read it seems that if you don’t have any other USB serial devices connected the modem will be assigned to /dev/ttyUSB0 and the user interface device to /dev/ttyUSB1. So far so good.

    Now to wrap all this up and see if we can connect to the Internet.

    It is worth noting at this point that our images currently have NetworkManager 0.7.0 in them as I have been evaluating that for managing the WiFi connection (along with Connman) so my plan is to see just how good the NetworkManager integration with the underlying adaptor is using the command line tools (I do not have the nm-applet GUI working with 0.7.0 yet).

    So I booted up the resulting image on the Pandora, plugged the USB stick in to the hub and waited a few seconds for that to settle and get connected then started to setup the connection.

    netm-cli -l
    GSM Devices:
    ttyUSB0:
            Udi: /org/freedesktop/Hal/devices/usb_device_12d1_1003_noserial_if0_serial_usb_0
            Driver: option
            Capabilities:
                    - Supported
            State: Disconnected
            Managed: True
            IP config:
                    No IP settings found

    Excellent, ok, NetworkManager sees that we have a ttyUSB0 GSM device. Now lets try connecting to the internet with it using my Vodafone SIM.

    netm-cli --connect --gsm=ttyUSB0 --user=web --passwd=web --apn=internet --number=*99#
    Device ttyUSB0: activating the connection
    Device ttyUSB0: created connection '/org/freedesktop/NetworkManager/ActiveConnection/1'
    /org/freedesktop/NetworkManager - State: Connecting
    Device ttyUSB0: state - Prepare
    Device ttyUSB0: state - Config
    Device ttyUSB0: state - Need Auth
    Device ttyUSB0: state - IP Config
    /org/freedesktop/NetworkManager - State: Connected
    Device ttyUSB0: state - Activated
    /org/freedesktop/NetworkManager/ActiveConnection/1 - State: Activated

    Wonderful, NetworkManager has talked to the modem and negotiated a connection to the internet.

    Sparking up a Firefox session on the Pandora proves this and shows that it is working just fine. FTP and all the usual IP services are all working as expected. The connection has been up for a good few hours now and seems very stable.

    So, what does this all prove. Well Mobile Broadband sticks (at least the Huawei E220) will work on the Pandora, NetworkManager is happy to configure the connection and as soon as I can get the NetworkManager 0.7.0 GUI going this whole process should be ‘plug and play’ just like it is on other major distributions like Ubuntu.

    I am not 100% sure at this stage about choosing NetworkManager or Connman for the final images (it is rather dependent on some tweaks that need doing to our TI1251 Wireless driver to properly support Linux Wireless Extensions and further stability/signal tests) but either way NetworkManager will be available in the Pandora repositories and, as proven here, provides a perfectly viable and quick way to connect to Mobile Broadband if you have supported hardware.

    John

  • Unpacking the GP2X Wiz

    Posted on February 4th, 2009 DJWillis 2 comments

    I was recently fortunate enough to be sent a ‘near release’ prototype of the new GamePark Holdings (GPH) portable games console, the GP2X Wiz. Considering that, it only seems fitting to put together a quick post with some random observations and pictures.

    Remember that these observations are not based on a long period of testing so come with the caveat that my opinions may change!

    Now, obviously this is the successor to the GP2X (and spiritually the GP32).

    What is interesting from my point of view is the direction GPH have taken the Wiz.

    First thing you note is that it’s a tiny little console (only a little bigger then a GameBoy Micro). It’s small. Not really small but somehow much smaller then I was expecting.

    Secondly, GPH seem to be betting a lot of making the device accessible to Flash developers (this really does feel like it is the focus for the device as the front end ‘launcher’ is flash based). This is quite a marked departure from the GP2X and feels more like a step into the casual game market that is often dominated by mobile phones. I guess this change makes sense for their Korean markets.

    Time will tell what effect this has on the wider markets and the adoption of Flash on the device. I suspect very little to start with as a lot of GP2X devs will no doubt get a Wiz and treat it as a logical extension of what they have done there and start hacking the hardware and giving flash little more then a glance ;) . Given time however Flash could lower the entry level for apps and open the door to creative non-coders and that can only be a good thing for homebrew.

    Anyway, onto some hardware information.

    The GP2X Wiz is based on the MagicEyes Pollux SoC clocked at 533MHz and powered along by its ARMv5 ARM926EJ core. Paired with that you have the usual large page NAND, 64MB of RAM, touch screen and an SDHC slot for storage. Oh, and finally a decent fitted lithium-ion battery (that proudly tells you not to let Children and Pets chew or lick it as it may be a health risk).

    I was initially a little surprised that GPH did not opt for the MagicEyes MMSP2+ SoC in the Wiz (the GP2X used the older MMSP2 SoC) as moving to the VRender range means you loose some very handy features (The ARM94* 2nd core, the basic 2D engine, RGB scalar etc.) but on the flip side you do get an OpenGL ES 1.1 3D core. Unfortunately, as it stands, no one has got the said 3D core doing much yet (but I know Pickle was doing a little investigation work). As there are only a few dozen of these devices out and about in hackers hands that is no surprise. It is something I want to dabble with time permitting :) .

    One interesting thing I want to test sometime is to discover if the Pollux used in the Wiz suffers the same issues with strangled RAM bandwidth that the MMSP2+ suffers with. When I get time I will try the apps I built to test RAM bandwidth on the MMSP2+. If the Pollux is as bad as the MMSP2+ when it comes to RAM bandwidth that could be a bit of a snag.

    The form factor.

    It’s really shiny. To say the plastic used smudges easily is a massive understatement :D . That said it feels well made and fairly solid to hold with no flex (a pleasant continuation of the GP2X F200 level of build quality rather than a slide back to the dire quality of the 1st GP2X’s). It even has a slot for the stylus now, something the F200 GP2X did not manage.

    The control layout is not quite to my tastes (big hands so it can tend to feel a little cramped). Buttons seem responsive and have a fairly positive feeling. The dPad is not as bad as all that but I have not really tried it in games yet. Not sure I am a convert to the ‘split dPad’ button layout for the right hand side mind you. This also raises the point that the L and R triggers are inset from the edges of the unit. That feels a little odd but you get used to it I guess. All in all, the controls are not great but not bad. They do the job.

    The screen (when it is not suffering something like a vsync tear) is very nice. Its OLED technology and is nice and bright. Assuming the screen setup issues are software its a classy screen despite the low (comparatively) resolution of 320*240.

    Something else that jumped out at me was the interesting choice GPH has made by deciding to move everything other than the headphones to the EXT port on the bottom. This includes things like the USB (device and host), TV out and charging. You won’t be connecting your Wiz to a PC directly without some additional fly leads due to the lack of a USB device port on the unit.

    I suspect GPH plans to ship (as an extra or included, not sure) a dock or clip-on unit that provides at least USB and TV out and maybe WiFi if the picture below is accurate.

    The software platform.

    The 1st thing that greats you is the Flash menu GPH have developed for the unit.

    Not a lot to say about it really. It feels like a sloppier version of the menu used on the GP2X. I hope this is down to the unit being pre-release but the menu crashes regularly and does a generally poor job of being a menu. Another aspect of the pre-release software is the lack of a lot else on the unit (that reliably works) so there is not a lot of software to talk about.

    It is Linux 2.6 based but I have yet to get hold of the source to have a look at how clean the MagicEyes/GPH changes are. Looking at the file system and kernel it seems safe to assume that AESOP Embedded did the kernel porting work like they have done for other MagicEyes chips.

    It seems to ship with a decent set of libraries and SDL. It is not clear if the stock SDL features some basic hardware acceleration.

    I’ll update this and add more pictures when there is final software available as it is more then a little unfair to draw real conclusions from early code such as this

    So what do I plan to do with it?

    Not a lot right now (for at least the next few days) as I have some other projects to clear off my plate but once they are out of the way the 1st thing I want to do is clean up my basic ScummVM port then look at what is needed to add the Wiz as a supported machine to OpenEmbedded and look at what funky stuff can be done towards supporting stuff like kexecboot and a full Ångström distribution ;) .

    What about the Pandora?

    Well it’s no secret that I look after the Ångström based operating system for the Pandora (among other things) and I guess that could represent a conflict of interests (yeah, right) but I would draw your attention to one little fact. I am a geek who likes to mess around with electronics :) . The more the merrier. I could not give a stuff about ‘community politics’. I just simply look at something and ask myself ‘does that look interesting’ and ‘will I mess about with it’.

    Having now had a little time to mess about with the Wiz it is obvious to me that I will be doing some hacking about with it and I can’t really see how it and the Pandora are in any way directly ‘competing’. Different design goals, different software goals, different platforms and different price points ;) . Both look like decent hacking platforms in there own way. When they are out, and if you can afford it, get both or just ask yourself what you want to do with it and ignore anyone who sounds rather too devout about one platform or the other.

    The Wiz with some other consoles to get an idea of size.

  • OpenPandora, OpenEmbedded and Ångström

    Posted on January 9th, 2009 DJWillis No comments

    One of the things I have been asked a few times is what the relationship is between OpenEmbedded, Ångström and the Pandora.

    It really is quite simple ;-) . To quote Wikipedia “The OpenEmbedded Project (OE for short) is a software framework to create Linux distributions aimed for embedded devices”.

    Ångström is a distribution that builds upon OpenEmebdded to collect everything needed for a feature rich Linux kernel based operating system.

    We use Ångström as a base to then build the operating system images for the Pandora. There are a number of reasons behind this but some of the top ones include OpenEmbedded’s extreme flexibility, Ångström’s sensible approach to configuration and the ability for us to get fine grain optimisation into the images (packages on the Pandora are ARMv7 where possible and many include patches for Cortex A8 features like the NEON or OMAP specific optimisations).

    OpenEmbedded’s overlay approach to the way it handles metadata also allows us a great deal of freedom to tailor the Pandora distribution without compromising the main Ångström/OpenEmebdded metadata removing any need for silly things like forks or additional OpenEmebdded distributions.

    When I talk about Ångström on the Pandora I really am talking about the mainline Ångström and not some nasty Pandora specific fork. If we add new features to Ångström our aim is to push them upstream in a sensible way quickly and only provide our overlay with the minimal amount of transitional stuff or things that would never be acceptable in mainline.

    Anyway, on the back of all this I recently made a long overdue hello to the Ångström developers mailing list to try and garner some interest and support. If your interested in reading that you can find the mails in the Ångström developers mail archive here.

  • ScummVM: 0.12.0 "Preview 2" released.

    Posted on October 20th, 2008 DJWillis No comments

    All,
    This post is to announce the preview 2 release of the upcoming 0.12.0 release for the GP2X.
    This release fully supports all GP2X’s (F100 and F200 with touchscreens).
    There are improvements to the touchscreen code in this release and improved support for USB keyboards. If all goes well this will be largely unchanged for the official release.
    You can download the release here .
    The official forum is here.
    This should support all new games added in the 0.12.0 release cycle. These new games are largely untested on the GP2X so feedback about them is especially important.
    All being well this is pretty much what will end up as the official 0.12.0 release apart from USB keyboard and improved touchscreen support to be added in later previews.
    How to provide feedback?
    In order to help me keep track of requests, bugs etc. I am asking that people kindly report such issues to the correct places (or at least copy them there). I don’t spend all my time looking at forums and bug reports placed on random internet forums are never very helpful to me (i.e. they are very unlikely to get fixed). The same applies to feature requests etc. etc.
    If you would like me to consider a feature or fix a bug help me to help you by ensuring the reports end up recorded in the one official place.