ドライブ番号4～6からの起動

『ドライブ番号=SCSI ID』としているので、理論上はドライブ番号0～3だけでなく4～6からも起動できるのですが、X1turboのIPLがそれを許さない。なので、制限している部分を書き換え。

書き換えたBIOSで起動し、ドライブ番号6を選択してのBASICを起動…

BASICの起動画面が表示されたものの、直後に"Bad file descpriter"エラーで停止。

あー、そうか。

ディスク上にあるBASICではドライブ番号の最大値を変更していないのに"HD6:Start up.Bas"を読み出そうとしてエラーになっている。

標準ではないブート手法は無用な混乱を避けるために、控えた方が良さそうだ。

ドライブ番号が0～3の理由って

せっかくのSCSIも、X1turbo（正確にはHuBAISCやturbo CP/M）では0～3の4台しか使用できない。この制限は、FDDが4台まで接続出来るので、これに合わせたのかな？ではなぜ、EMMは0～9なのか…なんで？そんなに拡張スロットないでしょ。

SASIを解析をしたとき、マシン語処理部"DISK UTILTY.Obj"では、わざわざ8台分のHDDに対応した作りになっており、将来的には0～7になっていたかも？

FDDはドライブ側の仕様も関係しているため4台までですが、SCSIならば最大7台までの接続が可能なわけで、この制限突破を試みる。

手始めにFILES"HD4:"を実行すると"Bad file descripter"になるところから、このエラーにジャンプしている部分を検索。すると、ドライブ数を格納しているテーブルらしき領域を発見。EMMであれば0～9の最大10ドライブ、 MEMなら0～1の2ドライブと、X1turboならではの「それっぽい値」が並んでる。

しかし、ドライブ番号が0～3なのはHDDだけではなく、5（or3）インチFDD、サポートされず仕舞いの8インチFDDもあるため、どれがHDDに該当するのか…全部書きかえて試せば分かる事が、テーブル値の並びを見てBIOSワークのFDCNOと同じではないかと推測。

HDDに相当する部分を書き換え、FILES"HD6:"を実行するとID6にしてあるMOドライブをアクセスする事に成功。

turbo CP/Mについては、HDD用のワークが4台分しか存在せず、そもそものドライブレターがA～Hの8台分なので、最大接続数の変更は面倒なうえにメリットがないような…ので割愛っと

光磁気ディスクへの対応

今やすっかり過去のデバイスとなったMOこと光磁気ディスク。

電源投入直後から読み出せるハードディスクと異なり、MOドライブでは電源投入直後に読み出しても読み出せません。そもそも電源投入直後に接続デバイスのチェックもせず、いきなり読み出す使い方がダメなんだけど、X1turboの場合はドライバを仕込むROM容量が厳しいわけで…

で、本題。

MOドライブは電源投入直後(メディア交換直後)にはユニットアテンション状態になっていて、このときに読み出しコマンドを実行してもチェックコンディションのステータスを返し、イニシエーター側にそれなりの対応を促してきます。

そこで、この状態から抜け出すための処理を追加するだけの簡単なというか、手抜きな対応。

チェックコンディションをクリアするためだけにリクエストセンスを実行し、戻ってくる情報は読み捨て(ヒドいｗ)。あとはROM容量との相談でしたが、実装してみると空き容量を数バイト残してなんとか対応。

変換番長からブートして、MOドライブに230MBのメディアを挿入してみると、無事にメディアを認識。フォーマット、SYSGENで起動ディスクの作成も正常終了し、MOからのブートも可能です。もちろん、メディアを交換しても大丈夫。

このMOドライブは640MB対応なので、2048バイト/セクタの640MBメディアはどうか…
640MBのメディアを挿入し、フォーマット…問題無しかな（以下略

1セクタ512バイトの世界

512バイト/セクタが使えれば、大抵のSCSIディスクが使えるわけで、昔はよく見かけた512バイト/セクタのCD-ROMドライブも使えるようになり、夢がひろがりんぐ…

しかし、512バイト/セクタを使うには512バイト分のバッファが不可欠で、そんな広大な空き領域があるわけもなく、これはもうHuBASICの構造自体を換えないとダメなわけで、不可能なんじゃないか…

