ファミ・コンパーチブル（改）

あきばお〜で買い物ついでに。。。
600円弱とちょーお安かったのでw

背面についてる端子は写真の通り。
コンポジット端子なのでその辺のモニタに気楽にさせるわけですが、ちょっと配置が変（笑。付属のケーブルも赤／黄だったりして、なんじゃ？　って感じ。

答えから言うと、白と赤にはまったく同じ信号が配線されてます。日本ではステレオに繋ぐ時にもL（白）だけ繋げれば自動で左右に展開されるのが一般的ですが、大陸では違うのでしょうか。。。謎は深まります。

ちなみにACアダプタ端子が付いてますが、添付の紙っぺらによれば使用禁止。
・・・PSE通ってないから？　一応電池4本でも動くんですけど、電池は面倒です。
「まぁ、その辺のアダプタをさせば動くだろう・・・」
と甘い考えでその辺に転がってたアダプタをさしたら

ぷつんっ
「あっ」
・・・ぷ〜ん（異臭）・・・

やべー、やべー。
ってことでさっそく分解して調べてみたら極性が逆でした。

しかし、この電源作りが怖いです。。。
アナログ弱いんで理解が怪しいですが、トランジスタ（8550）１つで定電圧回路を作ってました。エミッタベース間に逆電圧をかけてツェナー効果で6Vを作っている模様。

ってなもんで、試しにセンターマイナスのアダプタを挿してみましたが、電圧が不安定なせいで画面がぶれまくり。

しかも、めちゃくちゃ熱くなるので要注意。。。

これじゃ使えないな、という事で例によってUSBから電源拾えるように（笑

写真の位置が空きスペース的にも固定するにもあつらえ向きでした。ここからUSB配給の電源を電池ケースの+/-に繋ぎ込めばOKです。

電圧が6Vから5Vになりますが、まぁ大丈夫でしょう。というか、むしろ5Vが本命な気はする。

で、多くの互換機と同じように拡張音源に対応してなかったので、ついでにその辺もプチ改造。カートリッジの45番ピンと46番ピンがショートしてるので、パターンカット。カートリッジから出力端子に繋がってるケーブルのA(udio)線をカットして、基板側を45番に、A(udio)線を46番に繋ぎ込めばOKなはず。

という事でためしにマダラを。

う〜ん・・・鳴るようにはなったけど、バランスがいまいちでした。FC音源側が極端に小さく鳴ります。

45番と46番の間にダイオードと抵抗挟むくらいで調整できないかな。。。
アナログ詳しい人いたら弟子入り希望（笑

という事で、ちょっと息抜きの寄り道でした。満足したのでこいつはステステ（ぇ

（注）この記事は無保証ですので、改造はAYORでお願いしますね。

浮気なぼくら

そのうちハードからOSに・・・とか言っておきながら、実は最近の休み時間活動はVNC@Haikuだったりしました（笑。

普段、設計用の端末ではUbuntuが動いてたりするんですが、そろそろ飽きてきた（かつ、ドライブの空きがなくなってきたw）かなぁ・・・と。

端末ならVNCが動けばたいていは事足りるので、ここは一つHaikuでも、と思ってBeOS用のVNCを動かしたんですが、なんでこんなに・・・ってくらいに糞重い！　なんでだろ・・・とか思ってVNCのプロトコルを調べてみたら、結構まとまった資料になって公開されている模様。それならば・・・という事で、プロトコルの調査がてらクライアントを作ってみました。

もともとVNCはアプリケーションレベルで色々組み込んでも遊べるかなぁ・・・って事で、興味は持ってたんですよ。例えばAVR上のMZ-80Kエミュレータの画面がVNC over UARTで飛んでくる、とかね（笑。

とりあえずハマったのはtwitterでも呟いてた認証の部分。標準のVNCAuthではDESを使って認証するんだけど、暗号化する時のパスフレーズ、なぜかバイト単位で上位下位を反転してやらないといけない。自分の書いたDESが間違ってるのかと思って、色々なライブラリと期待値比較しちゃったよ。。。

とまぁ、そんな感じでボチボチ動くようになったVNCクライアント。とりあえず家でも32bit rawという一番単純なプロトコルでOS Xの画面共有に接続してみたけど、LANで使ってる分には普通にサクサク動く感じ。なんで世の中のBeOS向けクライアントがこんなに重いのか・・・わけわからんちんですよ。

カーネル／VM探検隊

同じ会社にしばらくいると、少し外の空気を吸わないと・・・という気分になります。
Lionsもその一環なのですが、しばらく前にngcomで「最近は勉強会が流行っている」
という話を聞いたので、なにか面白そうなものがあれば参加したいな・・・と思い
目をつけていたのがカーネル／VM探検隊。ちょうど仕事にも余裕が出てきたところなので、
平日開催という敷居の高さを乗り越えて（午後からエスケープしたとも言う）参加して
きました。

