amd64移植におけるテーブル構造

東大版Palo Alto Tiny BASICをWSL2のUbuntu環境に移植しようと作業を進めています。BASICというのは、プログラム編集機能とインタプリタ機能が統合されています。オリジナル版は、SDK-80のシリアルポートにASR-33が接続された環境を想定していますから、プログラム編集機能といっても簡単なものです。amd64移植にあたり、機能的な拡張は全くおこなわない方針です。今日の水準から見れば貧弱そのものですが、移植する過程を学ぶのが主目的なので、本格的な機能は求めないことにします。

 

ひとまず編集機能はできあがりましたので、次はインタプリタ機能です。ここで問題となるのが、入力された文字列を認識して、対応する機能に分岐するロジックです。オリジナル版は、i8080というものに強く依存しているので、そのままamd64に対応させるのはよくないと考えています。基本的な構造は「CASEマクロ」にあります。

CASE   .macro STR,ADRS
       DB    &STR
       DB    (&ADRS SHR 8)+80H
       DB    &ADRS AND 0FFH
       .endm

このマクロを使って次のようなテーブルが作られます。例えば「LIST」という文字列だったら、LISTルーチンに飛ぶことになります。

CMDKW: CASE  'LIST',LIST
       CASE  'RUN',RUN
       CASE  'NEW',NEW
STMKW: CASE  'NEXT',NEXT

ここで注目すべきは、文字列の終端を認識するために、ルーチンのアドレスのMSBをONにしている点です。しかもi8080はリトルエンディアンなのに、ビッグエンディアンのように逆転させて配置しています。これはi8080の事だけを考えて組み立てるのであれば、秀逸なアイディアと言えます。しかしamd64に移植しようとするなら、あまりよろしくありません。しかも、amd64への移植が済んだら、他の環境にも移植したいと考えているので、なおさらです。

 

どうしたらよいか、これから検討します。Geminiに相談してみようと思います。 

 

sudo、doas、opendoas

最近購入したLet's note CF-SV8RDCVSにFreeBSD 15.1-RELEASEをインストールしました。個人で使用するだけですが、昨今のセキュリティ事情を踏まえると、いい加減な運用は避けた方が良いだろうと思います。rootの他に一般ユーザを作るのは当然ですが、その一般ユーザをwheelグループに入れるか否かは慎重に考える必要があります。一般ユーザがWheelグループに入れば「su」でrootになれますが、セキュリティ的には注意が必要です。 

 

最近はrootアカウントを使わず、「sudo」を使うのが一般的です。しかし「sudo」は、多機能すぎて肥大化していることが問題視されており、代替としてOpenBSD由来の「doas」があります。

 

FreeBSDにもdoasをインストールしようと思いましたが、doasの他にopendoasが存在することに気づきました。何が違うのかと言うと、「persist」オプションがあることです。これがあれば、sudoのように、またはOpenBSD上のdoasのように、いったん認証に成功したら一定時間は認証を省略できるようになります。

 

FreeBSDに限りませんが、一般ユーザが「su」で直接rootになれるのは、セキュリティ的には避け、sudoやdoasを用いるようにした方が良さそうです。 

FreeBSD 15.1-RELEASEの無線LAN設定

Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールしました。インストール中は有線でネットワークに繋ぎました。今後デスクトップ環境を入れていくつもりですが、その前に無線LANの設定を済ませておこうと思います。

 

『FreeBSD Handbook』では「7.4. Wireless Networks」として設定手順が説明されています。それに従って作業すると、次のようになります。

1. 接続先となるSSIDとPSKを入手しておきます。
2. 「/etc/wpa_supplicant.conf」を作成します。ひな形が示されているので、そこに入手したSSIDなどの情報を入れます。
3. 「/etc/rc.conf」に無線LANの情報を追加します。これも示された手順のとおりです。ただし設定ファイルを直接編集せずに、「sysrc」というコマンドを使っているのを初めて知りました。
4. 以上で設定が済んだので「service netif restart」とすれば、繋がるはずです。

 

ところが繋がりませんでした。これまではdynabook SS SX/15AのNetBSD/i386で接続できていたので、何が違うのか確認してみました。私の自宅ではステルスSSIDとしていたため、「network」の設定の中に「scan_ssid=1」を入れておく必要があるようです。これを追加したら、繋がるようになりました。しかしGeminiと相談した結果、ステルスSSIDはセキュリティ的に望ましくないという意見だったので、ステルスSSIDを止めて公開設定に変更しました。そうなると「scan_ssid=1」は不要です。

 

さらに「/etc/rc.conf」に「create_args_wlan0="country JP regdomain JAPAN"」という設定も追加しました。『FreeBSD Handbook』が英語版であるからなのか、日本特有の設定については記述がありません。これもまたGeminiとの相談の結果ですが、この設定は必須とのことでしたので、追加しました。

 

以上で無線LANが使えるようになりました。若干トラブルがありましたが、とても簡単でした。 

「FreeBSD-15.1-RELEASE-amd64-memstick.img」に入っているのは「PkgBase」

最近入手したLet's note CF-SV8 RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールしてみました。公式サイトから「FreeBSD-15.1-RELEASE-amd64-memstick.img」を入手し、RufusでUSBメモリに書き込みます。ハンドブックの「2.3.1. Prepare the Installation Media」に「-memstick.img: This file contains all of the files needed to install FreeBSD, its source, and the Ports Collection. 」と書かれているように、インストールに必要なファイルは全て入っています。つまりインストール中にネットワークアクセスは必要ありません。もし「-bootonly.iso」や「-mini-memstick.img」を使うと、必要なファイルをネットワーク越しに取得することになります。

 

インストール中の選択肢に「Select Installation Type」があります。これまでのFreeBSDで使われてきた「Distribution Sets」か、FreeBSD 16からデフォルトになると言われている「Packages (Tech Preview)」のどちらを使うか選ばなければなりません。PkgBaseがデフォルトになるのは次のバージョンからですので、今回は「Distribution Sets」でインストールしようと考えました。ところが、ネットワークへのアクセスは不要なはずなのに、ネットワークからファイルを取得しようとするのです。

 

ネットワークに接続せずにインストールを完了させたかったので、ネットワークへのアクセスが発生すると困ります。ここで気づきましたが、「-memstick.img」にはインストールに必要なファイルが全て入っているとは言っても、「Distribution Sets」と「Packages」の双方が入っているわけではないようです。入っているのは「Packages」の方だけで、「Distribution Sets」を選んでしまうと、ネットワーク越しに取得しにいくのでしょう。

 

案の定、「Packages (Tech Preview)」を選択したら、ネットワークへのアクセスする事なく、インストールが完了しました。インストール完了後に改めて起動させたところ、Let's note CF-SV8RDCVSでFreeBSD/amd64 15.1-RELEASEが無事に起動しました。 

「LBUF EQU VTOP+0037H」が0036Hではない謎

共立出版の『マイクロコンピュータのプログラミング』に掲載された東大版Palo Alto Tiny BASICについて調査しています。アセンブラで書かれたプログラムの先頭では、以下のようにメモリ配置が定義されています。

;  MEMORY MAP
ITOP   EQU   0000H
ISIZE  EQU   0800H
LTOP   EQU   1000H
VTOP   EQU   5000H
LBUF   EQU   VTOP+0037H        ;0037H?
LBFSZ  EQU   80
MSTK   EQU   LBUF+LBFSZ
TMSTK  EQU   MSTK+30        ;30?
STACK  EQU   6000H

 

本文では「図3 メモリマップ」として説明されています。VTOPとLBUFの間は「変数エリア」になっています。Tiny BASICですから、プログラムで使える変数は「A」～「Z」と配列「@」の27個に制限されています。また変数に格納できるのは16ビット整数だけです。つまり27種類×2バイト=54バイトあれば良い計算になります。これは、16進数ならば0036Hです。

 

ところがLBUFは、「VTOP+0037H」として定義されています。何故「0036H」ではないのでしょうか。プログラムを解析してみると、ロジックの都合ではないかと思われます。

 

LBUFからLBFSZ（=80）は、「行バッファ」です。キー入力される文字列を格納する領域です。この処理は、次のようになっています。

EDITR: MVI   A,'>'
       CALL  GETL
       PUSH  D
       LXI   D,LBUF
       CALL  GINT
       CALL  SKPBL
       MOV   A,H
       ORA   L
       POP   B
       JZ    KWCPR
INSRT: DCX   D
       MOV   A,H
       STAX  D
       DCX   D
       MOV   A,L
       STAX  D

 

GETLルーチンで入力された文字列は、先頭に数字があるかをGINTルーチンで判断しています。つまり「10 PRINT A」のように入力すると、先頭の数字をバイナリに変換し、数字文字列と置き換えます。また空白も取り除くので、入力された行は、「<0A><00>PRINT A」としてメモリ上に置かれることになります。数字文字列をバイナリに変換した結果を格納しているのが、INSRTで始まる処理です。

 

このようなロジックになっているので、現代的な書き方であるインデントを使用としても、全て取り除かれてしまいます。「10         PRINT A」のように空白を入れても、内部構造は「<0A><00>PRINT A」になります。さらに当時の厳しいメモリ事情の為なのか、Tiny Trekのプログラムでわかるように、意味がとおるなら空白文字を省くことができます。つまり「10PRINT A」としてもエラーではありません。

 

ここで考えなければならないのは、数字文字列をバイナリに変換して格納している点です。バイナリは16bitなので、2バイト必要です。数字文字列が「10」であったり、例え一桁であったとしても「1 PRINT A」のように空白が入っていれば、2文字あるので、16bitのバイナリを格納することができます。ところが「1PRINT A」のような記述を認めているので、数字文字列が1文字しかない場合、16bitのバイナリを格納するには領域が不足してしまうのです。プログラムでは例外処理がありません。どうしているかというと、LBUFの直前にある「変数エリア」に踏み込んでしまうのです。これが「0036H」ではなくて「0037H」になっている理由と思われます。

 

試しに「LBUF EQU VTOP+0036H」としてアセンブルしたプログラムで実験してみました。変数「Z」に何か値を代入しておいて、「1PRINT Z」を入力すると、変数「Z」の値が変わってしまいました。やはり変数「Z」の領域を壊してしまうのです。

 

こうならないようにするため、あえて「LBUF EQU VTOP+0037H」として1バイト分ずらして領域を確保しているのですが、極めて技巧的です。 

東大版Palo Alto Tiny BASICのGETIルーチンをamd64に移植するとLEA命令を使う

SDK-80のシリアルポートにASR-33が接続された環境を想定している東大版Palo Alto Tiny BASICをWSL2Ubuntu環境に移植しています。Geminiと相談しながら作業しています。BASICというものは、編集環境と実行環境が統合されているところに真髄があるのですが、まず編集環境の方から移植を進めています。数字文字列を2進数に変換するために「GETI」というルーチンがあります。これをamd64にしてみます。

 

オリジナルは次のようになっています。

GINT:  LXI   H,0000H        ;GET INTEGER
       MOV   B,H
       CALL  SKPBL
GETI1: CPI   '0'
       RC                    ;RETURN INTEGER IN HL
       CPI   '9'+1
       RNC
       MVI   A,0F0H
       ANA   H                ;IF INTEGER＞#0FFF ERHOW
       JNZ   ERHOW
       INR   B
       PUSH  B
       MOV   B,H            ;HL HL+10
       MOV   C,L
       DAD   H
       DAD   H
       DAD   B
       DAD   H
       LDAX  D                ;HL HL+(DE)&#0F
       INX   D
       ANI   0FH
       ADD   L
       MOV   L,A
       MVI   A,00H
       ADC   H
       MOV   H,A
       POP   B
       LDAX  D
       JM    ERHOW
       JMP   GETI1

 

Geminiの指導を受けながらamd64に移植したら、次のようになりました。

.equ    GINT_DIGIT_MAX,        (NINE-ZERO)
.equ    GINT_MAX_BEFORE_X10,    0x0FFF
gint:    xor    eax,eax
    xor    ecx,ecx
    call    skpbl
geti1:    movzx    edx,byte ptr [rdi]
    sub    edx,ZERO
    cmp    edx,GINT_DIGIT_MAX
    ja    geti9
    cmp    ax,GINT_MAX_BEFORE_X10
    ja    erhow
    inc    cx
    # amd64の真骨頂: LEA命令による AX = (AX * 10) + DX
    lea    eax,[rax + rax*4]
    lea    eax,[rdx + rax*2]
    inc    rdi
    test    ax,ax
    js    erhow
    jmp    geti1
geti9:    ret

amd64と比べるのは卑怯かもしれませんが、i8080は命令が貧弱です。レジスタの内容を10倍するのも、簡単にはできません。一方amd64は、IMUL命令で簡単に10倍できるはずですが、Geminiが提示してきたのはLEA命令を使う方法でした。なぜIMUL命令を使わないでLEA命令なのかとGeminiに問うと、内部処理の都合上この方が速いのだそうです。ここがボトルネックという訳ではないので、微妙に速くなっても全体としては速さを意識できないと思います。しかし、いかにもamd64チューニングされているという感じにはなりました。 

セキュアブートとUSB起動

Let's note CF-SV8RDCVSを中古で購入しました。Windows11が入っていたので、HWiNFOやCrystalDiskInfoなどで、情報を収集しておきます。また自宅の無線LANに接続してみて、問題ないことを確認しました。これで、ひととおり初期状態の確認が済んだので、Windows11とはお別れして、BSD系OSに入れ換えてみようと思います。

 

これまで使っていたdynabook SS SX/15AではNetBSD/i386を使っていました。せっかくなので各BSDを試してみて、気に入ったものを選ぼうと思います。まずは、FreeBSD/amd64 15.1を試してみます。公式サイトからUSBのためのIMGファイルを取得し、RufusでUSBメモリに書き込みます。これを使って起動しようとしたら、ちょっと問題が発生しました。

 

dynabookの頃には存在しませんでしたが、最近は「セキュアブート」というものがあります。これが有効になっていると、FreeBSDのインストーラが起動しません。しかもLet's noteは、USBメディアの起動順位が低いので、ただ挿しただけでは起動してくれません。

 

「セキュアブート」を無効にするには、電源投入時にF2キーを押し、設定画面に入ります。「セキュアブート」の項目を「無効」に設定して、保存すれば完了です。

 

USBメディアの起動順位を上げるのも、同様に設定画面で出来そうに見えます。しかし設定しても、USBメディアを抜くと優先順位が最下位に戻ってしまうようです。これはセキュリティ上の考慮なのかしれません。USBメディアから勝手に起動できてしまうと、不審者が勝手に操作できてしまうのを避けようとしているのかもしれません。理由は定かではありませんが、できないものは仕方ないので、USBから起動させたい場合は、いちいち設定画面に入ることになりそうです。 

Let's note CF-SV8RDCVSを購入

20年ほど前に購入したdynabook SS SX/15Aは、当初Windows Vistaがインストールされていました。10年ほど前にサポート終了したので、NetBSD/i386に入れ換えて使ってきました。しかし近年、ソフトウェアの32ビット対応が無くなりつつあります。さらにハードウェア本体も劣化の傾向が見られ、電源を入れてても起動しなくなることが増えてきました。起動しなくても、揺すったり、叩いたりして、何度も電源投入を試みると起動します。いったん起動してしまえば、途中で落ちることはありません。ハードウェア的にも、ソフトウェア的にも、限界が迫ってきている気がするので、新しいPCを調達することにしました。

 

購入するのを決意したのは今春です。dynabook SS/SX15Aの後継ですから、いわゆるサブノートが候補です。Microsoft Windowsがインストールされていたとしても、それは捨てて、伝統か新興のBSDに入れ換えるのが、当初からの方向性でした。新品を購入することは考えず、中古を探そうと考えていました。ただし中古PCを店頭で探すにも、秋葉原に気軽に行ける場所に住んでいる訳ではないため、通販かオークションなどを使うしかありません。いろいろな販売店やサイトを探せば、何かしら中古サブノートPCは見つかりますが、新品を買うのと違って、中古は一期一会ですから、石橋を叩いて渡る気持ちで探しました。

 

数か月前に、通販で購入可能なショップからひとつに絞り込み、さらに機種もLet's noteに決めて、定期的に出品と値段を確認するようになりました。この時点ではLet's noteには決めたものの、CF-SV7にするか、CF-SV8かCF-SV9にするか、まだ流動的でした。出品や値段をウォッチしつつ、中古で値段が安いとは言ってもCF-SV7では性能が劣り、CF-SV9は値段が多少上がってしまうので、最終的に機種はCF-SV8に決めました。

 

ショップも決まり、機種も決まったとしても、Let's note CF-SV8は、様々な状態の中古が出品されていて、それを絞り込むのがまた一苦労です。絞り込むための条件として、次のようにしました。

1. 中古の状態が悪いことが明記されているものは、候補から外す。
2. 画面の状態に問題があることが明記されているものは、候補から外す。
3. SSDが新品に換装されているものを、候補とする。
4. ACアダプタは、純正でなくても構いませんが、純正の方を優先する。
5. 使用時間は、5,000時間以下とする。 

 

このような条件で、先月までショップをウォッチし続け、今月に入り実際に購入するため最終確認をしたところ、候補が数件まで絞り込まれました。今週頭に、条件に合う候補をひとつに絞り、注文し、今日到着したところです。

 

Windows11 Professionalがインストールされていましたが、これは捨てて、BSDに入れ換えるつもりです。その前に、HWiNFOやCrystalDiskInfoなどを使って、ハードウェアの状態を記録しておきました。BSD系をインストールし、ハードウェア状態を知る必要が出てきた時には役立つでしょう。PC本体は中古ですが、SSDは新品に換装されていました。またACアダプタも純正でした。自前で換装したりすることは可能ですが、その手間もお金もかけずにすみました。さらにPC本体は、若干擦り傷はあるものの、基本的に綺麗で、ディスプレイもキーボードも新品同様です。またBIOSで使用時間を確認すると3,000時間でした。送料がかかりましたが、値段も安かったので、お買い得でした。

 

