レトロコンピューティングの楽しみのためにZ80自作コンピューターを構築し、電子設計の基礎を学ぼうとしています。概念実証のために、私は前の週にブレッドボード上に基本的なシステムをすでに組み立てました。
現在のプロトタイプは非常に単純です。Iは、システムクロックとして74HCT04ピアス発振器によって駆動される4 MHzの水晶を用い、透過モード（中の2つの74HCT573ラッチLE16ビットアドレスバスのためのバッファとして高い）により制御反対方向にさらに2 74HCT573 RDとNOT RD双方向データとしてバスバッファ。私は、添付の100nsの AT28C256 EEPROM（のみ16 KiBのがデコードさ）および2つの150ナノ秒のシステムバスに8 KiBのSRAMチップ。74HCT42を使用してCS信号を生成しOE、EEPROMをLow WEからHighにハードワイヤードし、EEPROM を制御するCS信号を1つだけ残しました。
ブレッドボード上のすべてがうるさいですが、すべてのステージを完了した後、システムは完全に動作しているように見えました。今では、EEPROMから命令をフェッチSRAMへ/からデータを読み取り、書き込み、およびそれは別のラッチ74HCT573から作られたシリアルポートを持っている、ことができますD0に接続されているD0、LEある(NOT (IOREQ NAND WR))、出力から出てくるQ1だけで一つの出力ポート、つまり、 adrressデコードロジックなし。CPU / RAMを多用するベンチマークプログラムを作成しましたが、コンピューターは期待どおりの結果を出力できます。Memdumpsは、Z80がEEPROMからすべてのバイトを正しく読み取ることができるため、すべてが機能していることも示しました。
しかしD0、データバスのピンをプローブしようとすると、論理1の出力に奇妙な「ノッチ」が見られました。
そしてCS、EEPROM の信号がアクティブになった直後に、いくつかの論理1で常に表示されるようです。たとえば、青色のEEPROM CS信号に重畳された奇妙なノッチのキャプチャです。
問題を切り分けようとしたので、SRAMのすべてのCSピンをHIGHに固定し、システムから効果的に削除し、メモリアクセスのない単純なテストプログラムを作成しました。
.org 0x00
di
xor a
loop:
out (0x00), a
inc a
jp loop
しかし、問題は依然として変わらず、奇妙な「ノッチ」でいつものために表示されるいくつかの論理1S、直後にMEMRQ（それが今、基本的にワンチップだから）、および/またはCS（青）はローになります。
SRAMのすべてのCSピンはHIGHであるため、システムにはほとんどメモリとしてAT28C256 EEPROMチップ、出力ポートとしてラッチがあります。システムには、DMA要求中にEEPROMをオンザフライで再プログラムするAtmega328pで作られたインシステムプログラマもありますが、プログラマのすべてのデータとアドレス出力をトライステートにしたので、それが原因ではないと思います。プログラマーを追加する前からノッチを見てきました。
そのため、オペコードフェッチサイクル中に「ノッチ」を作成する必要があります。彼らは何ですか？
私にはいくつかの仮説があります：
問題はありません。これはブレッドボードのシグナルインテグリティが悪いために発生したもので、適切に設計され、適切に分離されたPCBでは自動的に消えます。ブレッドボードには、インピーダンス不整合、反射、寄生容量、クロストーク、EMI / RFIなど、あらゆる種類の信号整合性の問題があります。ボード上を走る長いバスワイヤは、問題をある程度悪化させる可能性があります。
もしそうなら、「ノッチ」の性質を説明できますか？この現象はEEに名前がありますか？私は以前に多くのオーバーシュートとリンギングを見ましたが、「ノッチ」を見たことはありません。そして、なぜ私はいくつかの論理レベルでのみそれを見るのですか？
タイミング。EEPROM出力または他の論理回路の短い「整定時間」がバスにこの奇妙な効果を引き起こしている可能性はありますか？
扇形に広がります。おそらく長いバスには大量の電流が流れ、静電容量が大きいため、EEPROM出力はバスを高く駆動するのに苦労していましたか？おそらく、オシロスコープのプローブもバスに負荷をかけていますか？
バスの競合、または何かがデータバスをプルする原因となった他の論理エラー。ありそうもないと思う？バス上の他のコンポーネントは分離されており、単一のAT28C256 EEPROMまたはラッチがこれを行う方法を確認できませんでした。しかし、配線エラーやブレッドボードの隠れた内部短絡のために、それはまだ可能だと思います。
更新：ボードのデカップリングコンデンサとフィルタリングコンデンサを最初から使用していました。ボード全体でかなりの数の0.1 uFデカップリングコンデンサを使用しましたが、CPUにはデカップリング用に0.1 uFと0.01 uFの両方のコンデンサがあります。現在のシステムには8つのボードがあり、各ブレッドボードにはローカルフィルタリング用に2つの4.7 uFアルミニウムコンデンサが両方のレールにあります。また、devboardから得られる電力には200 uFのタンタルコンデンサがあります。しかし、私が言ったように、問題はここにあります。
ただし、ブレッドボード上のチップの近くに104個のコンデンサを配置することの難しさを考えると、それで十分かどうかはわかりません。おそらくさらに追加することで修正できますか？
私が興味を持っているのは問題の根本原因です。それが単に不十分なデカップリングやブレッドボード上の信号の完全性の固有の問題であることが確認できれば、最終設計はPCBになります。確信はないけど。
ありがとう。
Update2：私の考えでは、ブルース・アボットのコメントは正しい答えを与え、問題は解決されたと思います！明日までテストできませんが。犯人はZ80のDRAM更新です。詳細については、私自身の回答を参照してください。現在、新しい回答は必要ありません。解決策を確認したら、自分の回答を受け入れます。うまくいかない場合は、質問を更新します。みんなの助けてくれてありがとう。
