復活！ＣＰ／Ｍ　ワンボードマイコンでＣＰ／Ｍを！
ＣＰ／ＭがＴＫ−８０互換のワンボードマイコンの上で復活します
ＮＤ８０Ｚ�VとＭＹＣＰＵ８０の上でＣＰ／Ｍが走ります！

［第２８６回］


●ロジアナでとらえたアドレスセットの誤動作波形

前回説明をいたしました、Ｚ８０で追加された命令が原因で発生した、Ｅ−８０（仮称）ミニコンのアドレスセット（ＲＥＡＤ操作）で実際に誤動作している様子をロジアナで観測いたしました。
今回はその記録波形をお見せします。
なおここで使いましたロジアナにつきましては「ＴＴＬだけでＣＰＵをつくろう［第３７４回］」でご紹介いたしました。
超ローコストですぐれもののロジアナ（カメレオンＵＳＢ＋ロジアナキット）です。

ロジアナのプローブを接続して観測をおこなった信号は［第２７６回］と同じです。
下図はそのときにお見せした、プローブの接続ポイントをプロットした回路図です。



こちらが誤動作している様子をとらえた波形の記録です。

［第２７６回］でお見せした正常動作しているときの波形と比べてみてください。
両者の違いがよりはっきり分かるように、［第２７６回］の説明を下敷きにして説明をすることにいたします。

アドレスセット＋メモリリードの操作はＲＥＡＤスイッチをＯＮにすることで行われます。
ＲＥＡＤスイッチは中点復帰式（ｍｏｍｅｎｔａｌｙ。押している間だけ接点が閉じ、離すと元に戻る）のスイッチです。
そのスイッチ信号によって７４ＨＣ１２３から出力されたワンショットパルスによって回路動作がスタートします。
７４ＨＣ１２３のＱ出力にロジアナのプローブ００を接続し、その立ち上がりを測定開始トリガとしました。
ＲＥＡＤスイッチをＯＮにする前に、ＳＴＯＰスイッチをＯＮにしてＣＰＵをＭ１のタイミング（命令ＯＰコード読み込み）でウェイトさせてあります。
そのときのアドレス表示は××３ＡＨで、データバスにはメモリのそのアドレスの値７８Ｈが出力されています。
ここにはアドレスの上位８ビットは（プローブを接続していませんので）表示されていませんが、０７３ＡＨであることがわかっています。

今までのところではフロントパネルの操作についてしか説明してきませんでしたが、Ｅ−８０（仮称）ミニコンはもっともっと大きな機能をもっていて、当記事に先行してその機能についての各種動作テストも行っております。
実は現在デバッグ中のＥ−８０（仮称）ミニコンのＲＡＭにはＮＤ８０Ｚ�V（ＮＤ８０Ｚ３．５）のＲＯＭの中身がすでに移植済みになっています。
ですのでパワーＯＮしますと、その移植しましたＮＤ８０Ｚモニタが動作して、ＵＳＢ接続待ちになります。
そこでは以下のプログラムが実行されます。

; 0726 41 SOUTSB:LD B,C 0727 0EFE LD C,FE 0729 3E06 LD A,06 072B D3FB OUT (FB),A 072D ED78 SOUTSB2:IN A,(C) 072F F22D07 JP P,SOUTSB2 0732 78 LD A,B 0733 D3FC OUT (FC),A 0735 3E08 LD A,08 0737 D3FE OUT (FE),A 0739 ED78 SOUTSB3:IN A,(C) 073B FA3907 JP M,SOUTSB3 073E AF XOR A 073F D3FE OUT (FE),A 0741 3E07 LD A,07 0743 D3FB OUT (FB),A 0745 C9 RET ;

リストからお分かりいただけますように、上のロジアナ波形で最初のスタートポイントでＣＰＵが停止しているのはアドレス０７３ＡＨですから、まさに前回説明をいたしました、Ｚ８０で追加された命令ＩＮ　Ａ，（Ｃ）　命令コードＥＤ７８　の２番目のＯＰコードフェッチサイクルでＲＡＭから２番目の命令コード７８Ｈを読み込もうとしているところです。