次は、どのBSDにするか決める必要があります。dynabook SS/SX15Aの流れを引き継いでNetBSD/amd64でも構わないのですが、FreeBSDやOpenBSDにするか、DragonFly BSDやNomadBSDにするとか、helloSystemやravynOSでも面白いかもしれません。いろいろインストールしてみて、決めていくつもりです。 

東大版Palo Alto Tiny BASICをamd64環境に移植するための入力ルーチン

東大版Palo Alto Tiny BASICをamd64環境に移植してみるため、出力ルーチンが出来たので、引き続き入力ルーチンも書いてみました。WSL2のUbuntuを使っていますが、端末をRAWモードに設定する必要があります。プログラムを動かす前にsttyで設定を変えておくことにして、プログラム内部ではロジックを組みません。

 

オリジナルの入力ルーチンは次のようになっています。

GET:   IN    IFLG
       NOP
       ANI   IMSK
       RZ
       IN    ITTY
       ANI   7FH
       CPI   0FH
       JNZ   TTYI2
       LDA   OMASK
       CMA
       STA   OMASK
       JMP   GET
TTYI2: CPI   03H
       JZ    START
       RET

Geminiに教えてもらいながら、入力ルーチンを書いてみました。動作確認には、既にできている出力ルーチンを使いました。

# as get.s -o get.o
# ld get.o -o get
# stty raw -echo ; ./get ; stty sane
.intel_syntax noprefix
.global _start

.equ    CTRL_C,        0x03
.equ    CTRL_O,        0x0F
.equ    CR,        0x0D
.equ    LF,        0x0A
.equ    SYS_READ,    0
.equ    SYS_WRITE,    1
.equ    SYS_IOCTL,    16
.equ    STDIN,        0
.equ    STDOUT,        1

.equ    TC_MAGIC,    'T'
.equ    FIONREAD_CMD,    27
.equ    FIONREAD,    (TC_MAGIC << 8) | FIONREAD_CMD

.equ    OMASK_TOGGLE,    0x01

_start:    call    get
    call    put
    jmp    _start
    
done:
    # プログラム終了 (sys_exit = 60)
    mov rax, 60         # システムコール番号 (sys_exit)
    xor rdi, rdi        # 第1引数: 終了ステータスコード (0)
    syscall             # Linuxカーネル呼び出し

put:    cmp    byte ptr [rip+omask],0
    jne    ttyo0
    ret
ttyo0:    cmp    al,CR
    jne    ttyo1

    call    ttyo1
    push    rax
    mov    al,LF
    call    ttyo1
    pop    rax
    ret

ttyo1:    push    rax
    mov    rax,SYS_WRITE
    mov    rdi,STDOUT
    lea    rsi,[rsp]
    mov    rdx,1
    syscall
    pop    rax
    ret

get:    push    rbp
    mov    rbp,rsp
    sub    rsp,16

    mov    rax,SYS_IOCTL
    mov    rdi,STDIN
    mov    rsi,FIONREAD
    lea    rdx,[rbp-4]
    syscall
    test    eax,eax
    js    ttyi8
    cmp    dword ptr [rbp-4],0
    jz    ttyi8

ttyi1:    mov    rax,SYS_READ
    mov    rdi,STDIN
    lea    rsi,[rbp-5]
    mov    rdx,1
    syscall
    cmp    rax,1
    jl    ttyi8

    movzx    eax,byte ptr [rbp-5]
    cmp    al,CTRL_O
    jne    ttyi2

    xor    byte ptr [rip+omask],OMASK_TOGGLE
    mov    rsp,rbp
    pop    rbp
    jmp    get

ttyi2:    cmp    al,CTRL_C
    je    done
    jmp    ttyi9
ttyi8:    xor    eax,eax
ttyi9:    mov    rsp,rbp
    pop    rbp
    ret

.data
omask:    .byte 1        # 出力フラグ（0: 出力抑制 / 0以外: 出力許可）

東大版Palo Alto Tiny BASICをamd64環境に移植するための出力ルーチン

東大版Palo Alto Tiny BASICをamd64環境に移植してみようと思います。基本方針としては、オリジナル版の仕様を再現することに主眼をおき、C言語で書き直すとか、整数16ビットを拡張するなどはおこなわないつもりです。プログラムのデータ構造やサブルーチン構成も変更しないつもりですが、i8080とamd64の違いでやむを得ない場合は、変更します。

 

またオリジナル版は、SDK-80のシリアルポートにASR-33が接続された環境を想定していると思われます。amd64環境としては、WSL2のUbuntuとかFreeBSD/amd64などを考えていて、少なくともOSの管理下で動作するようにします。まずは入出力ルーチンを移植してみようと思います。

 

オリジナル版の出力ルーチンは、次のようになっています。

PUT:   PUSH  PSW                ;PUT CHARACTER IN A REG
       LDA   OMASK
       ORA   A
       JNZ   TTYO0
       POP   PSW
       RET
TTYO0: IN    OFLG
       ANI   OMSK
       JZ    TTYO0
       POP   PSW
       OUT   OTTY
       CPI   0DH
       RNZ
       MVI   A,0AH
       CALL  PUT
       MVI   A,0DH
       RET

 Geminiの助けを借りながら、オリジナルと同じ動きになるような出力ルーチンを書いてみました。動作確認のため「Hello World」を出力させてみましたが、うまくいっているようです。

# as put.s -o put.o
# ld put.o -o put
# ./put
.intel_syntax noprefix
.global _start

CR        =    0x0D
LF        =    0x0A
SYS_WRITE    =    1
STDOUT        =    1

_start: lea    rbx,[rip+msg]
loop:    mov    al,[rbx]
    cmp    al,0
    je    done
    call    put
    inc    rbx
    jmp    loop
    
done:
    # プログラム終了 (sys_exit = 60)
    mov rax, 60         # システムコール番号 (sys_exit)
    xor rdi, rdi        # 第1引数: 終了ステータスコード (0)
    syscall             # Linuxカーネル呼び出し

put:    cmp    byte ptr [rip+omask],0
    jne    ttyo0
    ret
ttyo0:    cmp    al,CR
    jne    ttyo1

    call    ttyo1
    push    rax
    mov    al,LF
    call    ttyo1
    pop    rax
    ret

ttyo1:    push    rax
    mov    rax,SYS_WRITE
    mov    rdi,STDOUT
    lea    rsi,[rsp]
    mov    rdx,1
    syscall
    pop    rax
    ret
    
.data
omask:    .byte 1        # 出力フラグ（0: 出力抑制 / 0以外: 出力許可）

.section .rodata
msg:    .asciz    "Hello World\r"

東大版Palo Alto Tiny BASICをamd64環境に移植できるだろうか

simhのAltair 8800シミュレータ上で東大版Palo Alto Tiny BASICが動作し、Tiny Trekも動きました。ひとまず区切りがつきましたが、これを他の環境に移植してみても面白いのではないかという気がします。他の環境というのは、具体的にはつぎのようなものを思い描いています。

• amd64環境として、WSL2のUbuntuかFreeBSD/amd64
• PDP-11/40のUNIX v6
• OpenVMS vax
• OpenVMS alpha 

 

いずれの環境であっても、アセンブラで書いてみようと思います。オリジナルはOSを意識しておらず、シリアルポートの先にASR-33が接続されているのを想定しています。しかし入出力はOSのが提供する機能を利用しようと思います。それでも、行編集のような便利な機能はつかわず、ASR-33並みの原始的な行入力にしておこうと思います。

 

またオリジナルの8080版では、整数16ビットを想定しています。amd64なら整数32ビットにすることもできるかもしれませんが、そういうTiny BASICの仕様を拡張するようなことはしない方針です。できるだけオリジナルと同じ仕様にしておきつつ、動作環境が8080ではないという方向で考えています。

 

データ構造やサブルーチンなども、オリジナルの東大版Palo Alto Tiny BASICと同じようにしようと考えています。発表当時の時代背景を踏まえて、BASICソースは、メモリ上に単純に置かれています。ソフトウェア工学的には、メモリ上の持ち方を変えればスマートかもしれませんが、そういうこともしないつもりです。所詮はTiny BASICなので、大規模と言ってもTiny Trekのような高々200行弱のプログラムで十分です。何千行もあるようなプログラムになることは考えず、最適化されたアルゴリズムを採用しません。

 

いろいろな環境を考えているとはいっても、いきなり全てはできません。まずはamd64環境から始めようと思います。 

東大版Palo Alto Tiny BASICでTiny Trekが動いたけど、遊び方が分からない

simhのAltair 8800シミュレータを使って東大版Palo Alto Tiny BASICが動いています。またAutoHotkeyを使って、長いBASICソースを入力させることが出来るようになりました。そしてTiny Trekを動かしてみたところ、あっさり動作しました。それは嬉しいことなのですが、遊び方が分かりません。

>RUN
DO YOU WANT A DIFFICULT GAME?  (Y OR N):N
STARDATE 3200:  YOUR MISSION IS TO DESTROY 8 KLINGONS IN 30 STARDATES.
THERE ARE 2 STARBASES.
ENTERPRISE IN Q-65 S-83
CAPTAIN:G
ENTERPRISE IN Q-65 S-83
COMPUTER DISPLAY OF GALAXY MAP

1:   0   0   0   0   0   0   0   0

2:   0   0   0   0   0   0   0   0

3:   0   0   0   0   0   0   0   0

4:   0   0   0   0   0   0   0   0

5:   0   0   0   0   0   0   0   0

6:   0   0   0   0   0   0   0   0

7:   0   0   0   0   0   0   0   0

8:   0   0   0   0   0   0   0   0
    ..  ..  ..  ..  ..  ..  ..  ..
     1   2   3   4   5   6   7   8

CAPTAIN:R
STATUS REPORT:
STARDATE      3200
TIME LEFT     30
CONDITION     GREEN
POSITION      Q-65 S-83
ENERGY        4000
TORPEDOES     10
KLINGONS LEFT  8
STARBASES     2
CAPTAIN: 

クリップボードの限界とAutoHotkey

simh上のAltair 8800シミュレータ上で東大版Palo Alto Tiny BASICが動作するようになりました。「Hello World」程度の簡単なプログラムを動かすなら何とも思いませんが、Tiny Trekのような（比較すれば）大きなプログラムを動かそうとすると、いちいちプログラムを入力するのは大変です。そもそもTiny BASICにはsaveやloadコマンドが存在しません。

 

本来のPalo Alto Tiny BASICでは、ASR-33の紙テープを使って、事前に作成済みの紙テープを使うことで、大きなプログラムを動かすことができたようです。simh上のAltair 8800シミュレータでは、紙テープのためのPTR/PTPデバイスは備えられていますが、本家も東大版も対応していません。対応できるように改造するという方法は考えられますが、まずは別の方法で対処しようと思います。

 

まず考えたのはクリップボードを利用する方法です。プログラムを事前にクリップボードに入れておけば、Altair 8800シミュレータ上で動作中の東大版Palo Alto Tiny BASICにクリップボードからコピーすれば、うまくいくと思いました。ちょっと試してみたところ、うまくいくようです。ところが、Tiny Trekのような大きなプログラムでは、クリップボードからのコピーが早すぎて、途中で文字の取りこぼしが発生してしまいました。

 

解決策を探していたら、AutoHotkeyというものが使えそうという感触を得ました。ちょっとしたスクリプトを作成することで、指定したファイルの内容を、あたかもキー入力したかのように、アプリケーションに送ることができるようです。以下に示すようなスクリプトをGeminiに作ってもらいました。試行してみたところ、うまくいったようです。

 

 #Requires AutoHotkey v2.0

waitMs := 1000
selectedFile := FileSelect(16, A_MyDocuments . "\PaloAltoTinyBASIC\Altair8800", , "BASファイル (*.bas)")
if (selectedFile == "")
    return

try {
    Loop read, selectedFile, "UTF-8"
    {
        currentLine := A_LoopReadLine
        SendText(currentLine)
        Send("{Enter}")
        Sleep(waitMs)
    }
} catch as err {
    MsgBox("処理中にエラーが発生しました: " . err.Message, "エラー", "Icon!")
}

Palo ALto Tiny BASICとTiny Trek

Palo Alto Tiny BASICを開発したLi-Chen Wangは、Tiny Trekも発表しています。Tiny BASICが流行った当時、なぜかスタートレックのゲームも流行していました。 Tiny Trekは、People's Computer Company Jul. 1976、Vol. 5、No.1に掲載されています。Tiny BASICで動作するTiny Trekだからなのか、とれも短いプログラムです。

 

印刷されているものを参照して電子ファイル化しようと思いましたが、文字が潰れていて読みにくいです。頑張る気力がなかったので、ネットを調べてみたら、テキスト化されたファイルを見つけました。これがあれば、自分で文字を起こす必要がありません。

 

ただし、PCCに掲載されたものとは、若干異なっていました。Palo Alto Tiny BASICでは「PRINT」を「P.」と省略できるようなのですが、それが全て「PR.」に変更されています。どのような理由で変更したのかは不明です。

 

また、BASICは入力されたプログラムをメモリ上に置くので、それを極限まで切り詰めるためか、空白を入れるのを避けているようです。例えば「205 PR.;F.I=U-1TOU+1;F.J=V-1TOV+1;M=8*I+J-9,A=0」のようになっています。もし省略形を用いず、空白を入れるなら、「205 PRINT;FOR I=U-1 TO U+1;FOR J=V-1 TO V+1;M=8*I+J-9,A=0」のようになるでしょう。他にも「IFH-K>9PR.」のような箇所もあり、メモリが少なかった当時の努力を感じます。

IMEで「いま」を現在時刻に変換できるらしい

「日本語力ソフトで郵便番号から住所入力、Googleは大口事業所個別番号対応」という記事を読んだら、「例えば、「いま」と入力すると、現在時刻が変換候補に現れる（図1）。」と書かれていました。「いま」以外にも、「あす」や「ことし」なども受け付けるようです。では、受け付けてくれる候補は何があるのか、一覧はないのでしょうか。

 

Geminiに相談したら、気軽に「ここにありますよ」と答えてくれたのですが、そんなリンクはありませんでした。こういう雑な反応は、Geminiらしいところです。

 

受け付けられる文字列が分かっているなら、入力時に意識しようとも思います。しかし何が受け付けられるのかわからないのであれば、「ことし」が「2026年」に変換される機能があったとして、最初から「2026年」と入力するだろうと思います。

 

 

再生鉄

ネットを見ていたら「自動車に「再生鉄」、トヨタも採用　東京製鉄トップが語る変化の兆し」という新聞記事が目に入りました。スクラップを再生した鉄を使用することでリサイクルを目指すようです。

 

どうしたことか「再生鉄」という文字を見たら、鉄道ファンの新しいジャンルかと勘違いしました。近年は、鉄道ファンという表現をすることは少なくなり、「乗り鉄」とか「撮り鉄」などと呼ばれます。それだけではなく、「座席鉄」や「顔鉄」などというニッチな表現もあるようです。「あなたは、何鉄ですか？」と問われることもあるらしいのですが、その質問自体がナンセンスというか、何故それほどまでに細分化したがるのか謎です。元々は「鉄道ファン」と呼ばれた愛好家は、「鉄道マニア」とも呼ばれ、「鉄道オタク」とも「鉄ちゃん」とも呼ばれましたが、この頃は「鉄道全般の愛好家」という意味であって、特定の一部を強調することはありませんでした。写真も撮るし、乗車して旅行もするし、模型も作るという、何でも屋でした。 

 

閑話休題。あまりにも細分化され過ぎた表現を見過ぎたせいか、「再生鉄」を見たとき、「おっ、新しい鉄道ファンのジャンルか？でも「再生」の鉄って何？」と、ズレた疑問を抱いてしまいました。 

Squad Leader CLASSIC Revised Rules Book Version 1.2

1980年代にAvalon Hillから発売された「Squad Leader」というゲームがありました。とても人気があり、「Cross of Iron」、「Crescendo of Doom」、「GI: Anvil of Victory」という拡張版も発売されました。ところが、当初のルールが拡張版で追加変更され、さらに追加されたはずのルールが後続した拡張版で変更され、複雑怪奇なルール体系になってしまいました。

この問題はAH側でも意識しており、ゲーム全体を仕切り直した「Advanced Squad Leader」が登場しました。SLとASLは、似ているとは言っても、ゲーム体系として別物です。本来のSquad Leaderのルールは「増築を重ねた旧い旅館」のようになってしまっていて、とても見通しが悪いです。

 

ルール体系を整理したいと考えている人は少なくないようで、「Squad Leader Rules (Includes All Gamettes)」という存在を知りました。自分で整理するよりも、この成果を使わせてもらう方が、何かと有難いと思っています。 

「還暦間際のオッサンが8Bit時代に戻って不完全燃焼をやり直す話」とフォレストガンプ

「還暦間際のオッサンが8Bit時代に戻って不完全燃焼をやり直す話」という小説がネットで連載されているのを偶然知りました。小説なので、当時の時代の状況を正確に反映しているわけではなく、天才的な(?)主人公が、周囲の人間を巻き込み（翻弄し）ながら、テクニカルな成果を次々にあげていくという内容です。とても楽しく読んでいます。

 

Z80が全盛だった頃からAT互換機が出現する時期のパソコンに、次々の（当時としては）新機能を実装する主人公に周囲の人間が驚き呆れるのです。ふと思ったのですが、これはトム・ハンクス主演の映画「フォレストガンプ」に似ているのではないでしょうか。

 

「フォレストガンプ」は、第二次大戦後におけるアメリカの歴史的な出来事（例えば公民権運動とかベトナム戦争）に、主人公のフォレストガンプが常に登場するストーリ仕立てになっています。フォレストガンプが歴史的な出来事に一回くらい遭遇するだけならまだしも、いつでもどこでも、常に顔を出すのは、娯楽映画だからこそ許される展開です。

 

コンピュータ技術に爆走する少年と、米国史に立ち会うフォレストガンプは、話の展開が似ていると思うのです。 

紙テープとクリップボード

