Posts Tagged with "space invaders"

既に発行済みのブログであっても適宜修正・追加することがあります。
We may make changes and additions to blogs already published.

ソフトブロック解説 (4)

posted by sakurai on June 7, 2021 #414

graphics階層

基本的にはgraphic_controlモジュールが中心となる階層です。次の3つのモジュールから構成されています。

  • graphic_controlモジュール --- クロックとリセットを入力し、HS, VS, DT等のグラフィックディスプレイタイミングやVRAMアドレスを生成するモジュール (Verilog)
  • xslice --- VRAMデータ中のRGB成分のみを抜き出す (Xilinx IP)。VRAMはRGBの他にもう一面持っており、その面にはシールドデータのみが描画されています。しかしながら、その面は表示はされません。この情報は、自弾及び敵弾の衝突判定に用います。これによりシールドをピクセル毎に破壊することができます。

    図%%.1
    図414.1 ピクセル毎の衝突判定

  • display_outモジュール --- ディスプレイタイミング時に表示データを出力し、さらに爆発信号EXPにより全面赤表示にするモジュール (Verilog)

図%%.2
図414.2 graphics階層


左矢前のブログ 次のブログ右矢

ソフトブロック解説 (3)

posted by sakurai on June 4, 2021 #413

VRAM階層

VRAM階層は、図413.1で示すように以下の2モジュールから構成されます。

  • VRAM --- 256×256×4bitのデュアルポートメモリ (Xilinx IP)
  • Muxモジュール --- メモリダンプモジュールからのアドレスをマルチプレクスする (BSV⇒Verilog, 過去記事で設計)

図%%.1
図413.1 VRAM階層


左矢前のブログ 次のブログ右矢

ソフトブロック解説 (2)

posted by sakurai on June 3, 2021 #412

invader階層

引き続きinvader階層です。これはインベーダゲームの中心となる、GameFSM(invader_move)を含む階層です。基本的には、

  • GameFSMモジュール --- ゲームのシナリオを実行するFSM (BSV⇒Verilog)
  • パターンROM --- インベーダその他のビットマップを格納するROM (Xilinx IP)

の2つのモジュールにより、VRAMをR/Wすることにより絵を動かしています。この階層には、さらに以下のモジュールが存在します。

  • buttonsモジュール --- FPGAボード上のプッシュボタンと、PMODのジョイスティックインタフェースのOR取り (Verilog)

図%%.1
図412.1 invader階層


左矢前のブログ 次のブログ右矢

ソフトブロック解説

posted by sakurai on June 2, 2021 #411

ソフトブロック解説

ここから、簡単に各ソフトブロック階層の解説をします。全体ブロック図は過去記事に挙げてあります。全体ブロック図において、左から順に、clock階層、メモリダンプモジュール(ソフトブロック階層無し)、invader階層、VRAM階層、graphics階層、sound階層となっています。

clock階層

図411.1にclock階層の構造を示します。使用されているモジュールは全てXilinx IPです。

図%%.1
図411.1 clock階層

入力は
  • sys_clock --- 100MHzクロック
  • reset --- 負論理リセット

の2本です。出力は、

  • C921_6KHz --- 921.6KHzクロックであり、UARTのボーレートクロック
  • C60Hz --- 60Hzクロックであり、動画の1フレーム(tick)を決める基準クロック
  • C2MHz_FSMCLK --- 文字通り2MHzのFSMクロック
  • MCLK --- 11.289MHzクロックであり、サウンド用のマスタークロック
  • C40MHz --- 40MHzクロックであり、グラフィックのドットクロック
  • locked --- 負論理のリセット信号

バイナリカウンタ説明

  • c_counter_binary_0 --- clk_wizからの8MHzクロックを入力し、bit0(4MHz)、bit1(2MHz)、bit2(1MHz)と分周する。xslice_0はそのbit1(2MHz)を取り出し、C2MHz_FSMCLKとして出力する。
  • c_counter_binary_1 --- c_counter_binary_0からxslice_2はそのbit2(1MHz)を取り出し、c_counter_binary_1で0x411a(=16666)を計数したらリセットする。xslice_1ではその14bit(16.667msec=59.9988Hz)を取り出し、C60Hzとして出力する。これはデューティは50%ではないが、エッジを見るため問題ない。
  • c_counter_binary_2 --- clk_wizからの7.3728MHzクロックを入力し、bit0(3.6864MHz)、bit1(1.8432MHz), bit2(921.6KHz)と分周する。xslice_3はそのbit2(921.6KHz)を取り出しC921_6KHzとして出力する。

