On Sun, 12 Feb 2006, Thom Johansen wrote:
The sim used to be able to be built in MSDev, but not anymore. However, the
SDL sim _should_ work fine in MSDev after you've set it up (assuming no
Cygwin/UNIX specific functions are used).
I'd be very surprised if that worked without a sufficient
gl wrote:
Just not maintained, and it was for the old Win32 build which we are now
trying to phase out in favour of the SDL one.
Check. Is the old MSDev project still in CVS, or does somebody have a
copy? I googled one link but it's vanished. Would anybody else be
interested in it?
--
All,
I seem to recall that the moving of id3.[ch] and related higher-level
mpeg code from firmware/ to apps/ has been mentioned a few times, and
no-one seemed to object to the idea.
I did a quick test this afternoon, and tried to move the following files
from firmware/ to apps/:
id3.[ch]
David, these were missing from Wavpack.h:
void WavpackUpdateNumSamples (WavpackContext *wpc, void *first_block);
void *WavpackGetWrapperLocation (void *first_block);
I have the Wavpack record code written (for now hard-coded into
pcm_record.c). I can't get it to compile though. For
Have you looked at this patch?
http://sourceforge.net/tracker/index.php?func=detailatid=439120group_id=44306aid=1412272
No, didn't think this had been done yet. Thanks.
--
gl
Could we apply an older patch first that enables the user to have multipreset support (fmr)?There is already an updated patch on the tracker.It changes some parts of the radio.c (and a bit into filetree.c (and some other files)to integrate the fileformat). Except the multipreset functions (load,
Oh I forgot the link.https://sourceforge.net/tracker/?func=detailaid=1315353group_id=44306atid=439120
On 12/02/06, XavierGr [EMAIL PROTECTED] wrote:
Could we apply an older patch first that enables the user to have multipreset support (fmr)?There is already an updated patch on the tracker.It
The sim used to be able to be built in MSDev, but not anymore.
Did something break compatibility or was it just not maintained? I'm
happy
to update an old project if there is one.
It was me who once made the MSDev6 project for Rockbox. It's ages old, prior
to the plugin system. It was in
It was me who once made the MSDev6 project for Rockbox. It's ages old,
prior
to the plugin system. It was in parallel to the make files, ignoring
these.
So any change had to be merged manually in there, too.
And that's how it became unmaintained.
Right, I wonder if it's possible to generate
We don't use malloc and free in Rockbox. Allocate whatever memory you need
with static buffers.
Those two buffer sizes are unknown at compile time: one I can talk to David
about, the other because I was anticipating packing to various formats, eg.
8bit. I guess I could statically allocate
gl wrote:
We don't use malloc and free in Rockbox. Allocate whatever memory you
need with static buffers.
Those two buffer sizes are unknown at compile time: one I can talk to
David about, the other because I was anticipating packing to various
formats, eg. 8bit. I guess I could
If we used malloc(), we'd need to keep this amount of memory free in
case it would be needed anyway, so it's just as wasteful as using malloc.
Good point, except of course it's wasteful to permanently allocate memory
that is only used in a particular mode (eg. recording). But I guess it
Dan Everton wrote:
Are their any objections to this? Should I try and keep those other
sims running? Or has the SDL sim become usable enough that we can
deprecate the others?
Well, you have my vote for switching to the SDL sims. But if it's not to
hard to keep the others working for a while,
On Sun, 12 Feb 2006, Dan Everton wrote:
I've got some SDL simulator changes pending (sound.c is now implemented like
the actual hardware, backlight works, etc). However committing these changes
will break the X11 and Win32 sims as the stub implementations of these
functions are no longer
14 matches
Mail list logo
