PDP-11の777572番地はMMRなのかSRなのか、それともSSRなのか

PDP-11/40で動作するUNIX V6のカーネルを勉強するため、まず最初にブートストラップ処理を追いかけていこうと思っています。その処理はm40.sのstartラベルから始まります。まず最初に「bit $1,SSR0」という処理が現れますが、SSR0とは何でしょうか。カーネルを読み進めていくには、PDP-11について幅広く理解していることが求められます。カーネルを学んでいる最中には、それほど知識を有しているわけではありませんから、DECが発行していた資料を調べてみたりする必要があります。その最初の課題が「SSR0」を理解することです。

 

1972年に発行された『pdp-11/40 processor handbook』を参照すると、「CHAPTER 6 MEMORY MANAGEMENT」の中に「6.6.1 Status Register #0 (SR0) (status and error indicators)」という項目があります。ここでは「SR0」とあり、「SSR0」ではないのですが、おそらく同じものです。同書の巻末にある「APPENDIX B MEMORY MAP」では、777572番地が「11/45 SSR0」と説明されています。なぜか「11/45」と断っているし、「SSR0」となっているのも気になります。Lions本では、m40.sの1445行で「SSR0 = 177572」とあるので、SR0が正しいのかSSR0が正しいのか不明ですが、UNIX V6ではSSR0としているようなので、あえて意義を唱えることもありません。

これで一件落着かと思うところですが、さらに調べてみると、疑問が拡がりました。1973年に発行された『pdp-11/45 processor handbook』を参照してみると、「CHAPTER 6 MEMORY MANAGEMENT」の中に「6.6.1 Status Register #0 (SR0) (status and error indicator)」という項目があります。これはpdp-11/40と同じなのですが、巻末の「APPENDIX C MEMORY MAP AND RESERVED LOCATIONS」では「777572 through 777577 Memory Management Status Register 0-2」とあり、pdp-11/40とは表現が異なります。

 

さらに1975年に発行された『pdp-11/70 processor handbook』を参照すると、「CHAPTER 6 ADDRESSING」の中に「6.5.6 Fault Recovery Registers」とあり、そこでは「Memory Management Register #0 (MMR0) (status and error indicators)」と名称が変わっており、巻末の「APPENDIX A UNIBUS ADDRESSES」では「777 572 Memory Mgt regs. (MMR0)」となっていて、もはやSSR0とは名乗らず、MMR0で統一されています。

 

777572番地のレジスタの名称が「SSR0」だろうと「MMR0」だろうと、DECが決めた名称なので、どちらでも構わないのですが、PDP11のモデルによって名前が変わるのは、今後資料を参照する際に混乱しそうで、ちょっと心配です。PDP11の後継機種の資料を参照すると、もはや「SSR0」とは呼ばず、「MMR0」となっているので、DECで方針が変わったのではないかと推測します。当初の「Status Register (SR)」というのは、機能として実体に即しているとは思いますが、意味が一般的すぎることを懸念したのかもしれません。最終的に「Memory Management Register (MMR)」とすることで、より限定された意味を持たせることにしたのでしょう。

 

この調査をしていて、いろいろな資料を見つけました。1976年に発行された『KT11-D memory management option user's manual』では「CHAPTER 3 OPERATION AND PROGRAMMING」の中に「3.6.1 Status Register 0 (SR0)」とあるのは、上述した『pdp-11/40 processor handbook』で書かれていたのと、ほぼ同じ内容です。この資料の「CHAPTER 2 INSTALLATION INFORMATION」には以下の記述があり、pdp-11/40と11/35で使われたモジュールであることがわかります。

The installaion procedure for the KT11-D Memory Management Unit option is included as part of the complete PDP-11 system installation procedure described in Chapter 2 of the PDP-11/40, PDP-11/35 System Mnual (21 Inch Chassis).

 

 また1972年に発行された『PDP-11/45 memory management reference manual』では「INTRODUCTION」において以下の記述があります。PDP-11/70もメモリ管理としてはPDP-11/45と同等のようなのですが、PDP-11/70でKT11-Cを使用しているという情報は得られませんでした。

The KT11-C Memory Management Unit is a hardware option designed for use with the PDP-11/45 Programmed Data Processor.

 

ギリシャ語のスパムメール

