ＴＴＬでＣＰＵを作ろう！

~~標準ＴＴＬ~~だけ（！）でCPUをつくろう！（組立てキットです！）
(ホントは７４ＨＣ、ＣＭＯＳなんだけど…）
［第３７２回］

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

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

●ＴＫ８０のプログラムが動きません

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

うっかりしていました。
お尋ねの通りです。
ＴＫ８０が売り出された当時は、メモリの集積度は非常に低く、ＲＡＭもＲＯＭもとても高価でした。
そのためＴＫ８０はアドレス８２００～８３ＦＦのわずか５１２バイトしかＲＡＭを搭載していませんでした。
基板上にＲＡＭを増設することができましたが、それでも最大１ＫＢまでで、そのときのアドレスは８０００～８３ＦＦでした。

そういうハード上の制約から、ＴＫ８０のシステムワークエリアはＲＡＭの８３ＸＸ番地に置かれていました。
一方、ＭＹＣＰＵ８０は３２ＫＢのＲＡＭを搭載しています。
ＲＡＭのアドレスは８０００～ＦＦＦＦの３２ＫＢです。
せっかく３２ＫＢもＲＡＭエリアがあるのですから、このアドレスを有効に使えるように、と考えてシステムのワークエリアを８３ＸＸからＦＦＸＸに移動してしまいました。

ＴＫ８０プログラムをそのまま走らせる、という互換性維持の観点から考えてみれば、ここは移動しなかったほうがよかったかも知れません。
もっともそうするとＬＥＤ表示のためのＤＭＡアドレスを８３Ｆ８～８３ＦＦにするためには、ちょっとハード回路の負担が大きくなってしまいます。

それは将来同様のボードをもしも作ることになったような場合には、検討の余地がありそうです。
しかしながら、ＭＹＣＰＵ８０ではそういう理由で、システムワークエリアについては残念ながらＴＫ８０と同じではありません。
ただ８３ＸＸをそのままＦＦＸＸに平行に移動しただけですから、もしも昔のＴＫ８０のアプリケーションプログラムなどを実行させてみたい、とお考えになった場合には、システムワークアドレスを指定している部分の８３ＸＸをＦＦＸＸに書きなおせば、ＴＫ８０のために書かれたプログラムがＭＹＣＰＵ８０の上でもそのまま実行できるはずです。
ただし、プログラムによってはＬＸＩ命令やＳＴＡ、ＬＤＡ命令で８３ＸＸのようにアドレスを直接指定するだけではなくて、８ビットのＭＯＶ命令やＭＶＩ、ＣＭＰなどの演算命令でシステムワークアドレスの上位の値８３をデータとして扱っているような場合もありますから、もしうまく動作しないような場合には、その点にも注意してみる必要があるかも知れません。

●正しいＲＺの回路は？

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

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

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

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

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

ＪＭＰ、ＪＸ命令のタイミングチャートです。

条件不成立のときはＴ８でＭｃｌｒが出力されますが、同じＴ８でＰＣＬへのｒｅｇＷＲが出力されますから、ＲＸと全く同じタイミングです。
これについては前回説明しましたＩＣ４２のｐｉｎ１、ｐｉｎ１４間に１ＫΩのプルアップ抵抗を追加することと、ｐｉｎ３、ｐｉｎ７間への２７０ｐＦコンデンサの追加によって、誤動作しなくなるであろうことは、ＲＸの場合と同じです。

ところでＲＸ、ＪＸとくると、それじゃあＣＸも危ないのじゃあないの？
という疑問が出てきそうです。
でもＣＸは大丈夫なのです。

ＣＡＬＬ、ＣＸ命令のタイミングチャートです。

条件が不成立のときはＪＸと同じようにＴ８でＭｃｌｒが出されますが、ＣＸの場合にはＴ８はダミーサイクルになっているので、ＪＸやＲＸのような誤動作の要因は存在しません。
これはＣＸだけが誤動作を回避するためにダミーサイクルを入れていたのではなくて、ＣＡＬＬ命令は、先にＳＰ（スタックポインタ）を－１してから、プログラムカウンタをメモリに書き込まなければならないために、メモリへの書き込み作業より前のＴ９でＳＰへのクロックを出しておく必要から、ダミーサイクルが入っていたのです。
目的は全く違うところにあったのですが、ＣＸについてはたまたまそのダミーサイクルが誤動作回避にも役立っていたのです。

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

２００９．１０．２７ｕｐｌｏａｄ

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