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

［第３０回］

●Ｂｄｏｓ　Ｅｒｒの解明

前回からの続きです。
そこしか通らないはずのアドレスにブレークポイントを設定したにもかかわらず、そのアドレスをすり抜けてエラーメッセージが表示されてしまいました。
プログラム的には有り得ないことが、現実に起きています。
ということは、本来の設計を離れたルートを通ってエラー表示ルーチンが実行された、ということになります。

そういうことならば。
事実は事実として認めた上で、それではどういうルートでエラー表示ルーチンが実行されたのか、ということを追及していくことにいたします。

前回は、Ｄ０３５にブレークポイントを設定してトラップを張ったのですが、見事にすり抜けられてしまいました。

Ｄ０３５　ＣＣ４７Ｃ７　　　ＣＡＬＬ　Ｚ，ＳＬＣＴＥＲＲ

は、通らなかったということです。
それならば、理由は置くとして、その先のＳＬＣＴＥＲＲが実行されてしまった可能性はあるのでしょうか？

ＳＬＣＴＥＲＲは前回お見せした、こちらのリストにあります。



ＳＬＣＴＥＲＲのアドレスはＣ７４７ですが、その次のＣ７４Ａも必ず実行されるはずですから、Ｃ７４Ａにブレークポイントを設定して、前回と同じように、ＣＰ／Ｍを起動して、ＤＩＲコマンドを実行したあと、ｔ１５２０　ｔ１５２０−２．ｔｘｔ　を実行してみました。

その結果は、下のログファイルにありますように、やはりＣ７４Ａに設定したブレークポイントを通らずにエラーメッセージが表示されてしまいました。

>/ld cpm_1o4.bin,bc00 loading CPM_1O4.BIN ...16e8(5864)bytes loaded,from BC00 to D2E7 >bp c74a >jp bc00 a>dir A: FILLE5 COM : ABC COM : CPMTST9 COM : TST012 COM A: TST6 COM : TEST1520 TXT : T1520 COM : T1520-2 TXT a>t1520 t1520-2.txt Bdos Err On A: Select

どうやらもっと先の部分がいきなり実行されてしまっているようです。
もう、何かミステリーの世界にでも突然スリップしてしまったような感じです。
Ｃ７４７　２１０ＢＣ４　　ＳＬＣＴＥＲＲ：ＬＤ　ＨＬ，ＢＡＤＳＬＣＴ
Ｃ７４Ａ　５Ｅ　　　　　　ＪＵＭＰＨＬ：ＬＤ　Ｅ，（ＨＬ）
の先ということになりますと、ＢＡＤＳＬＣＴをたぐっていくことになります。

ＢＡＤＳＬＣＴも前回お見せしたこちらのリストにあります。



しかしＢＡＤＳＬＣＴにありますのはジャンプテーブルで実行命令ではありません。
Ｃ４０Ｂ　Ａ５Ｃ４　ＢＡＤＳＬＣＴ：ＤＥＦＷ　ＥＲＲＯＲ２
は、ここに書かれているＣ４Ａ５がＨＬレジスタに入れられて、ＪＰ　（ＨＬ）命令でそのアドレス（Ｃ４Ａ５）にジャンプするためのテーブルです。
つまりは、そのテーブルに依らないで、いきなりＣ４Ａ５が実行されたという推測が成り立ちます。

むむ。
なんと、まるで非常線の警戒網を見事にくぐりぬけた犯人の残した足跡をたどる探偵の心境そのものですなあ。
はたして犯人はいかにしてこの厳しい警戒をくぐりぬけて目的を達成したのでありましょうや？

現場百遍でありますから、どうしてもＣ４Ａ５に行かざるを得ませんでありましょう。

Ｃ４Ａ５も前回お見せしたこちらのリストにあります。
なんだか前回たどった道を逆に歩いているような気がいたします。



おや、ここは？
前回たどりはじめた最初のポイントです。
Ｃ４Ａ５　２１Ｄ５Ｃ４　ＥＲＲＯＲ２：ＬＤ　ＨＬ，ＢＡＤＳＥＬ
ここは、あのエラーメッセージを表示する、一番コアな部分のルーチンです。
いくらなんでもここを外しては、あのエラーメッセージを表示することは不可能でありましょう。

