MZ-1E30
(MZ-2500/2800用HDD I/Fボード)

Tweet
 MZ-2500とMZ-2800で使用できる、ハードディスクI/Fボードです。HDDの普及が本格化し始めた時期なのか、SASI規格が採用されています。SASIと言えばSCSIの前身となる規格で(シュガートが独自に作ったI/Fなのだから規格という言い方は違うんだけど)、PC-9801用としてあちこちのサードパーティーから外付けドライブが発売されたことから、程度の良い中古品が適価で入手できたこともあって、X1turboと共にちょっと贅沢な環境で使用していた人もいたんじゃないかと思います(I/Fが入手できたかはともかく)。

 かつてS-OSユーザーズクラブでは会員向けにパソコン通信ホスト局「S-OS NET 大阪」を運営していて、その構成がMZ-2500とHDDだったのでした。
 ちなみにその支局としてオープンさせた「S-OS NET 横浜」はホストパソコンとしてMZ-2800を使用していたものの、HDDは1993年当時ホットだったSPCボード(富士通・MB89352使用のSCSIホストアダプタ)経由SCSI HDDを接続していました。だって純正I/Fは入手できても高いし、実は特殊フォーマットが必要でPC-98用のが使えたかどうかわかりませんでしたからねぇ。

 ROMが搭載されていますが、これはMZ-2500用のIPL ROMです。MZ-2800で使用する時にはそばにあるジャンパをOFF側に差し換えます。IPLと言いますか、このROMは単に起動するだけじゃなくてIOCSにHDDへのアクセス機能を追加する働きも持っています。つまりX1turboとは違い、元々のMZ-2500にはHDDのアクセス機能はないんですね。後から追加できるってのはすごいと思える反面、X1turboより1年遅れて発売されたマシンなのだからそれぐらいデフォルトでサポートしててもよかったのにとも思ってしまいます。

 それと、HDD用IOCSの拡張はBASICでの使用を前提にしているため…というかBASICのことしか考えずに作られているため、P-CP/Mでも使えないとされています。そりゃまぁ階層化ディレクトリが使えないCP/Mで容量の大きすぎるディスクは決して使い勝手が良いとは言えませんけれど、フロッピーに比べれば格段にアクセス時間が短いのですから、サポートされてれば良かったのになぁと思ってしまうのです。

 バスコネクタ(カードエッジ)が50ピンサイズになっています。これはMZ-2800で追加された信号(DMAと割り込み)を使っているからなのですが、MZ-2500ではもちろん意味のない部分なので、従来の44ピンの信号でも動作します。動作はしますが、コネクタのサイズが広くなっていますからMZ-1500/800の本体スロットを除いて、他のMZの拡張スロットに装着することはできません。

 SASIバスコネクタがアンフェノールタイプの50ピンなので、こういうスロットカバーが付属します。標準的な開口部がD-Sub37ピンぐらいまでしか収容できないので、特別なカバーが必要になってしまうのですね。MZ-1E30専用の開口部が下段にしかないので、自然にスロットも下段がMZ-1E30専用ということになってしまいます。

 ところで、よく見たら上段のスロットのフタを留めておくためのネジが、下段のネジ穴と同じような場所についてますね。つまりこのフタを使えば下段も塞いでおくことができるということになるわけですが…それってMZ-1E30を装着していない状況ですよね…そもそもこのカバーを使う必要があるんでしょうか…それとも一部ユーザーは標準のカバーを持ってない可能性があるとか? いやHDDで運用するシステムの、I/Fだけ取り外される事態(しかも故障したとかではなくて外したままになる)は未来の可能性について考えすぎ・気を回しすぎじゃないかと…。
 私が持ってるマニュアルでは、MZ-1E30はMZ-2500のみのオプション製品ということになっていて、MZ-2800については何の記述もありません。MZ-1E30(と純正ドライブであるMZ-1F23)の発表は1987年3月ごろと思われ、MZ-2800の発表がそのもう少し後なので、ある時期までのマニュアルには未発表の製品のことは書けなかったのだろうと思います。とは言えわざわざMZ-2800に対応できないバージョンがあると混乱しますから、マニュアルに書いてなくても最初からMZ-2800対応のボードだったことは明らかです。

 こういう狭間の製品を見ると、ついつい邪推したくなっちゃうんですよね。MZ-2800の企画はいつだったのか、開発期間はどれぐらいだったのか…MZ-2500の拡張I/Oポートのバスコネクタ端子数が50なのはなぜなのか、MZ-2800で専用の信号が配置されるようになったのは偶然か…こういった狭間の製品から垣間見えることもあるんですが、それはまた別の機会に譲りましょう。

 ちなみに、「MZ-2500にHDDを接続するオプション」については、当時のパンフなど資料を当たってみると1986年5月ごろにテレシステムズがHD-25S-10/HD-25S-20というシステムを発売していますね。システムの深いところを利用しているわりには純正の方が後追いになっているというのが不思議なところですが、MZ-2500の開発にもテレシステムズが深く関わっていると思われますし、もしかするとMZ-1E30もMZ-2800対応(DMAとか)ついでにテレシステムズが開発したんじゃないかと思うんですが…。

 それはそれとして。
