I'm just guessing here. but did you try swapping or modding the .lcf from the "RK2608_SDK_DEMO" firmware?.

Never done anything with this myself, just a thought.

btw tested the SDCARD.rkp, listed files ok, but only 8.3 dos filenames. Long filenames should be do-able have you looked in the firmware source for any ideas? maybe browser source.

I'm just glad it works on your player anyway, it means that this library runs ok on rk2606a (mine) and rk2608 (yours) players as well (I must mention that there is a dozen of similar libraries in both SDKs 2606 and 2608 and this is the only one that works for me).

As I said, long names can be done, unfortunately support for file system doesnt work from SDK so I implemented this FatFS opensource lib for this. There are two versions of this, one pffs and ffs, the first one is optimized in code and in memory but it doesn't give long names, the second one also works and it gives long names but the size of the code is 3 times larger and it takes 3 times more memory which we have very little. Maybe we can mod this pffs to add long name support without getting so much of code.

I didn't go into *.lcf from SDK because it has different structure, and also we cannot rearrange basic memory regions which are devoted to platform pointers to functions. I will keep trying to squeeze everything and then I will upload some blank project for everyone with all the necessary libs included.

BTW, maybe I am wrong but, I think that the whole RKP code is loaded into IRAM before execution? In a way that it's not read from disk while executing next part of code but all at once.

EDIT:
Do you have some ideas how to arrange Open and Save dialog? I am just asking about graphical placement, as I think we should make those dialogs universal for all such apps. Perhaps something to prepare in photoshop. Also, I am going to introduce new font, different kind of fonts, maybe even run-time antialiased so we can create a nice opendialog box with alpha transparency, antialiased fonts and so on ;-)

Not the end of good news guys :D I cut into pieces RK_MLC_USBFS_SD.A this lib and elicited only those functions that are necessary to access SDCard. It reduced the code size and memory dramatically. Also I am thinking that maybe we can do the same with flash memory driver. I didn't succeed with flash because there was too much of the code to put into the memory so it always kept hanging, but perhaps it will work if I remove all the unnecessary functions from this lib and leave only I/O low level access to nand flash. Two versions may be needed though (SLC and MLC).

If it will work, it's great! Not only because of the full access to the files, but also it will be possible to make a backup of the firmware using RKP app.

If the firmware was extracted then we would have to rebuild the .rfw to reflash with consumerUpdate.

The only way I can think of doing this would be to split the extract to create an .out file, a picture resource file (.uis) and a text menu resource(.meu), so in addition it would need an additional utility I think to do this, but it would be worth the effort I think.

The only way I know of to generate a .rfw is FWTools.

The same thing.
Press the (Alt / Option) M / >|| / AB button to start the navigation through different commands
http://img158.imageshack.us/img158/4251/picture5z.png

But it'll be faster to make the simple interface - the same as the player's explorer

Wow! that is impressive flasher, did you manage to somehow decompile this file?

Regarding a file open dialog, I think it would be best to do something similar to what the firmware already does to select files, in other words like the browser screen a simple text list that fills the screen and just select the file you need using the direction arrows and choose with the play button, just to keep it simple and easy to operate.:rolleyes:

Regarding a save dialog, do we need one at all? sure the option to save is needed for things like updating a configuration but I think that's about it.;)

I would like to implement something like SDL for GDK :- http://www.libsdl.org/index.php
this is used for things like the gameboy and to create emulators etc, but it would probably be a bit too much to make this work with the GDK.

Actually, it wasn't that hard, there is a tool for splitting archives called sdar inside rock compiler. I just deleted all the rest of the stuff that is useless - I left only sd.obj and interface.obj, also added a new mine *.obj for some of functions that were also in that library, but adding them would cost too much, so I rewrote them to make it as thin as possible.


