Creative Zen Vision:M

[bobbaluba]

Nope, I still get the same errors.
Tried running make anyway, and then i first got the same error as Thorondor.
Then I tried: "../tools/convbdf -h -o sysfont.h ../fonts/rockbox_default.bdf" as suggested by falafel, but i still get this error when trying to compile:

Code: [Select]

make[1]: *** No rule to make target `/home/Administrator/rockbox/rockbox/build/f
irmware/target/arm/tms320dm320/creative-zvm/ata-creativezvm.o', needed by `/home
/Administrator/rockbox/rockbox/build/librockbox.a'.  Stop.
make: *** [build] Error 2

[mcuelenaere]

Nope, I still get the same errors.
Tried running make anyway, and then i first got the same error as Thorondor.
Then I tried: "../tools/convbdf -h -o sysfont.h ../fonts/rockbox_default.bdf" as suggested by falafel, but i still get this error when trying to compile:

Code: [Select]

make[1]: *** No rule to make target `/home/Administrator/rockbox/rockbox/build/f
irmware/target/arm/tms320dm320/creative-zvm/ata-creativezvm.o', needed by `/home
/Administrator/rockbox/rockbox/build/librockbox.a'.  Stop.
make: *** [build] Error 2

I suppose you're using Cygwin? Try using tools/rockboxdev.sh to fetch and download the latest ARM compilers (you'll need them anyway for compiling as ARM926EJ-S); if it still doesn't work I advice you to use the VMWare method: this will definitely work as I'm using it.