左矢前のブログ 次のブログ右矢

Space Invadersの構成と物量

posted by sakurai on May 31, 2021 #409

ブロック図

ブロック図をIP Integratorで示します。

図%%.1
図409.1 ブロック図

リソース使用量

各階層(ソフトブロック)のリソース使用量を図409.2に示します。

図%%.2
図409.2 リソース使用量

表409.1に示すように、BRAMの割合がかなり大きいです。全部で50個中、39.5個を使用しています。

表409.1
リソース 割合[%]
MMCM 20
BUFG 25
I/O 16
BRAM 79
FF 6
LUT 36

モジュール配置

各階層の配置状況を図409.3に示します。おもしろいことに、サウンドが4つのまとまりに分かれていますが、図409.4のように4つのステートマシン毎に固まっていました。

図%%.3
図409.3 モジュール配置図

図%%.4
図409.4 サウンド関係配置図


左矢前のブログ 次のブログ右矢

BSVによる歩行音の改善

posted by sakurai on May 28, 2021 #408

インベーダの歩行音

インベーダの歩行音は、現在は隊列に同期して出力されます。インベーダ一匹の歩行処理は60Hzで実施されるため、初期状態では55/60secに一度、最後の一匹では1/60secに一度歩行音が出力されます。

最後の一匹の時に、どうも歩行音が速すぎると思っていたら、過去記事のとおり、インベーダの数に応じた間隔で歩行音が出力され、必ずしも隊列の動作とは同期していないことが判明しました。アニメーションは、インベーダーの数に比例して徐々に速くなるのに比べ、サウンドは段階的に速くなるのは、どのような意図があるのでしょうか?

なるべくオリジナルに近づけるという方針から、今回はこれを実装します。

歩行音間隔タイマの実装

まず、過去記事の表を実装します。タイマ初期値の最大値は52なので6bitのレジスタが55個必要です。1から55までを使用しており、0を含めた56個を定義しています。

UInt#(6) inv_init_stimer[56] = {5, 5, 7, 9,11,12,13,14,16,16,19,19,19,21,21,21,21,24,24,24,
                         24,24,28,28,28,28,28,28,34,34,34,34,34,34,34,34,39,39,39,39,
                         39,39,39,46,46,46,46,46,46,46,52,52,52,52,52,52};

過去記事の歩行音間隔タイマの仕様に示すように、これはタイムアウトした際に、インベーダ数に応じた値でタイマを初期化するための表です。次に、歩行音間隔タイマ本体を実装します。

Reg#(UInt#(6)) inv_stimer <- mkRegU;

次に、サウンドパターンは4から7を繰り返すため、2bitのパターンレジスタを用意します。

Reg#(UInt#(2)) inv_spattern <- mkRegU;

初期化部分です。タイマの初期値は52とします。パターンの初期値は0とします。

        inv_stimer <= 52;
        inv_spattern <= 0;

隊の先頭で実施していた次のサウンド出力処理を削除します。

//          if (inv_ido != END_STATE) seq
//                sound(extend(inv_pattern) + 4); // from 4 to 7
//          endseq

その代わり、 全てのインベーダについて次の処理を追加します。

     // 全てのインベーダについて処理
     if (inv_stimer == 0) seq
           sound(extend(inv_spattern) + 4); // from 4 to 7
           inv_spattern <= inv_spattern + 1;
           inv_stimer <= inv_init_stimer[inv_no];
     endseq else seq
           inv_stimer <= inv_stimer - 1;
     endseq

これにより過去記事のような動作を行うはずです。⇒実施したところ、正しく動作したようです。


左矢前のブログ 次のブログ右矢

posted by sakurai on May 27, 2021 #407

受信したデータは以下の図に示すように、一文字4bitのデータが連続する、VRAM内容を示すログデータです(右側を一部省略)。

図%%.1
図407.1 受信データ(部分)

VRAMデータ4bitの意味は以下のとおりです。

  • bit3: バリケード(シールド)=非画像情報
  • bit2: R=画像情報
  • bit1: G=画像情報
  • bit0: B=画像情報

従って、非画像情報を無視し、次のPHPにより画像フォーマットであるPPMに変換します。

