Rockbox Development > New Ports
Creative Zen Vision:M
mcuelenaere:
--- Quote from: Aurix Lexico on December 18, 2008, 06:52:11 PM ---Using send_command_to_pic, I've tried writing everything between 0x0000 and 0xFFFF to the PIC. I then tried just changing the third byte (aka between 0x00 << 16 and 0xFF << 16) and then tried just changing the fourth byte (aka between 0x00 << 24 and 0xFF << 24). It didn't appear to do anything. The keycodes never changed. Most of the time the function gave me back 0xFF0F0000, but every once in a while (once in every 30ish calls to send_command...), with absolutely no pattern that I can find, it will return a different code. Well, actually, if you move your finger over the touchpad very fast it will start returning 0xFFFFFFFF. All I can think about is, what is the point of the PIC? It has to have a point, it has to serve a purpose otherwise why even bother with it in the first place? Why change the keycodes at random?
--- End quote ---
I know it is used to disable the touchpad.
It is also used to give information about various input (i.e. keys, TV-out, headphones, USB inserted, charger inserted, ...)
But because the protocol is completely proprietary (and custom-designed, like we're used of Creative..), I think the only way to figure out how it works is reverse engineering the OF...
Why change the keycodes at random?
I don't know, perhaps we just don't understand the protocol completely? Perhaps there's something wrong with the I²C implementation? (although I doubt that)
Aurix Lexico:
Well, is there a way for me to extract and disassemble the OF? I'm not great with assembly, but I still want to try :-\
mcuelenaere:
--- Quote from: Aurix Lexico on December 18, 2008, 07:13:30 PM ---Well, is there a way for me to extract and disassemble the OF? I'm not great with assembly, but I still want to try :-\
--- End quote ---
Yes, have you already downloaded ZenUtils?
If so, with it you're able to extract the OF from the Creative firmware updater software and decrypt it.
The next step is disassembling, and if you have access to IDA there are some tools on the wiki which help IDA understand the firmware format.
I think I already helped somebody else explaining how the OF's firmware structure basically works, I'll look for that info and I'll post it here if I find it.
Aurix Lexico:
I've been looking at the disassembled code for the PIC the last couple of days. The function that handles the i2c communication is conveniently labeled "i2c_handler" and I've been tracing through the 550ish lines of assembler that make it up. Unfortunately, "i2c_handler" is the only actual name in the entire 55k line file, all the other function and variable names are just numbers based on where it is in the file. Even so, the actual code is fairly easy to understand since PIC 18 has very few instructions. I still haven't found anything useful yet, though
mcuelenaere:
--- Quote from: Aurix Lexico on December 23, 2008, 12:38:53 AM ---I've been looking at the disassembled code for the PIC the last couple of days. The function that handles the i2c communication is conveniently labeled "i2c_handler" and I've been tracing through the 550ish lines of assembler that make it up. Unfortunately, "i2c_handler" is the only actual name in the entire 55k line file, all the other function and variable names are just numbers based on where it is in the file. Even so, the actual code is fairly easy to understand since PIC 18 has very few instructions. I still haven't found anything useful yet, though
--- End quote ---
I remember myself RE that same piece of code (lost all the files though...), and I think at the time I got some documentation about how the PIC handles I²C (probably source code or so)..
You have seen the datasheet I suppose?
You could also try looking at the Microchip.com site if they provide code/a framework for handling I²C, if they did Creative probably used it and you can abstract away at least one layer then.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version