２０１２．２．９
前へ
次へ
ホームページトップへ戻る

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

［第２９回］

●メモリ増設基板裏のＩＣソケット

メモリ増設基板裏には細ピンヘッダーを取り付けてありますから、その先にさらにＩＣソケットを取り付けて、そのＩＣソケットをＮＤ８０ＺⅢのＲＯＭ用ソケットに挿すというのは、無駄なことのように思われるかもしれません。
ですのでここは説明が必要かと思います。

最初は私も細ピンヘッダーを直接ＮＤ８０ＺⅢのＲＯＭ用ＩＣソケットに挿そうと考えました。
しかし複数の理由から、細ピンヘッダーの先にさらにＩＣソケットを取り付ける、という案に落ち着きました。

その１番目の理由は、ＮＤ８０ＺⅢのＲＯＭ用ＩＣソケットの近くにあるＲＡＭとＺ８０ＣＰＵの背の高さの問題です。
下の写真を見てください。
メモリ増設基板をＮＤ８０ＺⅢに取り付けたところを、横から撮った写真です（少し前に撮った写真なので、まだ電解コンデンサがついていません）。



細ピンヘッダーに取り付けたＩＣソケットがゲタになっていて、増設基板が左右のＺ８０ＣＰＵとＲＡＭから少し離れています。
このＩＣソケットのゲタをはかせないと、この位置では細ピンヘッダーの長さが少し足りなくて、左右のＺ８０ＣＰＵとＲＡＭに邪魔をされて、しっかりとＲＯＭ用ＩＣソケットに挿すところまでいかないのです。

第２の理由は、作業のし易さです。
メモリ増設基板裏側のＩＣソケットは、ｐｉｎ２０とｐｉｎ２２を切り取らなければいけません。
ＩＣソケットのピンは薄くて柔らかいので、簡単に折り取ることができますが、細ピンヘッダーは細いとは言え、とても折るわけにはいきません。
ニッパーが必要になりますが、抵抗などのリード線よりも太くて固いので、ニッパーの刃先をいためてしまうかもしれません。

それにひょっとして、うっかり間違えて、別のピンを折ってしまうかもしれません。
また、ＮＤ８０ＺⅢのＲＯＭ用のＩＣソケットに挿すときに、ピンの先を曲げてしまうかもしれません。
そんなときでも、普通のＩＣソケットですから、安価に入手して交換することができます。

第３の理由は、ＲＯＭ用ＩＣソケットに直接細ピンヘッダーを挿すと、ＩＣソケットをいためてしまうかもしれないという懸念があったからです。
丸ピンソケットならばＩＣピンのコンタクト部分も堅牢ですが、ＮＤ８０ＺⅢのＲＯＭ、ＲＡＭ用のＩＣソケットは、ごく普通のバネによってＩＣピンを支える形のものですから、ＩＣピンよりも太い、幅の有る端子を挿し込むと、ピンのバネが変形して接触不良になってしまう可能性があります。

メモリ増設基板の裏側の細ピンヘッダーの先にＩＣソケットを取り付けるようにしたのは、そういう理由からです。

●またしてもお恥ずかしいミス

お恥ずかしいミスにつきましては前回にも書いたばかりなのですが、またまたお恥ずかしい初歩的なミスのために、およそ１日を空費してしまいましたというお話です。

前回のミスは間違っている回路図や写真をＵＰしてしまったあとで気が付いたのでありますから、これはもう黙っているわけにはいきません。
あ。いや。そ知らぬ顔で黙って差換えてしまうことだってできないことはありませんけれど、お読みいただいております方の中には、毎回コピーしてノートパソコンに移した上で出先などで時間をみつけてお読みいただいておりますとか、全部プリントアウトしてファイリングしていただいておりますとか、もう冥利に尽きるといいますか、まことに有り難いお話などもお聞きしておりますので、とてもとても黙って差換えてそ知らぬ顔などはできませんです。

しかし。
今回は、別に何かを発表したわけでもありません。
私だけが黙っておれば誰も知らぬことでありますから、黙っておればよいのでありますけれど。

だいたいにおいて、うまくいった話、他人の成功談など、読んでいても面白いものではありませぬ。
そこへいきますと、他人が失敗したりヘマをやったような話は面白い。
他人の不幸は蜜の味であります。
昔から対岸の火事は大きいほどよい、と相場は決まっております。

