BUGさんのKaban Extra

MouserでAT45DB161D-SU-2.5 が・・・なくなってる（T_T)

外堀すら埋められないとは ○|￣|＿

あーあ・・・・・

XMEGA64がいつになるか分からないのに、注文しちゃった（てへっ

・・・・・・ダメ人間・・・

最近、どうにも三脚が欲しい(笑)

というか、何だろ。
PowerShotA40ではうまく撮れなくなってきた・・・・・気がする。

腕が落ちたのか、筐体の反応が鈍くなってきたのに関連するのか、
それは分からんのだが、とにかく、PowerShotA40(で撮る絵)が絶不調な感じ。

そんなことはさておき。

EOS40Dを買ったときから、「コンパクトデヂカメはもう持たない」ぐらいの勢いで
今でも４０Dを毎日担いで歩いてる。ただの錘みたいなもんですが。

少なくとも、以前は三脚なんていらないと思ってたし
今でも、「もって歩くのは勘弁」なのは変わらないのだが。

ホームページ用の写真を撮るのに、さすがに４０Dではでかすぎるし面倒。
かといって、最近はPowerShotでの写真も、なかなかピントが合わない。
で、今のところ携帯電話の500万画素に頼ってるのが現状だが、
これこそ今時の「バカチョンカメラ」なわけで。

使ってる当人としては、不満たらたらなわけです。

そんな中で、いろいろ妥協点を探っているのですが。

ひとまず、三脚を導入して、安定状態を作って撮ってみよう、というところで
衝動買い落ち着いたのです。

たいした三脚じゃないのでアレですが。ヨドバシで1980円だったので
まさに衝動買いレベルですな。

つーか、一眼レフは重すぎるからやめたほうがいいって言われたのに・・・・(笑)

コンパクトデジカメも新しいのを買おうかと物色してる最中で、
とりあえず、三脚だけ先に買って慣れておこうとか思ったら。。。

