MSXのWait動作
2025.10.10
turboR upgrade boardの不具合というか仕様不備というか。
※という報告を8月あたりに貰っていたんだけど色々忙しくてやっと手を付け始めた。
R800時にVDPアクセスするとwaitがやたら(具体的には約8us)入るというのは周知の事実である。
が、このwaitは常に入るわけではなく、「連続してIOアクセスしたときに入る」。
つまり、前回のIOアクセスから8us経っていないときにIOアクセスすると、IOバスサイクルが発生する前にバスIDLEが発生する。
※なので、処理→VDPアクセス→処理→VDPアクセス、とするとIOウェイトは入らない。ある意味よくできている。
turboR upgrade boardのIO Waitも基本的にはこれと同じ動作をする。
ただ、これとは別に速度を高速化するために本物と違う動きがある。

※Z80 user manualから抜粋。
ここのTWがR800時には入らない。つまりIORQなどのパルス幅が本物より1clk短い。
まあこれで手元では動かないハードは無かったので問題なしとした(というか1clk短い設計にしたのをすっかり忘れてた)が、まずこの仕様ダメだった。やっぱり動かないハードあるらしい。
ここは仕様決めるときにコンフィグできるようにするべきだった←というあたりを修正中。結構根深い。
ちなみに、コンフィグからWAITを増やしても、前述の連続アクセス時のバスサイクル前のIDLEが増えるだけで、IORQなどのパルス幅は変わらない。なのでそもそも短いパルスが拾えないハードはコンフィグ設定しても回避できない。
で、正直ロジックはわりと簡単に直せる。が、動作検証が厳しい。
前回リリースでやっちまったのが、「どワーストの個体差の機体を引き当てると、バスサイクルをちょっといじってタイミングずれただけで動かなくなる」というもの。
まあかなりギリギリな設計になっているからなんだけど。
少なくとも手元の環境では全数出荷検査してるのでそこまでワーストケースには当たってないんだけど、世の中そういう例があるってことがわかってしまったのでアップデート時はそれをカバーできる検証をしないといけない。クロック「ちょっと」早くするとか。むずい。
少なくとも前回リリースで「やっちまった」環境が再現できないと厳しい。うーん・・・。
※という報告を8月あたりに貰っていたんだけど色々忙しくてやっと手を付け始めた。
R800時にVDPアクセスするとwaitがやたら(具体的には約8us)入るというのは周知の事実である。
が、このwaitは常に入るわけではなく、「連続してIOアクセスしたときに入る」。
つまり、前回のIOアクセスから8us経っていないときにIOアクセスすると、IOバスサイクルが発生する前にバスIDLEが発生する。
※なので、処理→VDPアクセス→処理→VDPアクセス、とするとIOウェイトは入らない。ある意味よくできている。
turboR upgrade boardのIO Waitも基本的にはこれと同じ動作をする。
ただ、これとは別に速度を高速化するために本物と違う動きがある。

※Z80 user manualから抜粋。
ここのTWがR800時には入らない。つまりIORQなどのパルス幅が本物より1clk短い。
まあこれで手元では動かないハードは無かったので問題なしとした(というか1clk短い設計にしたのをすっかり忘れてた)が、まずこの仕様ダメだった。やっぱり動かないハードあるらしい。
ここは仕様決めるときにコンフィグできるようにするべきだった←というあたりを修正中。結構根深い。
ちなみに、コンフィグからWAITを増やしても、前述の連続アクセス時のバスサイクル前のIDLEが増えるだけで、IORQなどのパルス幅は変わらない。なのでそもそも短いパルスが拾えないハードはコンフィグ設定しても回避できない。
で、正直ロジックはわりと簡単に直せる。が、動作検証が厳しい。
前回リリースでやっちまったのが、「どワーストの個体差の機体を引き当てると、バスサイクルをちょっといじってタイミングずれただけで動かなくなる」というもの。
まあかなりギリギリな設計になっているからなんだけど。
少なくとも手元の環境では全数出荷検査してるのでそこまでワーストケースには当たってないんだけど、世の中そういう例があるってことがわかってしまったのでアップデート時はそれをカバーできる検証をしないといけない。クロック「ちょっと」早くするとか。むずい。
少なくとも前回リリースで「やっちまった」環境が再現できないと厳しい。うーん・・・。