Rockbox mail archiveSubject: Re: Volunteering for porting Rockbox
Re: Volunteering for porting Rockbox
From: [IDC]Dragon <idc-dragon_at_gmx.de>
Date: Wed, 25 Aug 2004 08:43:21 +0200 (MEST)
> With respect to this discussion, I should probably say that I have the
> time to create a Rockbox port if a platform is selected.
> What I don't have is the physical acuty of sight necessary for reverse
> engineering - I can't see well enough to trace circuit boards and my
> limited electronics knowledge isn't really up to the job anyway.
> Also I probably can't afford to buy hardware. (The reason I have time
> is that I have post-viral fatigue. This means that I am well enough
> to do stuff about 40% of the time, but I can't reliably predict *when*
> I'll be well enough. This is obviously not a problem for Open Source
> coding but makes holding down a job kind of hard. Obviously this
> isn't conducive to having a large supply of cash to donate to the
> porting project.)
>From what you described, low-level hacking some new hardware is not
apropriate for you, but there is more to it. You mentioned "porting
Rockbox", which to a great deal means making Rockbox portable. For this kind
of work, we don't need actual hardware, nor be too specific about it.
One of the ideas I had in the past weeks (without a chance of having the
necessary time, my job is demanding, plus we're building a house) is to make
a proof-of-concept by porting Rockbox to the PC. You read correct, and we do
have the UI sim, but this is no port to my measures. For example, the code
is plastered with #ifdef SIMULATOR, which shoudn't be required if things are
layered and can be exchanged on a file basis. A PC port should not try to
mimic the Archos specific details, but should supply all functionality of a
PAD (portable audio device), or at least fake it so that the interfaces are
identical and the conditional code is minimized.
A real port would mean to split up the firmware parts into what's actually
hardware specific and what is general control code. We need a clean
architecture and generic-enough interfaces. For example, future boxes won't
have a MAS chip, but either software decoders running on the main CPU or on
a companion DSP. They will play more formats than mp3. So we'd need a codec
API instead of reading MAS registers from the application code. A PC port
can use that and interface it e.g. to DirectShow if it's Windows (I can help
with that), so we can actually have the PC port playing.
OK, I got carried away to the long term goals, but my point was to work on
the Rockbox architecture, to prepare it for porting.
-- Supergünstige DSL-Tarife + WLAN-Router für 0,- EUR* Jetzt zu GMX wechseln und sparen http://www.gmx.net/de/go/dsl _______________________________________________ http://cool.haxx.se/mailman/listinfo/rockboxReceived on 2004-08-25