マイコンのビデオ表示に回転機能付けられないかな？

ふと、思いついて電卓でメモリ量とクロック数の計算。
妄想開始です。マイコンでビデオ表示のお話。


以前マイコンでビデオ表示をした物といえば
TINY2313のスプライトや背景表示器があるわけですが、
いわゆるＸＹ座標系なので、例えばこれでゲームを
作ろうとしても、どうしても80年代ゲームになって
しまうのは仕方ないところ。

うーん、もう少しひねりを加えて、なんとか表現力
を増せないかなと…

以前諦めた「回転機能」、コレ、意外に出来ちゃうんじゃ
ないかな…という思いつき。

回転処理というのは、一番わかりやすい例は大昔の
タイトーのゲームで「キャメルトライ」というのが
あるので検索をしてみていただきたいのですが、要は
角度を指定すると、表示されている画面がその角度で
傾く（回転する）という仕組みのことです。

コレをマイコンで出来ないかなというお話。


回転の計算原理自体はそれほど難しくは無く、高校生
レベルの行列計算とｓｉｎ、ｃｏｓ計算だけ使えばｏｋ。
処理能力に物を言わせてグリグリとコーディング
すれば理論上は可能なんですが、ネックはメモリと
処理クロック数のこと。ＮＴＳＣ信号作りながら
ですからねぇ。


正攻法でビデオ表示をしながら回転計算をやる
なんて…無理無理。

と考えて、最初から諦めていたのですが、処理方法
を工夫すれば何とかなっちゃうんじゃないかな…と。

まぁ、とは言ってもかなり無理無理なことを無理矢理
やるわけで、以前作った背景表示器のようにキャラクタ
コードからビットデータをデコードしながら回転する
って言うのはちょっと難しい。

となると、小さ目のビットマップ（せいぜい８０×８０ドット）
でＶＲＡＭを構成し、それを1ドット単位で制御
するっていう感じかな。これだと、800バイト程度の
メモリ量で済むし、ドット数が減ることで処理データ量も
減るわけで、キャメルトライみたいに回転軸を画面の
中心だけに限定すれば計算も複雑にはならないし。

１ｋＢのMEGA88程度でも入りそう。三角関数計算は
表示前に1回やっておけば良いし、後の回転計算（行列
計算）も上手い具合に端折って（小数の足し算の繰り返し）
しまえば、ハードウェア乗算命令すら使わなくても
それなりに詰め込めそう。

問題は、回転の場合はＶＲＡＭ全体が表示されるわけ
じゃなく、画面からはみ出る部分も出てくるので、
それを考慮すると実際に表示されるのは５０～６０ドット
四方といった程度なんだよなぁ。狭いな。表現力がイマイチ。
それにスクロールとかも1ドット単位でねちねちと
やらないといけないので、応用範囲もイマイチ。

もう少しＳＲＡＭがあればなぁ。
５０ドット程度の画面でなにやらドットらしいものが
同じところでグルグル回っても、あまり面白くないよなぁ。

なら、やっぱりキャラクターのビットマップデータを
持っておいて、そこからデコードしていく方向かな。

そうすると、メモリ量としては制約がほぼなくなるんだけど、
問題は処理速度。

　・キャラクターコード→ドットへのデコード処理
　・三角関数計算
　・行列計算

の3つが必要ということに。後ろ2者は何とかなるとしても、
デコード処理は厳しいな。

以前作った背景表示器でもキャラクターコードからドット
へのデコード処理を行っているわけですが、これは
横8ドット単位でデコードが出来る（要は8倍速）から
押し込むことが出来たわけですが、回転となると
1ドット単位で処理しないといけないので、
処理時間的にはやっぱり厳しいよな。


あとでまた考えよう…。

arduino pong を動かしてみた。

例のarduino－pongを一度動かしてみたいと
思っていたので、ちょこちょこっとやってみました。

