26:プリンセスミネルバ,イース3/停まる

最終状態:完了
report#26.1
投稿者:nidone
時刻:2018-02-09 21:11:09
状態:新規
頻度:ときどき起きる
再現方法:
起動直後のビジュアルシーンで高確率で停まる。
ソフト起動直後、何もボタンを押さないでいると始まるビジュアルシーンにて、
主人公が指を挿すシーンで高確率で停まる(8回中6回)

スタートボタンを押してタイトルへ進めば回避。

タイトル後のビジュアルシーンでも、たまに停まったり、音が飛んだり不安定。
この場面はスタートボタンで飛ばせない。
report#26.2
投稿者:na6ko
時刻:2018-02-11 16:31:25
状態:受付済
頻度:ときどき起きる
指をさしているシーンは私のための親衛隊よ!っていってる部分だと思います.
確かに不安定です.調査いたします.
report#26.3
投稿者:na6ko
時刻:2018-03-24 12:57:35
状態:受付済
頻度:ときどき起きる
このソフトは現状は個別に解析していないのですが、ADPCMコントローラにだいぶ手を入れたのかだいぶマシになっているみたいです.
最新版では長時間放置してもとまらないことは確認してますが、ADPCMのボイスがたまに途中で切れています.
report#26.4
投稿者:na6ko
時刻:2018-04-21 22:57:23
状態:受付済
頻度:ときどき起きる
解析したところ ADPCM の初期化と追記は下記の手順で行なわれる.

初期化
1. READ(6) を発行. 転送先を ADPCM 向け RAM にして転送. (0x20sectors).
2. IRQ の割り込み許可を再生完了(w3=1),再生バッファ残り半分(w2=1)に設定.
3. ADPCM を再生開始. 

残り半分→追記開始
4. IRQ2 が発生; 理由:残り半分
5. w2 = 0
6. READ(6)発行. (0x10 sectors)
7. CD-ROM読み込み完了割り込みを発生. (w6:5 = 2'b11; w6 = 0)

追記完了→残り半分割り込み待ち
8. IRQ2 が発生; 理由:CD-ROM読み込み完了
9. その割り込み許可を停める (w5 = 0)
10. バッファ残り半分の許可(w2=1)

再生し終わるまで4から10をループで回す. 割り込み待ちの部分は待ち時間が長くその間に6280は別の作業をすることが普通.
report#26.5
投稿者:na6ko
時刻:2018-04-21 22:59:43
状態:受付済
頻度:ときどき起きる
(7.を訂正)

初期化
1. READ(6) を発行. 転送先を ADPCM 向け RAM にして転送. (0x20sectors).
2. IRQ の割り込み許可を再生完了(w3=1),再生バッファ残り半分(w2=1)に設定.
3. ADPCM を再生開始. 

残り半分→追記開始
4. IRQ2 が発生; 理由:残り半分
5. w2 = 0
6. READ(6)発行. (0x10 sectors)
7. CD-ROM読み込み完了割り込みを許可. (w6:5 = 2'b11; w6 = 0)

追記完了→残り半分割り込み待ち
8. IRQ2 が発生; 理由:CD-ROM読み込み完了
9. その割り込み許可を停める (w5 = 0)
10. バッファ残り半分の許可(w2=1)

再生し終わるまで4から10をループで回す. 割り込み待ちの部分は待ち時間が長く
その間に6280は別の作業をすることが普通.
report#26.6
投稿者:na6ko
時刻:2018-04-21 23:10:10
状態:受付済
頻度:ときどき起きる
このソフトだけの問題としては、CD-ROM読み込み完了に関する IRQ2 の設定タイミングを調整することで改善した.

2つの割り込みの制御は下記が担当する.
残り半分割り込み → HDL.ADPCM controller
CD-ROM読み込み完了 → MCU.scsi.c

この問題が不安定な原因はソースコードで * の部分である.
disc_done_cdrom()

	cdimage_cdrom_dma_end(s->cdimage);
	//bios 0xeb78 付近を使う場合 0x200 byte 読んで, 0x800 byte 読み捨てるという処理が入っておりハードできれいに同期が取れないのでwaitをいれる
*	//_delay_ms(10);
	cdrom2_irq_done_set(s, 1);
	ack_wait_out(C_DATA_IN, 0, W_INTERRUPT | C_STATUS);

_delay_ms() を削除することで安定する. ただしその上に書いたコメントが bios 0xeb78 のためにいれているので消すとまずい気がする. また該当ソフト名が書いてないのでそれを再度調べ直す必要がある.

この問題の発生頻度が不安定な原因は MCU 制御であること. つまり、 MCU の動作時間は upergrafx の video の空き時間に実行するしソフトで _delay_ms() をいれるのは実際の待ち時間にかなりばらつきがあるためと思われる.
report#26.7
投稿者:na6ko
時刻:2018-04-22 00:10:59
状態:受付済
頻度:ときどき起きる
この対策を入れたのは精霊戦士スプリガンのため.
report#26.8
投稿者:na6ko
時刻:2018-04-22 00:32:01
状態:受付済
頻度:ときどき起きる
イース3でも同様の修正で安定する.
ただしこの時間設定をソフトのソースコードでやるには無理がある結果となった.
イース3は待ち時間が少ない値(_delay_us()の引数400以下)が必要に対して、精霊戦士は多い値(同関数の引数800以上)を求める.

抜本的対策はハードウェアでの精度の高い同期調整が必要である.
report#26.9
投稿者:na6ko
時刻:2018-04-22 14:23:53
状態:修正済
頻度:ときどき起きる
精霊戦士スプリガンは 6280 から読み込む場合にこの wait が必要.
YS3とみねるばは ADPCM controller から読み込み、そこから割り込みをかける場合にこの wait が不要.

ということでソフトでこのための分岐を追加したことで改善した.
この対処は暫定的な物であるので、再度この部分の改善が必要な場合はハードウェアでタイミングを調整するようにする.

確認用に ys3 とブライ2でADPCM長時間再生をするセーブデータを添付.
report#26.10
投稿者:na6ko
時刻:2018-05-04 18:01:26
状態:完了
頻度:ときどき起きる
第3者から確認が取れたので終了.