summaryrefslogtreecommitdiff
path: root/docs/TECH
blob: 00abf8805c19d02725beb4eec91e310a5ed03886 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
                        Rockbox From A Technical Angle
                        ==============================

Background

  Björn 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.

CPU

  The CPU in use is a SH7034 from Hitachi, running at 11.0592MHz or 12MHz.
  Most single instructions are excuted 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).

  ...

Spinning The Disk Up/Down

  To save battery, the spinning of the harddrive must be kept at a minimum.
  Rockbox features a timeout, so that if no action has been performed within N
  seconds, the disk will spin-down automaticly. However, if the disk was used
  for mpeg-loading for music playback, the spin-down will be almost immediate
  as then there's no point in timing out. The N second timer is thus only used
  when the disk-activity is trigged by a user.

FAT and Mounting

  Rockbox scans the partitions of the disk and tries to mount them as fat32
  filesystems at boot.

Directory Buffer

  When using the "dir browser" in Rockbox to display a single directory, it
  loads all entries in the directory into memory first, then sorts them and
  presents them on screen. The buffer used for all file entries is limited to
  maximum 16K or 400 entries. If the file names are longish, the 16K will run
  out before 400 entries have been used.

  This rather limited buffer size is of course again related to the necessity
  to keep the footprint small to keep the mpeg buffer as large as possible.

Playlist Concepts

  One of the most obvious limitations in the firmware Rockbox tries to
  outperform, was the way playlists were dealt with.

  When loading a playlist (which is a plain text file with file names
  separated by newlines), Rockbox will scan through the file and store indexes
  to all file names in an array. The array itself has a 10000-entry limit (for
  memory size reasons).

  To play a specific song from the playlist, Rockbox checks the index and then
  seeks to that position in the original file on disk and gets the file name
  from there. This way, very little memory is wasted and yet very large
  playlists are supported.

Playing a Directory

  Playing a full directory is using the same technique as with playlists. The
  difference is that the playlist is not a file on disk, but is the directory
  buffer.

Shuffle

  Since the playlist is a an array of indexes to where to read the file name,
  shuffle modifies the order of these indexes in the array. The randomness is
  identical for the same random seed. This is the secret to good resume. Even
  when you've shut down your unit and re-starts it, using the same random seed
  as the previous time will give exactly the same random order.

Saving Config Data

  The Player/Studio models have no battery-backuped memory while the Recorder
  models have 44 bytes battery-backuped.

  To save data to be persistent and around even after reboots, Rockbox uses
  harddisk sector 63, which is outside the FAT32 filesystem. (Recorder models
  also get some data stored in the battery-backuped area).

  The config is only saved when the disk is spinning. This is important to
  realize, as if you change a config setting and then immediately shuts your
  unit down, the new config is not saved.

  DEVELOPERS:
  The config checksum includes a header with a version number. This version
  number must be increased when the config structure becomes incompatible.
  This makes the checksum check fail, and the settings are reset to default
  values.

Resume Explained

  ...

Charging

  (Charging concerns Recorder models only, the other models have hardware-
  controlled charging that Rockbox can't affect.)

  ...