日々様々なスパムメールが届くので、いちいち気にしていられないのですが、ギリシャ語で書かれたスパムメールが届いたのは、さすがに驚きました。本文は、こんな感じです。

 Σα   ενημερ  νουμε   τι κατ   τη δε  τερη προσπ  θεια παρ  δοση   του δ  ματο   μα  , δεν   ταν δυνατ   η παρ  δοσ   του στη διε  θυνση πο υ παρε  χατε.

 

ELTA Hellenic Postというのがギリシャの郵便局のようなものらしいのです。なんと驚いたことに（スパムメールだから、驚くことはないのですが）「日本の私の家に郵便を届けられなかった」と言うのです。それで、「アドレスが誤っているかもしれない」と言いつつ、何故か「パスワードと電話番号を入力」するように求めています。典型的なフィッシング手法かと思います。

 

しかも、本文ではギリシャの郵便局から連絡を装いながら、発信者が「ETC利用照会サービス事務局」となっています。不在連絡かと思ったら、ETCだったのかと、本文と発信者がずれていても気にしないのが、スパムメールらしいところです。

 

日本人に宛ててギリシャ語でメールを送っても、読んでもらえないと思います。何処の誰が送信したスパムメールなのか全くわかりませんが、この調子で世界中にギリシャ語でメールを送っているんだろうかと、いらぬ心配をしてしまいました。

UNIX V6カーネルのlow.sを読む

UNIX V6カーネルを学ぶため、日本語版の『Lions' Commentary on UNIX』を参照し、DECが発行していた各種資料などを参考にしつつ、ロジックを追いかけていこうと思います。カーネルは、システムコールを受け付けたり、メモリやディスクなどのリソースを管理したり、割り込みを処理したり、様々な役割を担います。しかしそれはカーネルが起動し定常状態に達してからの話であって、マシンが起動しカーネルが読み込まれたブートストラップ処理とは違う世界の話です。カーネルを学ぶために、どの切り口から挑んでいくかは人それぞれかと思いますが、私はブートストラップ処理から始めようと考えています。そうであれば、まず最初に見ていくのはlow.sです。

 

Lions本でlow.sは、0500-0599行目に相当します。日本語版では66-67ページにあります。

1. 0502-0505行では、br4からbr7という識別子に値を割り当てています。PDP-11に親しんでいれば疑問に思うことも無いのかもしれませんが、私はbr4やbr7というのが何なのか分かりませんでした。DECの資料を読んでいくと、brというのは「Bus Request」のことで、PSWのプロセッサ優先度ビットを定義していることが判明しました。
2. 0507行では、アセンブルされた結果が格納されるアドレスを指定しています。同様の記述が0520行や0529行などにもあります。この記述はPDP-11アセンブラの記述方法なのか、UNIXアセンブラ独時の記法なのかわかりませんが、とても特徴的です。Lions本では266ページで開設されています。ともかく0507行は「. = 0^.」となっていますから、000000番地を指定していることになります。
3. 0508行では、「br 1f」とあり、0522行目にある「1」というラベルに飛びます。これはそれだけのことだと思いますが、0509行には「4」という数字が突然表れます。これは何なのか、何故「4」なのか、これは誰かが参照しているのか、まったくわかりません。次の0512-0518行目には「トラップベクタ」が並んでおり、これらはアドレス毎に役割が決まっていますから、それとアドレスがずれないようにするための埋め草なのかもしれません。そうならば「4」などという意味の分からない数字ではなく「0」でも良いような気がしますし、または「. = 4^.」を入れても構わないような気がします。
4. 0512-0518行では、上述したとおり「トラップベクタ」が並んでいます。これらはPDP-11によって構造が定義されており、最初のワードが呼び出すルーチンのアドレスで、次のワードがPSWに格納される値です。それはよいとしても、全て「trap」というルーチンを呼び出すことになっているのは何故かという疑問は残ります。さらに謎なのが、「br7+0.」のように、0505行で定義された「br7」に数字を加えていることです。表記上の注意事項としては、数字にピリオドが付加されており、これはLions本の265ページに書かれているように10進数と解釈されるための工夫です。わざわざ10進数としなくても、8進数で記述しても良かった気もしますが、それはどちらでも構いません。疑問なのは、何故「br7」に数値を加えているのかです。これはPDP-11によってPSWに格納されるワードなので、加算された値はNZVCフラグに何かが入ることになります。それを「trap」ルーチン側で参照しているのかというと、そうでもなさそうです。参照していないような気がしますが、これはm40.sにあるルーチンなので、そこで再度考えてみようと思います。ちなみに「br7」に数値を加算しているのは、0538行とか0547-0549行にもあります。しかも「br7+7.」というのが、0538行と0547行にあり、重複してもよいのだろうかという疑問もあります。
5. 0522行では、「jmp start」があります。ここは40番地になっており、PDP-11としては「System Software」が利用する領域という扱いになっています。0番地では「br 1f」として40番地に飛び、40番地では「jmp start」として更にstartに飛ぶので、何故こんなに手間をかけるのだろうかとは思いますが、何か歴史的な事情とか、PDP-11の都合とかがあるのかもしれません。
6. 0523行では、「jmp dump」という命令が置かれています。ここにはラベルも与えられていませんが、どのようにして呼び出されることになっているのでしょうか。おいおいわかってくることを期待しています。
7. 0525-0544行では、デバイス事の割り込みベクタが定義されています。そもそもlow.sはmkconfによって生成されるものなので、現実のUNIX V6においては利用されるデバイスに相当する割り込みベクタが出現するはずです。Lions本では説明の都合上必要なデバイスだけが現れます。そこではbr4-br7の何れかが記述されていますが、それらはデバイスのデフォルト値として、それぞれのマニュアルに記述されています。マニュアルによって記述箇所は一定していませんが「Address and Priority Assignments」という箇所に書かれていることが多いようです。
8. 0558-0577行では、0525-0544行の割り込みベクタで指定されているルーチンが定義されています。基本的な構造は同一で、0558行のklinであれば「jsr r0,call; _klrint」となっています。ここに現れる「call」はm40.sにあるので、あとで詳細に見ていくつもりです。ただし現時点で不思議なのは、なぜ「jsr」命令をつかっているんだろうということです。ここには「jsr」命令が並んでいますが、「Jump Sub Routine」という名前から想像されるところでは、サブルーチンから戻ってくるのだろうかと思うところですが、多分片道切符で、戻ってこないのでしょう。それならば「jmp」命令のほうが自然ではないかと思うのです。

 