DDJで発表されたPalo Alto Tiny BASICは、ASR-33のようなテレタイプを入出力装置として想定しています。その派生である東大版Palo Alto Tiny BASICをsimhのAltair 8800シミュレータで動作するようになりました。さて、Tiny BASICが一世を風靡した頃には「Hello World」というプログラムを書いてみるという習慣はありませんでした。テスト的に簡単なプログラムを入力し、実行できるようにはなりましたが、Palo Alto Tiny BASICには、saveやloadというコマンドはありません。しかし、入力したプログラムを保存できないのは、困ります。さらに、過去に作成したプログラムを読み込めないのは、もっと困ります。

 

ここで当時の状況を思い起こすと、ASR-33のようなテレタイプには、紙テープのリーダーやパンチャーがついていたという事実です。ASR-33の操作方法は分かりませんが、あたかもキーボードから入力しているかのように紙テープを入力装置としたり、あたかも印字するかのように紙テープを出力したりすることが出来たようです。つまりPalo Alto Tiny BASICから見ると、入力がキーボードなのか紙テープなのか区別できませんし、出力がプリンタなのか紙テープなのか区別できません。こういう機構があれば、Palo Alto Tiny BASICにsaveやloadコマンドがなくても、紙テープを記録メディアとして利用できることになります。

 

それでは、Altair 8800シミュレータでPalo Alto Tiny BASICの場合、「紙テープ」の代替は何でしょうか。いろいろな手法が考えられるかもしれませんが、「クリップボード」が使えそうです。あらかじめエディタか何かで、プログラムを編集しておき、その全てをクリップボードにコピーしておきます。次にAltair 8800シミュレータで動作しているPalo Alto Tiny BASICにペーストすれば、いかにもキーボードから入力したかのように、プログラムが一気に入力される（はず）です。つまり現代のクリップボードは、当時の紙テープを再現していると言えるでしょう。

 

Palo Alto Tiny BASICが流行した当時は、何故かStar Trekゲームも流行していました。Palo Alto Tiny BASICを開発したLi-Chen Wangは、Tiny Trekも発表しています。Tinyなので130行ほどしかありませんが、ゲームを遊ぶたびに、いちいちキーボードから入力しなければならないのは嬉しくありません。当時は紙テープから一括入力したようですが、現代ならクリップボードの出番です。これで一括入力できるはずです。

PLANとSIMPLE

共立出版の『マイクロコンピュータのプログラミング』におさめられている「マイクロPLANのプロセッサ」という記事では、参考文献として雑誌「bit」の記事が参照されています。国立国会図書館のデジタル資料に雑誌「bit」があるので、確認してみました。

 

1974年8月号～12月号までは、PLAN言語の連載記事があります。ただしデジタル資料は館内限定公開と指定されているので、読みたければ国立国会図書館に行くしかありません。

1. ミニ言語PLAN（8月号）
2. 構文解析（9月号）
3. 記号の処理・宣言と定義の処理（10月号）
4. 目的プログラム（11月号）
5. 目的プログラムの生成（12月号）

 

1977年1月号～1978年3月号までは、SIMPLE言語の連載記事があります。雑誌「bit」は館内限定公開のデジタル資料です。しかし、この連載を単行本化した『やさしいコンパイラの作り方』（中西正和・大野義夫、共立出版、1980年）は、デジタル資料になっており、個人送信も可能として指定されているので、アカウントがあれば自宅でも読めます。 

Firefox 153では「ユーザーのコンピューター上のローカルファイルへのアクセス」の無効がデフォルトになっている。

Firefoxを更新して153にしたら「 File Backups - For TiddlyWiki」が動かなくなりました。何が原因なのか分からずに焦りましたが、「PSA: If you’re using Timimi with Firefox 153+ (or an equivalent fork)」という情報がありました。これは、Timimiというプラグインの場合ですが、対処方法は同じでした。

 

Firefox 153では、プラグインの管理メニューに「ユーザーのコンピューター上のローカルファイルへのアクセス」が 追加され、デフォルトでは「無効」になっています。これによりプラグインがバックアップできなくなってしまったようです。

 

この設定を「有効」としたら、問題は解決しました。 

東大版Palo Alto Tiny BASICのメモリマップ

共立出版の『マイクロコンピュータのプログラミング』に掲載されている「東大版Palo Alto Tiny BASIC」は、DDJに掲載されたオリジナルのPalo Alto Tiny BASICを拡張したものです。しかし記事に書かれているように、「Palo Alto版のオブジェクト・プログラムを、独自に逆アセンブル、変更を加えたもの」です。いろいろな変更が加えられていますが、メモリマップも違っているようです。

 

記事では「図3 メモリ・マップ」として開設されています。プログラム本体は、0000番地から始まるメモリに配置されていて、0786番地まで続くので約2Kバイトです。作業領域、BASICプログラム格納領域、スタックなどは、1000番地から1400番地までなので、たかだか1Kバイトです。

 

一方でDDJに掲載されているオリジナル Palo Alto Tiny BASICは、プログラム本体が、0000番地から074E番地までの約2Kバイトで、作業領域などが、0800番地から2000番地までの6Kバイトです。東大版に比べると、作業領域などに割り当てているサイズが大きく違います。

 

これらが発表された当時のハードウェア状況を考えれば、 メモリが1Kバイトしかないとしても、やむを得ないでしょう。しかし割り当てが少なすぎて、例えばStar Trekなどを動かすのは、おそらく無理でしょう。

 

SimHのAltair 8800シミュレータを使うなら、64Kバイトのフル実装するのも簡単なことです。そこまで大きく拡げないとしても、東大版Palo Alto Tiny BASICのソースプログラムで指定されている値を変更しておきたいと思います。

Firefox 153.0で「File Backup Utility For TiddlyWiki」が動作しない

TiddlyWikiをFirefoxで利用しています。2026年7月22日にFirefox 153.0がリリースされたのですが、アドオン「File Backup Utility For TiddlyWiki」が動かなくなりました。ブラウザがバージョンアップすることでアドオンが動かなくなるという事例があるようです。「File Backup Utility for TiddlyWiki」が今後動作しなくなるのか、対応版がリリースされるのか、現時点では情報がありません。

 

昔からFirefoxでTiddlyWikiを使ってきました。このアドオンも相当前から利用しています。ハノイの塔方式でバックアップしてくれるのも有難いですが、最も助かっているのは、TiddlyWikiでTiddlerの編集が終わると自動的に保存処理をしてくれるところです。

 

このアドオンを使い始めた頃は他に選択肢はありませんでした。しかし今は「timimi」もあります。状況によっては、アドオンを乗り換えるかもしれません。 

Altair 8800対応「東大版Palo Alto Tiny BASIC」が動いた

共立出版の『マイクロコンピュータのプログラミング』に掲載されている「東大版Palo Alto Tiny BASIC」をSimHのAltair 8800シミュレータで動くように変更を加えてみました。共立本に掲載されているプログラムの実行環境が不明ですが、SDK-80だろうと思います。本文にはテレタイプと書かれていますが、その入出力はi8251を使っています。一方で、Altair 8800では、シリアルインターフェイスはMC6850が使われています。

 

Altair 8800に対応させるには、i8251を意識している箇所を、MC6850に対応させる必要があります。具体的には、次のようにします。

1. 入出力データは、0FAHとなっているのを、011Hに変更します。 
2. ポーリングのために参照するレジスタは、0FBHとなっているのを、010に変更します。
3. i8251の「TxRDY」は、D0です。MC6850の「Transimit Data Register」は、D1です。このため、OMSKの定義を、001Hから002Hに変更します。
4. i8251の「RxRDY」は、D1です。MC6850の「Receive Data Register」は、D0です。このため、IMSKの定義を、002Hから001Hに変更します。

 

定義を変更するだけで、とりあえず動いてくれました。

Altair 8800 simulator V3.9-0
sim> load KYORITSU-ALTAIR8800.rom
4118 Bytes loaded.
sim> run

OK
>10 INPUT A,B
>20 PRINT #3,'A+B=',A+B,' A-B=',A-B,' A*B=',A*B,' A/B=',A/B
>30 STOP
>RUN
A:10
B:2
A+B= 12 A-B=  8 A*B= 20 A/B=  5

OK
>

 

 

SimH Altair 8800で「Hello World」

K&Rの『プログラミング言語C』以来、「Hello World」とは「最初の一歩」という意味を持つようになりました。SimHのAltair 8800シミュレータを使い、「Hello World」を出力するプログラムを動かしてみようと思います。ここで重視しておくのは、CP/MとかDOSのような実行環境を一切使わないということです。

 

まずプログラムはアセンブラで書きます。入出力は、Altair 8800のSIOポートを使います。「Hello World」という文字列の各文字をSIOポートに出力し、HALTするだけ、というプログラムです。Geminiに作成してもらいました。アセンブラはzasmです。オプションとして「-uw --asm8080」を指定しました。 アセンブルした結果は、Rawバイナリ形式のファイルになります。オプションを指定すれば、インテルHEX形式や、モトローラS形式にも出来るようです。

 

SimHのAltair 8800シミュレータを起動し、プロンプトが出たところで「load hello.rom」のようにして、Rawバイナリ形式のファイルを読み込みます。そして「go 0」したら、文字列「Hello World」が出力されました。文字出力できました。

 

さらに、文字入力も確認しておきます。文字入力ができることを確認するだけなので、数字キーをおしたら、その回数だけ「Hello World」を出力するプログラムとしました。これもGeminiに作ってもらいました。アセンブルし、実行する手順は、同じです。これもうまくいったので、文字入力も大丈夫です。

 

Altair 8800が想定している入出力装置は、ASR-33のようなものなので、とても原始的です。使いやすくはありません。当時の時代の息吹が感じられるとも言えるかもしれません。

共立版「東大版Palo Alto Tiny BASIC」のソースコード

「東大版Palo Alto Tiny BASIC」と呼ばれるものは、共立出版の『マイクロコンピュータのプログラミング』に掲載されているものと、雑誌アスキーに掲載されているものがあります。両者の違いを詳しく確認したわけではありませんが、ちょっと見ただけでも違いがあります。

 

共立版の方には何も情報がないのですが、アスキー版には「8080 MACRO ASSEMBLER, VER 2.0」という文字があり、また「FOR SDK-80 VERSION」とも書かれています。「東大版Palo Alto Tiny BASIC」を学ぶため、どちらを使うか迷うところです。共立版の方が内部構造の説明が詳しいので、共立版を使おうと思います。

 

ひとまず書籍に掲載されているソースコードを入力したファイルを作成しました。これをアセンブルしようと思いますが、Windows11で利用可能なzasmを使おうと考えています。アスキー版にある「8080 MACRO ASSEMBLER」というのが、どういうものなのか分かりませんが、共立版も同じなのでしょう。zasmを使うなら、変更しておく箇所があります。

1. 文字列をくくるのに「シングルクォート」が使われています。文字列中にシングルクォートが現れると、文字を重ねて対応するようですが、シングルクォートが多すぎて見にくいところがあるので、直そうと思います。
2. マクロの構文がzasmとは違うようなので、対処が必要です。
3. 「\」という文字が使われていますが、「$」のことのようなので、変更します。 

 

もう一つ考えておく必要があるのは、実行環境です。おそらくSDK-80を想定していると思われます。私は、SimHのAltair 8800エミュレータを使おうと考えています。文字入力や文字出力に関わる部分を変更する必要があるでしょう。

ケトル

薬缶とは呼ばずに、ケトルと呼ぶのは、なぜだろうかと思いますが、ドリップコーヒーを淹れるのに使われることが多いケトルが壊れたので買い替えました。いつ買ったのか覚えていませんが、30年くらい前なのかもしれません。握り手を本体に溶接してあるところが外れてしまいました。それ以外は何の問題もないので修理して使い続けたいと思いますが、どうしようもないので、買い替えることにしました。

 

下見したところ、ニトリでは1,790円、CAINZでは1,480円でした。微妙にデザインは違いますが、その違いに拘ることもないと思いました。最終的には値段で決め、CAINZの方を買いました。結局は薬缶ですから、コンロにかけてお湯になればよいだけです。

 

使ってみて気づきましたが、CAINZのケトルは、握り手の部分がプラスチック製です。一方のニトリの方は、木製のようです。大した違いではないかもしれませんが、コンロにかけるとプラスチック製の握り手は熱くなるのに気づきました。また握り手が短いような気もします。

 

もし次に買い替えることがあれば、ニトリの方にしようと思います。しかし当分買い替える必要はないでしょう。仮に買い替える時が来たとしても、ニトリにしろCAINZにしろ、違う商品になっているでしょう。 

Palo Alto Tiny BASICとRST N

Palo Alto Tiny BASICは、様々なテクニックを駆使してプログラムサイズを小さくしていると言われています。そのテクニックの一つが「RST N」を多用している事です。プログラム先頭には「ZERO PAGE SUBROUTINES」として、次のように書かれています。

THE 8080 INSTRUCTION SET LETS YOU HAVE 8  ROUTINES IN LOW MEMORY THAT MAY BE CALLED BY RST N. N BEGIN 0 THOUGH 7. THIS IS A ONE BYTE INSTRUCTION AND HAS THE SAME POWER AS THE THREE BYTE INSTRUCTION CALL LLHH.

 

インテルの8080は、RST 0からRST 7が実行されると、0000番地、0008番地・・・と固定されたアドレスに制御が移ります。普通にサブルーチンコールをCALL foobarすれば3バイトになるところを、RST Nなら1バイトなので、インテルがこのような使いかたを想定しているわけではないと思いますが、メモリの節約になります。その代償として、0000番地付近をPalo Alto Tiny BASICの管理下におく必要があります。Palo Alto Tiny BASICが登場した頃は、メモリマップを制約するOSのようなものが無く、自由だったので、このようなアプローチも許されました。

 

しかしメモリマップを変更することができなくなります。Palo Alto Tiny BASICでは、Version 2.0というのはプログラムのインストラクションをインテル互換に変更しただけですのでRST多用になっていますが、Version 3.0ではRST多用と決別したようです。また東大版はPalo Alto Tiny BASICの流れをくむことになっていますが、以下のように説明されており、RSTを使わないようになっています。

(v) システムやバッファをそれぞれのキットに合わせて任意のアドレスから始まるように変更することが容易である。（これは、筆者の変更による。） 

Microsoft Flight Simulator 2002において、ジョイスティック応答をキーボードでどのように操作するのだろうか

長年放置していたMicrosoft Flight Simulator 2002を今さらながら取り組んでいます。マイクロソフト的にはジョイスティックで操作して欲しいのかもしれませんが、所有していないので、キーボードを使うしかありません。ジョイスティックの操作が、どのようにキーボード操作にマッピングされているのか、付属していた文書類には書かれていません。

 

ジョイスティックを前後に動かすことは、キーボードなら「8」キーや「2」キーであるとは書かれていますが、それだけです。マイクロソフトのフライトシミュレータは、かなり精密にシミュレートしているとは言われますが、そうだとしてもパイロット資格を取得する目的で作られているわけではないですし、結局はゲーム性を重視しているはずです。

 

ジョイスティックを所有していませんが、噂で聞くところによると、ジョイスティックを前後に倒しても、手を離すと自動的に中立に復元するそうです。それは、キーボード操作では、実現されているのでしょうか。例えば、ジョイスティックを手前に倒し、その後で手を離したとすると、ジョイスティックは中立に戻ります。これと同じ状況を再現するには、キーボード操作では、どのようにしたらよいのでしょうか。

 

ここで問題になるのが、相反する情報があることです。ひとつは、「キーボード操作においては、勝手に中立に戻る」から、「2」キーを押すだけでよく、「2」キーから手を離せば（ジョイスティックが勝手に中立に戻るように）何もしなくてよいという情報です。もうひとつは「キーボード操作においては、ジョイスティックとは異なり、押したキーの方向に固定された状態になる」から、ジョイスティックを傾け続ける状態に相当するので、「5」キーを押さないと中立に戻らないという情報です。

 

さらによくわからないのは、ジョイスティックを少し傾けた場合と、最大限に傾けた場合とは、キーボード操作では、どのように変わってくるのかです。例えば「2」キーを押し続けたとすれば、それはジョイスティックを最大限に傾けた場合と等価だろうとは想像できます。もしジョイスティックを1.5cmくらい手前に引いたのと等価にしたいなら、キーボードをどのように操作すれば良いのでしょうか。「2」キーを0.5秒くらい押した後で離すだけで良いのでしょうか。それとも「2」キーを0.05秒くらい押して離すという行為を数回繰り返せば良いのでしょうか。

 

「難しく考えずに、やってみてうまくいけば、それでいいんだよ」という意見もあるでしょう。結局はゲームなので、それで良いのだと思います。キーボード操作に失敗すれば、失速して墜落するだけです。ゲームですから墜落しても生死につながりません。結局は「慣れるしかない」が答えなのかもしれません。

Googleマップのタイムラインで「乗馬」が何故必要なんだろう

Androidのスマホを利用しています。Googleマップのタイムラインを有効にしているので、移動の軌跡が記録されます。このアプリには、相当不満はありますが、目安になればよいという程度の認識なので、利用を続けています。最も大きな不満は、精度が酷すぎることで、Google謹製のアプリとは思えないほど悪いです。そこは我慢するとして、謎な仕様もあります。

 

賢いというべきなのか、ある場所から別の場所に移動すると、勝手に移動手段を認識して「徒歩」とか「電車」などとラベルをつけてくれます。もし移動手段を認識できないと「移動」となりますし、認識された移動手段が間違っている場合もありますので、修正が必要になります。修正すると言っても、予め用意されている選択肢から選ぶしかありません。「自転車」とか「バス」という選択肢は理解できます。「スケートボード」という選択肢もありますが、これを予め選択肢に用意しておく必要があるか疑問ですが、まあ良いとしましょう。しかし「水泳」とか「手こぎボート」とか、あろうことか「乗馬」などという選択肢も用意されているのですが、これは必要ですか。 

 

「乗馬」という選択肢を利用する人がいるかもしれませんが、何人いるんでしょうか。そういう選択肢を用意しておくくらいなら、もっと他に用意しておくべき選択肢があるのではないかと、しみじみと思います。 

東大版PALO ALTO TINY BASICのバリエーション

