仕事どころで日記書いてる暇が、というのが正直なところ。実際、今日もお仕事なので。
今年の日記をざっくり読み直してみましたが、今年の1月の日記は今年の1月に書いているはずなんだけど、感覚的には2〜3年程度前のことのように見えています。それくらい忙しかったなあと。
思うに、今年は色々なことを積み残したまま来年に持っていきそうです。そして積み残すものは今後どんどん増えていくことになるのかな、とも。
とりあえず、二輪の教習は見事に第二段階のみきわめを落としているので（教習所内のコースを全く覚えずに挑んだのが敗因であることは確かだ）、まずはそこを片付けるところから始めようかとは思うのですが…片付くんですかね、コレ。
♪
という訳で、来年もよろしくお願いします。58.65kg(05:40)
※MSX Advent Calendar 2015参加記事です。
これまでのあらすじ
MSXのJIS第二水準漢字ROMの存在判定は、龠（83区94点）のグリフの左上8×8ドットのデータのチェックサムを使用して行います。詳細は11-Jun-2015に記していますが、MSX-Write II, FS-A1ST, HBI-J1の三つとも、龠のグリフは同じデータを使っていました。Panasonic系の漢字ROMとSONY系の漢字ROMはフォントデザインが大きく異なっているにも関わらず。
分かっていないこと・知りたいこと
SANYO系MSXの第二水準漢字ROMにおいて、龠のグリフはどのようなデータになっているのか？というのが未だに解決されていない疑問です。SANYO系MSXの実機さえあれば吸い出して調べるだけなのですが、残念ながら実機を持っていないためにどうにもなりません。
類似環境での調査
昔、とある方のblogで、SANYO系MSXはタイプバンクのフォントを使用しているという話を目にしました。DOS/Vが登場する前に、日本語が使用できるPC/AT互換機として存在したAXパソコンのごく一部の機種(SONY Quarter L)でもタイプバンクと思われるフォントを使用していたので、これを使用して龠のグリフがどうなっていたかを調べてみます。
本来であれば、AXパソコンをAXパソコンとして存在させるための要となるJEGAカードから完全なフォントデータを吸い出した上で調べるのが筋ではあります。しかしQuarter Lに搭載されていたJEGAカードは手元に残っているものの、これを動かすためのISAバスを搭載したPC/AT互換機を手放してしまっているため、はるか昔にFONTX2用フォント作成ツール(mkfxntax.exe)で吸い出しておいた結果を使用しています。よって不完全なデータで調査を行っている可能性があります。
龠の左上8×8のチェックサムは0x00 + 0x01 + 0x02 + 0x04 + 0x1b + 0x60 + 0x3d + 0x25 = 0xe4、この結果ではJIS第二水準漢字ROMなしと判断されてしまいます。
推測
実際のところがどうなっているかについては、実機から吸い出したデータを見ない限り何とも言えないので、あくまでもここでは推測を記すことしかできません。
おそらくですが、SANYO系の漢字ROMにおいても、龠のグリフはPanasonic/SONY系の漢字ROMと同じデータになっているのではないでしょうか。逆に言えば、SANYO系の漢字ROMにおいては、このグリフに限りタイプバンクのグリフではない可能性が高そうです。
おわりに
この話を書く前に、以下のような実験を行っています。
実機ではできなかった漢字ROMのフォントデータの変更も、エミュレータの登場により気軽に試せるようになりました。MSXの漢字ROM（のフォントデザイン）はメーカーによって違うというのはよく知られている事実だと思いますが、この違いがソフトウェアの動作（雰囲気）に大きな影響を及ぼしていたことを指摘する人はあまり多くないように思われます。
フォントは、その機種の「顔」であると自分は考えます。MSXに限らず全てのホビーパソコン（ワープロも含む）において、漢字ROMのデータはきちんと保存され、可能であれば自由に利用できるようにして頂きたいと常日頃考えているのですが、この記事を読んだ皆様はどうお考えでしょうか。60.00kg(00:05)
OpenBSD上で久々にHAIKUのビルドを試してみましたが、GNU拡張な<regex.h>を使っている（OpenBSDはPOSIXのみ対応）という理由により失敗です。ビルド時のログを転がしておきますが、src/bin/keymap/Keymap.cppのリンク時にre_set_syntax(), re_compile_pattern(), re_search()が無いと怒られます。
どうにかしてこれらの関数を持ってくるか、POSIXなregcomp(), regexec(), regfree()で代替するか、他の適当な正規表現ライブラリを使うか、スタブを書いて適当にお茶を濁すかのどれかを行う必要がありそうです。
それにしても、何故今までGNU拡張に依存していたことに気付かなかったんでしょうかね。なんか色々と悔しいのですが。58.75kg(05:15)
今はMultiboot specificationは0.96よりも1.6(multiboot2)の方が主流のようなのだけど、そこに書かれているExample OS codeをQEMUに食わせても動かない…
EGAのテキストコンソールではなくフレームバッファコンソールが有効になっていたり、UARTのアドレスがどこかにメモリマップドされたアドレスになっていたりと、何か手を加えないと動かないことは間違いなさそうなのですが。
♪
なんか毎年の恒例行事化しているので（そうした覚えはないはずなんだけど）、今年もOpenBSD上でのHAIKUのビルドに挑戦するかもしれません…とはいえ、仮想化のおかげで気楽にマルチOS環境が構築できる以上、わざわざOpenBSD上でビルドするのが適切か？という疑問もなくはなかったりします。Jamがやたらと遅い（fork()が重いからか？？）というのもありますし。
とりあえず、git.haiku-os.orgから落としたソースがきちんとビルドできるかどうか、Ubuntu 15.10上でのビルドを試しているところです。
♪
バイクの教習は第二段階の終盤、セット教習とみきわめを残すのみです。時間さえあれば今年中に卒業検定まで終わらせることも可能そうですが、時間の都合上みきわめと卒業検定は来年に持ち越す必要がありそうです。もしかするとセット教習も持ち越しになるかも。
可能なら勢いに任せて大型も取ってしまおうかなどと考えていますが、（時間もそうですが）教習費用をどう捻出したものか…58.90kg(06:15)
16-Dec-2016補足：年内のセット教習も受講不可、全て来年への持ち越しが決定しました。HAIKUについてはLinux上でのビルドが上手くできたこと、31-Dec-2014のパッチがそのまま当てられることは記しておきます（このパッチでOpenBSD上でビルドが通るようになるかどうかは不明です）。
モニタもどきを移植してみました。
QEMUの-kernelオプションを使用した場合しか確認していないので、実機上でGRUB使って本当に動くかどうかは不明です。イマドキのマシンだとシリアルポートを持っていないので、そもそも実機上で試せないという問題もありますし。
これをamd64/x32なコードで動かすことが目標なのですが、うまくいくかな？58.30kg(05:45)