SHARP PC-1600KでCP/M80!その4

f:id:PocketGriffon:20210502105404j:plain

PC-1600Kの狭い画面で開発続けるの大変だなぁ…と思っていたところ、Twitterで「シリアルに出してみたら」という感じのご意見を頂いた!なるほど、ぜーんぜん気づいてませんでしたw これだけブログ内でV20-MBCとか触ってるっていうのに…汗

 

さて今回は、ディスク周りをどのようにしているのかを解説していきたい!

 

ディスク周りの設定など

CP/M80におけるディスクについては、BIOSの設定パラメータの中に「ディスク・パラメータ・ブロック(略してDPB)」というデータが存在する。ここで細かいことを説明する事はしないけれども、詳しく知りたい場合はCP/M80の解説本を読んでみてほしい。本によって説明が異なったりするので、何冊か読んでみる事をオススメする。

 

CP/M80内部ではデータを128バイトひとまとめとして扱っている。ここではこれをセクタと呼んでおく。

DPBではこのセクタが何個あって、どこがどのように使われるのかが記されている。

DPBの書き方によってディスクのサイズが変わったり、アクセス方法が変わったりする。なので、DPBは厳格に定義せねばならない。CP/M80の移植で難しいところはココかも?

f:id:PocketGriffon:20210502113139j:plain

↑難しい事を簡単に書かれている辺りが初心者キラーっぽい(T-T)この図ではDPBLKと書かれているが、本に掲載されているソースではDPBと書かれている

DPBは「どんな感じの機材が繋がっているのか」をCP/M80本体(主にBDOS)に教える定義だが、その機材へアクセスをするのは(自分がこれから書く)BIOSの方だ。極端な事を言えば、ディスクとしてアクセスされたものが、実際のディスクだろうとメモリだろうとシリアルだろうと関係ない。そこはBIOSが吸収してやればいいのだ。

そして今回のPC-1600K CP/M80では、増設メモリをディスクと見立ててアクセスをする。

 

PC-1600Kの増設メモリは以下のようになっている。

f:id:PocketGriffon:20210502114123j:plain

1MB増設メモリはスロット2に取り付けられているので、アドレス8000h〜BFFFhのバンク2と3に見えている。この2つのバンクで32KB分。残りの992KB(1024KB-32KB)分のメモリは縦バンク(図ではVerticalBank)としてバンクを切り替えていけばアクセスが出来る。

以降、図に書かれている横方向に伸びるバンクをHBANK、縦に伸びていくバンクをVBANKと呼ぶ。

 

VBANK0(のHBANK2と3)はメインメモリとして0000h〜7FFFhに顔を出しているのでディスクとしては使えない。

VBANK1(のHBANK2と3の合計32KB)は今後の拡張用として残しておこうと考えている(80x24表示用のバッファとか小さいフォントデータ格納用とか)。

RAMディスクとしてはVBANK2以降を使うこととした。これはDPBに書くことではなく、BIOS側が吸収する。

 

1つのメモリブロックは16KBのサイズがある。1セクタ128バイトなので1トラック=128セクタと管理したら、とても簡単な計算で実アドレスを求められる事となる。

本CP/M80では、Aドライブとして448KB(512-64KB)、Bドライブとして512KB用意した。わざわざドライブを分けたのは、512KBメモリモジュールを持っている人でも使えるようにしたかったためだ。

 

RAMディスクアクセスの問題

ここでひとつドハマリしたバグがあったのでご紹介したい(^-^;

 

CP/M80では、ディスクから128バイトを読み込むバッファ(DMAバッファ)がある。 このバッファ、通常はメインメモリの0080hからの128バイトとなっている。

このPC-1600K CP/M80システムでは、ディスクはメモリモジュールとなっているから、ディスクからデータを読む イコール メモリからメモリへのコピーとなる。正しいメモリバンクを設定しておいてZ80よろしくLDIRすれば安直にコピーが出来る……と思い込んでいた!

 

実際にそのようなコードを組んでみたところ、セーブしたファイルを実行しようとすると、どうにも不安定になる場合がある。この「場合がある」というのが厄介だ。なぜ不安定になるのかがさっぱり見当付かなかった。例えばAというコマンドを実行しようとすると不安定になる、ディスクをフォーマットして書き込んでいくうちに、今度はBのコマンドが不安定になる…という感じで法則性が読めない症状だ。

 

この手の不安定要素は早急に対応しなければ、作業を先に進める事が困難になる。ほぼ半日悩んでようやく原因らしきものを突き止めた。残念ながらこの期に及んでも推測の域は出ていない(TT) 

 

上にも書いた通り、DMAバッファがあるのはメインメモリの0080hだ。ここは64KBフルRAMモードではHBANK1だが、実際にはHBANK3のVBANK0が見えている。

この状態で、ディスクをアクセスしようとしてVBANKを切り替えた瞬間、どうやらメインメモリの0000h〜3FFFhも一緒に切り替わってしまうようなのだ(おそらく4000h〜7FFFhも同様)。メインメモリの0080hへデータをコピーをしたつもりが、別のVBANKに切り替わっていてディスクの情報を破壊する…というのが不安定になる原因だったようだ。

考えてみれば「そりゃそうだ」と思うのだが、メモリマップだけを見ているとコレがなかなか気がつけない(T-T)

 

 仕方ないので、バンク切り替えには影響されないC000h以降に中間バッファを設け、そこを介してディスクとのやりとりをするように構造を変更した。転送時間は2倍掛かる事となったが、これ以降はすこぶる安定して動作するようになったので、まぁヨシとしよう(^^;;

 

現状のPC-1600K CP/M80

一旦、今の状態をまとめておきたい。

まだまだ実装できていない事が多くて、安定動作には程遠い状態だ。

 

まずキー入力がまともではない。SHIFT+なんとかのオペレーションが出来ていないので、ダブルクオートとか「;」などが入力出来ない状況だ。BSも機能しないため、非常に面倒。

 

WBOOTを実装していないため、MBASICでSYSTEMしてもCP/M80に戻れない(^^; いつもリセットしているのだ!面倒すぎるww これはトラック0セクター1にCCP+BDOSを書き込んでやれば良いのだが、システムが安定していないのでまだ先にしたいという想いから。

 

CP/M80自体を抜けて、素のPC-1600Kへ戻る事が出来ない。これも実装しなければならないことがいくつかあるようで、その調査が進んでいない。

 

多分、キー入力とWBOOTを実装すればある程度CP/Mとして「動いた」と見てよいのかも知れないが、そこへ到達するまでにはもう少し時間がかかりそうだ。

 

次回はディスク関連その2を書こうと思う。ディスク周りは面倒が多い(T-T)

ではまた次回!(^-^)ノ