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

UFOスコア表

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

図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で記憶しています。

オリジナル

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

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

Javascript実装

最後に、Javascriptによる実装でも同様なアルゴリズムにより、自弾ショット数の15の剰余を取った数に6のオフセットをかけています。

const // UFOスコアテーブル us = [100,100,100,50,150,100,100,50,50,100,150,100,100,50,300];

const plus = us[(6 + shotCount) % 15];

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

---

前のブログ 次のブログ

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

敵弾速度

参考にした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となります。従って、上記のフレーム2においてさらに「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にするだけで良いような気もしますが。

Javascript実装

Javascriptによる実装では、インベーダ数=55の時に52、インベーダ数=1の時に5と、上表と同様ですが、その間は線形補完しているようです。

---

前のブログ 次のブログ

Ultra96においてBSVで開発

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

図271.1 サウンドキュー

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

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

図271.2 1段バッファに変更

Artyボード移植後

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

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

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

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

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

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

図271.4 両側でemptyを確認するように修正
このように修正したところ、No.9の次のコマンドが!empty(=buffer full)のため捨てられることにより、図271.5のように受け付けられるようになりました。 図271.5 ILA波形(OK)
FIFOではないので、原理上取りこぼしは防げないものの、実用上これで動作するようです。

---

前のブログ 次のブログ

QSPIフラッシュへの書き込み

通常ではVivadoからPROGRAM AND DEBUG⇒Open Hardware Manager⇒Open Target⇒Auto Connectとし、Program DeviceによりJTAG経由でFPGAにビットストリームを焼きこみます。しかしながらこれだと電源断によりFPGAのSRAM内容が消えてしまいます。また、FPGAプログラミング用のPCが常に必要です。オンボードFlashにデータを焼きこめばPCを持ち運ぶ必要がなく、電源onでアプリケーションが立ち上がるため、Flashのプログラミングを行います。

binファイルの作成

最初にFlashへ書き込むデータファイルであるbinファイルを用意します。これは、Tools⇒Setting(歯車マーク)⇒Project Settings⇒Implementation画面で行います。この画面を開くと、Write Bitstream(write_bitstream)という選択枝が現れ、その下に複数のチェックボックスが表示されます。その中の、-bin_file*のチェックボックスにチェックします。

図270.1 bin_fileにチェック

これを行ってから、通常どおりPROGRAM AND DEBUG⇒Generate Bitstreamを実施するとWrite Bitstreamが完了しますが、同時にbinファイルが生成されています。場所はbitファイルと同じところで'プロジェクト/プロジェクト.runs/impl_1/'です。

binファイルの焼きこみ

binファイルができたら、Add Configuration Memoryにより、Add Configuration Memory Device画面が開きます。Flashデバイスの選択が可能なので、この中で"s25fl128sxxxxx0"を選択します。Search窓にs25fl128を入力すれば、候補が3つ現れますがその真ん中です。

図270.2 FLASHデバイスの選択
選択したらOKをクリックします。するとプログラミングが始まり、30秒程でプログラミングが完了します。

実行

リファレンスマニュアルにはJP1でプログラミングモードが決まるとあります。JP1の位置がどちらでもJTAGからは書き込めるとのことです。初期状態はJP1はショートで、SPI-FLASHのモードとなっており、そのまま電源のOFF⇒ONでSpace Invadersが立ち上がりました。

図270.3 JTAG接続なしにSpace Invadersが動作

---

前のブログ 次のブログ

Arty A7-35ボードの購入

DigilentからArty A7-35ボード(魚拓)を購入しました。このボードはUltra96と比べて本体が約半額と安いだけでなく、(弊社開発の)PMOD変換ボードも不要なので、最も安くSpace Invadersを動かすことができます。

必要な周辺

Space Invadersを動作させるには、Artyボードの他に必要なものは以下のとおりです。

• 12V電源
• PMOD I2Sインタフェース(オーディオDAC)カード
• オーディオケーブル 図269.1 PMOD I2Sインタフェースとケーブル
  
• アンプ付きミニスピーカ 図269.2 アンプ付きミニスピーカ
  