ある日、とある環境でMZ-1E30を使おうとして、なんだかSASIバス信号が化けてるようで、故障なのか確認するためにも回路がどうなってるかわからないと手も足も出ないことから、回路図を描いてみました。

 マニュアルにも詳しいレジスタの解説はなかったので(そりゃそうよね)、回路図から読み取ってみましょう。まずはROMディスクの方から。

アドレス $A8
  Write Read
アドレスバス
(A15〜A8)
7 無効 無効
6
5
4
3 0
2 0
1 無効
0
データバス 7 無効 無効
6 ROMの上位アドレス
(A14〜A8)
5
4
3
2
1
0
アドレス $A9
  Write Read
アドレスバス
(A15〜A8)
7 無効 ROMの下位アドレス
(A7〜A0)
6
5
4
3
2
1
0
データバス 7 無効 ROMデータ
6
5
4
3
2
1
0

 MZ-2500のROMディスクはEMMの要領と同じくポート0xA8でROMの上位アドレスをセットし、ポート0xA9からデータを読み出します(EMMでの書き込み機能がないということ)。注意が必要なのは、上位アドレスセットの際Bレジスタのビット3と2も記憶されて、この値がデコードに取り込まれているというところです。両ビット共'0'でないとROMにアクセスできません。

 これなんなんでしょうね? 回路の雰囲気からするとポートアドレスは同じでもこの信号の取り込み方で最大4つのROMディスクを並列接続可能なようにしてあるようですが、この設定を変えることでブート可能なROMをサーチするとか、"ROM1:"とかのファイルディスクリプタでアクセスしたら設定を変えるとかしてないようですので、企画倒れだったのかな…。まぁIOCSだけ変更すれば実現は可能ですので、カスタム対応とかあったのかもしれませんけれど…。

 次にSASIのホスト部分。

アドレス $A4
  Write Read
7 コマンド/データ  ステータス/メッセージ/
データ
6
5
4
3
2
1
0
アドレス $A5
  Write Read
7   -REQ状態(1=リクエスト)
6   -ACK状態(1=出力中)
5 -SEL出力(1=出力) -BSY状態(1=ビジー)
4   -MSG状態(1=メッセージ)
3 -RST出力(1=出力) -C/D状態(0=データ, 1=コマンド)
2   -I/O状態(0=出力, 1=入力)
1 DMAイネーブル(1=許可)  
0 割り込みイネーブル(1=許可) 割り込み状態(1=発生中)

 ポート0xA5のビット1と0はMZ-2800用の機能のオン・オフや状態確認に使われるもので、MZ-2500ではこれらのビットは常に'0'をセットするようにしておきます。割り込みとはZ80の割り込み信号ではなく80286方面への専用割り込みライン"IRHD"のことですね。

 SASIの制御線は一通りその状態をレジスタから読み取ることができますが、制御出力のうち-ACKだけはレジスタにありません。これはコマンドまたはデータをポート0xA4を通して読み書きすると、自動的に-ACKが出力されるからですね。データポートの入出力の際はどうせ必ず-ACKを出すわけですから、これを自動化しているI/Fは多かったと思われます。

 SASIの各フェーズの実行を、レジスタの操作に注目して考えてみると…。

★ セレクションフェーズ
  1. ポート0xA5・ビット5が'0'であることを確認 (バスフリーフェーズである)
  2. ポート0A4に1(ターゲットID=0)を出力
  3. ポート0xA5に0x20を出力 (-SELを有効にする)
  4. ポート0xA5・ビット5が'1'になるまで待つ
  5. ポート0A5に0を出力 (-SELの出力を終了する)