ま、しかし、ＥＲＲＯＲ２はＨＬレジスタにＢＡＤＳＥＬをセットしてＥＲＲＯＲ５にジャンプしていますから、ＥＲＲＯＲ５にトラップを張っても捕まえることはできるはずです。
ＥＲＲＯＲ５はアドレスＣ４Ｂ４ですから、そこにブレークポイントを仕掛けて、犯人がひっかかるのを待つことにいたしました。

>/ld cpm_1o4.bin,bc00 loading CPM_1O4.BIN ...16e8(5864)bytes loaded,from BC00 to D2E7 >bp c4b4 >jp bc00 a>dir A: FILLE5 COM : ABC COM : CPMTST9 COM : TST012 COM A: TST6 COM : TEST1520 TXT : T1520 COM : T1520-2 TXT a>t1520 t1520-2.txt A F B C D E H L A'F' B'C' D'E' H'L' PC SP IX IY I SZ H PNC F1B3 000F 805C C4D5 0044 8000 0000 800D C4B4 C3A5 0044 F1A1 FF 10110011

おお。
ついに、捕まえました。
今度こそ、エラーが表示される直前に、逮捕です。
理由はまだわかりませんが、今までたぐってきたルートとは別のルートを通って、ここに来ていることはほぼ間違いありません。

ですが、念の為。
今回最後に狙いを定めた、ＥＲＲＯＲ２にトラップを仕掛けて、そこでもひっかかるかどうかを試してみました。
ＥＲＲＯＲ２はアドレスＣ４Ａ５ですから、そこにブレークポイントを設定します。
その結果は。

>bp c4a5 >jp bc00 a>dir A: FILLE5 COM : ABC COM : CPMTST9 COM : TST012 COM A: TST6 COM : TEST1520 TXT : T1520 COM : T1520-2 TXT a>t1520 t1520-2.txt A F B C D E H L A'F' B'C' D'E' H'L' PC SP IX IY I SZ H PNC F1B3 000F 805C C3EF F1B3 000F 805C C4D5 C4A5 C3A5 0044 F1A1 FF 10110011

やっぱり、トラップにひっかかりました。
もう間違いありません。
本来通ることのない、謎の道を通って、このＥＲＲＯＲ２が実行されたことに間違いはありません。

しかし。
そうなると、次なる問題は、一体どこを通って、ＥＲＲＯＲ２が実行されたか？
ということです。

こういうことになりますと、デジタルアナライザでもつかうか、もっと高度なデバッガを使って、最初から自動トレースするしかないのでは？
などとお考えになるかもしれません。

いえいえ。
まだまだ、そんなものは不要であります。
まだギブアップしなくても、捜査の方法は残されておりまする。

犯人は、どこを通って、ここに侵入したのか？
きっとその手がかりは、現場に残されているはずである。

しかり。
その手がかりはここに、残されていたのであります。

A F B C D E H L A'F' B'C' D'E' H'L' PC SP IX IY I SZ H PNC F1B3 000F 805C C3EF F1B3 000F 805C C4D5 C4A5 C3A5 0044 F1A1 FF 10110011

アドレスＣ４Ａ５でブレークしたときに表示されたレジスタダンプです。
これは、ＣＰＵがアドレスＣ４Ａ５の命令を実行する直前のＣＰＵレジスタの内容を表示したものです。
いわばＣＰＵの軌跡の最後の瞬間を捕らえたものだということになります。
ここに、ＣＰＵがどこからやってきたのかが示されているのです。

いったい、どこに、そんなものが？

ＳＰを見てください。
ＳＰはスタックポインタ（Ｓｔａｃｋ　Ｐｏｉｎｔｅｒ）です。
ここにＣＰＵの軌跡があります。
ＳＰの値はＣ３Ａ５になっています。
ここが現在のスタックポインタの最終アドレスです。

スタックはレジスタをＰＵＳＨ命令で保存するときにも使われますが、サブルーチンをＣＡＬＬしたときに、戻り先（つまりＣＡＬＬ命令の次のアドレス）を保存するためにも使われます。
おそらくはＥＲＲＯＲ２がどこかからＣＡＬＬされたに違いない、と考えたとすれば、それならスタックを調べれば、どこからＣＡＬＬされたのかがわかる、はずです。

現在のスタックポインタの値Ｃ３Ａ５近辺のメモリの内容をダンプ表示してみました。