low.sを見てきて、いろいろと疑問が生まれ、それらが全て解決したわけではありません。疑問が残ったままですが、カーネルのブートストラップ処理を追いかけるため、次は「start」処理を見ていこうと思います。

PayPayの本人確認手続きで運転免許証の暗証番号を初めて利用した

スマホにはPayPayのアプリをインストールしてありますが、普段使うことは殆どありません。softbankを契約しているので、たまにPayPayポイントを貰えることがあり、それを利用するくらいです。ところが本人確認が必要らしく、あまり利用していないこともあり何も手続きしていませんでしたが、催促のメッセージが送られてきました。

 

本人確認手続きは、強制ではないようです。何もしなくても私の利用形態には影響無さそうですが、別に後ろ暗いところもないのに何もしないでいるのもどうかと思うので、手続きしました。本確認手続きをするには、いくつかの方法があるようですが、運転免許証を使うことにしました。免許更新時に登録した暗証番号を入力しました。今までにも何度か免許更新時に暗証番号を登録してきましたが、実際に利用したのは初めてです。

さらに運転免許証の中に保管されている情報を読み出すために、スマホが利用できることに驚きました。私の所有しているスマホがおサイフケータイに対応しているから読み込めるのかもしれませんが、以前に使用していたスマホはおサイフケータイ非対応だったので、その場合にはどうなったんだろうと思います。

PDP-11のTRAP命令のバイナリ表現が104400から104777の256個もあるのは何故だろう

PDP-11/40上で動作するUNIX V6のlow.sを解析するため、PDP-11の命令について調べています。low.sの中ではTRAP命令は使われていません。ただし、紛らわしい事に、m40.sの中で定義されている「trap」という番地を参照しているので、うっかりするとTRAP命令が使われていると誤解してしまうかもしれません。

PDP-11 processor handbookでTRAP命令を確認すると、対応するバイナリ表現が104400から104777までの256個もあります。普通なら、BPT命令なら000003とか、IOT命令なら000004などのように、1対1に対応しているはずです。TRAP命令だけではなく、EMT命令も104000から104377までの256個用意されているので、何か意図がありそうな気がします。

 

