GP2X Wiz

I suffer from a weakness for handheld videogame consoles. I’ve got most of the iterations of the Game Boy, the three iterations of the DS, all but one of Game Park’s GPxx series and a variety of other handhelds, from Game & Watches to the Atari Lynx. From the GBA onwards, I’ve mainly been buying these things to run homebrew on them. Two consoles released recently, the GP2X Wiz and the Dingoo A320, have homebrew as their focus and I found that I simply couldn’t resist the urge to buy them. I’ll discuss the Dingoo in another post, whilst the Wiz is reviewed below.

First of all, some history. The Wiz is the successor to Game Park Holding’s GP2X, which was itself the successor to the GP32. Whilst the GP32 was designed to be a platform for commercial games, albeit wacky Korean commercial games, it quickly found a niche as the homebrewer’s console of choice. This can primarily be attributed to its use of SMC memory cards as its storage media and its freely available SDK. Its successor was the GP2X, which was created by a splinter group from the original company. They realised that the homebrew aspect of the original console made it much more popular than the ropey commercial offerings ever did. (Meanwhile, the original company followed the commercial route and quickly went bust without releasing any new hardware.) The GP2X was faster than the GP32, used Linux as its operating system, had more memory, more buttons, and used SD cards instead of SMC.

Both consoles had advantages over their mainstream rivals. Both had relatively large screens, were easy for homebrewers to develop for, and used cheap, generic memory cards for storage. Most importantly, amateur developers did not have to contend with a constant stream of firmware updates designed to stop them enjoying themselves. This freedom resulted in the phenomenal amount of homebrew available for both systems, including a number of superb emulators. The GP2X even did a credible impersonation of an Amiga 500.

That is not to say that the consoles were perfect, however - far from it. The GP32 shipped in at least 4 versions, each of which was designed to make the screen slightly less invisible than the last. Subsequent versions were improvements, but the first hardware iteration had an unlit screen and was unusable in most lighting conditions. All of the GP32 models featured a ridiculous, tiny joystick instead of a d-pad, cunningly designed to make it difficult to activate diagonals, making entire genres of games utterly unplayable.

The GP2X also came in multiple models, each featuring its own unique set of problems. The original model, the “F100 First Edition”, featured a joystick that managed to be even less useful than the GP32’s - GPH outdid themselves by using a cheap joystick mounted the wrong way around, and produced a stick that could hit diagonals but none of the other directions, making virtually all genres of games unplayable. At the time, many people wondered if the problem could be fixed in firmware, but if the hardware is broken, software can’t really help. The second version crippled the USB hardware making it impossible to debug from the system itself. The final version, the “F200”, finally replaced the joystick with a d-pad, but it had such a bizarre, outsized design that using it quickly led to blistered thumbs. It also featured a touch screen, which I have discussed before. In brief, it was so twitchy, inaccurate and unreliable that I gave up on the idea of a Woopsi port pretty much as soon as I got a test version to compile.

This brings us, in a roundabout way, to the GP2X Wiz, which is the latest in the line. The Wiz is essentially the GBA Micro of the GP2X world, but with added improvements. GPH have slimmed down the hardware (it’s now slightly smaller than a closed DS Lite) but bumped the specs. They’ve replaced the two 200MHz ARM CPUs with a 533MHz ARM9 with 3D hardware, replaced the USB1.1 port with USB2.0, swapped the TFT screen for AMOLED, and added an excellent built-in battery instead of space for two AAs. Amazingly for a GPH device, it features a d-pad that actually works, and I can play Street Fighter 2 and Thunderforce 4 without wanting to throw the console across the room. It feels sturdy and well-made, and boots a good deal faster than the GP2X ever did.