毎回毎回退屈な話ばかり読んでいただいておりますのもまことに申し訳無いことでありますので、たまには犠牲的精神を発揮いたしまして、おばかな失敗談を書くのもよろしいかと…。
そういう次第で。恥なお話です。

昨日は、とうとう更新するゆとりもありませんでした。
ことの次第と申しますのは。

やっとメモリ増設基板についての説明も一段落しましたので、ずっと棚上げにしておりました、ＣＰ／ＭソースファイルのＢＩＯＳパラメータの設定についての説明にとりかかることにいたしました。
このところメモリ増設基板の説明ばかりが続いておりましたが、もちろん楽屋裏では、着々とＣＰ／Ｍの実装に向けて作業を進めておりまして、当初はまったくわからなかったところもかなり理解できるようになってきました。

オリジナルのＣＰ／Ｍソースファイルに対する変更箇所は、当初は［第２０回］あたりで説明しております通りでしたが、その後にそこからさらに手直ししたところなどが出て来ています。
気が付いたところなどは、時間をみつけてちょいちょいと手直ししたりもしていたのですが、それをアセンブルして、できたマシン語のプログラムをＮＤ８０ＺⅢに組み込んで、みなさま方のお手もとのＮＤ８０ＺⅢでも同じ動作テストをやっていただくことができますように、念の為に、もう一度テストをしておくことにいたしました（この段階ではまだ増設メモリボードは使いません。標準のＮＤ８０ＺⅢ機能のみでテストを行なえます）。

そこで、昨日は朝から、あらためての動作テストに取りかかったのでありますが。
なんと。
突然に、今まで出たことのない、怪しげなエラーメッセージが表示されてしまいました。



ｔ１５２０　ｔ１５２０－２．ｔｘｔ［Ｅｎｔｅｒ］と入力した途端にエラーメッセージが表示されてしまったのですが…。
しかし、これはすでにテスト済みのプログラムです（［第１５回］）。
今まで何回も同じテストをしていても、こんなエラーメッセージは出たことがありません。
思うに、ここ１週間ほどの間に行なったプログラム修正が原因であることにほぼ間違いはありませんでしょう。

まあ。確かに。
当初わけもわからずいい加減に書いていたＢＩＯＳのパラメータとかプログラム部分も、ある程度は理解が進んできましたので、そのためにあちこち書き直したことも事実です。
しかし。

わけもわからずに適当に書いたときにはうまくいっていて、わけがわかってきて書き直したら、途端にエラーメッセージが出てしまった、というのも不条理なものでありますが、まあ、世の中といいますのは、大体においてそのようなものであります。

一体どこを直したのが原因だったのか、と思って、こちらが修正前、こちらが修正後、なんて調子で調べ始めたのですけれど、なにしろメモも取らずに思いつくままに直していたものですから、どの段階までがよくて、どこからがおかしくなったのか、ということを追求するだけでも一苦労でありました。

が。
やっと、わかりました。
たった、１行の手直しがその原因らしいということまでは、わかりました。
この部分です。

	ORG CPMTOP	;	ORG	(MEM-7)*1024
REBOOT:
CBASE:	JP	COMMAND		;execute command processor (ccp).
	JP	CLEARBUF	;entry to empty input buffer before starting ccp.

実はこの部分は当記事を書く段階でこのようにしたのですが、もともと私が実際にテストしたプログラムでは下のようになっていました。

	ORG CPMTOP	;	ORG	(MEM-7)*1024
REBOOT:	JP	COMMAND
CBASE:	JP	COMMAND		;execute command processor (ccp).
	JP	CLEARBUF	;entry to empty input buffer before starting ccp.


記事を書く段階で、ＪＰ　ＣＯＭＭＡＮＤがダブっていることに気が付いたので、上のようにしたのですが、そのように直したものでは実際にテストはしていなかったのです。
それでは記事で紹介したプログラムと、私がテストしたプログラムとが異なってしまいますから、そこを合わせておこうと考えて、上のように直したものでテストをしたのです。

このように書きますと、いとも簡単に原因個所が見つかったように思われるかもしれませんが、変更箇所はここだけではなくて、ほかにもいろいろ直していますから、その中から、ここにたどりつくまでには一苦労でありました。
とにかく、上のように直したプログラムを実行すると、さきほどのエラーになります。
直さないでＪＰ命令がダブっているプログラムではエラーは発生しません。