まったく知った顔がいない、という状況は凄く久しぶりで、言葉通じるのにまるで
海外出張みたいにドキドキしてしまいました（笑。そうは言っても、実は大学の同期も
いたのですが、すいません人を覚えるのがトコトン苦手な私。。。うっすらと記憶に
あるものの、よく覚えていませんでした（汗。一応、だんだんと記憶は戻ってきて
最後にはなんとなく思い出してたんですよ。。。とフォローはしておきます（笑。

本業の面では畑違いなんですが、Plan 9とか、SheevaPlugとか、プライベートな嗜好では
思いっきりストライクゾーンで、人見知りとは別の意味でドキドキワクワクな時間でした。

LTのタイマー割り込みの話とか妙に盛り上がって（一部の？）参加者のハイレベルっぷりに
ときめいたりしてました。自分はv6のclock.c callouts近辺のコードしか頭になくて、
どこまで話についていけてたかわかりませんが。。。
先日の社内でのsignal話もそうなんですが、今まで身近にkernel hackerがいるって状況に
なかなか巡り会えなかったので、最近のこの体験はちょっとした感動です。

そのうちLTネタくらいは出したいなぁ。

P.S.
スライドがド派手な人が多くて驚いた。最近はこれが普通なのか。。。あと、OS Xを
使って長いくせに、画面の一部を拡大したり・・・って機能をまったく知らなかったorz

脈々と続くV6の血

仕事で、Linux kernel担当者のところへsignal周りの処理を質問にいった。
コードを見ながら色々と説明してもらった。

ところどころSMPを意識したコードが入ってはいるが、
基本的な処理の流れはV6のそれとまったく同じだという事に驚いた。

計算機に携わる以上、Lionsは一通り読んでおいて損はなかったな、と思った。

。
。
。

と言いつつ、ちょっと昼休みのコード読解は止まってまして、
しばらく思いつきで始めたこんなことをやってました。

CP/Mの次はMZ-80K、700、その次はApple II・・・と少しずつ
複雑なハードを再現したいなぁ・・・とか思ったりしてるのですが、
適度なところで飽きて、またOSに戻ってくると思います。

要素技術は身につけたので、AVR上でV6相当のOSを・・・とか
思ってたりするのですが、壊れたLANTANKを、とか玄柴さんを・・・とか
遊ぶネタは盛りだくさんです。LANTANKを会社に持ち込んで遊ぶのは
ちょっとアレかもしれませんねぇ。。。

Lions' Commentary (8) - lshift -

なんかまた色々と忙しくなってきちゃって進みが悪いんだけど、read / write 周りのsystem callが一通り追いかけられた感じなのでブログにエントリしてみようかと。

readi / writei は今までに読んだbio.c周りのバッファを使ってブロック単位に読み書きしてます。inodeから論理ブロック番号に変換して、最終的に物理ブロック番号を求める当たりもこの辺に。ファイルのオフセットからブロック番号とブロック内オフセット位置を求めるところでlshiftというアセンブラルーチンを呼んでまして、普通に書けば簡単な関数なんですが、アセンブラで良くわからん命令があって、ちょっと読解に苦戦しました。これは後述します。

ファイルの読み書きは基本512バイトのブロック単位で行うので、書き出しの際に1ブロック丸々上書きにならないような場合にはread modify writeの処理が入ります。また書き出し時には512バイト境界をまたぐごとに非同期書き込み要求を出し、境界に達しない半端な書き込みはバッファブロックにDIRTYと印を付けておき、バッファがLRU制御で追い出される際に遅延書き込みで吐き出されるようになってます。ブロック番号が直前に読み出したブロック番号+1になっていると、シーケンシャルプリフェッチが働くようになっており、古典的とは言えI/O処理の基礎は一通り完成している感じです。

プロセス管理やメモリ管理はLions'のみで一通り理解できてきた感じですが、I/O周りとなるとソース読解だけではなかなか理解が進みませんね。この辺はBach本の併読が遠回りなようで近道かも。

で、問題のlshift。例によってconf/m40.sです。

.global _lshift
_lshift:
    mov    2(sp),r1
    mov    (r1)+,r0
    mov    (r1),r1
    ashc   4(sp),r0
    mov    r1,r0
    rts    pc

「ashc」の使い方が良くわからなくて悩んだんですが、右オペランドがデスティネーションで、偶数レジスタを上位、奇数レジスタを下位としたペアレジスタに対して算術シフトを施す、という事ですね。この場合、r0が指定されているので、(r0 << 16) | r1 が操作対象というわけです。で、左オペランドがまた4(sp)なんて書かれているもんだから意味がわからなかったんですが、これがシフト量ですね。すっかりRISCが染み込んでしまっていたので、シフト演算の入力がオフセット付きレジスタ間接アドレッシングというのは、ちょっと斜め上をいく感じでした。結局、2(sp)が第一引数、4(sp)が第二引数なので、C言語で書けば