★ コマンドフェーズ
  1. ポート0xA5の、ビット6が'0'であり(何も出力中ではない)、かつビット7が'1'である(-REQを受け取っている)ことを確認
  2. ポート0xA5・ビット3が'0'だったり、ポート0xA5・ビット2が'1'だったりするとコマンド待ちではないので終了
  3. コマンドを出力し、1に戻る。6バイト分繰り返す
★ データ転送フェーズ
  1. ポート0xA5の、ビット6が'0'であり(何も出力中ではない)、かつビット7が'1'である(-REQを受け取っている)ことを確認
  2. ポート0xA5・ビット3が'1'だったりするとデータ転送ではないので終了
  3. データ出力時はポート0xA5・ビット2が'0'であることを確認してポート0xA4にデータ書き込み、データ入力時はポート0xA5・ビット2が'1'であることを確認してポート0xA4からデータ読み出し
  4. データの長さ分を1〜3まで繰り返す
★ ステータスフェーズ
  1. ポート0xA5の、ビット6が'0'であり(何も出力中ではない)、かつビット7が'1'である(-REQを受け取っている)ことを確認
  2. ポート0xA5の、ビット4が'1'だったり(この場合メッセージフェーズ)、ビット3や2が'0'だったりするとステータス転送ではないので終了
  3. ポート0xA4からステータス読み出し
★ メッセージフェーズ
  1. ポート0xA5の、ビット6が'0'であり(何も出力中ではない)、かつビット7が'1'である(-REQを受け取っている)ことを確認
  2. ポート0xA5の、ビット4が'0'だったり(この場合ステータスフェーズ)、ビット3や2が'0'だったりするとメッセージ転送ではないので終了
  3. ポート0xA4からメッセージ読み出し

となりますでしょうか。なおMZ-2800ではDMAが使用できますので(チャンネル0)、転送直前にDMAを設定してポート0xA5に0x02を書き込めばDMAにて転送してくれるものと思われます。もちろんMZ-2800でも上記の方法(PIO転送)を使用してかまわないはずです。

 ところで、不思議なことが二つ。

 以前から所有してたのに今さら気づいたことがありまして…カードエッジコネクタの近辺、妙なスルーホールとか穴とかあるじゃないか、これは見覚えあるぞ…ということでMZ-1E32(右)と並べてみました。

 ふむ、拡張I/Oポートなしで固定するためのものと思しき穴と、メインボードと直結するためのコネクタを取り付けるスルーホールということで良さそうです。でもMZ-1E30の方のコネクタがないのはどういうこと…?

 マニュアル(上)を見てもボードの絵に二つ並ぶ穴がありますから、最初からあったんでしょうけど、固定金具があるわけでなし、コネクタがないのですから利用もできないわけで…もちろんマニュアルにそれ以上の記述はありません。

 ひとつ推測できるとしたら、いわゆるカスタム対応というやつで、システムで納入するセットに拡張スロットにはこれ1枚しか装着する必要がない場合、MILコネクタを後付けしたものをあらかじめ組み付けていた…というところでしょうか。スロットを使わず固定すると下段の位置にならざるを得ませんから、専用スロットカバーが下段スロットを前提とした構造になってるのもうなづけるような気がしますね。

 もうひとつの不思議は、Z80バス部分にて*INT端子がMILコネクタの*INTのところにだけ配線されていて、ボードの他の所ではまったく使われていません。回路図がそうなっているのは実物のボードの配線に従ったからなのですが、カードエッジコネクタの信号のうち使用していないものはコンタクトパターンを設けないという設計方針と思われるのに、*INTだけそこから外れているのが気になります。もしかしてですよ、設計当初は、Z80にも割り込みを使えるようにしようと考えたものの、なんらかの理由でやめちゃった…とかだったりしないのでしょうか。

 まぁ、SASIと言えどFDに比べればずっと速いですし、割り込みを待つ間できる処理の量はたいしたことないかもですね…それよりDMAの方が必要だった…それゆえのMZ-2800でのサポートだったのでしょうが…。

 手元には二つのバージョンのMZ-1E30があります。その違いは終端抵抗の電源にダイオードが追加されたのと、コンデンサ追加です。古い方の基板も改修されて新しいものに追随済みになっています(私が描いた回路図には反映済み)。追加されたコンデンサは裏面にハンダ付けされていて、新版の方でもまだ裏面にひとつありますから、もう一つ新しいバージョンがあるのかな…。

