実機でおかしくなるのはバンク切り替えの問題ではなかった。
色々削ってみてるけどなんかずれてる。
Yスクロールの値が定期的にズレるっぽい雰囲気。
レーザーの書き込みではないし、スクロールのネームテーブル書き込みを止めてもダメで、レーザーの本数を一本まで減らしても点滅するので、何処かの修正がまずかったっぽい気がするが、$2000の書き込みとかいろいろ変えたり削ったりしても起きてる。
実機でしか起きないのは面倒…。色々試したけど原因不明。なにかハードに関わる処理を変えた時には実機動作も確認しないとどこでおかしくなったか判別不能だ
過去バージョンの.nesを全部実機に焼いてみてどこでおかしくなるかを調べる、とかが簡単そうか。
GitHubから全バージョンの.nesを落として実機で動かしてみたら、21/02/28のNMIで処理するのをやめてMainで全ての処理をするようにしたところから実機動作がおかしくなってた。
試しに今のNMI相当の処理を戻してみたら、実機でも直らないが、FCEUXは処理落ちするだけで動いているが、Nestopiaは実機と同じおかしさになってたのでここで原因を調べたらなにかわかるかも。
いまほどGitHubに上げといてよかったと思ったことはない。これがなかったら詰んでた
Nintendodulaterの再現度がとても高い事がわかったので、Windos環境で動かすことにした
Windows用のNESASMをセットアップしたが、
#[1] lasterScrollTest.asm
313 00:8176 .include "padInput.asm"
みたいなエラーが出て .include と .incbin が通らない。
ググってみたら、まさかの「先頭にスペースが必要」だった。Mac版はなぜか通る
http://forums.nesdev.com/viewtopic.php?t=6154
Nintendulatorでステップ実行して止めた結果、壊れ方としては「IRQが0フレームで掛かっている」という壊れ方に見える。
NMIでIRQを設定してたときには安定してたけど、MainLoopに移動したら正しいタイミングでIRQが指定できなくなっているのかも
NMIでnmiProcとMainLoopを動くようにして、MainLoopの先頭でモノクロにして終わったら戻すようにしたら、壊れてるフレームではモノクロになっていなかった。→ MainLoopがまともに動いていないとか？、NMIがちゃんとよばれてないとか。
NMIが1フレーム飛ぶ説はあるかも。資料も調べる
そしてこれは、FCのエラッタである。「NMI割込中に、すでにセット済のNMI割込フラグをセットすると、すぐさま次のNMIが呼ばれる。」──したがって、BGMが速くなるのはバグでなくFCのエラッタであり、そして飛空艇の速度向上もまた然り。https://t.co/3EtVp0j7Vl
— 宮内悠介 (@chocolatechnica) 2018年10月30日
挙動的にこの辺が怪しいかも
「読書PPUSTATUSことを正確に同じ時間で（$ 2002）PPUSTATUSは7ビットは、垂直ブランキングの開始時にハイになり、すべてで起こって高いから$ 2002.D7を保ち、そのフレーム。（回避策：NMIを使用して垂直ブランキングを待機します。）
- 一方でPPUSTATUSは7がセットされたビットのNMIを有効にする1つの変更（場合、PPUCTRLは7ビット）、それはすぐにNES CPUに新しいNMIをトリガします。これは、NMIがフレームに対してすでに通知されている場合でも、垂直ブランキング中にあり、コードがまだPPUSTATUSを読み取っていない限り、発生する可能性があります。（回避策：NMIを有効にする直前にPPUSTATUSを読み取ります。）」
この辺も。
MainLoopの bit $2002 のループにnopをいっぱい挟むと点滅しにくくなるので、どうも↑っぽい。何か回避策がありそうなので調べる
メモ：この辺を参考に初期化コードを書こう
