In other news, I've been making some progress on the Playstation 2 Linux front. I think I'm now within spitting distance of actually being able to make a start on porting the various old games I wrote for the PC and BBC to run on the PS2, which will be cool.

Most of the work was done for me by the PS2 port of libSDL. For those who don't know what SDL is, it's a library that attempts to allow direct framebuffer access while still being portable to abstracted sorts of operating systems such as X and Windows. It achieves this by having a "lock" call, which returns you a pointer to a framebuffer or something looking very like one. You then modify the memory pointed to by that pointer, call "unlock" and "update", and your changes appear on the screen. So on a system that provides direct framebuffer access, "unlock" and "update" do nothing while "lock" simply hands you a pointer to the real framebuffer; and on a system where you're several security barriers away from anything resembling real hardware, "lock" gives you a pointer to a chunk of ordinary memory owned by SDL and "update" uses the local bitmap-handling functions to copy your changes on to the window your program is displaying.

Given that surely the whole point of a dedicated games machine is that you should be able to directly access the framebuffer, it therefore seems a bit strange that the PS2 port of libSDL doesn't give you direct access; instead it appears to do a bulk copy when you call "update". I speculate that Linux is getting in the way here, blocking access to real memory and forcing everything to be mediated through system calls. Still, I seem to be able to shift a whole screenful of data around in every frame (running at 50 fps to match the TV) and still have about 3/5 of my CPU time free, so that ought to be more than enough for any games I plan to port. It may constrain my options if and when I wonder about writing some new ones, though; particularly since I can only achieve this performance in the 8-bit paletted video mode and can't manage anything so good in true colour. Ah well; such is life.

Meanwhile, SDL has some trouble accessing the controllers; it can cheerfully get at the direction buttons and eight of the fire buttons, but the mushroom-shaped analogue things give it more trouble. It can't see the right-hand one at all; it can't see the two extra fire buttons you get by pushing the tops of the mushrooms; and it can't turn on analogue mode in the first place so I have to do it manually with the button on the controller. All of this exactly matches what happens when I open /dev/js0 myself and monitor input fron it, though, so it doesn't seem to be SDL's fault. I assume you need to send something back to the controller to change its mode. Again, this won't impair porting of my old games, but will restrict what I might wonder about writing in future.

Timing off the vertical retrace was no picnic either; SDL seems to contain no facility for doing this. I remain incredulous that nobody except me seems to think vsync timing is remotely necessary in a games platform; how else are you supposed to get decently smooth movement, eh? I suppose it might be less important in modern 3D-type games, and it was almost useless on the PC because (a) the PC won't give you a vsync interrupt and even finding out when they're happening is CPU-intensive, and (b) vsyncs happen at a different rate depending on your graphics hardware, which makes it hard to write a game that uses them and is consistent on all machines; but in pretty much everything I used to write, the video frame was the natural unit of time around which to base everything that happened in the game. Fortunately the PS2 hardware will give you a vsync interrupt, even if SDL doesn't know anything about it; so I was eventually able to look up the vsync interupt in the PS2 hardware manuals, search through the kernel source until I found the code that received it, and then look for the ioctl that provided user access to the facility. And thankfully it can be done - there is an ioctl which lets you wait for a vsync, and another which lets you count the vsyncs as they pass. Phew.

So I now have adequate video, controller access and timing facilities to start porting my old games (the only remaining difficulty being that half of them are written in BBC machine code and the other half in Borland Pascal!). Of course what I really wish is that someone would port a Spectrum emulator ... :-)