From: <Bjorn.Stenberg_at_contactor.se>
Date: Wed, 2 Jan 2002 20:15:32 +0100 (MET)

Stuart Martin wrote:

> o Are the character font sizes fixed on the LCDs or are they variable?

On the JB6K they are fixed, since the display is character based. The Recorder has a bitmap display and can therefore display variable size fonts.

> o What is the quality of the gcc generated code? With such a small
> footprint available, would assembler be a better bet? I've no idea,
> just thinking aloud here.

The GCC-generated sh-1 code is definitely sub-optimal and hand-written assembler can in some instances create _much_ shorter code than gcc-compiled C.

On the other hand C is a lot better than assembler for an open source project, so I would prefer to limit the assembler to parts of the code where it really does make a big difference.

> o Are there any (tiny or otherwise) OSs already written
> that we could obtain/use/modify?

Yes, lots of them. One high-profile example is eCos, by RedHat/Cygnus. Another one worth looking at is uCOS.

> can anyone envisage a need
> for scheduling/multiprocessing?

We can probably make it without an OS, but as you say even a basic scheduler makes things a lot easier. We loose some bytes but gain a lot of application simplicity.

> o Is there any argument for the immediate development of high-level
> components of prospective applications before the low-level
> interfaces are completed?

Well, there are a couple of viewpoints to that:

- We don't know the low-level interfaces so it's difficult to write clean high-level code that doesn't indirectly dictate the lower interfaces.

- But it's an open project, everyone contribute what you feel like. I certainly won't reject any code just because "we're not there yet".

- Many people have complained about the native Archos user interface, calling it counter-intuitive and archaic. Myself, I have never used another MP3 player so the Archos is my reference and I can't claim to judge objectively if it's difficult or not. Looking at a couple of different popular players and gauge their various UI strengths and weaknesses might be a more useful starting point than writing code.

> o Is the CPU capable of decoding other music formats in real-time,
> or is dedicated chip support necessary for this?

The CPU runs at 12MHz and is definitely incapable of decoding compressed music, we need external hardware. On the other hand, the decoder chip is programmable and thus we can theoretically support other formats with this chip.

> o Which low-level components need developing before we can begin to
> replace the archos-provided code? I know the MP3 en/decoding is done
> on chip - do any more of these come for 'free'?
> o USB driver code?

This comes for "free", as the USB interface is not handled by the on-disk firmware. If a USB cable is plugged in at power-up, the Archos does not read the harddisk firmware file.

> o IDE controller code?

Needs to be written. Public domain reference code is at www.ata-atapi.com.

> o LCD driver code (exciting to see the preliminary work done here)

Needs to be researched and written.

> o MP3 decoding drivers?

We don't need MP3 decoding code, but we need code to interface with the decoder chip. There are a couple of other projects using the same chip that we might be able to get code and/or help from.

> o Is it possible to write code to dump the *rom* firmware to a file?

Yes, I think it is. For that, we obviously need IDE interface driver code.

> would this be directly usable as (or convertable into) a mod file
> for others?

I don't know.

/Björn
Received on 2002-01-02