tech.txt

rockbox掌上游戏机源码,包括pc仿真和小机代码

                        Rockbox From A Technical Angle
                        ==============================

Background

  Bj鰎n Stenberg started this venture back in the late year 2001. The first
  Rockbox code was committed to CVS end of March 2002. Rockbox 1.0 was
  released in June.

Booting and (De)Scrambling

  The built-in firmware in the Archos Jukebox reads a file from disk into
  memory, descrambles it, verifies the checksum and then runs it as code. When
  we build Rockbox images, we scramble the result file to use the same kind of
  scrambling that the original Archos firmware uses so that it can be loaded
  by the built-in firmware.

  1) The built-in firmware starts
  2) It looks in the root directory for a file called "archos.mod" (player)
     or "ajbrec.ajz" (recorder)
  3) If it finds one, it loads the file, descrambles it and runs it

CPU

  The CPU in use is a SH7034 from Hitachi, running at 11.0592MHz (recorder)
  or 12MHz (player).
  Most single instructions are executed in 1 cycle. There is a 4KB internal RAM
  and a 2MB external RAM.

Memory Usage

  All Archos Jukebox models have only 2MB RAM. The RAM is used for everything,
  including code, graphics and config. To be able to play as long as possible
  without having to load more data, the size of the mpeg playing buffer must
  remain as big as possible. Also, since we need to be able to do almost
  everything in Rockbox simultaneously, we use no dynamic memory allocation
  system at all. All sub-parts that needs memory must allocate their needs
  staticly. This puts a great responsibility on all coders.

Playing MPEG

  The MPEG decoding is performed by an external circuit, MAS3507D (for the
  Player/Studio models) or MAS3587F (for the Recorder models).

  The CPU has a serial connection to the MAS for MP3 playback, using serial
  port 0 at approx. 1mbit/s. The MAS has a handshake signal called DEMAND,
  that informs the CPU when it wants more MP3 data. Whenever the DEMAND
  signal goes high, it wants data sent over the serial line, and it wants it
  quickly, within ~1ms. When the MAS has received enough data, it negates the
  DEMAND signal and expects the incoming data stream to stop within 1ms.

  The DEMAND signal is connected to a port pin on the CPU which can generate
  an IRQ, but only on the falling edge. That means that the mpeg driver code