A New SuperZaxxon When You Least Expect it


A couple of weeks ago, Notaz released a surprise update for the Pandora firmware. After all, the 1.73 one was supposed to be the very final firmware update for the Pandora, yet Notaz is a perfectionist and does not easily leave things unfinished. This new firmware comes with a number of changes worth mentioning in a whole post.

First let’s go through the list of changes brought by 1.74.

  • Kernel: updated to 3.2.78
  • Kernel: the vsync code has been rewritten: multiple programs can now wait for vsync, it now works correctly when LCD is off and TV-out is on
  • Kernel: added a new custom adaptive vsync ioctl
  • Kernel: added a new custom ioctl to read the line counter
  • Kernel: changed the LCD timings to reduce the VFP<->vsync window. Possibly reduced flicker in 50Hz mode too.
  • Kernel: enabled the xpad (xbox/xinput compatible gamepad) driver (no idea why it was off…)
  • Kernel: it’s now possible to map memory at virtual address 0 (might be useful for some emulators)
  • Kernel: fixed a SD card read corruption (reported by dgame)
  • Kernel: the default SGX driver should no longer crash when display is turned off (usually when lid is closed) and 3D program is running
  • SDL: now uses the new adaptive vsync when SDL_OMAP_VSYNC is enabled
  • Bluez: /etc/bluetooth/audio.conf defaults changed to enable the socket API. Note that this disables the dbus API, so you may need to edit the file if you need it. See http://www.lightofdawn.org/blog/?viewDetailed=00031 for more info.
  • Fixed bluetooth suspend (patch by urjaman)

While some changes are fairly explicit, others require some additional explanations. Since Notaz was so kind to be available for precisions, let’s go through with him on several aspects of this update.

First, as most of you know, the mainline Linux kernel is now in the 4.x series, yet this update continues in the 3.2.x branch. Actually the main reason why the Pandora does not get the latest kernel is due to numerous hardware drivers holding it back:

Notaz: The reason for staying on 3.2 is that the Linux kernel is always moving and evolving at a very fast pace, so if the code doesn’t find it’s way into Linus’ mainline tree, it has to be carried and maintained by the vendor to be compatible with the core. There is no stable internal API and the drivers have to change along with the Linux core. When drivers are in mainline, people making the core changes also update the drivers, when they are not, the vendor has to do it. Unfortunately we have quite a few such things like the nub drivers, pwm leds, some charger functionality, bsp’s c64_tools. Some things can’t ever get into mainline because of the nature of things, like keypad Fn handling (not allowed in the kernel), overclocking and of course the SGX driver. We also have some things like hugetlb support, cached framebuffer (those were proposed but never accepted to mainline due to lack of interest) and also hacks that benefit Pandora but would break other devices. There is also a problem of common OMAP driver regressions in the new kernels as it seems the OMAPs are getting less used over time and problems are not noticed by the kernel devs. The main benefits of newer kernels for Pandora would be more USB device support, newer filesystems and newer Linux distribution support. Unfortunately the effort needed to do a full-featured port is way too large. Meanwhile if basic support is enough, the mainline already has it and the latest kernels should at least boot successfully, albeit with various issues.

All the new changes related to VSync actually started with a request from TomB, who noticed that Vsync was hard to stabilize in his Amiga Emulator (UAE4ARM) when more demanding games were running. Here’s a few more details on why some changes were necessary to improve the Vsync function:

Notaz: The idea of the new Vsync code is to eliminate the performance penalty that in some cases results from using Vsync. Vsync is fine when the game can always prepare a new frame faster then in 16ms, for example if it needs 6ms to prepare the frame, Vsync will wait out the remaining ~10ms to get 16ms and you get stable 60fps (1/0.016666…). However if it’s not fast enough and you need say 17ms, you’ll get 1/0.017 ~= 58fps without Vsync but only 30fps with Vsync on! That’s because at the time of 17ms, the Vsync signal at 16.666…ms will be missed and the wait will wait until then next at 33.333…ms. Things are even more complicated when the game (or emulator or whatever) can produce frames fast enough in some cases and not in others because scene complexity changes, and this is quite common actually.

So the above problem can be “solved” by presenting the user with Vsync on/off option, but I don’t think this is optimal. The game should be able to do it all by itself by measuring time, however it’s not as easy as it sounds, because there is no way to know how much time exactly is left until the next vsync. It could take a timestamp just after wait for Vsync returns, and after preparing the frame compute the difference to see if it has fit into 16ms or not. Unfortunately this is not reliable, as Vsync wait may actually return several ms (or more) after actual Vsync because the kernel had to do some driver work (processing sound, input queue, interrupts or whatever) and the game may think it has some time left until next Vsync while in fact it doesn’t.

So there is where the new Vsync ioctl fits in, it atomically (in one operation) checks if it’s the next frame already and waits if it’s not.

So far this feature may be especially beneficial in UAE4ARM but Notaz may have some plans for other software too:

Notaz: I haven’t released anything to take advantage of it yet. Jazz Jackrabbit 2 might be a good candidate, but I still need to update it.

The addition of XInput to this update is great news, and it’s actually coming from a personal needs from Notaz! I have not tested it yet, but there’s a good chance it may let you use Xbox360 controllers right out of the box now.

Notaz: The reason I enabled it was that I bought a 3rd party xinput device (marketed as Xbox compatible) and it did not work, which turned out to be because of the missing driver. I don’t know if the actual Xbox controller works, but based on the driver’s description it looks like it should.

As mentioned in the update, there was apparently a SD card corruption problem. This is one of these obscure issues that are hard to reproduce. Nevertheless Notaz took action to reduce the chances of it happening, with the following tweaks.

Notaz: The SD card corruption issue is not entirely clear. It seemed to be very rare (only one user (dgame) reported it) and showed up after code change of multiple DMA parameters (prefetch, burst, so called “posted” mode). I’ve disabled all of them, except burst for wifi (the only one that gives measurable improvement) and dgame reported that the problem went away, so I left it at that.

One of the nicest, noticeable changes coming from this firmware is related to the GPU driver. As Pandora users know well, closing your Pandora and attempting to go to sleep mode when an program uses the GPU driver leads to a system freeze. This problem is now resolved in 1.74 – You can go ahead and try it. Now games using the GPU should be able to go to sleep and recover from sleep just fine when you open the lid again.

Notaz: I’ve found some strange code which executes at the time of display blanking and just removed it. The open portion of the SGX driver is a mess with no comments and it’s hard to tell what the code does without any documentation.

And last but not least, the bluetooth changes now include the socket mode by default, and this fixed for me the issue I had with not being able to connect to any audio BT device. Kickass apparently could do it before this firmware, but it never worked for me until then. I have recently shown how you can do it in 1.74 (there are some manual steps required but it’s easy) in case you have any interest in using bluetooth audio.

And that’s it for 1.74. A very nice update indeed.

Leave a Reply

Notify of