Creative Zen Vision:M

[Stu L Tissimus]

Sorry to get off topic, but something I noticed on the Wiki page for this port is that the original Nucleus OS makes use of Nano-X, which is licensed under both the GPL and MPL. I'm no lawyer, but I think that means that they're obligated to supply the public with the source code if the source code was modified, right? (I'd be amazed if they got Nano-X running on a new platform without some modification.)

So what I'm getting at is: couldn't we legally force Nucleus (or even better, Creative) to show us their source code? I'm sure that'd offer some clues about getting Rockbox running on the ZV:M.

Just my $0.02.

[mcuelenaere]

Sorry to get off topic, but something I noticed on the Wiki page for this port is that the original Nucleus OS makes use of Nano-X, which is licensed under both the GPL and MPL. I'm no lawyer, but I think that means that they're obligated to supply the public with the source code if the source code was modified, right? (I'd be amazed if they got Nano-X running on a new platform without some modification.)

So what I'm getting at is: couldn't we legally force Nucleus (or even better, Creative) to show us their source code? I'm sure that'd offer some clues about getting Rockbox running on the ZV:M.

Just my $0.02.

I thought about that myself (that's why I put that information in the wiki ); but I'm pretty sure a) it wouldn't yield much interesting information (they won't provide any hardware docs) and b) you'll first need to succeed in sueing them which isn't that easy AFAIK.

BTW this isn't off-topic

[mophead740]

Has anyone sent them an email asking for the source code, or are we just assuming that we'd have to sue them?

[mcuelenaere]

Has anyone sent them an email asking for the source code, or are we just assuming that we'd have to sue them?

I have sent them once (and I believe others have done too), but they aren't willing to do anything; so just asking for something will lead to nothing.

And like I said sueing them won't give much either I think as Nano-X is just a little part of their code and it isn't really hardware related so even if they would provide their changes it won't do much good to the port. Although I want to say this is just my opinion, I'm not saying it's a lost cause; if someone wants to sue them I do support it and hope he/she will succeed.

[JQuilty]

If Nano-X is indeed under the GPL, perhaps the Free Software Foundation would be interested in forcing them to release the source code. They've gone after companies for doing so in the past, and won. And since this is giving freedom to DAP's, I'm sure they'd find it very interesting.

They even have an email address set up for this. compliance@fsf.org.

[quetzalcoatl]

heh, now this gets interesting even more
You see, just before going on holiday I've started a opensource project on SourceForge to keep the drive-reader sources easily available, but I wasn't quite sure whever would it be accepted because it might conflict with Creative's rights to the drive structure etc.
Now, if the Creative's OS is based on GPL, so is the HDD driver, so ... may still be a conflict in publishing the Rev-Eng work? uh.. too complicated for me

Fortunatelly the project was accepted and now I'm proud to announce that current sources are available
SourceForge: https://sourceforge.net/projects/nomadrawexplore
CIA: http://cia.vc/stats/project/nomadrawexplore

Currently:
- detects 2 types of minifs (20mb, 50mb)
- only Win32, MFC due to the GUI

The 'core' of the reader:
- is in C++ with Boost 1.35
- has drive:volume(0) hardcoded as minifs
- can list the files contained
- can read a file or its part
- performs all the checks and integrity tests I could think of

-- edit --
I've enhanced GUI a little bit and fixed file-reading to respect the file size as indicated in directory entries. Current svn rev.5 seems stable.

[mcuelenaere]

heh, now this gets interesting even more
You see, just before going on holiday I've started a opensource project on SourceForge to keep the drive-reader sources easily available, but I wasn't quite sure whever would it be accepted because it might conflict with Creative's rights to the drive structure etc.
Now, if the Creative's OS is based on GPL, so is the HDD driver, so ... may still be a conflict in publishing the Rev-Eng work? uh.. too complicated for me

Fortunatelly the project was accepted and now I'm proud to announce that current sources are available
SourceForge: https://sourceforge.net/projects/nomadrawexplore
CIA: http://cia.vc/stats/project/nomadrawexplore

Currently:
- detects 2 types of minifs (20mb, 50mb)
- only Win32, MFC due to the GUI

The 'core' of the reader:
- is in C++ with Boost 1.35
- has drive:volume(0) hardcoded as minifs
- can list the files contained
- can read a file or its part
- performs all the checks and integrity tests I could think of

-- edit --
I've enhanced GUI a little bit and fixed file-reading to respect the file size as indicated in directory entries. Current svn rev.5 seems stable.

Thanks!

I finally got the code to compile under VS2005 (do File->New->Project From Existing Code; enable Unicode, set include dir to ./;../;"C:\Program Files\boost\boost_1_35_0" and set 'Create precompiled header') and it seems to be working pretty good
Nice job!

I haven't found the time to actually look into the code and start making a C version/Rockbox adjusted version for it, but I will in a few days.

edit:
@quetzalcoatl: could you also please publish your notes? Could help in porting the code..

[quetzalcoatl]

The only things you should need are in the NJB folder, the rest is GUI. Oh, and two 'common' .h files in the root directory.

There's plenty of room for simplification/optimization - for single 'jukebox.jrm' file there's no need for cacheing direntries, nor whole bitmaps