edit:
I misread your post, you're saying you still get the same errors so the patching failed.. I'll upload my firmware/target/tms320dm320/* tree in a zip-file in a minute..

edit2

[bobbaluba]

edit:
I misread your post, you're saying you still get the same errors so the patching failed.. I'll upload my firmware/target/tms320dm320/* tree in a zip-file in a minute..

edit2

Yay, it worked. Now my zvm is counting too.

[gnu]

I had the sysfont error myself, and I found that a "make clean" and "../configure" solved it.

[mcuelenaere]

I've taken my player apart and took some photos, if somebody is interested here's the link.

[Falafel]

Uhm, I don't know what happened, but the code won't compile anymore!
And although it's an error I can vaguely remember: "error: called object '196608' is not a function" I can honestly say that I cannot recal how to solve it..

Ow, and if I can get my hands on a camera I will post some ics of the internals of my zen too, might come in handy.

[mcuelenaere]

Uhm, I don't know what happened, but the code won't compile anymore!
And although it's an error I can vaguely remember: "error: called object '196608' is not a function" I can honestly say that I cannot recal how to solve it..

Ow, and if I can get my hands on a camera I will post some ics of the internals of my zen too, might come in handy.

Mmm, strange.. I think it has something to do with system-dm320.c; can you track down the error by doing 'svn revert system-dm320.c' in target/arm/tms320dm320/ ?
Test if that works, and if it does try re-applying the patch bit by bit (I believe you do understand some C, so I think that won't be a problem?)

[Falafel]

Good plan, I'll do that!

Edit:
Problem seems solved now, although to do so I had to revert back all the files you changed and afterwards I had to do some "snoeiwerk" in the files you added because for some reason they had their contents doubled. But this does explain what the problem was: I think I cut off the wrong part last time..

Now I'm gonna look at the new program running...

Edit2: Awesome!
It boots into the bootloader rescue menu and in the right bottom it shows a 4BYTE value that changes whenever I press a key, although I cannot actually move the cursor around.. Or select anything.. but Maybe thats because ZV uses different values there?

[mcuelenaere]

Good plan, I'll do that!

Edit:
Problem seems solved now, although to do so I had to revert back all the files you changed and afterwards I had to do some "snoeiwerk" in the files you added because for some reason they had their contents doubled. But this does explain what the problem was: I think I cut off the wrong part last time..

Now I'm gonna look at the new program running...

Edit2: Awesome!
It boots into the bootloader rescue menu and in the right bottom it shows a 4BYTE value that changes whenever I press a key, although I cannot actually move the cursor around.. Or select anything.. but Maybe thats because ZV uses different values there?

Hmm, I suppose it boots directly into the 'Rescue Mode' because it falsely detects you're pressing the MENU key.
But can you post all the hex values you're getting when you press buttons (look in buttons-creativezvm.c for some reference)?
Also give the values when you press the buttons for more than 2 seconds (button_x_long value) and normally after you release the button, the button_x value should reappear.
And if you can, please report the values for plugging in headphones, charger, USB, dock, power, ...
Thanks!

[Falafel]

First number is just pressing it, second is when you release it or keep it pressed a bit longer
Also, all the value are preceded by FFFF

On/Off    = 0F00 && 0F01
Hold      = 9F06
UnHold    = AF06
Volume Up = 6F00 && 6F01
Vol Down  = 7F00 && 7F01
Up        = DF00 && DF01
Right     = EF00 && EF01
Down      = FF00 && FF01
Left      = CF00 && CF01
Back      = BF00 && BF01
Menu      = 9F00 && Etcetera
Ok        = 1F00
Play      = 2F00
Next      = 4F00
Prev      = 5F00

USB       = 2F06
USB ouot  = 3F06
Headphones= AF06
Hdphns out= BF06
Charger   = 4F06 -> 9F05
Chgrout   = 5F06 -> 8F05
AV in     = 8F06
AV out    = 9F06

There doesn't seem to be a button long value..

[mcuelenaere]

First number is just pressing it, second is when you release it or keep it pressed a bit longer
Also, all the value are preceded by FFFF

...

There doesn't seem to be a button long value

Here's an updated diff with your values added: to enable them, uncomment the last line in export/config-creativezvm.h

Please test them and tell me if there's something wrong (I also updated the BASEPX and BASEPY in lcd-creativezvm.c so you won't need to do that).

But I'm thinking in the future, the Creative Zen Vision should be a port on it's own cause it seems it uses some different buttons as the ZVM does (but we could preserve the files used in tms320dm320/creative-zvm/xx-creativezvm.c; we could make separate ones for the zen vision). What do others think?

edit: it seems I added some unwanted test stuff, @Falafel: recomment #define DO_THREAD_TEST

[Falafel]

Well, I would say that given the minute differences till now, it would be useless to make it completely seperate.. A few defines for things like BASEPX and such should be enough.. at least, as long as the differences don't grow to big.

[mcuelenaere]

Well, I would say that given the minute differences till now, it would be useless to make it completely seperate.. A few defines for things like BASEPX and such should be enough.. at least, as long as the differences don't grow to big.

Ok, but if we're going to add the 60GB, the 30GB, the Zen Vision and perhaps the Zen Vision:W won't it be better if files are separated ?
But you're right, as for now this is the best solution.

One thing is bugging me (and which doesn't affect your device apparently) is that I don't get a 'button-release' value..
For now, there's just a built-in check that removes the currently pressed button after 40 ticks; but this isn't a very good solution and I thought maybe some kind of polling method to the PIC could solve problems (and I believe there's one according to OF, but I haven't figured it yet out how); so I'm puzzled why the Zen Vision has this and why the ZVM not...

BTW: what I meant with 'long value' is just what you reported: the 0F01 vs 0F00

[Falafel]

Yes, but this value is shown whenever you release a button OR hold it longer.. but well, I suppose it's alright.

Btw. when I load your diff in tortoise, I do not see any changes to button-creativezvm.c?

[mcuelenaere]

Yes, but this value is shown whenever you release a button OR hold it longer.. but well, I suppose it's alright.

Btw. when I load your diff in tortoise, I do not see any changes to button-creativezvm.c?

Arg, I forgot to do a 'svn add button-creativezvm.c' !
Anyway, here's the correct diff..