From: alankorr <alankorr_at_subdimension.com>
Date: Wed, 02 Jan 2002 19:33:25 GMT

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

  - AJB6K, apparently a text LCD so no possibility to change
font.
  - AJBR, a graphical LCD, so no limit for our imagination.

> 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.

  Due to my experience with SH1 and GCC, an assembly code
written by
  a good coder will be far better and more compact than the
GCC
  will generate. I will strongly discourage people from only
coding
  in C code because SH GCC is not so good as IA32 GCC is.

> o Are there any (tiny or otherwise) OSs already written
> that we could obtain/use/modify? If there are, would
such an approach
> be sensible? After all, an OS typically provides raw
services
> for client applications, whereas we would have just a
single
> application, no? Is this right, or can anyone envisage a
need
> for scheduling/multiprocessing? Does this require CPU
support?

  There is one OS i know but i'm not sure it is totally free
: its source
  is available to
http://www.funet.fi/pub/microprocs/Cygnus-Embedded/ucos/.

  It is a generic OS which would not be compact and wouldn't
use on-chip
  peripherals modules easily, so I wouldn't use it.

> o Is there any argument for the immediate development of
high-level
> components of prospective applications before the
low-level
> interfaces are completed? I know that this is the hacker
mentality
> coming to the fore :) but application developers could
make
> progress on core features (music control, playlist
manipulation, etc)
> independently of the work being carried out on the metal
itself.

  Yes, it might be a good idea.

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

  Nope, SH1 is suspected just to send mp3 streams to a DSP
which
  really decodes them.

> 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?

  Nothing to do, ISD200 is totally independent
 
> o IDE controller code?

  Easy to do, there is a lot of sources.
 
> o LCD driver code (exciting to see the preliminary work
done here)

  Easy to do when LCD is known.


> o MP3 decoding drivers?

  DSP is in charge of decoding MP3 streams, not CPU.

> o Is it possible to write code to dump the *rom* firmware
to a file? If
> so, would this be directly usable as (or convertable
into) a mod file
> for others? I'm thinking about newer models with
firmware on rom
> (rather than shipped as updates).

  To dump it, it would be easy when we could write the
firmware into
  a void HD (on PC, we create a contiguous 256KB file with a
DOS name
  and let our software to write firmware on that file with
contiguous
  ATA WRITE SECTOR(S) because we will also know the first
LBA of this
  file).

  To use it as an archos.mod, i'm doubtful. Why ? firmware
tries to download
  for an archos.mod on HD. If an archos.mod tries to
download an archos.mod
  on HD, it falls in a forever loop.
 
Regards


_____________________________________________________________________
// free anonymous email || forums \\ subZINE || anonymous browsing
            subDIMENSION -- http://www.subdimension.com
Received on 2002-01-02