手機內部的存儲空間是連續的，幾乎所有的信息，包括鈴聲，圖片，甚至內置鈴聲和動畫待機圖的名稱，都是用指針來實現調用的。我們備份文件的時候，按地址以此導出bin1，ogm1，bin2，ogm2，這四個文件的地址是連續的，導出文件時需指定地址，分別是：
    BIN1:000000--6FFFFF
    OGM1:700000--7FFFFF
    BIN2:800000--C6FFFF
    OGM2:C70000--最后
    我們發現，前一個文件的末地址，經過十六進制+1之后，就是下一個文件的首地址，由此不難得出，四個文件合起來就是手機內部整個連續的存儲空間。
    這就很容易解釋調用bin1，ogm1，bin2，ogm2中內容的指針相對被調用內容的地址（此處“地址”指用winhex之類的十六進制編輯器打開四個文件之一時所看到的地址）分別需要加入0，700000，800000，C70000的增量了。因為我們在用十六進制編輯器調用這四個文件的時候，四個文件的起始地址都是000000。所有文件內的地址，都是對于文件頭的相對地址。對照備份四個文件時輸入的四個首地址，很容易看出，用十六進制編輯器調用時的000000分別對應了bin1的000000，ogm1的700000，bin2的800000，ogm2的C70000。因此這四個文件內的地址在手機內的真實地址就應該是用十六進制編輯器打開時看到的地址，加上這個文件在手機內的首地址。簡單說來，我們在PC上，用十六進制編輯器看到的是分別相對四個文件首地址的相對地址，而在手機內部真正實現調用的時候，需要使用到的是相對手機內部存儲空間起始地址的相對地址，兩個“相對地址”相對的000000并不一致。
    做過DIY版本的人都知道確定調用bin1，ogm1，bin2，ogm2這四個刷機文件中內容的指針時，該指針分別要加入0，700000，800000，C70000的增量，原因就在這里了。
舉例來說，我們用十六進制編輯器看到一個圖片或者鈴聲，又或者字串的地址是xxxxxx，那么如果它在bin1中，它在手機中的地址就是xxxxxx；如果它在ogm1中，那么它在手機中的地址就是xxxxxx+700000；如果它在bin2中，它在手機中的地址就是xxxxxx+800000；如果它在ogm2中，它在手機中的地址就是xxxxxx+C70000。指針所指向的，是內容在手機中的地址，這就是增量的由來了。
    如果把四個文件首尾相接，連接成一個文件，那么這個文件里面所有內容的地址就和它們在手機里面所占的地址完全一致，這時指針所指的地址，就是文件內的相對地址了，也不再存在增量的問題。當然，這么做比我們現在使用的加入增量來實現調用的方法更不方便，這樣只是為了用一個文件來模擬手機內的信息存放，因為我認為，刷機文件分成四個部分來dump只是為了配合刷機軟件downloader 3.2分四個文件刷入的模式，而刷入機器內部之后，四個文件其實就重新連接成了一個大文件。
                                                  20:36 2004-8-20