しかし。
一体、この変更のどこがいかんのか？
プログラムの先頭のＪＰ命令を削ったため、以後の命令やジャンプ先アドレスはすべて３バイトずれてきますが、それでエラーが出るというのも奇怪な話です。
ｓｅｃｔｏｒＲＥＡＤにともなうエラーかとも思いましたが、ＤＩＲコマンドは正しく実行されています。
そのあとでｔ１５２０．ｃｏｍを実行した直後にエラーが発生しているように見えます。
しかし、上でも書きましたように、このプログラムはテスト済みのものです。

むむ。
面妖な…。
しかし、このままにしておくわけにはいきませぬ。
覚悟を決めて原因を追求することにいたしました。
ほんとうにきつい人生であります。

さきほど説明をしましたように、先頭のＪＰ命令を削除したＣＰ／Ｍでは、ｔ１５２０．ｃｏｍを実行すると必ずエラーメッセージが出ることがわかりましたから（実は他のプログラムを実行しても出ることもわかりました）、まずはこのエラーメッセージの正体から追求してみることにいたしました。

追求がし易いように、アセンブルリストをもとに調べていくことにしました。
まずは「Ｂｄｏｓ　Ｅｒｒ」をキーワードに検索してみました。



表示するのに使ったテーブルはここに間違いないようです。
すると次は、ラベルＢＤＯＳＥＲＲ：を使っているルーチンを捜すことになります。

ＢＤＯＳＥＲＲを使っているのはここだけしかありません。



すると次はＰＲＴＥＲＲの検索です。

ＰＲＴＥＲＲはＥＲＲＯＲ１とＥＲＲＯＲ５で使われていることがわかりました。



でもよく見ますと、ＥＲＲＯＲ５はＥＲＲＯＲ２～ＥＲＲＯＲ４でも使われていますから、結局ＥＲＲＯＲ１～ＥＲＲＯＲ５の全てが対象になります。

しかし。全て？
さらにさらによく見てみますと、ＨＬに第２テーブルを入れています。
さきほどのメーセージでは、最後の’Ｓｅｌｅｃｔ’がそれのようです。
さきほどのキーワード検索で見ますとＳｅｌｅｃｔにはＢＡＤＳＥＬラベルがついています。
ということは、ＥＲＲＯＲ２がＣＡＬＬされたということになります。

しかし？
ここで疑問が。
ＥＲＲＯＲ２には’Ｂａｄ　ｄｒｉｖｅ　ｓｅｌｅｃｔｅｄ’というコメントがついています。
しかし、しかし。
もう一度さきほどのメーセージを見ますと、’Ｂｄｏｓ　Ｅｒｒ　Ｏｎ　Ａ：　Ｓｅｌｅｃｔ’になっています。
なんで、Ａドライブが、Ｂａｄ　ｄｒｉｖｅなのか？
なんとなく、嫌な予感がいたします。

ＥＲＲＯ２で検索しましたら、ここだけであることがわかりました。



ＢＡＤＳＬＣＴです。
確かに、ｂａｄ　ｄｉｓｋ　ｓｅｌｅｃｔと書いてあります。

今度はＢＡＤＳＬＣＴの検索です。
ここだけで使われています。



なんだか疲れてしまいますねえ。

ＳＬＣＴＥＲＲで検索しました。
ここ１箇所だけで使われています。



むむ。
ＬＯＧＩＮＤＲＶかあ…。
しかし、なぜここでＢＡＤ　ＤＲＩＶＥになってしまうのか…。
見たところ、ちゃんとＡドライブをアクセスしているようですし、そもそも今はテストなのでＡドライブしかありません。

プログラムを眺めていただけでは解決がつかないときは、実際に実行しながら追求してみるしかありません。
そう、デバッグです。
ＮＤ８０ＺⅢのＺＢ３ＢＡＳＩＣには、簡単なものではありますが、デバッグのための機能が備わっています。
それを使って追求をしていくことにいたしました。

ここで、またもや、納得のいかない摩訶不思議な現象に遭遇するのであります。
以下はそのときの様子を記録した、実際のログファイルです。
番号は説明のために後から書き加えたものです。

>/ld cpm_1o4.bin,bc00
loading CPM_1O4.BIN ...16e8(5864)bytes loaded,from BC00 to D2E7
>bp d035(1)
>jp bc00(2)

