HC-88でプログラミング！　その１２ - レトロパソコンであそぼう！

HC-88サブシステムの制御が奪えない！

f:id:PocketGriffon:20201108160717j:plain

ここんところ、どハマりしてた！(T-T)

スレーブCPU(6301)側のシステムを乗っ取って、メインCPU(Z80)とのやりとりを独自プロトコルで動くようにしてしまえ！…と思ってチャレンジしていたのですが、なぜかメインCPUとのやりとりがうまく行かない(T-T)

仕組みとしては、Z80側から「とある通信ポート」に書き込むと、6301側にIRQ割り込みが掛かる単純なもの。そこにはプロトコルも何もなくて、まさに直結！

6301側のIRQ割り込みを独自のモノに書き替えて拾ってみようとやっていたのですが、なぜか２度目以降のIRQが掛からなくなってしまう…。

良くあるパターンとしては、CPUのフラグレジスタ以外にもI/Oポート側に割り込みEnableフラグがあり、そこを読んだり書いたりしてあげないと次の割り込みが発生しない…という仕組み。HC-88でもそういう仕組みがあるのかと思いソースを相当読み込んだのだけど、それらしいポートが見つからない。

もうね…6301側のプログラムを穴が空くほど見た！

おかげで曖昧だったらシーケンス制御のフラグもなんとなく解析出来たｗ

f:id:PocketGriffon:20201108223051j:plain

だめだ…どうやっても制御が奪えない…。デバッガがあるわけではないので、プログラムを実行してみてダメだったら考える…という作業の繰り返し。そもそもメイン側が停止してるのかサブ側が停止してるのかすら知る方法がない。

サブ側は制御が動いてたら画面を変化させる事でなんとなく分かるけど、メイン側は画面もサウンドも担当していないので、動いてるって知るよしがないｗ

うーん…悔しいけど分からん…やるだけやったし後悔はしないレベルまで来たぞ…。

そう思い始めて「諦めました」ブログを書き始めてたｗ

突破口

HC-88のサブシステム(6301)側は、ワリと常に割り込みを受け付けていて、CPU命令のSLP(スリープ)で停止をしていても、すぐに起きてしまう。定期的に掛かっているので、おそらくタイマー割り込みだろう。

プログラムのシーケンスは奪っても割り込みは(IRQ以外は)そのままにしてある。一気に全部やるのは無理だし、特に止めなくても良いサービスもあるからだ。

ただ、通常のシーケンスを奪ってるということは、Z80側からの通常のSLAVEコールなどは受け付ける事は出来ず、入ってきたらまず間違いなくデッドロックとなる。

でもそこは自分でコード書いてるから、さすがにそんなプログラムは書いてない。

テストでやっていたことは、キー入力を受け付けて、押されたキー情報を6301側にデータとして送りつける…そんな単純なプログラムだ。そこにSLAVEコールが入る余地が無い。

　　　　ld c,#1
　　　　call BDOS

キー入力を待ち、答えがAレジスタに戻ってくるCP/MのBDOSコールだ。

……あれ？

なんか嫌な予感が…。#1ってエコーバックしなかったっけ？？記憶が曖昧！！

手元にあるCP/Mの書籍を見ても、詳細が書かれてるモノとそうでないモノがあって、何を信用したら良いの？！

仕方ないので、ぱぱっとテストプログラムを組んで試してみると……エコーバックした！！

これだ！！(TOT)

つまりこういう事だ。

・Z80側のプログラム開始

・6301側へプログラムを送り込む→実行開始

　(この時点でサブシステムは乗っ取られている状態)

・そこに通常コールの１文字表示処理が来てしまう

・想定していない手順で動こうとするとのでZ80側が無限ループ

一言で表すのならば「バグ」という…orz

その後も続くよ不具合は

上の問題を修正する事が突破口となり、もう少し先へ進んだ。IRQ割り込みは問題なく届くようになり、6301側は独自ルーチンで動くようになった！

…が、その後も安定せず…。なぜかいきなり停止してしまう症状に悩まされた。

6301側はメモリの内容を(専用のプログラムを組まない限りは)確認する術はなく、何が起きたのかをアタマの中でシミュレーションし、どんな問題が起こりうるのかを探っていく。

なにせシステムそのものを乗っ取っているわけだから、何が起きても不思議はない。暗中模索というか五里霧中というか、手探り感が半端ない！

停止するたびにシステムのプログラムを見ていくので、イヤでも中身に詳しくなるｗ

HC-88にどんなバージョンがあるのか分からないが、ROMのバージョン違いを考えたら、出来ればROMアドレスに直結のプログラムは組みたくない。RAMに用意されているフックを利用しながらシステムを組んでいる関係上、どうしてもソースは冗長になりがちだ。

ソースを探りつつ、原因を特定していく…。そしたら不思議な現象が出てきた。

　　　　clr WorkArea

この１行を削るとうまく行き、追加すると停止(おそらくハングアップ)する。

なんで？？？こんな簡単な命令でダメになるなんて？？

実はここで指定したワークエリアが実際には使われていて、なんらかのタイミングで数値を拾ってハングアップしているのか？clr命令を実行する時の注意があるのか？？

もうね、散々っぱら調べたｗ　使ったことのないシステムの、使ったことの無いCPUの命令だ、不具合が出る可能性は無限大にある。

そして分かった驚愕の事実(TOT)

アセンブラのバグだった！！！

そう、私が自作したアセンブラが原因だったのだｗ　もう、ふつーに使ってて自作した事すら意識が薄くなっていたんだけど、ここに来て久々の巨大バグヒット！

「clr ワークエリア」はエクステンドアドレッシングの３バイト命令に変換されるべきところを、なぜか４バイト命令だと勘違いしてコードを出力しようとしていた。結果、４バイト目は出力されずに汚れた１バイトとなり、それがたまたま未定義コードだったために、6301の未定義命令トラップ($FFEE)へ飛びハマってしまっていた…というのが真相だった。

たかが１バイト、されど１バイト、である(T-T)