summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDaniel Stenberg <daniel@haxx.se>2002-10-01 08:20:33 +0000
committerDaniel Stenberg <daniel@haxx.se>2002-10-01 08:20:33 +0000
commitd3f4c362b368a9c65ff8b6d3eaec3929c4025dbc (patch)
tree0a0adad7db62c95614b4c520437f96d5ea30fc45
parent18f6ea638efddc4c0141b426a09da4733057cf69 (diff)
downloadrockbox-d3f4c362b368a9c65ff8b6d3eaec3929c4025dbc.tar.gz
rockbox-d3f4c362b368a9c65ff8b6d3eaec3929c4025dbc.zip
"Rockbox From A Technical Angle", take 1
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@2457 a1c6a512-1295-4272-9138-f99709370657
-rw-r--r--docs/TECH117
1 files changed, 117 insertions, 0 deletions
diff --git a/docs/TECH b/docs/TECH
new file mode 100644
index 0000000000..523a3622a9
--- /dev/null
+++ b/docs/TECH
@@ -0,0 +1,117 @@
1 Rockbox From A Technical Angle
2 ==============================
3
4Background
5
6 Björn Stenberg started this venture back in the late year 2001. The first
7 Rockbox code was committed to CVS end of March 2002. Rockbox 1.0 was
8 released in June.
9
10Booting and (De)Scrambling
11
12 The built-in firmware in the Archos Jukebox reads a file from disk into
13 memory, descrambles it, verifies the checksum and then runs it as code. When
14 we build Rockbox images, we scramble the result file to use the same kind of
15 scrambling that the original Archos firmware uses so that it can be loaded
16 by the built-in firmware.
17
18CPU
19
20 The CPU in use is a SH7034 from Hitachi, running at 11.0592MHz or 12MHz.
21 Most single instructions are excuted in 1 cycle. There is a 4KB internal ram
22 and a 2MB external ram.
23
24Memory Usage
25
26 All Archos Jukebox models have only 2MB ram. The ram is used for everything,
27 including code, graphics and config. To be able to play as long as possible
28 without having to load more data, the size of the mpeg playing buffer must
29 remain as big as possible. Also, since we need to be able to do almost
30 everything in Rockbox simultaneously, we use no dynamic memory allocation
31 system at all. All sub-parts that needs memory must allocate their needs
32 staticly. This puts a great responsibility on all coders.
33
34Playing MPEG
35
36 The MPEG decoding is performed by an external circuit, MAS3507D (for the
37 Player/Studio models) or MAS3587F (for the Recorder models).
38
39 ...
40
41Spinning The Disk Up/Down
42
43 To save battery, the spinning of the harddrive must be kept at a minimum.
44 Rockbox features a timeout, so that if no action has been performed within N
45 seconds, the disk will spin-down automaticly. However, if the disk was used
46 for mpeg-loading for music playback, the spin-down will be almost immediate
47 as then there's no point in timing out. The N second timer is thus only used
48 when the disk-activity is trigged by a user.
49
50FAT and Mounting
51
52 Rockbox scans the partitions of the disk and tries to mount them as fat32
53 filesystems at boot.
54
55Directory Buffer
56
57 When using the "dir browser" in Rockbox to display a single directory, it
58 loads all entries in the directory into memory first, then sorts them and
59 presents them on screen. The buffer used for all file entries is limited to
60 maximum 16K or 400 entries. If the file names are longish, the 16K will run
61 out before 400 entries have been used.
62
63 This rather limited buffer size is of course again related to the necessity
64 to keep the footprint small to keep the mpeg buffer as large as possible.
65
66Playlist Concepts
67
68 One of the most obvious limitations in the firmware Rockbox tries to
69 outperform, was the way playlists were dealt with.
70
71 When loading a playlist (which is a plain text file with file names
72 separated by newlines), Rockbox will scan through the file and store indexes
73 to all file names in an array. The array itself has a 10000-entry limit (for
74 memory size reasons).
75
76 To play a specific song from the playlist, Rockbox checks the index and then
77 seeks to that position in the original file on disk and gets the file name
78 from there. This way, very little memory is wasted and yet very large
79 playlists are supported.
80
81Playing a Directory
82
83 Playing a full directory is using the same technique as with playlists. The
84 difference is that the playlist is not a file on disk, but is the directory
85 buffer.
86
87Shuffle
88
89 Since the playlist is a an array of indexes to where to read the file name,
90 shuffle modifies the order of these indexes in the array. The randomness is
91 identical for the same random seed. This is the secret to good resume. Even
92 when you've shut down your unit and re-starts it, using the same random seed
93 as the previous time will give exactly the same random order.
94
95Saving Config Data
96
97 The Player/Studio models have no battery-backuped memory while the Recorder
98 models have 44 bytes battery-backuped.
99
100 To save data to be persistent and around even after reboots, Rockbox uses
101 harddisk sector 63, which is outside the FAT32 filesystem. (Recorder models
102 also get some data stored in the battery-backuped area).
103
104 The config is only saved when the disk is spinning. This is important to
105 realize, as if you change a config setting and then immediately shuts your
106 unit down, the new config is not saved.
107
108Resume Explained
109
110 ...
111
112Charging
113
114 (Charging concerns Recorder models only, the other models have hardware-
115 controlled charging that Rockbox can't affect.)
116
117 ...