MZ-2500用IPL-ROM

 上でも書いたように、MZ-1E30にはブート兼機能拡張用のROMが搭載されています。機能拡張とは早い話が「デバイスドライバ」でして、詳しく見れば整理しきれてない部分はあるものの、OSというものがハッキリとは存在しないシステムでこういうものがあること自体驚嘆します。

 この仕組みをモノにすれば未知のデバイスの接続に道が拓けるということもあるので過去何度か解析しかけたんですけど、そのたびいろいろな理由で解析結果が失われる事故に見舞われ…いやまぁ個人的な理由なのでその悔しさをぶつける先もないんですが、とにかくなんでもやらないと前へ進めませんので、まずはROMのアドレスマップを書き出してみます。

レコード 内容 実行アドレス 備考
0 ブートレコード   クレジット表記がある
1 ブート処理 8000h
→0E000hに転送、
 0E01Ehにジャンプ
 
2  
3  
4 常駐部 0F00h  
5 リード 0C20h  
6 ライト 0C20h  
7 前処理 0C20h バスフリーフェーズ〜コマンドフェーズ
8 初期化 0C20h ヘッドリトラクトを含む
9〜14 未使用    
15 ビットマップ   2D相当
16〜23 ディレクトリ    
24〜31 FILE_TOOL.m 0E000h  
32〜39 FILE_TOOL.s 0E000h  
40〜127 未使用    

 アドレスマップを書き出すだけでもある程度は解析したので…忘れないうちにメモ代わりに簡単な解説を載せておきます。

 ROMはROMディスクとして搭載されています。そこでアドレス値ではなくレコード番号でマップを表してみました。レコード番号とは先頭を0番としてセクタに順に番号を振ったもので、レコードひとつで256バイトあります。"ROM:"としてアクセス可能なので、DEVI$で読み出すことができます。

 ビットマップとはディスクの使用状況をマッピングしたもの(FATに相当)、ディレクトリはファイル情報のテーブルが収められている区画になります。ROMの中身は2Dフォーマットのディスクと同じ構造になっていて、FILE_TOOL.mとFILE_TOOL.sという二つのファイルが記録されています。これらはそれぞれBASIC-M25とS25の機能を拡張するユーティリティで、BASICインタープリタの空き領域に組み込まれてフリーエリアを侵食しないようにされています。

 MZ-2500は起動時にROMディスクの存在を知ると、第0レコードを読んでブート可能かチェックします。ブートレコードとして受け入れ可能であれば、その情報に従ってプログラムを読み込みます。MZ-1E30のROMでは、第1〜3レコード(通常の起動ディスクの場合、Sys Loaderの管理データが収められている領域)にブート処理プログラムがありますのでこれをロードします。

 このブート処理には次の3つの役割があります。

 「常駐部のロード」とは、第4レコードにあるプログラムをIOCSの空き領域に読み込んでデバイス登録を行うもの、「IOCSへのパッチ」とはSHIFT+ESC押下によってヘッドのリトラクト(シッピング)を行うために1文字入力のファンクションコール(SVC INKEY)に対して機能追加を行うもの、「HDDからのシステム起動」とは稼働準備が整ったHDDにアクセスしてシステムを読み込むものです。

 なお「IOCSへのパッチ」などと言いますが、MZ-2500のIOCS ROMは一部の内容をRAMに転送していて、そこを書き換えることで改造みたいなことが可能です。SVCファンクションコールもジャンプテーブルはRAMに展開されていて、BASICがロードされて初めて使えるようになる機能は後からテーブルが書き換わるようになっています。

 なおIOCSの内部ルーチンを呼び出している箇所があるため、ROMのバージョンを確認しています。見たところ二種類のROMに対応しているみたいですが、手元ではMZ-2800(2500モード)で使えているわけですし、普通に市場に流通したものならバージョンエラーで撥ねられることはないと思います(MZ-2511/2521に搭載された最初のバージョン、MZ-2531に搭載のバグ修正バージョン、MZ-2800に搭載のCMT関係を削除するなどしたバージョンの少なくとも3つの存在は確認されている)。

 ロードされた常駐部は1レコード・256バイトしかなく(厳密には203バイト)、これだけではSASIバスの制御を全て記述するには少なすぎます。だからといって他に気軽に使える空き領域がそんなにあるわけではありません。そこで採られた方法が、「SASIの共通部分を常駐部に残して、あとは機能ごとにその都度ROMから転送してくる」というものです。

 その必要に応じてメモリにロードされ実行されるサブルーチン群が第5〜8レコードにあります。これらはいずれも実行アドレスが0C20hになっていて内容が違うのに同じアドレスとされているのは不思議に見えるのですが、それはロード先が同じアドレスになっているからなのですね。

 IOCSの0C20hからの160バイトは、「BASIC-M25ソースリスト」によるとプログラム転送用の空きエリアとされています。ここのエリアには、IOCS ROMのあちこちから様々なサブルーチンが転送されてくることになっています。というのも、必要に応じてメモリブロックの構成を変更しながらデータの読み書きとか転送を行うことになっており、IOCSの一部がRAMに展開されているのもそれが「共通部」としてシステムの円滑なデータ流通を司る役割を果たしているからなのです。当たり前の話と言えばそれまでですが、いくらMZ-2500のメモリブロックがどこでも自由に配置可能だからといって野放図に使っているわけではなく、ブロック単位で役割が決められているのですね。そうすることでデータ転送のルールが定まるということなのでしょう。

 0C20hからの160バイトのうち、HDDのドライバが使用しているのは144バイトです(残りは一時的なワークにも使われている)。たったこれだけの大きさなので、非常駐部すら第5〜8レコードに分割する必要があるわけです。

 本来ならば常駐部には共通ルーチンを置くところなのですが、どうしても入りきらなかったようで、第7レコードすらも共通部と定義してそれをサブルーチンコールしています。例えばリードでは一連の動作がこんな感じになっています。

