Diary/2006-7-2

GOverHD.x は必須なのですね

さて、前述のように 250GB の HDD を接続しましたが、ファイル・コピーの途中で失敗してしまいました (--;

 SCSI-ID : 0 ... 230 MB （c:20MB,  d:210MB  の2パーティション）
 SCSI-ID : 2 ... 250 GB  (e:900MB, f:2000MB の2パーティション）

こんな構成で d: に入っているファイル群を copyall で f: にコピーしたら、途中で「セクタが見つかりません」の白帯が出て止まるのです。250GB の方のパーティションをサイズを変えながら切り替えていった結果、どうもデータ領域で 1GB を超えたところで失敗している様子。

どこかで聞いた事のある 1GB の壁。もしや・・・と、GOverHD.x 2 を実行して250GB のディスクにも GOverHD 処置を施したら問題なく使えるようになりました。てっきり SCSI-ID の小さい方だけ適用されてれば大丈夫かと思ってましたが、そうじゃ無かったということですか。

やはり、1GB を超えたら GOver.x はお約束なのですね。FORMAT.x の GOver 対応版 FORMATa.x を使うと良いと聞きましたが、どこにも見つからなかったもので (^^;

copyall とバスエラー

NetBSD で X を使う為に 68030のFC2ピンを折りましたが、copyall.x を実行するとバスエラーになることに気づきました。030syspatch を常駐（DEVICE=で組み込む）していると問題はないのですが、何でかなぁと。

そこで db.x 上で copyall.x を動かしてみると、一番最初のサブルーチン・ジャンプでバスエラーが起きています。copyall.x は起動後、自分に割り当てられたメモリの最後のアドレス+1 のロングワード境界をスタックポインタに設定します。

 move.l 8(a0),d0
 andi.l #$fffffffc,d0
 movea.l d0,a0

このマシンは12M実装済みだから USP の初期値は 0xc00000で、最初のスタックアクセスは 0xbffffc になり、ここでこけているわけです。

メモリはあるはずなのに何でこけるのかな？と db.x 上から書き込もうとしてもやはりバスエラー。？？？と思いつつよぉ〜く考えてみると、何のことはない、030syspatch がこの領域を 68030 で使うように設定してるんですね（0xbea000 〜 0xbfffff の領域）。

config.sys から外しても無効にならないので、何故だろう？と悩みましたが、考えてみれば通常は HD から起動（030Syspatch 組み込み）し、その後はCTRL + OPT.1 + DEL でソフトリセットかけているから CPU 自体への設定はそのまま有効だったということのようで。・・・というわけで、ハードリセット（リセットボタン）押して起動すれば、030Syspatch が無くとも copyall が動きましたとさ。

大抵のプログラムだと、自分自身の最後の領域から何キロバイトかをスタックにし、残りのメモリは OS に返却してるから気づかないのですが、copyall.x はメモリ領域全部を取って、その最後にスタックを設定してしまうのでこんな現象が出たわけですね。

気づいてみればそのまんまですが、面白いものです。

[カテゴリ:x68]