Quote:
Originally Posted by knob
Wow! that is impressive flasher, did you manage to somehow decompile this file?
|
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.
Quote:
Originally Posted by knob
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. 
|
Quote:
Originally Posted by WIZARD
But it'll be faster to make the simple interface - the same as the player's explorer
|
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.
Quote:
Originally Posted by knob
I would like to implement something like SDL for GDK :- Simple DirectMedia Layer
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.
|
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
SD_CARD.rar
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)