常駐部   (ディスクリプタにもとづくリードのファンクションコール)
   
常駐部   (第5レコードをロード、実行)
   
第5レコード   (SASIのリードコマンドを準備)
   
常駐部   (第7レコードをロード、実行)
   
第7レコード   (SASIのコマンドフェーズを実行)
   
常駐部   (第5レコードをロード、再開)
   
第5レコード   (データ転送フェーズを実行)
   
常駐部   (SASIのステータスフェーズを実行)

 第7レコードにはバスフリーフェーズであることを確認して、コマンドフェーズを実行するルーチンが収められています。コマンドフェーズはSASIのHDDをアクセスするための起点になる動作ですから、本来は常駐部にあるべきなのですが…合わせると常駐部を置くことのできるエリアの大きさである256バイトを超えますので、仕方なく分離したのだと思います。

 この分離された第7レコードを、まるでサブルーチンコールするがごとく、常駐部と行き来しながら呼び出しそして戻ります。呼び出し元も呼び出し先も同じエリア、呼び出したら呼び出し元は上書きされて消えるわけですから綱渡りの処理進行と言えます。

 MZ-2500は最大256KBのRAMを搭載して、ユーザーに広大なフリーエリアを提供したという意味で魅力的なマシンだったわけですが、それもシステムがRAMをケチケチしながら創意工夫で明け渡してくれていたからこそ、ということなのかもしれません。

 解析したことでわかったことなどを二題。

 マニュアルには「init "HD1:"」とするとヘッドのリトラクトを実行するとあります。キー操作だけではなくプログラムからもリトラクトさせて電源切断タイミングを知らせられるようにするのが目的でしょうか。ところで、実はやはりinitコマンドなだけあって、ここに設定値を指定できるようになっています。

init "HD1:n"

コントロール・バイトを設定する。
n:0〜3
n 禁止を設定するモード
リトライ データエラーの修正
0 許可 許可
1 禁止 許可
2 許可 禁止
3 禁止 禁止

 nは実際には下位2bitしか見ていませんので、@,A,B,Cでもタ,チ,ツ,テでも指定できます。まぁただ、SASIで定義されている機能だからといってHDDがサポートしているかはわかりませんし、禁止を指定したくなる理由というのもよくわかりませんので、ここはデフォルトで許可にしたうえでマニュアルに載せなかったのは問題ではなかったでしょう。

 もう一つ、BASICにVERIFY ON/VERIFY OFFというディスク書き込み時にベリファイしてくれる機能をオンオフする命令があるのですが、これはHDDにも指定が有効で、VERIFY ON時にはちゃんと書込み後読み出していることがわかりました。

 が…空読みしてますね…今書き込んだデータと比較してないじゃないですか…単に読み出す時間が増えただけで、あまり意味がないような…。ああ、一応上記の設定にかかわらずコントロール・バイトの両bitを禁止にしているので、エラーがあれば修正せずエラーメッセージが送られて来るという想定でしょうかね…。