• PMOD VGAインタフェースカード
• VGA/HDMIインタフェース 図269.3 PMOD VGAインタフェースとVGA/HDMIインタフェース
  
• VGA/HDMIインタフェース用5V電源
• HDMIケーブル
• PMOD JOYスティック・スイッチインタフェース(弊社開発) 図269.4 PMOD JOYスティック・スイッチインタフェース
  
• JOYスティック・スイッチ(弊社開発) 図269.5 JOYスティック・スイッチ
  
• Micro-B USBケーブル 図269.6 Micro-B USBケーブル
  図269.7に、これら周辺を全て接続したArtyボードの写真を示します。 図269.7 Artyボードに周辺を接続
  

Arty A7-35ボードへの移植

FPGAの世代や遅延、容量は違うものの、基本的には同様に動作するはずです。ところが、一部動作がおかしかったので修正しました。まず、除算器にバグがあるようなので引き算方式に修正しました。スコアを表示する箇所において、各桁表示のため1000、100、10で割る場合がありますが、1000で割った商を誤ることがあるようです。除算をやめ、引けなくなるまで1000、100、10を引く方式に変更したところ、回路規模も小さくなり正常に動作するようになりました。

FSM clockを1/10に変更

ゲームFSMクロックを10MHzで設計し、96.4%がウェイトだと判明したので、FSMクロックを1MHzに落としました。自機増加音が無視されることがあるので、クロックを落としたのですが、原因は異なっていました(後述)。

60Hzクロックの生成

この修正により、FSMの待ち時間が影響を受けます。1tick=60HzのタイミングをとるのにFSMクロック数を数えていましたが、FSMクロックの周波数が変わるため、外部から60Hzを入力するように修正します。60Hzクロックは、上記FSMクロックである1MHzクロックをバイナリカウンタで\$411B回カウントすることで生成します。さらにFSM内での60Hzクロックとの同期は以下のように行います。countはtick(=16.67msec)の何倍待たせるかを示す引数です。

     repeat(pack(extend(count))) seq
        await(tick == 0);
        await(tick == 1);
     endseq

60Hzクロックの"L"を待ち、もし"L"であれば次に"H"を待つようにします。これにより60Hzの立ち上がりに同期して動作することになります。

このように変更した結果、FSMの処理時間は10倍の約5msecに増加し、60Hzの周期16.67msecの約30%になりました。図269.2の黄線が60Hzクロック、青線がそれによる実行(Hでウエイト中、Lで実行中)を示します。

図269.8 青線が"H"でウェイト中

---

前のブログ 次のブログ

過去ブログの、BSVによるスペースインベーダーの再設計の記事#234~#239, #254をまとめてQiitaに投稿しました。さらに考察を加えています。

BSV (Bluespec SystemVerilog)によるスペースインベーダーの再設計

過去ブログ記事でUltra96ボードを用いた、VerilogHDLによるSpace Invadersゲームの作成を投稿しましたが、その続きです。

図255.1 Qiitaの投稿記事

---

前のブログ 次のブログ

ゲームFSMのアルゴリズム

トライアルの結果、BSVによるゲームFSMが完成しました。過去記事のステートベースのサウンドステートマシンと異なり、ステート分解をしていないため、rule文を一切使用していません。全てbsc(Bluespec Compiler)の、StmtFSMライブラリにステート管理を任せました。

基本的にはCで記述するようにゲームが記述できることが分かりました。例えば、弾の移動及び衝突判定、衝突処理(爆発マーク)、爆発マーク消去等のアルゴリズムを考えると、自弾、敵弾共にアルゴリズムは共通で、疑似コードで書けば、