log2ppm.php

 <?php
   print "P3\n256 256\n255\n";
   for($y = 0; $y <= 255; $y++) {
       $line = readline("");
       for($x = 0; $x <= 255; $x++) {
           $ch = hexdec($line[$x]);
           if (($ch & 0x4) != 0) echo '255 ';    // R
           else echo '0 ';
           if (($ch & 0x2) != 0) echo '255 ';    // G
           else echo '0 ';
           if (($ch & 0x1) != 0) echo '255 ';    // B
           else echo '0 ';
       }
       echo "\n";
   }

上記をフィルターとして実行し、ログデータを画像ファイルに変換します。

$ php log2ppm.php <putty.log >putty.ppm

生成されたファイルを画像処理ツールであるgimp2で開くと以下のように正常に受信されています。

図%%.2
図407.2 受信画像

以上で、ゲームのメモリダンプ機能がひとおおり完成しました。ゲームの状態を吸い出したのは、これをオートエンコーダによりCNNに認識させるのを目的としています。


左矢前のブログ 次のブログ右矢

posted by sakurai on September 18, 2020 #319

インベーダーゲームのソースの研究を読んで理解したことを記します。

UFOスコア表

参考にしたUFOスコア表です。

図%%.1
図319.1 UFOスコア表

BSV実装

この表には重なりがあるので、実は、表は1つで問題ありません。 弊社のBSV実装では以下の表を用いています。

UInt#(5) ufo_score[15] = {10,10,10,5,15,10,10,5,5,10,15,10,10,5,30};

ただし、インデックスの初期値を6としており、7番目から使用することで上記のアルゴリズムを再現しています。まず、インデックスの初期化です。

    ufo_score_idx <= 6;

次にインクリメント部です。この表は15エントリしかないので、15でラップアラウンドします。

       ufo_score_idx <= ufo_score_idx + 1;
       if (ufo_score_idx == 15) ufo_score_idx <= 0;

また、インベーダーゲームは得点の1の位は常に0なので、得点は1/10で記憶しています。

オリジナル

さて、ソースコードの研究によると、少々ズレています。

図%%.2
図319.2 UFOスコア表

コメントでも書かれているように、UFOスコア表は16エントリにも関わらず、バグにより15個までしか使用されず、15番目の次は0番目に戻っています。従って、最後の50点は使用されません。

結果として、上記は実装が微妙に異なるものの、最終的には同一の結果となります。


左矢前のブログ 次のブログ右矢

posted by sakurai on September 17, 2020 #318

インベーダーゲームのソースの研究を読んで理解したことを記します。

敵弾速度

参考にしたcellvaderにおいて、敵弾の移動速度は1pixcel/tickでした(tick=1/60sec)。それで特に違和感がなかったのですが、上記資料を見ると、33%も速い4pixcel/3tickとのこと。そのため、3tick毎に4pixcel動かすように修正しますが、注意として衝突判定は1pixcel毎に行う必要があります。そうでないとすり抜けが起きる可能性があります。従って、

タイムフレーム0: 何もしない
タイムフレーム1: 何もしない
タイムフレーム2:
 y-1の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
 y-2の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
 y-3の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
 y-4の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
 y-4の位置に敵弾移動

この3フレームを繰り返すことになります。さらに、インベーダ―数が8未満の場合は敵弾速度が高速化するとのことです。具体的には5pixcel/3tickとなります。従って以下のようになります。

タイムフレーム0: 何もしない
タイムフレーム1: 何もしない
タイムフレーム2:
 y-1の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
 y-2の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
 y-3の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
 y-4の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
 y-5の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
 y-5の位置に敵弾移動

歩行音

フリートトーン(fleet tone)、もしくはステップサウンド(step sounds)と書かれていますが、インベーダーの歩行音のことです。同じく参考にしたcellvaderでは、歩行音の発生間隔は1tone/1fleetでした。つまり隊の動作と歩行音が同期しています。ただし、歩行音の発生毎に4種類の歩行音を切り替えます。

ところが、インベーダーゲームのソースの研究では、隊の移動と歩行音は同期しておらず、歩行音間隔の最小は5だとのことです。具体的な表を示せば、オリジナルのアルゴリズムは以下の表318.1のようになります。確かに、現状の実装ではインベーダー数が1になる場合は歩行音が速すぎる気がします。原文には5未満になると不愉快な音になると書かれています。