I am thinking the same. We need something similar, and I already started to experiment with this. The problem is, we have only 0x5000 (20480) bytes for the whole code of RKP application. It seems that if we run an rkp app, its loaded into IRAM as a whole (excluding resources), so we are limited. Speed is not a problem then, but simplicity in the code.

And thats my problem, I used to don't worry about the size of the code or memory as I am mostly Delphi programmer.

It would be nice, but I think that including this lib in the rkp project will eat 90% of available memory > see section *.text in LCF file.

I tested how much of memory does this file support takes and I came out with 0x207C bytes, so 40% of memory is gone by now, with an empty app. (maybe I will manage to shrink this FatFS lib even more, as I noticed some useless functions).

To omit this memory problem, and create real kick-ass apps we need someone who knows how to reload some parts of memory while rkp is running. Something like creating libs and splitting it into external files, and loading them if it is necessary to use such a function. So we would exchange currently loaded lib with another one. This way we can have the code as big as we want.

Anyway, here is what I've done so far:

• It contains improved fatfs with long file name support (though I limited it to 18 chars just for now).
• I wrote BMP decoder for obvious purposes (16bpp, 24bpp and 32bpp alpha transparent bitmaps are also supported, I didn't wrote decoder for 8bpp bitmaps because it takes too much of the code and memory to load palette and so on, surprisingly, 24 and 32bpp bitmaps loads faster than 16bpp which is the native of the screen). Note: Maximum width is 320 for 32bpp bitmaps. Wider will overload buffer and hang.
• Antialiased font (I converted Calibri 16)
• Detection of the drive which the RKP has been executed from, if it is loaded from flash memory, you'll see some custom message, so no hanging anymore.

Inside the package, rkp file, picture converter (PNG > BMP 32bpp), and sample bitmap.bmp

Attachment 525

To test drawing bitmap you must place a file called BITMAP.BMP in the root dir and press MENU button. (PLAY button exits the app)

My player locked up at first try.

Realised I'd got some files with names longer than 18 chars on my miniSD, reduced them and it's now working fine!

So flash, you finally have success with file loading by .rkp. congratulations!

The font looks great also, out of curiosity tried it out on the main flash memory and got the warning message as expected, this is really good stuff.

You already have most of the components of a picture viewer application.

What names exactly did you have, so it locked up? Maybe it wasn't about the length but about unicode characters? They will be supported. Because I also have very long names on my SD card, but in my case they were just cut off. Could you copy and paste the name of a file that causes hanging?

------------------
EDIT: I figured out why your player had locked up. My function for drawing text was awfully slow! And if executing one cycle of main function takes longer than 2 secs it locks up. Before to draw one full line of text took 245ms! But I optimized this function and now its only 38ms :-))
------------------

BTW. Do you know how big SDRAM is in those players? If big enough then it will be possible to speed up the interface: scrolling file list, and such.

New update of my tests:
Attachment 526

- has background, it is more visible how alpha transparency works, as well as antialiased fonts.
- scrolling of the whole list of files using up/down buttons
- here you also can hit menu to load bitmap.bmp (one sample 32bpp included in package)
- unicode works
- faster drawing of chars. Surprisingly antialiased font is not slower than the standard one as it suppose to be. I even managed to make it faster than standard platform 1bpp font by loading the binary font into SDRAM and accessing it from there instead of the resource file.

this scrolling works similarly to the one from firmware, though I think I will make something more smooth, like preloading into SDRAM the whole bitmap in which the file list had been drawn, this will enable to extremely fast and smooth pixel by pixel scrolling of the file list, not file by file like this.

EDIT:
I've noticed something great!! By default rock compiler does not use auto optimization (there are 3 options), but only one option really optimize it, and its nr 2, but I didn't use that because I got message that licence has expired, just out of curiosity I changed the system date to test this optimization, and it really stunned me! Length of the code has been reduced from 0x365a to 0x1cc2. Maximum allowed is 0x5000 so its amazing! I feel like a dumbass worrying about every single byte of code. We can do so much :-D