diff options
-rw-r--r-- | docs/TECH | 117 |
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 | |||
4 | Background | ||
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 | |||
10 | Booting 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 | |||
18 | CPU | ||
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 | |||
24 | Memory 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 | |||
34 | Playing 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 | |||
41 | Spinning 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 | |||
50 | FAT and Mounting | ||
51 | |||
52 | Rockbox scans the partitions of the disk and tries to mount them as fat32 | ||
53 | filesystems at boot. | ||
54 | |||
55 | Directory 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 | |||
66 | Playlist 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 | |||
81 | Playing 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 | |||
87 | Shuffle | ||
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 | |||
95 | Saving 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 | |||
108 | Resume Explained | ||
109 | |||
110 | ... | ||
111 | |||
112 | Charging | ||
113 | |||
114 | (Charging concerns Recorder models only, the other models have hardware- | ||
115 | controlled charging that Rockbox can't affect.) | ||
116 | |||
117 | ... | ||