EMT命令、TRAP命令、BPT命令、IOT命令は、PDP-11においては、それぞれの命令に専用のTRAP VECTORを介して、それぞれのルーチンに飛ぶようになっています。BPT命令なら014番地、IOT命令なら020番地、EMT命令なら030番地、TRAP命令なら034番地です。各命令に1つずつしか用意されていません。と言うことは、EMT命令やTRAP命令のバイナリ表現が256種類あったとしても、全て同じTRAP VECTORが使われる訳ですから、区別できません。しかも、256種類のバイナリ表現があり得るとしても、その値がレジスタに格納される訳でもないので、普通にプログラミングしているだけでは、256種類のバイナリ表現の違いを認識できません。どうして、こんなことになっているのでしょうか。

 

同じような疑問を感じた人は他にもいるようで「Using the TRAP instruction」という記事がありました。ロジックを工夫すれば、256種類あるバイナリ表現の中で何が使われたのかを実行時に識別することは出来るようです。

 

PDP-11の命令体系において何か意図してTRAP命令用のバイナリ表現として256種類を用意したのであれば、その区別がレジスタ参照で取り出せるようになっているべきではないかと思います。そうなっていないということは、命令体系上の方針としては、256種類を使い分ける必要はないと思っていたということでしょうか。

 

PDP-11の命令体系はよくできているという評価を得ているようです。私自身としては、まだPDP-11を学び始めたばかりなので、それほど深く理解している訳ではありませんが、多彩なアドレッシングモードが多くの命令で同じように使えるようなので、よく出来ているCPUだと思わなくもありません。そうであったとしても、TRAP命令とEMT命令については、謎めいているという印象です。

UNIX V6のmkconfはl.sとc.cを生成する

UNIX V6のカーネルを学ぶため、日本語版の『Lions' Commentary on UNIX』を主な参考書として使おうと考えています。この書籍にはUNIX V6カーネルの全ソースコードと解説が掲載されていますから、これだけあればソースコードとしては十分なのですが、ネット上にはUNIX V6のソースコードが置かれているので、それも併用しようと思います。

 

カーネルを理解するには、闇雲にアプローチしても手に負えません。カーネルは光の当て方によって、様々な姿を見せてくれますから、そのどこかに注力して、カーネルの深淵に迫ろうと思っています。Lions本にはLions本なりのアプローチがあり、BSDの黒本には黒本なりのアプローチがあります。どこからアプローチしても、途中で挫折しなければ、到達点は同じのハズです。

 

PDP-11/40にカーネルがロードされ、実行を開始し、初期設定などが完了してカーネルとして機能する準備が完了した後ならば、ユーザプロセスからシステムコールを受け付けたり、メモリ管理を行なったり、ファイルシステムによりファイル操作をするなど、カーネルとしての役割を淡々と実行していきます。カーネルとしての諸機能を恙なく処理するには、カーネルの実行開始時にリソースの初期設定を済ませておく必要があります。このような視点では、カーネルの初期状態と定常状態という2つの状態としてカーネルを理解するアプローチになります。

 

カーネルが定常状態に入った後は、システムコールとか、メモリやディスクなどのリソース管理とか、デバイスドライバの処理など、様々な観点からカーネルを見ていくことになるでしょう。しかしそれは、カーネルが初期状態を終えた後の話です。まずは、UNIX V6のカーネルが初期状態で何をしているのか理解するところから始めようと思います。

 

Linos本によれば、カーネルの初期状態は、66ページに掲載されているlow.sから始まります。UNIX V6のカーネルをネット上で探して見ると、The Unix Heritage Societyで「Sixth Edition Unix」を見つけました。ここに置いてあるのは、Lions本とは違う点があります。

1. Lions本では「unix」というディレクトリの下にフラットにソースファイルがあるように見えますが、上述した場所では、kenとかdmrなどのサブディレクトリに分かれています。
2. Lions本では、説明の都合上だと思いますが、説明対象外のデバイドライバのソースファイルは掲載されていませんが、上述した場所では全て置いてあります。
3. ここが最も重要かと思いますが、Lions本で掲載されているlow.sとconf.cは、上述した場所には置いてありません。
   

 

Lions本では、291ページで次のように書かれています。これはlow.sの説明ですが、conf.cも同様の記述があります。

mkconfと呼ばれるユーティリティプログラムによって生成される。

 