if (弾爆発タイマ >= 1) {   // 弾爆発中
    弾爆発タイマ++;
    if (弾爆発タイマ == MAX) {
        弾削除;            // 論理的な消去
        弾爆発マーク消去;   // 物理的な消去
        弾爆発タイマ停止;
    }
} else {
    if (弾が出ていない and 弾生成条件) {
        弾生成処理;
        弾発射音;     // 自弾のみ
    }
    if (弾存在) {
        衝突判定;
        if (対象物) {  // 自弾の場合はインベーダ及びUFO、敵弾の場合は自機
            弾削除;          // 論理的な消去
            対象物ステート <= 爆発;
            対象物爆発タイマ <= 0;
        } else if (上下ハズレ || ベース || 弾) { // 弾:自弾の場合は敵弾、敵弾の場合は自弾
            弾マーク消去;
            弾爆発マーク;
            弾爆発タイマ <= 1;
        } else {        // 衝突していない場合
            弾を進める;
        }
    }
}

一方、対象物は、

if (対象物ステート == 爆発) {
    if (対象物爆発タイマ==0) {
        対象物爆発タイマ <= 1;
        対象物爆発音;
        対象物爆発マーク;
    } else {
        対象物爆発タイマ++;
        if (対象物爆発タイマ == MAX) {
           対象物削除;          // 論理的な消去
           対象物爆発マーク消去; // 物理的な消去
        }
    }
}

のようになりますが、StmtFSMを使うと、このようなシーケンスをクロック毎のステートに分解しなくて記述できます。

インベーダのタイミング

某所で質問があったので、タイミングについて解説します。基本の1 tickは1/60秒で、その中で、インベーダ1匹、敵弾全弾、自機、自弾、UFO、スコア等の処理を行います。以下は実際のBSVのメインループのコードです。

 while (game_flag) seq // メインループ
    for (noy <= 0; noy < `Inv_TateS; noy <= noy + 1) seq  // インベーダの行処理
       for (nox <= 0; nox < `Inv_YokoS; nox <= nox + 1) seq // インベーダの列処理
          if (inv_s[nox][noy]) seq // インベーダが生きてれば
             ivader;      // インベーダ処理
             gun;         // 自機処理
             bullet;      // 自弾処理
             for (idx <= 0; idx < extend(max); idx <= idx + 1) seq
                invBullet(idx);  // 敵弾全弾処理
             endseq
             ufo;         // UFO処理
             scores;      // スコア表示
             endJudge;    // 終了判定
             counter <= counter + 1;  // tickカウンタ++
             wait_timer;  // インナーループを1/60secにするウエイト
          endseq
       endseq
    endseq
 endseq
 gameOver;  // ゲームオーバー表示

1tick=1/60secの間に、インベーダ1匹(2ピクセル移動)の処理に対して、自機(1ピクセル移動)、敵弾(1ピクセル移動)、自弾(4ピクセル移動)の処理が行われます。インベーダは初期に55匹存在するので、1/55倍のスピードで始まりますが、最終的に1倍のスピードになります。従って、インベーダを倒すたびにインベーダ全体は速くなり、一方その他の速度は変わらないわけです。

FPGAでの実装では1 tick内にインベーダ全体を移動することは可能ですし、そのような実装も見ますが、ゲーム性が変わってしまいます。具体的には、インベーダ全体の速度が次第に速くならなかったり、後ろのインベーダを撃つことができなくなります。

例えば、インベーダゲームのレインボーは、後ろのインベーダを撃つことにより出現します。インベーダは残りが一匹になると左へは2ピクセルずつ右には3ピクセルずつ移動します。下2段のインベーダは、左右2ピクセルまでの移動では跡が残らない図形になっていますが、3ピクセルだと跡が消えずに残ります。もちろん今回の実装でもレインボーを体験できます。

ゲームFSMの完成

図254.1は、BSVで再設計したゲームFSMにより動作する、インベーダーゲームの動画です。過去記事に書いたように、サウンドが4ch同時発声と高品質になりました。

図254.1 ゲームFSMの完成

---

前のブログ 次のブログ

サウンドFSMの完成

ミキサーは4chある音源のミキシングを行います。ミキシングは符号無し8bit整数を16bitに符号拡張し、加算することで行います。サウンド平均化を試しましたが、かえって違和感が出るため、シンプルな加算としました。念のためにクリッピング処理を入れています。

完成したsound階層を図239.1に示します。

図239.1 Vivado sound階層ブロック図

