Click in the nick column to highlight everything a person has said.
The icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

linusn, i've written a libdumb plugin which works fine on the h300 for disk writing, but when i try to get actual audio output with pcm_play_data(), rbx crashes with "illegal instruction" after a few calls to get_more()

WTH does timers.c:timer_register take a number of cycles (rather than a number of ms or us), but also automagically scales the timer when the CPU frequency changes, thereby changing the number of _cycles_ that the timer is running for?

the thinkg that wants to load the bmp will need to allocate ram for it on its stack (which will be a defined size for bmo loading), then it calls the loader which will use more than nescacery but once its returned that usage will be dumoped

JdGordon: I've just read the logs and I don't understand what you are asking about maximum bitmap size. Your bitmap loading function should take a pointer to a buffer and an integer containing the size of that buffer, and refuse to load anything larger than that buffer.

The idea of having the WPS bitmaps combined into one bmp file is that you load the entire bitmap into a buffer, and then your wps tags specify which parts of that bitmap are displayed where in the screen.

maybe im not being understood properly? plugins or whatever says "i want the rect 14x10 px sarting at (5,0) from some_pic.bmp... it passes a pointer to the stack which is the correct size of the rect being asked for.. the loader then fills it with the rect and every1 is happy...

There could be some cases where a load_color_bitmap_part() function may be useful. But the main use of your function will be for the WPS, and for that, we just want to load the whole of a single bitmap and use it in parts.

Nice excuse from iriver about missing features in their new h100 firmware: "Certain functions that were originally intended (Korean menus, OGG Lyric support, etc.), we endeavoured to include, but unfortunately we could not, due to hardware limitations. We ask for your understanding."

mirak: That made more sense on the Archos devices where mp3 playback is effectively done in the firmware, but I'm sure that will be moved to apps/ at some point - probably if/when the Archos and iriver playback engines are merged.

preglow: that's all the support code for profiling, in theory all a dev would have to do woudl be turn on -finstrument-functions in their code, and stick calls to profstart and profstop around the time to be executed _on the same thread_ as the code to be executed.

preglow: I switched from -pg to -finstrument-functions for how to activate it, so any code compiled with -finstrument-functions and running on the same thread as the thread where profstart is called will be profileed

Mindship-02: I think you're referring to my suggestion, which was to store the bitmap in the source as a .bmp file (instead of as a .c file as it is currently). The Rockbox build system would then convert the ,bmp file to .c when Rockbox is being compiled.

preglow: -pg turns on the whole profiling arch as designed for 'large systems' meaning it depends on the kernel to maintain the tic counts on a per-PC basis, -finstrument-functions _only_ adds __cyg_profile_func_enter and _cyg_profile_func_exit calls to the functions

linuxstb: I think I can oversee the process of doing so, but regarding the time it would take me to do one or the other, and, too, moving the splash to a file will be a structural time-saver for everyone who ever wants to change his splash...

Mindship-02: Assuming you can use a text editor, and can type in one command at the command-line, it will take you about 2 minutes to change the .c file containing the bitmap. I would be happy to talk you through it.

linuxstb: I'm doing my exams next week. When I start fiddling with Rockbox now that would mean I am going to focus on all that has to do with that. I will ask you someday later on next week if you have time (ofcourse, I will try to impress you by doing it myself first!)

I'm building a minimal support environment around the codec to allow it to run as a linux app, statically compiling it against uclibc and then running it on a linux userspace m68k emulator.. I'm halfway there..

Ahh.. but it's an emulated coldfire.. therefore the only thing I'm missing is memory wait states and cache fetches.. if I can use more cycle efficient instructions, less of them and other basic optimisations it does not matter where I run it.. we still win..

No, it's actually an emulated coldfire.. so it's correct instruction for instruction.. the actual binary is compiled using m68k-elf-gcc just the same as rockbox, and therefore the resulting binary and *.s asm code is identical

Well, this simpulator is supposed to be an accurate simulation of the coldfire.. but it's dead easy to modify to add instructions/registers in if required.. I have already spent enough time not to give up easily :)

i'm playing with writing a plugin, so i've written a simple app in C, now how do i compile my plugin so i can test it in the emulator and on my device? i'm new to cygwin... anyone willing to give me a step by step instruction?