マイコンの製作（自作ＣＰＵ ８０８０）
（７４ＨＣ（ＬＳもある）シリーズのＤＩＰで８０８０もどきを製作。名称をＭＤＫ８０８０とした。）
２０１６年１１月
１． はじまり
プロファイルのところでマイコンのことを書いたので思い出したが、Ａｌｔａｉｒ８８００のようなコンピュータを作ろうとした作りかけあったはずと押入れを探してみた。でも見つからなかった。どうしたのかなあ。？！そうだ、現在のところに引っ越した時に、ガラクタ廃棄命令で廃棄したかもしれない。しまった。捨てなければよかった・・・・。
懐かしくなりネットで８０８０を検索すると、あるある、みなさん８０８０もどきを製作してＣＰ／Ｍまで移植しているようだ。そのなかでも中日電工さんのページが圧巻だった。なんとＴＴＬ（実際は７４ＨＣ）で８０８０ＣＰＵを作ると言うのである。記事を読んでいるうちに作りたくなった。出来たとして何に使うか、何につかえるか？などと思ったが、そんなことを考えると趣味なんてできない。これはロマンである。でも組み立てるだけではつまらない（天邪鬼だねぇ）。組み立てるのではなく創るのである。自分で回路を考えて動かすのが楽しいのである。
２０１６年１２月
２． 回路設計
自分で回路を考えようと意気込んでみたものの、はたして回路ができるのか。まずはＣＰＵの仕様を探した。98-153B_Intel_8080_Microcomputer_Systems_Users_Manual_197509と言う青い表紙の資料がダウンロードできた。便利な世の中だ。
でもＡＬＵが手に入るのか？、中日電工さんは加算器を使っていたが。ＡＬＵの７４ＨＣ１８１を探すと中国にあった。とりあえず注文だけしておいた。ＡＬＵが入手できるつもりで回路を考えることにした。
８０８０の命令は１６進数で表現されているが、レジスタは７個＋１なので、オペランドは３ｂｉｔである。これはＰＤＰ−１１と同じように３ｂｉｔで区切った方が分かりやすい。命令デコードは３ｂｉｔで区切ってデコードすようにする。
ＭＥＭＯＲＹのＲＥＡＤ、ＷＲＩＴＥとＩＯは分離して出すようにする。つまり８０８０＋８２２４＋８２２８が一体になった回路とする。
約１ヵ月かかって回路が出来た。頭の中では動作している（いつもそうだが、現実は違う・・・汗）。でもＡＬＵが届かない。１ヵ月経つのだが。問い合わせたら、途中で紛失したようなので再度送ると連絡が来た。さすが中華・・・・。もう１ヵ月待たねば。
回路図 ＿＿＿
でもどうやって基板へつけるか？。秋月にユニバーサル基板のＡ４（よりちょっと大きい）サイズがあるのが分かった。これに載らなければあきらめよう。図面を描いてみた。
おやおやうまく載ってしまった。少し余裕がある。あと２〜３個ＩＣを載せれる。回路デバッグでＩＣが追加になっても何とかなりそうだ。つまり作れという天の声か・・・・。
ちなみに赤がアドレスレジスタ。黄緑がプログラムカウンタやスタックポインタ、ＨＬなどのレジスタ部分である。緑はＡレジスタやフラグレジスタ、ＡＬＵ、シフト用レジスタなど、ピンクはメモリーＲＥＡＤ、ＷＲＩＴＥ、ＩＯ ＲＥＡＤ、ＷＲＩＴＥなどの信号部、青が命令レジスタ、水色がクロックと命令デコード部、黄色が命令実行部である。
ALU周りの回路を考えるときに、ALUの仕様を検討したが、データは負論理で設計されている。しかし、そのままの動作で正論理で受け取ることもできる。７４HC181は論理を切り替えて加算、減算、AND、OR、XORなどそのほかのロジックも動作する。その他のロジックのときに正論理の動作もできるようだ。しかし、内部等価回路を見るとA=Bの信号は負論理でないとうまく動作しないように見える。説明書には正論理の場合どうなるか明記されていない。事前に調べたいが、中華からはまだ届かない。ひょっとすると永久に届かないかもしれない。事前に調べたいのと保険にと別途探すことにしたが、やはり無いようである。無いというのは間違いであるところにはあるが、１００個売りで１個売りはしていない。１００個もいらいないのでそこはダメである。では、７４LS181はと調べると、これはまだ残っているようで、２個ほど購入した。最悪ALUだけ７４LS１８１にすることにする。
さっそくALUの実験をやってみた。やっぱりA=Bは負論理のときだけ正しく動作する。なので負論理で回路を設計した。
２０１７年１月
発注していたIC（一部）がａｉｔｅｎｄｏから届いた。
ａｉｔｅｎｄｏさん、お願いですからＩＣは導電スポンジにさして下さい。
２０１７年１月
残りのＩＣがｃｈｉｐ１ｓｔｏｐから届いた。梱包はさすが、導電スポンジやＩＣ用レールに入っている。
圧巻はこれかな。７４ＨＣ０４が２００個である。２００個以上での販売だった。でもこれで１３１円である。在庫処分かな？
２０１７年１月
今日何気に回路をみているとＤＡＡの計算回路を間違っているのに気付いた。なんで間違ったかなぁ。ＡＬＵ回りを正論理から負論理回路に変更したときにもれたかなぁ。ＩＣがそろったし（コネクタ類はまだだが）。そろそろ作りはじめるかな。どのくらい掛かるだろう。２０ＰＩＮと１６Ｐと１４Ｐだが２０Ｐが多い。おおざっぱに２０Ｐが２００個として４０００本の配線かな。
えっ・・・。そういう計算では無いって・・・。そうだけど・・・。ＩＣのピン３本を繋ぐ配線は２本の計算だからですね。でもコンデンサやプルアップ抵抗やらを繋ぐのでそれを含めて、おおざっぱに計算しているのです。
４０００本だとすると４０本／日とすると１００日かかる。３ヵ月ほどかかるかなぁ。すると５月の連休にテスト開始できるかな？
では、それを目標にがんばろう！
２０１７年２月
最終チェックと思ってなにげに回路図をみていると、ＩＣ番号にダブりがあった。やれやれ、ＩＣを１個追加だ。おやーー、番号に空きがある。どうやらコピー後の変更忘れか？。番号を取っているので変更忘れはなさそうだが・・・はて？。いずれにしろ配置図を修正せねば。おや、配置図にも間違いが・・・。コピーして配置して番号を書き換えるの忘れている。やれやれ恥ずかしい配置図をアップしてしまった。
修正した配置図
２０１７年２月
ああ、そうそう。回路設計するにあたり、本棚の肥やしになっていたこの本を引っ張りだして参考にした。約４０年前にＣＰＵを作ろうとして買った本である。仕事でコンピュータをさわっていたせいもあるかもしれないが、結局完成しなかった。Profileに書いたが、TMS８０８０を使った部品キットを作っただけで頓挫していたのだ。４０年経ってようやく作ることになろうとは。
２０１７年２月
ICを少し取り付けてみた。配線はまだこれからである。４０本／日はちょっと辛いなあ（弱気・・・）。
それと名前を付けてみた。
MDK８０８０とした。８０８０もどきである（笑）。
２０１７年２月
先日ＩＣがそろったと書いたが７４ＨＣ１８１はまだ届かない。今日、返金要求をしておいた。
ＡＬＵは７４ＬＳ１８１を使うことにする。ＬＳをＨＣで受けるにはプルアップが必要だ。ＨＣＴタイプだと受けることができるが、ＨＣしか買っていない。
ちなみに７４ＬＳ１８１の出力はこのようになっている。これではどう頑張っても３．６Ｖ以上は出てこない。
２０１７年２月
すこし配線してみた。まだまだ先は長い・・・・。
ＢＵＳ以外の配線半ば、うーん、４０本／日はやっぱり厳しいなぁ・・・。完成は遠いぞぉ・・・・。まあ、それだけ長く楽しめるということだが（そう思おう）、他のことが出来ない。
仕方ないけど。
２０１７年２月
ようやくBUSの配線が終わった。
ALU周りを実装した。
２０１７年２月末日
７４HC１８１の返金手続きが完了して、返金されたことを確認した。（やれやれ）。
なのでALUは７４LS１８１である。てか、もう実装してあるが。
２０１７年３月中
ようやくＡＬＵ回りの配線がほぼ完了した。
２０１７年３月中
クロックと命令デコーダ部を実装した（配線はこれから）。
２０１７年３月中
奇しくもタイムリーに（？）こんな本が発売された。さっそく購入してみた。出版社から直接買えるので購入した。直接購入するとオマケのＣＤが付いていて本のＰＤＦやソフトのソースファイルが入っている。これはお薦めだ。
「インテル８０８０伝説」の本。光の具合が悪く白っぽくなってしまった。
２０１７年３月末
だいぶ配線ができてきたが、まだまだだ。
しかし、ここまで配線してＩＣのダブりが判明した。うーーーんん。このＩＣが無いとＨＯＬＤを受け付けない。よし、ＨＯＬＤ無しだ！。あっ！・・・待てよ。ＨＯＬＤができないとＤＥＢＵＧ回路が使えない。
仕方ない１個追加だ（やれやれ）。
黒いボックスコネクタと白いコネクタの間に１個追加した。
２０１７年４月中
ようやく配線ができた。と言っても命令実行部はまだだが。
ここまで出来ると命令フェッチとデコードが動作する（はず）。まあ、実行部が無いので全てＮＯＰだが（笑）。
いや、実行部の不要なＮＯＰは動くはずだ、他にもＳＴＣ，ＣＭＣ（訂正：ＣＭＣは命令実行部があった）、ＨＡＬＴが動作するはずだが。
それを確認するためのＤＥＢＵＧ回路ボードを作らねば。
２０１７年４月末
ＤＥＢＵＧボードである。
まだ完成では無い。部品を付けただけである。プリント基板なら完成だが・・・。裏の配線はこれからである。
ＭＤＫ８０８０の方は命令実行部が無いので、およそ半分のＩＣしか搭載していない。もう直ぐＧＷだが当初の予定の半分しかＩＣが付いていないので、４０本／日はやっぱり無理だった。半分の２０本／日ってところだ。
ＧＷにＤＥＢＵＧ回路が完成すれば御の字だ。それからＤＥＢＵＧしながら命令実行部を載せていくと、盆休み前に完成かな。まあそんなところだろう。
２０１７年５月中
ＧＷではＤＥＢＵＧ回路の配線は終わらなかった。なかばにようやく完成した。ではＤＥＢＵＧ回路のＤＥＢＵＧする回路を・・・・・な訳にはいかない。
取り敢えずＣＰＵボードに接続して見た。
右端のＬＥＤ群はレジスタを読み出して表示する。読み出すのはＨ８マイコンだ。ＣＰＵにＨＯＬＤを掛けて動作を停止し、ＤＥＢＵＧ用のポートからレジスタの内容を読み出す仕掛けだ。
今表示しているのは読み出したつもりの適当な値だ。実際にうまく読み出すかはこれからである。
２０１７年５月末
Ｈ８ソフトのバグが少しあったが、ＤＥＢＵＧ回路も何とか動作するようになった。ＤＥＢＵＧ回路が動作するようになって、ＣＰＵ回路のハンダ不良が５カ所あるのを発見した。
ハンダ不良を嘆くべきか、ＤＥＢＵＧ回路がうまく動作したのを喜ぶべきか・・・・。
先にも書いたが、命令実行部のＩＣが無くても実行できる命令の動作確認をした。
まずＮＯＰ命令。まあ、全て（上記命令以外）動作はＮＯＰだが。動作する（当たり前？？）。おそらく回路に間違いがあっても次へ進むのでよくわからんが。
次にＳＴＣだ。ＳＴＣもうまく動作した。次はＥＩだ。ＩＮＴ ＥＮＡＢＬＥをセットするだけなので、簡単に動作した。次はＤＩだ。さっきのＥＮＡＢＬＥを落とすだけ。これもうまく動作した。
さて残るはＨＡＬＴだ。ＨＡＬＴ命令で実行が停止した。停止したと言ってもＩＮＴ ＥＮＡＢＬＥにしているとＩＮＴＥＲＲＵＰＴを受け付けなければならない。とりあえず巧くいった。ただし命令実行部がないのでＲＳＴ命令が実行できない。ＮＯＰとなって次へ進む。今の段階ではＯＫだ。
ここまでうまく動作したので、気をよくして命令実行部を実装する。
２０１７年６月初
ＬＸＩ命令とＤＡＤ命令が実装できた。早速テストしてみる。
ＬＸＩ Ｂ、４４５５Ｈ
ＬＸＩ Ｄ、８８ＡＡＨ
ＬＸＩ Ｈ、０ＣＣ３３Ｈ
ＬＸＩ ＳＰ、０Ｆ００ＦＨ
とパターンがダブらないようにデータを入れる。
レジスタの内容は読み出してＬＥＤを点灯させている。うむうむ、うまくいったぞ。
ＤＩＰＳＷの一番下はＨＡＬＴ命令だ。突っ走らないようにＨＡＬＴ命令を置いている。
さて、ＤＡＤ命令のテストだ。ＬＸＩ命令が無いとレジスタにデータ設定ができないので、ＬＸＩが動作してからのテストだ。
ＤＡＤ Ｂ
ＤＡＤ Ｄ
ＤＡＤ Ｈ
ＤＡＤ ＳＰ
を試してみる。これはＡＬＵを使って、ＬレジスタはＡＤＤ命令、ＨレジスタにはＡＤＣ命令でそれぞれのレジスタを足し込む。
まずはうまく桁上がりするかどうか。
ＬＸＩ Ｈ、００００１Ｈ
ＬＸＩ Ｂ、０ＦＦＦＦＨ
ＤＡＤ Ｂ
を実行。桁上がりしてＨＬレジスタは０となりＣフラグはＯＮしている。ＤＡＤ命令で変化するのはＣだけだが、テストの為全てのフラグをセットしている。
ＡＣがＯＮ、ＺがＯＮしている。おや〜、ＳもＯＮしている。０だからＺがＯＮして正解だが、ＳがＯＮするのはおかしい？？
回路図を調べたら、何と！間違っている。負論理にしたときに、変えなければならないをそのままにしている。やれやれ。
接続を変更だ。配線を追っかけようと、ＳのラッチＩＣを見ると。な、っな、なんと、配線が無い！！。いや〜、歳のせいかな。回路を間違っていたうえ配線していないとは！
ミスのミスでミスの２乗である（とほほ）。そのおかげで（？）配線変更が楽だ（なんてね・・・）。
配線を追加して、動作ＯＫとなった。その後、ＤＡＤ命令でＣフラグだけ変化するように配線を変えた。
２０１７年６月中過
ＳＨＬＤ、ＳＴＡ命令とＬＨＬＤ、ＬＤＡ命令ができた。それぞれの命令は関連がありよく似ているので回路に共通部分がある。共用部分があるので、そろえて作ったほうが楽だったのだ。
さて、動作確認だ。ＳＴＥＰで動作させるとうまく動作した。
そこで連続動作でテストするためのプログラムを設定した（組んだ）。
ＬＸＩ Ｈ、０ＡＡＣ５Ｈ
ＳＨＬＤ ０Ｆ０００Ｈ
ＬＤＡ ０Ｆ０００Ｈ
ＳＴＡ ０Ｆ００１Ｈ
ＬＨＬＤ ０Ｆ０００Ｈ
ＨＡＬＴ
この結果
Ａレジスタ＝０Ｃ５Ｈ
ＨＬレジスタ＝０Ｃ５Ｃ５Ｈ
となるはずである。
ＳＴＥＰ動作ではうまくいったので、クロック１ＭＨｚで実行させてみた。結果は上々、ラクチンラクチン。
では２ＭＨｚではどうだろう。
・・・・・えっ！ う、うまく動かない。ＨＬレジスタが０ＡＡＣ５Ｈのままだ。おや〜。
クロック１ＭＨｚのＣＰＵってことぉ〜。いやいやそんなはずは・・・・。
悩んでもしようがない。ロジックアナライザの出番だ！。
あれやらこれやら調べった結果、アドレスのＡ１４の変化が変なことに気付いた。
ロジックアナライザなので、波形は矩形であるが、波形の変化タイミングから元波形がなまっているのではないかと疑った。こればっかり使っていると波形のタイミングから元波形がおかしいのではと何となく分かるようになるものである。
早速Ａ１４のラインを調べていくと・・・ビンゴ！。半田不良を見つけた。
手直しすると２ＭＨｚでも動作した。
半田不良なのに１ＭＨｚでは何故動作するのか？（推測だが）半田不良部は高抵抗で繋がっていて、信号はある程度伝わるのでは。ＣＭＯＳ−ＩＣは入力インピーダンスが高いので、信号を受け取れるのだろう。TTLは電流で動作するのでそうはいかないが。クロックが早くなると高抵抗と浮遊容量でフィルタのようになった部分で信号が伝わりにくくなるのであろう。
さて２ＭＨzが動作したので、試しに４ＭＨzにして見た。・・・・やっぱり・・・・動作しない。そんなもんかなぁ、まあ期待はしていなかったが。ロジックアナライザが繋がっているので、波形を採って見た。
おやっ！アドレスラッチがうまくいってない部分がある。その部分以外はちゃんとラッチできている。・・・・・・あっ・・・・・急に思い出した。半年前に回路設計時に頭をよぎったことが・・・。
おかしくなっているのはＳＴＡ命令の後だ、ＳＴＡ命令はＳＨＬＤ命令を半分つかう。Ｌレジスタをメモリーに書くかわりにＡレジスタを書いて、マシンサイクルをリセットする。リセットしなければそのままＨレジスタを書いてしまう。この実行ＩＣのアドレスラッチ信号が生きている（Ｈの状態、トライステートがアクティブになっている）。これとＳＴＡ命令の次の命令をフェッチするためのＰＣをラッチする信号回路がケンカしている。じゃあ何故２ＭＨｚでは動作するのか？？これはよくわからん。
命令をフェッチしてしまえば、ＳＴＡ命令実行信号が切り替わるのであるが、フェッチできなければ切り替わらない。実際には強制的にフェッチ動作するので、どこだか分からない（アドレスラッチに失敗しているので）アドレスのデータをフェッチしているので、命令は切り替わるが。
さて改造だ、フェッチサイクルの間（Ｍ１ステート）、命令デコーダをディスエーブルにしてみた。ふむふむ、これでどうーーーーだ！。
ありゃっ！動作しない。やっぱり４ＭＨｚはだめかねぇ・・・。
もののついでだ、ロジックアナライザで確認すると少し様子が変わった。信号のケンカは無くなったようだが、やっぱりアドレスラッチミスがある。これはなんじゃ。アドレスデータとラッチ信号が同時にでているぞ。どうやらうまく取り込めていないようだ。どうしてＰＣの出力が遅いのだろう。他の部分は問題無いのだが。
回路図をよーーーーく眺めると。あっ・・（こればっか）、もう一つ思い出した。昨日の晩飯に何食ったか忘れるので仕方ないか・・・、いや、思い出したのだから無問題かぁ・・・。
命令実行完了でマシンステートをリセットするが、リセットした途端にフェッチサイクルのＴ１ステートになる。だが、時間遅れがあるのでＴ１ステートの先頭ではない。この遅れが回路図では読めなかったのだ。実際に動作させないと分からん、とその時思ったのを、思い出したのだ。
元クロック１６ＭＨｚとしていて、２クロックほど遅れている。なので１２５ns遅れていることになる。アドレスラッチは３クロック目の立ち上がりを使っているので、やはり１２５nsで出る。これではだめなので、４クロック目の立ち上がりへ変更した。
そこで４ＭＨＺで動作させてみると、なんとうまく動作したのである。４ＭＨzで動作してくれれば御の字だ。いやーー嬉しいなぁ。でも、命令実行部を追加していってＩＣが増え、配線が増え、浮遊容量が増えると、動作しなくなるかもしれない。ぬか喜びにならなければ良いが。
クロック４ＭＨｚで動作した時の写真（※後日追記：Ｔｎクロックを４ＭＨｚで作っているので４ＭＨｚと書いてしまったが、Ｔｎの周波数は半分の２ＭＨｚとなる。どうやらこれがＣＰＵクロックのようである（汗）。なのでｉ８０８０の２ＭＨｚと同等であった。）
２０１７年６月末
ＳＴＡＸ、ＬＤＡＸ命令を追加し動作確認ＯＫ。これは楽勝だった。続いてＭＯＶ命令、ＭＯＶ ｒ、ｒである。追加完成して、同じく楽勝と思いきや、Ａレジ以外はうまく動作する。うまく動作しないのはＡレジへ入れる場合だ。ＭＯＶ Ａ，ｒ がうまく動作しない。うーーん、またやってしまった。８ビットバスに繋がったＡレジスタとＢ，Ｃなどのペアレジスタの１６ビットバスのデータルートの切り替えでミスっていた。レジスタ指定のｒが偶数の場合、Ｂ、Ｄ、Ｈレジスタとなり、奇数の場合はＣ、Ｅ、Ｌレジスタとなる。なのでＭＯＶ命令のＳｏｕｒｃｅとＤｅｓｔｉｎａｙｉｏｎが偶数どうし、奇数どうしはそれぞれの８ビットバス内だが、違う組み合わせでは、偶数←奇数、奇数←偶数の場合はそれぞれの８ビットバスデータをもう片方へ送るようにゲートを切り替えるようにしている。だが、ＤｅｓｔｉｎａｔｉｏｎのＡレジスタは奇数だが、１６ビットバス側ではなく、最初に書いたように８ビットバス側にあるのだ。なのでそちら側へデータ送らなければならない。そこが抜けていた。うーーーん。ＩＣ１個追加だ。幸い回路見直しで１個不要になった部分があるので、そこに実行部のまだ実装していないＩＣをずらしてスペースを作り１個追加した。
これでＭＯＶ ｒ，ｒ命令が完成した。（やれやれ）
ＭＯＶのテスト命令
ＬＸＩ Ｂ、０ＡＡ５５Ｈ
ＭＯＶ Ａ、Ｃ
ＬＸＩ Ｂ、０ＦＦＦＦＨ
ＭＯＶ Ｂ、Ａ
ＭＯＶ Ｃ、Ｂ
ＭＯＶ Ｄ、Ｃ
ＭＯＶ Ｅ、Ｄ
ＭＯＶ Ｈ、Ｅ
ＭＯＶ Ｌ、Ｈ
ＨＬＴ
実行結果の写真
命令を１個づつ追加するのは面倒だと思ってもみたが、こういう事が有るのでやはり命令は１個づつ追加する事にしよう。（やっぱり）。
２０１７年７月初旬
追加できた命令はＩＮＸとＣＭＡ、ＤＡＡである。
テスト
まずは
ＬＸＩ Ｂ，００ＦＦＨ
ＬＸＩ Ｄ，００ＦＦＨ
ＬＸＩ Ｈ，００ＦＦＨ
ＬＸＩ ＳＰ，００ＦＦＨ
ＩＮＸ Ｂ
ＩＮＸ Ｄ
ＩＮＸ Ｈ
ＨＬＴ
とした。ＩＮＸ ＳＰも入れたかったが１バイト足らない。ＩＮＸ ＨをＩＮＸ ＳＰに変えて２回テストする。
ＩＮＸ ＳＰに変えてテストした写真。
次にＣＭＡとＤＡＡのテスト。
ＬＸＩ Ｂ，００５５Ｈ
ＭＯＶ Ａ，Ｃ
ＣＭＡ
ＨＬＴ
でＡレジスタがＡＡＨになることを確認。
これにＤＡＡを追加すると
ＡＣフラグとＣフラグＯＮしていたので、１０ＨとなりＣフラグがＯＮしている。
取り敢えず動作しているようである。
でもこのペースだとお盆休みまえには完成しそうにない。
１１月ころ完成かなぁ・・・。これだと回路図を書きはじめて１年かかったことになる。あわてて作る必要も無いのでのんびり作るか・・・。
あ、そうだった。ＤＣＸもできているのだった。ＩＮＸとＤＣＸはほとんど同じで、＋１するか−１するかの違いなのでほぼ共通回路でできるのだ。写真を撮り忘れていたので、書き忘れていた。
改めて写真を撮り直した。
レジスタに同じデータを入れるならＬＸＩを並べるよりＭＯＶを使った方が命令バイト数が少なくてすむ。
と言うことで実行した命令は
ＬＸＩ Ｂ，０１００Ｈ
ＭＯＶ Ｅ，Ｃ
ＭＯＶ Ｄ，Ｂ
ＭＯＶ Ｌ，Ｃ
ＭＯＶ Ｈ，Ｂ
ＬＸＩ ＳＰ，０１００Ｈ
ＤＣＸ Ｂ
ＤＣＸ Ｄ
ＤＣＸ Ｈ
ＤＣＸ ＳＰ
ＨＬＴ
これを実行すると全てのレジスタの値は００ＦＦＨとなる。
２０１７年７月中
ＭＯＶ ｒ、ＭとＭＯＶ Ｍ，ｒができた。
早速テストだ。
ＬＸＩ Ｂ，０Ｆ００５H
ＭＯＶ Ｅ，Ｃ
ＭＯＶ Ｄ，Ｂ
ＭＯＶ Ｌ，Ｃ
ＭＯＶ Ｈ，Ｂ
ＭＯＶ Ｍ，Ｃ
ＭＯＶ Ｂ，Ｍ
ＭＯＶ Ｄ，Ｍ
ＭＯＶ Ａ，Ｍ
ＭＯＶ Ｈ，Ｍ
ＨＬＴ
とした。これで全部のレジスタが０５Ｈに書き換わった。しめしめ、できたぞ〜。
せっかくなのでＣ，Ｅ，Ｌレジスタに書くＭＯＶをＨＬＴを除いて追加した。
どーーだと実行させたが・・・・。ありゃ〜。Ｃ，Ｅ，Ｌレジスタが０５Ｈにならない。？？？。
何故？。Ｃ、Ｅ，Ｌ側へデータが行かない？
上に書いたＢ，Ｄ，Ａの所をＣ，Ｅ，Ｌにするとうまく動作した。しばらく悩んだが・・・・。！ひらめいた！！
もう一度冷静に命令を見ると。
ＬＸＩ Ｂ，０Ｆ００５H
ＭＯＶ Ｅ，Ｃ
ＭＯＶ Ｄ，Ｂ
ＭＯＶ Ｌ，Ｃ
ＭＯＶ Ｈ，Ｂ
ＭＯＶ Ｍ，Ｃ
ＭＯＶ Ｂ，Ｍ
ＭＯＶ Ｄ，Ｍ
ＭＯＶ Ａ，Ｍ
ＭＯＶ Ｈ，Ｍ
ＭＯＶ Ｃ，Ｍ
ＭＯＶ Ｅ，Ｍ
ＭＯＶ Ｌ，Ｍ
ＨＬＴ
もうお分かりかな。Ｌに同じデータ入れてどうすんねん・・・と言う突っ込みは無し。問題はＭＯＶ Ｈ，Ｍの位置である。この命令を実行すると、Ｈ＝０５Ｈとなる（当たり前）。
つまり、この後のＭのアドレスは０５０５ＨとなってＲＡＭの無い（と言うか何も無い）アドレスを読み出したのであった。この命令を一番最後に持ってきて、めでたしめでたしとなったのである。
その後ＭＯＶ Ｍ，Ａなど各レジスタからＭへ書く命令をテストした。
ＬＸＩ Ｂ，０Ｆ００５H
ＭＯＶ Ｅ，Ｃ
ＭＯＶ Ｄ，Ｂ
ＭＯＶ Ｌ，Ｃ
ＭＯＶ Ｈ，Ｂ
ＭＯＶ Ａ，Ｃ
ＭＯＶ Ｍ，Ａ
ＭＯＶ Ｄ，Ｍ
ＭＯＶ Ｂ，Ｍ
ＭＯＶ Ｄ，Ｍ
ＭＯＶ Ｈ，Ｍ
ＨＬＴ
を実行したときの写真である。
２０１７年７月中過ぎ
ＩＮＲ、ＤＣＲ命令が出来た。早速テストしてみる。
まずはＩＮＲから。
ＬＸＩ Ｂ，１０１０Ｈ
ＭＯＶ Ｄ，Ｃ
ＭＯＶ Ｅ，Ｃ
ＭＯＶ Ｈ，Ｃ
ＭＯＶ Ｌ，Ｃ
ＭＯＶ Ａ，Ｃ
ＩＮＲ Ｂ
ＩＮＲ Ｃ
ＩＮＲ Ｄ
ＩＮＲ Ｅ
ＩＮＲ Ｈ
ＩＮＲ Ｌ
ＩＮＲ Ａ
ＨＬＴ
テストした写真。レジスタが１１Ｈとなっている。よしよし。
では、次はＤＣＲだ。ＩＮＲをＤＣＲに変えて実行。うまくできた。
次に何気にＤＣＲをＬだけにしてみた。・・・・！・・・・おや〜、Ａレジスタにも同じ値が入る。？？？。じゃぁ、Ｈレジスタだと・・・・。やっぱり同じだ、Ａレジスタに同じ値が入る？？？？。
では、と言うことでロジックアナライザだ。えっ！ロジックアナライザを繋ぐとうまく動作する。Ａレジスタには格納されない。・・・？？？・・・。
ＤＣＲ実行部はＩＮＲ実行部と同一になっている。つまりＩＮＲとＤＣＲをＯＲして命令実行部にＥＮＡＢＬＥを出す。なのにＩＮＲでは問題無い。ＤＣＲ実行に信号が出ない？いやいや実行はしているのだから問題無いはず。この信号だけロジックアナライザに接続してモニタしようとすると現象が出なくなる。おや〜・・・・。分からん。試しに電圧を測ると４．５Ｖだ。問題無い。ＥＮＡＢＬＥ時はＬレベル（ほぼ０Ｖ）になるはず。ちなみに他の命令の端子は４．９Ｖだ。うん・・・。４．９Ｖ。いろいろ測ったが全て４．９Ｖだ。ではＤＣＲのところは何故に４．５なのか？う〜〜ん。眠い。今日は寝よう。
さて、翌朝目が覚めたとたん閃いた。きっと寝ている間に脳が勝手に考えていたのかも。それは、ＶＣＣが浮いているのでは、と言うこと。早速テスターで当たってみると、ビンゴ！。ＶＣＣが浮いていた。そこからＶＣＣを接続しているＩＮＲ，ＤＣＲ実行部も道連れにＶＣＣが浮いていた。出力の寄生ダイオードまたは入力保護ダイオードを通じて電圧が掛かっていたのだ。でもＣＭＯＳなので動作してしまう。
ＶＣＣをチェックして問題部を修正した。
では、どうだ。・・・・ありゃりゃ。ダメである。Ａレジスタのラッチ信号をロジックアナライザでモニタすると、ＤＣＲ命令時にＡレジスタラッチ信号に細いパルスが出ている。ＤＣＲの対象レジスタにかかわらず、いつも出る。何故だぁーー。 そうだ、一晩寝てみよう・・・・goodnight
翌朝・・・なにも閃かなかった。・・・しゃあない、調査だ。ＤＣＲ回路のＡレジスタラッチ信号をはずして（浮かせて）、ロジックアナライザで観測すると、ややっ！立派なラッチ信号が出て来た。つまりラッチ信号がケンカしていたのだ。
ではＤＣＲ命令実行時に同時に動作する命令があるはず。回路を追っかけると・・・、あった！。ＣＭＡ命令が動作してしまう。なぜに・・・、あっ！そうか。昨年の１１月に回路最終段階の見直しでＩＮＲ、ＤＣＲ命令を変更したのを思い出した。元の回路は＋１、−１カウント回路で＋１−１していたが、これではフラグが変化しないので、ＡＬＵで＋１−１するように変更したのだった。
ＡＤＤ命令とＳＵＢ命令を使っても良いが、それではステップ数が多くなるので、なにか方法は無いかと７４ＨＣ１８１のデータシートと別にゲットしたロジック表をににらんで、Ｓ、Ｍ信号とＣ（キャリー）の組み合わせで、入力Ａの出力がＡ＋１の場合とＡ−１の場合があることが分かった。＋１する場合は現状の回路（通常Ｓ，Ｍが全てＨレベル）にＣ＝１（Ｈレベル）にすればＡ＋１が出力される。なのでＩＮＣの場合はＣをＨにするＯＲ回路を追加した。−１する場合はＳ，Ｍを全てＬレベルにすれば良い。現状の回路ではＣＭＡとＡＤＤの信号を同時に入れると良いので、そのように回路を作成したのである。
ではＡＤＤもまずいのかと言うとこれは大丈夫である。演算命令（ＡＤＤ，ＳＵＢなど）実行にＡＤＤするかＳＵＢするかの選択信号としていて、トライステート出力となっていてケンカしない。ＣＭＡは単独の命令実行指令なので、これにＤＣＲを入れるとこの信号自体もケンカしているのである。
ＣＭＡ命令作成時はＤＣＲ命令部は未実装だったので、動作確認で気付かなかったが、もしＤＣＲ命令を先に作っていたらＣＭＡ命令で悩んでいたかもしれない。
ＡＬＵに入れるＣＭＡの信号を余ったＯＲ回路でＣＭＡ、ＤＣＲをＯＲして接続した。
これでようやくＤＣＲ命令が完璧に動作した。
ついでにＣＭＡ命令も追加してテストした写真。
２０１７年７月末
ＲＲＣ、ＲＡＲ、ＲＬＣ、ＲＡＬ、ＩＮＲ Ｍ、ＤＣＲ Ｍ、ＣＭＣ、ＭＶＩ Ｍが完成した。
早速テストした。今度はあっけなく動作した。スルッと動作しても面白くないが・・・。とりあえず動作したのでＯＫとしよう。（写真は無し。あってもランプが点灯しているだけでつまらない？・・・）
２０１７年８月初日
ＭＶＩ ｒ ができた。早速テストした。
ＭＶＩ Ｂ，１
ＭＶＩ Ｃ，２
ＭＶＩ Ｄ，３
ＭＶＩ Ｅ，４
ＭＶＩ Ｈ，５
ＭＶＩ Ｌ，６
ＭＶＩ Ａ，７
ＨＬＴ
うまく動作した。ランプが点灯しているだけだけど、寂しいので写真をアップ。
２０１７年８月中
お盆の帰省で中断していたが、ようやく再開して命令を作った。
ＳＰＨＬ、ＰＣＨＬがまずできた。
取り敢えず動作したので、ＰＣＨＬを使って０番地へ戻るようにしてループさせて、長時間ランニングしてみた。特に問題なく動作している。
次に作ったのは
ＰＯＰ、ＲＥＴとＲＸＸ（条件ＲＥＴ）である。なぜに先にＰＯＰだけかと言うと、回路図の順番がそうなってしまっただけの事だ、深い意味は無い。（当然？）
メモリーにデータを書いておいてＰＯＰで取り出すテストを実行、問題なく動作した。
ＲＥＴも戻り番地をメモリーに書いてＲＥＴで取り出すとそこへジャンプする。これも戻りを０番地にして、ループさせてみた。問題なし。
さて条件ＲＥＴだが、条件が成立してＲＥＴＵＲＮする場合は問題無いが、条件が成立しなかったときに次のステップに進むはずのところが、次の次へ飛んでしまう。
ロジックアナライザで確認すると、条件不成立時の命令クリアが思ったより遅く、次の命令のアドレスラッチに間に合ってない。以前書いたようにアドレスラッチは４クロック目だが、これが最後のクロックなので、これ以上遅らせられない。もともとのタイミング設計がまずいのであるが、ここまで作ってしまったら致し方ない。クロックカウントもクリアするように変更するしかない。こうすると、命令実行時間の見積もりが難しくなるが、動作しないよりはまし、と言うことで改造した。なので命令実行時間はマシンサイクルの時間＋アルファ（命令リセットの遅れ）となってしまった。
もし製作途中でうまい方法を考え付いたら改造するかもしれない。
２０１７年８月中
引き続き、ＰＵＳＨ命令を実装した。
では、テストだ。
ＬＸＩ Ｂ，０ＡＡ５５Ｈ
ＰＵＳＨ Ｂ
ＰＯＰ Ｄ
ＰＵＳＨ Ｄ
ＰＯＰ Ｈ
ＰＵＳＨ Ｈ
ＰＯＰ ＰＳＷ
ＨＬＴ
さーーあ、どうだ。・・・・おやっ？、うまく行かないぞ。・・・・
あっ！、まずいじゃん！。
ＬＸＩ ＳＰ，０Ｆ０００Ｈ
ＬＸＩ Ｂ，０ＡＡ５５Ｈ
ＰＵＳＨ Ｂ
ＰＯＰ Ｄ
ＰＵＳＨ Ｄ
ＰＯＰ Ｈ
ＰＵＳＨ Ｈ
ＰＯＰ ＰＳＷ
ＨＬＴ
そう、スタックポインタを設定しなければ。
さあ、どうだ。・・・・やっぱりうまく行かない。
やれやれ、ロジックアナライザの出番だ。
どれどれ、おや〜。スタックポインタを−１する、最初の信号が出てこない。命令実行タイミングのマシンクロック１クロック目で−１する信号を作っているが、命令実行部のトライステート出力のＥＮＡＢＬＥも同タイミングで入る。以前Ｍ１で命令デコーダをブロックするように改造したので、Ｍ１解除で命令出力信号が出て、それをＨＣ０４で反転させてＥＮＡＢＬＥ信号としているので、実際に−１信号が出力に現れるのが遅れて出てこない。ＥＮＡＢＬＥでトライステートが有効なったときは２クロック目になっているのだ。これではどうあがいても−１信号が出てこない。そこで仕方なく、−１信号は２クロック目を使うことにした。ただし、こうするとアドレスラッチを３クロック目にしているので、スタックを−１した結果がアドレスラッチに間に合わない。
案ずるより産むがやすしで実際に動作させると、うまく動作した。いいのかなあ〜。スタックのカウント完了からアドレスラッチまでの時間をロジックアナライザで見てみると、１０〜２０ｎｓになっている。
ちょっときわどいので、アドレスラッチ信号を１段バッファを通して遅らせてみた。これで先の時間は２０〜３０ｎｓとなった。
取り敢えずこれでしばらく様子を見よう。
２０１７年８月末
次にできたのは、ＣＡＬＬ、ＣＸＸ（条件コール）とＯＵＴ命令だ。
早速ＣＡＬＬをテストしたがうまく行かない。やっぱりスタックのところだろうと当たりを付けてロジックアナライザで見てみると、やっぱりそうであった。この回路ではアドレスラッチがスタックの−１カウント完了よりわずかに早い。ＰＵＳＨみたいにゲートを入れてもギリギリだからこの手も使えない。しばらく悩んだが、ラッチ信号を反転させよう。つまりインバータ（ＨＣ０４）で反転させるとラッチの立ち上がりエッジが６２．５ｎｓ遅くなる。ゲートの信号が命令のＥＮＡＢＬＥで出たとたん１回ラッチされてしまうが、その直後正しいデータ（アドレス）がラッチされる。
試しにやってみるとうまく動作した。みっともない方法、邪道かもしれないが自分で使うマイコンなので良しとしよう。出来た暁には回路図をアップしようと思っていたが、突っ込みどころ満載の回路になってしまったので、止めることにしよう（ヤレヤレ）。
ところでＯＵＴ命令はＩＮ、ＯＵＴのテスト回路を搭載するのを忘れていたのでテストできない。ＩＯＲＥＡＤ、ＷＲＩＴＥ信号が出ているのを確認しただけだ。
ケースに収めた時のパネルの回路でＩＯを使っているのでその時のお楽しみだ。
２０１７年８月末
次にＩＮ、ＸＴＨＬとＲＳＴ作成。これで最後だ。
さて、ＸＴＨＬの確認。実行と同時にどこかへすっ飛んだ。おや〜、ロジックアナライザだ。でもよく分からん。再度回路を確認。あっ！、しまった。ＸＴＨＬはスタックからデータを取り出してＷＺレジスタへ退避して、ＨＬレジスタをスタックに書いて、ＷＺレジスタをＨＬへ書く動作だが、ＷＺレジスタへのアクセスはＣＡＬＬでも使っている。ＣＡＬＬの場合は命令に続く飛び先アドレスをＷＺレジスタへ入れておき、ＰＣ（プログラムカウンタ）をスタックへ入れて、ＰＣへＷＺレジスタのデータを書くと飛び先へ実行が移る。このＷＺレジスタの部分をコピーしてそのままだったのだ。つまりスタックへ入れた適当なデータをＰＣへセットしてしまっていた。（やれやれ）。早速修正。ＷＺレジスタをＨＬレジスタへ書くように変更。無事動作した。
次にＲＳＴ命令だ。固定（８とおり）のサブルーチンコールと同じである。まずスタックにＰＣを退避、ＲＳＴ命令による飛び先をＰＣへセットする。まずスタックに退避するので、ＰＵＳＨ命令と同じタイミングを流用して作成。問題なく動作した。
ＣＡＬＬと同じにしなければならないかとも思ったが、ＰＵＳＨと同じタイミングで大丈夫だった。
２０１７年９月初
さて、取り敢えず命令が完成した。およそ２１０日掛かったので、やっぱり２０本／日のペースだったことになる。
では、連続命令テストをやってみよう。ＤＩＰＳＷのＲＯＭではステップが不足なので本物のＲＯＭに登場してもらおう。
ＲＯＭに書くテストプログラムはあらかじめダウンロードしたaltair8800_emulaterを使ってCP/Mを動作させ、CP/M上で動作する８０８０命令テストプログラムを、このDEBUGボード用に修正してコンパイルした。出来上がったリストとHEXファイルをWINへ転送して、HEXファイルをターミナルソフトでPROMライターへ転送してROMを焼いた。
PROMライターは押入れから発掘してきた。同時にPROMも発掘。PROMはいろいろあったがMB8532を使用、４ｋバイトのPROMだ。そんなに容量はいらないがこれが最小容量のPROMだった。
発掘したPROMライター
もう何年も電源入れてないので、恐る恐る電源入れたら、セルフチェックしてOKと出た。一安心。
使い方を忘れてしまったので、ADVANTESTからマニュアルをダウンロード（便利になった）。
RS232Cのコネクタが２５PINコネクタだ。今時見ないコネクタである。たしかどこかに２５ピン−９ピン変換コネクタがあったはずだが・・・。もう何年も使ってないし・・・、押入れを探したが発掘できなかった。仕様がないので、とりあえず９ピンのメスコネクタをつかって変換を作った。と言っても２５ピンが無いのでこちら側はリードをコネクタのソケットに直接差し込んでみた。
マニュアルを見ながらHEXファイルを転送するとうまく転送できた。INTELのHEXファイルにも対応しているので簡単であった。当時のPROMライターは色んなHEXファイルに対応している。
PROMに書き込んでDEBUGボードに装着した。
さあ、実行だ。
直ぐにずっこけた。ありゃ！。エラーの場合はHLレジスタにエラー発生場所のアドレスが入るようにしているので、リストで確認すると。ん、キャリーフラグがONしていない確認でエラーになっている。確かにキャリーがONしている。これはLOGIC演算（AND,OR,XOR）でキャリーがOFFしていることのテストでエラーになっている。
ありゃ〜。LOGIC演算でキャリーOFF？？。８０８０のマニュアルを見ると、確かにキャリーはリセットされると書いてある。回路の作り忘れ？。う〜ん。記憶のかなたにうっすらと・・・。
そうだ、ALUがよろしくやってくれると思いその後全く気にしていなかった。ALUのA=Bのテストでやっておけば良かったのだが、その時はすっかり記憶のかなたであった。
余ったゲートでなんとか出来そうだ。早速追加して動作確認（DIPSWのプログラム）OKである。
後日追記
よく考えたら、ＡＣは（ハーフキャリーとも言っている）はどうなのだろう。ＡＬＵは４ビットで２段接続している。下４ビットのキャリーを上４ビットにいれて、これをＡＣとしている。つまり論理演算でＣがＯＮするならＡＣもＯＮするはずである。試すとやはりＡＣがＯＮしている。そこで疑問。ＤＡＡ命令のテストでＡＣをクリアするためにＯＲ命令を実行している。ＯＲ Ａを実行すると・・・。ＡＣはＯＮしない。つまりＣもＯＮしない。うん。ＡＬＵまかせでもよかった？？。いろいろ試すと、論理演算のｓｏｕｒｃｅとＤｅｓｔｉｎａｔｉｏｎの値が同じ場合はＡＣ，ＣがＯＮしないことが分かった。８０８０のマニュアルのはＣはゼロをセットすると書いてあるが、ＡＣは結果が反映されると書いてある。ゼロをセットするとは書いてないのでなんらかの状態に変化するのであろう。実際にどうなるかは８０８０が無いので分からない。
ちなみにＤＡＡのテスト前でＡＣをクリアする命令としてＯＲ Ａとなっているので、Ａレジスタに何が設定されていても同じデータどうしなのでＡＣはクリア（ＯＦＦ）される。もしかしたら８０８０も同じ動作かもしれない。ＯＲ ＡとしなければＡＣがクリアされないのかも。
追記ここまで
ではPROMのプログラムスタート。OKだ！。よし！やったーー。出来たぞ！（実はぬか喜び）
次に連続動作スタート・・・・。おや、ずっこけた。連続動作のパスカウントを調べると３が入っていた。３回はうまく動作して４回目でずっこけたことになる。
少なくとも、１回は動作するので、命令の実行シーケンスには問題なく、タイミングに問題がありそうである。
タイミングの問題だと難しそうだ。
さっそくＬＯＧＩＣアナライザを接続。ＨＬＴ命令で停止するので、そこをトリガにする。早速エラーで停止した。調べるとＣＰＩ命令で比較したときにデータは等しいのでＺフラグがＯＮするはずが、ＯＮしていない。Ｚフラグの信号がふらついている。どこかにまだ半田不良があるようだ。ＡＬＵにＬＯＧＩＣアナライザを接続して再実行、どうやらＤ１ラインが不良のようだ。半田をやり直してＯＫとなった。
さあ、ではこれでＯＫか。テストプログラム実行！。ありゃずっこけた。こんどはどこだぁ〜。またもＬＯＧＩＣアナライザを接続、調べるとＩＮＸ命令の後でエラーとなる。何故に？？。ＩＮＸ命令の動作を調べると、ＩＮＸ Ｂ、ＩＮＸ Ｄ，ＩＮＸ Ｈと実行するのだが、どの命令でもＢＣレジスタが選択される。ええっ〜。ＩＮＸ Ｄ、ＩＮＸ ＨでＢＣも同時に選択されるので、データがケンカしている。やれやれ。
選択信号が他の選択信号と混触してるのかなぁ。半田不良かなぁ。とりあえず半田ごてを当てて再半田してみたが、直らない。混触かもと思い、ＢＣ選択信号を出す所の配線をはずしてみた。信号は無くなって安定している。混触は無さそうだが・・・はて。再度配線を接続した。おや、直ってしまった。半田不良だったのかなぁ。ここも再半田してみたところなんだが、不十分だった？？。
直ってしまって現象が出ないと調べようがない。連続動作で評価を続けるしかないかなぁ。
さて、最終的に出来た表の部品搭載状況だ。
ちなみに裏側。配線がカオス状態。
ＲＯＭのテストプログラムを連続動作中。写真ではよく分からんが。
２０１７年９月初旬
あぁ、そうだ、ＲＡＭとＲＯＭのタイミングについて書いてなかったので少し。
ＲＡＭはＨＭ６２６４ＬＰ−１５で１５０ｎｓ。当時のＲＡＭとしては遅い方だ。でも４ＭＨｚクロックだと問題無い。
Ｐ−ＲＯＭはＭＢ８５３２−３５である。３５０ｎｓなので、早い方だが、４ＭＨｚクロックだとギリギリなんとか読める。
手持ちのＰ−ＲＯＭを見るとＭＢ８５３２−３５とＭＢ８５３２−４５が混在していた。当時はあまり気にしてなかったのかなぁ。もうすっかり記憶のカナタである。
どうやら連続運転は大丈夫そうである。これから周辺機器の設計製作である。
押入れから古い物を発掘した。
確かＰＣ−６００１の拡張ＢＯＸからＢＵＳ信号を引っ張り出すＩＦボードと拡張ＭＥＭＯＲＹボードだったと思う。
さらに、その拡張に装着するＦＤＤインタフェースボードである。
確か、これで８インチＦＤＤをドライブしてＬＯＡＤ、ＳＡＶＥしていたような。左の細長い追加のボードは後で追加したクロック成形回路だった（はず）。
真ん中のＬＳＩがＩＮＳ１７７１Ｎ−１で、ＦＤＤをコントロールしてデータを読み書きするのだが、トラックの中央より（トラック番号の大きい方）のデータリードミスが多かった。
それを改善するには読み取ったクロック波形を成形して１７７１に入れると改善できると何かの雑誌に書いてあったので、その回路を追加したのだった。
でも、それほど改善できなかったような記憶がある。
今でも動くのかなあ。ＦＤＤが無いので確認のしようが無い。
あっ！これらを使うつもりはありません。今では１チップで３２ｋＢのメモリが入手できますから。それからＦＰＧＡも。
２０１７年９月
ケースに入れようとして検討したら、横幅４００mmの大きなケースになってしまった。なにせＣＰＵが１枚ボードだから仕方ないかな。
（ツ）さんに発注していたケースが届いた。これからケースの加工だ。
２０１７年９月中
パネルの加工をやっている。文字をいれようとレタリングを取り出したら数字がなかったので、数字とついでに文字も手配。とどくまでお休み・・・？
２０１７年９月中
レタリングが届いたので、文字を入れてクリアラッカーでコーティングした。ただ今乾燥中。
えっ！Ｄ１が少しズレている？。ほかにも？・・・・ええ、これは手作り感を出すためにわざとずらし・・・・・・。はい、不器用なのでズレてしまいました。ＤとＰは８個しか無かったので、やり直せなかったのですぅ！
２０１７年９月末
ＬＥＤを取り付けようしたがバリが出ている（なんだかなぁ）。安いからしょうがないのかもしれないが大陸製というのもあるかも。しかもＬＥＤは後ろから嵌めてあるだけだ。なのでパネルに取り付けてもＬＥＤを前から押すと後ろへ抜けてしまうと思われる。
バリが出ているのがお分かりかな。しかもスプリングワッシャーのような物も変、捻りが逆である。ワッシャーとして役に立たない（やれやれ）。適当に形だけ真似るからこうなるのであろう。
ＬＥＤは後ろへ抜ける。普通の砲弾型ＬＥＤがはめ込んであるだけ。
バリを取るとき気付いたが、バリはカッターで切り取れた。材質は亜鉛（合金）のようである。日本製の真ちゅう削り出しにクロムメッキでは無い。
亜鉛合金のようなので、ネジを締めすぎると首の所で破断しそうだ。ネジ締めは気を付けないと・・・。
ようやく組みあがった。
さて。配線しなければ。
２０１７年９月末
ＬＥＤの配線をコネクタ接続としたいのだが。ＬＥＤのリードとコネクタをユニバーサル基板で接続しようとすると半田付けが裏表でやりにくい。コネクタを先に半田付けしてＬＥＤに基板を付けて半田付けしても配線が・・・。そうだ、ＬＥＤは後ろに抜けるので、まずＬＥＤを半田つけして、ＬＥＤごと外してコネクタを半田付けして配線することにしよう。
で、やってみた。
ＬＥＤを基板に半田付けして、後ろに抜いたところ。この後コネクタを付けて配線した。なるほど後ろに抜けるのはこのためかぁ・・・・（ホンマかいな）。
ＬＥＤとＳＷの配線をやってパネルを組んでみた。
別の角度から。
見れば動作しそうな感じだが、まだこれでは動作しない。なにせ１枚でＣＰＵチップと同等なので、言わばＣＰＵチップだけ搭載したようなものだ。ＳＷの読み込み、ＬＥＤの点灯、メモリーなどが必要だ。
２０１７年１０月初旬
パネルインタフェースとメモリー回路を鋭意製作中だ。
２０１７年１０月中過ぎ
ようやくＳＷインタフェースとメモリーの部分ができた。実装してＳＷからパチパチとプログラムを書き込んで実行させてみた。
メモリはまだＰＲＯＭが出来ていない（プログラムが出来てない）のでＲＡＭだけ。６４ｋＢのエリア全てＲＡＭの状態だ。
あと、ＴＥＫ２７８２の修理で余ったＳＰＡＲＴＡＮ−６のＦＰＧＡを載せてＳＤカードを外部記憶替わりとする予定。さらにＳＤＲＡＭをビデオＲＡＭとしてカラー（８色）表示もするつもり。どこまで出来るやら・・・。
ＲＡＭ２個で６４ｋＢ。ちょっとブレたかな。
取り敢えずＲＵＮ。プログラムは入って無いので暴走状態。この後ＳＷから少しプログラムをインプットしてＲＵＮさせてみた。昔はこうやって動かしていたのだが。
２０１７年１０月下旬
簡単なモニタプログラムを作ってＲＯＭに焼いた。機能はメモリの読み書き、ＩＯの読み書き、ＨＥＸファイルのロード、ブレイクポイント１つ、レジスタ表示、変更である。簡単なデバッグはできる。昔々を思い出しながら製作した。（昔のデバッグはこんなんだったんだよ〜）
早速、命令テストプログラムをＲＡＭで動作するように書き換え、正常パスカウント値を黄色のＬＥＤに表示するようにした。ＨＥＸファイルの作成はaltair8800_emulaterでＣＰ／Ｍを動かし、コンパイルしてＨＥＸファイルを作る。それをターミナルソフトで流し込む。
早速ＲＵＮさせると、途端にエラー停止。んっ！何故に止まる。エラーの箇所を調べるとＣＭＡ命令がエラーとなっている。ああぁＤＣＲ命令でケンカしていたところだ。でも修正確認したよなぁ・・・。って言うかＲＯＭのテストプログラムで動いていたじゃん・・・。半田不良？？
バラしてロジックアナライザを接続。やっぱり半田不良っぽい。ＡＬＵ回りを入念に再半田した。
さあどうだ。再度組み立てて、命令テストを開始。おお、動いた動いた。１５分ほどしたら止まった。えっ！、う〜ん。今度のエラーはＣＭＡではない、ＣＰＩ命令だ。ＺフラグがＯＮしているはずがＯＮしていない。いや〜まだ半田不良が・・・。
また分解。フラグレジスタ回りを再半田。もう他に無いか、ＤＥＢＵＧボードでテスト。動作させながらＩＣを指でコツコツはじくと特定の場所で動作停止する。その辺に半田不良が有りそうだ。そのＩＣ回りを再半田。指でコツコツはじいても動作停止しないようになった。ヤレヤレ。
そういえば半田のやり方が前半と後半で違っている。ＤＥＢＵＧボードの製作より前が前半で、後が後半である。後半で製作したのは命令実行部だが、こちらは半田不良がでない。
前半の半田はＩＣピンに１回巻きで半田鏝の熱で被覆を溶かすやり方と、線の先端を半田メッキしてＩＣのピンへ半田付けする方法だった。しかも半田鏝の温度は後半より少し低い。当然半田付け後にテスタで１００％導通チェックはしたのだが、付きが弱いのか時間とともに取れるようだ。鏝の温度が低め（被覆を溶かすには）だったので被覆が十分に溶けないのと、半田メッキしてＩＣピンへ付ける方法は良さそうだが、ピンの隙間に先端が入り、入り過ぎて半田部分から向こう側へ突き出てしまっていた。
ＤＥＢＵＧボード製作時にこれに気付いたので、その後はＩＣピンに２回巻き、先端を半田メッキしたあとは付き出ないように１回巻きで半田付けした。しかも半田鏝温度を高く設定した。しかも２回巻くと力強く巻けるので、巻いただけでピンの角で被覆に切れ込みがはいり導通する。そこへ半田鏝を当てると熱が線に伝わりやすく被覆が溶けるのが早い。
前半では導通チェックで半田不良が見つかっていたが、後半では１００％不良はでなくなったので、後半の途中から導通チェックは省略した。
結果やはり前半部分での半田不良がでる。後半からは出ていない。
ＲＯＭとＦＰＧＡを装着してみた。ＦＰＧＡの中身はこれから。ケーブルが繋がっているのはＵＳＢ−パラレル変換器。最初はＵＳＢ−ＲＳ２３２Ｃ−パラレルにしようと思っていたが、ＲＳ２３２Ｃにする意味が無いことに気付き、急遽ＵＳＢ−パラレル変換を付けた。モニタソフトはこれでＰＣと通信する。
２０１７年１０月エンド
書き込みが遅くなったが、この時期やっぱり不具合が見つかった。それは条件ＣＡＬＬ命令だ。条件が不成立でＣＡＬＬされなかった時の挙動がおかしい。スタックポインターが１つ減ってしまう。命令テストプログラムでは発見できなかったが、アプリで発覚した。サブルーチン内で条件ＣＡＬＬして、不成立で戻ろうとするとスタックが狂っているので、暴走したのだ。
原因は命令リセット回路である。以前、命令完了でリセットするやり方で、命令完了の次のクロックの頭でリセットしていることを書いたが、それが災いしていた。命令不成立で、次のクロックの頭でリセットを掛けるが、不成立でない場合はＣＡＬＬ先へ飛ぶ動作となる。そのため、現在のプログラムカウンタをスタックへ退避するため、スタックポインターを一つ減らす動作に入る。これが同時に起こるのでスタックポインターが一つ減ってしまう。
そこで、命令リセットのところで、良い考えがあれば変えるかもと書いたが、実は良い考えが出来てはいたのだが、面倒なので実施していなかった。それは、命令完了後のクロックでリセットするのでは無く、命令最後のクロックのその最後でリセットする方法である。実施するには、全ての命令のリセットクロック信号の配線がやり直しとなってしまう。取り敢えず動作しているのでそのままにしていた。
でも、ここだけはそうはいかない、命令条件不成立で実行をブロックする手もあるが、考えたリセット方法の検証の意味もあり、リセットタイミングをＣＡＬＬ命令のアドレス取得完了のクロック最後でリセットする回路にした。結果うまくリセットできて動作にも問題無い。
他の命令全てこの方式に変えるとすっきりするのだが、手間が・・・・。
２０１７年１１月初旬
気付くと、回路設計を開始して１年になる。月日の経過は早いものだ。道理で歳をとるのが早いはずだ。取り敢えずＢＯＸに入って動作を始めたので、１年で完成だ！！
これからＣＰ／Ｍの移植に入る。ＦＤＤなんて無いから、いや無くはないがＳＤＣＡＲＤなるものがあるので、これをＤＩＳＫ代わりにしよう。
早速、ＦＰＧＡでＳＤＣＡＲＤを読み書きする回路を作成している。いろいろネットで手順をさぐっているが、難しいなぁ。
２０１７年１１月中旬
ＳＤＣＡＲＤの初期化ができたので、２ＧのＳＤＣＡＲＤを入れて試してみた。うん、うまく・・・・・いかない！ ？。
ＦＰＧＡの回路はどうも取っ付きにくい。ついついソフトのように書いてしまう。ハードなので同時実行なのだが・・・。
なんとか読み書きできるようになった。ものの本に初期化クロックは４００ｋＨｚくらいと書いてあったので、そのようにしていたが、ネットで早くてもＯＫと書いてあるのを見つけた。早速、クロックアップしてみたが、全然大丈夫である。最終的には１０ＭＨｚクロックとした。
２０１７年１２月中旬
さんざん苦労してＳＤＣＡＲＤの読み書きが出来るようになって、ＣＰＭのＢＩＯＳを作成した。何度かバグ退治していると一月ほど経過してしまった。
まずはＳＤＣＡＲＤだが手元に２ＧＢのカードが２枚ある。1つはＣＭＤ０→ＣＭＤ１で初期化できるが、もう一つはそれではだめで、ＣＭＤ０→ＣＭＤ８→ＣＭＤ５５→ＡＣＭＤ４１としなければならない。
ＣＭＤ８はどちらも有るので、ＣＭＤ０→ＣＭＤ８→ＣＭＤ５５を送ってレスポンスがエラーだったらＣＭＤ１を送るようにした。
ＡＣＭＤ４１を送らなければならないカードは以前スマホで使っていたのパーティションをＷｉｎとスマホ（Ａｎｄｒｏｉｄ）に分けていたせいなのか、ＭＢＲが２重になっていた。
通常だとディレクトリの場所をたどるのに、ＭＢＲ→ＢＰＢ→ＦＡＴ→ＤＩＲとなるのだが、パーティションを分けていて、削除してフォーマットし直したにもかかわらず、ＭＢＲ→ＭＢＲ→ＢＰＢ→ＦＡＴ→ＤＩＲと辿らなければならなかった。最初のＭＢＲでＷｉｎとＡｎｄｒｏｉｄを分けて、そこから通常のＷｉｎのＭＢＲになるようだ。フォーマットしなおしてもここは残っていて、Ｗｉｎ側のＭＢＲで全体の容量が使えるようになっている。
ＢＩＯＳのディスクパラメータをＡｌｔａｉｒ８８００ｅｍｕｌａｔｅｒで書いたディスクイメージが使えるようにした。ＳＤＣＡＲＤの１セクタは５１２バイトだがＣＰ／Ｍの１セクタは１２８バイトなのでＢＩＯＳでバッファしてＲＥＡＤ、ＷＲＩＴＥするようにした。ＲＥＡＤは４セクタ毎にＳＤＣＡＲＤから読めばいいので簡単だが、書き込みは悩んだが、書きたいセクタのＳＤＣＡＲＤのセクタを計算して、読み出して、その中の１２８バイトをメモリに書いてそのまま５１２バイトを書き戻すようにした。同じＳＤＣＡＲＤのセクタであれば２度読みはしないようにはしたが、１２８バイトの書き込みの都度、５１２バイト書いてしまう。出来れば書き込み回数は減らしたいところではあるが、取り敢えず良しとした。キャシュ的にして、５１２バイトデータ変更部がたまってから、またはＳＤＣＡＲＤの異なるセクタの書き込み要求時に書き戻す、書き込みが終了したら書き戻すのが正解かもしれないが、自分で使うのみなので、安易な方法とした。
Ａｌｔａｉｒ８８００ｅｍｕｌａｔｅｒで作成したディスクイメージがそのまま使えるようにしたので、そこに入っていたアセンブラやＢＡＳＩＣがそのまま移植できた。
ＢＯＯＴしてディレクトリを表示したところ
ＬＡＤＤＥＲと言うゲームがあったので起動してみた。
ところが、このゲームを終了するとＨＡＬＴしてしまう。最初はＢＩＯＳをバグったかと思って調べると、ＣＣＰの部分とＢＤＯＳの部分にパターン（ＤＡＴＡ）を持っていて、それが不一致になるとＨＡＬＴする。ＣＰＭ２２のソースにもコメントでパターンが異なるとＨＡＬＴする、ＷＨＹ？と書かれているので、なぜこのような仕組みになっているか逆アセンブルしてコメントを付けた当人にも分かっていないようだ。
私の脳味噌ならぬただの味噌で考えてみたが、ＣＣＰエリアのパターンとＢＤＯＳエリアのパターンを比較しており、どこにも書き込むプログラムは存在しない。ＣＣＰエリアはＷａｒｍ ｂｏｏｔ で再読み込みするが、ＢＤＯＳは読み込まない。なのでＢＤＯＳエリアは破壊されると困るのは確かだが・・・。ＢＤＯＳエリアが破壊されたと判定してＨＡＬＴにして、アプリ開発者に知らしめるのかなあ・・・。ＨＡＬＴせずにＣｏｌｄ ｂｏｏｔでも良さそうだが・・・？
アプリが５９ｋＢＣＰ／Ｍ用では無いと言えばそれまでだが・・・。
ＤＩＳＫドライブ数を８にしたのでバッファエリアにそれなりの容量が必要なので、５９ｋになってしまった。ＢＩＯＳをできるだけＲＯＭに入れると少しは容量が増えて６０ｋＣＰ／Ｍには出来そうだが、今後の課題としておこう。
２０１８年１月中
気づけば２０１８年も半月が過ぎた。取り敢えずＣＰ／Ｍが起動できたが、まだ細かい部分がうまくいかないのを、動作確認しながら修正した。例えば、ＷＭでプログラムを編集して終了したときに、必ずＡドライブに戻ってしまう。Ａドライブで編集していると気づかなかったが、ＢやＣドライブで編集してもＡに戻る。ウオームブート後にＣＰ／ＭへジャンプするときＣレジスタにカレントドライブ番号を入れておかなければいけないのが、入ってなかったのだ。などなど・・・。
ところがこれが災いしてか、存在しないドライブに切り替えたときエラーとなるが、コントロール＋Ｃでウオームブートして再び、エラーとなる。つまりカレントドライブの存在しないドライブへアクセスして、再度エラーとなる。これを永遠と繰り返す・・・。なんだかなぁ・・・。ＣＰ／Ｍのソースを見てもコントロール＋Ｃで単にウオームブートへジャンプしているだけ。う〜ん、どうすれば・・・・。暫し考えよう・・・。
２０１８年２月初
やれやれ２月になってしまった。
ＦＰＧＡボードのＤＲＡＭにＭＤＫ８０８０からデータを書き込んで、それをＶＧＡ信号で出力する部分を作成していた。ＭＤＫ８０８０からデータを書くときにミスることがあり、いろいろ調べると、ＭＤＫ８０８０の５Ｖ系からＦＰＧＡの３．３Ｖ系の変換機器が誤動作しているようだ。秋月で買った変換機で双方向自動切換えなのだが、データバスは双方なのでこれで良いがアドレスやＩＯ、ＭＥＭＯＲＹのＲＥＡＤ／ＷＲＩＴＥ信号は一方向なので自動切換えは不要である。よく調べるとデータも不安定だ。時々化ける。なのでデータバスは７４ＨＣ２４５を付けて、変換機が方向を間違ってもＭＤＫ８０８０側へ影響が及ばないようにした。でもアドレスやＲＥＡＤ信号なども影響があるのでバッファを入れた。自動切換えは良さそうで、あまりよくなかった。意図した方向になってくれない。
さて、方向を固定したが（データバスは違うが）まだ動作がおかしい。さらに調べるとＩＯＷＲＩＴＥ信号にノイズが載っているようだ。う〜ん、配線の引き回しがまずいのかなあ。しようがないので、ＦＰＧＡでチャタリング防止回路のような回路で読むことにしてずいぶんと改善された。でもまだときどきおかしい時がある。ほとんど問題なく動作するのだが、忘れたころＷＲＩＴＥ信号を見落とすことがある。ほとんどＳＤＣＡＲＤの読み出しコマンドの書き込み（ＷＲＩＴＥ）を見逃すので、データＲＥＡＤで待ちぼうけになって、だんまりになる。待ちぼうけにならないように監視タイマーを入れると良いのだが、そこまでやっていない。
ふつうに遊ぶにはぜんぜん問題ないからだ。
ＺＯＲＫを遊んでみた。
２０１８年３月
ＢＤＳ＿Ｃを入手した。昔昔買った使い方の本を発掘してきた。これは文法書ではなく、タイトルどおり使い方だ。８０８０のＣＰ／Ｍで動作させる説明となっている。早速開いて見たがすっかり忘れている。ミスプリを修正した痕跡があるので、当時、一所懸命読んだのであろう。が、記憶のかなたである。
早速、テストプログラムを作って起動すると・・・、動作はうまく行くが、終了でＨＡＬＴする。おやおや、ＬＡＤＤＥＲゲームと同じだ。何故だろう？？？。
ＤＤＴを使ってデバッグすることにした。
デバッグ開始してすぐに気づいたが、６番地から２バイトデータを取ってきてスタックにセットしている。６番地は、ＢＤＯＳコールの５番地の飛び先なので、ＢＤＯＳのエントリポイントとなっている。そうかぁ、ＢＤＯＳの先頭をスタックにしているのかぁ。つまりＣＣＰエリアはスタックで壊れる仕掛けになっている。でも、ＢＤＯＳのエントリはピッタリの番地ではなく６番地ずれている。たとえばＤ８０６番地の様に、ＨＡＬＴにするチェックパターンはこの前の６バイトになっている、Ｄ８００〜Ｄ８０５がチェックパターンになていて、ＣＣＰにあるパターンと比較して、違っていたらＨＡＬＴする。
でもここをスタックとして使うのだから、絶対に壊れる。これではＣで作成したプログラムを動作させると必ずＨＡＬＴすることになる。やれやれだ、ＣＰ／Ｍを改造してＨＡＬＴせずに０番地へジャンプさせようか、そうするとウオームブートするはず・・・・。じゃない、ＨＡＬＴするのはウオームブートの後なので、そんなことするとウオームブートを繰り返すだけである。
うーーん、しょうがない、ＢＤＯＳの先頭１セクタをウオームブートで読み込むことにしよう。
そこで、ウオームブートを改造してＲＯＭを焼き直した。早速ためすと・・・・。うまく行った！。よし！
これでＬＡＤＤＥＲの終了もうまく行くようになった。
つづく