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

Looks good now. Would it be able to handle a slightly bigger font than the 16 size do you think? say 18 or 20, I think it would look even nicer. ;)

Regards
knob

Of course, you can load as many fonts as you wish, different sizes, faces, styles. My drawing function just require offset to the resource file where the binary font is stored. I made a special format for this font, to speed up the loading. I will release a tool for converting fonts into my format (is 99% done). Though it's not native. It converts exported font from AngelCode Bitmap Font Generator (a freeware tool which generates bitmap fonts from system TrueType fonts). In my tool you just open exported font, and it creates one bin file which you can add to RKP resources and its done.

I created this thinking of RTF reader where I could convert a bunch of different fonts and sizes so there will be no problem for displaying formatted text - while I change the offset to different font it will draw it as normal, without any special config (all necessary info is stored in binary font ex. widths of chars, line-height and such).

This application is faster than the embedded image viewer! :o

Possible improvements: scroll bars, the ability to open folders;
and (maybe) the ability to select the image files and open them -
it'll be the good base for document viewer's dialog.

Yes, that's what I am working on :-) I want to release really well working package as a good start for developing fully functional applications. I just need a little more time and I will upload it here on this very site. I know my first challenge in this will be RTF reader, I hope that other people will also find it interesting and use it in creating their own apps ;-)

I hope this patch will helps you:
***
C:\Program Files\RockTools\RockCompiler\sdspI\bin>fc /b sdopt.exe.bak sdopt.exe
Comparing files sdopt.exe.bak and SDOPT.EXE
0001FEE0: 55 90
0001FEE1: 8B 90
0001FEE2: EC 90
0001FEE3: 51 90
0001FEE4: 51 90
0001FEE5: 8D 90
0001FEE6: 45 90
0001FEE7: F8 90
0001FEE8: 50 90
0001FEE9: FF 90
0001FEEA: 15 90
0001FEEB: 10 90
0001FEEC: 52 90
0001FEED: 4A 90
0001FEEE: 00 90
0001FEEF: 8B 90
0001FEF0: 45 90
0001FEF1: F8 90
0001FEF2: 8B 90
0001FEF3: 4D 90
0001FEF4: FC 90
0001FEF5: 6A 90
0001FEF6: 00 90
0001FEF7: 05 90
0001FEF8: 00 90
0001FEF9: 80 90
0001FEFA: C1 90
0001FEFB: 2A 90
0001FEFC: 68 90
0001FEFD: 80 90
0001FEFE: 96 90
0001FEFF: 98 90
0001FF00: 00 90
0001FF01: 81 90
0001FF02: D1 90
0001FF03: 21 90
0001FF04: 4E 90
0001FF05: 62 90
0001FF06: FE 90
0001FF07: 51 90
0001FF08: 50 90
0001FF09: E8 90
0001FF0A: B2 90
0001FF0B: 37 90
0001FF0C: 00 90
0001FF0D: 00 90
0001FF0E: 8B 90
0001FF0F: 4D 90
0001FF10: 08 90
0001FF11: 85 90
0001FF12: C9 90
0001FF13: 74 90
0001FF14: 02 90
0001FF15: 89 90
0001FF16: 01 90
***

Try to use :

DSTATUS disk_initialize (BYTE disk)
{
write_mem(CLOCK_PWRCON,read_mem(CLOCK_PWRCON) | 0x4);
printf("disk_initialize(%d)\n",disk);
return RES_OK;
}

before work with SD

I used that mem addres for this:
#define RUN_FROM_SD (read_mem(CLOCK_PWRCON)&0x04)>>2
if run from sd, its value is 1, if from flash its 0.

What does your function do? Because all I need is to check from which drive it has been initialized (and my function above does it). If from flash, it shows my warning message or something like that

btw, what does this patch do? It takes off the license check or something?

I have commented this condition and LFN are working in my sample

file ff.c :

