soledad penadés

Some months ago I began tinkering with programming for PSP. I installed the toolchain and all that, but kind of abandoned it because although the ps2dev guys created a really nice environment to develop in, it still felt bad and precarious in a certain manner: whatever you did was in a way illegal. You had to jailbreak your PSP for installing custom software and so had to do the potential users of your application. And it didn’t feel right to be programming for a platform whose creator (Sony) doesn’t want you to program for — unless you pay them a license, I guess. On the other hand, developing for iPhone is definitively a no-go area for me, as you might already have deducted from my previous posts on this subject.

Then, Ricardo got an Android phone a few weeks ago and began programming for it. Yesterday, somehow I thought: And why not? I wasn’t aware that it was that easy to get started, and I am very pleased to have been proved otherwise: I downloaded the SDK and began following the guides and more or less had a grasp of how to build my first app in just few hours. Compared with building something for PSP, it is actually a bless. I do not know how does it compare with programming for iPhone, but from my experience with Cocoa, Objective C and XCode, I am sure it is much better. If only morally speaking and because one does not need to use the cumbersome [ brackets : everywhere syntax [here : with more [brackets : ha! ] ] or the infamous and opaque Apple developer docs.

It’s been a very very long time since I last did any Java programming –OK, actually it is not that long, only five years, but that, in Internet time, is definitely a lot of time–, and hence my ability to combine layers and layers of code to form what I used to call the archetypal Java onion is a little bit rusty.

So I am all the time looking for information googling for this and that, since I don’t remember well certain things, other have changed, some features are not implemented or are slightly different in the Android platform, and finally, in other cases, my mind is intoxicated with other languages and I tend to think that if something is available in language X there will probably be something like that in Java.

And there I was, looking for some info regarding File separators, when I found this guy suggesting the use of File.separator. Of course!, I thought that’s the least one should do. In fact, I was looking for an equivalent of Python’s os.path.join, which I happen to find very convenient, so this wasn’t exactly what I expected to find. Anyway, I kept reading the comments and suddenly got hit where it truly hurts:

What about properties file?

says that comment. Ouch, that really HURT.

This was one of the main reasons why I disliked Java programming. The tons of property files scattered all around the project, for configuring all sorts of stuff which could be deducted sometimes or that wasn’t actually needed in fact, but was there, due to lazy habits, or just out of ignorance. And XML databases, and a myriad more horrors created by unexperienced bad Java consultants. Not that I was the Best Java Programmer EVER, but I certainly noticed the code smells, which is undoubtedly the first step towards better coding.

Fortunately, things seem to have changed a lot since then. For good: my development computer is amazingly fast (back then, I was assigned a rheumatic Pentium III at 550MHz with a ridiculous 64M of memory and 6 Gb disk – of which only 0.5 were actually free: you had to use headphones to prevent your ears from being mercilessly hammered with page-swapping noises). And in the software front, the Android SDK is very nice and well thought (or at least it seems so, at first sight). The emulator — I love it! That’s where the whole concept of Java demonstrates its power, since being a virtual machine, it can be executed everywhere, whether it is the actual phone or the emulator.

I also like the idea that you can get really dirty –programmatically speaking, that is– and optimize certain parts of the code with C or assembly. Of course, then you can instantly forget about portability aspirations (since it will get compiled for an specific processor, i.e. ARM), but if required, could be done.

Being day number 1 of Android programming, I still feel a tad lost, and some things do not make much sense yet (for example: the easiness with which the applications get terminated when an error is encountered, although it is understandable in a limited resources environment such as a phone) but I am finding my way around.

Expect to find some Android related posts here from now on :-)

Messing with the memory stick is fine if you’re just going to do it a couple of times, but after a while it becomes tedious.

At that point I decided I would try to make psplink work with my computer. It is another utility programmed by the superclever people at pspdev, and enables you to control the psp and even use your computer’s hard drive as readable/writable by the console, so you don’t need to copy things to the GAME directory anymore.

The building process was quick and easy, although it could have been faster, if I hadn’t mistakenly gone into the psplink directory from pspsdk’s SVN repository (which is an older version), instead of going directly to the psplinkusb directory, which is the one that lets you do everything via the USB cable. Also, this version’s manual is a tad clearer and more explicit, so unless you have any odd interest in using the older version, go for the newest one, at svn://svn.ps2dev.org/psp/trunk/psplinkusb.

