◎ [NetBSD/x68k] 昨日の config_console() あたりをごっそり書き換えたやつは port-x68k に出しといた。日本語で説明するのですら頭痛いのに、あの英語では 誰も読めないので突っ込まれることなくタイムアウトするといういう作戦 orz。 あれが commit できると残りのデバイスの device_t/softc 分離も完了できる。

◎ [NetBSD/x68k] 各デバイスが好き勝手に sram(4) を触っているところが なんかもうちょっときれいにならないかと思って、 とりあえず rtc(4) をターゲットに眺めてみた。 けどなんか煮詰まってきた。 なんだかなーみたいな方法しか思い浮かばん。

◎ 煮詰まってきたので、 気分転換に9月以来のコーヒータイマー第2弾のハンダ付けでも再開してみる。 半日かかって一層目の配線を8割方ってところか。 配線大杉。

◎ [Perfume] 昨日深夜の CDTV の生ライブに Perfume が出るってんで録画しといたのを見てみた。 久しぶりにどす黒い声の混ざらない「Perfume です」の決め挨拶が 聞けたのでよかった。 Perfume じゃない奴が声揃えて Perfume ですって言うのもおかしいし、 決めの挨拶に乗っかって邪魔してるのもおかしいよ。

◎ コーヒータイマーのメイン基板完成。被覆線は初めて使ったけども、 ハンダをはじくような感じでかなりはんだ付けしにくいので 途中からはまず被覆線の両端にハンダごてを当ててこすったりして ちょっと被覆をはがすような感じにしたりしてて、 これじゃそのままハンダ付け出来ますっていう被覆線のメリットがないような…。 まあそれであってもジャンパ線のみで配線するよりは随分楽だけど。 珍しく配線ミスも接触不良もなく一発で動作した。 後はケース加工。

◎ [NetBSD/x68k] NetBSD/x68k のデバイス間アクセスをなんとかしたい。 試しに、馬鹿正直に bus_space(9) を使ってみる。

/* ヘッダファイル、例えば <arch/x68k/dev/sramvar.h> */
extern struct sram_softc *sram0;

static inline void
sram_write_1(int offset, uint8_t val)
{
#if DIAGNOSTIC
   if (sram0 == NULL)
       panic("sram0 == NULL");
#endif
   bus_space_write_1(sram0->sc_iot, sram0->sc_ioh, offset, val);
}

/* 使うほう */
#include <arch/x68k/dev/sramvar.h>

   sram_write_1(0x26, 7); /* SRAM の 0x26番地 ($ed0026) へ値 7 を書き込む */

まあ NetBSD 的には正当っちゃ正当で、 これを使ったソース (↑ 下側) もまあ直感的で分かりやすいと思う。 ただ、そのために sram_softc を extern にするのはなんかキモい。 sram_softc は当然 sram_attach() で設定されるため、参照するデバイスと 参照されるデバイスのアタッチ順をしっかり管理する必要もある。 手もとのソースでは実装してみてあってそれはそれで悪くない気もするけど。 で、せっかくインライン関数にした (そして x68k の bus_space_{read,write} もインライン関数である) にもかかわらず、 x68k の bus_space_{read,write} (の __X68K_BUS_ADDR マクロ) が 非常に効率悪くて、これをアセンブラに展開するとちょっとお茶吹きそう。 いやもちろん MI なデバイス触る時の __X68K_BUS_ADDR マクロの 驚異的な動きには頭が下がるけどね。 しかしそもそもここ移植できないところだし、 なんでコンパイル時に定数の番地に1バイト書き込むのに こんだけ必要なのかはちょっと考えてしまう。 bus_space_write_1() はこう定義されているので

#define __X68K_BUS_ADDR(tag, handle, offset)    \
       (((long)(handle) < 0 ? (offset) * 2 : (offset)) \
        + ((handle) & 0x7fffffff))

static inline void
bus_space_write_1(bus_space_tag_t t, bus_space_handle_t bsh,
       bus_size_t offset, u_int8_t value)
{
       *(volatile u_int8_t *)__X68K_BUS_ADDR(t, bsh, offset) = value;
}

アセンブラではこうなる。

.L132:
       move.l sram0,%a0
       move.l 4(%a0),%d0       | %d0 に sram0->sc_ioh (= handle)
       jblt .L225              | handle < 0 なら .L225 へジャンプ

       moveq #38,%d1           | %d1 に offset (= 0x26)
       bclr #31,%d0            | handle & 0x7fffffff
       move.l %d1,%a0
       add.l %d0,%a0           | %a0 = (handle & 0x7fffffff) + offset
       move.b #7,(%a0)         | そこに value (= 7) を書き込み