>d.,c390,c3af C390 20 21 F0 C3 B6 C2 09 BE-C3 82 BF 00 00 00 00 96 !.ﾃｶﾂ.ｾﾃ.ｿ..... C3A0 BC 73 BE EF C3 0D C4 08-81 5F C3 00 00 24 24 24 ｼsｾ.ﾃ.ﾄ.._ﾃ..$$$

スタックは若いアドレスに向かって２バイトずつ消費されていきます。
スタックポインタは常に、最後に使われたスタックアドレスを保持しています。
ということで、Ｃ３Ａ５の値を見ますと、０Ｄになっています。
これは下位バイトです。
次のＣ３Ａ６に上位バイトがあります。
Ｃ４です。
もしここがＣＡＬＬ命令の結果使われたのだとすれば、Ｃ４０Ｄは、そのＣＡＬＬ命令の次のアドレスということになります。

果たしてアドレスＣ４０Ｄの前にはＣＡＬＬ命令が書かれているのでありましょうか？
実はアドレスＣ４０Ｄ近くのプログラムは、今回の始めの方でお見せしたリストについています。
しかしいよいよ核心に迫る、肝心のところでありますから、もう一度下にお見せすることに致します。



Ｃ４０Ｄを見ていただきますと…。
こ、ここは…。
命令ではない…！？

Ｃ４０Ｄも、その前もＣＰＵが実行すべき命令ではなくて、ＨＬレジスタに入れるジャンプ先アドレスデータです。
マシン語に詳しくない方はよくおわかりにならないかも知れませんが、ＣＰＵは必ずしも全てのコードを命令として実行するとは限らないのです。
プログラムの流れの中で、ただの文字コードとしか認識しない、ということも有り得ます。
そうでなければＣＰＵが「文字」を扱うことはできませんから。

で。
ここはプログラムとして、つまりＣＰＵが実行する命令としてあるのではなくて、ただのデータ、ジャンプテーブルとして存在しているのです。
すると。
スタックに保存されたＣ４０Ｄは、推理してきたようにＣＡＬＬ命令のリターン先アドレスなどではなくて、このテーブルアドレスがたとえばＨＬレジスタに入れられていたとして、それがＰＵＳＨ　ＨＬ命令でスタックに入れられたものでしかなかったのか？

しかし。
Ｃ４０Ｄをテーブルアドレスとして見ると、そこは
ＲＯＤＩＳＫ：ＤＥＦＷ　ＥＲＲＯＲ３　；ｄｉｓｋ　ｉｓ　ｒｅａｄ　ｏｎｌｙ．
という全く今までに出現したことのないエラーメッセージを表示するためのテーブルアドレスですから、その可能性はかなり少ないと考えられます。

うーん。
ということになりますと…。
やっぱり、ここは、命令として、実行されたのか？

いよいよ謎解きの最終章なのでありますが、本日はここまでといたします。
謎解きのためのヒントといたしまして、ｔ１５２０．ｃｏｍの最初のあたりのリストを以下に示しておくことにいたします。
このリストは［第１５回］でお見せしたものです。

2012/1/16 17:49 T1520.TXT END=814A ; cp/m t1520 ｵｳﾖｳcp/m p.82 ;12/1/16 ; ORG $8100 FCB=$805C FCBCR=$807C DMABF=$8080 DIRPOINT=$8790 BDOS=$C409 ; 8100 0E0F START:LD C,0F;=15 8102 115C80 LD DE,FCB 8105 CD09C4 CALL BDOS 8108 FEFF CP FF 810A CA3181 JP Z,OPNERR

さて。
もともとは正しく動いていたものが、ＣＰ／Ｍの先頭のＪＰ命令がダブっていることに気が付いて、それを削除してしまったところ（その結果それ以降のプログラムアドレスがすべて３バイト前方にシフトしてしまったのでありますが）、突然にＢｄｏｓ　Ｅｒｒが表示されるようになってしまいました。
前回と今回とで、なぜそのようなことが起きてしまったのか（おそらくは先頭の３バイトを削除したことに起因していると思われるのでありますが）、その理由について追求してまいりました。

そして。
お話はついにその核心部分に到達したのであります。
聡明なる読者諸賢におかれましては、すでに事態の全容を把握せられたことと思います。

次回解決編。乞うご期待。

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

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