Rockbox

oops - the file moonrock.dat does not upload..

I have included it here split in two:

on linux systems:
cat moonrock.dat.aa moonrock.dat.ab > moonrock.dat
fixes the data file…

   moonrock.dat.aa (1.91 MiB)
   moonrock.dat.ab (1.39 MiB)

I don't understand the #define LINEBUFFER 320?

What's the reasoning behind the value 320?

I noticed that the read in of the bmp was limited to the target size. I increased it from LCD_WIDTH because 320 is the widest of any target (I think), then you can read in this size and scale down bmp with smooth_resize on other targets. (this could be a often occuring use of resize). (the dat file actually is patched together bmp)

The M:Robe 500 has a 640x480 screen. I really don't think we want to allow this size for all targets.

hmmm, I see.
It is worthwhile, though, to consider increasing the size allowed by the buffer in the read_bmp routine.
(also, the buffer is for one image line: the penalty is not the full image size)
Is there another way to read in bmp with sizes bigger than the screen?

Seems simpler to just pre-generate bitmaps, use Rockbox' bitmap build system, and use LCD_WIDTH for LINEBUFFER.

use of pregenerated bitmap is limited by the plugin memory, 512 Kb I think..

btw, I guess one could adapt the read_bmp_fd file to read blocks of limited size (=LCD_WIDTH),
but repeatedly, along the lines of the included patch.

   lcdwidth.patch (9.2 KiB)

I tried to re-sync the patch.
It's possible that all the affected files but moonrock.c are ok.
moonrock.c it seems to be too much far from the actual svn sources, so I'm not able to re-sync it.
Any volunteers?

   plugins-9270moonrock.2.0.patch (17.4 KiB)

I tried to sync moonrock.c. it showed something but i don't know this is valid chage.

   moonrock.2.0.patch (17.8 KiB)

Great! It works nice. Thank you.

Sync to r23223.

   plugins-9270moonrock3.0.patch (17.7 KiB)

Hello,
ok, I was able to apply the patch for the current release and it seems to work so far and nicely.
But you should mention, thet the patch has to be applied from the /rockbox/-Project directory and has to be run with the -p0 parameter.
I had to copy the moonrock.dat manually to the /.rockbox/rocks/apps-directory on my player to see the moon picture. Is that correct?
I am very interested in further development of this rock. I plan to do some extensions of displaying the calculations.
More soon (tonight?)

Hi Marek,

that is correct - the picture data is relatively big so had to come seperately
(lately a png decoder has been added to rockbox, so this may be improved)

note also: since syncing to r23223.(but maybe earlier) it may corrupt
music playback (after pausing music after running the plugin), so some
debugging/improvement is definitely needed….

cheers..

Hello,

so far it runs. I've started to investigate the source and going to add some more informations since I am very interested in astronomical calculations
Here a very quick and dirty screenshot with dummy placeholders, but you should image what it does mean.
The main problem at the time, that the Rockbox-Time handler does not (?) have got an informations about time shift or time zones, but astronomical algoriths usually need at least UTC for reference.
My proposal as a workaround would be to add a .moonrockrc (run command) file where e.g. the UTC shift and font-size could be stored.
What do you think about? Are you interested in?

Regards, Marek

   dump 091231-011707.bmp (75.7 KiB)

hi,

looks nice!
yes, at the moment the plugin assumes that the time zone is GMT - so time zone info would be necessary - ideally this would be something settable within the plugin..
I wonder if it's a big deal to include this in the firmware time struct….

Hello,

here some more hacking effort:
* implemented UTC shift by means of julian time conversion
* implemented calculation of easter date
* implemented output of week day names and moth names
The source code needs tidy up and optimization, hat to write some own functions or workaraound, since a lot of simple mathematical functions like modf are not (?) implemented to Rockbox compiler, therefore the orgies with the castings.
Runs on Simulator for Sansa e200V1, can not compile for hardware so far

Ho to apply this patch?
First apply plugins-9270moonrock3.0.patch from above. Run it from the /rockbox project directory with -p0 parameter
Then cd /apps/plugins and apply my patch. It works only on moonrock .c, do not forget to backup it with -b parameter.
run make. run make install to your simulator or copy the firmware to your player. do not forget to copy moonrock.dat to apps/plugins directory.
Ok, for the rest of the evening, let's celebrate year's change!
Regards

   Unbenannt.png (29.8 KiB)
   plugins_9270_moonrock_3.4_200... (16.1 KiB)

Ok, a little more improvement. Use the following patch to patch the previous plugins_9270_moonrock_3.4_20091231.patch.
Should compile on Simulator and Hardware. Added a function to print double numbers in strings, since the platform compiler does not support double output in snprintf.
Still looking forward to implement phasehunt and prediction of next phases.

   plugins_9270_moonrock_3.4_201... (7.6 KiB)

I have created a new, cleaner version using some of the functionality that has been added to rockbox since I last looked at this!

It now uses the view text and jpg functions from the lib.

apply patch from root with patch -p0 < moonrock_21082010.patch
and copy the data file to apps/plugins/

I have put in Marek's ideas, except the easter dates calculation, can be added later…

the patch still changes 1 little api thing: it adds the set_time_screen, function for an easy dialog to obtain new dates.

   moonrock_21082010.patch (27.6 KiB)
   moonrock.dat (251.5 KiB)

oops - forgot the CATEGORIES file…

   moonrock_21082010.patch (27.9 KiB)

Synced to SVN r27875 (made compatible with kugel's latest plugin changes)

   moonrock_24082010.patch (27.8 KiB)

Sync to 30189.
My .dat file seems to be broken when I run the plugin: I need to check.

   9270-plugins-Moonrock_calcula... (27.6 KiB)

Rosso:

have you checked the version of the dat file (you should use the approx 250kb one)?

(haven't had a chance to try latest rockbox)

Ops, I had not notice the new file .dat.
But not it data aborts.
The file is not a "normal" jpeg image, is it?

Sorry, I want to say: "But now it crash with data abort".

I (as a rockbox developer) am in favour of getting this plugin accepted into rockbox. I haven't looked closely at the coding style, but it looks fine to me (except for some indenting inconsistency).

I have checked using the x5l simulator - fresh chechout, applying the latest (22/7) patch, copying the dat file to apps/plugin in the source
then make. It seems to work - does it exit the plugin or does it give an error ("no image data") and go into main menu?
(the dat file is combination of jpg files and data)

I would be happy if it went into the trunk!