表318.1 オリジナルの歩行音間隔表
インベーダー数[匹] 歩行音間隔[tick]
55 52
54 52
53 52
52 52
51 52
50 52
49 46
48 46
47 46
46 46
45 46
44 46
43 46
42 39
41 39
40 39
39 39
38 39
37 39
36 39
35 34
34 34
33 34
32 34
31 34
30 34
29 34
28 34
27 28
26 28
25 28
24 28
23 28
22 28
21 24
20 24
19 24
18 24
17 24
16 21
15 21
14 21
13 21
12 19
11 19
10 19
9 16
8 16
7 14
6 13
5 12
4 11
3 9
2 7
1 5

そのため、現状での隊(rack)の先頭での歩行音処理を廃止し、次の処理を追加予定です。

  • 歩行音間隔タイマーを設置します。
  • インベーダー1匹の処理につき、歩行音間隔タイマーを1だけデクリメントし、タイマーがゼロになったら歩行音を鳴らします。
  • タイマーがゼロになったら、その時点のインベーダー数で上表を引き、歩行音間隔値をロードします。

インベーダーが減るたびに上表を引いて歩行音間隔値を変更するのではありません。それだとタイマーがゼロになる寸前でインベーダーが死ぬと新たなタイマー値がロードされ、歩行音間隔が約2倍の長さとなる不具合が起きる可能性があります。

歩行音が隊と同期はしていても不快な音にならないように、最小を5にするだけで良いような気もしますが。

ブログ記事で実装完了しました。


左矢前のブログ 次のブログ右矢

ゲームFSMとサウンドFSMの連携

posted by sakurai on June 5, 2020 #271

Ultra96においてBSVで開発

元々Verilog版では、コマンドバッファに書き込むだけで特に何もしなくても動作していました。今回BSVで再設計する際に、サウンドを4chとし、取りこぼしを避けるために考えたのがサウンドキュー(FIFO)でした。

図%%.1
図271.1 サウンドキュー

これはVivadoのFIFOジェネレータで作成したため、最小段数でもかなり深く1024段程度となっています。 実験したところ、確かに取りこぼしは無いのですが、一方、サウンドがゲームとズレて行き、まるでサウンドレコーダのような動作になってしまいました。そのため、FIFOを1段に修正しました。FIFOジェネレータでは1段のFIFOは作成できないのでVerilogで記述しました。1段のためFIFOと呼ぶのはおかしいのでコマンドバッファと呼ぶことにします。

コマンドバッファには、ゲームFSMからコマンドが来たことを示すフラグemptyを設け、書き込むと!emptyとなるようにします。サウンドFSMからは!emptyの時に新たにコマンドが来たと判断し、コマンドを読んだ後にemptyに変更します。

図%%.2
図271.2 1段バッファに変更

Artyボード移植後

Ultra96ではこれで動作していたのですが、Artyボードに移植後に自機増加音が無視されることに気づきました。サウンドFSMが取りこぼしているのだと推測し、再考すると、ゲームFSMが不必要に速いことに気づきました。DSOを接続して調べたところ、96.4%がウェイトだと判明したので、これを1MHzに落としたところ、動作するようでした。

ところが実験すると、依然として自機増加音(コマンドNo.9)が無視されるようです。そこで、ILAを接続して、

  • サウンドコマンド
  • サウンドFSMステート
  • コマンドバッファemtpy
  • サウンドFSM内部フラグ(fNO9)

を観測しました。最後の内部フラグfNO9は自機増加音がプリエンプトされないように割込みを禁止するためのフラグで、コマンドNo.9を受け付けた際にTrueになる信号です。

図%%.3
図271.3 ILA波形(NG)

図271.3はゲームFSMクロックを2MHzとして取得したものですが、フラグfNO9がTrueにならず、コマンドNo.9を無視しています。その原因は、サウンドFSMが受け取る前に次のコマンドNo.4を上書きしているためです。

従って、コマンドの書き込みの際にemptyである場合のみ書き込み、!emptyの場合は捨てる処理を行います(図271.4のマゼンタ矢印の処理を追加)。

図%%.4
図271.4 両側でemptyを確認するように修正

このように修正したところ、No.9の次のコマンドが!empty(=buffer full)のため捨てられることにより、図271.5のように受け付けられるようになりました。
図%%.5
図271.5 ILA波形(OK)

FIFOではないので、原理上取りこぼしは防げないものの、実用上これで動作するようです。

左矢前のブログ 次のブログ右矢


ページ: