Let's note CF-SV8RDCVSに伝統BSD（FreeBSD/NetBSD/OpenBSD）を評価してみました。NetBSDは、無線LANインターフェイス未対応だったため、候補から脱落しました。伝統的なBSD以外にも、次のような新興勢力のBSDがあります。これを検討してみました。
DragonFly BSDには「HAMMER」という独自のファイルシステムがあります。helloSystemやravynOSは独自色が強い印象です。しかし新興BSDは、基本的にFreeBSDをベースにしており、それぞれに方向性は異なるものの、伝統BSDのような違いはありません。
Let's noteにインストールするにあたり、伝統BSDと新興BSDを等価に考えていました。しかし検討してみると、結局は、FreeBSDにするか、OpenBSDにするかの二択に絞られてきました。どちらにするにしても、GUIが欲しいので、デスクトップ環境に何を選ぶのかも決める必要があります。だいぶ絞られてきましたが、もう少し検討を続けようと思います。
Let's note CF-SV8RDCVSにOpenBSD 7.9をインストールしました。FreeBSDとは違い、インストールが終わるとxenodmでグラフィカルにログインできますが、起動するのはtwmです。OpenBSDらしい硬派な環境ではありますが、デスクトップ環境を入れようと思います。FreeBSDで各種デスクトップ環境を試してみました。OpenBSDでは、FreeBSDよりは選択肢が少なくなりますが、メジャーなKDE plasmaを入れることが可能です。
OpenBSDでパッケージからインストールするにはコマンド「pkg_add」を使用します。OpenBSD Handbookの「Desktop Environments and Window Managers」を参考に「doas pkg_add kde-plasma」とすると、460個ほどのパッケージがインストールされました。xennodmからログインすると、KDE plasmaが起動します。FreeBSDでは「KDE plasma Version 6.6.6」でしたが、OpenBSDでは「KDE plasma Version 6.6.4」でした。
日本語環境として、フォント「noto-cjk」 と日本語入力「fcitx-anthy」を入れておきます。この後で、KDE設定から「Region & Language」として「日本語」を選択します。ログインし直すと、日本語環境になりました。
この後は更にFreeBSD同様にアプリケーションを入れて評価しようと考えていたのですが、動作が若干怪しいです。アプリケーションのアイコンをクリックしても起動せず、ホームディレクトリにはコアがあります。何が原因なのかは調べていませんが、ほぼ何もしていない段階で動作が不安定になると、使い続ける意欲が下がるのは否めません。
OpenBSDの評価は、ここまでにしようかと思います。FreeBSD/NetBSD/OpenBSDと伝統的なBSDをLet's noteにインストールしてきました。NetBSDは無線LANインターフェイスが未対応でしたし、OpenBSDはKDEの動作に不安があります。今後は、新興BSDを試してみようかと思います。
Let's note CF-SV8RDCVSにOpenBSD/adm64 7.9をインストールしました。有線LANを有効にしておいてインストールしたので、有線LANは使えますが、無線LANを有効にする設定が必要です。直前にインストールしたNetBSD/amd64 11.0では、Let's noteの無線LANインターフェイスが認識されませんでした。しかしOpenBSD/amd64 7.9は、「iwm0」として、ちゃんと認識されています。
無線LANの設定は、FreeBSDやNetBSDでは「wpa_supplicant」が使われます。ところがOpenBSDでは勝手が違うようです。「HOSTNAME.IF(5)」に従い「/etc/hostname.iwm0」を準備します。『OpenBSD Frequently Asked Questions』の「Wireless Networking」も参考にします。接続先が未来永劫にわたり1つしかないのであれば、それ専用の記述方法があるようですが、ノートPCですから出先で接続する可能性があります。このため「join」を使う記述方法にしました。
wpa_supplicant.confでは、暗号キーを暗号化してファイルに格納しましたが、hostname.iwm0ではべた書きするようです。心配なので、0600にしておきました。
ファイルを用意して、再起動したら、あっさり繋がりました。もう少し何かあるかと思いましたが、簡単でした。
OpenBSDは、まだ初期インストールして、無線LANが繋がるようになっただけです。ここから、FreeBSD同様に、各種環境を整えていこうと思います。
Let's note CF-SV8RDCVSにOpenBSD/amd64 7.9をインストールしました。このマシンには、FreeBSD/amd64 15.1-RELEASE、NetBSD/amd64 11.0をインストールしてきましたが、いろいろな伝統的BSDや新興BSDを入れてみて、気に入った環境を探そうと思っています。
OpenBSDのインストーラは、「硬派」です。親切なGUIではないし、NetBSDのようなテキストベースのウィンドウでもありません。コンピュータ黎明期のUIのようにも見えます。
インストール中に「Do you want the X Window System to be started by xenodm(1)?」という質問で「yes」としておきました。インストールに成功し、再起動したら、xenodmというディスプレイマネージャが出てきました。ログインするとtwmという、これまた「硬派な」環境が立ち上がりました。
今の段階では、初期インストールが済んだだけです。FreeBSDのように、いろいろな設定をしていこうと思います。
自宅の庭の雑草をとるのに「草刈鎌」を使ってきました。手間がかかりますが、なんとかなりました。大変なのはもちろんですが、刈り終わったところが綺麗になっているのを見るのは、爽快です。
何年か前から、近所には町内会がボランティアで掃除している公園があり、そこの草刈りを将来的には手伝って貰えるとありがたいと言われるようになりました。そうなると手作業では大変ですから、刈払機が必要です。刈払機があれば、自宅の庭でも使えるので、検討に検討を重ねて、先月HiKOKIのCG18DAを購入しました。本体にはチップカッターが付属していましたが、自宅の庭で使うにはナイロンカッターの方が良さそうです。HiKOKIの別売り製品は高額なので、ホームセンターで安価なものを購入しました。また、充電器などの付属品を収納するため、これもホームセンターで手ごろな工具箱を購入しました。
準備万端整えて、自宅の庭で初めて刈払機を使ってみました。ナイロンカッターなので、土埃が飛びますが、あっという間に雑草が無くなっていくのは驚きです。また塀際などの雑草も刈れるので、とても助かります。バッテリは30分くらいしか持ちませんでした。
刈払機の威力に驚きましたが、地面の上にある雑草を刈り取っているだけです。これまで手作業でやっていたときは、地中の根も取り除いていたので、同じことが刈払機で出来るわけではありません。今後は、刈払機と手作業を併用していくことになると思います。
Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールし、アプリケーションを入れたり、デバイスを使えるようにしたり、いろいろと調査してきました。なかなか悪くないと思いますが、他のBSDも試してみて、最終的に何を使うか決めようと思います。そういうことで、今度はNetBSD/amd64 11.0をインストールしました。
インストールそのものは、普通です。NetBSDのインストーラは、地味で、Ubuntuなどに比べると不親切と評されることもあります。そういう印象はありますが、インストール自体は、問題なく終わりました。
無線LANを設定しようと思い、「ifconfig -a」 してみると、デバイスが出てきません。Geminiに救いを求め、「pcictl pci0 list」したところ、「000:20:3: Intel Dual Band Wireless AC 9560 (miscellaneous network, revision 0x11)」と認識されています。ところがマニュアル「IWM(4)」では「The iwm driver provides support for Intel Wireless 3160, 3165, 3168, 4165, 7260, 7265, 8260, and 8265 PCIe Mini Card Ual Band newtork adapters.」と書かれており、未対応のようです。
Let's note CF-SV8は、2019年頃に登場したマシンですから、それほど最新機種ということもありません。FreeBSD/amd64では無線LANが使えていましたから、故障しているわけではありません。NetBSDのポリシーとして、綺麗に設計しようとしていて、対応が遅れているのでしょう。いつかは対応されると思いますが、今は使えないのは確かです。
NetBSDは諦めることにします。次はOpenBSDを試そうと思います。
Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールしました。このマシンには内蔵カメラがついています。これまで所有してきたデスクトップPCやノートPCで内蔵カメラがあるのは初めてです。当面使う予定はありませんが、ちょっと試してみました。
設定手順は難しくありません。
pkg install webcamd」でwebcamdをインストールします。sysrc webcamd_enable="YES"」しておいて、「service webcamd start」すべきなのですが、一時的なテスト目的ですので、以下の手順で直接起動しました。これで設定できたので、内蔵カメラを使ってみます。
以上で、動作は確認できました。当面利用することはないのですが、何かの折に役立つのではないかと思います。
Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールしました。このマシンにはBluetoothがあります。Bluetoothを積極的に使ってみたいという訳ではないのですが、どんな風に使うのか気になったので、設定してみました。
設定手順は難しくありません。
pkg install iwmbt-firmware」でファームウェアパッケージをインストールします。usbconfig | grep -i bluetooth」でデバイスの番号を確認しておきます。iwmbtfw -d ugen0.3 -f /usr/local/share/iwmbt-firmware」でファームウェアを転送します。ここでは「ugen0.3」が前項で確認したデバイス番号です。
これで設定できたので、Bluetoothを使ってみます。
hccontrol -n ubt0hci Read_BD_ADDR」でBluetooth MACアドレスを読み取ってみます。hccontrol -n ubt0hci Inquiry」で周辺にある機器が反応するか確認してみます。
Bluetoothに対応した機器はスマホくらいしか所有していません。「Inquiry」で検出できたのは確認しました。しかしBluetoothを使って、何かをしようという気にはならなかったので、確認はここまでとしました。
記事「Windows 11の大型アップデートKB5124008で深刻な不具合続出…「更新を遅らせるな」の直後に混乱発生」によると、「ファイル履歴(File History)がバックアップ用ドライブを認識しないという報告が多数上がって」いるそうです。私が「ファイル履歴」が動かなくなったのも、これが原因なのかもしれません。
マイクロソフトは「ファイル履歴」を重視していないように見受けられます。推測となりますが「OneDrive」を推しているのでしょう。
もしかすると、この問題が解決するパッチが出るかもしれません。しかし私自身は、「ファイル履歴」からFreeFileSyncに移行するつもりです。
Windows11では「ファイル履歴」の動作が怪しいので、FreeFileSyncを使用して同等機能を実現しようと思います。ちょっと試したら、ほぼ期待したようになったのですが、こちらはこちらで動作が怪しいです。
同期元はWindows11で、同期先はFreeBSD上のSambaです。初回は同期対象ファイルを全てコピーします。これは想定しているとおりです。問題は、2回目以降の同期対象ファイルが多すぎることです。ログを残す設定にしているので、どのファイルがコピーされたのかは把握できます。しかし、全く変更していないファイルが同期対象ファイルとして選ばれています。これは、FreeFileSyncにおける「比較」処理の問題です。
FreeFileSyncでは、同期元と同期先のファイルを「比較」し、同期対象ファイルを選択します。この「比較」では、「変更日時とファイルサイズ」、「ファイル内容」、「ファイルサイズのみ」という手段が提供されています。よく利用されるのは「変更日時とファイルサイズ」のようです。
FreeFileSyncには、デバッグ用ログというものが存在しないので、挙動を観察して状況を推測するしかありません。同期対象として選択されるファイルについて、Windows11側とSamba側のタイムスタンプの精度が関係している気がします。Windows11側では秒以下の時間も記録しているようですが、Samba側では記録していないようなので、「比較」すると「差異がある」という判断になってしまうようなのです。
それでは「比較」を「ファイルサイズのみ」でおこなうことにしたら、うまくいくのではないかと思い、試してみました。ところが相変わらず、全く変更していないファイルが同期対象ファイルとして選択されてしまいます。「比較」には「ファイル内容」という手法もありますが、ファイルの内容を読むのは処理時間が相当長くなる恐れがあるので、試してみるのは避けようと思います。
2回目以降の同期で誤って同期対象ファイルを選択していると思われるのは、全ファイルの1%弱なので、スッキリと納得はできませんが、このまま利用を続けてみようと思います。
自宅で使用しているデスクトップPCは、Windows8からWindows10に移行し、昨年にはWindows11を使っています。Windows10の頃から「ファイル履歴」を使用してきました。普段のオペレーションで、うっかりファイルを削除してしまったり、上書きしてしまったことがあり、その場合に救出するのに役立ちました。
Windows11になってから、「ファイル履歴」の動作がWindos10の頃とは違う気がしていましたが、動作はしていました。しかし数日前に動作が止まり、再実行させようとしても、「ファイル履歴のドライブに再接続してバックアップを実行するまでの間、ファイルは一時的にハードドライブにコピーされます。」というエラーがでてしまいます。解決を試みましたが、動作するようになりません。
Geminiに相談すると、Windows11では「ファイル履歴」を非推奨にしようとしている傾向がみられるとのことでした。そうであれば、もう「ファイル履歴」を使い続けるのは諦め、何か別の手段に移行しようと思います。FreeFileSyncというものがあるそうなので、使ってみようと思います。
Let's note CF-SV8RDCVSに様々なディスプレイマネージャをパッケージからインストールしてみました。最初はKDEと親和性が高いSDDM、次にGNOMEのお友達のGDM、それからLightDMなどです。全て「pkg install」でインストールしました。その時に画面をよく見ていなかったのが悪いと言われれば、その通りなのですが、これらのディスプレイマネージャは、共存できないようです。つまり、他のディスプレイマネージャをインストールしようとすると、既にインストールされているディスプレイマネージャは、自動的に削除されてしまいます。
ディスプレイマネージャを使うには、/etc/rc.confに「lightdm_enable="YES"」のような設定が必要です。昔はエディタで手書きしていましたが、今は「sysrc」というコマンドを使うのが推奨されているようです。
複数のディスプレイマネージャを入れると、/etc/rc.confに「sddm_enable="NO"」とか「lightdm_enable="YES"」のような設定が残ります。複数のディスプレイマネージャを「YES」にするのは、さすがにマズいと思いますが、どれか一つだけを「YES」にして、残りを「NO」にするのは、問題ないと思います。それでは、「YES」と「NO」を切り替えながら、複数のディスプレイマネージャを切り替えて使えるのかというと、どうも違うようです。つまり、そのYESやNOの設定とは無関係に、最後に「pkg install」したディスプレイマネージャ以外は、削除されているからです。
もしSDDMをインストールし、「sddm_enable="YES"」としたとします。次にLightDMをインストールし、「lightdm_enable="YES"」として、忘れずに「sddm_enable="NO"」とします。さて、再度SDDMを使う場合は、どうなるでしょうか。「sddm_enable="YES"」とするだけではダメなのです。何故ならSDDMのパッケージは、LightDMをインストールした際に削除されているからです。あらためてSDDMをインストールし直さなければなりません。
KDEやXfceのようなデスクトップ環境は、複数インストールしておいて、切り替えて使用できます。しかしSDDMやLightDMのようなディスプレイマネージャは、複数インストールできませんので、切り替えてるつもりなら、そのたびにインストールが必要です。
ディスプレイマネージャもデスクトップ環境のように、複数インストールして、切り替えて使用できても良いような気もしますが、できない「仕様」のようです。ちょっと混乱して、勘違いしてしまいました。
Let's note CF-SV8RDCVSにインストールしたFreeBSD/amd64 15.1-RELEASE環境で、KDE、GNOMEに次いでXfceを入れてみました。導入手順は、これまでと同様で、『FreeBSD Handbook』の「8.2.3. XFCE」に従いました。GNOMEでは手順通りでは動作しなくて苦労しましたが、Xfceはあっさり動作しました。
これまで、KDEやGNOMEをインストールしてきたので、Xfceのプログラムメニューには、KDEやGNOMEのアプリケーションも出現しています。しかも、KDEでは、note-jpやfcitx5-anthyなどの日本語環境を整えておいたので、Xfceでも日本語環境が引き継がれています。そういうものなのでしょうか。デスクトップ環境を入れるたびに、個別に日本語環境を設定する必要があると思い込んでいたので、何もしなくて済んで有難いことです。
ディスプレイマネージャはLightDMです。これまでインストールしたKDEやGNOMEを選ぶこともできます。その日の気分でディスプレイ環境を切り替えられるというのも、予想外なので、驚きです。
Let's note CF-SV8RDCVSにFreeBSD 15.1-RELEASEをインストールしました。X.orgを使ってデスクトップ環境としてGNOMEを入れてみました。GNOMEを使えるようにはなりましたが、GDMではなく、LightDMが必要でした。
FreeBSD公式サイトにある『FreeBSD Handbook』の「8.2.2. GNOME」に従って作業しました。とても簡単で、KDEの時と同様かと思いましたが、一筋縄ではいきませんでした。
LightDMならば、ログインに問題はなく、GNOMEも動作しました。GNOMEは、先日のKDEとは大きくことなり、画面操作の感覚がつかめません。しかも、気のせいかもしれませんが、KDEよりも重い気がします。当初は、KDE同様、日本語環境の設定などをしてみようと思っていましたが、意気消沈しました。KDEに続いてGNOMEを入れた目的は、Let's noteに様々な環境を構築してみて、気に入った構成を探すためです。その一環としてGNOMEを入れましたが、候補からは外そうと思います。
次は、『FreeBSD Handbook』でGNOMEの次に記述されているXFCEを試そうと思います。
Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールし、デスクトップ環境にはKDE Plasmaを使いました。GUIのログイン画面をデスクトップマネージャと呼ぶようですが、KDEではSDDMを使います。デスクトップ環境とデスクトップマネージャは一心同体のように見えますが、本当に問題ないかどうか不確かですが、基本的に両者は独立していることになっています。つまりデスクトップ環境はKDEでも、デスクトップマネージャをSDDM以外にすることができることになっています。
いろいろなデスクトップマネージャを試してみましたが、結果として成功しませんでした。仕方ないのでSDDMに戻そうとしたら、あろうことかSDDMも動作しなくなってしまいました。どこかのログにエラーメッセージが出ているかもしれないので、それを手掛かりに復旧しても良いのですが、KDEの代わりにGNOMEを試そうかと考えています。
FreeBSDでデスクトップマネージャを切り替えるには、基本的にpkgからインストールし、起動するデスクトップマネージャを/etc/rc.confで有効化します。デスクトップマネージャによっては、他のファイルにも設定する場合があります。これが基本作業ですが、試したデスクトップマネージャは、次のとおりです。
うまくいかなかった状況は様々です。GDMは、エラーメッセージがでて、そもそも起動しませんでした。LXDMは、pkgにありませんでした。LightDMとXDMは、ログイン画面は出たのですが、ユーザ名とパスワードを入力してもデスクトップ環境に遷移せず、ログイン画面に戻ってしまいます。
ちょっと試してみて駄目だったので直ぐに諦めましたが、ログなどを参照して解決できるのかもしれません。
Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールしました。X.orgでKDE Plasma 6を入れて、日本語環境も整えました。このマシンは、dynabook SS SX/15Aの代替として使っていくつもりです。dynabookは、当初Windows Vistaでしたが、NetBSD/i386に変更しています。旧いマシンだから劣化しただけではない気がしますが、起動しているだけでもバッテリを使い切ってしまうので、ACアダプタを常時つないでいました。それに比べるとLet's noteは、バッテリがもちます。感動的です。
FreeBSDの電力設定を見直して、よりバッテリがもつようにしておきたいと思います。このために、以下の設定を変更しました。
1番目の設定は、当初「hw.acpi.cpu.cx_lowest: C1」 でした。「sysctl dev.cpu.0.cx_usage」すると「dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 71921us」のようになりました。この設定を「/etc/sysctl.conf」に加えると「hw.acpi.cpu.cx_lowest: C8」となり、cx_usageも「dev.cpu.0.cx_usage: 17.34% 67.87% 14.78% last 34861us」のようになりました。
2番目の設定は、当初「0」でした。Geminiのアドバイスでは、「1」が推奨されるとのことなので、「/boot/loader.conf」に設定を追加しました。
これらの設定を見直したことで、より長くバッテリがもつと良いのですが。
Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールしました。それからX11でKDE Plasma 6を入れ、日本語設定なども済ませました。ここまでは、一般的なインストールに過ぎません。Let's noteにはSDカードリーダが内蔵されているので、これを使ってみます。
まず最初にGeminiに相談してみました。すると設定方法を指南してくれたのですが、結局は何も追加設定することなく、SDカードが利用可能でした。まずpciconfでは、次のように認識されています。
sdhci_pci0@pci0:58:0:0: class=0x080501 rev=0x01 hdr=0x00 vendor=0x1217 device=0x8520 subvendor=0x1217 subdevice=0x0002
vendor = 'O2 Micro, Inc.'
device = 'OZ777 SD/MMC Card Reader Controller'
class = base peripheral
subclass = SD host controller
特に設定することもなくSDカードを挿入すると、勝手にマウントしてくれました。dmesgでは、次のメッセージが残っています。
mmc0: <MMC/SD bus> on sdhci_pci0
mmcsd0: 2GB <SD 00000 1.0 SN 75792127 MFG 11/2010 by 27 SM> at mmc0 50.0MHz/4bit/65535-block
もうちょっと何かすることがあると予想していたので、いい意味で裏切られました。
Let's note CF-SV8RDCVSにFreeBSD 15.1-RELEASEをインストールしました。このままでは、デスクトップ環境も日本語環境もありません。そこでX.org、KDE Plasma 6、fcitx5-anthy、noto-jpなどを入れて、ひととおり環境を整えました。ここまででならば、一般的なインストールにすぎません。せっかくLet's noteを使っているので、その特徴的な円形タッチパッドを有効にしてみようと考えました。
結論からいうと、駄目でした。
そもそもタッチパッドがうまく認識できていないのです。「Let’s Note CF-SZ5 のタッチパッドクルクル OK。」には「一番最後が model Generic PS/2 mouse か model Synaptics Touchpad の違いです。」とあるように、どう認識されているかが重要です。Geminiに助けてもらいながら、いろいろと試してみたのですが、うまくいきませんでした。Geminiに言わせれば、OSレベルで認識できていないので、KDEだろうがGNOMEだろうが、たぶん駄目だろうとのことです。
FreeBSD 15.1は、すべてのLet's noteにおいて円形タッチパッドを使えないのか、たまたまCF-SV8RDCVSが駄目なのかは不明です。当面は円形タッチパッドとして鑑賞するにとどめますが、ゆくゆくは機能するようになって欲しいと思います。
Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールしました。それからX.orgでKDE Plasmaを入れましたが、このままでは日本語環境がありません。日本語環境として、日本語フォントを日本語変換エンジンを入れます。
最初に日本語フォントを入れました。IPAexにしようかと思いましたが、調べてみるとnoto-jpが良さそうです。
これで日本語が表示できるようになりましたので、次は日本語変換エンジンです。ネットの情報を調べるとKDEなら「fcitx-mozc」が選ばれているようです。しかしパッケージからは消えていました。それならば「ibus-mozc」にしようかとも考えましたが、これもありませんでした。そうなると「ja-fcitx5-anthy」をインストールすることにしました。インストール中に多少手間取ったところはありましたが、ほぼ問題なくインストールし、設定を終えました。
me:\
:charset=UTF-8:\
:lang=ja_JP.UTF-8:\
:setenv=XMODIFIERS=@im=fcitx,GTK_IM_MODULE=fcitx,QT_IM_MODULE=fcitx:
これで日本語入力もできるようになりました。以前にdynabook SS SX/15AにNetBSD/i386をインストールした時は、そうとう苦労して日本語環境を整えましたが、あまりにも簡単なので、驚きです。
Let's note CF-SV8RDCVSにX.orgをインストールしました。twmが使えるようになりましたが、素朴すぎます。『FreeBSD Handbook』の「Chapter 8. Desktop Environments」に従ってデスクトップ環境を入れようと思います。まずは「KDE Plasma」を入れてみます。
インストールは簡単です。以下のコマンドを入力するだけです。
これだけでも良いようなのですが、ディスプレイマネージャ「SDDM」も入れてみます。
ここで再起動したら、SDDMのログイン画面が出ました。しかしパスワードを入力しても、入力を間違っているわけでもないのに、ログイン画面に戻ってしまいます。ログファイル「/var/log/sddm.log」をGeminiに見てもらったところ、「Plasma (Wayland)」として動作しようとしているとのことでした。ログイン画面の左下をよく見ると「デスクトップセッション: Plasma (wayland)」と表示されています。ここで「Plasma (X11)」に変更して、改めてパスワードを入力すると、KDE Plasmaが使えるようになりました。Geminiによると、FreeBSDでpkgでインストールすると、初期状態が「Plasma (Wayland)」になっているそうです。
将来的にはWaylandに一本化されるのかもしれませんが、現状ではX.orgの方がトラブルが少ないようです。
中古で先月購入したLet's note CF-SV8RDCVSにFreeBSD 15.1-RELEASEのインストールを済ませました。これだけではXが使えないので、『FreeBSD Handbook』の「Chapter 5. The X WIndow System」に従って、X.orgをインストールしました。
手順に従い、次のコマンドを入力しました。
このあと「一般アカウント名」でログインし、startxしてみましたが、エラーになりました。インストールしたドライバが読み込まれていないようなので、再起動してから改めてstartxしたらtwmが動作しました。
xtermでキーしてみたら、どうもキー配列がASCIIになっているようです。設定を調整する必要がありそうなのですが、twmを常用するわけではないので、デスクトップ環境のインストールに進みたいと思います。
東大版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に相談してみようと思います。
最近購入した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を用いるようにした方が良さそうです。
Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールしました。インストール中は有線でネットワークに繋ぎました。今後デスクトップ環境を入れていくつもりですが、その前に無線LANの設定を済ませておこうと思います。
『FreeBSD Handbook』では「7.4. Wireless Networks」として設定手順が説明されています。それに従って作業すると、次のようになります。
ところが繋がりませんでした。これまでは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が使えるようになりました。若干トラブルがありましたが、とても簡単でした。
最近入手した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が無事に起動しました。
共立出版の『マイクロコンピュータのプログラミング』に掲載された東大版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バイト分ずらして領域を確保しているのですが、極めて技巧的です。
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)�F
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チューニングされているという感じにはなりました。
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から起動させたい場合は、いちいち設定画面に入ることになりそうです。
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は、様々な状態の中古が出品されていて、それを絞り込むのがまた一苦労です。絞り込むための条件として、次のようにしました。
このような条件で、先月までショップをウォッチし続け、今月に入り実際に購入するため最終確認をしたところ、候補が数件まで絞り込まれました。今週頭に、条件に合う候補をひとつに絞り、注文し、今日到着したところです。
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環境に移植してみるため、出力ルーチンが出来たので、引き続き入力ルーチンも書いてみました。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
# 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環境に移植してみようと思います。基本方針としては、オリジナル版の仕様を再現することに主眼をおき、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"
simhのAltair 8800シミュレータ上で東大版Palo Alto Tiny BASICが動作し、Tiny Trekも動きました。ひとまず区切りがつきましたが、これを他の環境に移植してみても面白いのではないかという気がします。他の環境というのは、具体的にはつぎのようなものを思い描いています。
いずれの環境であっても、アセンブラで書いてみようと思います。オリジナルはOSを意識しておらず、シリアルポートの先にASR-33が接続されているのを想定しています。しかし入出力はOSのが提供する機能を利用しようと思います。それでも、行編集のような便利な機能はつかわず、ASR-33並みの原始的な行入力にしておこうと思います。
またオリジナルの8080版では、整数16ビットを想定しています。amd64なら整数32ビットにすることもできるかもしれませんが、そういうTiny BASICの仕様を拡張するようなことはしない方針です。できるだけオリジナルと同じ仕様にしておきつつ、動作環境が8080ではないという方向で考えています。
データ構造やサブルーチンなども、オリジナルの東大版Palo Alto Tiny BASICと同じようにしようと考えています。発表当時の時代背景を踏まえて、BASICソースは、メモリ上に単純に置かれています。ソフトウェア工学的には、メモリ上の持ち方を変えればスマートかもしれませんが、そういうこともしないつもりです。所詮はTiny BASICなので、大規模と言ってもTiny Trekのような高々200行弱のプログラムで十分です。何千行もあるようなプログラムになることは考えず、最適化されたアルゴリズムを採用しません。
いろいろな環境を考えているとはいっても、いきなり全てはできません。まずはamd64環境から始めようと思います。
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:
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を開発した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.」のような箇所もあり、メモリが少なかった当時の努力を感じます。
「日本語力ソフトで郵便番号から住所入力、Googleは大口事業所個別番号対応」という記事を読んだら、「例えば、「いま」と入力すると、現在時刻が変換候補に現れる（図1）。」と書かれていました。「いま」以外にも、「あす」や「ことし」なども受け付けるようです。では、受け付けてくれる候補は何があるのか、一覧はないのでしょうか。
Geminiに相談したら、気軽に「ここにありますよ」と答えてくれたのですが、そんなリンクはありませんでした。こういう雑な反応は、Geminiらしいところです。
受け付けられる文字列が分かっているなら、入力時に意識しようとも思います。しかし何が受け付けられるのかわからないのであれば、「ことし」が「2026年」に変換される機能があったとして、最初から「2026年」と入力するだろうと思います。
ネットを見ていたら「自動車に「再生鉄」、トヨタも採用 東京製鉄トップが語る変化の兆し」という新聞記事が目に入りました。スクラップを再生した鉄を使用することでリサイクルを目指すようです。
どうしたことか「再生鉄」という文字を見たら、鉄道ファンの新しいジャンルかと勘違いしました。近年は、鉄道ファンという表現をすることは少なくなり、「乗り鉄」とか「撮り鉄」などと呼ばれます。それだけではなく、「座席鉄」や「顔鉄」などというニッチな表現もあるようです。「あなたは、何鉄ですか？」と問われることもあるらしいのですが、その質問自体がナンセンスというか、何故それほどまでに細分化したがるのか謎です。元々は「鉄道ファン」と呼ばれた愛好家は、「鉄道マニア」とも呼ばれ、「鉄道オタク」とも「鉄ちゃん」とも呼ばれましたが、この頃は「鉄道全般の愛好家」という意味であって、特定の一部を強調することはありませんでした。写真も撮るし、乗車して旅行もするし、模型も作るという、何でも屋でした。
閑話休題。あまりにも細分化され過ぎた表現を見過ぎたせいか、「再生鉄」を見たとき、「おっ、新しい鉄道ファンのジャンルか？でも「再生」の鉄って何？」と、ズレた疑問を抱いてしまいました。
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時代に戻って不完全燃焼をやり直す話」という小説がネットで連載されているのを偶然知りました。小説なので、当時の時代の状況を正確に反映しているわけではなく、天才的な(?)主人公が、周囲の人間を巻き込み（翻弄し）ながら、テクニカルな成果を次々にあげていくという内容です。とても楽しく読んでいます。
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のプロセッサ」という記事では、参考文献として雑誌「bit」の記事が参照されています。国立国会図書館のデジタル資料に雑誌「bit」があるので、確認してみました。
1974年8月号～12月号までは、PLAN言語の連載記事があります。ただしデジタル資料は館内限定公開と指定されているので、読みたければ国立国会図書館に行くしかありません。
1977年1月号～1978年3月号までは、SIMPLE言語の連載記事があります。雑誌「bit」は館内限定公開のデジタル資料です。しかし、この連載を単行本化した『やさしいコンパイラの作り方』（中西正和・大野義夫、共立出版、1980年）は、デジタル資料になっており、個人送信も可能として指定されているので、アカウントがあれば自宅でも読めます。
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」は、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のソースプログラムで指定されている値を変更しておきたいと思います。
TiddlyWikiをFirefoxで利用しています。2026年7月22日にFirefox 153.0がリリースされたのですが、アドオン「File Backup Utility For TiddlyWiki」が動かなくなりました。ブラウザがバージョンアップすることでアドオンが動かなくなるという事例があるようです。「File Backup Utility for TiddlyWiki」が今後動作しなくなるのか、対応版がリリースされるのか、現時点では情報がありません。
昔からFirefoxでTiddlyWikiを使ってきました。このアドオンも相当前から利用しています。ハノイの塔方式でバックアップしてくれるのも有難いですが、最も助かっているのは、TiddlyWikiでTiddlerの編集が終わると自動的に保存処理をしてくれるところです。
このアドオンを使い始めた頃は他に選択肢はありませんでした。しかし今は「timimi」もあります。状況によっては、アドオンを乗り換えるかもしれません。
共立出版の『マイクロコンピュータのプログラミング』に掲載されている「東大版Palo Alto Tiny BASIC」をSimHのAltair 8800シミュレータで動くように変更を加えてみました。共立本に掲載されているプログラムの実行環境が不明ですが、SDK-80だろうと思います。本文にはテレタイプと書かれていますが、その入出力はi8251を使っています。一方で、Altair 8800では、シリアルインターフェイスはMC6850が使われています。
Altair 8800に対応させるには、i8251を意識している箇所を、MC6850に対応させる必要があります。具体的には、次のようにします。
定義を変更するだけで、とりあえず動いてくれました。
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
>
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」と呼ばれるものは、共立出版の『マイクロコンピュータのプログラミング』に掲載されているものと、雑誌アスキーに掲載されているものがあります。両者の違いを詳しく確認したわけではありませんが、ちょっと見ただけでも違いがあります。
共立版の方には何も情報がないのですが、アスキー版には「8080 MACRO ASSEMBLER, VER 2.0」という文字があり、また「FOR SDK-80 VERSION」とも書かれています。「東大版Palo Alto Tiny BASIC」を学ぶため、どちらを使うか迷うところです。共立版の方が内部構造の説明が詳しいので、共立版を使おうと思います。
ひとまず書籍に掲載されているソースコードを入力したファイルを作成しました。これをアセンブルしようと思いますが、Windows11で利用可能なzasmを使おうと考えています。アスキー版にある「8080 MACRO ASSEMBLER」というのが、どういうものなのか分かりませんが、共立版も同じなのでしょう。zasmを使うなら、変更しておく箇所があります。
もう一つ考えておく必要があるのは、実行環境です。おそらくSDK-80を想定していると思われます。私は、SimHのAltair 8800エミュレータを使おうと考えています。文字入力や文字出力に関わる部分を変更する必要があるでしょう。
薬缶とは呼ばずに、ケトルと呼ぶのは、なぜだろうかと思いますが、ドリップコーヒーを淹れるのに使われることが多いケトルが壊れたので買い替えました。いつ買ったのか覚えていませんが、30年くらい前なのかもしれません。握り手を本体に溶接してあるところが外れてしまいました。それ以外は何の問題もないので修理して使い続けたいと思いますが、どうしようもないので、買い替えることにしました。
下見したところ、ニトリでは1,790円、CAINZでは1,480円でした。微妙にデザインは違いますが、その違いに拘ることもないと思いました。最終的には値段で決め、CAINZの方を買いました。結局は薬缶ですから、コンロにかけてお湯になればよいだけです。
使ってみて気づきましたが、CAINZのケトルは、握り手の部分がプラスチック製です。一方のニトリの方は、木製のようです。大した違いではないかもしれませんが、コンロにかけるとプラスチック製の握り手は熱くなるのに気づきました。また握り手が短いような気もします。
もし次に買い替えることがあれば、ニトリの方にしようと思います。しかし当分買い替える必要はないでしょう。仮に買い替える時が来たとしても、ニトリにしろCAINZにしろ、違う商品になっているでしょう。
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を今さらながら取り組んでいます。マイクロソフト的にはジョイスティックで操作して欲しいのかもしれませんが、所有していないので、キーボードを使うしかありません。ジョイスティックの操作が、どのようにキーボード操作にマッピングされているのか、付属していた文書類には書かれていません。
ジョイスティックを前後に動かすことは、キーボードなら「8」キーや「2」キーであるとは書かれていますが、それだけです。マイクロソフトのフライトシミュレータは、かなり精密にシミュレートしているとは言われますが、そうだとしてもパイロット資格を取得する目的で作られているわけではないですし、結局はゲーム性を重視しているはずです。
ジョイスティックを所有していませんが、噂で聞くところによると、ジョイスティックを前後に倒しても、手を離すと自動的に中立に復元するそうです。それは、キーボード操作では、実現されているのでしょうか。例えば、ジョイスティックを手前に倒し、その後で手を離したとすると、ジョイスティックは中立に戻ります。これと同じ状況を再現するには、キーボード操作では、どのようにしたらよいのでしょうか。
ここで問題になるのが、相反する情報があることです。ひとつは、「キーボード操作においては、勝手に中立に戻る」から、「2」キーを押すだけでよく、「2」キーから手を離せば（ジョイスティックが勝手に中立に戻るように）何もしなくてよいという情報です。もうひとつは「キーボード操作においては、ジョイスティックとは異なり、押したキーの方向に固定された状態になる」から、ジョイスティックを傾け続ける状態に相当するので、「5」キーを押さないと中立に戻らないという情報です。
さらによくわからないのは、ジョイスティックを少し傾けた場合と、最大限に傾けた場合とは、キーボード操作では、どのように変わってくるのかです。例えば「2」キーを押し続けたとすれば、それはジョイスティックを最大限に傾けた場合と等価だろうとは想像できます。もしジョイスティックを1.5cmくらい手前に引いたのと等価にしたいなら、キーボードをどのように操作すれば良いのでしょうか。「2」キーを0.5秒くらい押した後で離すだけで良いのでしょうか。それとも「2」キーを0.05秒くらい押して離すという行為を数回繰り返せば良いのでしょうか。
「難しく考えずに、やってみてうまくいけば、それでいいんだよ」という意見もあるでしょう。結局はゲームなので、それで良いのだと思います。キーボード操作に失敗すれば、失速して墜落するだけです。ゲームですから墜落しても生死につながりません。結局は「慣れるしかない」が答えなのかもしれません。
Androidのスマホを利用しています。Googleマップのタイムラインを有効にしているので、移動の軌跡が記録されます。このアプリには、相当不満はありますが、目安になればよいという程度の認識なので、利用を続けています。最も大きな不満は、精度が酷すぎることで、Google謹製のアプリとは思えないほど悪いです。そこは我慢するとして、謎な仕様もあります。
賢いというべきなのか、ある場所から別の場所に移動すると、勝手に移動手段を認識して「徒歩」とか「電車」などとラベルをつけてくれます。もし移動手段を認識できないと「移動」となりますし、認識された移動手段が間違っている場合もありますので、修正が必要になります。修正すると言っても、予め用意されている選択肢から選ぶしかありません。「自転車」とか「バス」という選択肢は理解できます。「スケートボード」という選択肢もありますが、これを予め選択肢に用意しておく必要があるか疑問ですが、まあ良いとしましょう。しかし「水泳」とか「手こぎボート」とか、あろうことか「乗馬」などという選択肢も用意されているのですが、これは必要ですか。
「乗馬」という選択肢を利用する人がいるかもしれませんが、何人いるんでしょうか。そういう選択肢を用意しておくくらいなら、もっと他に用意しておくべき選択肢があるのではないかと、しみじみと思います。
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に掲載されているアセンブラソースと比較すれば、どの辺りを変更しているかが分かるのではないかと思います。
まだマイコンと呼ばれていた時代に様々な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のバリエーションです。ただし、記事にも書かれていますが、DDJを参照して変更を加えたのではなく、「オブジェクトを独自に逆アセンブルし、変更を加えた」ものとのことです。
インターネットが存在しない時代ですから、発表媒体は雑誌などに限られると思います。想像となりますが、Palo Alto Tiny BASICを個人的に修正したり拡張したりした事例は、少なくないと思います。さらに、オリジナルはi8080版ですが、x86など他のCPUに移植したものも存在するのではないかと思います。技術的な関心として、取り組んでみたいと考えています。
共立出版から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.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に更新できます。
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購入依頼、この「初飛行」を何度となく試みました。操作もよくわかっていないし、飛行機の操縦も不慣れなので、酷いものです。シミュレータなので命は無事ですが、そうでなければ何十回も死んでいたところです。墜落こそしないものの、飛行場を遥かに離れた場所に着陸するとか、建物を突き破るなど、なんでもありです。
何度も「初飛行」していて慣れてきたのか、今日ようやく、まともなフライトに成功しました。離陸した飛行場に戻ってこられましたし、滑走路のすぐ傍に着陸できました。
これで、やっと「フライトレッスン」に進級できそうです。
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を使うことがあります。きちんとしたトレーニングを受けずに使っているので、常に試行錯誤しています。英文の「初心者用ガイド」が付属していますが、かなり膨大です。PDF版は241頁でした。これに目を通しておいた方が良いのだろうと思います。
簡単な図を描くだけなら、手探りで試行錯誤しても、なんとかなります。ただし綺麗な図にはなりません。簡単な図を描いてみたのですが、文字が太くなってしまいました。別に太字として設定したわけではありません。それなのに、太字で、完全にメタボです。
解決策をGoogleで検索したら、「テキストにもフィルとストロークがある」が見つかりました。この記事のとおりに設定を見直したら、文字がスッキリしました。ダイエットに成功した感じです。
NHKで放送が続いている「世界ふれあい街歩き」という番組があります。放送されるときにはナレーションを担当する芸能人が会話しているように編集されていますが、収録時は現地のコーディネーターが会話しています。これはウィキペディアに記載があります。しかも相手とは偶然の出会いのように会話していますが、事前に打診があるようです。ただしそれを「仕込み」と考えるかどうかは、ウィキペディアとオンラインのQ&Aサイトの回答とで見解が分かれています。
人が集まっているところで「何をしているんですか」と声をかけるシーンが度々現れますが、それが偶然なのか、事前に打ち合わせ済みなのかは、放送を見ているだけでは判断つきません。全部仕込みに決まっているだろうという主張もあり得ますが、番組の性格上、通りすがりの人に声をかける場面もあるので、そこまで仕込みとは思えません。仕込みが全くないとは主張しませんが。
放送では、朝から夜まで散策したかのように編集していますが、実際には2日間撮影しているようです。通りすがりの人に声をかけてみたものの、思ったような反応が返ってこないこともあるでしょうし、NGシーンもあるでしょう。それを編集して、あたかも1日で歩いてみたという設定にしているのだと思います。ただ、初日と二日目の天気が大きく違っていたらどうするのだろうと思います。
事前に打ち合わせ済みの場所を撮影する場合は、いかに自然な出会いであるかのように見せるかが腕の見せ所なのだと思います。NHKには「ブラタモリ」 という街歩き番組もあります。この番組では、街を紹介する担当者が、不自然な様子で待機しているシーンがよく登場します。偶然出会ったという風にする必要はないので、あえて不自然な待ち方にしているのかもしれません。
これまで知りませんでしたが「formail」というコマンドがあるようです。procmailが提供しているようです。procmailは以前から利用していましたが、formailは知りませんでした。
話の発端は、MH形式でローカルに保存していたメールファイルが、様々な問題をかかえていたので、修正しようとして考えており、その調査のためにメールヘッダを網羅的に検証する必要がでてきたことでした。例えばContent-typeに「iso-2022-jp」と書かれているのに、「nkf --guess」で確認するとEUC-JPだったりするのですが、この他にも、多種多様な問題がありました。
やっかいなのは、メールヘッダの各項目は、一行ですむとは限らないことです。メールヘッダのある項目が、複数行に別れている場合があります。そうなると、単純にgrepしただけでは、検出できない場合が考えられます。そこで、複数行に別れているなら1行に結合する前処理をおこなえば、grepでも対処可能なので、そうしようと考えていました。その前に、念のためにGeminiにお伺いをたてたら、「formail」の存在を教えてもらいました。
formailは、まさに求めていたものです。これを使えば、自前で前処理をする必要がなくなります。なんと便利なものがあるものかと、これまでの無知を恥じ入るばかりです。
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万円前後のようです。今すぐ購入することは可能ですが、もうちょっと様子をみようと思います。
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人+α」ということです。公暁は「十六人」と人数をぼかしていないのに、殿上人は実際の人数を明らかにしていません。
『平家物語』には、語り本系と読み本系があり、これは語り本系です。印刷されたものを読むこともあるでしょうけど、本来は琵琶法師とかが語るのを聴くものです。「さんじゅうよにん」と語られたら、聞いている方としては、「三十四人」と理解するのか、「三十余人」と理解するのか、どちらなのでしょうか。
20年ほど前に購入した「dynabook SS SX/15A」には「Windows Vista」がインストールされていましたが、2017年にサポート終了となったので「NetBSD/i386」に入れ替えて使い続けてきました。メモリは4Gなので、32bit CPUとしてはフル実装ですが、HDDが60Gしかないので、窮屈です。換装しようにも、1.8インチHDDが使われているため、代替品を入手するのが困難です。
さらに昨今はソフトウェア側で32bit CPU対応を止めるものが多くなってきています。日常的に使用しているわけではないので、最新版を使いたいわけでもないのですが、利用可能なバージョンが古くて不便な状況に追い込まれてきました。
しかも、電源を入れても素直にOSが起動しない場合があります。そういう場合は、ノートPCごとを揺すってみたり、表面とか裏面から手で押してみるとかを繰り返すと、起動できるようになります。いったん起動してしまえば、動作中に落ちることはありません。大昔の家電製品は故障したら叩けば直ると（嘘か真か）言われていましたが、それに近いものがあります。
このままダマしダマし使い続けるのは可能だと思いますが、そろそろ代替品を探して、移行しようと思います。次もNetBSDにしようと考えています。新品である必要はないので、中古かジャンク品を入手しようと思っています。2万円くらいで入手できないかと思い探しています。通販でもよいのですが、現物を確認して買いたいところです。
ローカルにMH形式で持っているはずのファイルを確認したら、いろいろな意味で問題があることが分かりました。2000年前後のものなのですが、メールヘッダには「iso-2022-jp」とあるのに、本文を「nkf --guess」したら「EUC-JP」と訴えています。これだけなら変換すれば良いのですが、文字化けという意味ではなく、種々雑多な問題が潜んでいそうです。しかも、そのようなメールが9万ファイル弱あって、簡単には修復できそうもありません。
Geminiに相談したら、ファイルごとの情報を整理したCSV形式ファイルを作ってから、対処方法を考えるべきだとのアドバイスをもらいました。それでCSV形式ファイルを作ってみましたが、ここから問題のパターンを整理しなければなりません。
これまでCSV形式ファイルを調査するには、AWKなどのコマンドラインツールを駆使してきました。今回もそれでいこうと思ったのですが、ちょっとGeminiに相談したところ、「Miller」というツールを紹介してもらいました。パッケージから簡単にインストールできましたが、使い勝手が手強そうです。公式サイトから「Miller 6.18.1 Documentation」を見つけました。まずは、これを読んで勉強してみようと思います。
数年前から語り本系の平家物語を暗誦しようと思い、少しずつ覚えています。「祇園精舎」から始まり、「殿上闇討」、「鱸」、「禿髪」と進み、今は「吾身栄花」を覚えているところです。
ここには、「一人は、桜町の中納言重教卿の北の方にておはすべかりしが、八歳の時、約束計にて、平治の乱以後、ひきちがへられ、花山院の左大臣殿の御台盤所にならせ給ひて、君達あまたましましけり。」という一節があります。「花山院の左大臣殿」とは藤原兼雅のことです。二男一女をもうけたようですが、「君達あまたましましけり」というほどでもないかという気がします。
平清盛には18人の子がいたようですので、ここまでいれば「ましまし」という感じはします。現代では「マシマシ」と言うとラーメンの注文のようですが、ニュアンスは同じのように思います。
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週間なのです。ただし注意が必要ですが、正確に言えば、視聴できるのは「本放送」から1週間です。「再放送」は関係ありません。
例えば「100分 de 名著」の場合、本放送は「毎週月曜 午後10時25分」で、再放送は「毎週金曜 午後３時５分」です。この場合ですと、本放送が終わってから1週間は見逃し配信がありますが、再放送は見逃し配信の期間に影響しないので、再放送からカウントすると数日間しかありません。
本放送とか再放送とか言う区分は、「放送」における区分に過ぎず、「ネット配信」とは別概念なのです。当たり前かもしれませんし、この違いは著作権の扱いによるものですが、少なからず専門的な概念ともいえるのではないかと思います。テレビやラジオを視聴している人にとって、それが本放送なのか再放送なのか気にしていないと思いますが、内部の放送関係者にすれば大問題なのです。だからこそ「見逃し配信はいつまで見られますか？」という問いに対して「見逃し配信は、放送の終了から1週間視聴できます。」と答えていますが、その真意は伝わっていないかもしれません。
視聴者からすれば、放送もネット配信も同じだと思っているのでしょうけれども、現時点では違うものです。しかしそれが未来永劫そうだとも限りません。未来は変わっていることを願いたいと思います。
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」でパスキーの登録ができるようになってもらえるとありがたいのですが。そうでないままに、「ログイン方法をパスキーに一本化」されるのは、とても困ります。
メールを読む環境は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が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ファイルが数多くあるのですが、更新は当面見合わせるつもりです。
メールを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/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などでは、改良されているのでしょうか。それとも手付かずのままなのでしょうか。
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年くらい前のことですし、強いて思い出してもらわなければならないほど重要な問題でもありません。
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が変化するのを期待しているわけではありません。
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」を生成する箇所と一致します。
一方で、Lions本は、0500番台の行番号がついている「low.s」によれば、以下のデバイスが有効になっています。
ディスク操作は、どちらもRK11ですが、端末関係が違います。このような違いも含めて、UNIXv6のカーネルを学んでいこうと思います。
自宅の固定電話に着信するのは、不審なものばかりです。ナンバーディスプレイを契約しているので、相手先の番号がわかるのですが、「0120」とか「0800」などの国内から発信されたもの以外に、番号体系が「0AB～J」や「0A0」にはなっていないものが増えてきています。おそらく海外から発信されたものなのでしょう。
不審着信は無視しているし、同一番号からの着信が多い場合は、ブロックリストに入れて着信音が鳴らないようにしています。このような対策をしているのですが、物は試しとGeminiに相談してみました。すると「国際電話不取扱受付センター」という存在を教えてくれました。ここに登録しておけば、海外からの着信を全て拒否するようになるそうです。
こんなものがあるのかと思いました。これを申し込んでも海外に発信することはできるそうですし、海外からの着信を受けたくなれば、登録を解除することもできるそうです。実際に登録を申し込むかどうか分かりませんが、考えてみようと思います。
2024年3月で終了となった「ブラタモリ」が 、2025年4月からレギュラー放送に戻りました。復活前には「番組のコンセプトはそのままに、街道を歩くシリーズものなど、新しい試みにも挑戦し、より幅広い世代の人に地域の魅力を届けます。」という発表がNHKからありました。
復活直後は、シリーズで街道を取り上げていましたが、しだいに昔ながらのブラタモリに戻っていて、いまはもう普通のブラタモリになっている気がします。2026年4月には皇居内に入ったので「新しい試みに挑戦」とも言えるかもしれません。しかし「街道」はどうしたと言いたいところです。
「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に相談したら、簡単なスクリプトを生成してくれました。これを使えば、検索ボックスでシンボル名かアドレスを入力すると、対応するアドレス（またはシンボル名）を見つけてくれます。ミニツールではありますが、便利に利用できそうです。
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」ひとつだけで処理しないで、もうひとつあれば良いのにと思うところです。
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バイト以下におさめる必要がありますから、エラーチェックをしっかりとか、ファイルシステムを完璧に実装しようなどという理想に走ると、容量をオーバーしてしまうでしょう。問題があることはわかっているけど、仕方ないよねという割り切りを感じるのです。
PDP-11で動作したUNIXv6について学ぼうとすると、真っ先に挙げられるのは「Lions本」と呼ばれる『Lions' Commentary on UNIX』です。僕自身も、アスキー出版局から出た和訳を参考にしています。その中には、次のような箇所があります。
この一文の前半にある「論文の改訂版である」というのは、一読しても何のことか分かりませんが、後半の「再読すべきである」は、よく分かります。暗記してしまうくらい熟読せよという意味でしょう。これはネットを検索すれば見つかるので、手元に置いておき、仰せの通りに何度も読み直そうと思います。
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の旧いソースを追いかけると、わかるかもしれません。
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が正常終了したか異常終了したかに依って処理を分岐させたいのであれば、他の方法もあるだろうし、そうすることが困難だとも思えません。
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バイト制限を気にするほどのことではないと思います。
おそらく簡易編集機能は、あってもなくても構わない程度の、おまけ機能なのでしょう。