そんなふうに考えていた時期が俺にもありました（ＡＡ略

ちょっと考えを変える。

BIOSの処理を1セクタ毎になるように分割して、読み出しでは後半256バイトを読み捨て、書き込みでは後半の256バイトに詰め物を…

詰め物を英語でPaddingなわけで、どこかで見た・・・

もしや、MB89352のPadding転送ってのが使えるのかも？

Transferコマンド実行中に、トランスファカウンタが0になってもSCSIバス側で転送要求が有ればダミーで転送を継続してくれるという、正直言って本来は何に使うのが正しいのかよくわからない転送モード。『転送の完了はマンドコンプリートでなく、フェーズ遷移で見てね！』という妙な仕様ですが、プログラム的にはチェックするレジスタが変わるだけで済む。

ということで、ちょいちょい仕込んで、1セクタ毎に処理するようになったためループ処理が増えたけど、まだ容量に若干の余裕。

変換番長のディップスイッチを256バイト/セクタから512バイト/セクタへ戻し、X68030で使っているCFを挿して DEVI$ したところ、ハングアップしたりバグったりせず正常に読めているようだ。次々と読出しを続けると、各セクタとも前半の256バイトだけ読み出されている。しかし、これは1セクタ毎に読み出しているから、たまたま正常に見えている可能性が否定できない。

書き込みをテストするのも面倒なので、フォーマットを実行。続いてマッピング、SYSGENして、IPLリセット…

なんだ、普通に起動するし。意外と簡単だった。

これならMOドライブも…しかし、手抜きの限りを尽くしているためダメでは？

はい、やっぱりダメでした。が、どうすれば良いのか分かっているので、その対応。

ベンチマークのおまけ

前回のベンチマーク結果。この時の設定条件を書き忘れていた。

　基本的にX1turboにおいて、Z80 DMAでディスクをアクセスする際の転送モードは、なぜかバイトモードという最も低速な転送モードを用いている。今回のベンチマークでは、無難で高速なバーストモードで行なってます。


そして、おまけという本題、いちおうデフォルトであるバイトモードの結果も必要だろう、と。

『１バイト転送毎にバス制御権を返してると、どのくらい遅くなるのか。』とか、『純正HDDとの比較』や『変換番長を純正HDD I/Fで使用したときと比較』など、考えてみたらこっちの方がネタとしては面白いかも。

結果は、バーストモードの19秒(538.95KB/秒)が、バイトモードでは40秒(256.00KB/秒)となった。１バイト転送毎にCPUが1マシンサイクル動くから7割程度になんのかなーと考えていたが、結果は半分以下の速度だった。バス制御権の行ったり来たりオーバーヘッドだろか。

まぁ、半分以下の速度っても64KBしかないメモリを埋めるには十分すぎる。


もう一つのおまけ、DMAIOFを書き換えてGRAMへの直接転送のベンチマーク。

バーストモード431.16KB/秒、バイトモード219.43KB/秒。ノーウェイトのメインメモリと比べて8割程度の速度で、CRTC側からのウェイトで1バイトの転送にほぼ9クロックかかっているようだ。これらはハイレゾモードでの値で15KHzでは若干異なりますが、割愛します。

いちおうベンチマーク

どんくらいの転送速度が出てんのか、やっぱり気になる。

　SCSI BIOSを使用して、標準的なHDDの最大容量である10MB分の読み出しを行なって計測したいのだけど、一度には無理なので、20KBの読み出しを512回行う事で10MBとする。

いまさらだが、基本仕様を押さえよう。X1turboは4MHzのZ80システムなので、

I/Oリードサイクルは4クロックの1000ns
メモリライトは3クロックの750ns
DMAを使用して1バイト転送は、所要7クロックで1750ns

単純に10MB分(10,485,760回)繰り返すと約18.35秒(約558.0KB/秒)、これが理論的速度となるわけだが、実際にはDMAへのパラメータ設定、SCSIコマンド処理、BIOS呼出し、BASICでの処理等々の、オーバーヘッド盛り沢山(しかも、512回も繰り返す)なので、理論的な値よりもグッと遅くなることは確実だが、果たしてどこまで理論値に近付けるか…