In fact, the only downside to the hardware thus far is the screen. It is a touch screen, but it suffers from the same problems as the GP2X F200 - the values reported by the touch screen bear only passing resemblance to the actual location of the stylus, and each subsequent poll will return entirely different values regardless of whether or not the stylus has moved. Even worse, GPH have managed to add a deadzone to the screen, either by using even cheaper components or by fitting the screen improperly and squashing the edges. The deadzone seems to vary in size amongst Wiz consoles. Unfortunately, this means there is absolutely no point whatsoever in porting Woopsi to the Wiz.

To make matters worse, GPH have used a 240x320 screen instead of a 320x240 screen. This results in the same sideways VRAM arrangement last seen in the GP32. Not too big of a problem in itself, but it is also thought to be the reason for a screen tearing effect that causes half of the screen to update before the other half. The two halves are separated by a diagonal line from the top-right corner of the screen to the bottom-left. It is not too distracting, though, and if screen tearing is the price I have to pay for a d-pad that works, I’ll gladly pay it.

Typically, GPH’s response to both of these issues is to insist that they will be fixed in new releases of the firmware, but as with the GP2X F100’s joystick, if the hardware is broken, software can’t really help.

As the Wiz has been available for less than a month, software support is lacking. Notable software currently includes a C64 emulator (Vice, seems pretty capable), a Mega Drive emulator (PicoDrive, superb) and a SNES emulator (PocketSNES, 50fps except when dealing with Mode 7). No official libraries or an SDK have yet been released, so developers are currently relying on mostly undocumented, unofficial, Linux-only toolchains designed for the GP2X.

Despite the hardware problems, the Wiz is actually a pretty good console. Its improved specs and usable d-pad represent a significant improvement over the GP2X. The new form factor makes it more portable, and it looks and feels so much more professionally made. For me, the only disappointment is the hopeless touchscreen, but to be perfectly honest I was expecting nothing more.

However, I am not sure that the Wiz will ever amass a development community as large as the GP2X’s. The lack of an SDK is a big problem at the moment (I have the OpenWiz toolchain installed in an Ubuntu VM, but a lack of documentation and libraries is preventing me from using it for anything), but the real issue is the impending release of the Pandora. Designed by people who clearly have a better grasp of videogames and homebrew than GPH, the Pandora will inevitably lure programmers away from Wiz development and reduce the amount of software that gets produced for the console.

To summarise: Pros:

  • D-pad is pretty much perfect.
  • Great battery life.
  • Good size.
  • Boots faster than the GP2X.


  • Screen tearing can be distracting.
  • Touchscreen is useless.
  • Not much software yet.
  • No official SDK yet.


Woopsi2x Abandoned

Tinkering with and researching the GP2x’s touch screen reveals some answers to the questions posed last time around.

First off, my GP2x isn’t duff. Other people have discovered the same problem as me - the only readily-available example of using the touch screen on the GP2x jitters like crazy.

I’ve tried swapping batteries, which often cause problems with the console, to no effect.

Testing the read() function reveals that the touchscreen will produce new values every time it is interrogated. There’s no need to wait for a VBL before it will produce new values. This means that my initial jitter-removal routine based on mean averages was actually doing something. I’ve increased the sample count from 5 to 40, which has improved things a lot, but it’s still nowhere near perfect.

I realised that I’ve got no idea what the “open(“dev/touchscreen/wm97xx”)” command does. Does it access the raw hardware, or does it just open a driver? Not having done any Linux kernel hacking I couldn’t say. I’ve looked through the driver sourcecode and it appears to have some jitter correction built-in. It definitely compensates for some of the quirks of the hardware. If the open() command works with the driver, there’s something seriously wrong if I’m still getting wildly different values back each time I poll the screen. If I’m working with the hardware, I’ll have to re-implement the driver for the 2x in order to get any decent values from it.

