CrossMosa 試用心得

我這個人就是反骨，不是拿 X3 國際版來刷第三方韌體，而是使用 X3 一般版。

果不其然，使用 SD 卡順利刷機成功，可惜的是，忘記先記住機器序號，總之是10/16 在熊老闆那購買的，顯示晶片是 UC8253。

介面看起來還不錯，又可以 Wi-Fi 傳檔，不過對我來說，有兩個致命缺點：

1. 不能關機，只能休眠，可能要翻一下說明書。

2. 以橫列來說，差不多大小的字型，目前只能顯示 8 列，比原生的少一列。

最重要的是下面會多出一列空白，這樣上下沒有對稱，看起來就不開心。

另外，如果是在閱讀畫面進入休眠狀態，有機會底色會變很髒。

我自己是覺得原生的閱讀起來比較順。

CrossMosa 比原生好的地方

01. 介面看起來不錯。

02. 有 Wi-Fi 傳檔。

03. 作者已經提供不同大小的字型檔案可以直接使用。

04. 閱讀頁面底部顯示資訊比較豐富。

05. 開源，隨時可以自行修改。 

06. 註腳可以隨時跳躍並返回。

07. 直排書就是直排顯示。

有機會應該會再刷回原廠韌體。

2026/11/05 更新

如果沒有下面的問題，個人覺得一般人如果不排斥刷機，使用 CrossMosa 是個不錯的選擇。因為它忠實反映了書本的原始樣式。

直排書就是直排書，橫排書就是橫排書。

無奈，我發現我放進 SD 卡的書，目前除了《人月神話》外，看沒 10 分鐘，就會像下面截圖一樣變得很髒，感覺跟之前待機畫面的問題有關？

等我人月神話看完，再請 AI 來修復？

關於 PTT 最近更新

最近 PTT 似乎有些改版，各家 PTT App 多少都有些問題。

今天想要使用 Pubook Mobile 來上 PTT，才想起需要更新，但是居然在 Google 商店看到不支援此裝置？

還好剛才想到今年剛買時是使用手動安裝 APK 的方式安裝 BePTT，重新順了一下原本的 script，之後才不會忘記這件事。

ptt.sh 第 11 行註解寫錯了，應該是加上 pull command 從正常手機抓出所有的 APK。

另外一家嘿嘿工具又失敗了

應該是該家工具偷偷改版的緣故？

印象中今年都還有嘗試備份書檔？

解決方式也很簡單，請出我們的 WireShark 即可。

由於之前的工具是用 Node.js 寫的，但這次需要修改 http get 的參數，不知道是大家現在都用 AI 還是怎樣的關係，居然搜尋結果前幾個的程式碼都不能直接拿來用，害我只好直接去看官方文件。

我從以前就對這家的文件沒轍，可能跟我沒有好好學過 Javascript 有關，不是很懂基礎概念，導致我看文件有時都會很出戲？

總之，官方文件描述可以將 url 和 options 分開傳遞，果然順利解決。

可惜的是嘿嘿工具尚無法自動化，因為我無法知道官方工具將我需要的那個東東藏在哪裡？算了，看在目前很少買書的份上，有需要再開啟 WireShark 即可。

終於，我可以來看我的人月神話了，沒想到居然還不是版式書籍？這樣才是一本好的電子書，希望約耳談軟體也可以出電子書。

果然是老人懷古呀XD

2026/11/01 更新

這個東東約一個小時內會更新一次，我印象中 WireShark 有 API 可供呼叫，直接請 AI 寫？

寸步難進

大概幾個星期，就要被 simulation 跑不過搞一次！

即使已經經過快 10 個月的洗禮，現在還是很難快速定位到真正出錯的地方？

我也搞不懂是我跟那個環境不熟還是怎樣，內心還是覺得 GTKWave 才好用，至少可以快速找到訊號，搜尋速度也很快，有編譯 db 的 EDA 工具搜尋居然如此難用？

雖然上班這兩天需分心搞定模擬（嚴格來說，只有一天，今天都還沒開始呢），放假後兩天身體不舒服也沒法思考，早上還是順利找到原因，但不是我原本想的 3 個地方，只要處理 1 個地方就能 pass 基本的 pattern。

那為啥我看圖會覺得是這兩個地方 unknown 造成？是啥原因造成我誤判？還是哪邊我搞錯了，到現在還是想不通？

套句《劍來》的術語，原來我已達到飛升境圓滿而不自知XD

想要再進一步，我只能往十四境邁進了？

好像會了一點東西，又好像什麼都不會？

這就是在浮沙逐塔的壞處呀！

不如醉裡挑燈看 Code 來得自在？

沒完沒了的更新

我的 KoboExpense 已經掛了一陣子，之前怎樣看都看不出來正規表示法跟現在的網頁有啥不同？

我覺得當初應該不是我眼睛脫窗？

至少今天再次嘗試，已經把他修正完畢，結果這次只是沒有加雙引號以及句尾多了空格。

Kobo 的工程師如果整天只會搞這些旁枝末節，我真懷疑他們的能力何在？

去年有買灌籃高手及滅活法，今年則是購買神龍之謎整套。

同場加映讀墨網站，當初我將 ReadmooExpense 開發完畢後，針對購買資訊部分就沒更新過了，5, 6 年都過了，還是沒啥大問題。

雖說讀墨網站的呈現，工程師是以 API 的方式，來取得購買資訊，但至少人家的介面一直保持不變。

舊愛還是最美

昨天終於有時間來觀察客戶自行設計的記憶體修復流程。

話雖如此，真正的實作是客戶請我跟 AI 討論後設計出來的。

客戶要修復的記憶體不算太多，但要透過 GUI 一個一個訊號拉出來觀察也是有些沒勁？

還好上個星期已經有寫一個簡單的 Tcl，將要觀察的訊號轉成 Tcl 餵入 Simvision 軟體。

但最困難的還是這個無中生有的訊號如何定義？都怪那該死的 Escaped Identifier Verilog 語法，我實在無法簡單的從 RTL 轉成最後網表看到的訊號名稱？再加上有些訊號是 for loop gen 出來的，也大大的增加我轉換難度！

這次不像上星期可以從 error log 中 parse 出我要的 instance，沒辦法，只好先找到一個 instance，再用其他程式語言組合出訊號名稱，然後餵進我的 Tcl（理論上應該在 Tcl 直接用 3 層迴圈，但懶得找語法了XD）。

沒想到 Python f string 要跳脫 Escaped Identifier 不是那樣直觀？試了 Google 前面幾篇文章的辦法還是不成功？

C 語言就沒那樣奇奇怪怪的講究，還好客戶工作站還是有 gcc，3 層迴圈，蛋糕一塊，重點是我根本不需要 Google 都還記得住語法！

果然是我學軟體以來用得最多的程式語言，小孩愛吃已回購。

2026/10/23 更新

靠，原來是被錯誤訊息誤導，大括弧要用大括弧跳脫，只有反斜線要用反斜線跳脫。

但我覺得 Python 這個設計也不好，都用反斜線跳脫不就好了？程式語言設計應該要有一致的行為模式才對。

我閱故我在

先前因為事情太多，一個終端機執行起來後，便馬不停蹄的開啟下一個終端機，繼續下一個任務，如此周而復始。

也不能說這樣不好，但以時間管理的角度來說，我們還是應該關注那隻最重要的青蛙！

雖然越晚執行的終端機表示越不重要，但以前一陣子所處的階段來說，每一個終端機都不保證能順利執行完畢，因此還是需要花費時間去 debug。

既然越晚執行的終端機越不重要，這也表示執行的時間有可能較短，當任務執行完畢有錯誤需要 debug 時，也是要花費一定的心力去處理。

結果就是第一重要的終端機已經跑完，也有錯誤需要花時間 debug，但我們卻被困在第 5 或第 6 不重要的任務上。

這個星期學乖了，不跑超過 3 個以上的終端機，且跑起來第 3 個終端機後便把焦點移回到第 1 個終端機畫面上，拿著我的 X3 邊閱讀邊想下一步計畫，重點是持續關注第一個終端機畫面。

也因為這樣，才讓我發現 xrun 編譯的盲點，也想到要處理增量編譯的問題。

如果你不用眼睛用心觀察，你根本不會意識到這有問題。

下面是我最後搞定增量編譯的比較時間，雖然只看 log 建立時間有點不準，但我們在意的是相對性。

左邊是使用增量編譯的版本，可以看出整整節省了 2 個小時的時間，更何況右邊還是使用砍掉編譯資料夾加速的方法，如果是我最早的版本，我想編譯浪費的時間一定更多。

購買 X3 的決定果然是對的XD