RaSCSIを接続する

 Raspberry PiのGPIOに適切な信号を割り当てて、バッファ基板経由または直接、パソコンのSCSI端子に接続すると仮想のHDDやCD-ROMが実機から扱える「RaSCSI」「RaSCSI baremetal version」。元々がGIMONSさんが拡張するX68kシリーズエミュレータ「XM6 TypeG」の派生プロダクトという生い立ちゆえか、SASI HDDをエミュレートする機能もあります。

 ならばMZ-1E30を装着したMZ-2500/2800でも使えるんじゃないかと試してみました。当初は必要だったパッチも今では最適動作により高速アクセスが実現しており、さらにSASI対応が充実して大変便利になりました。ここではそれぞれの対応状況や使い方をご紹介しておきます。なお使用しているRaSCSIのバージョンは1.50です。

 配布されたバイナリがそのまま使用可能です。アダプタボードに合ったものを選んで使ってください。ただし、バージョン1.50ではフォーマットが正しく進行しないことがわかっております。それ以外での動作は問題ありませんので、フォーマットの時だけは1.47を使うか、エミュレータでフォーマットしたイメージをコピーするか、当面1.47に留めておくかしてください。
 HDDイメージは20MBの大きさで作成して下さい。これはMZ-2500がHDDのサイズを20MBと決め打ちしているためです(BASICから使えるディスクの大きさは10MBであり、これはソフトで区画分けしている)。
 イメージはRaspbianのddコマンドで作っても良いですし、Common Source Code ProjectのMZ-2500エミュレータ(EmuZ-2500)では2020/08/16版から空のHDDイメージを作成してマウントする機能が追加されましたので、そちらをコピーして使用してもいいでしょう。
 なお純正HDDであるMZ-1F23の容量は、マニュアルの説明から計算すると22437888バイトとなります。今のRaSCSIのバージョン(1.46以降)では、MZ-2800対応のためこの22437888バイトという大きさのHDDイメージファイルを特別扱いして、1024バイト/セクタとして振る舞うようになっています。というのも、MZ-1F23にはセクタサイズを256バイトと1024バイトで切り替えられるスイッチが備わっているのですが、RaSCSIにはコマンドラインなどでの設定はありませんので、ある種のマジックワードのように22437888という数値を利用しているのです。
 そんなわけでイメージファイルのサイズは22437888バイトを避けたものにしないといけないのですが、しかしそうするとMZ-2500の動作に影響しないか心配になります。足らなかったり多すぎたりするとエラーが出たり、ハングアップしたりしないのでしょうか?
 結論から先に言えば、多くの場合問題にはなりません。EmuZ-2500で作成できるHDDイメージの大きさは20786176バイトですし、RaSCSI推奨であるXM6 TypeGのディスクイメージ作成機能は20748288バイトのイメージを出力しますが、次のようにフォーマットでも実運用時でもアクセスする範囲に収まるのです。
 HDDの全容量・22437888バイトのうち、最後の1655808バイト分はヘッドのシッピングゾーン+余裕分として使用を除外されています。SASI時代のHDDは電源断時にヘッドがディスクよりも外に退避するような機能がなく、ディスク上にヘッドがある状態で電源が落とされるため、ディスクの回転で発生する風圧がなくなってヘッドがディスク盤面に着地してしまうことになっていました。ヘッドと盤面が接触すると盤面に傷がついてしまいかねないので、敢えて一部のエリアを非データ領域=シッピングゾーンという扱いにして電源断直前にあらかじめそこにヘッドを移動するようにしたわけです。おかげで酷使されたHDDはモーター起動トルクが減ってきてるのにヘッドが接触して抵抗になり、ディスクが回転しなくなるトラブルが多発することになったわけですが…(ドライブ全体をディスクの回転方向に回るようちょっと力をかけてあげると回り出す、通称「押し掛け」なるテクニックも生まれたりしてますが)。
 ヘッドのシッピングはSASIにシッピングコマンドなんてものがあるのではなく、シッピングゾーンへシークすることで実現しているようなのですが、RaSCSIはシークコマンドにてシーク先のブロックアドレスを受け付けておらず、シーク本来の動作をしていません(いわゆるSSDみたいなもんなんだから当たり前だ)。もちろんシッピング自体やる意味がありませんね。
 そしてシッピングゾーンを除いた20782080バイトがユーティリティによるフォーマットの対象になる領域で、末尾の33792バイトはRaSCSIでサポートする容量から溢れてしまいますが、フォーマットコマンドもまた指定されたブロックアドレスを捨てていますのでイメージファイルをアクセスすることはなく、エラーになりません。
 さらに、20504320バイトを超える部分はデータの読み書きに使われないため、RaSCSIでサポートする容量を超えてアクセスされることがなく、結果としてMZ-1F23の容量と違っていてもXM6 TypeGで作ったディスクイメージをそのまま使って問題ないということになっているのです。
 MZ-2800ではセクタサイズが1024バイトのHDDを使用することになっています。先述したように、RaSCSIはこの対応をマウントしたHDDイメージファイルの大きさ(22437888バイト)で判断して切り替えています。
 MZ-2800専用のHDDイメージファイルの作成は、sasidump(SASI専用ディスクダンプツール・本当に使えるかは未確認)を使うか、Raspbianのddコマンドで作るかします。ddコマンドの例は、こんな感じになります。