Palo Alto Tiny BASICは、DDJ Vol.1 No.5 (May, 1976)で発表されました。これに派生するのが東大版PALO ALTO TINY BASICです。しかしDDJに掲載されているソースプログラムを基にしているのではなく、オブジェクトを独自に逆アセンブルし、改良を加えたとのことです。

 

東大版が掲載されているのは、『マイクロコンピュータのプログラミング』（共立出版、昭和53年）と、「2K BASIC」（ASCII 1977年8月号初出、エンサイクロペディア・アスキー Vol.1再録） です。これらは、同じものなのでしょうか。全体を確認するのは大変ですが、先頭を見ただけでも違いがありました。

 

『マイクロコンピュータのプログラミング』に掲載されている方は、次のようになっています。

;

;

;  PALO ALTO TINY BASIC

;

;

; MEMORY MAP

ITOP EQU 0000H

ISIZE EQU 0800H

LTOP EQU 1000H

VTOP EQU 1300H

LBUF EQU VTOP+0037H

LBUFSZ EQU 80

MSTK EQU LBUF+LBFSZ

（以下略） 

一方ASCII掲載の方は、次のようになっています。

;

;

; PALO ALTO TINY BASIC

;

;

; FOR SDK-80 VERSION (1977/03/23,ONO)

;

STACK EQU 1400H

VTOP EQU 1300H

LBUF EQU 1337H

MSTK EQU 13A7H

（以下略） 

 

目につくのは、ASCII版には「FOR SDK-80 VERSION (1977/03/23,ONO)」があり、『マイクロコンピュータのプログラミング』版には無いことです。推測となりますが、ASCII版にある表記を、『マイクロコンピュータのプログラミング』版で削除したというのは考えにくいと思われます。『マイクロコンピュータのプログラミング』の出版が昭和53年（=1978年）ですが、原稿を書いていた時期は、その前でしょう。最初はリリース日付を入れていなかったものの、どこかのタイミングで入れるようになり、それがASCII掲載版になったのではないかと想像します。

 

上述した箇所だけではなく、プログラム本体を見ても、『マイクロコンピュータのプログラミング』版とASCII版は、違いがあります。東大版が最終的にどうなったのかは不明ですが、何かしら改良を加え続けていたのだろうと思います。

 

そもそも東大版は、オリジナルのPalo Alto Tiny BASICのオブジェクトを逆アセンブルしているということです。最初の段階では、DDJに発表されたものと同一だったはずです。DDJに掲載されているアセンブラソースと比較すれば、どの辺りを変更しているかが分かるのではないかと思います。

 

Palo Alto Tiny BASICのバリエーション

まだマイコンと呼ばれていた時代に様々なTiny BASICが存在しました。COMPUTOPIAの1977年10月号の「"Tiny BASIC"のすすめ(2)」という記事の中には「表3 各種Tiny BASICの言語仕様・性能比較表（東京大学理学部 小野芳彦氏、同学石田晴久助教授の調査による）」という一覧表があります。

 

これらのTiny BASICの中で人気があったのが何だったのか不明ですが、個人的にはPalo Alto Tiny BASICに最も馴染みがあります。今さらTiny BASICを必要とする時代ではありませんが、内部構造を学ぶのは、技術的な興味があります。基礎的調査として、Palo Alto Tiny BASICのバリエーションを調べてみました。

 

