ドライブ番号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の初期化の呼出し忘れがあったくらいで、意外とすんなり動作。デバッグ用のコードを外し、コード圧縮してみると意外と小さくなって納まってしまい、これといってハマる所も無く終わってしまうい…

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

オールBASICでSCSI

FDDのようなシビアなタイミング等は皆無で、BASICのみで制御が可能です。のんびりと処理をやっても、全てMB89352が対応してくれます。

HuBASICでSCSI制御をしたときのプログラムの一部です。

まず、セレクション。
変数TARGETに、セレクションしたいデバイスのIDを設定します。

1440 OUT PCTL,&H0               'START Selection Phase
1450 WAIT SSTS,&B11110000,&B11111111
1460 OUT SCTL,(INP(SCTL) OR &B10000)    'Arbitration Enable
1470 OUT TEMP,(INP(BDID) OR 2^TARGET)
1480 OUT TCH,&HF
1490 OUT TCM,&H46
1500 OUT TCL,&H4
1510 OUT INRS,INP(INRS)
1520 OUT SCMD,&B100000          'Command Code = Select
1530 WAIT INRS,&B10100
1540 R=INP(INRS):OUT INRS,INP(INRS)
1550 IF R<>&B10000 THEN PRINT"Selection Error[";BIN$(R);"]":GOTO"ERR"

"INRS"はMB89352のINTSです。BASICの予約語とぶつかり"INTS"に出来ないため。

バス制御は全てMB89352がやってくれるので、BASICではその結果を見ているだけです。


データイン動作は、変数TLENに転送バイト数、変数MBASEに読み込むメモリのアドレスを入れます。

1810 OUT TCH,0
1820 OUT TCM,(TLEN AND &HFF00)\&H100
1830 OUT TCL,TLEN AND &HFF
1840 WAIT PSNS,&B10000000       'REQ待ち
1850 IF (INP(PSNS) AND &B111)<>&B1 THEN PRINT"Data In Phase Error":GOTO"ERR"
1860 OUT PCTL,&B1               'Set Data In Phase
1870 OUT INRS,INP(INRS)
1880 OUT SCMD,&B10000100        'Command Code = Transfer
1890 WHILE (INP(SSTS) AND &B11110000)<>&B10110000
1900 WEND
1910 FOR X=1 TO TLEN
1920   WAIT SSTS,&B1,&B1
1930   POKE MBASE+X-1,INP(DREG)
1940 NEXT
1950 WAIT INRS,&HFF
1960 R=INP(INRS):OUT INRS,INP(INRS)
1970 IF R<>&B10000 THEN PRINT"Data In Error[";BIN$(r);"]":GOTO"ERR"

SSTSを見て、FIFOバッファが空でなければDREGからデータを受け取ります。 この1バイト受け取るために、SSTSを監視する方法は非常に遅く、『まずい！ぶっ壊れたか？』と思わせるくらいのインパクトがあります。

高速化したい場合には、SSTSのバッファフルを見て8バイト毎転送するようにすると良いです…とは言うものの、BASICでの高速化は意味がありません…素直にマシン語かDMAで。

動作確認

配線が正しければ、余程の事が無い限り動作するはずです。

ここでいう余程の事とは、

• MB89352が壊れている
• X1turboの拡張スロットが壊れている

です。

動作の確認で起動するBASICは、I/Oポートを操作するだけなのでCZ-8FB02である必要もなく、DMAを使用しないBASICの方がある意味安心なので、CZ-8FB01を用います。

X1turboの電源を入れ、IPL画面が出たらMB89352とPLDを触って発熱していない…たぶん大丈夫

まず、BDID を設定。BDID は書き込んだ値（0～7の範囲）が、読み出し時にはビット位置となって反映されるため、MB89352の動作をみるには都合が良いいぞ。

OUT &HF70,0:PRINT INP(&HF70)

この時、BDIDのビット0がセットされるため、正常であれば「1」が表示されます。

OUT &HF70,5:PRINT INP(&HF70)

同様に、BDIDのビット5がセットされるため、正常であれば「32」が表示されます。

ここまで正常ならば、MB89352へのアクセスは問題無し。


次に、SCSIバスの方を確認。