ＲＥＡＤスイッチをＯＮにすると７４ＨＣ１２３のｐｉｎ１３からＨパルスが出力されます。
これがプローブ００の信号です。
この信号（正確にはｐｉｎ４からの出力信号）はメインボードに送られて、メモリアクセスの禁止信号になります。
そうしてメモリからの出力を禁止するとともに、同時にプローブ０５の信号をアクティブにすることによってデータバスにコードＣ３Ｈを出力します。
データバスの信号がメモリの値７８ＨからＣ３Ｈに変わる様子がはっきりとわかります。
このＣ３Ｈがデータバスに乗るまで十分な時間を稼ぐために遅延回路が使ってあります。
この遅延回路はＩＭＳＡＩ８０８０にはありませんが、必要と判断して入れてあります。
その遅延によって、ゆっくりとＷＡＩＴ信号（プローブ０１）がＯＦＦになります（８２００ｎｓあたりです）。
するとＣＰＵが動き出し、データバスのコードＣ３Ｈを読み取ってＭ１が終了します。
ＭＲＥＱ（プローブ２４）の�@のところです。
ＭＲＥＱ（プローブ２４）とＭ１（プローブ２５）がＨになります。

このあと［第２７６回］の説明では、

ＣＰＵはコードＣ３Ｈを解読して、その結果、次にデータバスからジャンプ先アドレスの下位８ビットを読み込みます（�A）。

と書いているのですが、今回のロジアナ波形ではそのようにはなっていません。
実は�Aはすこし後ろの１００００ｎｓから始まっています。
その代わりに�D�Eの２つのマシンサイクルが実行されています。
�Dではアドレス下位８ビットにＢ１Ｈ、データバスには０７Ｈが出力されています。
そして�Eではアドレス下位８ビットにＢ０Ｈ、データバスには３ＡＨが出力されています。
�Eのアドレスの値が�Dのアドレスの値−１であることと、それぞれのデータバスの値から、これはその直前にウェイトしていたアドレス０７３ＡＨがスタックにプッシュされているところだと推測できます。
ＣＡＬＬ命令や割り込みなどでスタックにアドレスがプッシュされるときは、最初に上位アドレス、次に下位アドレスの順に行われます。

ＭＲＥＱ信号（プローブ２４）を見ますと�Dと�Eの間でも１回アクティブになっています。
このときはＤＲＡＭのためのリフレッシュが実行されているのだと思います。
データバスを見るとその期間だけＣ３Ｈになっています。

実はこの�D〜�Eの期間を通してデータバスにはＣ３Ｈが出力されているのです。
そのＣ３ＨとＣＰＵから出力された０７Ｈ、３ＡＨがショートしていると考えられます。
しかしＣ３Ｈ出力のうちのＤ０，Ｄ１，Ｄ６，Ｄ７のＨ出力は、何も出力しないことでプルアップ抵抗によって消極的にＨとしているだけですから、ここはＣＰＵからの出力が勝ってしまいます。

ロジアナの入力はアナログではなくてデジタルなのでショートの状態を直接見ることはできません。
信号がぶつかっていて中途半端な電圧値になっていても入力の閾値より上ならばＨ、下ならばＬとして取り込まれます。
Ｄ２，Ｄ３，Ｄ４，Ｄ５のＬはダイオードを介してＬに引っ張っていることと、１つのゲート出力で最大４本の信号ラインからのＨの流れ込みを受けていることから、ダイオードのアノード側がＨ出力であった場合には、やはりＨの影響を受けてしまうと考えられます。
そのような理由からだと思いますが�D�Eの期間のデータバスの出力からはＣ３Ｈは消えてしまっています。
しかしＣＰＵからデータが出力されない�Dと�Eの間のリフレッシュの期間中はデータバスにＣ３Ｈが現れています。

�Dと�Eの期間にデータがぶつかっている影響は意外なところに現れています。
プローブ０５を見てください。
プローブ０５はＣ３コードをデータバスに出力するために、ダイオードを介してデータバスのＤ２〜Ｄ５をＬにしている７４ＨＣ１０のゲート出力信号です。
ここは本来は２００ｎｓから１００００ｎｓまでずっとＬのはずなのですが、途中�F�Gの２回Ｈになっています。
�F�GはちょうどＣＰＵからデータが出力されている期間に重なっています。

プローブ０５は上の回路図の７４ＨＣ１０ｐｉｎ８の出力信号（Ｃ３）ですが、その先は下図のようになっています。


ＣＰＵから０７Ｈ、３ＡＨが出力されているとき、７４ＨＣ１０のｐｉｎ８にはダイオードを介してＣＰＵからのＨ出力信号が流入します。
その結果、７４ＨＣ１０のｐｉｎ８出力が浮き上がって、ロジアナではＨレベルとして認識されたのだと思われます。
うーん。
ＨＣＭＯＳの出力ゲートをＨに引き上げるほどの出力がＺ８Ｓ１８０のバス出力にあるとは思えないのですけれど…。
ま。
でも現実にはそういうことがおきています。
しかし。
これはＣＰＵにとって余りよいことではないですねえ。
このプローブ０５の信号を見ているとちょいと心配になってしまいます。