Yes! no more messing with the memory stick! You can even reset the console or get an screenshot, like the one from the picture :-)

Following the installation of the toolchain, I decided to make a little program to get some information about the PSP’s interface, from the programmers point of view. That is, it would use SDL’s joystick functions to find out how many axis and buttons and which codes did they report to the program. Although it might seem useless it is an easy exercise in checking events and it could even be the base for a future game.

I first tested the program on my computer, using a Logitech USB pad that I have for playing emulators. I intended to use it for real games but I still haven’t found one which doesn’t use the mouse. By the way, the pad works flawlessly in linux, just in case you were looking for a compatible joystick for your linux box.

The pad reported as having six axes, where the axes corresponded to the two analog joysticks and one digital joystick (two axes per joystick: vertical and horizontal), so I was expecting to find a very similar result in the PSP, but with four axes since it only has two joysticks.

Instead, I got an interesting result: two axes only, and the rest were buttons! PSP is reporting the digital joystick as simply four isolated buttons. This, although being surprising, also makes much easier to program simple stuff where you just need to react when a button has been pressed, instead of having to check the value of the axis which is reporting motions, and deduct the appropriate intended direction from there.

I also noticed that the analog joystick can sometimes have a very erratic behaviour, reporting movements while no one is even touching the console. It might be because it’s not a brand new PSP and maybe there’s some dirt or something in the controls … or maybe we were experiencing a earthquake and nobody noticed? :)

For the record, these are the reported SDL button codes, so you can look for an SDL_JOYBUTTONDOWN type of event, and compare event.jbutton.button to the following values to decide what to do:

Left: 7
Right: 9
Up: 8
Down: 6
L: 4
R: 5
Triangle: 0
Square: 3
Circle: 1
Cross: 2
start: 11
select: 10

I didn’t manage to read the other buttons, they seem to be out of the reach of SDL. Maybe it’s got something to do with kernel/user mode, but it doesn’t worry me for the time being.

If you want to try this at home – worry not, it’s safe and harmless! Here’s the source code. You’ll notice I also used the balls and hats functions, but I must confess that while I suspect that balls is referring to trackballs, I have no idea what hats is referring to. If anybody knows, let me know in the comments so that I can stop imagining a little Mexican hat dressing a gamepad :-D

Here’s also a possible sample output, using my logitech pad and pressing buttons and moving sticks randomly:

(As all the guides I found out there were either outdated or specific to windows/cygwin, I decided to put this here just so that I remember how to do this next time I have to install the toolchain on another computer :-) )

First, check out the toolchain sources from svn://svn.ps2dev.org/psp/trunk/psptoolchain into say ~/tmp/psptoolchain:

Notice the svn:// and not http://, most tutorials are still using http://svn… and it won’t work.

Now read ~/tmp/psptoolchain/readme-ubuntu.txt. It tells you to make sure you have a series of packages installed; a pity they forgot to add a couple of packages (libmpfr-dev and libgmp3-dev). This is the full, updated list of packages to install:

with that and following the remaining instructions in the readme-ubuntu.txt file you should be able to get the toolchain installed in your computer. It will take some time depending on your processor etc, on my powerpc mac it takes a lot of time (in the order of hours), whereas in my brand new ubuntu machine with quad processor it took ~25 minutes, if I remember correctly.

So once it finishes, everything will be installed at /usr/local/pspdev. You might want to create a shortcut to the samples, which are in /usr/local/pspdev/psp/sdk/samples, but have a look at the other folders anyway, since the .h files are in there too and it’s good to know what you’re dealing with.

And this is entirely optional, but if you want to install SDL and other libraries, the easiest way I found is to use their psplibraries script. It is hosted in the same SVN repository so you just need to check it out:

Again, there’s a readme-ubuntu.txt file; you might need to install libtool as specified there, and after that, simply run the libraries-sudo.sh file and let it work for a while since it needs to grab the sources for the libraries and build them.

Once that is finished too, the libraries will be also ready for your consumption and linkage inside the /usr/local/pspdev folder too, so everything is nice and clean. The guys at pspdev did a good job, kudos to them!