.L229:

:

.L225:
       moveq #76,%d1           | %d1 に offset * 2
       bclr #31,%d0            | handle & 0x7fffffff
       move.l %d1,%a0
       add.l %d0,%a0           | %a0 = (handle & 0x7fffffff) + offset * 2
       move.b #7,(%a0)         | そこに value (= 7) を書き込み
       jbra .L229              | 元の続きに戻る

あれ、つーかこれ、最適化ゆるいな。こっちのほうが短くね?。まあいいけど…。

.L132:
       moveq #38,%d1
       move.l sram0,%a0
       move.l 4(%a0),%d0
       jbge .L225              | ニーモニック知らんけど要するに jblt の反対
       add.l %d1,%d1
.L225:
       bclr #31,%d0
       move.l %d1,%a0
       add.l %d0,%a0
       move.b #7,(%a0)

◎ [NetBSD/x68k] というかあれだな。 同じ奇数番地のみのレジスタ配置であっても、 MI なデバイスについては、本来連続したレジスタ空間を BUS_SPACE_MAP_SHIFTED によって奇数番地(あるいは偶数番地) のみの 1バイトおきに変換したもの。 X68000 固有のデバイスについては、 BUS_SPACE_MAP_SHIFTED ではなくて 「奇数番地のみが(たまたま)有効な」連続した空間、と考えたほうがいいのか。 というか今現在の実装がそうなってるな。 そう意図してるのか、手抜きでそこまで考えられてないのかは分からないけど。 こういう「創り手の思想」みたいなもんはコードに落としただけだと 抜け落ちちゃうからねえ…。 ま、それはともかく、 だとすると、最初 (2008/12/14 の日記) の intio_write_1() は悪い解じゃないな。 各デバイスの先頭からのオフセットとかは関係なくて、 最初から intio の中の物理番地でいうどこそこに アクセスしたいと分かってるわけだからな。

static inline void
intio_write_1(int addr, uint8_t val)
{
   *(volatile uint8_t)IIOV(addr) = val;
}

これだと、アセンブラにするとこれだけになる。 コンパイル時定数の番地にアクセスするのだからこれくらいなら許せる。

       move.l intiobase,%a0
       add.l #(0xed0026 - 0xc00000),%a0
       move.b #7,(%a0)

これやっちゃうと bus_space(9) 使う意味がなくなるってのはあるけど、 最初からそもそもここで bus_space(9) 使う意味は移植性という意味では 全くないわけだし、分かりやすさでいえば現状の IODEVbase 使う方法に 比べると十分分かりやすくなってるよな。 それに現状の実装が *(volatile *)addr = val の生アクセスであることを考えると ほとんどパフォーマンスのロスなしに ソースコード上からは関数形式にラッピングしたように見える だけでも十分な前進と捉えたほうがいいか。 とはいえこれを commit するかというと 結局 bus_space(9) 使えっていう話にしかならんのだけどな。 だからたぶん10年前からこのコードのままなんだろうけど。 あー最初に戻った orz。

◎ [NetBSD/x68k] 気分転換に (なるとは思えないけど)、FD へのアクセスでささる件。

# dd if=/dev/fd1a of=/dev/null bs=512 count=1
fdgetdisklabel()
fdioctl:
fdstrategy: read b_blkno 0 b_bcount 2048 cylin 0
fdcintr: in DEVIDLE
fd_set_motor:

で、赤ランプでモーター回りっぱなし。恐い恐い。 どうせまた callout とか spl とかその辺の仕様が変わって 追従できずにあぼーんていう話だと思うんだけど、 さてどっから printf 入れたらええんかいな(汗。

◎ [NetBSD/x68k] うん?、FDC の割り込みレベルは 3 なんだけど、splbio() が昔は splraise3() だったのを 2007/12 に ad さんが spl*() をぐちゃっとまとめた 時に splbio() が splraise4() になり、その後さらにうちが splraise5() に 変えてるんだけど、これ大丈夫なんだっけ。 m68k (x68k?) の割り込みレベルと BSD の spl(9) の概念がいまいちしっくりこねー。 ええっと、FDC の割り込みが上がり続けてるな。 MOTORWAIT からステートが変わらないらしい。 このステートを変える fd_motor_on() を callout_reset() でセットしたのにシカトされてるっぽい。 どういうこっちゃ。

◎ [NetBSD/x68k] あ、splraise3() は 3 以下の割り込みを禁止する (= 3 も禁止) だから、 4 でも 5 でも (ここに限れば) 問題ないのか。

◎ [NetBSDとか] spl*() について。 http://wiki.bit-hive.com/xnumemo/pg/%C7%D3%C2%BE%C0%A9%B8%E6%B4%D8%CF%A2 より引用。

ユニプロセッサのシステムでプロセスコンテキストと割り込みコンテキストの間で排他制御をするのに使われていた。
(中略)
これらの関数は割り込みを禁止するだけなので、マルチプロセッサ環境においては役に立たない。Xnuのコード上には残っているが、新たなコードでは使わないこと(というか使っても意味がない)。排他制御を行う場合はSpinlockなどを使用すること。

spl*() は(特定の)割り込みを禁止するものだが、 ユニプロセッサ環境に限れば、該当する割り込みを禁止してしまえば 通常のコンテキストと割り込みコンテキストとが排他になる。 ということで、ユニプロセッサしか眼中になかった当時としては それで十分だったからか、本当の排他制御が高価だったからかは分からないけど、 spl*() は割り込みを禁止するものであると同時に (特にデバドラ方面では) あたかも排他制御にも使うもの であるかのような用法も一人歩きしたと。 で、もちろん、特定の状況下ではこれが排他制御としても使えたことは事実だが、 実際には spl*() は排他制御をするものではなくて 所詮割り込みを禁止してるにすぎない。 案の定マルチプロセッサ環境では割り込みを禁止しただけでは 排他制御をしたことにはならないし、という話なのかしらね。 違ってたらごめそ。でも、ずーっと長い間 ぼんやりしてたところが解決した感じ。 もう一つ見つけたのでメモ。 spl*() の順位付けについて。 http://search.luky.org/fol.1999/msg03993.html。 10年前の曽田さんレベルに追い付くのにはあと20年以上は必要そう。

◎ 今年最初の NEWS23、オープニングタイトル明けて、

全員「こんばんわ」
後藤「今年もよろしくお願いします」
膳場「し、新年…」

こ、このおばちゃん、新年一発目の台詞を噛んだよ…。

◎ [PCとか] メモ。つい昨日リリースされた FreeBSD 7.1 の新機能、 複数ルーティングテーブルの概説。

◎ [航空] 東京出張。久しぶりに窓際に乗ってみる。 離陸後すぐに北に針路をとって中国山地上空を飛び、 琵琶湖、セントレアの直上を通過した感じ。 真上から見たセントレアを写真に撮ったけどもうまく写ってなかったのが残念。 ただ、今どき Google Map があるから上空からの写真は逆に珍しくはないけど…。

◎ [NetBSDとか] NetBSD 5.0-BETA (i386) をインストールして使ってみる。 X が Xorg になったらしい。 ヒトバシラーの方の日記なんかはちらほら見てたけど、 実際に見たのは初めて。というか途方に暮れる。 最初の X の設定、つまり従来の xf86cfg 相当は X -configure とやるらしい。 さくっと /root/xorg.conf.new ていうファイルが出来るので /etc/X11/xorg.conf にリネームする。 X の起動は /usr/X11R7/bin にある startx か xinit で行う。 この辺はパスが /usr/X11R6 から /usr/X11R7 に変わっただけで だいたい同じみたい。 ただ、パスが変わったことで自分用の設定ファイルは比較的お祭り orz。

◎ [NetBSDとか] おっ、ついに標準の vi や less で日本語が扱えるようになっている。 この辺の成果は毎朝どっちの方角向いて頭を下げたらええのかな。 今日気づいたのはとりあえずこのくらいだけど、 わりと面白そう。

◎ [ドラクエ] 去年の8月末に買ってから移動中にちまちまやってた DS 版のドラクエ4を6章までクリア。 45時間くらい、レベルは42くらいだったかな。 ファミコン版のドラクエ4は仲間が全員AI戦闘であほすぎたため 面白くなかったが、今回は全員「めいれいさせろ」に出来るので戦闘は楽。 あれ、サントハイムが元に戻るイベントってなかったっけ?

◎ [アニメとか] リリアとトレイズ[I] そして二人は旅行に行った(上)リリアとトレイズ[II] 同(下)。 「リリアとトレイズ」は[I]から[VI]までの6冊あるが、 3話を各上下巻の2冊ずつにしているので、 リリアとトレイズ[II]に上巻下巻があるのではなくて [II]が1話目の下巻。ネーミングが紛らわしいよう。 で、アリソンシリーズの続きなので、 アリソンシリーズ3話での登場人物とのつながりを分からずに これを読むのはもったいないので必ずアリソンから読むべし。 あいかわらず核心にはきなくさい話が待ち構えているわけだが、 リリアは今流行のツンデレというやつですかね。 こっちゃなんとなくトレイズのポジションが気に入ってるけど。

◎ [NetBSD/x68k] fd_motor_on() が呼ばれない理由が分からない…。 ここの動作はモータを回して少し (元は 0.5秒) 待ってから モータ安定待ちフラグ (FD_MOTOR_WAIT) を下げるだけなので、 頭悪い感じでこんなことをしてみたらちゃんと動いた。 え、ええ、ここ以外に他に大きな問題がないということが確認できた のは大きな進歩ですよ(汗。 さすがに commit できないので、とりあえず FDD が読めればいいという 方はどうぞ。

--- sys/arch/x68k/dev/fd.c	10 Jan 2009 06:16:18 -0000
+++ sys/arch/x68k/dev/fd.c	10 Jan 2009 06:20:19 -0000
@@ -1081,9 +1081,16 @@
 			fd_set_motor(fdc, 0);
 			fdc->sc_state = MOTORWAIT;
 			/* allow .5s for motor to stabilize */
+#if 0 /* XXX */
 			callout_reset(&fd->sc_motoron_ch, hz / 2,
 			    fd_motor_on, fd);
 			return 1;
+#else
+			/* wait a bit for motor to stabilize... */
+			delay(50 * 1000);
+			fd->sc_flags &= ~FD_MOTOR_WAIT;
+			goto loop;
+#endif
 		}
 		/* Make sure the right drive is selected. */
 		fd_set_motor(fdc, 0);

◎ [NetBSD/x68k] あー思い出したので、メモ。確か数年前もそうだったと思うけど、 エラーの出るアクセス (fd0X の X のところが違うとか) を した次のアクセスで DMAC のタイミングエラーが表示される。 DMAC のエラーをクリアしてないところがあるっぽい。

◎ [NetBSDとか] しかし読めば読むほど fd.c もご愁傷様な感じ。 モータを止めるのは fd_motor_off() だが、 モータを回すのは fd_motor_on() ではなく fd_set_motor()。 fd_motor_on() ていう関数は別にあって、こっちは前述した通り fd_set_motor() で回したモータが安定した頃に callout で 呼ばれて飛び出て動作を再開する人。関数名がおワットる。 fd_set_motor() の第二引数 reset は有史以前から使われてないし、 fd_set_motor() でどのドライブのモータを回すかの指定もかなり 危険な方法だし。なんか歴史の重みを感じる。

◎ [ドラクエ] なんとなくプレステ2版のドラクエ5を手にいれてみた。 よーし遊ぶぞー。 というか、 ドラクエ6をやりかけだったんだけど、ちょっと意味が分からなく なってきて再開する気がおきない。

◎ [NetBSD/x68k] いまさらだけど、NetBSD/x68k での fd?a が Human68k 標準のフォーマット、 fd?c が NetBSD/x68k で使われるフォーマットっぽい。 それと言われてみれば当り前だけど、ブートローダで指定する fd0a の a には意味がないので前述のフォーマットの違いとは無関係。 ああ紛らわしい。 NetBSD/x68k の fdc(4) でアクセスできる形式と Human68k 方面での 呼称のロゼッタストーン。 fd?d〜fd?h は 2D/2DD っぽくて今のところ俺様には必要ないので省略。

デバイス名	sect/track	byte/sect	total cyls	total sect	NetBSD 側のコメント	Human68k 側での通称
fd?a	8	1024	77	1232	1.2MB japanese format	2HD(Human68k)
fd?b	18	512	80	2880	1.44MB	2HQ
fd?c	15	512	80	2400	1.2MB	2HC

これ、fd0i 以降で 2HS とか 2HT も扱えるように出来ないかなあ。
(2010/01/03 追記、表中の数値の間違いを修正)

◎ [NetBSD/x68k] あー、arch/x68k/dev/fd.c は dev/isa/fd.c をコピーして派生したのか。 いや違うな。元もと i386 とか MD ごとに別々にあった fd.c のうち似たやつを dev/isa/fd.c にまとめたんだな。 X68000 の FD はモータ ON とドライブセレクトが FDC の信号を使わず 別コントローラだったりするっていうあたりで、 たぶん #ifdef とかやめたほうがよくて、 コピーして似たものを作るしかないからな。 で、fd_set_motor() とかは dev/isa/fd.c にもあるから x68k のはこいつらに由来してこの動作を真似てるから 不思議な感じになっとるのか。なるほど。 ということは dev/isa/fd.c (とか Attic の arch/i386/isa/fd.c) の 変更点を眺めながら適宜追従させたほうがいいのかな…。

◎ [X680x0] FD アクセスができるようになったので、10年越しに手もとにある X68000 の5インチフロッピーを片っ端から dd(1) で読み込んでイメージを作成中。 というか 10年前から必要性は分かっていたのに、 一番大事なレスキュー用ディスクが数年前に CRC エラーでお亡くなりに なってしまってて、要するに手遅れになってから着手し始めたという…。 NetBSD/x68k で読み込める 2HD、2HC 形式のフロッピー全部 (約100麻衣) 読んで結局 CRC エラーだったのは あの1麻衣のみ。1麻衣のみで済んだわりには影響がでかすぎ…orz。

◎ NHK の7時台のニュース。

アナウンサー「続いては気象情報です。今日は山本さんが インフルエンザでお休みなので…」

えっと、山本さんはいわゆるお天気お姉さんなんだけど、 そのインフルエンザ情報ってわざわざ公表する必要ある?

◎ [NetBSDとか] christos-time_t ブランチがマージされて time_t (と dev_t) が 64bit になったっぽくて、わりとお祭りっぽい。 ユーザランドもカーネルも全編に渡って ビルドエラーでまくりなのは放置ぷれいらしいので x68k も PRI64u 程度のところだけは追従しておく。 kbd/ms は週末あたりに見るべか。

◎ [NetBSD/x68k] おおしまさんところ より。 あれ、うちの x68k のビルドはまだ MI のユーザランドでこけてて 先へ進めないんだけどな。

◎ [アニメとか] リリアとトレイズ[III] イクストーヴァの一番長い日(上)リリアとトレイズ[IV] 同(下)。 ものすごいペースで読んどるわけだが。 リリアとトレイズの2話目で、今度はイクストーヴァが舞台。 アリソンIIもそうだったけど個人的にはイクスの話はなんとなく好き。 あとアリソンシリーズはロクシェ語とベゼル語を通常母国語の方しか理解 できない一般人と両方理解できるごく一部の人という設定が 鍵になったりするわけだが、今回はそれに更にイクス語が 出てきたあたりがいい感じ。 きなくささはそれほどないものの、銃と銃殺の描写が細かくなってきてて それはそれでいやん。

◎ [NetBSD/x68k] お、christos-time_t マージ以降初めてビルドがユーザランドを通過したっぽい。 カーネルでこけるのはすでに分かっているのでこれから着手。 って arch/x68k/dev/event.c って dev/sun/event.c とまったく同じものやん…。 これ使いまわしちゃだめなんかしら。 x68k は sun じゃないから例えコードが同じでも違う場所にあることに 意味があるのか、 x68k の kbd/ms が勝手に sun を真似してるのは別にいいから 全く同じものならデッドコピーはやめるべきなのか。 歴史的経緯ワカンネ。

◎ [NetBSD/x68k] おおしまさんの仰ってたインストールフロッピーのところへようやく到達。 とりあえずビルドエラーにならないようにだけ修正しておく。 で、fdc(4) も仮復旧したので久しぶりにインストールフロッピーを 突っ込んで起動してみたところ、2麻衣目のディスクを読み終わったら 次に1麻衣目を入れろと。 で、もう一回1麻衣目を読んでからまた2麻衣目を入れろと…。 なんじゃこりゃ。 どうしてこう、いつもいつも動かなくなるのかねえ。 いつもっつっても前回起動を確認したのは1年以上前 (2007/11/11 の日記参照) なわけだが。

◎ [NetBSD/x68k] christos-time_t マージ後の 5.99.7 カーネルで起動したら、 ブートデバイスを聞かれた (だけで正常に立ち上がってきた)。 ああ、bootdev が dev_t だったから 64 ビットになったんだけども locore.s では bootdev は 32 ビットだと思って movl してるからだね…。 他の port も見渡してみたけどとりあえずここの bootdev は locore.s との インタフェースでもある訳だし、サイズが明確なほうがいいのかもしれん。 とりあえず bootdev を dev_t から uint32_t に変更する方向にしておこう。

◎ [NetBSD/x68k] consinit() が絡むデバイスが device_t/softc 分離できない件 の続き。12月末に port-x68k に出しといたパッチを commit してしまう。 まーさすがに間違った方向のことはしてないと思う。 それに x68k みたいな辺境の port のパッチは温めとくと古くなるだけだし、 動作確認できた時にタイムリーにやっちまったほうがいいからね。

◎ [NetBSD/x68k] やっぱり覚えてられなくなってきたので NetBSD/x68k の TODO。 大杉…。

• インストールフロッピーが2麻衣目のあと1麻衣目を要求する。
• fd.c を dev/isa/fd.c とか見て一部追従。
• fd.c はほんとは fd_motor_on を callout で呼ぶべき。
• event.c いるの?
• 割り込み中で spl4() とかしてるところを修正。 (2009/01/18 修正)
• struct device → device_t がまだあったはず。
• style fix たくさんありすぎてどうしよう。
• というかおうちのソースツリーとの差を減らさないと diff が 当たらなくなってきた。
• sram アクセスをきれいにしたい。
• pow.c の setalarm() 周りをきれいにしたい。
• pow(4)、フロントスイッチと EXPON でイベントを分ける?
• intio_write_1() とか、やっちゃいたい。
• ssir の削除。hp300 参照。
• bus_space_map() で extent(9) をもうちょっとちゃんと活用するか。 intio_map_allocate_region() がいまいちな気がする。
• intio(4) の子デバイスは dmac(4) を優先してアタッチしないと いけない希ガス。

  〜 〜

• netboot の X68030 対応。
• netboot も commit できるくらい整備したい。
• hdc(4)
• その前に PRO-II をフロッピードライブを修理…。
• wscons(4) 対応…。( -.-)
• 9SCDRV 相当って実現できないのかなあ(ぉ

◎ [NetBSD/x68k] ということで、おうちのソースツリーとの差を減らすべく、 いくつかどうでもいいものを commit しておく。

◎ [ドラクエ] NetBSD のほうが煮詰まってきたので、ドラクエ5にコンテキストスイッチ。 現在レベル15。

◎ [NetBSDとか] NetBSD/hpcsh。 某所でもう7〜8年は放置されている Jornada680 で、 ちょいと NetBSD/hpcsh を動かしてみようと思った。 とりあえずNetBSD/hpcsh User How-Toにおいてある 2001年製の hpcboot.exe、カーネル、miniroot.fs をとってきて CF (メモリカード) に置く。 WindowsCE を立ち上げてエクスプローラでメモリカード上の hpcboot.exe を実行。 ブートに必要なパラメータを入力して boot ボタンを押す。 プログレスバーが伸びていくが途中でメモリが足りないと言われる。 ああ、エクスプローラすら上がってることが許されないぎりぎり具合なのか。 エクスプローラを終了させてから再度実行。今度は成功。 で、なにやらカーネル起動。 いい感じでずらずらっと autoconfig のメッセージが流れていくものの、 pid 1 で SEGV かなんか起きたーーというメッセージが無限に流れ続けて 電源ボタンも効かなくなった。 というか WindowsCE 機自体触ったことないからよくシラネ。 バッテリ引き抜いて停止させる。たぶんよいこは真似しないように。 それだけじゃアレなんで、でも薄々余計に駄目かもとは思いながらも -current の hpcsh をビルドしてそのカーネルで起動してみた。 hpcboot.exe にメモリが足りないと怒られた。ああ、やっぱりね…。 どうみてもカーネルのサイズが半端なくでかいもんね。 ということで、しゅーりょーー。 まあ、動くところが見たかっただけで、特に動いたからどうってこともないんだが。

◎ [NetBSDとか] おおしまさんより。 -current の hpcsh の状況。 というかやはりシリアルコンソールか。 (← 書いてある通りにやらない人)

◎ [NetBSDとか] NetBSD/i386 の 5.0-BETA。 普段ビルドはソースツリーを一旦 nullfs で readonly マウントして そっちをソースディレクトリに指定している。 せっかく NetBSD 5 なので、PUFFS を有効にしたカーネルで /usr/src/share/examples/puffs/pnullfs にある PUFFS 版の nullfs を使ってみることにした。 どうでもいいけど、これソースツリーにはあるけど /usr/share/examples にインストールされないのは まだ experimental 扱いだからってことかしら。 と思いながら ビルド始めてわりとすぐ、tools 作成中にカーネルごと固まったっぽい。 え、そうなん? 仕方ないのでリセット。 すると fsck かもうちょっと進んだあたり、 横目で見てただけなのでちゃんとは分からないけど、fsck 終わるのを 待ってたつもりが、気付いたら NetBSD のカーネルが上がってきてる ところだった。 えーっと??

◎ [Perfume] Perfume 動画、 素晴らしすぐる。 やっぱ、かしゆか髪型戻してくんねえかな。 0分42秒あたりのかしゆか(;´Д｀)ﾊｧﾊｧ。

◎ [NetBSDとか] NetBSD/i386 の 5.0-BETA を VMware Player で動かしてるんだけど、 どうもゲスト OS に認識させた USB デバイスをデタッチすると ゲスト OS が不安定になるっぽい。 同じホスト上の NetBSD 4 ゲストではそんなこと一度もなかったんだけどな。

◎ [NetBSD/x68k] インストールフロッピーの2麻衣目が1麻衣目を要求するのは MI の問題らしい? → install/38943。 じゃー誰かよろ(ぉ。

◎ [ドラクエ] ドラクエ5。もはや何の躊躇もなくビアンカを選ぶ。レベル23。

◎ [NetBSDとか] あら、hpcsh はすっかりそっち方面の人を発動してしまったらしい。

◎ 物置を大掃除中らしい。 落書きしすぎて本文が原型をとどめてない小6の国語の教科書とか、 中高大学時代のものすごい数のノートやレポートや試験問題とか、 1988年〜90年頃にかけての全盛期の MSX FAN とか、 妙に保存状態のよい日テレジェニック 2000 な福井裕佳梨さんのトレカとか 出てきた。うひょー。 もはや歴史的価値の域に達して…はいないんだろうか。 その他、貰い物で保存状態の悪い X68000 2台が粗大ゴミと同じエリアに整頓されていたので救出。 しかし、電源は入るのかとか、FDD は動くのかとか、 そもそもどこに置いておくのかとか、いろいろ課題はあるわけだが…。

◎ [アニメとか]  リリアとトレイズ[V] 私の王子様(上)、[VI] 同(下)。 リリアとトレイズの最終話。 え、そういう終わり方? ていう感じで、なんかしれーっと終わったよ? もうちょい続ききぼん。 しかし、この世界でのイクストーヴァ王室への忠誠といい、 ベゼル王室への忠誠といい、みんな半端じゃないな。 ロクシェが連邦制で王室がないから余計にかも知れないが。 あと、 何巻目だったか忘れたけど、サイドストーリー「騎士の背中」を 読むとなんかもう誰がどっちの何者だか分からなくなってくる。 読解力なさすぎか。

◎ この1週間、無駄に忙しかった。 というか馬鹿が仕事しないあるいは仕事を増やすから 忙しいという状況はなんとかならんものか…。 馬鹿は全員氏ねばいいのに。

◎ [アニメとか]  メグとセロン[I] 三三〇五年の夏休み(上)、[II] 同(下)。 アリソン、というか「リリアとトレイズ」のスピンオフ作品。 スピンオフだし学園モノなので最初は読まなくてもいいやくらいのつもり だったんだけど、思いのほかリリトレを早く読み終えてしまったので 買ってみた。 読んでみると、学園モノだけあって読みやすいし、 詳細な描写で人が死んだりしないのでこっちのほうがいい。 相変わらず序章に1年後の結論だけが書いてあるので、 結果だけ知ってて展開を読まされるわけだが、 特に最初の最初、セロンがラリーに電話してるくだりからどうやって あの序章へ辿り着くのかと思うと読まないわけにはいかない。 セロンのキャラが途中からアリソン[I]の頃のヴィルとかぶってる気がしたり、 ベゼル語って授業で教えてるくらいならもうちょっと普及してんじゃ ねーのとか思ったりもしなくはないが…。 「リリアとトレイズ」のスピンオフなので、最初のうちは ちらっと脇役のように登場するリリアの登場具合が面白かったりしたが、 途中からはそんなことよりメグかわいすぎ。