確かに上述した場所にはmkconf.cがあるのですが、このユーティリティプログラムが生成するのはl.sとc.cであって、low.sとconf.cではありません。カーネルの生成につかわれるスクリプトを見ても、生成されるのはl.sとc.cとして処理されるようになっています。Lions本が何故low.sとconf.cに変わっているのか、理由は不明です。もしかして初期のV6はl.sやc.cだったけど、いずれかの時点でlow.sやconf.cに変更されたのかもしれないと想像しました。しかしUNIX V7のmkconf.cを参照してみましたが、相変わらずl.sとc.cのままだったので、先の仮定は成り立たないようです。

 

Lions本がlow.sとconf.cに変更されているのは、独自に変更したのか、そういう変更が加えられたものを入手したのか、経緯は不明です。

PIANISTとDRUMMER

The Japan Times Alphaの2024年8月30日&9月6日合併号に掲載されていた「LUANN」では、次のようなセリフが載っていました。

This band has a pianist, guitarist, bassist, saxophonist, trumpeter and drummer.

 

このセリフを発した理由は、なぜ楽器の奏者に「-ist」がつく場合と「-er」になる場合があるのかという疑問からでした。その答えとして、次のように説明しています。

It's because "trumpet" and "drum" are nouns and verbs, like "bugle." You can trumpet, drum and bugle, but you can't piano, guitar or bass.

要するに、名詞と動詞の両方で使える単語なら「-er」で、そうでないなら「-ist」という事のようです。

 

これは私自身も以前から疑問に思っていました。マラソンなどの選手は「ランナー」と言いますし、ボーリング選手は「ボウラー」ですし、冬季オリンピックでもお馴染みになったカーリングの選手は「カーラー」だそうです。

日本では俗語として現れる「転売ヤー」というのは、「転売」という語が単独で名詞と動詞の両方で使えるわけではない（動詞なら、サ変動詞として「転売する」になる）ので、「転売ニスト」の方が正しいのかもしれません。

 

パソコンの達人のようなひとは、Windows使いなら「Windowsist」とか、Mac使いなら「Macist」と呼ぶのでしょうか。同様にLinuxを極めた人であれば「Linuxist」とか、BSD好きなら「BSDist」で、究極的にUNIXのGURUなら「unixist」かもしれません。

OSカーネルを勉強してみたい

OSに関する理解を深めるためにカーネルを学んでみようとするのは、ごく普通のアプローチではないかと思います。Linuxであろうと、FreeBSDやNetBSDなどであろうと、カーネルのソースコード自体は公開されていますから、それらを素材としてカーネルを学ぶことは「理論上」としては可能です。しかし「現実問題」としては、困難でしょう。例えるなら、普段からウォーキングをしているからと言って、なんの準備もなく、いきなりエベレスト登山に挑戦できるかと言えば、無理でしょう。

 

書籍として『私はどのようにしてLinuxカーネルを学んだかゆたかさんの技術書』のようなものがいろいろと出版されていますから、Linuxを素材としたいと考えている人は、少なくないのでしょう。2024年時点でLinuxカーネルは3600万行もあるようで、カーネルを初めて勉強しようとする人が取り組むようなものではないと思います。

 

これに対して、古典的なUNIXのカーネルを素材として学ぼうとするアプローチもあります。有名なところでは『Lions’Commentary onUNIX』がありますし、『はじめてのOSコードリーディング ~UNIX V6で学ぶカーネルのしくみ』もあります。これはごく初期のUNIXなので、TCP/IPネットワーク機能は入っていません。しかもCPUはPDP-11/40なので、x86系CPUとはアーキテクチャが異なります。今日のLinuxやBSDと比べると、全然違う訳ではないのですが、基本的な機能しか実装されていないので、戸惑うところがないわけではありません。

 

UNIX V6以外も、V1だろうと2BSDだろうと、インターネット上ではソースコードが公開されています。それらを独力で解析していくことも可能ですが、できれば参考書がある方が、ひとりで頑張るよりも望ましいと思います。これらを勘案し、Lions本を参照して、SIMHでUNIX V6環境を使用して、カーネルの理解を進めていきたいと思います。

昔々ネットニューズが一般的だった頃、fj.os.bsd.freebsdに「Re: How to read FreeBSD2.1.0 source」という記事が流れました。この記事には次のような事が書かれています。

大学院生のソース読み輪講につきあったことがあるのですが、彼らも同じような非効率なアプローチを取りました。システムコールが呼ばれた時の制御の流れや、コンテキストスイッチとは CPU の何をどうすることかなど、超基本的な知識を咀嚼できてない状態で「生の OS」のソースコードに手を出すのは難がある（ひどく遠回りをするという意味）ように思います。

 

