標準ＴＴＬだけ（！）でCPUをつくろう！（組立てキットです！）
(ホントは７４ＨＣ、ＣＭＯＳなんだけど…）
やっと（！）MYCPU80の改良型基板製作に着手しました！！





［第８３８回］

●ＭＹＣＰＵ８０の修理

ずっと追われておりました受注品の納品などの作業がやっと片付いて久しぶりにほっと一息つくことができました。
しかしのんびりはしておれません。
もうじき新ＭＹＣＰＵ基板ができてきたら、またがんばって見本としての組立作業をしなければなりません。
またおよそ１年ほども中断したままになっておりますＫＬ５Ｃ８０Ａ１２マイコンボードについてもいい加減に再開しなければなりません。
トランジスタでつくるＣＰＵボードも中断したままなので、そちらのほうも今年こそ再開しなければなりません。
ということになりますと、もう今しかありません。

実は昨年の７月からおよそ半年もの間お預かりしたままになっておりますＭＹＣＰＵ８０の修理依頼品があります。
半年もの間忘れていたわけではありません。
落ち着いてじっくり時間をかけないと解決できそうにない、と判断したからです。
それでご依頼いただいたお客様には「しばらく預からせてください」とお伝えしたのですが、私としてもまさか半年もお預かりすることになるとは思ってもみませんでした。
今思い返してみましても、この半年はそれほどにきついものでありました。

しかし、例年のことなのですが正月の休みを返上してがんばったおかげで、やっと１月の終わりになって少し時間が取れましたので、それでこの機会にお預かりしておりましたＭＹＣＰＵ８０の修理に取り組むことにいたしました。
このＭＹＣＰＵ８０の修理ではどうして時間がかかりそうと判断したのかといいますと。
「ＡＳＴＥＣ　Ｃの実行途中でこけてしまいます」という内容だったからです。

ＡＳＴＥＣ　Ｃについては「ＣＲＴ/VGAIF+KEYIF+SDCARDIFボードの製作」[総合第７８回]で紹介いたしました。
実は今回ＭＹＣＰＵ８０をお預かりしたのは、そこに書きました「ＭＹＣＰＵ８０でＡＳＴＥＣ　Ｃが途中でエラーになってしまいます」というメールをお送りいただいたお客様からです。
そのときもお問い合わせをいただいてから１年もお待たせしてしまいました。
毎回書いておりますようにいつも時間がないのは事実なのですが、それでも半日や１日でなんとかなりそうなものでしたら、それほど長くお待たせしたりはいたしません。
ただ内容が自分にとって全く知識のないことですので、そういうものに取り組むためにはよほど心にゆとりがないととてもできません。
結果的に随分長くお待ちいただくことになってしまいました。
２度も長い間お待たせすることになってしまいました東京都のＹ様にはあらためてお詫び申し上げます。

さてそれで、ずっとお預かりしたままになっておりましたＭＹＣＰＵ８０の動作テストにかかったのですが、なるほどＡＳＴＥＣ　Ｃの途中で異常ブレークしてしまいます。
下はそのときのログです。

D>CC TEST4.C C Vers. 1.06D 8080 (C) 1982 1983 1984 by Manx Software Systems D>AS TEST4.ASM 8080 Assembler Vers. 1.06D D>LN TEST4.O C.LIB C Linker Vers. 1.06D Base: A F B C D E H L PC SP SZ H P C 0400 0034 0004 0034 35D9 D304 00000000

リンクの途中で異常ブレークしてしまいます。
念のためＭＢＡＳＩＣを起動してＳＴＡＲＴＲＥＫを実行してみたのですが、こちらのほうはまともに実行されます。
ちょっと信じられないことなのですが、何か普段滅多に使われないような命令の使い方でもしているのでしょうか。
さて困りました。
こうなると命令のひとつひとつを試してみるしかありません。
そういえば。
確か以前にそういうためのテストプログラムを作ったようなかすかな記憶が…。

ありました。
「ＭＹＣＰＵ８０でＣＰ／Ｍを」［第３２回］に書いておりました。
それで、さっそく実行してみたのですが…。

D>CC TEST4.C >/ld test1b.bin,8000 loading TEST1B.BIN ...00f2(242)bytes loaded,from 8000 to 80F1 >jp 8000 >p.hex$(a%) AFFC >/ld test2b.bin,8000 loading TEST2B.BIN ...0089(137)bytes loaded,from 8000 to 8088 >jp 8000 >p.hex$(a%) AFFC >/ld test3b.bin,8000 loading TEST3B.BIN ...00ec(236)bytes loaded,from 8000 to 80EB >jp 8000 >p.hex$(a%) AFFC >/ld test4b.bin,8000 loading TEST4B.BIN ...00d9(217)bytes loaded,from 8000 to 80D8 >jp 8000 >p.hex$(a%) AFFC >/ld test5b.bin,8000 loading TEST5B.BIN ...00dc(220)bytes loaded,from 8000 to 80DB >jp 8000 >p.hex$(a%) AFFC >/ld test6b.bin,8000 loading TEST6B.BIN ...0128(296)bytes loaded,from 8000 to 8127 >jp 8000 >p.hex$(a%) AFFC >/ld test7b.bin,8000 loading TEST7B.BIN ...012d(301)bytes loaded,from 8000 to 812C >jp 8000 >p.hex$(a%) AFFC >/ld test8b.bin,8000 loading TEST8B.BIN ...0093(147)bytes loaded,from 8000 to 8092 >jp 8000 >p.hex$(a%) AFFC >/ld test9b.bin,8000 loading TEST9B.BIN ...01fd(509)bytes loaded,from 8000 to 81FC >jp 8000 >p.hex$(a%) AFFC >/ld test10b.bin,8000 loading TEST10B.BIN ...008e(142)bytes loaded,from 8000 to 808D >jp 8000 >p.hex$(a%) AFFC >/ld test11b.bin,8000 loading TEST11B.BIN ...006a(106)bytes loaded,from 8000 to 8069 >jp 8000 >p.hex$(a%) AFFC >/ld test12b.bin,8000 loading TEST12B.BIN ...0091(145)bytes loaded,from 8000 to 8090 >jp 8000 >p.hex$(a%) 9FFE >

全くエラーなく全命令をクリアしてしまいました。
これってどういうこと？
おお、しかし。
そういえば、以前にこのテストをしたときも同じようなことがおきたような…。
で。
あらためてそのときの記事をじっくり読んでみましたら。
「ＭＹＣＰＵ８０でＣＰ／Ｍを」［第３９回］になりまして、まさかの結論になっておりました。
おお、そうでした。
このときの結果から、それ以後はレジスタ回路のＧＮＤラインをジャンパ配線で補強することにしたのでした。
うーん。
そうだったか。
このときもありえない異常動作がもとで最後にたどりついた結論としてＧＮＤラインをジャンパ配線で補強するという対策をしたのだったか。

確認してみましたら、今回のＭＹＣＰＵ８０基板もちゃんとその補強はしてありました。
しかし。
ひょっとすると。
たまたまこの方のＭＹＣＰＵ８０はそれだけの対策では足りないのかも。
そのように考えたものですから、下のようにそのほかの弱いと思われるＧＮＤラインも同じように補強してみました。


茶色の線がもとからのジャンパ配線で、青色の線が今回追加した配線です。
手持ちの０．３ＳＱの被覆線を使いました。
このように追加配線をおこなってから、あらためてＡＳＴＥＣ　Ｃを実行してみました。

D>ln test4.o c.lib C Linker Vers. 1.06D Base: 0100 Code: 1b71 Data: 01ef Udata: 0250 Total: 001fb4 D>test4 char 1 short 2 int 2 int * 2 long 4 float 4 double 8

上記の対策が功を奏したらしく、異常ブレークすることなく正しく実行されるようになりました。
結果としまして東京都のＹ様には随分長い間ご不便をおかけしてしまいましたことを重ねてお詫びいたします。

なお今回お預かりしましたＭＹＣＰＵ８０ではもう一点不具合があって調整したところがありますが、今回はちょっと長くなってしまいましたので、それについては次回に書くことにいたします。

ＴＴＬでＣＰＵをつくろう！［第８３８回］

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

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