従来回路図234.2と比べてサウンドチャネルが4倍になっただけでなく、ミキサー回路を新設したため、かなり大きくなっています。表239.1に各モジュールの物量(LUT数)を示します。LUTは使用個数は4,216個であり、全容量70,560個中の5.98%でした。またBRAMは使用個数は39.5であり、全容量216中の18.3%でした。

ゲーム全体の各モジュールの物量を表239.1に示します。色付け部分が今回BSVで開発したモジュールです。

表239.1　各モジュールの物量

モジュール	説明	物量			BSV行数	Verilog行数
		LUT数	LUT割合[%]	BRAM数
invader_move	自機、インベーダ、UFO、自弾、敵弾、スコア等を処理するFSM	3,239	76.7	0.0	ー	2,125
mkSoundFSM3	UFO音を演奏するFSM	197	4.7	0.0	448	939
mkSoundFSM2	インベーダ歩行音を演奏するFSM	192	4.6	0.0		950
mkSoundFSM1	インベーダ爆発音を演奏するFSM	190	4.4	0.0		922
mkSoundFSM0	自弾発射音、自機爆発音、自機増加音を演奏するFSM	184	4.7	0.0		957
mixer	4チャネルのサウンドミキサー	44	1.0	0.0	ー	30
graphic_control	VGA映像信号生成回路	38	0.9	0.0	ー	92
para_seri	サウンドパラシリ変換、タイミング生成回路	22	0.5	0.0	ー	101
sound_rom0	自弾発射音、自機爆発音、自機増加音を格納するROM	20	0.5	7.0	ー(IP)
sound_rom1	インベーダ爆発音を格納するROM	20	0.5	7.0	ー(IP)
sound_rom2	インベーダ歩行音を格納するROM	20	0.5	7.0	ー(IP)
sound_rom3	UFO音を格納するROM	20	0.5	7.0	ー(IP)
pattern_rom	自機、インベーダ、UFO、自弾、敵弾、スコア等の図形を格納するROM	7	0.2	3.5	ー(IP)
buttons	スイッチとボタンをORする回路	4	0.1	0.0	ー	21
display_out	ブランキング期間に表示を抑止する回路	3	0.1	0.0	ー	21
vram	ビデオRAM	2	0.0	8.0	ー(IP)
onestage	ゲームFSMとサウンドFSMの間のバッファ	2	0.0	0.0	ー	43
clk_wiz	クロック制御回路	1	0.0	0.0	ー(IP)

図239.2に全体のセルの配置図を示します。

図239.2 Vivadoセル配置図

例外動作

基本的に、サウンドエンジンはサウンド番号を受け、ROMに示されるサウンド長だけサウンドを演奏し、サウンド中に割込みが入る場合にはその割込みサウンドを演奏しますが、例外が2つあります。

• UFO飛行音 --- UFO飛行音ONでサウンドを演奏し、終了してもUFO飛行音OFFが来るまでは演奏し続ける。
• 自機増加音 --- 自機増加音演奏中に割込みが入ると聞こえなくなる場合がある。このため、自機増加音は優先サウンドとして扱い、他の割込みを受け付けない。

自機増加音は自弾発射音、自機爆発音と独立であるため、別チャネルとするほうが良いのですが、頻度が低いのと別チャネルにするとハードウエアが無駄のため、このような仕様としました。実験の結果、優先サウンドとしてもゲーム上特に問題はありませんでした。

---

前のブログ 次のブログ

サウンドFSMの作成(3)

FORMAT機能、DATA機能からコールされるREADCOUNT共通シーケンス及び、そこからコールされるREADMEM共通シーケンスを解説します。

   //  input:  romaddr
   //  output: (romaddr,...,romaddr+3) => dcount;
   //          romaddr + 4 => romaddr;
   //
   rule ruleREADCOUNT (state.func == READCOUNT);

      rule ruleS0 (state.step == S0);
         state.step <= S1;
         ret2 <= ret; // push to stack
         i <= 3;
         workd <= 0;
      endrule

      rule ruleS1 (state.step == S1);
         state <= State_t {cat:state.cat, func:READMEM, step:S0};
         ret <= State_t {cat:state.cat, func:READCOUNT, step:S2};
         worka <= romaddr + i;
      endrule

      rule ruleS2 (state.step == S2);
         if (i == 0) begin
            state <= ret2;
            dcount <= workd<<8 | extend(romdata);
            romaddr <= romaddr + 4;
         end else begin
            state.step <= S1;
            workd <= workd<<8 | extend(romdata);
            i <= i - 1;
         end
      endrule

  endrule // READCOUNT