• Palo Alto Tiny BASIC VERSION 1.0 (Dr. Dobb's Journal, Vol. 1, No. 5, May. 1976)
• Errata/additions to Palo Alto Tiny BASIC (Dr. Dobb's Journal, Vol. 1, No. 6, June/July, 1976)
• TINY BASIC FOR INTEL 8080 VERSION 2.0 BY LI-CHEN WANG, MODIFIED AND TRANSLATED TO INTEL MENMONICS BY ROGER RAUSKLOB 10 OCTOBER 1976 (INTERFACE AGE, Dec. 1976)
• Palo Alto Tiny BASIC Version Three (PCC'S REFERENCE Book of PERSONAL and HOME COMPUTING, Jul. 1977)
• PALO ALTO TINY BASIC FOR SDK-80 VERSION (1977/03/23, ONO) (エンサイクロペディア・アスキー Vol. 1)
• PALO ALTO TINY BASIC FOR TK-80用バージョン (1977/03/23, ONO) (エンサイクロペディア・アスキー Vol. 1)
• PALO ALTO TINY BASIC (『マイクロコンピュータのプログラミング』石田晴久編)

 

エンサイクロペディア・アスキーなどに掲載されているのは「東大版」と呼ばれており、Palo Alto Tiny BASICのバリエーションです。ただし、記事にも書かれていますが、DDJを参照して変更を加えたのではなく、「オブジェクトを独自に逆アセンブルし、変更を加えた」ものとのことです。

 

インターネットが存在しない時代ですから、発表媒体は雑誌などに限られると思います。想像となりますが、Palo Alto Tiny BASICを個人的に修正したり拡張したりした事例は、少なくないと思います。さらに、オリジナルはi8080版ですが、x86など他のCPUに移植したものも存在するのではないかと思います。技術的な関心として、取り組んでみたいと考えています。

「マイクロPlan」というプログラミング言語

共立出版から1978年に出版された『マイクロコンピュータのプログラミング』（石田晴久編）という書籍が手元にあります。昭和57年6月12日付のレシートが挟んでありました。この中に「マイクロPlanのプロセッサ」（戸村哲）という記事があり、以下のように書かれています。

マイクロPlanはその名前のとおり、ミニコン用のミニ言語であるPlan系のマイクロ言語である。

 

「皆さんもよくご存じのPlan系言語」という書き方ですが、ミニコン用のミニ言語である「Plan」というのが全くわかりません。例示として掲載されている「図2 8-Queenのプログラム」を見ると、Pascal風だと感じました。しかし「Pascal系」ではなくて「Plan系」だというのですから、Pascalの流れをくんでいないのでしょう。

 

数年前であれば「Google検索」をしたところですが、今は「Geminiとの対話」の時代です。Geminiに問いかけてみましたが、全く知らないと言われてしまいました。ハルシネーションで適当な話をでっちあげることもなく、完全にギブアップしています。

 

先ほどの記事の参考文献には「武市正人：ミニ言語のミニ・コンパイラ、bit、1974年8月号～12月号」とあります。bitが廃刊になって久しいですが、図書館で閲覧できるところもあるでしょう。機会をみつけて、読んでみようと思います。 

白いウィンドウ

ネットで「Windows 10/11で起動時に白いウィンドウが出る不具合、原因はChromeかもしれない」という記事を目にしました。この記事と同じような「白いウィンドウ」が最近出るようになったので、これは何だろうかと思っていたところです。

 

ただし記事では「起動直後」に表示されるとありますが、私の場合「画面ロック」を解除すると表示されます。

 

このような現象が現れているのは自分だけなのだろうか、解決方法はないだろうかと、Googleで検索してみました。しかし適切なキーワードが思いつかず、困っていたところです。「白いウィンドウ」というキーワードだと、全く関係ない記事がヒットしてしまうので、この現象をいったい何と表現するのだろうと悩んでいました。

 

現象は確認されているようなので、そのうち修正されるのを期待しています。 

TW5においてプラグインが動作しない問題が解決した

TW5.4.0に更新したらプラグイン「a simple calendar macro」が動作しなくなった問題が解決しました。自前で調査するつもりでしたが、JavaScriptのロジックを解析した経験がないので、Geminiにデバッグ方法を教えてもらうつもりでした。

 

Geminiと対話していたら、Geminiからプラグインのソース一式を見せてくれと要求されました。TW5のファイルからJSON形式でエクスポートし、Geminiにアップロードしたら、問題の原因を突き止め、解決方法を提示してくれました。解決するには「<<calendar>>」と記述していた箇所を「<<calendar state:"$:/state/sidebar/my-calendar">>」のようにすることでした。Geminiの指示どおりに書き換えたら、無事に動作しました。自分で解析しなくて済みました。

 

TW5本体かプラグインのいずれかのロジックに何か問題があるのだろうと思っていたので、自分でデバックするしかないと思っていましたが、その必要はありませんでした。TW5.4.0がリリースされ、カレンダープラグインが動作しないことが明らかになったので、手元にある数多くのTW5ファイルはTW5.3.8のまま更新しないで止めていました。しかし、若干記述を変更する必要があるものの、TW5.4.0に更新できます。 

TW5.4.0に更新したらプラグインの動作がおかしい

TiddlyWiki5の5.4.0がリリースされました。直前のバージョンは5.3.8でした。もう随分前からTW5を利用しています。あまり凝った使い方はできていませんが、いろいろな目的のために便利に利用しています。

 

何かのために新しくTW5ファイルを作る際は、プラグイン「Calendar - a simple calendar macro」を入れています。シンプルと銘打っているだけあって、カレンダーの特定の日をクリックすると、その日付のTiddlerが開くだけです。ところが、TW5.4.0に更新したら、このプラグインの動作がおかしくなりました。

 

具体的には、カレンダーで表示されている月の前後に移動できなくなったのです。「＜」や「＞」で前後の月へ、「≪」や「≫」で前後の年へ移動できるはずなのですが、まったく反応しません。TW5.3.8なら問題ないのです。このプラグインはタグ「$:/tags/SideBar」を指定したTiddlerで利用しています。サイドバーに表示されているカレンダーでは不具合がありますが、Tiddlerを単独で表示させると、問題ないことがわかりました。

 

TW5.4.0は、過去との互換性を断ち切ったところがあるようです。何が原因なのか不明ですが、ほんのちょっとした対処をすれば、解決できるかもしれません。挑戦してみようという気はあるのですが、TW5はJavaScriptを駆使して作られています。問題を突き止めるために、何をどうしたら良いのかも、よくわからない状態です。

 

Geminiに相談したら、デバッグ手法をアドバイスしてもらえるでしょうか。 

「便利なツールを享受しつつ依存しすぎない生活」と「喉元過ぎれば熱さを忘れる」

「「モバイルSuica」復旧後も続く混乱…「物理カード最強説」再浮上　今さら聞けない自衛策を解説」というWeb上の情報によると、通信障害が原因で様々なトラブルが発生したとのことです。この問題で影響を被ったのは、それなりにいたとしても、鉄道利用者の一部だと思います。鉄道系ICカードが全て使えなくなったのではないし、物理カードのSuicaなら影響を被りませんでした。

 

今回の問題は、あるサービスを利用するということは、それに依存しているのだという側面を露わにしました。スマホが普及し、過去に存在した物理カードを代替するスマホアプリが増えています。所有している物理カードを使うのを止めて、何でもスマホアプリに置き換えてしまえば、「スマホで何でもできるようになった。便利になった」という側面があることは否定しません。

 

スマホに何でも集中させることのメリットばかり強調されますが、デメリットを考えないのは片手落ちだと思います。スマホを落としてしまうこともあるでしょうし、盗難に遭うこともあるでしょう。それ以外にも様々な障害が考えられますが、どう対処するかを予め考えておくことはリスク管理ではないでしょうか。「卵は一つのカゴに盛るな」という格言もあります。

 

今回のようなトラブルが発生すると、「物理カード最強説」ということが言われたりしますが、「喉元過ぎれば熱さを忘れる」も忘れないで欲しいと思います。

初めて最初のフライトに成功した

Microsoft Flight Simulator 2002をWindows 11で動かしています。購入したのは20年以上も前でした。サポートはとっくに終わっていますが、Windowsを新しくするたびにインストールしていました。Windows 10までは、インストールすれば問題なく動作していました。ところがWindows 11では、インストールできるのですが、フライトを始めると異常終了してしまいます。なんとかならないかとGeminiに相談したところ、dgVoodooを使えば何とかなるかもしれないという助言をもらいました。試してみたら問題なく動くようになりました。

 

MSFS2002以外は、「ようこそ！」というメニューがあります。動画による簡単な説明が行われた後、いきなりですが、初飛行をします。MSFS2002購入依頼、この「初飛行」を何度となく試みました。操作もよくわかっていないし、飛行機の操縦も不慣れなので、酷いものです。シミュレータなので命は無事ですが、そうでなければ何十回も死んでいたところです。墜落こそしないものの、飛行場を遥かに離れた場所に着陸するとか、建物を突き破るなど、なんでもありです。

 

何度も「初飛行」していて慣れてきたのか、今日ようやく、まともなフライトに成功しました。離陸した飛行場に戻ってこられましたし、滑走路のすぐ傍に着陸できました。

 

これで、やっと「フライトレッスン」に進級できそうです。 

CF-SV9か、CF-SV8か、それともCF-SV7か

Windows Vistaの頃に購入したdynabook SS SX/15Aを使っています。Windows Vistaは既にサポート終了していますから、NetBSD/i386に入れ替えています。日常的に使っている訳ではなく、旅行などに持っていくだけですが、ハードウェア的にもソフトウェア的にも限界を感じるようになってきました。

 

新しいPCを購入しようと思いますが、BSD系のOSに入れ替えるつもりですし、最新型である必要はないので、中古で探そうと思います。今使っているdynabookと形状が近いLet's note CF-SV9にしようかと考えていました。

 

秋葉原に気軽に行ける場所には住んでいないので、通販で買うことになると思います。新品ならいざ知らず、中古を通販で買うのは多少の不安があります。新品同様の美品を期待している訳ではありませんが、部品取りにしかならないジャンクでは困ります。中古を扱っているサイトを調べていると、CF-SV9の底値は2万円くらいのようです。

 

ちょっとグレードを落としてCF-SV8にすると底値1万5千円くらいになり、さらにグレードを落としCF-SV7ならば底値1万円でした。どれであっても現状のdynabook SS SX/15Aと比べれば、快適に使えそうです。迷ったので、Geminiに相談してみました。中古なので、何を買ったとしても博打となる側面は避けられませんが、CF-SV7を選ぶよりは、CF-SV8かSV9を勧めるとのことでした。

 

Let's noteのこれらのモデルはSSDですが、入手してみないとSSDの劣化の程度が不明です。まだまだ十分使えるかもしれませんし、劣化が酷く交換した方が良いかもしれません。仮にSSDを交換するのであれば、その費用を考えれば、CF-SV8を選んでおく方が良いかもしれません。

 

何を選ぶにせよ、今夏には購入しようと思います。 

Inkscapeの文字が太い

文書に添付する図を描くときにInkscapeを使うことがあります。きちんとしたトレーニングを受けずに使っているので、常に試行錯誤しています。英文の「初心者用ガイド」が付属していますが、かなり膨大です。PDF版は241頁でした。これに目を通しておいた方が良いのだろうと思います。

 

簡単な図を描くだけなら、手探りで試行錯誤しても、なんとかなります。ただし綺麗な図にはなりません。簡単な図を描いてみたのですが、文字が太くなってしまいました。別に太字として設定したわけではありません。それなのに、太字で、完全にメタボです。

 

解決策をGoogleで検索したら、「テキストにもフィルとストロークがある」が見つかりました。この記事のとおりに設定を見直したら、文字がスッキリしました。ダイエットに成功した感じです。 

NHK「世界ふれあい街歩き」の謎

NHKで放送が続いている「世界ふれあい街歩き」という番組があります。放送されるときにはナレーションを担当する芸能人が会話しているように編集されていますが、収録時は現地のコーディネーターが会話しています。これはウィキペディアに記載があります。しかも相手とは偶然の出会いのように会話していますが、事前に打診があるようです。ただしそれを「仕込み」と考えるかどうかは、ウィキペディアとオンラインのQ&Aサイトの回答とで見解が分かれています。

 

人が集まっているところで「何をしているんですか」と声をかけるシーンが度々現れますが、それが偶然なのか、事前に打ち合わせ済みなのかは、放送を見ているだけでは判断つきません。全部仕込みに決まっているだろうという主張もあり得ますが、番組の性格上、通りすがりの人に声をかける場面もあるので、そこまで仕込みとは思えません。仕込みが全くないとは主張しませんが。

 

放送では、朝から夜まで散策したかのように編集していますが、実際には2日間撮影しているようです。通りすがりの人に声をかけてみたものの、思ったような反応が返ってこないこともあるでしょうし、NGシーンもあるでしょう。それを編集して、あたかも1日で歩いてみたという設定にしているのだと思います。ただ、初日と二日目の天気が大きく違っていたらどうするのだろうと思います。

 

事前に打ち合わせ済みの場所を撮影する場合は、いかに自然な出会いであるかのように見せるかが腕の見せ所なのだと思います。NHKには「ブラタモリ」 という街歩き番組もあります。この番組では、街を紹介する担当者が、不自然な様子で待機しているシーンがよく登場します。偶然出会ったという風にする必要はないので、あえて不自然な待ち方にしているのかもしれません。

 

formailは便利

これまで知りませんでしたが「formail」というコマンドがあるようです。procmailが提供しているようです。procmailは以前から利用していましたが、formailは知りませんでした。

 

話の発端は、MH形式でローカルに保存していたメールファイルが、様々な問題をかかえていたので、修正しようとして考えており、その調査のためにメールヘッダを網羅的に検証する必要がでてきたことでした。例えばContent-typeに「iso-2022-jp」と書かれているのに、「nkf --guess」で確認するとEUC-JPだったりするのですが、この他にも、多種多様な問題がありました。

 

やっかいなのは、メールヘッダの各項目は、一行ですむとは限らないことです。メールヘッダのある項目が、複数行に別れている場合があります。そうなると、単純にgrepしただけでは、検出できない場合が考えられます。そこで、複数行に別れているなら1行に結合する前処理をおこなえば、grepでも対処可能なので、そうしようと考えていました。その前に、念のためにGeminiにお伺いをたてたら、「formail」の存在を教えてもらいました。

 

formailは、まさに求めていたものです。これを使えば、自前で前処理をする必要がなくなります。なんと便利なものがあるものかと、これまでの無知を恥じ入るばかりです。

dynabook SS SX/15Aの後継としてLet's note CF-SV9を検討中

Windows Vistaが搭載されていたdynabook SS SX/15AをNetBSD/i386に入れ替えて使ってきましたが、ハードウェア的にもソフトウェア的にも、限界を感じるようになってきました。

 

そもそも電源を入れてても、NetBSDのブートメニューが出てこない場合があります。そういう時は、筐体を揺すってみるとか、表面とか裏面から押してみるなど悪あがきを何度か繰り返すと、そのうちに起動するようになります。起動してしまえば、途中で落ちたりはしませんが、どう見ても故障しているとしか考えられません。

 

また近年32ビット対応がなくなりつつあります。NetBSD/i386で利用できるFirefoxは、10年くらい前にリリースされたものしか入手できないので、単純にWebを見るくらいしか使いものにならなくなってきています。

 

新しいマシンを入手しようと思いますが、BSD系OSに入れ替えるつもりなので、Windowsは必要ありません。中古で十分ですし、状態のよいジャンクでも構いません（まともに動作しない、部品取りレベルのジャンクは、流石に願い下げです）。最新型である必要はありませんが、値段が変わらないなら、新しいモデルの方が有難いのは間違いありません。さらに、遠出する際に持ち運ぶ都合上としてB5サイズのサブノートを希望します。

 

このような条件で中古を探すとLet's note CF-SV9が候補にあがりました。中古ですから、状態も様々ですし、値段も様々です。安いものを探せば、2万円前後のようです。今すぐ購入することは可能ですが、もうちょっと様子をみようと思います。

古いドライブレコーダーで64GのmicroSDXCを使うためにFAT32にする

10年ほど前から車にドライブレコーダをつけています。購入時に付属していたのは4Gのメディアでしたが、録画時間を延ばすため、32Gに換装して使ってきました。つい先日、車のエンジンをかけたら警告音が鳴りだしました。何のエラーなのかと心配になりましたが、帰宅してからSDカードを確認したら、メディアが壊れていました。数か月前にも、スマホで使っていたSDカードが壊れてアクセスできなくなった経験があるので、多分同様の現象なのだと思います。

 

ドライブレコーダにメディアが入っていないことには、ドライブレコーダの機能を果たせませんから、急遽家電量販店に走りました。世間の噂によるとSDカードが品薄で値上がりしているとのことで、家電量販店でも在庫が少なかったし、値段も上がっている印象でした。

 

これまで32Gのメディアを使っていたので、同容量のものが欲しかったのですが、在庫がありませんでした。128Gとか、もっと大容量のメディアはありましたが、値段が高いのも困りものです。何か買わないことにはドライブレコーダが使えるようにならないので、64Gのメディアを買いました。

 

購入したばかりのSDカードをドライブレコーダに装着してみましたが、警告音が鳴りやみません。もしかすると壊れたのはメディアではなく、ドライブレコーダ本体の方なのかという不安がよぎりました。しかしネットで情報を集めてみると、古いドライブレコーダは、FAT32しか対応していない可能性があるが、64GのメディアはexFATが使われるので、FAT32でフォーマットしなおす必要があるという結論を得ました。

 

Windows11の標準機能では、64GのメディアをFAT32でフォーマットすることができないので、代替品を探しました。いろいろあるようですが、「I-O DATA ハードディスクフォーマッタ」を利用しました。さっそく利用してみましたが、FAT32でフォーマットしたつもりなので、Windows11で確認するとexFATのままです。またしてもネットで情報を集めると、「管理者として実行」しないとフォーマットできないことがわかりました。あらためて「管理者として実行」したら、今度はFAT32でフォーマットできました。

 

FAT32でフォーマットした64GのmicroSDXCカードをドライブレコーダに装着したら、警告音が止まりました。他にエラーもないようですので、ドライブレコーダとしての機能が復活したようです。 

殿上人卅余人

数年前から語り本系平家物語を最初から暗誦できるように読み進めています。『新日本古典文学大系 44 平家物語 上』を使っていますが「吾身栄花」の途中まで覚えました。ここは、平清盛だけでなく一門が繁栄したことを語る場面です。そこには、つぎのような一節があります。

すべて一門の公卿十六人、殿上人卅余人、諸国の受領・衛府・諸司都合六十余人なり。

 

ここで殿上人は「卅余人」（さんじゅうよにん）とあります。「三十四人」ではありません。「30人+α」ということです。公暁は「十六人」と人数をぼかしていないのに、殿上人は実際の人数を明らかにしていません。

 

『平家物語』には、語り本系と読み本系があり、これは語り本系です。印刷されたものを読むこともあるでしょうけど、本来は琵琶法師とかが語るのを聴くものです。「さんじゅうよにん」と語られたら、聞いている方としては、「三十四人」と理解するのか、「三十余人」と理解するのか、どちらなのでしょうか。

dynabook SS SX/15Aの代替を探したい

20年ほど前に購入した「dynabook SS SX/15A」には「Windows Vista」がインストールされていましたが、2017年にサポート終了となったので「NetBSD/i386」に入れ替えて使い続けてきました。メモリは4Gなので、32bit CPUとしてはフル実装ですが、HDDが60Gしかないので、窮屈です。換装しようにも、1.8インチHDDが使われているため、代替品を入手するのが困難です。

 

さらに昨今はソフトウェア側で32bit CPU対応を止めるものが多くなってきています。日常的に使用しているわけではないので、最新版を使いたいわけでもないのですが、利用可能なバージョンが古くて不便な状況に追い込まれてきました。

 

しかも、電源を入れても素直にOSが起動しない場合があります。そういう場合は、ノートPCごとを揺すってみたり、表面とか裏面から手で押してみるとかを繰り返すと、起動できるようになります。いったん起動してしまえば、動作中に落ちることはありません。大昔の家電製品は故障したら叩けば直ると（嘘か真か）言われていましたが、それに近いものがあります。

 

このままダマしダマし使い続けるのは可能だと思いますが、そろそろ代替品を探して、移行しようと思います。次もNetBSDにしようと考えています。新品である必要はないので、中古かジャンク品を入手しようと思っています。2万円くらいで入手できないかと思い探しています。通販でもよいのですが、現物を確認して買いたいところです。

CSVを操作するための「Miller」というツールがあるらしい

ローカルにMH形式で持っているはずのファイルを確認したら、いろいろな意味で問題があることが分かりました。2000年前後のものなのですが、メールヘッダには「iso-2022-jp」とあるのに、本文を「nkf --guess」したら「EUC-JP」と訴えています。これだけなら変換すれば良いのですが、文字化けという意味ではなく、種々雑多な問題が潜んでいそうです。しかも、そのようなメールが9万ファイル弱あって、簡単には修復できそうもありません。

 

Geminiに相談したら、ファイルごとの情報を整理したCSV形式ファイルを作ってから、対処方法を考えるべきだとのアドバイスをもらいました。それでCSV形式ファイルを作ってみましたが、ここから問題のパターンを整理しなければなりません。

 

これまでCSV形式ファイルを調査するには、AWKなどのコマンドラインツールを駆使してきました。今回もそれでいこうと思ったのですが、ちょっとGeminiに相談したところ、「Miller」というツールを紹介してもらいました。パッケージから簡単にインストールできましたが、使い勝手が手強そうです。公式サイトから「Miller 6.18.1 Documentation」を見つけました。まずは、これを読んで勉強してみようと思います。

花山院の左大臣殿の御台盤所にならせ給ひて、君達あまたましましけり

数年前から語り本系の平家物語を暗誦しようと思い、少しずつ覚えています。「祇園精舎」から始まり、「殿上闇討」、「鱸」、「禿髪」と進み、今は「吾身栄花」を覚えているところです。

 

ここには、「一人は、桜町の中納言重教卿の北の方にておはすべかりしが、八歳の時、約束計にて、平治の乱以後、ひきちがへられ、花山院の左大臣殿の御台盤所にならせ給ひて、君達あまたましましけり。」という一節があります。「花山院の左大臣殿」とは藤原兼雅のことです。二男一女をもうけたようですが、「君達あまたましましけり」というほどでもないかという気がします。 

 

平清盛には18人の子がいたようですので、ここまでいれば「ましまし」という感じはします。現代では「マシマシ」と言うとラーメンの注文のようですが、ニュアンスは同じのように思います。

GNUSを諦め、Wanderlustに復帰するかもしれない

10年ほど前から、メールを読むのにGNUSを使ってきました。ここ最近になって（それでも今年とか、去年とかではありませんが）、サマリー表示が「[nobody](1970-01-01 09:00)(none)」のようになっているのに気づきました。当初は、これはGNUSのバグだと考えていたので、いずれバグフィックスされるだろうと思っていました。いつまで経っても直らないので、GNUSの利用者が少ないか、開発者が少なくて、問題が発覚しないか修正されないのかと、見当はずれなことを思っていました。いい加減に業を煮やしてGeminiに相談したところ、対策を編み出してくれました。

 

そもそもメールを読むのに、FreeBSDを使っています。プロバイダからfetchmailでローカルに取り込み、procmailで振り分けてから、GNUSで読んでいます。Geminiに相談した結果、fetchmailやprocmailの設定誤りが発覚しました。その対処を済ませたので、もう大丈夫だろうと思っていたのですが、相変わらず、同様の現象が発生します。Geminiに言わせれば、ヘッダが大きすぎるので、GNUSの解析が途中で打ち切られてしまうのが原因だろうと推測しているようです。そうなのかもしれません。試しにヘッダを加工して、大きすぎるエントリを削除してみると、うまく解析できているようです。そうであれば、ヘッダが悪い可能性は高いと思います。

 

しかしメールのファイルをWindows11上のThunderbirdで読ませてみると、別に問題が発生しないので、GNUS側でなんとかならないのだろうかという気になります。Geminiに相談を持ち掛けてみたのですが、いろいろと試してみましたが、どうにも解決に至りそうにありません。

 

GNUSに拘るわけではありません。しかしEmacs上で動くこと、MH形式ファイルを扱えることが必要です。この条件にあうのは、GNUS、Mew、Wanderlustが候補となります。しかし、もともとはWanderlustを使っていたのです。ところが2013年3月頃、emacs24でエラーが多発するようになり、GNUSに移行したのでした。しかしGNUSでのメール送信方法がわからなかったので、メール送信にはMewを利用してきました。

 

GNUSを諦めるとすると、MewかWanderlustが候補です。Wanderlustの使用を止めようと思った頃にもMewにしようかと考えました。しかしMewは、メールの未読管理ができなかったのです。つまりMewの管理外、すなわちprocmailで振分けられてしまうメールを、Mewは未読か既読か認識できなくなってしまうのです。それでGNUSを選択したのでした。

 

2013年3月以降GNUSを使ってきて、サマリー表示が変にならなければ、このままGNUSを使い続けていたところです。しかしそういうわけにもいかなくなってきたので、懐かしのWanderlustに復帰しようかと考え始めました。

 

いきなり移行してしまうのも性急に過ぎると思います。まずは、現状のGNUSを使い続け、その裏ではWanderlustを試行しようと思います。そしてWanderlustでも大丈夫だと確信できたら、その時はGNUSを諦め、Wanderlustに復帰することになります。

NHKの見逃し配信は「本放送」終了後1週間

NHKのテレビやラジオは、ネット配信が行われています。視聴できるのは、テレビ（またはラジオ）で放送されてから1週間なのです。ただし注意が必要ですが、正確に言えば、視聴できるのは「本放送」から1週間です。「再放送」は関係ありません。

 

例えば「100分 de 名著」の場合、本放送は「毎週月曜　午後10時25分」で、再放送は「毎週金曜　午後３時５分」です。この場合ですと、本放送が終わってから1週間は見逃し配信がありますが、再放送は見逃し配信の期間に影響しないので、再放送からカウントすると数日間しかありません。

 

本放送とか再放送とか言う区分は、「放送」における区分に過ぎず、「ネット配信」とは別概念なのです。当たり前かもしれませんし、この違いは著作権の扱いによるものですが、少なからず専門的な概念ともいえるのではないかと思います。テレビやラジオを視聴している人にとって、それが本放送なのか再放送なのか気にしていないと思いますが、内部の放送関係者にすれば大問題なのです。だからこそ「見逃し配信はいつまで見られますか？」という問いに対して「見逃し配信は、放送の終了から1週間視聴できます。」と答えていますが、その真意は伝わっていないかもしれません。

視聴者からすれば、放送もネット配信も同じだと思っているのでしょうけれども、現時点では違うものです。しかしそれが未来永劫そうだとも限りません。未来は変わっていることを願いたいと思います。

 

SIMHのPDP-11エミュレータのメモリ参照は、16bitアドレス? 18bitアドレス? 22bitアドレス?

SIMHのPDP-11エミュレータを利用し、PDP-11/40上で動作するUNIXv6について学ぼうと考えています。まずは「m40.s」のラベル「start」から起動するプロセスを見ていこうと思います。ここではMMUが無効になっていますが、管理レジスタを設定し、MMUを有効にするための準備をおこないます。

 

「mov    $77406,(r1)+」のような箇所でMMUのレジスタに値を設定しています。ここでR1には「KISD0」が入っており、具体的には「172300」です。これは16bitアドレスとしての表現です。PDP-11/40のメモリ管理装置である「KT11-D」では、マニュアルの「Table 3-1 PAR/PDR Address Assignments」において「772300」のように定義されています。これは18bitアドレスです。ところがSIMHのPDP-11エミュレータでは、「17772300」のような22bitアドレスで参照しなければならないようなのです。

 

デバッガ機能を利用してメモリを参照した例を以下に示します。このように、16bitや18bitアドレスではMMUレジスタを参照できず、22bitアドレスで参照すると、格納されている値が参照できます。

Step expired, PC: 003370 (MOV #77406,(R1)+)
sim> s
Step expired, PC: 003374 (ADD R4,R2)
sim> e R1
R1:     172302
sim> e 172300
172300: 000000
sim> e 772300
772300: 000000
sim> e 17772300
17772300:       077406 

 

ちなみに、CPUは次のように定義しています。

sim> sh cpu
CPU, 11/40, NOFIS, idle enabled, stability wait = 20s, autoconfiguration enabled, 256KB 

エミュレーションするモデルを11/70としているのであれば、22bitアドレスでも納得するところです。しかし11/40として設定しているはずなの、22bitアドレスなのは、ちょっと不可解です。ただしSIMHが、そのような挙動なのは、そうなのですから、それを受け入れるしかありません。

外部セキュリティーキーは「パスキー対応」で使えないのだろうか

2026年4月14日に「Yahoo! JAPAN ID、安全性・利便性向上を目的としてログイン方法を「パスキー」に一本化へ」という発表がありました。Yahoo以外でも、ログイン時にパスキーが使えるというサイトは増えている印象です。

 

普段使用しているWindows11のデスクトップPCには、スマホのような生体認証デバイスがありません。どうしたら良いのかと悩んでいたら、USBポートで使える「外部セキュリティーキー」というものがあるようです。Amazonで調べると、値段が高いものも安いものもあり、何がどう違うのか分からないので、Geminiに相談してみました。安いのでも構わないだろうと判断し、TrustKeyのT110を購入しました。Geminiからバックアップ用も必要とのアドバイスを得たので、2つあります。

 

さっそく幾つかのサイトでログインでパスキー認証をするように設定してみましたが、うまくいっているようです。ところが、サイトによっては、使用環境が厳しいところがあり、WindowsではEdgeかChromeと明記され、Firefoxが対象外になっている場合があります。対象外でも実は大丈夫ではないかと試してみましたが、エラーになってしまいました。

 

EdgeかChromeなら良いとあるので、Chromeで試してみたところ、パスキーの登録先を外部セキュリティーキーにしたら、やはりエラーになってしまいました。そのサイトではエラーになった場合の対処方法として、「何度か試してみる」とか、「キャッシュをクリアする」などが書かれているので、何度か試してみましたが、全くうまくいきません。Geminiに「キャッシュをクリアする」のは有効だろうかと質問してみましたが、それでうまくいく可能性は低いとの回答を得ました。Geminiの推測によれば、サイト側で「外部セキュリティーキー」や「Firefox」を対象外としてロジックを組んでいるのではないかとことです。

 

できれば「外部セキュリティーキー」を使用し、「Firefox」でパスキーの登録ができるようになってもらえるとありがたいのですが。そうでないままに、「ログイン方法をパスキーに一本化」されるのは、とても困ります。 

またしてもGNUSでサマリー表示が「[nobody](1970-01-01 09:00)(none)」になった

メールを読む環境はFreeBSD/amd64上に構築しています。プロバイダからfetchmailでローカルに取り込み、procmailで振分け、GNUSで読んでいます。GNUSサマリー表示が「[nobody](1970-01-01 09:00)(none)」になってしまうのは気がついていましたが、最近になってGeminiに相談して、解決に至ったと思っていました。

 

ところが、再び同様の現象になりました。若干違うのは、全く同様の現象のメールと、日付だけは正しく表示されるメールがあることです。再びGeminiに助けを求めました。こちらから情報を提供し、Geminiからは、あれを確認しろとか、これを設定してみろとか指示が飛びます。基本的にはGeminiの指示に従うのですが、方向性が解決から逸れているんじゃないかと思うところもあり、軌道修正を図ります。Gemini（というか生成AI一般に）との向き合い方は、一方的に妄信するのではなく、こちらも相応の技術背景を持ったうえで、対話に臨む必要があると感じます。

 

閑話休題。今回の問題メールは、なんとGoogleが発信元なのです。結論として、Googleが送信時に付加する「X-」で始まるヘッダに問題がありそうだということになりました。ローカルに持ってきた問題メールをエディタで編集し、「X-」のヘッダを全て削除したところ、サマリー表示が正常になるのを確認しました。

 

まさかGoogleが送ってきたメールなのにと思わないでもありません。Geminiに言わせれば、（本当かどうかわかりませんが）、GNUSはヘッダの解釈が厳密で、Googleが送信するメールも完璧ではないので、こういうこともあり得るとのことでした。少なくともこちらでできることはないので、Google側が何とかしてくれる（そもそも気づいているのか）のを待ちたいと思います。 

TiddlyWikiｇ 5.4.0がリリースされたけど・・・

TiddlyWiki 5.4.0が2026年4月21日にリリースされました。新しいバージョンがリリースされると、いつも手持ちのTW5ファイルを更新しているのですが、今回は控えようと思います。いつも利用しているTW5ファイルを更新したら不具合が出たからです。

 

TW5ファイルは、基本的にはWindows11上のFirefoxで利用しています。あまり凝ったことはしていませんが、「Calendar - a simple calendar macro」というプラグインを入れています。これが動かなくなりました。具体的には「<」や「>」で前後の月に移動できなくなりました。TW5.3.8なら問題なかったのです。

 

またNetBSD/i386 9.0上のFirefox 52.9.0では、Internal Errorが表示され、全く動きません。「TypeError: result.mqList.addEventListener is not a function」というメッセージが出ています。Firefoxのバージョンが旧いですが、NetBSD/i386で動作するFirefoxは、これしかないのです。しかもTW5.3.8では問題なかったのです。

 

TW5.4.0がリリースされたばかりなので、もしかすると近日中にTW5.4.1が出るかもしれません（出ないかもしれませんが）。手持ちのTW5ファイルが数多くあるのですが、更新は当面見合わせるつもりです。

GNUSでサマリーが「[nobody](1970-01-01 09:00)(none)」と表示される

メールをFreeBSD/amd64上で管理しています。プロバイダに届いたメールを、fetchmailで取り込み、procmailで振分け、Emacs上のGNUSで読んでいます。Emacsでメールを扱うのは昔からで、元々はWonderlustを使っていましたが、十数年前にGNUSに変更しました。しかし送信の設定ができていないので、メールを送る時はmew（もしくはWindows11上のThunderbird）を使っています。

 

最近（と言っても数年たっていますが）になって、GNUSのサマリーモードで表示が「[nobody](1970-01-01 09:00)(none)」となるメールがあるのに気付きました。すべてそうなるわけではなく、送信者、送信時刻、サブジェクトが表示されているものもあります。以前はこんなことにならなかったので、てっきりGNUSのバグだと思っていました。そのうち直るだろうと高をくくっていました。それなのに、いつまでたっても直らず、そもそもGNUSを使っている人がいないんじゃないか、だから直らないんじゃないかと、あらぬ疑いをかけていました。

いつまで待っても修正されないならば、自分で対処しようと思いましたが、Emacs Lispは不慣れですので、Geminiにお願いしようと考え、Geminiに相談を持ち掛けました。いきなりEmacs Lispについて相談したわけではなく、GNUSの現象を示して回答を求めたのですが、なんとGNUSの問題ではなく、fetchmailかprocmailが怪しいとの診断が出ました。

Geminiとの対話を繰り返した結果、設定ファイル「~/.fetchmailrc」の中で「mda "/usr/local/bin/procmail -f- -d %T"」とある「-f-」が原因ではないかというのがGeminiの見立てでした。procmailのオプション「-f-」というのは、PROCMAIL(1)によれば、「If fromwhom consists merely of a single `-', then procmail will only update the timestamp on the `From ' line (if present, if not, it will generate a new one).」と書かれています。このオプションが指定されていることで、メールの先頭にある「From」の次に「>From」という行が生成されてしまうようなのです。このような行があると、GNUSがメールヘッダをハンドリングしようとして失敗するので「[nobody](1970-01-01 09:00)(none)」となってしまうようです。

 

若干疑問なのは、届いたメールは全てprocmailを通すので、全メールが「>From」のようになっています。それでもサマリーモードが問題なく表示されるものもあるのです。この点についてGeminiに尋ねたら、何か説明してくれましたが、読み飛ばしてしまいました。

 

ちなみにmewを使った場合、サマリーモードでも全く問題ありませんでした。

PDP-11のハードウェアTRAPにおけるモデル差異

PDP-11/40で動作するUNIXv6を、Lions本を頼りに学んでみようと考えています。まず手始めに「low.s」を調べています。この中でトラップベクタが定義されていますが、PDP-11のモデルによって違いがあるのではないかと気になりました。カーネルの動作環境は、SIMHのPDP-11エミュレータを使用するつもりですが、PDP-11/40を想定しています。しかし、PDP-11/45とかPDP-11/70という環境を考えることも、できなくはありません。PDP-11のモデルは他にもありますが、まずは11/40、11/45、11/70を考えると、モデルによる差異はどうなっているのでしょうか。

 

調査した資料は、PDP-11/40、11/45、11/70の『Processor Handbook』です。

 

まず、4番地から34番地にある7つのTRAPは、どのモデルにも存在します。また240番地と244番地の2つのTRAPも、どのモデルにもあります。しかし250番地のTRAPは、PDP-11/45、11/70にしかないようですし、114番地のTRAPは、PDP-11/70だけにしか存在しません。「low.s」では、これらのTRAPが全て定義されていますが、定義されていても別に無駄にはならないので、問題ではないのでしょう。

 

また各トラップベクタでは「trap; br7+5」のように記述されています。PDP-11のトラップベクタは、2ワード(4バイト)で構成されており、第1ワードが飛び先アドレス、第2ワードがPSWです。そして「br7」というのは割り込みのプライオリティを示していますが「+5」は何でしょうか。「low.s」の中では「br7+0」から「br7+9」まであります。

 

「trap」とは、「m40.s」の中にあるラベル「trap」のことで、Lions本の0755行にあります。この中で更に制御が移り、「trap.c」の「trap()」が呼ばれます。これはLions本の2693行にあります。ここで「+5」などを処理するために、switch-caseがあります。ただし「br7+4」と「br7+7」に相当するcase文はありません。これらはdefault文で処理されることになります。

 

しかも「low.s」には「br7+7」となっているトラップベクタが2つあります。Lions本の0538行と0547行です。これらは、「trap()」でも対応するロジックがありませんから、UNIXv6としては、未対応で十分という判断なのだと思います。今回UNIXv6のカーネルを学ぶに際しても、それ以上の調査は行いません。ただし将来的には、これらのTRAPの扱いがどうなっているのか、調べてみたい気がします。UNIXv7とかBSD2.11などでは、改良されているのでしょうか。それとも手付かずのままなのでしょうか。 

「4」とは？

PDP-11/40で動作するUNIXv6を学び始めました。カーネルを学ぶ入口は様々かと思いますが、まずは起動する過程を追いかけていこうと考えています。参考書はLions本で、オンラインで参照できる様々な資料も使います。実行環境は、実機があればよかったのですが（よくない？）、SIMHのPDP11エミュレータを使います。

 

カーネルの0番地に関連するのは、「low.s」です。Lions本では500行から599行までです。508行の0番地には「br 1f」があり、522行には「1: jmp start」があるので、カーネルの起動処理は、実質的には「start」から始まっているようです。

 

ここで509行目に目を移すと「4」とあります。これは何でしょうか？PDP-11の命令ではないし、疑似命令でもありません。何かの定数宣言でもなさそうですし、コメントが入っていないので、意図も分かりません。

 

『PDP-11/40 processor handbook』の「APPENDIX B MEMORY MAP」 には「INTERRUPT VECTORS」として、0番地から300番地あたりまでに定義されている割り込みベクターが記載されています。これらは、2ワード(4バイト)を組みとして、第1ワードが飛び先アドレス、第2ワードがPSWの設定内容となっています。ただし0番地は「RESERVED」となっているため、ここが割り込みベクターとはなっていないし、実際に「br 1f」という命令が置かれているわけです。仮に割り込みベクターと考えたとしたら、PSWが入るはずの場所に「4」があるわけですが、そもそも割り込みベクターではないので、PSWに設定する値ではないはずです。

 

「low.s」では、512行から「trap; br7+0」のように、PDP-11/40が定義した割り込みベクターが並んでいます。これらは4番地から始まるので、0番地の「br 1f」だけでは番地がずれてしまうので、何か埋め草が必要です。それが「4」のように見えるのです。

 

この「4」には、何か意味があるのでしょうか。「0」でも構わないのではないでしょうか。もしくは「4」を記述せずに、「. = 4^.」を明示した方が良かったのではないでしょうか。この疑問には答えがありません。強いて言えば開発者本人に聞くしかありませんが、もう60年くらい前のことですし、強いて思い出してもらわなければならないほど重要な問題でもありません。 

「klin: jsr r0,call; _klrint」とは何をしているのか

Lions本や、オンライン上にある情報を参考に、PDP-11/40で動作するUNIXv6について学んでいます。まずはカーネルが起動する過程から調べていこうと思い、「low.s」を見ています。これは機械的に生成されたものである点に注意しておかなければなりません。実行環境は、当然ならが実機を所有していないので、SIMHのPDP11エミュレータを用いて、「Installing UNIX v6 (PDP-11) on SIMH」の手順で作成された環境を利用します。 

 

Lions本に掲載されている「low.s」は、実行環境とは構成されているデバイスが違います。しかし「klin: jsr r0,call; _klrint」のようなエントリが並んでいるのは同様です。このようなロジックを考え付いた経緯はわかりません。他の実装も考えられるかもしれません。僕が疑問を感じる（と言っても、この実装が駄目だと言っているわけではないのですが）のは「JSR（Jump to Subroutine）命令を使っているのに、この場所に戻ってくることは想定していない」からです。もし本当にサブルーチンコールを意図しているなら、何らかの処理をしたら、この場所に戻ってくるわけですが、「low.s」では各デバイスのためのJSR命令が並んでいるだけですから、それを順番に処理しても意味がありません。このJSR命令は、戻ってこないのが前提であり、むしろJMP（Jump）命令のような動作を期待しているはずです。

 

さらにJSR命令の後に続く「_klrint」は何でしょうか。これは、Lions本であれば8078行にある「klrint()」のことです。そしてJSR命令で呼び出される「call」（Lions本の776行）には「jsr pc,*(r0)+」があります。PDP-11のJSR命令は、x86のCALL命令とは異なり、戻り番地がスタックに積まれるとは限りません。特に今回のように「jsr r0,call」となっている場合、戻り番地は、レジスタR0にあります。と言うことは、R0が指している場所には「_klrint」があります。つまり「jsr r0,call; _klrint」では、形式的にサブルーチンコールとして「call」が呼ばれ、その中で「jsr pc,*(r0)+」として、「_klrinit」に制御が移ります。最終的に呼び出し元に戻ってくることはありません。

 

なお「jsr pc,*(r0)+」において、R0の内容が変化しますが、これは副作用です。PDP-11に「jsr pc,*(r0)」のような指定が存在しないだけであって、カーネルとしてR0が変化するのを期待しているわけではありません。 

Lions本とUnix-v6-Ken-Wellsch.tapとではデバイス構成が異なる

SIMH上のPDP-11エミュレータでUNIXv6カーネルを学ぼうと考えています。まずは、「low.s」と「m40.s」から手を付けていきます。参考書は、オンライン上の資料もありますが、やはり定番のLions本です。UNIXv6環境は、「Installing UNIX v6 (PDP-11) on SIMH」に従い、「Unix-v6-Ken-Wellsch.tap」を利用するつもりです。

 

「low.s」は「mkconf.c」により生成されるものなので、UNIXv6のソースツリーには含まれていません。Lions本には「low.s」が掲載されていますが、これがSIMH上の環境と合っているとは限りません。まずSIMHのデバッガ―を利用して、メモリ上に置かれたカーネル「rkunix」を調べてみました。

 

確認したところ、カーネル「rkunix」は、以下のデバイスを有効にしていると見られます。これは「run」の内部で「rkunix」を生成する箇所と一致します。

1. RK11
2. TM11
3. TC11 

 

一方で、Lions本は、0500番台の行番号がついている「low.s」によれば、以下のデバイスが有効になっています。

1. RK11
2. LP11
3. PC11

 

ディスク操作は、どちらもRK11ですが、端末関係が違います。このような違いも含めて、UNIXv6のカーネルを学んでいこうと思います。 

「国際電話不取扱受付センター」というものがあるらしい

自宅の固定電話に着信するのは、不審なものばかりです。ナンバーディスプレイを契約しているので、相手先の番号がわかるのですが、「0120」とか「0800」などの国内から発信されたもの以外に、番号体系が「0AB～J」や「0A0」にはなっていないものが増えてきています。おそらく海外から発信されたものなのでしょう。

 

不審着信は無視しているし、同一番号からの着信が多い場合は、ブロックリストに入れて着信音が鳴らないようにしています。このような対策をしているのですが、物は試しとGeminiに相談してみました。すると「国際電話不取扱受付センター」という存在を教えてくれました。ここに登録しておけば、海外からの着信を全て拒否するようになるそうです。

 

こんなものがあるのかと思いました。これを申し込んでも海外に発信することはできるそうですし、海外からの着信を受けたくなれば、登録を解除することもできるそうです。実際に登録を申し込むかどうか分かりませんが、考えてみようと思います。

復活したブラタモリは普通のブラタモリ

2024年3月で終了となった「ブラタモリ」が 、2025年4月からレギュラー放送に戻りました。復活前には「番組のコンセプトはそのままに、街道を歩くシリーズものなど、新しい試みにも挑戦し、より幅広い世代の人に地域の魅力を届けます。」という発表がNHKからありました。

 

復活直後は、シリーズで街道を取り上げていましたが、しだいに昔ながらのブラタモリに戻っていて、いまはもう普通のブラタモリになっている気がします。2026年4月には皇居内に入ったので「新しい試みに挑戦」とも言えるかもしれません。しかし「街道」はどうしたと言いたいところです。 

SIMHを使用してUNIXv6カーネルを学ぶための準備

「SETTING UP UNIX - Sixth Edition」に記述されている「Making a Disk From Tape」と「Booting UNIX」の手順について、内部処理を確認してきました。これをおこなうことで、UNIXv6のソースファイルにも、PDP-11の動作についても、分かってきました。さらにSIMHのPDP-11エミュレータ内蔵デバッガについても、理解が進みましたので、いよいよカーネル本体を学ぶ練習としては、ちょうど良かったと思います。

 

これからカーネル本体について学んでいきますが、Web上の様々な情報を参照するつもりですが、主たる参考書はもちろんLions本です。ソースファイルを参照するには「The Unix Heritage Society」のサイトにあるものを使おうと考えています。

 

カーネル本体は、これまで見てきたブートローダに比べると大きいし、アセンブラではなくC言語が使われています。SIMHのデバッガは、UNIXv6カーネルのシンボル情報を参照できません。闇雲にデバッガを操作しても、深みにはまるだけで、何も得られないと思います。なんとならないかとGeminiに相談したら、コマンド「nm」を使って、シンボル情報リストを入手しておくことを勧められました。「nm -n rkunix」を実行して得られたリストを手元に置いて参照することにしました。今の時代なら、シンボリックデバッグを使えばローカル変数でも何でも参照できますが、UNIXv6時代では、そこまで求めることはできません。でも、関数のエントリポイントのアドレスが分かるので、最低限の参考にはなりそうです。

 

カーネルの調査を進めていくため、調べたこと、分かったこと、分からないこと等々を記録していく必要がありますが、TW5を利用するつもりです。取得したシンボルテーブルもTW5に記録しておくつもりです。そのままでもシンボルを検索できないわけではないと思いますが、もう少しなんとかならないかと思います。Geminiに相談したら、簡単なスクリプトを生成してくれました。これを使えば、検索ボックスでシンボル名かアドレスを入力すると、対応するアドレス（またはシンボル名）を見つけてくれます。ミニツールではありますが、便利に利用できそうです。 

rkubootのbufは、もうひとつ欲しい

SIMHのPDP-11エミュレータを使ってUNIXv6について調べています。RK05にインストールされたカーネルを起動するには、ディスクの先頭にあるブートローダ「rkuboot」が使われています。これの主な処理は「fsboot.s」にあります。これはファイルシステムを解釈して、指定されたカーネルのiノードを取得し、その中で参照されているディスクブロックをメモリ上にロードします。UNIXv6のカーネルは、今の目から見れば小さいですが、さすがに直接参照だけでは足らないので、間接参照が使われています。

 

処理の概要は、間接参照のディスクブロックをひとつずつ見ていき、その指し示しているディスクブロックを順番にメモリ上に持ってきます。ここで気になるのが、間接参照のディスクブロックを見る際も、カーネルに相当するディスクブロックを得る際も、512バイト分として確保されている領域「buf」を使っていることです。

 

カーネルに対応するiノードは、メモリ上に確保された「inod」に置かれますから、特に問題はありません。そのiノードの中から間接参照によるディスクブロック番号を得るために、「buf」を使用します。そしてカーネルの一部があるディスクブロック番号が判明すると、その内容を「buf」に持ってくるのですが、こうすることで、先ほどの間接参照として使っていた内容は上書きされてしまいます。「buf」にあるのはカーネルの一部ですから、それをメモリのしかるべき位置にコピーしています。カーネルの次のディスクブロックを得るには、再びiノードを参照して間接参照によるディスクブロック番号を取得する必要がありますが、「buf」には情報がありませんから、またしてもrmblkで読み込む必要があります。この繰り返しが、カーネル全体を読み込むまで続きます。

 

ひとつの「buf」を使いまわしているから、こうなってしまうのではないかと思います。UNIXv6当時のCPUやメモリリソースが限られていたとしても、「buf」ひとつだけで処理しないで、もうひとつあれば良いのにと思うところです。 

rkubootにおける直接参照も間接参照も、カーネルをブートできれば良いと割り切っている

SIMHのPDP-11エミュレータを使いUNIXv6について学んでみようと思っています。マシンが起動され、RK05にインストールされたカーネルがメモリ上にロードされるには、ディスクの先頭にあるブートローダ「rkuboot」が使われます。この主処理は「fsboot.s」にあります。このローダがファイルシステムを解釈して、カーネルを探して、メモリ上に配置し、制御を移すことで、カーネルが動き出します。

 

ファイルシステムを解釈するには、iノード、ディスクブロックの直接参照や間接参照などを取り扱う必要があります。その処理はルーチン「rmblk」にあるようです。UNIXv6当時のファイルシステムは、今日とは異なり、「LARGEフラグ」をみて、直接参照と間接参照を切り替えていたようです。さらにコメントには「huge algorithm is not implemented」とあり、二重間接参照は実装していません。

 

ブートローダの目的は、UNIXのファイルシステムを正確に取り扱うことではなく、カーネルさえ読み込めれば十分であるという割り切りがあるようです。そうであるなら、当時のカーネルは小さなファイルだったので、さすがに直接参照では扱えませんが、間接参照だけで読み込める程度の大きさだったのでしょう。二重間接参照が必要となるほど大きなファイルにはならなかったので、それを実装したところで絶対要らないのが明らかですから、余計なことはしていないのでしょう。

 

しかも、直接参照にしろ間接参照にしろ、ディスブロックとして得られた値が「0」になっていれば、そこで読込みを終えることになります。そのためのロジックは入っていますし、「bno = buf+514.」のように、何故か512+2が指定されていることからわかるように、それなりに考慮はされているようです。しかし、直接参照にしろ間接参照にしろ、いかなる場合も絶対に問題が起きないように念入りに対処するというよりは、「カーネルを読むだけだから、細かいところは気にしなくても良いだろう」と割り切っているのではないかと思われるロジックに見えます。

 

ブートローダは512バイト以下におさめる必要がありますから、エラーチェックをしっかりとか、ファイルシステムを完璧に実装しようなどという理想に走ると、容量をオーバーしてしまうでしょう。問題があることはわかっているけど、仕方ないよねという割り切りを感じるのです。 

リッチーとトンプソンによる「The UNIX Time-Sharing System」は2つある

PDP-11で動作したUNIXv6について学ぼうとすると、真っ先に挙げられるのは「Lions本」と呼ばれる『Lions' Commentary on UNIX』です。僕自身も、アスキー出版局から出た和訳を参考にしています。その中には、次のような箇所があります。

• 『The UNIX Time-sharing System』はオリジナルの『Communications of the ACM』の論文の改訂版である。1か月に少なくとも一度は再読すべきである。

  

この一文の前半にある「論文の改訂版である」というのは、一読しても何のことか分かりませんが、後半の「再読すべきである」は、よく分かります。暗記してしまうくらい熟読せよという意味でしょう。これはネットを検索すれば見つかるので、手元に置いておき、仰せの通りに何度も読み直そうと思います。

 

UNIXv6のブートローダを調べていると、ファイルシステムの構造として「LARGEフラグ」というものがあり、それに応じて、直接参照と間接参照を切り替えていることを知りました。今日でもファイルシステムでは直接参照と間接参照がありますが、「LARGEフラグ」というものは存在しません。何時ごろ無くなったのだろうかとGeminiに尋ねてみたら、UNIXv7で変わったとの回答を得ました。ということは、LARGEフラグがあるのはUNIXv6が最後ということになります。

 

しかもGeminiがいうには、「The UNIX Time-Sharing System」には、1974年のCACM版と、1978年のBSTJ版があるそうです。その「4 Implementation of the file system」の記述内容が大きく変わっているとのことでした。あらためてネットから入手し直してみると、タイトルも著者も同じですが、内容が異なる2つの論文があることを確認しました。

 

UNIXの系統樹などを見ると、BSD版はUNIXv6から派生したように書かれています。直接的にはそうなのかもしれませんが、UNIXv7で加えられた変更をBSDが取り込んだタイミングがあると思います。それは何時だったのでしょうか。BSDの旧いソースを追いかけると、わかるかもしれません。 

rmblkはリターンアドレスを操作する

SIMHのPDP-11エミュレータを利用し、RK05にインストールされたUNIXv6のブートローダ「rkuboot」について調べています。これは「run」により作られますが、主たる処理は「fsboot.s」にあります。この中にあるルーチン「rmblk」は、サブルーチン呼び出しのリターンアドレスを操作しているようです。

 

rmblkが呼び出されると、まず「add $2,(sp)」があります。このままサブルーチンを終える場合もありますが、場合によっては、戻る直前に「sub $2,(sp)」しています。一方でrmblkの呼び出し元では「jsr pc,rmblk」の直後に「br callout」と「mov $buf,r1」が置かれています。普通なら、JSR命令で呼び出したサブルーチンから戻ってくると、その次の命令（ここであれば、BR命令）が実行されることになります。しかしrmblk側でリターンアドレスを操作しているので、戻り方に依っては命令を飛ばし（BR命令は実行されず） 、MOV命令から実行されます。かなり職人芸と言える技だと思います。

 

PDP-11上でUNIXv6が動作していた時代は、現在から比べると、CPU性能もメモリ容量も極めて限られていたので、このような芸当を駆使していたのだと説明されることがあります。確かにその通りかもしれません。そうであったとしても、このような芸当に走るのは、ちょっとやりすぎではないかと思わないでもありません。rmblkが正常終了したか異常終了したかに依って処理を分岐させたいのであれば、他の方法もあるだろうし、そうすることが困難だとも思えません。 

rkubootにはmbootのような行入力の特殊文字がない

SIMHのPDP-11エミュレータを利用し、「SETTING UP UNIX - Sixth Edition」における「Making a Disk From Tape」から「Booting UNIX」の動作を追体験しています。配布されたテープイメージをディスクにコピーする段階では、テープの先頭にあるmbootにより、ディスクからブートする段階では、ディスクの先頭にあるrkubootにより、キー入力された名前のプログラムを探し、それに制御を移しているようです。mbootもrkubootも、Geminiに助けてもらいながら、ロジックの詳細は理解できました。

 

mbootもrkubootもスクリプト「run」で作られます。mbootの中心となるのは「tpboot.s」で、rkubootの中心となるのは「fsboot.s」で、どちらも同じような作りになっています。ただしよく見ると、tpboot.sでは、キー入力を間違った場合の簡易編集機能として「@」や「#」を扱う処理が入っています。しかしfsboot.sにはありません。

 

mbootにしろrkubootにしろ、キー入力時に簡易編集機能が必須というわけではないと思います。あればあったで便利かもしれませんが、なければなくても別に困らないと思います。また簡易編集機能を処理に組み込んだとしても、些細なロジックですから、ブートローダの512バイト制限を気にするほどのことではないと思います。

 

おそらく簡易編集機能は、あってもなくても構わない程度の、おまけ機能なのでしょう。 

rkubootの動作

SIMHのPDP-11エミュレータを使用してUNIXv6について学んでいます。同様の試みはオンラインでも書籍でも数多く存在していますが、カーネル本体がメモリ上にロードされた以降を対象にしているようです。もちろんそれで何の問題もないのですが、いきなりカーネルを学ぶよりも、助走のつもりで、ディスク上のブートローダがカーネルをメモリに読み込むところから調べてみることにしました。UNIXv6のブートローダは、ディスク毎に分かれているようですが、RK05用のrkubootを対象にします。

 

rkubootはスクリプト「run」で作られています。主要部分は「fsboot.s」です。ブート手順については「SETTING UP UNIX - Sixth Edition」の「Booting UNIX」に書かれているとおりです。まずPDP-11のフロントパネルからブートローダをメモリ上に置くプログラムを入力し、実行します。そして読み込まれたブートローダを実行すると、プロンプト「@」が出力されるので、カーネル名称として（例えば）「rkunix」を入力します。こうするとブートローダがカーネルを読込み、制御を移し、カーネルが動き出します。

 

ブートローダ「rkuboot」の概要は上述したとおりですが、「fsboot.s」を追いかけてみると、次のような処理をしていました。

1. 0番地に置かれている自分自身を137000番地に移す。こうしておかないと、カーネルを読み込もうとした際に、ブートローダ自身が上書きされて壊れてしまいます。
2. プロンプト「@」を出力し、カーネルのパス名を入力させまる。ここで、mbootにあったような特殊文字「#」や「@」のハンドリングはありません。またカーネルが階層ディレクトリに置かれている場合でも対処できる処理になっています。
3. 入力されたカーネル名称をファイルシステムから探します。FILE SYSTEM(V)にも明記されているとおり、i番号の「1」がルートディレクトリなのが決まりですから、それを前提に探します。そしてルートディレクトリ（またはサブディレクトリ）に指定されたカーネルが見つかれば、そのi番号をからi-nodeを参照してディスク上のカーネルをメモリに読み込みます。

 

ブートローダですから、上記した内容が全てですが、これらの処理を512バイト以内に納める必要があります。あまり複雑な処理とか、エラーチェックとかをしている余裕がないようで、ある種の「割り切り」があるように思います。例えば、fsboot.sのコメントには「huge algorithm is not implemented」とありますが、これは今日のUNIXにもある「二重間接参照」は実装されていないということのようです。実際問題として、二重間接参照が必要となるほどカーネルは大きくないので、実装しなくても実用上問題ないという「 割り切り」があるのでしょう。他にもエラーチェックなどをしない箇所がありますが、それも「普通そういう事態にはならないはず」という「割り切り」があるのだと思います。

「Making a Disk From Tape」と「Booting UNIX」の対称性

「SETTING UP UNIX - Sixth Edition」の「Making a Disk From Tape」と「Booting UNIX」は、手順が対称的になっていることに気づきました。

 

「Making a Disk From Tape」では、細部を省略すると、次のような手順です。

1. TU10コードをフロントパネルから入力して実行する。
2. mbootがロードされるので、実行されると、プロンプト「=」が出力される。
3. tmrkなどを入力することで、テープからディスクにコピーが行われる。

 

これに対して「Booting UNIX」では、次のような手順です。

1. RK05コードをフロントパネルから入力して実行する。
2. rkubootがロードされ、実行されると、プロンプト「@」が出力される。
3. rkunixなどを入力することで、ディスクからカーネルが起動する。

 

「Making a Disk From Tape」の処理を追いかけてくることで、UNIXv6が動作する以前の世界が理解できました。

RK05は2種類ある

「RK05 disk drive maintenance manual」（DEC-00-HRK05-C-D）に記載されている「Table 1-1 Performance Specifications」には「Sectors(records)」として「4872 (12 per revolution)/6496 (16 per revolution)」とあります。これは何でしょうか。

 

RK05は、片面203シリンダ（含予備）なので、両面ならば406トラックあります。406×12=4872ですし、406×16=6496です。計算は合っていますが、どういう意味でしょうか。Geminiに相談したら、RK05は、1シリンダが12セクタの製品と16セクタの製品が存在したのだと回答しました。そうなのかもしれません。しかし裏付け資料が見つからないので、真偽が定かではありません。

 

UNIXv6の「rk.s」には、「div $12.,r0」という処理があります。この結果がRKDAレジスタ（777412番地）に入ることになるので、12セクタのための処理なのでしょう。しかし、もし16セクタのRK05があるとするならば、その容量を活かせていないことになります。

 

RK05に12セクタ版と16セクタ版が存在すると仮定して、UNIXv6が自動判別する処理を組み込むのは、当時の歴史的事情としては許されなかったのではないかと推測します。どちらかい決め打ちするのであれば、12セクタ版にしておいた方が無難と判断したのかもしれません。 

 

 

tm.sのtreadとrk.sのwblk

スクリプト「run」で作られる「tmrk」の処理の中心は「mcopy.s」にあります。最も重要なのは、「tread」と「wblk」を呼び出して、512バイト（256ワード）のコピーを指定回数分だけ繰り返しているところです。

 

「tread」は「tm.s」にあります。「wblk」は「rk.s」にあります。両者を見比べると、テープを操作するかディスクを操作するかという事だけではなく、大きく違うのですが、論理的には対称になっているはずです。「wblk」の方がシンプルで、「tread」は複雑です。その複雑さに目を奪われてしまうことなく、対称性に注意すれば、「tread」が何をしようとしているのか見えてくると思います。 

mcopy.sにおいて「illegal digit」が出力された場合の挙動

「SETTING UP UNIX - Sixth Edition」の「Making a Disk From Tape」の手順に従って「tmrk」を呼び出すと、「disk offset」、「tape offset」、「count」の入力が求められます。これは「mcopy.s」のルーチン「numb」が呼ばれることで、キーボードから入力された数値がR0に入ります。ここで数字以外を入力すると「illegal digit」というエラーメッセージを出力して、「rts pc」が実行されます。ここで気になるのは、一体何処にもどるのでしょうか。

 

「tmrk」の中で「jsr pc,numb」として呼び出されている訳ですが、「tmrk」の中に戻るわけではないようです。エラー発生時に処理を追いかけていくと「tst (sp)+」をした後で「rts pc」となっています。この「tst (sp)+」が重要です。オペコード「TST」というのは、オペランドを評価してフラグをセットする命令です。普通は直後に条件分岐命令が続きます。しかしここでは「rts pc」が続いていて、フラグの状態には影響されません。

 

要するにここでは、TST命令である必要はなく、「(sp)+」として、SPが変化する事が重要なのです。SPを変化させることで、「tmrk」から呼び出された際の戻り番地を捨て、その上位にある「mboot」に戻るためのテクニックだと思います。そうなら、それが分かりやすいプログラムを書けば良いではないかと思うところですが、こういう職人芸的なプログラムを書くところが当時の時代背景としてあったのでしょう。 

「SETTING UP UNIX - Sixth Edition」の「Making a Disk From Tape」におけるmbootとtmrkの関係

SIMHのPDP11エミュレータを利用し、UNIXv6について学ぼうと考えています。同様の志を持つ方は少なくなく、オンラインでも書籍でも数多くの情報があります。しかしながら、それらはUNIXv6がディスクにインストールされていることを前提としており、「SETTING UP UNIX - Sixth Edition」の「Making a Disk From Tape」について言及されていないように思います。それでも別に構わないのですが、いきなりカーネル本体に取り組むより、例え多くの情報が蓄積されているとしても、まずはPDP-11のCPU本体や周辺機器の扱いに慣れる意味で、「Making a Disk From Tape」の手順や、その処理に精通しておくことにしました。

 

「Making a Disk From Tape」では、TU10の先頭ブロックをロードするコードが提示されています。PDP-11実機であれば、これをフロントパネルから入力し実行することで、配布テープの先頭ブロックがメモリにロードされます。これは、スクリプト「run」で作成される「mboot」であることを突き止めました。これが実行されると、プロンプト「=」が出力され、入力待ちになります。導入手順では「tmrk」と入力することになっていて、これをおこなうことで、配布テープからディスクにUNIXv6がコピーされます。

 

「mboot」も「tmrk」もスクリプト「run」によって作成されるa.out形式ファイルです。しかし両者は独立している訳ではないようで、「mboot」が主、「tmrk」が従の立場で動いているようです。このような主従関係と考えるのは、以下のような挙動だからです。

 

まず「mboot」が0番地からロードされ、実行されると、まず最初に自分自身を137000番地に移して、以降はそちらで実行を続けます。これは、「tmrk」などが0番地からロードされた際に、「mboot」が壊されないためと思われます。この挙動から、「mboot」が主で、「tmrk」が従と見做せます。 

 

さらに「mcopy.s」のでは、文字列を出力するため「jsr pc,4(r5)」のようなサブルーチン呼び出しが存在します。ここでR5は、「tmrk」では設定されていません。「mboot」の方で設定されていることが前提となっています。このような前提で「tmrk」が動作している事実が、主従関係があると判断する理由です。

 

また「tmrk」が実行されると、「disk offset」、「tape offset」、「count」の入力を求め、その入力に応じてテープからディスクにコピーすると、実行を終了してしまいます。実行終了後にどうなるかと言うと、「mboot」に戻るのです。この挙動を見ても、「mboot」が主で、「tmrk」が従だとわかります。

 

「Making a Disk From Tape」の手順6では、「tmrk」の代わりに「htrk」、「tmrp」、「htrp」などを使う場合の記述があります。これらのプログラムは調査していませんが、おそらく「tmrk」と同様だろうと思います。 

mbootとUnix-v6-Ken-Wellsch.tap

「SETTING UP UNIX - Sixth Edition」の「Making a Disk From Tape」で行われた処理について調べています。ここで書かれている手順の概略は次の通りです。

1. PDP-11のフロントパネルを操作し、100000番地からTU10コードを入力し、実行する。
2. テープから先頭ブロックが0番地に読み込まれるので、実行する。これは「mboot」です。
3. 「mboot」の中でプロンプト「=」が出力されるので、テープの内容をディスクに書き込むプログラム名を指定する。ドキュメントでは「tmrk」が指定されています。「mboot」は、指定されたプログラム「tmrk」をテープから探し、メモリにロードし、制御を移します。
4. 「tmrk」が実行されると、指定位置から指定長をテープから読み込み、ディスクに書き出します。

 

UNIXv6が出た当時は、これらの手順を実機PDP-11/40などでおこなったのでしょうけれども、21世紀に生きる我々はSIMHのPDP11エミュレータを使います。そしてテープイメージには、ファイル「Unix-v6-Ken-Wellsch.tap」を使います。

 

「mboot」は、スクリプト「run」によると、「tpboot.s」、「tty.s」、「tm.s」からできています。これらのソースを参照し、SIMHのPDP11エミュレータのデバッグ機能を駆使し、時々Geminiとの対話を繰り返しながら、解析しました。なんとか「mboot」の動作は理解できた気がします。動作の概略は、以下のようになっています。

1. TU10コードにより、「mboot」はメモリ番地0からロードされます。「mboot」の目的は、ユーザが指定した「tmrk」などのプログラムをメモリ番地0からロードして制御を渡すことなので、このままではよくありません。そこで自分自身を上位に移し、プログラムがロードされる場所を空けておきます。上位のメモリ番地は137000のようです。
2. プロンプト「=」を出力し、ユーザからプログラム名を入力してもらい、それをテープから検索します。
   1. プログラムを入力する際、「@」が入力されると、それまでの入力が全て取り消されます。また「#」が入力されると、その直前の入力が取り消されます。
   2. 入力された文字列（「tmrk」など）がテープに存在するか検索します。テープファイル「Unix-v6-Ken-Wellsch.tap」を調べたところ、先頭ブロックには「mboot」が格納されていますが、その次には「hboot」が入っていることがわかりました。その次からTP(V)形式のディレクトリが続きます。PDP11のデバッグ機能を使って動作を確認すると、「hboot」が格納されているブロックから検索を始めていることが分かりました。TP(V)形式のディレクトリではないし、そもそも何故「hboot」がテープに置かれているのか分かりません。 
3. テープ上の場所が分かったら、それをメモリ番地0からロードして、制御を渡します。ただしロードする前に、メモリを全て0クリアしています。未初期化の変数を参照してしまった場合、再現不能なバグが出ないための事前準備でしょうか。

 

テープファイル「Unix-v6-Ken-Wellsch.tap」を解析すると、次のようになっていました。

1. Block#0は、a.out形式の「mboot」が格納されている。
2. Block#1は、a.out形式の「hboot」が格納されている。
3. Block#2からは、TP(V)形式のディレクトリ情報が格納されている。格納されているプログラムは、次の通りです。
   1. 「dldr」（size:000000344,tape:000031）
   2. 「dtf」（size:000004546,tape:000032）
   3. 「hboot」（size:000000724,tape:000037）
   4. 「hpuboot」（size:000000766,tape:000040）
   5. 「hthp」（size:000000624,tape:000041）
   6. 「htrk」（size:000000554,tape:000042）
   7. 「htrp」（size:000000566,tape:000043）
   8. 「mboot」（size:000000674,tape:000044）
   9. 「mcopy」（size:000000660,tape:000045）
   10. 「mem」（size:000012756,tape:000046）
   11. 「reset」（size:000000024,tape:000061）
   12. 「rkf」（size:000000200,tape:000062）
   13. 「rkuboot」（size:000000716,tape:000063）
   14. 「rpuboot」（size:000000730,tape:000064）
   15. 「tboot」（size:000000626,tape:000065）
   16. 「tcf」（size:000004516,tape:000066）
   17. 「tmhp」（size:000000574,tape:000073）
   18. 「tmrk」（size:000000524,tape:000074）
   19. 「tmrp」（size:000000536,tape:000075）
   20. 「uboot」（size:000001000,tape:000076）

Unix-v6-Ken-Wellsch.tapの構造

SIMHのPDP11エミュレータを使ってUNIXv6を学ぼうと考えています。同様の志を持つ人たちが、ネットでも書籍でも多くの情報を提供しています。ただしUNIXがインストールされた環境を前提にしていることが多いように見受けられます。カーネルを学ぶには、インストールが済んだことを前提にする方が良いのだと思いますが、PDP-11について学ぶ練習のため、「SETTING UP UNIX - Sixth Edition」の手順でインストールするところから調べてみようと思います。

 

 SIMHで利用できるテープイメージのファイルが「Unix-v6-Ken-Wellsch.tap」として入手できます。これはSIMHで扱える形式になっているようです。その構造は「SIMH Magtape Representation and Handling」という資料があります。この構造を確認するため、Pythonでスクリプトを組んでみました。

#!/usr/bin/python3

def readblock(f):
    global TapeMark
    global Block
    Block += 1
    len0 = int.from_bytes(f.read(4),'little')
    if len0 == 0:
        TapeMark += 1
        if TapeMark >= 2: raise EOFError
        return 0
    TapeMark = 0
    data = f.read(len0)
    len1 = int.from_bytes(f.read(4),'little')
    print("[%6d]:" % Block, TapeMark, len0, data[:4])
    return 0 if len0 != len1 else len0

TapeMark = 0
Block = 0

with open("Unix-v6-Ken-Wellsch.tap","rb") as f:
    while True:
        try:
            readblock(f)
        except EOFError:
            break
#[EOF]

 これで確認すると、512バイトのブロックが12,100あります。ドキュメントに書かれているとおりです。

 

また先頭ブロックには「mboot」があります。次のブロックには「hboot」が置かれています。その後には「TP(V)」形式のディレクトリが続きます。ブートプログラムとして「mboot」と「hboot」の二つが用意されている理由はなんでしょうか。ドキュメントでは、フロントパネルから入力する「TU16」のプログラムが「(To be added)」となっています。このテープの配布を受けた側がTU10でもTU16でも対応できるようにしておいたのかもしれません。

SDカードは劣化すると「書込み禁止状態」に入るらしい

スマホで写真を撮影しても、撮ったはずの写真が残っていない現象に遭遇しました。「カシャ」という音はするのですが、ファイルが残っていません。アプリの設定を確認すると「SDカードに記録する」という項目があり、「ON」になっていたので、「OFF」に切り替えたところ、問題が解決したようです。

 

スマホで使っているSDカードは、随分前にガラケーで使っていたものです。15年以上前に購入したものだと思います。劣化していてもおかしくはありませんが、記録されている情報は普通に読み取れるのです。最近は、Googleで似たような事例を検索してみるのではなく、Geminiに相談することが増えました。Geminiが言うには、SDカードが劣化して「書込み禁止状態」になっているのではないかとのことです。

 

SDカードが劣化すると「書込み禁止状態」にはいるという事を初めて知りました。Googleで検索してみたら、そういう状況を報告する「SDカードの「書き換え寿命」と、壊れる直前のサイレントサイン 」が見つかりました。壊れるものは仕方がないので、新しいSDカードを購入するしかありません。劣化したSDカードからファイルを救い出すことはできそうなので、完全に壊れて読めなくなる前に、新しいものと交換しようと思います。

 

TU10コードからmbootを経由してtmrkが呼ばれるまで

「SETTING UP UNIX - Sixth Edition」の「Making a Disk From Tape」において、手順3で入力されたコードを実行すると、テープからプログラムがロードされます。simhのPDP11エミュレータを使用し、テープイメージとして「Unix-v6-Ken-Wellsch.tap」を使用する場合、このロードされたプログラムは「mboot」だと思われます。これは「run」の中で、以下のようにして作られています。

as tpboot.s tty.s tm.s
strip a.out
ls -l a.out
cp a.out /usr/mdec/mboot 

 

そして手順5において、プロンプト「=」が表示され、「tmrk」を入力するように指示されています。

 

この一連の処理を追いかけているのですが、「tpboot.s」では、プロンプト「=」を出し、「TP(V)」形式のテープから指定されたプログラム（例えば「tmrk」）を読みだして、制御を移しているだけです。 

 

つまり、「Making a Disk From Tap」では、次のような段階を踏んで、テープにあるUNIXv6をディスクにコピーしていることになります。

1. フロントパネルからTU10コードを入力し、実行する。
2. テープの先頭ブロックにmbootが入っており、それを実行する。
3. mbootがプロンプト「=」を出し、コマンド「tmrk」などを入力すると、mbootがテープから探し出し、メモリ上にロードする。
4. メモリ上にロードされたプログラムが、テープからUNIXv6本体をディスクにコピーする。

 

 処理の流れが見えてきました。これだけわかれば十分とも言えますが、mbootに含まれるtpboot.s、tty.s、tm.sは、PDP-11のアセンブラで書かれていますが、短いので、今後UNIXv6の本体を追いかけていく練習として、ロジックを細部まで見ていこうと思います。

さぁ、ここからはピッチを調節して、あなたが操縦して着陸してください

Windows11でMicrosoft Flight Simulator 2002が動くようになったので、紹介ビデオの直後のフライトに挑んでいます。操作は、ジョイスティックを所有していないので、全てキーボードでおこないます。このフライトは、ゲーム購入直後におこなうものだと思います。飛行用語も操作方法も全く知らずにおこなうので、滅茶苦茶な操縦をしながら、離陸から着陸までを体験します。これがシミュレータなので事故も怪我もありませんが、いきなり飛び立ち着陸させるなんて、本当の飛行訓練ではありえない状況だと思います。

 

離陸は比較的簡単です。エンジンを全開にしてから機首を上げると、離陸できます。空中では、右旋回や左旋回を体験しますが、教官が代わって操縦してくれます。そこまでは、手取り足取りなのに、着陸だけは、「さぁ、ここからはピッチを調節して、あなたが操縦して着陸してください」と言われてしまいます。

 

このソフトを使う人の中には、操縦に関する知識があり、何をすべきか熟知していることもあるでしょう。しかし私は素人なので、何をしたらよいのか、さっぱりわかりません。着陸操作をしろと命じられたら、じゃぁエンジンを切ればよいのだろうかと考えてしまいますが、それでは墜落してしまうでしょう。ならば機種を下に下げれば良いのかとも思いますが、それでは失速してしまいそうです。要するに、何をしたらよいのかわかりません。それなのに教官は「ピッチを操作し、速度を65ノットに保ち、着陸してください」と簡単に言います。もちろんシミュレータですから、操作が酷くても事故にはつながらないのは、十分に承知していますが、困ってしまうのは確かです。

 

飛行機というものは、XYZ軸に応じて、「ヨー」、「ロール」、「ピッチ」という言い方をするようです。教官の言う「ピッチを調節して」というのは、このことを言っているのだろうかと、つい最近気づきました。混乱するのは、計器類の中にピッチトリムというものがあり、教官はこれを操作しろと言っているんだろうかと誤解するのです。

 

何度か離陸着陸を繰り返しているうちに、だんだんわかってきました。しかし空港の滑走路に着陸できたことは一度もなく、建物や樹々に激突します。しかし機体にも自分自身にも何の怪我もないのが、シミュレータですね。

mboot

UNIX V6のセットアップをおこなうドキュメント「SETTING UP UNIX - Sixth Edition」によると、配布テープは「The tape contains 12100 512-byte records followed by a single file mark」だそうです。さらにオフセット100から4000レコードが「バイナリ」、その後の4000レコードが「ソース」、その後の4000レコードが「ドキュメント」との事です。全体として12,100レコードということは、オフセット0から100レコードには、テープを読みこみディスクに書き出すユーティリティが格納されていることになります。

 

ドキュメントの「Making a Disk From Tape」では、TU10コードにより、テープのオフセット0から数レコードを読んでメモリの000000番地以降に展開しています。ここで何を読み込んだのか不明ですし、どのような処理が行われた結果としてプロンプト「=」が出るのか、霧の中です。もっとも、この過程がわからなくても、UNIX V6のディスクを作ることはできます。しかも、わかったところでUNIX V6の本体の理解が進むわけでもありません。そうであったとしても、何故この処理を理解しようとするのかと言えば、今後UNIX V6を学んでいくための準備練習として最適ではないかと考えるからです。

 

TU10コードを実行した後からプロンプト「=」が出るまでの間を理解するため、Googleを検索したり、Geminiに相談したりしましたが、確たる情報は得られませんでした。そうならば、発想を変えて、TU10コードが実行された後のメモリがどうなっているかを調べてみようと思い至りました。「Installing UNIX v6 (PDP-11) on SIMH」で使われている「Unix-v6-Ken-Wellsch.tap」を使用してTU10コードを実行してみました。その後simhのPDP11エミュレータで「e -m 000000-001000」することで、1レコード分を逆アセンブルしてみました。その内容を確認してみると「mboot」であることが確認できました。

 

UNIX V6のソースを確認すると「source/mdec/run」には、次のような箇所があります。

as tpboot.s tty.s tm.s

strip a.out

ls -l a.out

cp a.out /usr/mdec/mboot 

ソースには「source/mdec/tpboot.s」、「tty.s」や「tm.s」もありますから、逆アセンブルした結果を全て確認したら、まさに「tpboot.s」、「tty.s」、「tm.s」そのものでした。これらをアセンブルしたものが「mboot」というバイナリで、これはa.out形式です。サイズは440バイトだったので、1レコードに収まります。ここから考えても、TU10コードでは数レコードを読み込もうとしていますが、1レコードを読み込むだけで十分であることが分かります。

 

次はmbootの処理を追いかけてみようと思います。 

 

 

 

 

UNIX V6の配布テープを読み込む処理

UNIX V6を通してOSについて深く学ぼうと考えています。simhのPDP-11エミュレータを使用しようと考えています。このようなアプローチは、以前よりオンラインでも書籍でも多くの情報があります。それらは、ほとんどの場合において、UNIX V6がディスク上にインストールされていることを前提としています。しかし「SETTING UP UNIX - Sixth Edition」を読むと、前段階として「Making a Disk From Tape」が必要です。これらはOSの挙動とは関係ありませんが、PDP-11の動作を学ぶには格好の素材ではないかと思います。そういうつもりで、この処理を詳しく調べてみることにしました。

 

まず最初におこなうのは、TU10コードを（本物のPDP-11/40なら、フロントパネルから）入力し、テープから「何か」を読み込むことです。ドキュメントにはバイナリコードが記載されていますが、理解しやすくするため逆アセンブルしておきます。これが100000番地から格納されることになります。

100000: MOV #172526,R0

100004: MOV R0,-(R0)

100006: MOV #060003,-(R0)

100012: BR 100012 

 

100000番地で、R0に定数「172526」を代入しています。これは100004番地の処理をするための、準備と言えます。100004番地では、代入先が「-(R0)」となっていますから、まずR0をデクリメントし、そのR0が指しているアドレスに何かを（ここではR0の内容）を代入しています。R0は172526だったのですから、デクリメントすると172524になります。これはTM11のMTBRCレジスタです。代入される値もR0ですから「172524」です。

 

ドキュメント「TM11 DECmagtape system」（DEC-11-HTMAA-D-D）によると、「4.2.3 Byte Record Counter (MTBRC)」で説明されていますが、転送量の2の補数を指定します。ここでは「172524」を指定していますが、これは転送量を2の補数にしたものなので、本当の転送量は、逆算して、「2732」となります。読み取り操作では、ワード数で指定するようです。テープは512バイトを1レコードとしていますが、2732ワードならば、10レコード以上あるし、しかも中途半端です。何故中途半端な値を指定するのかは不明ですが、推測するに、フロントパネルから入力するロジックを短くしたかったのでしょう。おそらく本当に必要なのは1レコードだったと思われますが、それを忠実にロジックに落とすと、ちょっとだけ長くなるので、それを避けたかったのでしょう。今日であれば気にするほどのことではないと思いますが、当時の時代背景を踏まえると、重大問題だったのだと思います。

 

100006番地では、さらにR0をデクリメントしていますから、172522であるMTCに「060003」を代入しています。これもドキュメントの「4.2.2 Command Register (MTC)」より、「DEN8」が「1」で「DEN5」も「1」なので「800bpiの9チャンネルテープ」であり、「Function」が「001」なので「Read」となり、「GO」が「1」なので実行開始されます。

 

最後に無限ループに入りますが、現実のPDP-11/40ならば、操作する人が目視していれば、テープ装置の読取り終了が判断できるのでしょう。 

 

このようにしてテープから読み込まれた内容（おそらく1レコードで十分なはず）が000000番地から書き込まれています。ドキュメントでは、手順4として「Halt and restart the CPU at 0.」と書かれているので、読み込まれたプログラムに制御が移ります。 

PDP-11のJSR命令の挙動と時代背景

PDP-11のJSR命令は、サブルーチンを呼び出すために使われます。x86におけるCALL命令のようなものです。x86に限らず、Z80でも6800でも、同様の命令が存在します。使うには、x86なら「CALL サブルーチン」のようにします。戻り番地はスタックに積まれているので、サブルーチンでは「RET」するだけです。

 

ところがPDP-11では「JSR レジスタ, サブルーチン」のようにしています。このとき戻り番地がレジスタに入りますが、レジスタをR7（=PC） とするなら、戻り番地はスタックに積まれます。要するにx86や6800などと同じ挙動です。サブルーチンを呼び出す命令で、なぜレジスタが出てくるのか分からず、Geminiに相談してみました。Geminiの応答は、自信たっぷりに返事をしますが、必ずしも正しいとは限らないので、話半分に聞いておく必要がありますが、それなりに納得できました。

 

Geminiが言っていたのは、PDP-11が登場した頃の時代背景が理由として考えられるそうです。その要点は、つぎのようなものでした。

1. 当時は、アーキテクチャとしてスタックが今日のように一般的ではなかった。
2. サブルーチン呼出し命令の直後に引数を置いておくテクニックが存在した。
3. コードとデータの分離が不完全で、職人技的技法としてコードを書き換えることもあった。 

 

x86などでは、サブルーチンに与える引数は、レジスタに持つことが多く、少なくともCALL命令の直後に置いておくことはありません。しかも、8080の頃ならいざ知らず、80386以降のプロテクションモードの時代では、実行中にコードを書き換えることはなく、そんなことをしたら保護違反になってしまいます。

 

手元に、共立出版が1978年に発行した『マイクロコンピュータのプログラミング』という本があります。この中で「プログラム技法」（中西正和）では、「2.6 命令の中に命令を作る」として、今日では考えられないテクニックが紹介されています。ここで書かれているのは、バイナリ列「01 FE FF」 があったとすると、先頭から見れは「LXI B,0FFFEH」だが、2バイト目から見れば「CPI 0FFH」と見做せるし、3バイト目から見れば「RST 7」と見做せるというものです。まさに職人技です。そうかもしれないけど、そこまでするかという感じです。このようなテクニックがもてはやされるのは、メモリも少なく、（今日からすると）CPUも遅いという時代背景があるためだと思います。

 

PDP-11のJSR命令における不思議なレジスタの存在も、当時のプログラミング事情として「インライン引数」というものが存在したという時代背景が根底にあるようです。このような事情を知らないと、PDP-11のJSR命令の挙動が理解できない事を学びました。

洗濯時間はこれほど短かったのか

先月、自宅で使用している洗濯機がエラーを出しました。「ピーピーピー」という警告音が鳴った後、操作パネルのLEDが全て点滅していました。その時は、再スタートしたところ、その後は問題ありませんでした。ところが、後日洗濯機を使おうとした際にも、エラーが出てることが多くなりました。もしかしたら故障したのだろうか、買い替えるべきなのかと悩みました。

 

そもそも使用している洗濯機は、製造元が三洋電機です。購入時期は覚えていませんが、20年以上前だと思います。買い替えても良いとは思いますが、自宅で他にも故障が相次いでおり、出費がかさんでいるので、できれば買換えは避けたいところです。

 

何が悪いかわかりませんが、少なくともエラーを出す前から注水の勢いが弱いとは思っていました。水道栓と洗濯機の間が狭くて、ホースが捻じ曲がって配置されています。もしかすると水の通りが悪いのではないかと当たりをつけました。ホースを取り外し、スムースに水が供給されるように、配線を変えてみました。

 

変更した結果、力強く給水されるのが確認され、それ以来エラーも出ていません。これが原因だったのかもしれません。それだけではなく、洗濯時間も短くなりました。以前は2時間くらいかかっていましたが、洗濯量にもよりますが、今は30分ほどで終わります。あまりにも早いので、途中でエラーで止まっているんじゃないかと不安になるくらいです。