Creative Zen Vision:M

[mcuelenaere]

I committed a small part of the patch now that seemed clean and not likely to cause troubles for anyone else.

Some parts of the remainder of the patch seems to modify stock dm320 code that isn't clean enough to commit. And then I'm not sure how valid the firmware/target/arm/tms320dm320/creative-zvm parts are.

Comments?

I just want to help getting the core vision:m stuff added so that more people can join in this effort and help easier.

The only DM320 stuff I changed are in system-dm320.c (which I've enabled back since it doesn't cause any trouble) and in spi-dm320.c (which sets M:Robe 500 target specific GIO stuff and disables GIO stuff using spi_disable_all_targets() which isn't present at the ZVM and shouldn't be touched)

The main code at the moment is just for debugging purposes as I only have access to the LCD for now. As for the target/arm/tms320dm320/creative-zvm/ : these are just stubs so that Rockbox can compile (I haven't enabled these during boot in the bootloader).

[Bagder]

The only DM320 stuff I changed are in system-dm320.c (which I've enabled back since it doesn't cause any trouble) and in spi-dm320.c (which sets M:Robe 500 target specific GIO stuff and disables GIO stuff using spi_disable_all_targets() which isn't present at the ZVM and shouldn't be touched)

Right, but those changes are unconditional and thus I don't dare to commit them since all I know they make cause trouble in the mrobe 500 camp.

As for the target/arm/tms320dm320/creative-zvm/ : these are just stubs so that Rockbox can compile (I haven't enabled these during boot in the bootloader).

Well, if they are truly only stubs I would rather see them as stubs only and then I wouldn't mind committing them. Atm it seems like lots of leftovers from other parts that you probably used as basis when you copied these from elsewhere in Rockbox.

I'm not really complaining, I'm just explaining my reasoning why I didn't commit more files (yet).

[mcuelenaere]

Right, but those changes are unconditional and thus I don't dare to commit them since all I know they make cause trouble in the mrobe 500 camp.

Ok, you're right about that; that wasn't entirely clean.

Well, if they are truly only stubs I would rather see them as stubs only and then I wouldn't mind committing them. Atm it seems like lots of leftovers from other parts that you probably used as basis when you copied these from elsewhere in Rockbox.

I'm not really complaining, I'm just explaining my reasoning why I didn't commit more files (yet).

I don't say you're complaining

Anyway, here's my current diff (no need to commit this one, it's just for possible other ZVM porters?)

update: added new diff

[Falafel]

Hmm, are you using the compiler from TI or uhm, well gcc-arm? Because I want to start taking a look at how I might use the code for my ZV

Btw. Awesome work!

[mcuelenaere]

Hmm, are you using the compiler from TI or uhm, well gcc-arm? Because I want to start taking a look at how I might use the code for my ZV

Btw. Awesome work!

The only thing you should have is a copy of Rockbox SVN patched with my latest diff.
Then configure your build for Creative ZVM and bootloader.
Then you'd have to make a CIFF file (I advise you to use CreativeWizard): choose for the Zen Vision and add a DATA block with the rockbox.zvmboot; upload this to your player and normally this will work (although it will look distorted on your player due to the other screen dimensions I presume)

edit:
if you want some kind of input on the device, the following code will detect if the USB is inserted (other input hasn't been figured out yet atm):

Code: [Select]

inline bool usb_detect(void)
{
    return ( (*((volatile unsigned short*)(0x60FFC018))) & 0x100)>>8;
}

[Falafel]

edit2: I'm trying to compile a bootloader, but I'm getting: 'ERROR: x uses FPA instructions, whereas y does not'
and other linker errors

edit3: found it, apparently -mcpu=arm926ej-s should be -mcpu=arm9 (or at least on my machine)

Hmm, I have the same errors here, but if I change arm926ej-s to arm9 in the makefile, it'll only change to even more errors saying ERROR: X uses VPF instructions, where....

And I'm kinda at a loss as to why this is so.

Edit: Ahem, I just gave up trying under Linux and lo and behold: cygwin compiles it instantly.. Now just see if I can get it on my Zen.

edit2: I'm afraid I can't check if it works because the firmware maker gets all sizes wrong...

[Bagder]

edit3: found it, apparently -mcpu=arm926ej-s should be -mcpu=arm9

Hmm, I have the same errors here, but if I change arm926ej-s to arm9 in the makefile, it'll only change to even more errors saying ERROR: X uses VPF instructions, where....

Did you guys build your arm-elf toolchain with the rockboxdev.sh build script?

[mcuelenaere]

edit2: I'm afraid I can't check if it works because the firmware maker gets all sizes wrong...

What do you mean by 'the firmware maker'? Scramble? CreativeWizard?

Did you guys build your arm-elf toolchain with the rockboxdev.sh build script?

Now I did and the problem is resolved; thanks!

[Falafel]

What do you mean by 'the firmware maker'? Scramble? CreativeWizard?

Oh yeah right, that's kind of ambiguous.. I meant Creative Wizard.

Edit: Here are the files, perhaps you can see what went wrong? The exact steps I took were:
Choose player AKA adding a cinf block,
Add data block, 'use file instead of data',
Then create firmware, but it gave me many errors about blocks not being named. (This could then be remedied by clicking both blocks again)
Followed by the nice messagebox asking me if I want a Nullblock, which is ,of course , what I want.
But it doesn't seem to work.

rockbox.zvmboot
hacked_093204.bin
Ps. I downloaded the latest one from epizenter, but there was no source code so I couldn't look into the problem myself.

[mcuelenaere]

Oh yeah right, that's kind of ambiguous.. I meant Creative Wizard.

What problem did you get?

The normal procedure is 'Make firmware'->'Select your player'->...->'Add block'->select the newly added block->change data type to 'DATA'->check 'Use file instead of data'->type 'Hjukebox2.jrm' in 'Filename' textarea->choose the file->press 'Create Firmware'->press 'Yes'->press 'OK'->in main window 'Upload Firmware'->choose your firmware and upload it to your player

Maybe you should update CreativeWizard to a newer version?

[Falafel]

  Forgot to add 'Hjukebox2.jrm'.

It Works!!

The prog only use the upper left corner of my screen but still!

[LambdaCalculus]

Falafel, can you snap a picture and show us what it does?

[Falafel]

Sure,

Bureaublad.rar

I think its because ZV uses a different memory address to map the lcd to.. But I haven't checked yet.

Edit:
Where do you set LCD_HEIGHT and _WIDTH?

[mcuelenaere]

Edit:
Where do you set LCD_HEIGHT and _WIDTH?

firmware/export/config-creativezvm.h

edit:
after seeing the photos, I would say also check lcd_init_device() in firmware/target/tms320dm320/creative-zvm/lcd_creativezvm.h;

more specific IO_OSD_OSDWIN0OFST (the format is (LCD_WIDTH*bpp)/256 )

[Falafel]

more specific IO_OSD_OSDWIN0OFST (the format is (LCD_WIDTH*bpp)/256 )

Hmm, but what exactly is it that this does?
I mean, I've changed it a bit and my screen gets garbled.. And if I set Height and width to 480x640 (because of the portrait-mode) it fills the screen almost, but it still misses a piece on the right side if I hold in the ZVM way. (too bad I have to go, because now I don't have time to take pictures)