Some digging around in the code for the 2x’s port of ScummVM suggests that the author built a time delay into its touch screen routines to cater for the jitter. At least that way you’re guaranteed to get steady values for the duration of the delay. Works fine for Scumm, as it doesn’t really require fine control. No good for Woopsi - any jitter is immediately obvious. One clever idea the author had was to use the SDL_WarpMouse() command to move SDL’s cursor to match the GP2x’s stylus position. This triggers an SDL_MOUSEMOVE event, which can then be interpreted in a standard SDL event parser block without any custom code. Neat.

The official SDK has no documentation. Nothing. There doesn’t seem to be any way to get the sourcecode, either (which is rapidly becoming my favourite way to understand a program - don’t tell me how it works, just show me the code).

Coupled with the fact that the GP2x has been abandoned by the majority of coders in favour of the forthcoming “Pandora” system (which looks like a weird cross between a 48K Spectrum, a dual-shock PS1 pad, a DS and an N-Gage), I think creating a GP2x port would be a painful waste of time. Shame, because the new d-pad does actually make it quite a good system.

Here’s the touchscreen class I came up with (credit to the author of the original “touchscreen_sample.zip” file, who neglected to include his details in the zip):


I’ve switched it from using Woopsi-style “u8”, “u16”, etc types to using SDL-style “uint8_t” types. I haven’t compiled it since then, but it should be OK. Consider the archive public domain.


Increasing the number of samples to 100 further increases the accuracy, but has a noticeable impact on speed. It doesn’t solve the problem of the touch screen occasionally producing totally incorrect values. Having noticed that the amount of pressure needed to trigger a response isn’t even vaguely uniform across the surface of the touch screen, I’m growing more and more certain that GamePark skimped on the touch screen and used components that fell off the back of a lorry.



Thought I’d have a play with the GP2x development kit. 10 minutes later:


This is Woopsi, compiled using the GP2x dev kit, running in Windows using SDL. Doesn’t quite work yet as there appear to be a few incorrect constants. I need to get hold of an F-200 build of SDL as the version that comes with the dev kit I’m using doesn’t seem to include the mouse handling code.

As a proof-of-concept, though, it does the job. The GP2x loses the second screen, but the screen is 320x240 instead of the DS’ 256x192 so it really only loses half of a DS screen. Having everything on one screen is a bit of a bonus, too.


After some more minor tinkering with the SDL code:


Now that the screens are the right size and aren’t overlapping, the mouse code works in the Windows compile. I need to test the GP2x compile, but I’d need to trim the top screen off first.

I’m not sure what’s happened to the button glyphs…

This highlights a problem in the code - it makes assumptions about the size of the screens. Not particularly helpful if you want to make portable code.

In addition to this, I’ve updated the main VC++ project to match the Xcode version. All of the (very buggy, as per the last post) scroller code is in there.


Heh, simple. It’s very slow, but when you realise that the entire display is being drawn pixel by pixel to a RAM buffer, then copied pixel by pixel to the frame buffer (plus the non-existent top screen is still being rendered in RAM), you can see that there’s plenty of room for optimisation.

Oh, and the mouse code doesn’t work. Not sure if I need updated SDL libs or if I need to change the way that Woopsi interacts with the stylus on this machine.

And the glyphs are back. They’re missing from the PC version because of the unsigned/signed char problem. I should fix that.



GP2x Dev Environment Setup; Some Tunes

I thought I’d have a play with the GP2x this evening, so looked into setting up the dev environment. I’ve cloned my DS development installation of Windows into a new virtual machine, and got it set up as a GP2x dev environment. Nearly, anyway. Thanks to a pre-configured installation of Code::Blocks available on GP32x.com, getting the IDE and compiler set up was easy. However, the Windows builds of the “Hello world” test app won’t run because of missing SDL libraries (the libraries don’t exist in the standard SDL distro, so I don’t know where they should come from), and the GP2x version quits straight back to the menu, even after I coded in a button-checking while loop. I think either the dev environment is just knackered, or it’s having problems with the F200.

And now for something completely different. When I’m not tinkering with homebrew and have nothing better to do, I write the occasional tune. As I’m never going to use these for anything else, I figure I may as well upload them on here. At least I’ll have backups should my hard drive die…