u16 lshift(u16 *vptr, s16 n)
{
    u32 v = (vptr[0] << 16) | vptr[1];
    if (n >= 0) v <<= n;
    else v >>= -n;
    return v & 0xffff;
}

これだけの処理。というか、やりたい事はu32値をブロックサイズ512で割りたいだけなんですが、なんとも面倒な話です。同様にdpcmpなんて関数もありまして、こいつも長々と書かれてますが32bitでcompareとるだけのアセンブラ関数でした。実際には減算結果を返し、結果は-512〜512に丸められます（という概要だけでも知ってればだいぶ読みやすいはず）。

PDP-11の命令フォーマットはオペランドに関しては基本的に6bitがアサインされており、3bitでレジスタ番号、残り3bitでアドレッシングモードが指定できるんですね。 CISCという意味では直行性があり洗練されてたのかもしれません。
＃レジスタ間接アドレッシングってPDP-1のINDビット以前は存在したんだろうか。。。ディレイスロットもそうだけど、プロセッサの歴史の中で誤った方向へ進んでしまった最初の一歩の１つのような気がする。

Lions' Commentary (7) - closeとunlink -

I/Oバッファから、i-node関連の処理、あるいはファイルデスクリプタの実体操作、ファイル処理などの関数に取りかかってきました。パイプ用の処理が分岐で書かれているのがちょっと気になります。キャラクタでバイスやブロックデバイスはそれぞれの特殊処理はドライバ側あるいはその上位層で処理しているのですが、パイプだけは各処理の中で直接分岐して書かれています。この頃アドホックにインプリされた物が後継版で整理されていくのでしょうか。。。名前付きパイプなんて出てくる頃には綺麗に書き直されている気がしますね。System IIIで実装済みなのは知ってるので、どんな実装か確認しようと思えばできるのですが、ちょっと後回しかな。しかし、正確に発明されたタイミングはどの時点だろう？

あと、UNIXでは伝統的な挙動、ファイルは消しても誰かがオープンしている間は実体が消えない、というやつ。自分は大学の先輩（mick'n）から教えてもらった気がする。これもcloseのsystem callを追いかけていると見つかります。fork時に実体の参照カウントはインクリメントされるので、close時に参照カウンタが1の時のみファイルデスクリプタの実体を閉じます。んで、この時にi-nodeのlink数を調べて0以下だったらtruncateしてi-nodeを解放する、つまり実体を削除する、という処理になっていました。

Lionsを読むと、このあたりの実装はテンポラリファイルの運用を簡便にするための物のようですね。プロセス生存中はpidがシステムでユニークである事をOSが保証しているので、そのpidを交えた名前はプロセス内で衝突しない限りはシステムでユニーク。で、プロセス内では生成直後にunlinkしちゃえば、他からは触れないし、上書きされる心配もない。で、使い終わったら明示的にcloseすれば削除されるし、segvで落ちちゃった場合なんかでもOSがプロセスの解放処理をする際に全ファイルをcloseしてくれるので自然に実体も削除されるという。simple is bestな実にUNIXらしい考え方です。

Lions' Commentary (6) - I/Oバッファ -

書籍のAmazonへのリンクの出し方がわかったので入れてみました。

Lionsのほうはドライバの構造から入って参考にRKのドライバ周りを一通り読みました。
複数のドライブを1つの大容量ドライブに見せる仕掛けとか入ってました。

Bach本ではバッファキャッシュの話が最初にあって、読んでいて「あぁ、文明の光・・・」って感じでした。6版の場合、複雑に作ってもむしろ性能が落ちるような規模のシステムなので、リソース管理は非常にシンプル。一方でこちらはいきなり複数の双方向リンクでバッファを管理するような話で、いっきに近代化された印象を受けます。

が・・・Lions本で先に進むとdmr/bio.c つまり バッファ周りのソース。ここがまさにバッファキャッシュになっていて、Bach本とほぼ同じ構造で管理してました。違うのはハッシュを使ってるかどうかってところくらい。高々15エントリなんですが、LRUで置き換える事を考えるとやっぱり真面目にリストで管理するしかないですかね。

という感じで、わりと相補的に読めます、この2冊。
実際、Bach本で読んでスルーしてた循環リスト構造、Lions本でincore()を読んでいて、なんでこのループで正しく処理できるんだ・・・みたいにハマってしまって、再びBach本を見てみたら図解で細かく説明されていたという。。。