[Troy Wright] acquired a lot of twenty broken Dell Axim PDAs. This type hardware was quite popular a decade ago, but looks archaic when compared to a modern cell phone. That’s why he was able to get them for a song. After a bit of work he managed to resurrect eight of the units, but was dismayed to find there’s no published method for controlling the back light from software. For some reason this is a deal-breaker for his project. But he knew it was possible because there are some apps for the device which are able to set the back light level. So he found out how to do it by reverse engineering the software.
The trick is to get a hold of the code. Since it’s not open source [Troy] used IDA, a graphical disassember and debug suite. He had some idea of what he was hunting for as the Windows CE developer documentation does mention a way to directly control the graphical hardware independently from the display driver. A few hours of pawing through assembly language, setting break points, and testing eventually led him to the solution.
that pda uses an x-scale chip. pwm registers addresses are known and windows on the device allows one to map hardware regs using a single api call
one can then adjust the PWM to ANY, not just one of 7 or one of 15 possible values
3 api calls total to do this
A good point, but I think that doing this will let the actual driver keep snatching control back, hence why I didn’t follow this route.
I should probably note the dangers of using out-of-normal-range settings on hardware registers. The Fuze 2 port of Rockbox up until recently used the full range of brightness steps the hardware exposed which went considerably higher than the stock firmware (>20 vs. 12) and was indeed much brighter. It worked fine on most devices, but some couldn’t handle it for whatever reason and overheated damaging their power management breaking the backlight control, front panel LEDs and battery meter. This was exacerbated by the stock UI being quite bright (blues/whites) while the default Rockbox UI is dark (black) giving the impression of 12 on Rockbox being about 6 on stock.
Never suggested using values out of range 🙂
But even that can be of use to users (see brightnessFix2 for palm devices – one of my most-downloaded freeware programs)
The article notes that the brightness control has a number of undocumented settings.
“That’s not all though, by using values greater than 0×7, you can get at some other brightnesses that aren’t usually available. 0xF, for example is a very dim setting that’s almost-but-not-quite off. This is perfect for our application!”
Realistically though if the program can make the hardware do something the stock software cannot it’s best to include a specific warning as that feature might be disabled for a reason.
The other brightness settings are in no-particular-order, which makes them useless for a slider and might be why they aren’t activated. It’s also important to note that none of them are any brighter than “stock” full-brightness. I probably should have mentioned that in the article.
There are linux ports to devices like this with open code. Look for Familiar or Angstrom distributions and also take a look at the openembedded project.
I had(have) one of those AXIMs!. I flush mounted it in a box, added a little program whereby you must enter a code to stop acountdown timer, and used it as ‘the bomb’ for air-soft battles.
http://www.makershed.com/Defusable_Clock_Kit_p/mkntd2.htm
I’ve got one of the newer versions of these, the X50v, sitting at home. I’ve been playing around with ARM Linux lately, maybe I could hack something onto the Axim as well, nobody really ever tried and the few ports that did get made didn’t go anywhere. The limiting factor on these was the 64MB RAM, because the CPU isn’t bad even by today’s low-end standards (624MHz ARM that can be pushed over 700 when overclocked).
A memory upgrade is apparently possible with the x50v, basically replacing the 64MB chip with a 128MB one. Higher values (depending on availability/existence of said chips) might be possible but as it seems to be a BGA package this complicates things considerably.
The X50v and especially the X51v were the last and best of the Axim line.
They’re two of the few Windows Mobile devices with a 640×480 screen and those two also support an external 640×480 VGA display.
The AxDroid project is still going, Andriod will sort of run on them. The big holdback is nobody knows anything about the advanced features of the video processor. The only available data is just enough to allow the most basic 2D non-accelerated video mode.
If full video processor access could be reverse engineered, the X51v would make a pretty decent Android PDA. The expansion slot could accommodate a multi function card with an accelerometer, compass and whatever else hackers could cram into a Compact Flash II sized module. Then there’s the SDIO support to add more peripherals.
The ultimate hack would be wiping WinMo from its 256 meg ROM and flashing Android in its place.
Memory management would have to be a top priority, though it should be possible to use space on the CF as RAM. The Palm LifeDrive did that on its MicroDrive – and it works much better with a CF card.
Would be nice if there was an active LifeDroid project, especially if it was built to use much larger CF cards internally plus SDHC and SDIO, which the hardware is capable of.
I used to have that PDA. Then my apartment was broken into and it was stolen.
hmmm….is that my PDA?