This first one is a Renoise tune that I finished off today. I was browsing the web one day absently-mindedly whistling this, when I realised I’d inadvertently come up with a new melody.


Just after finishing this I found another version of the same tune, recorded back in March on the guitar. I’ve got the tab, too:

Song4_2 Song4 Tab

Here’s a snippet of something else I came up with today, that might turn into something more substantial:


Here’s another Renoise track from a while ago:


This track uses a Creative Commons sound from here, one from here, and another from here. (Hopefully that’s enough detail to comply with the licence.)


Woopsi Version 2 Ideas #3, PALib Licencing, and Woopsi Docs

More Woopsi ideas that might make it into version 2. First of all, I pre-ordered a GP2X F200 as soon as I received an email announcing it. I’m hoping that the d-pad isn’t as spectacularly unusable as the mini joystick employed on the original GP2X and the three revisions of GP32, and I’m also hoping that it won’t suffer from the quality control problems that plagued the first edition of the F100 (though mine doesn’t seem to have any of the reported issues).

Anyway, rubbish d-pad or not, I’m planning on investigating the possibility of porting Woopsi to the new GP2X. Unless GPH manage to screw up the touchscreen as badly as they screwed up the joysticks, that is - if that happens I’ll just write it off as a bad idea.

Another idea - as I’m going to have to alter all of the hardware-specific sections of Woopsi for the GP2X anyway, I might look at stripping the PALib code out at the same time. I foresee there being two major barriers to widespread adoption of Woopsi - firstly, it uses C++, whereas most DS developers probably use C, and secondly, it uses PALib, which abstracts away the complexities of the hardware and is therefore frowned upon by the more purist homebrewers. C++ has to stay, as only a crazy person (or Linus Torvalds, apparently, who it seems will approach every problem with the same rusty screwdriver he’s been using for the past 20 or so years, because he’s seen a few people make a mess when using other tools such as step ladders or those new-fangled electric screwdrivers) would try to write a GUI with C when there are more suitable alternatives around. PALib isn’t a necessary requirement, however, and it would be annoyingly tedious but possible to strip it out of Woopsi and replace it with libnds calls instead.

On a side note, I’m slightly disturbed to discover that no-one seems to know what licence PALib has been released under. SourceForge lists its licence as “None Listed” (helpful), whilst no-one on the PALib forum has responded to a question I posted about it. The PALib installer doesn’t contain a licence or any mention of one. It doesn’t even have a copyright notice anywhere. To me, this suggests that it’s considered public domain. Either that, or choosing a licence didn’t occur to the developers. If it’s the former, then I could strip out the PALib dependency simply by merging the functions I use into the Woopsi sourcecode. If it’s the latter, then I’m dubious about using PALib when I have no idea what terms I’m implicitly agreeing to follow every time I hit the compile button.

Some other things that I think may be potential barriers to Woopsi adoption are:

  • It looks like an operating system from the early 90s
  • It hasn’t been designed specifically for the DS’ ergonomics (contrast with the beautiful iPod Touch/iPhone interface)
  • Homebrewers generally don’t want to use other peoples’ code - they want to create and discover things for themselves

I disregard all of these minor barriers because they are intentional in the design of Woopsi - I want to create an interface that looks like Workbench 3.0.

Here’s an idea that I want to integrate into version 1 - bitmap buttons. These are just like standard buttons, except they display a bitmap instead of text. When held down, they show a different bitmap. Should be easy to implement.

The addition of bitmap buttons will let me take Woopsi in unusual directions. For example, we can create a window the size of a screen, make it borderless, and add a superbitmap to it. We can then add a set of borderless bitmap buttons, and we’ve created an interface more akin to MenuDS than a windowing system.

Lastly, I’ve added a load of documentation to the Woopsi SourceForge project, which you can find here: