See Talk:Current work for discussion.
ToDo for 1.4
I'd like to support some more devices with 1.4; perhaps a generic firmware hacking program can be made.
ToDo for 1.3
I have discovered there's a bigger number of different firmware images in the world than 'just' the one TomTech uses. That wouldn't be a problem, if they would control the display in the exact same way. Well, they don't, e.g. the TomTec and the Coby devices, while possibly completely physically the same, control their displays in a different way.
What we need to get around that problem is a larger protocol: instead of just accepting the data, the device must be able to send it's specs so the software running on the PC can then send the data in the right way: 12bit, 16bit, 128x128, 64x96, whatever. To do this, we firstly need to modify the firmware to be able to communicate its display parameters to the PC, and secondly we need to create a library that interfaces to the devices in such a way that other programs can talk to that program universally. Communicating the parameters can be simple: just locate a free block of program memory and insert a magical identifier plus the parameter block.
It would be nice to have a bit more control over the display and the chip, that's why V2 may be better off with a sort of 'command set' as the hack-interface instead of the 'write-directly-to-vram' we have now: instead of raw data, commands like 'write this to this location, turn backlight on, reset' etc can be written to the device.
- Maybe it is possible to switch to "upload"-mode when plugging in an USB-connector and only start charging the battery when a key is pressed when inserting the USB cable. --TD-er 0:58, 22 January 2008 (CET). Seconded! --bifferos
- Make the controller talk UART over one of its button pins --Bertm 18:52, 21 January 2008 (CET)
- Perhaps it's possible to implement HID endpoint(s) for reading these keys, but I'd settle for just being able to read the (de-bounced) values in any way possible --bifferos