A F  B C  D E  H L  A'F' B'C' D'E' H'L'  PC   SP   IX   IY  I  SZ H PNC
FFAC 8000 D223 0000 0044 0000 0000 0000 D035 C73F 0044 F1A1 FF 10101100
>bp d038(3)
>rt

A F  B C  D E  H L  A'F' B'C' D'E' H'L'  PC   SP   IX   IY  I  SZ H PNC
FFAC 8000 D223 0000 0044 0000 0000 0000 D038 C73F 0044 F1A1 FF 10101100
>bp d035(4)
>rt

a>dir(5)
A: FILLE5   COM : ABC      COM : CPMTST9  COM : TST012   COM
A: TST6     COM : TEST1520 TXT : T1520    COM : T1520-2  TXT
a>t1520 t1520-2.txt(6)

Bdos Err On A: Select
A F  B C  D E  H L  A'F' B'C' D'E' H'L'  PC   SP   IX   IY  I  SZ H PNC
FFAC 8000 D223 0000 0044 0000 0000 0000 D035 C73F 0044 F1A1 FF 10101100
>0000 00C3 - 
リモート接続を終了しました
logfile closed at Wed Feb 08 23:24:44 2012


ここで何をやっているかを説明いたします。
何が起きているのかを探るために、エラーメッセージが表示される直前でブレークさせて、そのときのレジスタの内容を確認してみることにしました。

ＢＰ　Ｄ０３５　はアドレスＤ０３５にブレークポイントを設定するコマンドです（１）。
ここはまだＺＢ３ＢＡＳＩＣです。
そうしておいて、ＪＰ　ＢＣ００　で、ＣＰ／Ｍにジャンプします（２）。

すぐにブレークしてレジスタダンプが表示されます。
ＰＣ＝Ｄ０３５ですから、ちゃんとブレークは機能しています。
アドレスＤ０３５の命令を実行する直前にブレークしています。
レジスタを調べますと、右のほうにありますフラグレジスタの中のＺフラグは０になっていますから、Ｚフラグが立っていないことがわかります。
さきほどのプログラムリストを見ますと、アドレスＤ０３５の命令は、ＣＡＬＬ　Ｚ，ＳＬＣＴＥＲＲですから、Ｚフラグが立っていないときは、エラーメッセージは表示されません。
どうやら、このルーチンはくり返し実行されるようです。

そういうときは、一旦先に進んだところにブレークポイントを設定して、そこでブレークしてから、またここに戻ってブレークするようにします（Ｄ０３５でブレークしたまま、次のＤ０３５でのブレークを設定することはできません）。

ＢＰ　Ｄ０３８［Ｅｎｔｅｒ］
ＲＴ［Ｅｎｔｅｒ］
で、Ｄ０３８にブレークポイントを設定して、実行を再開します（３）。
ＲＴはブレークしたところに戻って実行を再開するためのコマンドです（ＲＴ＝ｒｅｔｕｒｎ）。

すぐにブレークしますが、ここは再度Ｄ０３５でブレークさせるためのダミーとしてブレークさせたものですから、レジスタの確認は不要です。

もう一度、
ＢＰ　Ｄ０３５［Ｅｎｔｅｒ］
ＲＴ［Ｅｎｔｅｒ］
で、Ｄ０３５にブレークポイントを設定して、実行を再開します（４）。

すると、
ａ＞と表示されましたから、ＤＩＲ［Ｅｎｔｅｒ］と入力しました（５）。

ディレクトリが表示されたあと、またａ＞と表示されました。
いよいよ、です。
ｔ１５２０　ｔ１５２０－２．ｔｘｔ［Ｅｎｔｅｒ］と入力しました（６）。

すると、ここで信じられないことが起きてしまいました。
なんと、Ｂｄｏｓ　Ｅｒｒ　…のエラーメッセージが表示されてしまったのです。
（４）で設定したブレークポイントをすり抜けて…！

エラーメッセージの表示後にブレークしているのは、［Ｃｔｒｌ］［Ｅ］を入力してＣＰ／Ｍを強制終了するときに、Ｄ０３５が実行されたためだと思われます（Ｚフラグは立っていません）。

しかし。
Ｄ０３５を通過することなしに、このエラーメッセージが表示されるはずはないのです…。

説明が長くなってしまいましたので、この続きは次回にすることにいたします（疲れました）。

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

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