それはともかくとしまして、やっと�Aのところでデータバスにはパネルスイッチの下位８ビットの値ＡＢＨが出力されました。
このときのアドレスバスの値を見ると下位８ビットが００Ｈになっています。
前回説明しましたように、ＣＰＵは先に読み込んでいたＥＤＨに続いてＣ３Ｈを読み込んだため、そこで未定義命令割込みが発生し、そのときのアドレスをスタックにプッシュしたあと、アドレス００００Ｈにジャンプしたことが読み取れます。
フロントパネルの回路ではこのタイミングはＣ３Ｈに続くジャンプ先アドレス値の読み込みですから、ただのメモリリードサイクルのはずなのですが、ＣＰＵのロジックではメモリアドレス００００Ｈにあるはずの命令コードを読み込む動作になりますから、ここでＭ１（プローブ２５）がアクティブになり、それがＯＰコードフェッチサイクルであることを示しています。

つまりここでＣＰＵはデータバスに置かれたＡＢＨをＪＰ命令のジャンプ先下位アドレスとしてではなく、命令コードとして解読してしまいます。
命令コードＡＢＨは　ＸＯＲ　Ｅ　です。
これはただちに実行され、その結果アドレスバスには次のアドレス０００１Ｈが表示されます。
�Bのタイミングです。

回路からはパネルスイッチの上位８ビットの値がＪＰ命令のジャンプ先アドレスの上位８ビットとしてデータバスに出力されます。
その結果データバスの値は８９Ｈになっています。
しかしＣＰＵはさきほどのコードＡＢＨを　ＸＯＲ　Ｅ　として実行して、次のアドレス０００１Ｈに進んだため、ここでもメモリアドレス０００１Ｈに置かれているはずの命令コードを読み取ろうとします。
そのため�BでもＭ１（プローブ２５）がアクティブになり、それがＯＰコードフェッチサイクルであることを示しています。

つまりここでもＣＰＵはデータバスに置かれた８９ＨをＪＰ命令のジャンプ先上位アドレスとしてではなく、命令コードとして解読してしまいます。
命令コード８９Ｈは　ＡＤＣ　Ａ，Ｃ　です。
これはただちに実行され、その結果アドレスバスには次のアドレス０００２Ｈが表示されます。
ここでやっと�Cのタイミングになって、ＷＡＩＴ（プローブ０１）がアクティブ（Ｌ）になりＣＰＵが停止します。

前回説明しましたようにＺ８０で追加された２バイト命令コードの２番目のＭ１でウェイトしたところから、アドレスセットの動作が開始されたために、本来ならばアドレスＬＥＤにはパネルスイッチの値８９ＡＢＨが表示されるべきところ、予期しない値０００２Ｈが表示されてしまう結果になりました。

今回ロジアナでの観測記録を見ていただきました通り、この現象は状況によって発生頻度はいろいろ変わるものの、いつかは必ず遭遇するものと覚悟しておかねばなりません。
それを避けるためには、前回書きましたように、ＳＴＯＰしたあと、すぐにＲＥＡＤスイッチの操作にいくのではなくて、必ず先にＲＥＳＥＴすることをルールとしておく必要があります。
先にリセットしなければならないというルールにすれば、前回および今回書きましたような不都合な現象は避けることができます。

やれやれ。やっと。
これにて一件落着です。

と、まあ、そういうことでもよいと思うのですけれど。

でも。
なんとなく、面白くないのですよねえ。
せっかくＭ１で停止するところまで考えてあるのに、Ｚ８０に拡張命令があるのはわかりきったことじゃありませんか。
であるのに、それに全く対応していない、つまり旧８０８０回路のままで、「じゃあ、そういうことですので、あしからず」って、それってちょっと面白くないのじゃありませんか。
ねえ。

ということになりますと。
そこのところをなんとかしたくなってしまうじゃありませんか。

wwひとのやれないことをやれぇーw

困った性分なのですよ。まったく（また納期が遅れてしまいますぅ）。

あ。
皆様も、それじゃあどうすればよいのか、ちょいと考えてみてください。

ワンボードマイコンでＣＰ／Ｍを！［第２８６回］
２０１３．１．７ｕｐｌｏａｄ

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