2007/5/10, Dave Chapman <dave_at_dchapman.com>:
> Christian Gmeiner wrote:
> > The big plus point is that we dont need to care about the simulator
> > with #ifdef's anymore as the simulator is a normal target.
> I don't see how that will happen - won't it just mean replacing "#ifdef
> SIMULATOR" with "#ifdef SDL_TARGET" ?
No you are wrong.. we will use the target tree feature:
Here we implement, for instance, a lcd driver based on sdl, audio
driver based on sdl,...
> Looking at the current code, there seem to be a lot of #ifdef SIMULATOR
> checks which are not needed - e.g. lines of the form:
> #if defined(CPU_COLDFIRE) && !defined(SIMULATOR)
> can just be changed to:
> #ifdef CPU_COLDFIRE
> - the CONFIG_CPU macro in the config files aren't defined for the simulator.
> Another problem is simply hardware features of targets which are not
> implemented in the sim - mainly the MAS on Archos devices, radio,
> recording, plus various other things like HAVE_PWM_BACKLIGHT_FADING.
> How would your proposal deal with these?
I dont want to write an emulator, I want to integrate the simulator
better into the current source! These are two _very_ different things.
So... whren we build a simulator for target X5, we will get a sdl
based executable (in combination with the bootloader), which has the
same size of lcd as x5, has the same buttons as x5, has recording if
supported - like our current uisimulator.
We can run now rockbox on our pc with sdl.. we will use sdl to play
sound and so on. But you have now the same core (threading,..) as we
would compile rockbox for a target, which can help debugging.
> I'm not convinced that a radical change in architecture is needed - the
> time might be better spent just implementing more features in the
> current sim, and ensuring #ifdef SIMULATOR is only being used when it
> absolutely has to be.
Believe me that nobody wants to check, if this ifdef is okay or not...
its much easier when there are none or a very small amout of these
Received on 2007-05-10