めいっぱい伸ばしても、PowerShotA40じゃピントあわねーでやんの(笑

当然30mm/F1.4なレンズの４０Dもダメ。
まあ、そこは一眼レフ、標準キットの18mm/F3.5がちょうどいい感じ・・・・・

実際の運用に入るかどうかは・・・微妙・・・

ツールの手直しをして、とりあえずテキストでデータを吐かせてみたけど・・・

ちょっ、ちょっと、考えさせてくださいｗ

とりあえず、方向としては

このまま行くか、
シリアルROM載せるか、

ですが。

なんの当てもなく、MouserでAT45DB161D-SU-2.5 あたりを
発注しようか迷ってる自分がいる・・・・・

どうしても、外堀埋めたいのね・・・

とはいえ、XMEGA64A4も入荷待ちになってるし・・・
しばらく停滞かもな～

フォントを扱うプログラムは、実に7年ぶりぐらい。

当時作ったフォント変換のプログラムを発掘して、
再度読み直してみる。

DOS窓で、フリーになったBorlandC++でコンパイルしていた形跡まで
全部残ってた。

あの時は、PICからAVRへと移りつつあった時期で、それでもまだ
PICでモノクロLCDパネルを表示して、その過程でフォント変換のシステムを
書いていた。

AVRの第一弾はLEDマトリックス。今みたいにキットがあったわけではなく
モジュールだけが簡単な資料とともに売られてた。
ゲーム業界からハードウェア設計に業種を変えたばかりで、
コードは書けても回路は描けない、そんな駆け出しにとって
その制御法は複雑怪奇なものでした。

それでもまあ、現場のボスに教えを乞い、タイミングチャートの読み方から始まった。

今にして思えば、たとえ制御できても、PC上での経験がなければ
文字の表示すら出来なかっただろう。
ゲーム業界、PCでの開発経験があったからこそ、今の自分がある。

まあ、絶対に無駄にはならないことは分かってたんだがｗ

で、フォントの変換システム。
単純な文字列からフォントデータを集めてアセンブリ形式のデータ定義ファイルに出す。
そんなものでも、いまだに役に立つのだから、これほど面白いことはない。
UnicodeとJISコードの変換テーブルを元にコードを取り出し、SJISに変換、その上でFONTXファイルから
データを探し出して、とりあえずファイルに。

16bitをUnicodeと見なして変換し、フォントのないところはダミーで埋めて・・・
そんなことをしたら2Mbyteになってしまった、なんてことがどこかに書いてあったな。
・・・・同じことを考えた人がいるんですねｗ

ファイルを分割してやれば何とかなるんじゃないかと思ってたんですが
予想以上に歯抜けというか、隙間が多い。
これだと分割の仕方が面倒になる。
というか、分割しきれない。

それよりも、SPIのシリアルROM、2MByteぐらいを積んで、
あとはテーブル引きしたほうが、断然速い気が・・・・・。
少なくとも、FATを辿っていくよりも、テーブルで一段引いて、それをオフセットにして
データ読み出ししたほうが、速いわな。。。
アドレスによる読み出し速度の違いはないんだし。

とはいえ、またSPIに頼るのも何だかな・・・

そんなことを考えながら、まだ画面には何も出てませぬ。。。

長い前フリでしたが（？）
やっと本題。

絵が出たので、次は文字列ですかね。

そーいうわけで、FONTファイルを探してたのですが
結局SJISの$FONTX2形式しか見つからなかったので
UnicodeからSJISへ変換しながら使うか、
それとも
フォントファイルをUnicodeで再構成してしまうか、ですが。

その前に、過去の経験からの話。

家庭用ゲーム機と呼ばれるものは、パソコンとは違って性能は
基本的に一定なわけです。
当然、使えるメモリサイズも一度決まってしまえば変わりませんね。

ここでは、各機の詳細は抜きで書きますけど
CPUから見えるメモリー範囲は一定であり、その時々によって中身が書き換わって、
ゲーム機のプログラムってのは動いています。
CD-ROMから読み込む、っていうのが、その書き換え行為そのものなのですが。

メモリが限られているわけですから、当然持てるデータが限られます。
たとえばRPGで、メッセージを出すために、すべてのフォントデータを常に丸ごと
メモリに置いてるか、といえば、そんなはずはありませんよね。

そのマップで、そのシーンで、必要な最低限をメモリにロードします。
メッセージ（文字列）は、開発過程で確定しますので、必要な文字はどれとどれか、ってのは
既に決まってるのです。
だから、そのフォントデータを抜き出して、番号を振りなおして、決まった場所に置いて、
メッセージはその再生順序を示すコードの列に置き換えられています。

たとえば

に 1
わ 2
に 1
は 3
に 1
わ 2
、 4
に 1
わ 2
と 5
り 6
が 7
い 8
る 9（振りなおした番号）

１４文字が、9文字分のデータに圧縮されます。

このデータをメッセージ表示の際に再生すれば、この文字列は再現できるわけです。

さて。
今回やってるマイコンでの画面表示ですが。
マイコンでも、同じようにメモリサイズは決まってますし、ROMサイズも決まっています。
ただ救いなのは、CD-ROMよりも大容量な（！）MicroSDが味方についてます。

たとえば、作ろうとしているものが、MP3プレイヤーだとしたら。

プレイリストをPC上で作らせて、その際にタグを解析して必要な文字列を全部洗い出して
必要な文字のフォントだけを集めて再構成し、文字列も全部プレイリストの中に持ってしまうのが
おそらく一番レスポンスよく動いてくれると思います。

その代わり、リストにないファイルについては、表示できなくなります。

まあ、最終的にどこを目指すかによるけど、とりあえずは、そうではなく。
もっと一般的に文字列を表示することを考えます。

そうすると、先の
Unicodeでフォントファイルを再構成する、という案が浮上してくるのです。
問題なのは、コードが飛び飛びになってること。

その辺をうまく使って、ファイルを分割するようにすれば、多少は速くなるんじゃないかと
思ったりもするのですが。

書き方次第、かな。

とりあえず、$FONTX2は、いつか来た道、なので。
まずはFONTの再編成から。

ここ数日、FONTを探してました。

WindowsがLFNでUnicodeを使うというので、
その配置で使える、$FONTX2形式を。

･･････････････････・・・・・・・・・・・・・・・・

そんなもん、ありませぬ　○|￣|＿

それよりも、
「文字コード、この乱立っぷりは一体何！何なの！」

英語圏は確かにASCIIコードで事足りるのかもしれないけど、
我々漢字圏は数万文字を持つわけで
確かに、昔から頭痛の種ではあったのですが。

日本には恐らく元々JISコードというものがあり、漢字にコードが振られていたのに
それをなぜかMicrosoftを含む数社が再マッピングしたShift-JIS、
ここ20年で国際化が進み、２バイトコードの標準化の過程で出てきた
EUC、そして、Unicode。

ややこしいのは、日本の漢字コードの規格化の過程において、幾度となく追加と修正が
行われ、そのたびにJISの規格番号が追加されていること。
その辺も含めないと、表示できない文字が出てきたりする。

・・・・・コード体系についてはかなり深いいきさつの元で成立してるようなので、
これ以上は突っ込みたくないな。

それ以上に、フォントファイルの形式がいっぱいありすぎて、
その殆どは仕様が公開されていない。
それらの相互変換を完璧にこなすようなツールもない。

Windowsで使われるttf形式とPostScript形式の変換は出来るようだが
旧来の$FONTX2形式にはならないらしい。。。

・・・・FatFsの説明書きをつらつらと読んでたら
どうも、SJISとUnicodeの変換テーブルを持ってるらしい。
使うにはcc932_avr.cをリンクしなさい、と。

ソースを覗いてみると・・・まあ、確かにあるね。
これでとりあえず、誤魔化せるのかしら。

じゃあ、変換するためのテーブルを探すか！と
検索すると・・・
ここでも、テーブルの内容にいくつものローカルなものが存在するらしい。

まぢですか～　○|￣|＿

Unicodeの文字をSJISのどの文字のコードに変換するか、というのは
実はそうそう簡単な話ではないらしい。
この辺の話も、掘り下げればかなり深いのかもしれないけど
ここでは書きません。

スルーして、じゃあどの変換テーブルが当面安全なのか、というと
JAVA 1.4.0以降のテーブルと同じだ、というテーブル表に行き着いた。

とはいえ、こんなデカイテーブル、マイコンのメモリに納まるわけがないのは
明白なわけで。

どうしますかねぇ・・・

どういうわけか、ここ最近
私の周辺にはミニ四駆をやってる大人たちが頻出する。

まあ、私の世代は、誰もが通った道として
懐かしく思う・・・のはまあ、いいとして。

某店に出入りする関係で知り合った某氏を例に、
その大人気ないマシンについて。

彼が、去年10月の展示会の際にタミヤブース近辺でやってた
ミニ四駆の大会の際に見せてくれた、
エンペラーｊｒを使った「ノンターボエアブレーキ」。

なんでも、ジャンプ時にボディが開いて、結果的にエアーブレーキの役割をするんですって。
その蝶番の機構を組み込むのに、エンペラーのボディがうってつけらしい。

・・・・・・・・・・・ウケた。かなり。

他にも、金に糸目をつけず各種限定パーツてんこもりとか。
大人の財力に子供が敵うわけないわな・・・
そこまでして、子供相手に勝ちたいのか！？

おとなげないなぁ！
まったくもぅ・・・

でも、そんな大人たちであっても、タミヤは見捨てたりしないわけで
いろいろレギュレーションを調整したり、ジュニアクラスと分けたり。

なにより、そんな大人たちを取り込もうと、
昔なつかしのボディを再販、シャーシもタイプⅠからタイプⅢまで
古い金型を発掘して再生産、再販にまわすという復刻ビジネスに・・・・

・・・・・一番大人気ないのは、タミヤなんじゃないか、ってオチで。

いや、本当は、昨日大会があって、ソレを見に行ったことを書こうと思ったんだけどね(笑
オチがついたのでもう寝ます。

このくらい、外気温が下がってると
雪になるかもね。

これで、大雪になって交通機関が麻痺したら
ジタバタせずに「有給休暇！」って言えるのになｗｗ

「だって、雪だし・・・電車動かないし・・・」

たぶん、今日の雨が凍って終わりだろうけど。

#5cmは大雪じゃねーぞ

A劣者で逝こう９A列車で行こう9が、実は今日発売。

このゲーム、かなり頑張って続いてるんですけど、
だんだんダメになってるというか。

前回買ったのは、5年前のA7.。
3ヶ月以上前に大々的に発表会をやって、確かにそのゲーム画面の進歩に感心したものでしたが
何度か発売延期を繰り返した上に、発売当日にすでにパッチが出てるという、
低レベルっぷりを露呈してました。

その辺にも呆れてたんですが、少し経ってからパッケージを買ったんです。
起動したら、画面一面、白いBOXだらけ。
「なんなんだ、このゲームは・・・」と思うことしきり。
メディアの中身は、リビジョンが上がったものが入ってたので恐らく何度かマスター出しなおしてたんだろうけど、
インストール中になんか、チルダ付のフォルダが展開されてるのが見えた。
おかしいと思ってインストール先を見ると、画像が入ってるフォルダが2つに分かれてしまい、片方はチルダ付のファイル名で
展開されてました。そのフォルダの中身をもう一方に移したら直りましたけどね。

そして、パッチの嵐。
その修正内容もゲーム性直結な内容。笑うというか、呆れたわな。
デバッグしとるんかいな、こいつら。

A8は知らないうちに出てたので、とりあえずスルー。

気がつくとA9のアナウンス。
なんだか、時代の最高スペックを要求してくる。

事前チェック用に、A9ビュアーというのを配ってるのですが、
こいつが案の定、やらかしてる。

インストールすると、「X3DAudio1_5.dllが見つからない」とのたまうわけですよ。
で、それだけ入れると、次はまた違うDLLを要求する・・・と。
結局、DirectXのランタイム一式を入れないと動かないわけで。

ゲーム買ったわけじゃないんだから、そんなものデフォルトで入ってるわけないだろ！！

この会社が、ゲーム機でマトモなゲーム出せてるのが
ほとほと不思議だわ。
どんな体制で開発/デバッグしとるんだ。

そんなわけで、期待の発売日ですが
今のところパッチは上がってないようです(笑）
FAQも追加ないようですし。

線路引く画面がA5-完全版-に似てるのを見て、
嫌な予感がよぎったのですが・・・・

とりあえず、今のマシンではスペック的に足りないので
買うにしてもPCの新調が必要でしょうね。
なので、しばらく様子見かな。

と、言うわけで（？）
書き込みコマンドの使い方も分かったので

とりあえず、画像でも出してみますか。
まあ、ここに載せるにあたり、人様の著作物を無断で使うわけには行かないので
自分の写真から何枚か。

当然、こんなデカイデータ、ROMにもRAMにも入りませんから、
MicroSDとFatFsを使っています。

元画像はJPEGですけど、とりあえず24bitカラーのBMPに変換してからトリミング、
最終的には16bitカラーBMPに変換しています。

その割には、ここに貼ってる写真はトリミングしてねーじゃないかってのは
突っ込んじゃダメですからね。

ROMから再生するためにデータ変換してBMPのヘッダ削ってC言語の配列にして・・・なんて
やってましたが、さすがに飽きたので(笑

FatFsを有効にして、とりあえずファイル名はテーブルに持って。

BMPファイルは、いつか来た道ですから。
画像サイズの情報を取り出して矩形を設定後、
1ラインづつ読み出して一度RGBに分解。
フェードイン/アウトの演算後、Gのみ６ビット、あとは５ビットの計16bitフォーマットに再構成、
バッファに書き戻した後でバースト転送。

やろうと思えば、24bitカラーでも変換しながら描けるんですけどね～

ちなみに、16bitカラーのBMPってのは規格外ですからね。
BMPの仕様には正式に含まれていないらしいです。