SCSIバスの制御線状態はPSNSに反映されるので、このレジスタを連続して読み出すプログラムを走らせ、I/O や MSG 等を GNDと直結してみてレジスタ値の変化で確認。データバスはチェック方法が思いつかなかったので未確認。制御線は読めているし、後は何かSCSI機器を接続してみることに。

製作開始から完了まで

とくに難所はありませんが、意外と部品配置が最大の難所です。

配線が終われば配線チェックをしますが、大したことはしません。

『回路図通りか？』

これをやるだけです。電源のショートにだけは、十分に注意。

極力、配線量を減らした構成なので、意外と早く終わってしまいますね。

製作前にする事

X1用ユニバーサル基板MCC-153に実装しますが、この基板には大きな問題点があります。

この基板を持っている人ならば、誰もが感じたことがあるのではないでしょうか。

なんで力一杯押し込まないと拡張スロットに入らないんだろう？

それは、カードエッジが本体後方から見て左側に2mm程ずれて作られているためです。この基板を力任せに押し込んでしまった場合、ガイドレールが歪みコネクタには異常な力が加わり、短時間では破損に至らないまでも、極めて危険な状態です。

ということなので、拡張スロットを壊さないためにも基板の修正を行います。修正と言ってもカードエッジ部をずらす事は不可能なので、ずれている分だけ基板の外周を削ります。

削る側は『1 5 10 15 20 25 30 35 40』とハンダ面にあります。この『10 15 20 25 30 35 40』の一の位が半分無くなる程度まで削ります。削り過ぎると拡張スロットに挿入した際ガイドレールから脱落してしまうので、様子を見ながら削ります。

それと、この基板の謎として、カードエッジそばの表示があります。部品面には23～44、ハンダ面には1～22という表示があるのですが、X1の拡張スロットのピン番号と全く関係がありません。しかも、1～22の並びは、X1の拡張スロットのピン番号とは正反対という罠の様な事になっています。一体、何のための番号なのでしょう。兎に角、謎の多い基板です。

回路設計・その４

ということでGAL16V8を用いるとTTL ICはすべてなくなり、次の回路となります。

最終的な部品は次の通りです。

• X1用ユニバーサル基板MCC-153
• MB89352
• GAL16V8（互換品可）
• 8MHzのオシレータ（TTL出力で5～8MHzならなんでも）
• ICソケット（今回、唯一の新規購入品が48ピンソケット）
• SCSIの終端抵抗（X68030から取り外した物）
• ショットキーバリアダイオードと、ヒューズ(ポリスイッチ)的な部品
• 基板用D-Sub25ピン・レセプタクル
• 220μF（100μFでもいい。気分の問題ですが、電源用が良いね)
• 100μF（こいつも気分の問題。極端な話、無くても良い）
• 0.1μF（適量）

以上です。

回路圧縮

別の部品ケースにEPROMなんかと一緒に別の場所に保管してあったPLDを完全に見落としていました。これを用いれば、今回の様な簡単な回路は１チップで済む可能性があります。

ということで、信号をリストアップ。

入力

1. AB11
2. AB10
3. AB9
4. AB8
5. AB7
6. AB6
7. AB5
8. AB4
9. EXIO
10. IORQ
11. BUSAK
12. RESET
13. MB89352 からの DREQ

出力

1. MB89352 への CS
2. MB89352 への RESET
3. MB89352 への DACK
4. EXRDY

と、これならばPLDのGAL16V8で余裕では…

回路設計・その３

ぐぬぬ、LS30は買わないと無いぞ。

楽な配線ばかり考えていてはダメで、手持ち部品を活用する事も考えます。

LS138なら複数個のあるので…とはいえ、ちょっと変態的。アドレスデコードに部品点数が増えてしまいましたが、手持ち部品を用いてローコストも方針のひとつなわけで。

しかし、手持ち部品をちゃんと調べたために…

回路設計・その２

回路設計をしたものの、LS688(またはLS521)は持ってないし今となっては高価な部品だ。でもHCT688ならそんなに高価でもないみたい。実体配線を考えたらLS688周辺が意外と手間だね。そもそも『アドレスを変更できる必要があんの？』という疑問…ROM化するのであればアドレスは固定で良いよね。

