HC-88サブシステムの制御が奪えない!
ここんところ、どハマりしてた!(T-T)
スレーブCPU(6301)側のシステムを乗っ取って、メインCPU(Z80)とのやりとりを独自プロトコルで動くようにしてしまえ!…と思ってチャレンジしていたのですが、なぜかメインCPUとのやりとりがうまく行かない(T-T)
仕組みとしては、Z80側から「とある通信ポート」に書き込むと、6301側にIRQ割り込みが掛かる単純なもの。そこにはプロトコルも何もなくて、まさに直結!
6301側のIRQ割り込みを独自のモノに書き替えて拾ってみようとやっていたのですが、なぜか2度目以降のIRQが掛からなくなってしまう…。
良くあるパターンとしては、CPUのフラグレジスタ以外にもI/Oポート側に割り込みEnableフラグがあり、そこを読んだり書いたりしてあげないと次の割り込みが発生しない…という仕組み。HC-88でもそういう仕組みがあるのかと思いソースを相当読み込んだのだけど、それらしいポートが見つからない。
もうね…6301側のプログラムを穴が空くほど見た!
おかげで曖昧だったらシーケンス制御のフラグもなんとなく解析出来たw
だめだ…どうやっても制御が奪えない…。デバッガがあるわけではないので、プログラムを実行してみてダメだったら考える…という作業の繰り返し。そもそもメイン側が停止してるのかサブ側が停止してるのかすら知る方法がない。
サブ側は制御が動いてたら画面を変化させる事でなんとなく分かるけど、メイン側は画面もサウンドも担当していないので、動いてるって知るよしがないw
うーん…悔しいけど分からん…やるだけやったし後悔はしないレベルまで来たぞ…。
そう思い始めて「諦めました」ブログを書き始めてたw
突破口
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側へプログラムを送り込む→実行開始
(この時点でサブシステムは乗っ取られている状態)
・そこに通常コールの1文字表示処理が来てしまう
・想定していない手順で動こうとするとのでZ80側が無限ループ
一言で表すのならば「バグ」という…orz
その後も続くよ不具合は
上の問題を修正する事が突破口となり、もう少し先へ進んだ。IRQ割り込みは問題なく届くようになり、6301側は独自ルーチンで動くようになった!
…が、その後も安定せず…。なぜかいきなり停止してしまう症状に悩まされた。
6301側はメモリの内容を(専用のプログラムを組まない限りは)確認する術はなく、何が起きたのかをアタマの中でシミュレーションし、どんな問題が起こりうるのかを探っていく。
なにせシステムそのものを乗っ取っているわけだから、何が起きても不思議はない。暗中模索というか五里霧中というか、手探り感が半端ない!
停止するたびにシステムのプログラムを見ていくので、イヤでも中身に詳しくなるw
HC-88にどんなバージョンがあるのか分からないが、ROMのバージョン違いを考えたら、出来ればROMアドレスに直結のプログラムは組みたくない。RAMに用意されているフックを利用しながらシステムを組んでいる関係上、どうしてもソースは冗長になりがちだ。
ソースを探りつつ、原因を特定していく…。そしたら不思議な現象が出てきた。
clr WorkArea
この1行を削るとうまく行き、追加すると停止(おそらくハングアップ)する。
なんで???こんな簡単な命令でダメになるなんて??
実はここで指定したワークエリアが実際には使われていて、なんらかのタイミングで数値を拾ってハングアップしているのか?clr命令を実行する時の注意があるのか??
もうね、散々っぱら調べたw 使ったことのないシステムの、使ったことの無いCPUの命令だ、不具合が出る可能性は無限大にある。
そして分かった驚愕の事実(TOT)
アセンブラのバグだった!!!
そう、私が自作したアセンブラが原因だったのだw もう、ふつーに使ってて自作した事すら意識が薄くなっていたんだけど、ここに来て久々の巨大バグヒット!
「clr ワークエリア」はエクステンドアドレッシングの3バイト命令に変換されるべきところを、なぜか4バイト命令だと勘違いしてコードを出力しようとしていた。結果、4バイト目は出力されずに汚れた1バイトとなり、それがたまたま未定義コードだったために、6301の未定義命令トラップ($FFEE)へ飛びハマってしまっていた…というのが真相だった。
たかが1バイト、されど1バイト、である(T-T)
ようやくメドが立ってきた!
よーやくZ80→6301の高速ハンドシェイクが実現出来そうな目処が立ってきた!実際の性能評価とサンプルプログラムはこれからとなるが、なんとなく良い結果が出そうな手応えは感じている。
また次回以降に楽しいご報告が出来るかと思う!
ところで…今回、HC-88での開発をヘビーに行ってみたけれども、いくつかの注意点と利点が分かってきた!
RAMドライブはマジ便利!
開発していると、何度もハングアップしてはリセットを繰り返す事になるけれども、HC-88についている拡張ボックスにあるRAMドライブはホントに便利!リセット→BASIC起動→RUN"RSで転送プログラムの実行、そしてバイナリを送り込んでテスト!
※RS.BASの拡張子は省略が出来る。
滅多な事ではRAMドライブが消えたりしない(一度も消えたことがない)ので、安心してハングアップさせられますw
RAMドライブの整備、そしてバイナリファイルの転送プログラムは作って良かったとマジマジ思う(^^)
HC-88にメモリを増設する! - レトロパソコンであそぼう!
HC-88でプログラミング! その2 - レトロパソコンであそぼう!
ハングアップ時のテープ対応
サブシステム(6301)がハングアップした際、ふいにテープが動くことがある。ロックがかかったり巻き戻しされたり、ヘタに上書きされてないかと「ぎゃーっ」てなる事も何度かあったw これはメモリにあるI/Oを勝手にアクセスしてしまうと起こる。
#その前にテープを外しておけよ…って突っ込み大歓迎w
テープドライブが動いてしまった場合は、たいていドライブにロックがかかってしまう。無理にテープを取り外したりすると、今度は逆に取り付けが出来なくなってしまう。
こういう時は落ち着いて、BASICで「mount」→「remove」をしてやる。そうすると正常な状態に戻ってくれるのだ。おそらくHC-40でも同等な事が起こるだろう。
さぁ、苦しい時間が続いたあとは、楽しいプログラミングをしたいね!
頑張るよ(^-^)/
ではまた次回!(^-^)ノ