超巨大基板の８０８０互換ＨＣＭＯＳ・ＣＰＵでＣＰ／Ｍを走らせてしまおうという、なんとも狂気なプロジェクトです！
［第２３回］
●ＭＥＭＲＤは使えませんでした
［第２１回］からの続きです。
あともう少し補足説明の追加をいたします。
ＭＹＣＰＵ８０から読み取ったアドレスバス、データバスなどのデータをメモリ（ＣＹ７Ｃ１３４７Ｇ）に書き込むときのタイミングパルスとして、当初はＭＥＭＲＤ、ＭＥＭＷＲ、ＩＯＲＤ、ＩＯＷＲの各信号を使うように考えました。
ところが実際にやってみますとどうもおかしいのですね。
データが思うように記録されません。
ＭＥＭＲＤがうまく利いていないようです。
はて？
そこで、しばし沈思黙考。
おお。
やっと気が付きました。
普通のＣＰＵと違って、ＭＹＣＰＵ８０ではメモリからの読み出しが連続して行なわれる場合には、ＭＥＭＲＤはその間は出っ放しになるのでした。
たとえばＪＭＰ命令（Ｃ３ＸＸＸＸ）の場合で考えてみますと、メモリからは３回の読み出し動作が行なわれます。
普通のＣＰＵでは当然ＭＥＭＲＤパルスが３回出力されるのでありますが。
わがＭＹＣＰＵ８０の場合には、その間は連続した１回のＭＥＭＲＤが出されるのでした。
もう記憶も定かではないのですが、おそらくＩＣをひとつでも減らしたいという切実な思いからだったでありましょうし、またたとえ毎回ＭＥＭＲＤを出力するようにしたとしても、何の得にもならないという考えからだったでありましょう。
しかし、こういう局面に出会ってみますと。
むむ。
普通のＣＰＵではＭＥＭＲＤが毎回律儀に出されていることには、それなりの意味があったのだなあ、とあらためて感じ入りました。
いやいや。
そんなところで感じ入ってみたってはじまりません。
ＭＥＭＲＤをなんとかしなければ。
そこで一計を案じました。
メモリからデータを読み出すときは、必ずＯＰｃｏｄｅｆｅｔｃｈかｒｅｇＷＲがアクティブになることに気が付きました。
メモリから読み込んだデータが命令の第一バイトであるならばそれはＯＰｃｏｄｅですからＯＰｃｏｄｅレジスタにラッチされます。
それ以外のデータならば、それは通常のレジスタか一時的に保存するためのワークレジスタにストレージされます。
ＯＰｃｏｄｅｆｅｔｃｈやｒｅｇＷＲは書き込みパルスですからレジスタに書き込む都度パルスとして出されます。
ですからそれを利用してＭＥＭＲＤとＯＰｃｏｄｅｆｅｔｃｈかｒｅｇＷＲのＡＮＤを取れば、結果としてＭＥＭＲＤが１バイトごとに出力されたのと同様の信号として得られると考えました。
［第１９回］の接続ケーブルのところの説明で「ＯＰｃｏｄｅｆｅｔｃｈ信号とｒｅｇＷＲ信号があとから必要になったので」と書いたのはそういう理由からでした。
そのようにしたところ、やっとまともにデータが取れるようになりました。
しかし。
データは取れるようになったのでありますが…。
●記録したデータの解析は大仕事でありました
とりあえずということで記録したログファイルはなんと１７ＭＢ以上もありました！
ＴＸＴファイルなのですが巨大すぎてメモ帳（ｎｏｔｐａｄ）などではとても開けません。
ＴｅｒａＰａｄでやっと開くことができました。
さすがＴｅｒａＰａｄはすぐれものです。
冒頭部分です。
ログファイルとして記録されています。
このログファイルをずっと後ろのほうまで調べていきましたら。
●おかしなところがみつかりました
やっと。
みつけました。
１２０４９８行〜１２０５００行は、アドレスバスは ０２１Ｅ〜０２２０ でデータバスは ＣＡ１６０２ （ＪＺ ０２１６Ｈ） になっています。
ところがその次の１２０５０２行では、アドレスが ０２Ｆ７ で、データバスは ＦＦ （ＲＳＴ７） になっています。
これはおかしい。
ここは条件ジャンプ命令ですから、条件が満たされたときはアドレス０２１６へ、条件不成立のときは次の０２２１へ行くべきところです。
なぜか、ここで突然暴走して関係の無いはずの０２Ｆ７に飛んでしまっています。
でもこのデータからは、その理由、原因まではわかりません。
ただ現象がみつかった、というだけです。
すると、この次はその原因をさぐらなければなりません。
が。
しかし。
その問題はちょっと置いておくことにいたします。
その問題とは別に、私としましてはどうしてもけりをつけておかなければならない問題がありました。
あ。
それはそれといたしまして。
この１２０５０２行という数字にもぜひともご注目くださいませ。
記録の先頭の第１３行からここまで、ずっとＭＹＣＰＵ８０の動作が正しいかどうかアドレスとコードを確認しながら追跡してきたのでありますよ。
この暑い中で、そりゃああなた、並大抵のことじゃありませんですよ。
そこんところをわかってくださいまし。
ま。
実を申しますと、途中ところどころ飛ばしながら、アドレスが正常な範囲にあるかどうかを確認しつつ飛ばし読みで追跡いたしましたです。
いくらなんでも先頭から１バイトずつ確認していたのでは、寿命が尽きてしまいまする。
で。
１２０５０９行の、アドレス ３Ｄ０２ つうのを見つけましたです。
ＴＫ−８０モニタプログラムは００００〜０２Ｆ３です。
アドレス３Ｄ０２はありえません。
それでそこから前に追求していきました。
まあ、死ぬほどの苦労ではありませんでしたけれど。
それでもしっかり疲れましたです。
年寄りにはきつい作業でありました。
お話を元に戻しまして。
その１２０５０２行、アドレスが ０２Ｆ７ で、データバスは ＦＦ （ＲＳＴ７） のところです。
ここはＲＳＴ７ですから、次のリターン先アドレスをスタックにプッシュしたあと、アドレス００３８にジャンプすべきところです。
そのあとの１２０５０３行〜１２０５０４行ではおそらくスタックと思われるメモリに次のアドレス（０２Ｆ８）をプッシュしています。
そこまではＲＳＴ７の動作としては正常です。
しかしその次の１２０５０５行ではなんと、アドレス ０２３Ａ に飛んでしまい ２Ａ０２３Ｄ が実行されています。
しかも実は、０２３ＡにあるのはＯＰコードではありません。
その部分のリストです。