xsnake さんの報告の理由を調べたところ、 CPU address $c800-$dfff で取得する data が不安定になっていました。 この address は $c800-$dfff となりますが、 A15 = 0 の場合 (カートリッジの信号では ROMSEL# = H)は $4800-$5fff となり、この address は internal RAM access port となります。
いままであまり大きく書いていませんでしたが、 kazzo ではこの address にある RAM やレジスタへ正常にアクセスすることができません。kazzo という用途で問題になるのは 163 と MMC5 の internal RAM の2件だと思います。
つまるところ kazzo では USB 機能がない、並列に動けない V-USB というライブラリで無理矢理 USB 通信をしている関係で、波形制御はものすごく雑です。当時作ってるときはそこまで気が回らなかったのですが、いろいろ機材をそろえたり本物の CPU の波形をみると実に雑な動作をしています。
話を戻しますと、 ROMSEL# は ~(A15 & φ2) となるので純粋な A15 を得ることが出来ません。このため CPU address $0000-$7fff の波形はタイミングをしっかりやらないとデータが取れないわけですが、なぜか $6000-$7fff にある SRAM は大体の場合正常に read/write ができています。
とはいえここまで深い考察ができるようになったのもここ最近の話で自分の設計が如何に雑であったことをいまさら痛感しております。根本的な解決をするにはハードとして USB 機能を持つ AVR を使うか、 CPLD などで厳密にタイミングをつくったり、ちゃんと計測機器で確認すべきという基本的なことだと思います。
いまの kazzo でもこの部分を直せる方法(ファームウェア部)があれば教えてください。いま kazzo の開発まで手が余り回らないので派生版を配ってる人が直して欲しいです。
修正スクリプト
話がそれましたが、いままで自分が確認したときになぜこの不備が発生しなかったのが謎です。前述の通り、namco 163 を使用した $c800-$dfff へのアクセスにはファームに問題があり直せないと思いますので、 この領域へのアクセスを避けるしかないと思います。
function cpu_dump(d, pagesize, banksize)
{
for(local i = 0; i < pagesize - 1 ; i += 1){
cpu_write(d, 0xe000, i);
cpu_read(d, 0x8000, banksize);
}
/*
note: databus conficts on $c800-$dfff. ($c800-$dfff & $7fff) are internal RAM port....
Unfortunately kazzo generates incomple read wave form. do not use $c800-$dfff.
*/
cpu_read(d, 0xe000, banksize);
}少しそれますが、 $c000-$c7ff は問題ありません。
