ロジアナが手に入り、CPUの詳細な動作状態がわかるようになったので、動画と音声の同時再生の可能性について検討してみたいと思います。 

計測結果とその妥当性

まず、計測から得られた情報です。 以下は、VDGによる1ライン分のBUSREQ/BUSACKのタイミングを取ったものです。

	BUSACK=L	BUSACK=H
水平帰線	40.16us	22.64us
垂直帰線		4482.32us

BUSACK=Lのときは、MC6847(VDG)からのDMAが動作していて、CPUは完全に停止しています。 多少測定誤差がありますが、Techknowの数値(1ライン＝63.5us)とほぼ符合します(図では62.8usと出ています)。 一画面分(192ライン)、1秒60フレームとして逆算すると、

(1,000,000 / 60) - (63.5 x 192) = 4,474.67us
  

となり、垂直帰線の数値もほぼ符合しています。

1画面の描画の間で使える時間は、おおよそですが以下のとおりです。

1水平線: 40us ≒ 160 T-states
1垂直線: 4474.67us ≒ 17870 T-states
1画面分: 40us x 192 + 4474.67us ≒ 48,541 T-states
  

T-stateの計算にクロック(3.993600MHz)を使っています。 丸め誤差が発生していますが、ここではとりあえず置いておきます。

1画面描画にかけられる時間

以上から、1画面にかけられるのはおおよそ48,500 T-statesとなります。 128x96ドットのモードの場合は、VRAMの容量は1,536バイト。 以前ムービープレイヤーを最適化していたときに計算したT-statesの平均値が37,000ほどだったのですが、この数値はWAITを入れていません。 すべて1バイト命令であるという単純な仮定で計算しなおすと、

37,000 x (5 / 4) = 46,250 T-states
    

となり、けっこうぎりぎりです。 ただし、これには2msecのクロック割り込みの時間なども入っています。 圧縮も何も考えずに単に1,536バイトのldirを行うとすると、WAITを考慮して33,787 T-statesです。 セットアップやらいろいろ考えても何とかなりそうですね。

256x192ドットのモードの場合は、VRAMの容量は6,144バイト。 以前のムービープレイヤーでは142,000 T-states (WAIT考慮なし、クロック割り込み時間込み)でした。 WAITを考慮したldirのみの実行時間でも135,163 T-statesです。 話になりません。

もっとも、これは秒間60フレームの描画を前提にした計算ですから、以前のように秒間15フレームにすれば4倍の時間、およそ185,000 T-statesかけられるということです。 処理のタイミング合わせは複雑になりそうですが。 128x96ドットなら音声も含めて再生が期待できそうです。

水平帰線期間中の処理の可能性

水平帰線期間中に1ライン分描画できるでしょうか。

128x96ドットのモードを使うとすると、縦1ドットに対して2水平線分の時間を割くことができますから、320 T-statesとなります。 これなら128ドット分(16bytes)の転送と音声の発声が何とかなるかもしれません。

ちなみに、256x192ドットのモードだと、160 T-statesで256ドット分(32 bytes)の転送となり、画像だけで5 T-state/byteしかかけられません。 M1ステート時のWAITを考慮すると、転送系最速のpush/popを使っても12/11 T-statesかかるため、この時点でアウトです。

ただ、PC-6001の場合は垂直帰線時間で描画しても問題ないので、それほど深刻ではないかもしれません。

問題点

さて、ここで以下の問題があります。

1. RAM空間ではM1ステートで1クロックのウェイトが入ります(調査の結果、ROM空間ではアクセスのたびに1クロックWAITが入ります)。 また、CB/DD/ED/FD prefixを持つ命令や、IN/OUT系ではさらにそれぞれ1クロックづつWAITが入ります。 これらを考慮して設計する必要があります。
2. VDPが画面を描画中のときは、CPUがVRAMにアクセスしたら停止するわけではなく、完全停止です。 そのため、MC6847が描画中に表示データのセットアップをすることができません。
3. 垂直・水平帰線期間中であることを検出する術がありません。 特に垂直帰線時に行う処理のタイミングが計れないので、致命的かもしれません。

以上は通常、他機種では問題の出ない部分でしょう。 例えば、MZ-700では上記の2, 3を活用しています。

3.を何とかすることはできるのでしょうかね? BUSACKは拡張ポートにも出ていないため、信号変化をトリガーに割り込みをかけるのも、本体に手を入れない限り難しそうです。

これまで、VDGのタイミングが全くわからなかったため、盲目状態で行っていたタイミング計算がだいぶ正確に把握できるようになってきました。ロジアナって便利ですね...。

ただ、タイミングあわせについてはもう少し調査が必要です...。