ということで、回路設計をやり直し基本方針通り、楽な配線＆ローコストを目指します。

I/Oアドレスについては、0100H～0FFFHはシャープが予約しているワケですが、新規に純正拡張ボードが出てくることもないので、デコード回路を楽に配線が出来る0F7XHにしました。

回路設計

回路は次の通りです。

ごく普通にMB89352を接続しただけですが、ご覧の通り以下の手抜きをしています。

●EXRDY処理
→他スロットに、同様の手抜きをしている拡張ボードがあると非常に危険です。

●データバス処理
→バストランシーバの類を入れてません。MB89352のファンアウトが足りているのか謎ですが、ダメだったら後から付ける方針で。

 SCSIコネクタには、Macintoshやサンプラーと同じD-Sub25ピンを用います。よくあるSCSIコネクタの50ピンは大きすぎて入らないし、ハーフピッチのは入手性が悪いので。ジャンク基板からハーフピッチコネクタを取り外す方法も考えられますが、やってみたところ案の定グラウンドがそう簡単には外れず、しかも半分近くグラウンドなわけで…

SASI HDD処理の解析

まず、BIOSについて。

当時の各種解析本によれば、

• FDCRED…読み出し
• FDCWRT…書き込み
• FDCVFY…ベリファイ
• HDINIT…HDD初期化
• HDOFFS…ハードディスクのOFF(HDOFFコマンド？)

以上が、SASI HDDに関する処理。

解析したところ、HDINIT と HDOFFS はSCSIにおいては特に何もしなくて良さそう。FDCVFY はいきなり RET 命令なので、当然何もしなくて良い。これ以外に呼び出されている部分が無いか検索しましたが、BIOS 部分では見つけられず。

あと BIOS から RAM上に展開される処理があって、これにも対応が必要です。なぜ RAM上に処理が必要なのかというと…いまさら説明するまでもないので割愛。

BIOS から RAM上に展開される処理は、

• HDDMAS

で、こいつもSCSI対応が必要です。

次に、アプリケーションまわり（BASICやturbo CP/M）について。

• "HD FORMAT    .Uty"
• "HD MAP       .Uty"
• "DISK SYSGEN  .Uty"
• "DISK UTILITY .Obj" 
• HDOFF.COM(turbo CP/M)
• HDMAINT.COM(turbo CP/M)

以上が、SASI HDDに大きく係わるものです。

この中で、"HD MAP.Uty"と"DISK SYSGEN.Uty"はBIOSが動けばそのまま動きそうなので後回しにします。

BASIC用ソフトの中身をざっと見たところ"DISK UTILTY.Obj"が肝となる事が分かります。これを解析したところ、SASI HDDのフォーマットをマシン語で行っているだけで、SCSIでは不要なものばかりでした。"HD FORMAT"ではマシン語処理を呼び出さずに、BASIC側では常にフォーマットが正常終了したものとして判断してやれば、このままでSCSIに対応できそうです。

あと、turbo CP/Mのコマンドですが、HDOFF.COMは名前の通りのもので、HDMAINT.COMは既知のBIOSファンクションを呼び出しているだけのもので、とくになにもしなくて良さそうです。

参考文献

Z80ファミリ・ハンドブック…ＣＱ出版社
X1システム研究室…日本ソフトバンク
Oh!MZ 1985年1月号…日本ソフトバンク
トランジスタ技術SPECIAL No.27…ＣＱ出版社
OPEN DESIGN No.1…ＣＱ出版社
SCSIプロトコルコントローラ（MB89352）ユーザーズ・マニュアル…富士通

ソフトウェア設計

方針として、

• BIOSはSASI HDD互換とすることで、BASICやturboCP/Mでそのまま使えるようにする
• 従来のSASI HDD処理を潰し、そこにSCSI処理を納める（現時点では納まるのか不明）
• FDD処理の改善（主にステップレートの変更）
• ROMを換えるついでに、便利な機能（？）の追加

基本方針

• SCSIコントローラに手持ちのMB89352を用いる
• 楽をする（とくに配線量の削減。ハンダ付け面倒だもんね）
• ローコスト化（死蔵している部品、廃品の利用などで）