　SCSIターゲットは、おなじみ変換番長。プログラム構成ですが、転送処理のみマシン語で、時間の処理は楽をしてBASICのTIME関数を用います。なので、結果には＋1秒未満の誤差が出ます。

そしてベンチマーク。

20KB毎に表示を行っていたら21秒で、表示無しで19秒(538.95KB/秒)。512回ものオーバーヘッド要素を考えれば、いい数字ではないだろうか。

さらに試行回数を増やし、もうちょっと計測してみる。

16倍の160MBならば、何秒なのか。19×16＝304秒？

実際には306秒でした。ということは、10MBの19秒は19.125秒くらいなのだろう。

基板の写真など

動作確認後の記念撮影

部品面

600mil幅のもん(MB89352)を何も考えずに載せてしまったために裏側配線になってしまった…

ハンダ面

ハンダ面のみで配線を行ったため、配線に厚み出てしまい拡張スロットへの出し入れで引っ掛かりまくる事態。

あと、この基板ってただの両面基板（非スルーホール）だからカードエッジの所からもってくる配線がやりにくいんだよね…

CZ-8FB02でSCSI

各SCSIファンクションのデバッグが終わったので、FDCRED と FDCWRT を使用するBASIC命令のデバッグに移ります。手始めに、デバイスを直接読み書きする、DEVO$ と DEVI$ を試したところ、これもあっさり正常動作。

本当に動いているのか？

ということで、以前の解析結果から"HD FORMAT.Uty"でマシン語を読んでいる部分を削除して実行。エラーも無く終了し、"HD MAP.Uty"で全領域をBASICに指定し領域確保。とりあえず正常終了。

FILES"HD0:"を実行すると、それっぽい表示…これで正しいのか？

兎に角、実機というかSASI環境が無いので、本来の動作結果を知りません(笑

"DISK SYSGEN.Uty"で"HD0:"へBASICを転送し、他のファイルも COPYコマンドで転送。

IPLリセットを行い、ドライブ番号の"0"押して、HDDを指定する"7"押して…一瞬、アクセスランプが点灯し、80ｘ25に切り替わり、CZ-8FB02の起動画面。

どうやら完成。

しかし、このテストで接続している変換番長はX68030で使用している物だし、X1turboで使いたい時にはケース開けてCFを交換してディップスイッチを切り替えて、ケース閉めて面倒臭い、不便すぎる。

SCSIディスクで一般的な512バイト/セクタのもんがX1turboでも使えたらいいよね！

ということで。

BIOSの開発

SCSIのBIOSは、元からあるSASI HDD処理の領域に納めることを目指します。なので、SASIとは共存できません（させる気も無い

HDINIT（78D9H） と HDOFFS（78E2H） はROM以外からの呼出しの可能性があるのでエントリアドレスが移動してしまわないように注意し、RAM上に展開される HDDMAS（ROM:7EC5H RAM:F929H）も領域をオーバーしないサイズに納めなくてはなりません。

以前、とある機種用にMB89352用ドライバを作った時のモジュール構成に似せたり、ラベル名はX68000のIOCSからのパクったりで、BASICから利用し易くデバッグし易い構造に。

HDINIT…S_INITを呼ぶだけ
HDOFFS…今回は何もしない
S_READ…FDCRED SCSI用
S_WRITE…FDCWRT SCSI用
S_BUSRST…SCSIバスリセット
S_INIT…MB89352の初期化
S_SELECT…指定IDのセレクション
S_CMDOUT…コマンド送信
S_DATAIN…データイン
S_DATAOUT…データアウト
S_MSGIN…メッセージイン
S_STSIN…ステータスイン

ざっと、ひと通り作ってみると、やっぱり容量オーバー。デバッグしてからコード圧縮した方が良いので、今後とも使わなそうな HCOPY処理を潰し、とりあえずBIOS内に納めました。ついでに、コード圧縮しても入らなかった時のために（個人的に）不要な処理を潰しました。

BASICから呼び出しでデバッグをはじめてみると、MB89352の初期化の呼出し忘れがあったくらいで、意外とすんなり動作。デバッグ用のコードを外し、コード圧縮してみると意外と小さくなって納まってしまい、これといってハマる所も無く終わってしまうい…

物語的には、盛り上がりに欠ける展開。