Rockbox Development > New Ports
Creative Zen Vision:M
fejfighter:
no, not yet.
only the boot loader can be changed right now. which then loads the creative firmware
@mcuelenaere
other ideas to get around the cfs problem i had thought of:
instead of finding a method to read it
-getting the usb driver to work then format the drive on a computer
-or write a formatter system into a bootloader for installation purposes.
i think i will lean to try and get the the first one done, if a method of communicating is found.
every attempt i had last night i couldnt get a consistant response from components, at one stage i had scroll up recognised as the hold switch...
keep up the good work,
hopefully i can find something of use!
mcuelenaere:
--- Quote from: fejfighter on December 14, 2008, 07:24:05 AM ---no, not yet.
only the boot loader can be changed right now. which then loads the creative firmware
@mcuelenaere
other ideas to get around the cfs problem i had thought of:
instead of finding a method to read it
-getting the usb driver to work then format the drive on a computer
--- End quote ---
I tried that approach for quite some time, but got stuck. I think the USB driver gets as far as sending some control messages on endpoint 0 and that's it (see this site for more info about USB)
--- Quote ----or write a formatter system into a bootloader for installation purposes.
--- End quote ---
What's the point about having a FAT filesystem if you don't have USB working to put files on it (either through Rockbox or through the OF)?
The OF will get erased by this, and even if you would put the FAT partition at some unused space inside the CFS partition; the OF still wouldn't 1) expose it over MTP because 2) it can't read it and doesn't know about its existence.
--- Quote ---i think i will lean to try and get the the first one done, if a method of communicating is found.
every attempt i had last night i couldnt get a consistant response from components, at one stage i had scroll up recognised as the hold switch...
keep up the good work,
hopefully i can find something of use!
--- End quote ---
You can find the driver here and the datasheet here (ISP1583).
fejfighter:
--- Quote from: mcuelenaere on December 14, 2008, 09:07:34 AM ---
--- Quote from: fejfighter on December 14, 2008, 07:24:05 AM ---no, not yet.
only the boot loader can be changed right now. which then loads the creative firmware
@mcuelenaere
other ideas to get around the cfs problem i had thought of:
instead of finding a method to read it
-getting the usb driver to work then format the drive on a computer
--- End quote ---
I tried that approach for quite some time, but got stuck. I think the USB driver gets as far as sending some control messages on endpoint 0 and that's it (see this site for more info about USB)
--- Quote ----or write a formatter system into a bootloader for installation purposes.
--- End quote ---
What's the point about having FAT filesystem if you don't have USB working to put files on it (either through Rockbox or through the OF)?
The OF will get erased by this, and even if you would put the FAT partition at some unused space inside the CFS partition; the OF still wouldn't 1) expose it over MTP because 2) it can't read it and doesn't know about its existence.
--- End quote ---
i completely over looked that..
i never considered the file transfer that will be required :-[
--- Quote ---
You can find the driver here and the datasheet here (ISP1583).
--- End quote ---
i think i have been looking at the wrong files and datasheets, using the pic instead, i will try the other approach now
mcuelenaere:
I think currently the main thing we should focus on is the CFS file system, as we almost have all pieces of the puzzle, but we just need to fit them correctly.
And whenever we have access to the VFSYS file, we can put a FAT partition on it and use it to boot Rockbox (+ we have the advantage of accessing it over USB through the OF using the Removable Disk Drive option).
Last time I checked, the code was working reliably (I even think I committed (non-working) code to SVN) but there's a problem with getting the different CFS sectors together and to 'merge' them to the FAT file system (at about p.42-43 at this thread you can read a bit more about it).
Aurix Lexico:
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?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version