2009-10-18 (日)
メモリアクセス，1.3Mbpsかと思ってたけどよく見たら13Mbpsだった．これは，AVRのSPIじゃ無理…．普通のシフトレジスタ使って８ビットずつ読めれば何とかなるかな…．
プローブ当ててると読み込みに失敗するのは，クロックの信号が鈍りすぎているからだった．間にバッファを入れて解決．
もうCPDLとかのほうが良いかも．そろそろマイコンと汎用ロジックに拘るのはやめようかなぁ．
*文字列プールを探す
フォントデータ内の文字の順序が分かったので，バイナリ内の文字列を探してみる．
こういうとき，文字にどのような番号が振られているのか分からないのでちょっと工夫が必要です．とりあえず，「ロクれて」に注目してみる．「ロックされて」の，「ッ」と「さ」が前に出てくるので飛ばされていることは，間違いありません．
「ッ」と「さ」は，「ロ」を基準にしてそれぞれ，12文字前と30文字前に出現します．つまり「0,-12,1,-30,2,3」に定数を足したバイト列が出現するはずです．こんな数列が偶然存在する可能性はかなり低いので見つかればたぶん文字列データです．
適当にプログラムを書いて検索してみますが，残念ながら見つかりません．
これで見つからないのは当然で，文字が256文字以上あるなら2バイト以上で格納されていているはず．shortとして扱うのも良いですが，バイトオーダーの問題もあるので，とりあえず1バイト飛ばしで比較することににします．
やっぱり見つかりません．
フォントデータが文字の左半分の後ろに右半分が格納されていることを思い出す．つまり，２バイト文字は文字コード上でも２文字として扱われている可能性を考えます．
そこで4バイトで１文字を表すようにして，さっきの文字コードの差分に2を掛けて検索すると…．
見つかりました．
周辺に他の文字列もあることが確認できたので，確実です．殆ど同じものが３箇所に存在していますが，なんだか使われていない残骸がまじってそうな感じがします．
内部で使っている文字コードは0x0020～0x007FまではASCIIで，0x0080～に昨日のフォントが入っているっぽい．そして，なぜか0x00ffの次が0x0200になる．16ビットの文字コードかと思ったけど，内部絵は8ビットとして扱っていて，前についている1バイトでテーブルを切り替えているのかも．
どうやって作ったフォントなのか不明だけど，ベースラインを無視して作ってしまった感じですね．
*秋葉原
パーツを少し買ってくる．
なんか，秋葉原に行くと予定外のものばかり欲しくなるので危険．
*読書::ニコニコ動画が未来を作る
そこそこ面白い．読んだからといって，何かが得られるような本ではない気がするけど．
布留川英一さんってドワンゴの人だったのか…．この人の本にはiアプリとかで昔お世話になりました．著者のところを良く見たら普通にドワンゴって書いてあるし．