この記事の教えを踏まえて、OSカーネルの勉強をしてみたいと思います。

Student Workbook Introduction to the PDP11

PDP11に関する資料を探していたら「Student Workbook Introduction to the PDP11」というものを見つけました。PDP11に関する入門的な情報に留まりますし、マニュアルの代わりになる訳でもなさそうですが、かなり詳しいところまで記載されているのでマニュアルを補足する情報として役立ちそうな気がします。

 

この資料がどのように使われたのか分からないのですが、何日間かのワークショップのようなものが開催されて、そこで使われたようにも見えます。ところどころに学んだところを確認するための小テストなども含まれています。もしこの資料を使った講習会が開催されたのなら、僕も参加してみたい気がします。

 

「course map」を見ると「SYSTEM OVERVIEW」から始まり「I/O PROGRAMMING」と「PDP-11 FAMILY」で終わるようです。コース中の各項目ごとにPDFファイルがあるのですが、以下の項目はPDFファイルが欠けているのが残念です。

• USE OF THE CONSOLE
• UNIBUS CONCEPTS
  

液体やゴミは検出されなくなりました

今使っているスマホは「Redmi Note 10T」です。Androidのバージョンは「13 TKQ1.221013.002」で、MIUIのバージョンは「MIUI Global 14.0.15.0(TKNJPSB)」になっています。

 

つい最近になって、USB Type-Cケーブルで充電をしていると、頻繁に接続が切れ、充電が中断してしまうことに気がつきました。もしかして本体が故障しているのか、それともケーブルが不良なのか、心配になったので、Googleで調べてみました。そうすると、USBポートが汚れていたり、埃が詰まっていたりするの原因であることが多いようです。エアダスターでほこりなどを吹き飛ばすと良いようなので、やってみました。それほど埃が溜まっていたようには見えませんでしたが、充電中に中断することは無くなったような気がします。

 

問題が解決して良かったと思っていたのですが、「液体やゴミは検出されなくなりました」というメッセージが出るようになりました。スマホというものは、エアダスターでUSBボートを掃除したことを検出できるようです。まさかこんなメッセージが出るとは思いもしなかったのですが、どうせなら、充電が中断してしまう時点で「USBポートにゴミが溜まっているようです」というようなメッセージを出してくれた方が有り難いのではないかと思いました。

UNIX V6のブートストラップ

PDP-11で動作したUNIX v6の内部構造に関する資料としては、『Lions' Commentary on UNIX』が有名です。これを用いてカーネルについて学んでみようと思い、いろいろと情報を集めているところです。

 

カーネルと言うものは、UNIX V6に限らず、WindowsでもLinuxでも、マシンの電源が入ってから、ブートストラップ処理を経て、カーネルとしての起動が完了します。カーネル自体はマシンの機種依存性が少なくなるように作られていますが、ブートストラップ処理はマシンに強く依存した処理になっています。

 

上述したLions本では、ブートストラップ処理について次のように書かれています。

これで、プロセッサのROMに永久に記憶されているブートストラッププログラムがスタートする。ブートストラップローダープログラムは（システムディスクのブロック#0から）大きなローダープログラムをロードし、この大きなローダープログラムが/unixと呼ばれるファイルを探し、メモリの低位部分にロードする。

 

これが間違いとは思いませんし、現状のWindowsやLinuxだって同様のブートストラップ処理をおこなっているはずですが、現状のパソコンのブートストラップ処理と同じイメージを持つと、PDP-11当時の状況を見誤ってしまう気がします。

調べてみたら、Web上で「PDP-11のブートストラップ」という記事を見つけました。Lions本ではあっさりと書かれている処理が詳細に書かれているので、細部がよくわかります。

しかもLions本で「プロセッサのROMに永久に記憶」されていると書かれている「ROM」というものが、現状のパソコンのような半導体メモリをイメージしてしまうと、当時の状況を反映していないと思われます。これもWeb上の記事「Diode Matrix」を見ると、具体的にわかります。

 

またYouTubeでも「PiDP-11 - Manually toggling the bootloader for RT-11」や「Booting v6 Unix on a PDP-11/34」などを視れば、PDP-11で起動する手順がどのようなものだったのかが、よくわかります。