標準TTLだけ(!)でCPUをつくろう!(組立てキットです!)
(ホントは74HC、CMOSなんだけど…)
[第372回]

●完成してちゃんと動いています

配達時にご不在でまだ配達ができません、ということでこのページでご案内させていただいていた札幌市のKK様からメールをいただきました。
無事受け取りました、とのご連絡でした。
そのメールには「全部完成してTK80回路も動いています」と書き添えてありました。
KK様、ご連絡有難うございました。
完成おめでとうございます。

●TK80のプログラムが動きません

というメールをいただきました。
TK80とはレジスタのアドレスが違うのですね?
という確認のメールです。

うっかりしていました。
お尋ねの通りです。
TK80が売り出された当時は、メモリの集積度は非常に低く、RAMもROMもとても高価でした。
そのためTK80はアドレス8200〜83FFのわずか512バイトしかRAMを搭載していませんでした。
基板上にRAMを増設することができましたが、それでも最大1KBまでで、そのときのアドレスは8000〜83FFでした。

そういうハード上の制約から、TK80のシステムワークエリアはRAMの83XX番地に置かれていました。
一方、MYCPU80は32KBのRAMを搭載しています。
RAMのアドレスは8000〜FFFFの32KBです。
せっかく32KBもRAMエリアがあるのですから、このアドレスを有効に使えるように、と考えてシステムのワークエリアを83XXからFFXXに移動してしまいました。

TK80プログラムをそのまま走らせる、という互換性維持の観点から考えてみれば、ここは移動しなかったほうがよかったかも知れません。
もっともそうするとLED表示のためのDMAアドレスを83F8〜83FFにするためには、ちょっとハード回路の負担が大きくなってしまいます。

それは将来同様のボードをもしも作ることになったような場合には、検討の余地がありそうです。
しかしながら、MYCPU80ではそういう理由で、システムワークエリアについては残念ながらTK80と同じではありません。
ただ83XXをそのままFFXXに平行に移動しただけですから、もしも昔のTK80のアプリケーションプログラムなどを実行させてみたい、とお考えになった場合には、システムワークアドレスを指定している部分の83XXをFFXXに書きなおせば、TK80のために書かれたプログラムがMYCPU80の上でもそのまま実行できるはずです。
ただし、プログラムによってはLXI命令やSTA、LDA命令で83XXのようにアドレスを直接指定するだけではなくて、8ビットのMOV命令やMVI、CMPなどの演算命令でシステムワークアドレスの上位の値83をデータとして扱っているような場合もありますから、もしうまく動作しないような場合には、その点にも注意してみる必要があるかも知れません。

●正しいRZの回路は?

今となってはもうどうしようもありませんから、もしもRZ命令で誤動作が確認されましたら、前回説明いたしましたように、regWRのプルアップ抵抗の追加と、ヒゲをつぶすためのコンデンサの追加をする、という対策をとっていただくようにお願いいたします。

でも最初からこのことに気がついていましたら、もっと根本から回路を考えていたと思います。
ポイントはただひとつ、T4でMclrが出力されたときに、regWRがアクティブにならなければよいのです。
タイミングチャートで説明をします。

本当はこういうチャートになるようにするべきだったのです。
どこがどう変わったかといいますと、全体を後ろにずらして、T4、T5にダミーサイクルを入れただけなのです。
これで、条件が成立しなかったときにT4が残ってしまっていても、そのT4のときには、回路はなにひとつアクティブにならないのですから、誤動作のしようがないのです。

●危ない回路がもうひとつあります

RXと全く同じ条件で誤動作する可能性がある回路がもうひとつあります。
全く同じ条件ですから、もちろん前回説明した抵抗とコンデンサの追加によって、誤動作が回避できるであろうことも同じです。
それは条件ジャンプ命令JXです。

JMP、JX命令のタイミングチャートです。

条件不成立のときはT8でMclrが出力されますが、同じT8でPCLへのregWRが出力されますから、RXと全く同じタイミングです。
これについては前回説明しましたIC42のpin1、pin14間に1KΩのプルアップ抵抗を追加することと、pin3、pin7間への270pFコンデンサの追加によって、誤動作しなくなるであろうことは、RXの場合と同じです。

ところでRX、JXとくると、それじゃあCXも危ないのじゃあないの?
という疑問が出てきそうです。
でもCXは大丈夫なのです。

CALL、CX命令のタイミングチャートです。

条件が不成立のときはJXと同じようにT8でMclrが出されますが、CXの場合にはT8はダミーサイクルになっているので、JXやRXのような誤動作の要因は存在しません。
これはCXだけが誤動作を回避するためにダミーサイクルを入れていたのではなくて、CALL命令は、先にSP(スタックポインタ)を−1してから、プログラムカウンタをメモリに書き込まなければならないために、メモリへの書き込み作業より前のT9でSPへのクロックを出しておく必要から、ダミーサイクルが入っていたのです。
目的は全く違うところにあったのですが、CXについてはたまたまそのダミーサイクルが誤動作回避にも役立っていたのです。

前回予告しました、RX命令が誤動作するかどうかの確認のためのプログラムについて、NOPを追加すると誤動作しなくなるわけを説明する予定でしたが、本日は時間が無くなってしまいました。
それにつきましては、また次回に先送りさせていただきます。

2009.10.27upload

前へ
次へ
ホームページトップへ戻る