HDDイメージファイルの作成
>dd if=/dev/zero of=HARDDISK.HDF bs=1024 count=21912  
 Common Source Code ProjectのMZ-2800エミュレータ(EmuZ-2800)でもMZ-2500エミュレータと同じく空のHDDイメージを作成する機能が追加されましたが、動作判別バイト数より少し小さい(20156416バイト)のでそのままでは使えません。ダミーデータを追加して大きさを合わせてください。
 なお、HDDイメージを複数台指定するとC, D,…と順番に割り当てられて、合わせれば20MBを超える容量のHDDの使用が可能になります。元々システムではサポートされていながら、メーカーの発行するシステム構成図などでは純正増設ドライブが発売されなかったがために使えるのかどうかさえわからなかった複数台のHDD。なんと手軽に実現することよ…。
複数イメージを指定したRaSCSIの起動方法
>sudo ./rascsi -HD0 disk_C.HDF -HD1 disk_D.HDF  
SASI HDDを複数台接続するためにはIDではなくLUN番号を順に割り振って指定します。
 Raspbian(Linux)ベースのソフトではないためセットアップが容易で電源断の手順もないベアメタル版。通常版と比較して機能制限(ネットワーク機能が使えない)はあるものの、どうせMZからRASETHERを使えるでなし、動的なイメージ入れ替えに対応しているわけでもないので、ベアメタル版で十分じゃないかという見方もありますよね。強いて言えばエミュレータとイメージを共用するためにSDカードリーダーが必要ってぐらいですか?
 ベアメタル版も1.46ベースのバージョンからSASIの1024バイト/セクタに対応するようになり、「通常版でないと使えない」理由はなくなりました。ベアメタル版はそもそも「電源の投入から使用可能になるまでの時間が短い」という特徴があるのですが、MZ-2500/2800はHDDの普及期の初期の製品であるからか、スピンアップ…つまりHDDが使えるようになるまでの時間を多く見積もって時間待ちをするためにRaspberry PiをMZと連動した電源で起動しても余裕を持って待機状態まで起動可能だったりします。単に「今手に入るSASI HDDの代替品」としてならベアメタル版は最適ですね。
 セットアップなど主な使い方は公式サイトに譲ります。HDDイメージのファイルの大きさで挙動が変わるのも通常版と同じです。Raspberry Pi上で直接空のイメージファイルを作ることができないので、別のRaspberry Piで作ったり、エミュレータのイメージ作成機能を使うなどしてなんとか工夫してください。
 なおベアメタルバージョンならMZ-2500でのフォーマットは失敗しません。

 以上について、手元での確認に留まっていることもありますので、無保証にてご活用ください。

所蔵品一覧に戻る