図示すると、図238.1のようなステート遷移となり、リトルエンディアンで格納されている4バイトの数値を1バイトずつ4回取り出し、dcountにまとめる機能を持ちます。

図238.1 READCOUNT共通シーケンスステート遷移図

次にREADMEMはROMから1バイト読み出す共通シーケンスです。当初はwireを用いても階層の上り下りでレイテンシがかかり、7サイクルとなりましたが、後述のmkConnectionを用いたことにより、RTLと同様の3サイクルの設計とすることができました。

上記のREADCOUNTから呼ばれる際はサイクル数は無関係ですが、サウンド再生中は正しいスループットで読み出す必要があるため、過去記事にもあるように、コール元が1サイクルとコール先(READMEM)が3サイクルの4サイクルで1バイトを読み出す前提で、FSMのクロック周波数=176.4KHzを決めています。

   // READ MEM
   //  input:  worka
   //  output: romdata;
   //
   rule ruleREADMEM (state.func == READMEM);

      rule ruleS0 (state.step == S0);
         addr <= worka;
         state.step <= S1;
      endrule

      rule ruleS1 (state.step == S1); // ROM address phase
         state.step <= S2;
      endrule

      rule ruleS2 (state.step == S2); // ROM data phase
         data <= romdata;
         state <= ret;
      endrule

    endrule // READMEM

---

前のブログ 次のブログ

サウンドFSMの作成(2)

階層化ステートマシンを解説します。基本的にBluespecにおいてはrule文のガードによりステートに入る条件を定義し、rule文の内部でステートの処理を定義します。そこで、ruleを構造化することで、ステートの構造化を実現します。具体的には以下のような構造となります。

rule ruleSOUND (state.cat == SOUND);

   rule ruleFORMAT (state.func == FORMAT);

      rule ruleS0 (state.step == S0); 
         // call readcount();
         state <= State_t {cat:SOUND, func:READCOUNT, step:S0}; 
         ret <= State_t {cat:SOUND, func:FORMAT, step:S1};
         case (code)
            'h1: romaddr <=     0 + 16;
            'h2: romaddr <=  4318 + 16;
            'h9: romaddr <= 13094 + 16;
         endcase
      endrule

      rule ruleS1 (state.step == S1);
         state <= State_t {cat:SOUND, func:DATA, step:S0};
         romaddr <= romaddr + extend(dcount);
      endrule

   endrule // FORMAT

ruleS0ではcodeによりROMアドレス先頭を決定します。wave formatの16バイト目からフォーマット長取得を行います。readcount()をコールしており、そのリターンはruleS1ステートです。readcount()ではdcount変数に4バイトの数値が得られます。

図237.1 FORMAT機能ステート遷移図
dcountにフォーマット長が得られたので、次にデータ長を取得します。

 rule ruleDATA (state.func == DATA);

     rule ruleS0 (state.step == S0);
         // call readcount();
         state <= State_t {cat:SOUND, func:READCOUNT, step:S0}; 
         ret <= State_t {cat:SOUND, func:DATA, step:S1};
         romaddr <= romaddr + 4; // skip "data"
     endrule

     rule ruleS1 (state.step == S1);
         state <= State_t {cat:SOUND, func:PLAY, step:S0}; 
         romaddr <= romaddr - 1;
     endrule

  endrule // DATA

dcountにデータ長が得られたので、実際のサウンドデータを出力するため、PLAYに移行します。

図237.2 DATA機能ステート遷移図
PLAYにおいては4倍のインターポレーションを行うため、4回同じデータを出力します。

---

前のブログ 次のブログ