Creative Zen Vision:M

[gitrdone300ex]

I have been watching this thread for a long time and I would like to try to start helping out if its not too late. I am new to this stuff, but i have done quite a bit of fw modding on cell phones. I have a lot of free time and would like to try to start helping if someone feels like explaining to me how i need to get started. I have vista 32 bit. What programs would I need and what do i need to have on my zen vision m? I would be glad to help. thanks

[tomaskn]

guestion: are there any plans to change the battery indicator system? because the current firmware wont let me use my new battery ,its 3,7V instead 3,2 or something like that;
i can make the battery work but if my player crashes and i have to reset the indacotr go's to "battery drained" mode wich is wrong.and when its working the indicator wont change

it would really be great if you can make these battery's work normally. you get something like 7,5hrs of video and much more audio (didnt test it)

i wish i could do something myself but...
could you make a code wh allows you to manually set battery 0% and let it charge all night (full charge) and then set the 100%

something like this is probably farfar away from today but  thank you all for reading this and all the work you guys have done before

sorry for the horrible english

[mcuelenaere]

I have been watching this thread for a long time and I would like to try to start helping out if its not too late. I am new to this stuff, but i have done quite a bit of fw modding on cell phones. I have a lot of free time and would like to try to start helping if someone feels like explaining to me how i need to get started. I have vista 32 bit. What programs would I need and what do i need to have on my zen vision m? I would be glad to help. thanks

Take a look at the wiki page. I also advice you to set up a build system, so you can compile code yourself.
Then start with trying to fetch the current SVN, patch it with my latest diff and compile that and upload it to your ZVM.
If you succeed in that, you can start trying to disassemble the original firmware and try figuring out the hardware.

guestion: are there any plans to change the battery indicator system? because the current firmware wont let me use my new battery ,its 3,7V instead 3,2 or something like that;
i can make the battery work but if my player crashes and i have to reset the indacotr go's to "battery drained" mode wich is wrong.and when its working the indicator wont change

it would really be great if you can make these battery's work normally. you get something like 7,5hrs of video and much more audio (didnt test it)

i wish i could do something myself but...
could you make a code wh allows you to manually set battery 0% and let it charge all night (full charge) and then set the 100%

something like this is probably farfar away from today but  thank you all for reading this and all the work you guys have done before

sorry for the horrible english

Yes, that will be no problems (look at the current Rockbox targets, they all support it). But, as you say, that's for in the far, far future

[Falafel]

@mceulenaere: It works! Constantly changing value

edit: But I messed some stuff and reverted to the originals and appllied your diffs, (which caused some trouble.. So I now have to rediscover the right settings for my screen.. after that I'll be able to give you all the addresses you wanted)

[mcuelenaere]

@mceulenaere: It works! Constantly changing value

Does it change about every second? If so, it is the RTC(Real Time Clock)

[Falafel]

No, way faster than that, I can hardly read/see the value before it dissapears..

[mcuelenaere]

No way faster than that, I can hardly read/see the value before it dissapears..

Did you just compile the diff I put on the forums or did you add i2c_reading(); ?
If not, could you do that anyway and post the addresses (0x??) it reports?

[Falafel]

I compiled the diffs.

Here are the addresses:

0xE
0XF
0x10E
0x10F
0x1A2
0x1A3
0x20E
counter is still running but it doesn't seem to add anything new, so I'll post this.

[mcuelenaere]

I compiled the diffs.

Here are the addresses:

0xE
0XF
0x10E
0x10F
0x1A2
0x1A3
0x20E
counter is still running but it doesn't seem to add anything new, so I'll post this.

Ok, now remove the i2c_reading(); line and replace (l.174)

Code: [Select]

unsigned short arr[2] = {0xD1, 0xC8};with

Code: [Select]

unsigned short arr[7] = {0xE, 0xF, 0x10E, 0x10F, 0x1A2, 0x1A3, 0x20E};and replace (l.178)

Code: [Select]

for(i=0;i<2;i++){with

Code: [Select]

for(i=0;i<7;i++){
and compile that.
Now tell me which address changes about every second.

edit:
I think 0xE, 0x10E and 0x20E are mirrored; the same applies to 0xF and 0x10F

edit2:
the counter is just a hardware counter that just counts up and resets and counts again.
It is just there so that I can identify if the device would have crashed

[Falafel]

When I compile and run (with finally the right dimensions on screen) I see the 7 hex codes I just added, with long (36 Bytes) never changing codes behind 'em, and the top one (0xE) has a constantly changing 4digit number behind the code.

Edit: the long ones are addresses? because they don't change.

[mcuelenaere]

When I compile and run (with finally the right dimensions on screen) I see the 7 hex codes I just added, with long (36 Bytes) never changing codes behind 'em, and the top one (0xE) has a constantly changing 4digit number behind the code.

Edit: the long ones are addresses? because they don't change.

Strange.
The format is as this: '0x[ADDRESS]: [READ 20-BYTES OUT ADDRESS]'.
If the long ones are FFFFFFFFFFF... or 00000000000... there isn't a slave device responding to that address.

But I conclude that the Zen Vision does have different hardware in comparison with the Creative Zen Vision:M.

BTW: what are the basepx and basepy values you use?

[Falafel]

Basepx = 80;
Basepy =   0;

Well, maybe I could find the different information in the fresc of my zv?

Edit:
also, it was possible to run the Rescue program of the ZVM on the ZV so at least buttons and such should have the same interface I guess.. (Although I do not remember if I tried them..)

Edit2:
output on screen:
0xE: 00...00 FF...FF
0xF: 00...00 FF...FF
0x10E: 00...00 FF7FFBFF7FFBFF7FFBFF
0x10F: 00...00 FF...FF
0x1A2: 00...00 1BFF001841
0x1A3: 00...00 41119858080
ox20E 00...00 F7F7F7F7F7F7F7F7F7F7

[mcuelenaere]

Whoow, I just see that I've got some new permissions on the forums  
Apparently, I got promoted to Developer? Whoever did that, thanks!  

Anyway, I'm getting close to the ATA driver, although I'm having trouble with ATA_CONTROL; I just can't seem to figure out which value it should have :S

As usual, diff is attached.

[mcuelenaere]

I'm having difficulties with sleep() and more precise sleep_thread() (and maybe switch_thread() ), the device just restarts when some code calls sleep().
Were there any other ports behaving the same at this stage?
It seems like it has got to do with some ARM-specific code, as I don't think the (current used) DM320 code can reboot/crash the device.

As I see in the code, sleep() is replaced with a loop for some ports as they have problems with it at bootloader stage. But my problem is that actually bootloader stage is already passed; so it won't matter if Rockbox or the bootloader get loaded; both will have trouble with sleep()

[Domonoky]

hi,

i seam to remember that on some targets the bootloader doesnt have the interrupts enabled, and thats why the replace the sleep with a loop.
Perhaps this also the problem here ?

good luck..