#if _USE_LFN
if (fno->lfname) {
TCHAR *tp = fno->lfname;
WCHAR w, *lfn;

i = 0;
if (dj->sect /* && (dj->lfn_idx != 0xFFFF) */ ) {/* Get LFN if available */
lfn = dj->lfn;
while ((w = *lfn++) != 0) { /* Get an LFN char */

It replaces function time() to NOP's :)

oh maan. It works now!! It can access SDCard while being executed from flash! If only we had access to flash memory we could even transfer files between these two drives.

Also, it runs so much faster if run from flash! Awesome, you re good. Maybe you have some ideas about flash memory then?

I tried. I can read pages from the flash, but I do not know structure of the flash drive ( numeration of sectors , begin of the FAT , e.t.c).

This function is reading page from flash ( I have hy27uu08ag5m , but it is the common command for all NAND-flash ):

void readPage(unsigned int col,unsigned long row)
{
int i;
write_mem(FLASH0_CMD,0x0);
write_mem(FLASH0_ADDR,col & 0xFF);
write_mem(FLASH0_ADDR,(col >> 8) & 0x0F);
write_mem(FLASH0_ADDR,row & 0xFF );
write_mem(FLASH0_ADDR,(row >> 8) & 0xFF);
write_mem(FLASH0_ADDR,(row >> 16) & 0x03);
write_mem(FLASH0_CMD,0x30);
printf("\n");
for ( i = 0; i < 2112; i++ ) {
buff[i] = read_mem(FLASH0_DATA);
}
}

The first page that I have read from flash was a part of firmare with some offset.

Wow, its great! You're genius!

Awesome
 

New breakthrough! :rolleyes:

Break on through to the other side! Nice!
This is rk26xx related, isnt it?

I used that function to read flash data, it works, though I had some problems. When I set up the FatFS lib for this, it showed me some weird filenames in the root dir (sometimes I get those names even with embed explorer, which needs a restart or reformat of the drive). Also we need to figure out where the offset of flash drive is written. I wrote a function which scans flash mem looking for fat file system, though it took 15 minutes to find it - getting through 14mb of FW data.

Yes, right.

EDIT:
Small piece of work regarding open dialog.
Attachment 528
look how extremely fast it draws graphics.

15 min of waiting - every time when you want to open/save the file :(
Though, it's better than nothing! :rolleyes:

EDIT:
This open dialog is nice! However, I can't open anything :p

Yeah, its incomplete.

Coming back to this flash memory. Is there someone who knows where in the FW data the total FW size is coded? it must be somewhere, like this tool for creating themes for rk26 knows exactly where bmp resources begin in the RKW file.

This is nice work, flash.
sig11 has done a file manager too.

try looking at the source from dancemammal editor, it's in delphi.

http://mympxplayer.org/dancemammal-m...030-df882.html

I'll check it, thanks.

BTW. Do you know how to hack memory flash in rk27? I still got one of these with one 4gb chip broken. I got 4gb of usable capacity while other 4 is dump space. How to format it to appear to be 4gb partition instead of 8gb? Those guys from ebay did that so it must be possible.

Never had the memory hack problem myself.
Someone here has fixed a Rockchip memory hack:-
http://mympx.org/forum/support-how/4...4-players.html
but not sure which version it refers too.

btw have you had issues with do,while() and printf() with the rk26xx Sdk/Gdk?
I've been looking at porting again and had some problems with bugs in the SDK.

Hm, I tried that, and it didn't work. Mainly because its not a hack right now, but broken chip which is being detected during firmware upgrade. At some point during FW update, it gets into Rock USB mode and there information about partitions are being transmitted.

I am using while() all the time. Also sometimes sprintf (for converting decimals to strings) but printf doesn't work for me. I am curious how sig11 is using printf (have you introduced some nice console?).

Though whole SDK is very buggy. btw sprintf doesn't support long data type. This function acts like it was signed int then.

You should to implement two functions fputc() and fwrite(). After this your prinf() will be work.

int fputc(int ch,int handle)
{
if ( ch & 0xFF )
outch1(ch & 0xFF);
if ( ch >> 8 )
outch1(ch >> 8);
return 1;
}

int fwrite(const char* buff,int isize,int count,int handle)
{
int i;
int j = count;
while ( j > 0 ) {
for ( i = 0; i < isize; i++ ) {
int ch = *buff;
outch1(ch & 0xFF);
outch1(ch >> 8);
buff++;
}
j--;
}
return count;
}

where outch1() is your function for output of one char.

My console driver is not ready yet ( cursor is missing, 8x16 font only, CP866 only, no UTF8 support e.t.c. )

That great! thanks.
I have been trying to emulate the conio.h functions like clrscr(), gotoxy() getch()to make game porting easier.

I was having problems making a while loop work for a getch() to emulate an operation like "press any key" I'll give it another try.:)

tried this instead of while:-

int KeyVal;
KeyVal=(*GetKeyVal)();
KeyVal=KeyVal&0x1FFF;

for ( ; ; )
{
if (KeyVal==KEY_VAL_PLAY)
break;
}
player just locks up, got something to do with detecting the keypress.

Use this instead of (*GetKeyVal)();

#define KEY_PORT GPIO_PDAT0
unsigned int getKey()
{
unsigned int KeyTemp;
KeyTemp = read_mem(KEY_PORT);
KeyTemp = ((~KeyTemp) & 0x3f) | (KeyTemp & 0x40);
return (KeyTemp);
}

(Sorry for my bad English)
Does this means that we are going to be able to run an app that can read files from FLASH ???

it looks up because it causes an infinite loop because variable KeyVal doesn't change no matter what happes with (*GetKeyVal)() as the result of this function is assigned to KeyVal before the loop. You should use (*GetKeyVal)() inside the loop.

Another problem with that is that if a one cycle of main() function tooks too much time, it locks up no matter how properly it is designed. In my case it keep hanging after about 2 seconds of executing main(), so this function must hang. Try to do this using multiply main() function variable dependent loop which will work for sure. Its because main function is executed directly by FW code every single time, and between those calls to this function it does some necessary operations (not sure what exactly though). For instance screen doesn't get refreshed before one cycle of main() is executed. If we draw a bitmap, it will be displayed only after main() function is ended.

But normal use of "getch()" or "repeat until keypressed" (pascal) is as far as I know impossible to implement. We must follow tricks to do that, because to be honest, when I first met RKP platform I was surprised by the way its all running (infinite loop of main function - in opposite to normal console app where main is executed once and thats it.

For now we can only read RAW data of flash memory, but implementing filesystem is possible, so probably yes - it will be possible to read files from flash - not sure about writing though, but who knows

SIG11. But isn't your function reading values only from standard button input? I got touchpad, so most probably (*GetKeyVal)() is something that should be left original way because it may be written differently - depends on used input keyboard driver in a particular rk26 model player.

That makes perfect sense, it is exactly the problem I have had, nothing gets displayed on screen, when logically it should.

Keeping this in mind, I will have another go at this, thanks again, flasher. ;)

yeah no problem. I discovered that thing while doing some animation. I was going nutts figuring out why it gets displayed only last frame of animation (as it refreshes screen after main function). About this refreshing screen, it can be done inside our code manually. I even started to wonder whether it will be more effective and optimal to display everything at low level (uploading display buffer directly to the screen driver memory, but I havent given a shot yet).

BTW. Open Dialog is almost done. Going into directories works, as well as coming back up level, also I introduced icons (in the sd card there must be icons folder in which icons in bmp format are stored and named like extentions of files ex. txt.bmp, gif.bmp and so on). Now I am trying to make scrolling of the filenames longer than possible to display in a row. Next will be filtering filelist only to files that we are interested in, and its done.

Try attachment.
Does it work on your player?

It shows START...
I press some key and it shows some number just below it (66 or 64?), then there are some messages and "Press any key to continue" text. After that nothing.

I don't know if this suppose to continue after some key is pressed but it stucks here(no quit possible). Also I noticed that backlight of my touchpad is always turned on in your application, while by default it turns on when I hit the button and turns off about a sec later. So I don't think that it should be used - it interfere custom input driver.

Beside that, its amazing how your console works. I like it!

EDIT:
I downloaded file manager from your repository, and it doesn't get stuck before init, but keyboard isn't working on my player. It acts like it was always the same button. Waiting for a new version so I can test it. It looks nice.