Darkside（https対応しました）

　まあ正規化というのは前菜であり、内分計算を伴う変換計算こそが本丸である。変換テーブルから引いた４つの値（正方形の頂点）と、アクセル＆ハンドルの入力値（正方形内部の一点）を正確に変換する。これが、今時のパソコンならどうってことはない。しかし、８ビットマイコンで行うとなれば話は別だ。多倍長の乗算は、やたら処理が重い。
　Ｃ言語であれば記述は楽なようでいて、何も考えないと計算時間を馬鹿食いする。
　ここでまた、無茶苦茶な変換結果が出て来る。

　ＸＣ８は、１６ビット超の変数がいきなり使い物になっていない。
　多倍長演算の負荷を減らすべく、ＸＣ８には short long 型という２４ビット整数が存在する・・・ことになっているらしいのだが、コンパイルでエラーになり使用できない。これだけでも、非常に痛い。24ビットで足りるのに、なにを好き好んで３２ビット使わねばならないのか。アセンブラであれば、最小限の計算規模に抑えたうえで8ビット単位のアクセスも自在なので、ＸＣ８とは比較にならない高速で計算できる。汎用の計算ルーチンさえ作ってしまえば、使い回しできるし。
　だが、アセンブラで作り込んだ資産は、ＰＩＣの機種乗り換えを困難にするんだよな。

　メンテナンス製や、目的に応じてＰＩＣの使い分けを容易にできるという点で、ＸＣ８のメリットは絶大だ。性能的にＸＣ８で間に合うなら、ＸＣ８を使う一手。それだけに、余計なことで性能劣化というのは耐えられない。
　目を瞑って long 型を使うと、今度は乗算が機能していない。明らかに、上位１６ビットに値は入っていない。問題をややこしくしているのは、ＸＣ８の sprintf が long 型を処理できないこと。下位１６ビットしか表示しない。しかし、>>16 させて上位１６ビットを持って来ても、値が入っていない。いやこれもひょっとすると、シフト演算子も１６ビットまでしか対応していないのかもしれない。

　だんだん頭が混乱して来る。２４ビット使えるようにしろよ。使えないなら３２ビットをちゃんと扱えよ。
　自前でＸＣ８による汎用計算ルーチンを作るとしても、やはりＣとアセンブラには決定的な機能差がある。特に、キャリーフラグは大きい。オーバーフローを知るのに、アセンブラならキャリーフラグという１ビットを参照するだけで済む。Ｃでは、１バイトを見るしかない。これだけで、必要なメモリーサイズが１バイト異なる。しっかり最適化しようとすると、その差は余りにでかい。

　まあ本来こういう計算は、なーんも考えずに浮動小数点演算できるＳＴＭ３２などでやるべきなんだろうな。でも、PIC16F88 のアセンブラでは難なく処理できていただけに・・・仕方なく、バラして１６ビット以内で計算できるように組み合わせ、何とか処理する。上下バイトの単独アクセスは union 使えば行けるし。

　とりあえず、左右キャタピラの動きに変換することは出来た。