スケッチは公開されているし、回路的にも２つの
デジタル出力ピンから出るビデオ信号とシンクロ
信号を抵抗で分圧してるだけ、入力も可変抵抗で
分圧した電圧をアナログ入力してるだけ、という
わけで、それほど難しいことはやってないわけで、
部品の配置も２～３分で終っちゃいます。

さて、コンパイルして書き込み。テレビに繋いで
みます…。


お！あっという間にタイトル出た！簡単だねぇ。

でゲーム画面…。うーん、ふつうにｐｏｎｇっぽい
画面なんですが、球が動き始めると球とラケット
が２重にブレて表示されてしまいます…。

うーん、アレかな？
http://alastair.parker.googlepages.com/arduinopong

このサイトの「Ｓｅｔ　Ｕｐ」ってとこに、正確な
タイミングを取るためにタイマー割り込みを無効に
するためのsetup();関数先頭の
　　　　　　cli();
ではもはや正しくないと書いてありますが、これが
原因かな？

うーん、タイマー割り込みのライブラリを直接修正
して使えと書いてあるみたいなんだけど、ライブラリ
を書き換えるのは嫌だなぁ。

一応、可変抵抗をグルグル回すとラケットが上下に
動くことは動くんだけど、2重に表示されちゃうと
アレだしなぁ。

タイトル画面や、球が動く前のゲーム画面がきちんと
表示されていることを考えると、多分アナログ入力
が悪さしてるんじゃないかな？

入力にアナログ入力を使わずに、デジタル入力を
使用すればそれなりに同期が取れた映像が表示される
んじゃないかなぁ？

ビデオ信号の表示がそこそこ出来ることが判って
しまえば、応用は色々利きそう。

ドットは大きいけど、簡単にビデオ表示が出来る
って言うのは便利だモンなぁ。アナログ入力さえ
使わなければ好きなように表示ができるとかなら。

後でスケッチの中身をもう少し眺めなおして
みましょうかね。

すこしずつ読み始めました。

この間ｓｉｍさんに教えていただいた本。
VHDLによる論理合成の基礎。

少しずつ読み始めました。

これまで試行錯誤して「こういうことかなぁ」って
なんとなく考えていたことが、ずばり「こうです。」って
書かれていて、これまでの苦労がなんだったんだぁ…と
いう感じになりました。

ランダムロジック（andやorなどの論理回路）と
順序回路（フリップフロップなどを含む回路）の
話とか、センシティビティーリストとシミュレーション
の話とか、そうそう、あと以前ハマッた複数のprocess文
に跨った代入はダメよとか。ここらへんはいままで
なんとなく理解はしていたつもりだったんだけど、
こうして概念をきちんと説明されると、あぁそうか…
と腑に落ちます。


この手の話って、他の本にはあまりしっかり書かれて
いないような気がするなぁ。ありがたい。


コンポーネントを使ったコーディングについても
解り易く書いてありました。
読み進むと、ライブラリの作り方も解るのかな？

まだ１／３程度しか目を通してないのですが、
頭の中がだいぶ整理された感じ。
やっぱり、「解った気になって進める」よりは、
こうしてきちんと頭の中整理した方が、安心して
コーディングに向かえるモンなぁ…


ある程度理解できたら、ＣＰＬＤでＮＴＳＣの
カラーバースト信号とカラーサブキャリア信号を
作ってしまおうという課題に再度取り組みたいと
思います。


まぁ、以前よりだいぶ障壁は小さくなったかな。

論理合成に向いたコーディングを考えるという
本題に比較的忠実な本ですね。
やはりｓｉｍさんに感謝です。


ただ、最初にこの本を手に取ると面食らうかもしれません。
デジタル回路の基本の基本は知ってないと厳しい
だろうし、ディスクリートＩＣで色々組んだ経験
がある人でも、ゼロからＶＨＤＬを始める場合には
向いてないかと思います。言語の詳説本ではないので…。
それ用には別途入門書は必要かと。