Let me know if you need any help in moving to C or in understanding how all things work. I tried to keep everything self-descripting, but while it surely is for me, it might not be for others:)

[mcuelenaere]

...

Let me know if you need any help in moving to C or in understanding how all things work. I tried to keep everything self-descripting, but while it surely is for me, it might not be for others:)

This is as far as I get now, but I'm stuck at the cluster chain's stuff.

I can't figure out what the structure of the cluster chain is, where it's located and how I need to find the data that belongs to the file attached to the cluster..

[GuybrushThreepwood]

Hello to everyone! I'm new and I'm writing here because I'm having some serious problems with the update_extract tool included in the Zenutils package. While on many ZVM 30Gb firmware packages (like 1.50.01 and 1.61.01) it works very well, on many other (like the last 1.62.02) it gives the following error:

Code: [Select]

>update_extract.exe -u ZENVisionM_30GB_PCFW_1_62_02.exe -V
[*] Looking for firmware archive offset...
[*] Printing input variables...
    Updater executable:  ZENVisionM_30GB_PCFW_1_62_02.exe
    Firmware archive:    ZENVisionM_30GB_PCFW_1_62_02_rk.bin
      Key:               34d122FD84fc7CD9143584962572593
      Offset:            0x0005e0c0
      Size:              0x00e91cec
[*] Reading firmware archive...
[*] Decrypting firmware archive...
[*] Decompressing firmware archive...
Failed to decompress the firmware archive.

I've checked the key (it's enough to open the package executable with an hex editor and search for the string 'PAVCString': the key is stored there repeated three times; I think that update_extract checks the key in this way too) and it's correct. I've also tried to specify it by the -k switch but it didn't help. Is this a common problem? I'm using update_extract v0.1, perhaps a newer version exists that solves this issue but I couldn't find either the sources for it (I've instead found the sources for the main libraries it's based on: zlib 1.2.3 for the compression and beecrypt 4.1.2 for cryptography). 
Thanks in advance to everyone for the help!

p.s. Is there a manual way alternative to using update extract to extract the firmware from the package executable?

[mcuelenaere]

Hello to everyone! I'm new and I'm writing here because I'm having some serious problems with the update_extract tool included in the Zenutils package. While on many ZVM 30Gb firmware packages (like 1.50.01 and 1.61.01) it works very well, on many other (like the last 1.62.02) it gives the following error:

Code: [Select]

>update_extract.exe -u ZENVisionM_30GB_PCFW_1_62_02.exe -V
[*] Looking for firmware archive offset...
[*] Printing input variables...
    Updater executable:  ZENVisionM_30GB_PCFW_1_62_02.exe
    Firmware archive:    ZENVisionM_30GB_PCFW_1_62_02_rk.bin
      Key:               34d122FD84fc7CD9143584962572593
      Offset:            0x0005e0c0
      Size:              0x00e91cec
[*] Reading firmware archive...
[*] Decrypting firmware archive...
[*] Decompressing firmware archive...
Failed to decompress the firmware archive.

I've checked the key (it's enough to open the package executable with an hex editor and search for the string 'PAVCString': the key is stored there repeated three times; I think that update_extract checks the key in this way too) and it's correct. I've also tried to specify it by the -k switch but it didn't help. Is this a common problem? I'm using update_extract v0.1, perhaps a newer version exists that solves this issue but I couldn't find either the sources for it (I've instead found the sources for the main libraries it's based on: zlib 1.2.3 for the compression and beecrypt 4.1.2 for cryptography). 
Thanks in advance to everyone for the help!

p.s. Is there a manual way alternative to using update extract to extract the firmware from the package executable?

Hi!

Did you use the ZenUtils from current Rockbox SVN or the ones attached in the wiki?

AFAIK I fixed this problem in SVN..

[GuybrushThreepwood]

Did you use the ZenUtils from current Rockbox SVN or the ones attached in the wiki?

AFAIK I fixed this problem in SVN..

Thank you very much for your fast reply! I've used a precompiled version found here:

http://www.pimpmyzen.com/download.php?list.15

If you can tell me where to get the revised version (even its sources if not precompiled), it would be great! Thank you!

[mcuelenaere]

Thank you very much for your fast reply! I've used a precompiled version found here:

http://www.pimpmyzen.com/download.php?list.15

If you can tell me where to get the revised version (even its sources if not precompiled), it would be great! Thank you!

Yes, those are outdated currently.

The current ones are in utils/zenutils/.
Instructions how to work with SVN are on the wiki; compiling zenutils will need CMake and even more info is in notes.txt.

[GuybrushThreepwood]

Thanks for your advices! Unfortunately, I couldn't use the SVN (it asks for a username and a password and I don't have them). I've tried to use cmake too but it gives me a ton of errors though it's correctly configured. I've manually downloaded update_extract and all of its libraries sources and tried to compile the update extract main.cpp but, even there, I receive another ton of errors though all the includes are where they should be. I'm starting to consider giving up... I'd like to know where I'm wrong...

[AlexP]

You only need to svn username and password to commit.  To check out source you don't need anything.

http://www.rockbox.org/twiki/bin/view/Main/UsingSVN