TomTom ONE v2

Back around Feb 2011, I was in need of a navigation device. After navigating the minefield that are TomTom model names, I managed to snag a TomTom ONE V2 off ebay for an uncontested $20 opening bid. The V2 is an "old" low-end model, so I guess no one particularly wants them, despite the fact that TomTom seems to have a maddening habit of removing functionality from newer models. So the V2 actually has Bluetooth, and an SD card slot, that newer (and much more in-demand) ONE models lack.

After searching bittorrentTHE FLOOR I managed to get an "SE" Navcore v8 running on it, which is hacked up to think its running on a high end model. (Supposedly v9 is possible, but everyone says it doesn't play nice with the not-widescreen, so I haven't tried it) Much of the difference between low end and high end TomTom models is simply some artificial software flags. So after cramming a 4gb SDHC card in it with some newer maps, I have essentially a high-endish GPS unit with IQ Routes, Advanced Lane Guidance, text-to-speech, MP3 etc for a total cost of ~$35.

270311221857-01 270311221907-01 270311223130-01

With that done, I of course immediately got to work totally hacking the gibson.

I installed TTconsole, and discovered it really sucked. So I downloaded the source, and proceeded to hack the hell out of it to 1) compile, 2) work properly (the touchpad code was completely broken) 3) compile cleanly and 4) not suck, which pretty much required rewriting the whole thing. It was adapted from an old Atari ST terminal emulator, and it shows. Absolutely terrible code, massive if/else blocks for dispatching events, global variables all over the place because apparently GEM developers never heard of the Law of Demeter or responsibility driven design. (In particular, ManifestResponsibility!) In other words, exactly how I remember Atari application code looking. No wonder I got nowhere trying to program GEM back in the day...

TTconsole embeds an implementation of an entire AES OBJECT manager in order to draw the keyboard!

270311234253-01I got a shell over bluetooth with btconsole, and compiled up a custom kernel with support for mounting a loopback ext2 filesystem, among other things:

280311033746-01I got tslib working, including writing a module to make it use the TomTom's native touchscreen calibration, instead of having to screw around with ts_calibrate:

I got DirectFB up and running: (Seems to have an odd glitch when blitting solid white areas for some reason

280311030933-01 280311033025-01 280311032629-01

280311020702-01After getting SDL working, including hacking the hell out of it to run with the TomTom's default of no vconsole support in the kernel, and compiling gpsd, I got navit working:

Performance is almost acceptable when not navigating, (and not viewing downtown Minneapolis) but if you actually try and navigate, it slows to a crawl and becomes completely unusable. Oh well.

For some lulz, and the possibility of running GpsMid, I managed to get phoneME running, seen here running MIDPSysInfo and showing a total lack of JSRs:

170411021514-01-fixed 170411021332-01

Which required an incredible amount of hacking, including writing glue code so that DirectFB pointer events actually connect to the GUI. Since it's designed for phones without pointing devices, Sun apparently just didn't bother. So I have me a fully functional MIDP environment running on a TomTom. Just in time for Android to come along and render MIDP completely moot...

Still, this means it is possible to run things like Gmail for mobile and Opera Mini on the TomTom. But until I figure out how to get a TCP/IP connection going over bluetooth, they don't really do much and don't even make for an interesting screenshot.

And then I got completely embroiled in hacking up the kernel. The TomTom OS mounts the SD card FAT filesystem in "sync" mode, which results in terrible performance, but is the only safe thing to do with its ancient 2.6.13 kernel. Bumping the kernel up to a version that supports the "flush" option should increase performance nicely. I managed to bump it up to a 2.6.14 kernel through the incredibly awkward and slow, but educational, method of applying TomTom's changes to 2.6.13 in a git branch, then re-basing 2.6.14 on top of it. Bumping that up to 2.6.15 was not so successful, due to changes in the device model I haven't completely understood and sorted out. I managed to come up with a kernel that would partly boot up but panic once it attempted to initialize the TomTom specific drivers. So my TomTom is stuck running 2.6.14 for now.

Current status: This PND has since been obsoleted by an Android smartphone.