TangConsoleDCJ11MEMではすでに2.9BSDが動作するようになっていますが、2BSDの最終版である2.11BSDを動かしてみようと思い立ちました。現時点までの作業内容や、変更の必要な個所などについて以下に説明します。
テープデバイスのprimary boot block
2.11BSDのインストールテープイメージをROMのブートローダから起動してもそのままでは動作しません。2.11BSDではprimary boot blockの起動時の要件が追加されていて以下のようになっています。
レジスタr0にブートデバイスのユニット番号を格納する(通常は0)
レジスタr1にテープコントローラのCSRのアドレスを格納する
2.9BSDにはこのような要件はなく、ブートローダでも特にレジスタの内容については配慮されていないように見受けられます。
レジスタの内容を適切に初期化するコードをブートローダに追加することでprimary boot blockが正常に動作し、bootプログラムがテープから読み込まれて起動するようになりました。
bootプログラムの機種判別方法
2.9BSDのbootプログラムではConsole Switch Registerの内容で機種を判定していましたが、2.11BSDでは機種判定の方法が変更されています。概略としては、mfpt命令の有無やMaintenance Registerの内容などを用いて判定しています。また、UNIBUS adapterの有無を判別するために、UBMAP(UNIBUS map) registerをアクセスした際にbus errorが発生するかどうかを利用しています。
Maintenance Registerの実装を追加することで、 PDP-11/74と判定されるようになりましが、これはUBMAPのアクセスに成功することでUNIBUSが存在すると誤認したためです。期待される動作としては、
mfpt命令が実装されているのでKDJ-11と判断
UNIBUSは存在しないのでUBMAPのアクセスはbus errorとなる
UNIBUSを持たないモデルとしてPDP-11/73と判定される
となります。
UBMAPのバスエラー
UBMAP(770200) でbus errorを返すように変更したところ、期待動作とは異なり、無限ループ状態になりました。期待動作としては、
UBMAPのアクセスでbus errorが発生する
bus errorのベクタに設定されているラベルtrapから命令が実行されてリカバリ処理が行われる
ですが、実際にはバスエラー発生時にアドレス0から実行されているように見えます。
この現象については現在調査中です。なお、変更内容は以下の通りです。
@@ -724,12 +728,14 @@ module top(
//---------------------------------------------------------------------------
// Bus error
// read 760000-760077 (for unix v6)
+// read 770200 (for 2.11BSD)
// read 777700 (for Microdiagnostic test 2)
// read 772440 (MTSC1) (for unix v7 tape boot)
//---------------------------------------------------------------------------
assign ABORT_n = bus_error ? 1'b0 : 1'bz; // simulate open collector output
wire bus_error =
+ ((address == 18'o770200) & bus_read) | // UNIBUS map register
((address == 18'o777700) & bus_read) | // Microdiagnostic test 2
((address[17:6] == 12'o7600) & bus_read) | // read 760000-760077
((address == 18'o772440) & bus_read
separate I&Dのプログラムが起動できない
UBMAPのバスエラー問題については一旦棚上げにして、インストールに使用されるプログラムが動作するか確認したところ、 separate I&Dのプログラム(restoreなど)が起動できない(途中でhaltする)ことがわかりました。これも調査予定です。
0 件のコメント:
コメントを投稿