実機が出ているうちにテストしておこうシリーズ。
秋川さんの P6 版ザ・コックピットにて、ゲームキーの割込み待ちの時間を何とかして高速化という話があった。
確かに何かとサボりがちな P6 であることを考えると、必要以上に待たされている気がしてくる。
今回はそこを計測。

TEST1 は通常キーで割込み中でのキー取得前のウェイト時間。
TEST3 はゲームキーの [$06] を投げて割込みが入るまでの時間。
カウント方法がそれぞれ違うので数字の大小では測れないが目安として。

ソースと D88 と P6 テープは以下。mode.5 page.1
keydelay_test

mk2SR で測ったところどちらも 0 か 1 くらいという結果。写真は撮ったが載せるまでも無し。
P6VW だと TEST1=$16 TEST3=$2E くらいだった。これはあからさまに遅い。サボりすぎ。
実機の方は何か間違っている気がしないでもない。

あるいは機種によって違ったりするのだろうか。

昔作りかけだった、バイナリを CLOAD 形式にくっつけて最終的に MP3 にするスクリプトが発掘されたので苦労して Python3 用に書き換えた。
せっかくなので 88 で進行中のものを P6 用に改造して動画でも撮ってみようかと思う。例によって音ネタなんだけどさ。


うぐぐ、ORG 決定するときの if〜elseif 周りの書式がバグっていた。
MODE==1 || MODE==3 は (MODE==1) || (MODE==3) のように書くのだった。

2022 年にもなって何だけど N60 BASIC に XOR が無いことにショックを受ける。
しかも何気にエラーも出ずに通ってしまうという… X OR 扱いになっているのか?
A=(-1-A) AND 255 とかで代用するしかないか。




とりあえず出来た。
一応導入記事も書いたけど、現状では正直人にはお勧めできない。顛末記的な感じにしかならんかも…。
・ADPCM が鳴らない。OS を古い安定版に変えても鳴らない。
・そもそも ADPCM を転送する段階で謎のデータ化けが発生する。
・放置しておくと無反応になって落ちることがある。FM/PSG/SCC のみの限定使用にも不安がつきまとう。
・ラズパイのアナログオーディオ出力が特殊かつ低品質で、工作費等々で結局追加出費が必要になり安価とはいえなくなるかも。
古い OS の場合 FM のみのデータでも重いものは音飛びが酷かった。対策は色々調べてみたけれど、おまじない or ご機嫌伺いレベルしか見つからず。

カメレオン的な音源の仕組み自体には未来を感じるが安定して使えないのは惜しい。
ソフトのアップデートで何とかならないものか。
68k 側のプログラムを読んでみた推測としては P6 の I/O 叩きが遅いのも一因かもしれない。だとすると PCM8 とか夢のまた夢だなぁ。

あと P6 の遅さを見くびっていた。
ADPCM が鳴らせないので FM 音源オンリーの曲鳴らしてみたら、それでも処理落ちするという事実。MSX に負けとる。
動画は PC66R と表示しているが、これは I/O $F6 を使っているのと(mk2/66 以降), BUSREQ OFF(SR 以降) の意味。
つまり画面が mode.1 相当かつ 16KB RAM なだけで、かなりチートしている。
ただ、この MDX ファイルが異常に重いだけで、普通のファイルはここまで弄らなくても快適に動く（誰に言い訳しているんだ…）。