dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: (no subject)

(no subject)

From: alankorr <>
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
  - 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
  will generate. I will strongly discourage people from only
  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
> for client applications, whereas we would have just a
> application, no? Is this right, or can anyone envisage a
> for scheduling/multiprocessing? Does this require CPU

  There is one OS i know but i'm not sure it is totally free
: its source
  is available to

  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
> components of prospective applications before the
> interfaces are completed? I know that this is the hacker
> coming to the fore :) but application developers could
> progress on core features (music control, playlist
manipulation, etc)
> independently of the work being carried out on the metal

  Yes, it might be a good idea.

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

  Nope, SH1 is suspected just to send mp3 streams to a DSP
  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
  ATA WRITE SECTOR(S) because we will also know the first
LBA of this

  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.

// free anonymous email || forums \\ subZINE || anonymous browsing
            subDIMENSION --
Received on 2002-01-02

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy