暗黑 2 真的要畢業了？

自從升上 99 後，玩遊戲已經不太提得起勁了？

雖說如此，去年還是練了一支火法，上個月又練了一支冰法XD

原本是想讓這支冰法用火弩 build，但是只有 87 等玩起來很怪，又很容易死？

最後改用 96 小老婆冰法玩火弩 build，原本的 87 等冰法再換回來。

目前 Bo 完，攻擊力為 13 ~ 16K，全身上下只有一顆 +- 4 的火珠以及滿變的閃爍火焰，配合米山的無限，8 人難度還是可以一玩。

目前暗黑 2 總時數來到 2525 左右，雖然全部大概買了 7 ~ 8 片的遊戲，第 2 時數多的遊戲應該也是玩不到 2 個小時？

有點考慮要買暗黑 3 了，老了不適合唸書了，想看書又會被看電視的老婆干擾，詩海石硯台的隱居處氛圍已蕩然無存XD

一直跟 AI 都相處不來，請他寫的程式或函數都不如自己寫來的快？

趁著連續兩個星期三上天龍國的機會買了兩本 LLM 相關的書，希望可以再給 AI 一次機會XD

雖說用 Python 寫 Code 很快，這一年工作寫到的程式，每個 py 也沒超過 1000 行，但怎麼看都像用 Python 寫 C code？

看著看著，心也累了，天涯何處是吾家呀？

花了一千多塊買了一本 Python 書，無聊就來翻翻吧XD

不知不覺，手上的 Python 書加起來應該已經超過 Golang 了？

巡田水 again

最近 Kobo 工程師很乖，沒有亂改 HTML 碼XD

看一下 github 修改記錄，上一次修改已經是半年前的事了。

很好，請 Kobo 繼續保持，這樣我才有動力繼續在這裡買書XD

STDF Format

STDF 是個很有趣的檔案格式，它常用在儲存 ATE 的測試資料。

對於寫 C code 的人來說，可以很簡單的用 fread + structure 的方式無腦 parsing。

它的 Hex 資料如上圖，這裡只框出前 5 筆 record。

每一筆 record 都帶有 4 個 byte 的 header，前兩個 byte 是 REC_LEN，後面兩個 byte，一個是 REC_TYP，另一個是 REC_SUB，header 後面就是帶有 REC_LEN 長度的資料。

一個橘色框框的是一筆 record，淺藍色的就是 REC_LEN，深藍色的是 REC_TYP + REC_SUB，沒有底線的就是該筆 record 的資料組成。

我們可以由 REC_TYP + REC_SUB 得知 record 的種類。

Spec 中也很貼心的用 C code 表達不同資料的解碼方式。

我們以第一筆 FAR record 為例，CPU_TYPE 欄位 = 0x02，屬於 IBM PC 的處理器，故其大於 1 byte 資料的順序為 Little Endian，比如說 REC_LEN 在解碼時，就必須反過來看。

隨便使用 STDF parser 當關鍵字在 github 搜尋就有 3 頁的程式碼可以參考，各類程式語言應有盡有，挑自己喜歡的來使用即可。

就像前面說的，C code 跟這種檔案格式很搭，故要快速得到一個結果，找 C code 的專案就對了。

2025/12/06 更新

剪頭髮時，因為等待的人數太多，看了一下 spec，終於知道如何分辨最新版本。

原本 FAR 的 STDF_VER 只有一個 byte，如果是 V4 其值等於 4。

而最新的版本為 V4-2007，因為版本號並沒有進位，故無法用一個 byte 來表示。

取而代之的是多了一筆 00 30 的 VUR record，他的 UPD_NAME 欄位是一個 char []，其值為 "V4-2007" 字串。

換句話說，即使沒有 STDF parser，直接打開檔案搜尋此字串即可。

另外，我有一個很奇怪的疑問，我發現我為了快速驗證用的 C library 在處理 D*n 時，有考慮到未滿 8 bit 的情況，故長度會 + 1，但網友用這個 C library 寫的 dumper，在 print_Dn 時犯了錯誤，並未印到後面 2 個 byte，但我印象在我修正 Code 後，辦公室的 Code 反而會當機，難道是我記錯了？

偏偏網路上都沒有 D*n 的 STDF 檔案可以驗證，真是好奇心殺死螞蟻呀XD

2025/12/13 更新

知道 Record 有所謂的 optional field，但從每個 Record 卻看不出來？

回過頭看前面的說明才知道，原來每個 Record Table 後面 Missing /  Invalid Data Flag 有描述的就表示是可選欄位，跟這個欄位一樣的值就表示該值沒有意義，可以忽略，但該欄位還是要存在，除了 Record 最後面的可選欄位。

另外，Initial Sequence 是必須要有的 Records，除了位在 STDF 檔案最前面外且順序如下圖。

總之，github 既然都有現成的專案可用，個人覺得了解到這樣就夠了。

Tcl 一些備忘

最近又開始用 Tcl 做一些事，之後應該會一直更新這篇。

01. array 傳遞方式

簡單來說，分別用 array get 以及 array set 來處理。

array get -> list -> array set。

02. exec 外部程式，比如 grep sed 等技巧

避免 regex 跳脫太複雜，把 regex 用 { } 包住即可。

03. Tcl 8.5 dict + upvar

從 Tcl 8.5 開始，有 dict 可用，配合 upvar 使用，array set 也可以比照辦理。

04. { } 裡面可以有 { }，不需要跳脫

exec echo 123 456 | awk {{print $1}}

05. 使用 grep 最好的方式

最好的方式就是不要用 grep，改用 sed。

因為 grep 天生遇到沒有匹配的情況會回傳 1，這會導致我們需要對結果做些事，才不會顯示 child process existed abnormally。

rm 恐慌症

雖然在工作站只有一般的權限，但因為自己寫的程式沒有地方可以 push，還是有點害怕自己在清理暫存檔時，無意間把自己的程式碼誤刪了！

昨天下班時突然想到，乾脆自己寫個簡單的 script 用 timestamp 來備份，每天早上的第一 build 便作檢查，如果當天還未備份過被順便備份，如果某天要大動刀程式碼時，也可以手動備份。

這樣應該還行吧？暫時我也沒有更好的辦法了。

順便記錄一下這個星期學到的新東西，原來 c shell 的 .rc 檔有順序性，比如 .tchsrc 已經存在，便不會再去管 .cshrc！

想想也是很合理，畢竟工作站的 /bin/csh 是 link 到 /bin/tcsh 無誤！

二一添作五

終於要發放了，再加上之前連續兩期雲端發票都有中獎，甘脆二一添作五好了。

沒想到今天就查詢到了，真是有效率。

雖然不想要收據，但還是要留個記錄，自從之前捐個某宗教團體查無資料後，好像也只能這樣來確保捐款單位的可信度了？

老派記事本

不知什麼時候開始的習慣？我在電腦螢幕前會擺一個雙圈記事本並摺成一半使用。

寫程式思考用它，臨時記錄事情也用它，閱讀技術文章整理重點還是用它！

去年用過好一陣子的 Obsidian，也花了錢訂閱及續訂，但因為一些緣故，最後沒有在辦公室使用。

雖然所有的事都記錄在同一本記事本很方便，但之後要整理時卻很傷腦筋，無法一眼看出那些資料要備份起來？尤其我在同一頁中會混合記錄不同的東西！

最近佳瑪已經沒有販買我常買的空白記事本，網路查了一下，只能線上或是去現場購買，真是有點不方便。

後來決定使用無印良品的雙環筆記本(空白)/80張.A6來代替，好處是要買隨時可以買，缺點便是書寫空間太小了。

沒想到雙圈空白筆記本這個東西還真冷門，沒看到第三個地方有賣了！

之後決定養成習慣，每頁上面劃條橫線記錄本頁主題及日期，只要換個主題便換頁書寫，希望這個方式可以解決我的問題。