Rockbox Development > New Ports
Creative Zen Vision:M
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:
--- Quote from: quetzalcoatl on August 18, 2008, 04:08:26 AM ---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.
--- End quote ---
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:
--- Quote from: quetzalcoatl on August 18, 2008, 03:50:21 PM ---...
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:)
--- End quote ---
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: --->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.
--- End code ---
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?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version