ハル・コーポレーションのクロッサム２＋という学習リモコンを購入した。我が家 にある、ケーブルテレビのホームターミナル(Pioneer BA-V520)の赤外線リモコン(BR-V520) のコードは、このようになっていた。 (テキスト・データ) このデータは、学習した信号をHALで昔作られたツールで拾いだし確認し、このツ ールのプリセットしてある、パイオニアのデータに埋め込んで作成した物です。お そらく間違いはないと思うのですが、チャンネルのアップだけ反応がないことがた まにあります。
今朝新聞を見ていたら、ソニーがITテレビなるものを発表していた。WEBの方を見た とところ、本体にはテレビとブラウザとメーラの機能があって、2.4G無線LANを使っ てベースステーションと通信するらしい。実は自分もPerforma 6410のBT878でテレ ビをキャプチャしてそれを無線で飛ばしてC1で見れたらいいと思っていたのだが、 これはそのものの製品である。どのようなプロトコルで通信を行なっているのか興 味があるところである。
某ケーブルテレビに申込を行なっているのだが、話しをしはじめてから5カ月も経と うというのに、未だにサービスが受けられていない。ずいぶんケーブルテレビの会 社には、クレームをつけているのだが、ひょっとするとそもそも筋違いなのかも知 れない。インターネット接続に関して考えれば、NTTや東電やらが自分たちの電柱を ケーブルテレビの会社には貸しにくくして普及を遅らさせ、自分たちのサービスを 普及させやすくしようとしているのではないかと、勘ぐってしまう。(ここのところ NTTはDSLの交換機を着実に増やしており、この詮索はあまりはずれていないように も思える)
ひょんなことから、我が家に真空管のアンプがやってきた。今はレコードをこの真 空管アンプで聞いている。まったくアナログな生活である。
またまた、飛行機の中で書いている。昨日のニュースステーションで、ゲノムの話 しをしていた時に、IT産業でのデジタルデバイドを問題視するような話しがあった。 しかしながらゲノム産業において、このデジタルデバイドの様な事が起きる方がより 問題のように思える。情報などは所詮興味がない人もいると思われるのだが、生死に 関わるような事を、デバイドされてしまうのは極めて問題と思う。
今回乗った飛行機は767-300と新しい物であったが、福岡から帰ってくる時に乗った 747とは違ってずいぶん安定して離着陸していた。やはり古い機体はちょっと恐かっ たりする。
Appleシンパではあるが、AirMac 1.2のサポートに非常に問題を感じている。米国で 1.2がリリースされてから、国内でのリリースがいつになるのか都度都度Appleのftp サイトをみていたとことなかなか発表されなかった。ところがAirMacのサポートペ ージをみていたら、1.2は9.0.4にソフトウエアアップデートの機能を使って、提供 されている事がわかった。AirMac 1.1では管理ツールは8.6以降のサポートだったの に、突然9.0.4でしかアップデートできないというのはげせない。また、システム自 体のアップデートならともかく、周辺機器にまつわるアップデートをこのような環境 で提供するのは、あまり良いとは思えない。でしょうがないので、iMacの9.0.4のソ フトウエアアップデートを開いて確認したと事、AirMacの項目はでてこず、ソフトウ エアアップデートのアップデートしか出てこなかった。とりあえず、この項目をアッ プデートしたとこと、もう一度ソフトウエアアップデートを確認した事、今度は表示 された。で、AirMacをアップデートしようとしたら今度は、なかなか進まず、今すで に30分以上経過しても表示は半分くらいである。そもそもルータのトラフィックを表 示するインジケータはそれほど点滅していない。おそらくサーバ側に問題があるよう に思われる。たまたま今日調子が悪いだけとか、環境に依存した問題の可能性もある が、ともかく腹立たしい。
WIDE関係の方が実装されたIEEE1394のドライバをカーネルに組み込んで、試している のだがなかなかうまく動かない。最初はカーネルが立ち上がらないような状態だった のだが、無理矢理うごくようにして見ているのだが、良くわからない。この実装はネ ットワークの機能として実装されているのだが、デバッグするのには骨が折れる。
iMacDV(MacOS 9.0.4)のDHCPが今一つ調子がよくない。NM128 SL11(Ver1.40)がサー バになっているのだが、NM128->AirMac->P6410->iMacDVの順で起動するとNM128の DHCP情報がおかしな状態になっていた。もしこの次に問題が起きたら、もう少し 調べてみようかと思う。
AirMacのアドレスはNM128から取得しているのだが、停電が起きた時には、立ち上 がりのタイミングによってアドレスの取得がうまくいかず、復旧後もネットワーク が復旧しないというような問題も考えられる。AirMacの設定で電源投入後にDHCPす るまでの時間を設定できると良いのではないかと思う。
上記の問題をチェックしている時に気づいたのだが、MacOS 8.6まではTCP関係の アプリケーションが起動されるまで、IPアドレスを取りにいかないのだが、Mac OS 9からは、システム起動時にかならずアドレスの取得を行なうようである。
突然ではあるが、SE/30と6410の組合せでMPWに入っている、Power Mac Debugger でリモートデバッグを試してみた。かなり悩んだのだが、手順は次の通りであっ た。まず、二つのマシンのシリアルポートをクロスケーブルで接続します。今回 はプリンタに使っていたケーブルを使った。次に実際プログラムを起動する6410 (ターゲット)のシステムに、Nubファイルを3つ入れて再起動します。SE/30にPower Mac Debuggerとソースとxcoffファイルを持っていき起動します。これでリモート デバッグが可能になります。実際に追いかける時にはプログラム中にDebuggerを 入れて、コンパイルして一旦止めて、観察するようにするのが便利のようです。 この操作で、一応動いたのだが、さすがにSE/30では遅すぎるのか、エラーが頻発 して実際には使い物にならなかった。:-(
MacintoshのコントロールバーからNM128の回線を切ることができるプログラムを 作ってみた。
C1に附属のUSBフロッピドライブをiMac(MacOS 9.0.4)につないでみたところそのま まで使える事が確認できた。以前VAIO505(Windows 98)にこのドライブをつないだ ところドライバを追加までしても正常に使えなかった事を考えると、OSの完成度の 違いを感じる。
上記のドライブは実はMacOS 9の最初のリリースではサポートできていなかった。 しかしながらMacOS USB SDKにはUFI(USB Floppy Interface)をサポートしたMass クラスのドライバのサンプルコードが入っていたので、これがOSにバンドルされ たのだと思われる。
昨日の新聞にBSデータ放送でホームバンキングを実現するという動きが報じられて いた。個人的に思うとところとして、いくら帯域があるからといって、個人宛の情 報をブロードキャストで提供するのはあまり効率の良いシステムには思えない。ま たセキュリティ的にも問題はないのであろうか?
ものしりフクロウのソースのリゾルバへのアクセス部分をMixedModeマネジャーを 使うように変更していた。ある程度は動いたのだが、一部正常に動作せず、調べた ところ、Univasal Header 2.1のころのヘッダーと同じように修正したソースとヘ ッダがあり、これを使うようにしたところPPC版も正常に動作するようになった。 ところが、TCでおなじソースをコンパイルしたところ、今度はこちらが動かなくな ってしまった。調べたところ、コードリソースに飛び込む時のパラメータの一つが 新しいヘッダーではenumで宣言されており、これがTCではかならずint(16bit)にな ってしまう為に、実際のサイズ(long)に合わなくなり問題を発生していた。あとは MacOS 9でアイコンがガビガビになるのを修正したら、アップしたいと思っている。
アイコンがガビガビになるのはBNDLビットがセットされていないファイルをコピーし てその情報が残ってしまった為のようである。(この問題はディスクトップを作り直 したら発生しなくなった)TCではビルドすると勝手にセットされていただのが、MPW ではsetfileコマンドでセットしないといけないようである。
ものしりフクロウはどうにかコンパイルする事ができた。ついでにPPC版もビルド してみたところ、ビルドはできた物のアプリケーションエラーを起こして立ち上 がらなかった。調べてみたところホスト名からアドレスを解決するルーチンがMacTCP では、コードリソースとして提供されていて、PPCコードからこれをメモリに張り 付け、飛び込む為にアプリケーションエラーになっていた。MixedModeマネジャーを 介してアクセスはできると思うが、今更にちょっと面倒である。(これはCarbonで は当然サポートされなくなるルーチンである)
今年の2月にリリースされたMPWにはUnivasal Header3.3が入っていた。この環境で ものしりフクロウをコンパイルしたところかなり修正が必要であった。ところが このアプリケーションで使っているWASTEというテキスト処理のライブラリは全く 警告さえなくコンパイルできた。格段のセンスの良さを感じる。見習いたいものだ。
wireless lanのカードで思ったほど帯域が使えないと書いたが、Performa6410の Fetchのバッファの設定を変更したところC1とのftpにおいて4.8Mbit/Sec弱のパフ ォーマンスが確認された。
去年の二月からAppleはCコンパイラの入った MPWをWEB上で配布 していたようである。昨日これを知り早速だダウンロードしてみた。CordWarrior の購入も検討したいたのだが、MPWは以前少し仕事で使ったことがあり、これでち ょっと試してみたいと思っている。
物作りの姿勢として自分の中ではInternet的とMicrosoft的とは両極に感じられる。 極端にいうと前者は「バグが出やすいプログラムは作らない」という姿勢であり、 後者は「たとえバグが出やすくなっても機能を実装する」という姿勢と思えるから だ。
たしかにできない事に向かってチャレンジする事は大切であると思う。しかしなが ら自分の背景から極端に遠いところに目標をおいて無理をするのははたして美しい 事であろうか。
すこし前の事であるが、“ものしりフクロウ”を使ってくれている人からお礼のメ ールがあった。このメールに触発されて、久しく使っていなかったのだが、おうち でもndtpdの設定をして試してみた。やはりエラー時のインターフェースをまったく 実装していないので、ちょっと戸惑うところがあった。:-)AirMacを通して“ものし りフクロウ”が使えるのは、なかなか面白い。
実験的におうちで、RADIUSのサーバ を立ち上げてみた。最初はサーバとNM128 SL11のデフォルトのポートが違っていて うまくいかなかったが、これをSL11に設定したら正常に動作した。
ずいぶんと長いこと、このページのアップデートをしていなかったものだ。先日彼 女がiMacと一緒にAirMacを購入した。これをFreeBSDから使えるかを調べたところ PAOのメーリングリストのアーカイブにすでに使っている人の書き込みがあり、す かさずMELCOの11Mのカードを購入して設定して試したところ問題なく使えた。ftp でlibretto->AirMac->C1の経路でデータのダウンロードを行なったところ、 2.4M程度のスループットであった。しかしながらワイヤレス経由でネットワーク上 のホストのktermを使ったところ十分に快適に使えた。
下記にまったく問題無くと書いているが、30フレームに一回程度のオーバーフロー は発生しているようである。ただ目に見える程度の物ではない。BT848ベースのカ ードをMacintosh用として、販売しているケースを見ると320×240のYUV2のフルフ レームのサポートまでと書いている。おそらくMacintoshのスペックではこれが 限界の値なのかもしれいない。
今使っている6410のビデオはPCIバスのATIになるので、これのフレームバッファに BTから直接DMAしてみたところ全く問題無く表示が可能であった。
久しぶりにMacWorldに行った。昔勤めていた会社の人間などにも会えた。ショップ のブースの辺りをいろいろあさっていたのだが、めぼしい物がなく6410で使える 5インチべイのマウントするための部品の中古を10円で 買ってきた。
BTドライバであるが、現在のアプローチではおそらくうまく行かない事がわかった。 これは、DDKのドキュメントによる通常のPCIからメインメモリへの書き込み能力は 20MByte/Sしかない。フルフレームのキャプチャでは35MByte/S程度のバス能力が必 要になるので不可能であると思われる。またMacintoshでは最大の書き込み処理能力 は80MByte/Sとなるが、これはデバイスがMemory Write and InvalidateというPCIの コマンドを使用してメモリアクセスをする場合であり、BTはBus Masterになる場合 にはこの機能をサポートしていない。この機能は、キャッシュラインに含まれるす べてのデータ(おそらくMacintoshの場合32Byte)を書き込む事で、キャッシュを即座 に無効して転送する方法である。
今後の作戦としてはYUV2(16bit)などのデータ量が少ないフォーマットの利用を考え、 またサイズも320×240程度を対象にすることが考えれる。またPCI上にあるATIのフレ ームメモリへの直接転送も検討してみたい。
会社から借りているNTT DocomoのPHS(622S)は文字メールに対応したものなのだが、 画像の添付に関して調べたところBMPをMIMEのマルチパートで添付している形をとっ ているようである。画像データを他メーカ製の携帯やPHSに送ったところ、互換性が ない場合が多いようであった。またNTT DocomoのPHSを使ったメールサービスは英数 字8文字までの別名が付けられるのだが、これを付けた場合でも、元からある電話番 号ベースのアドレスも使える。Internetメールに速くから対応していた、J-Phoneも 昨年の年末にやっと別名のサービスを開始した。こちらも電話番号ベースのアドレ スが並行して使える仕様になっている。iModeの場合には別名を付けた時点で、電話 番号ベースのアドレスが使えなくなるようである。
BTドライバは年明けからずっといじっているのだが、いまだに問題が解決していな い。MacOSのPCIドライバのSDKが新しくなっていたのでダウンロードしてみたが、あ まりかわりが無いように見える。DMAの問題によりINT_STATレジスタのFBUSがセット される事が確認できたが、これがなぜ発生するのかは不明である。
下記のドライバはあくまで低レベルのコントロールを行なうためのもので、QTでキャ プチャを行なうためには、このドライバをつかったデジタイズコンポーネントを作成 しなければいけない。先はまだまだ長い。
正月は昨年の夏にちょっと書きかけた、MacintoshのBT878(848)ドライバのデバッグ をしていてた。このコードはFreeBSDにあるドライバのコードをベースにしている。 BT878にはRISCというDMAをコントロールするインストラクションがありこれを適当に 作成してメモリにのせ、このアドレスをレジスタにたたき込むことでフレームのキャ プチャが可能になる。一通りの処理はできているのだがフレームをキャプチャした時 にどころどころのラインでDMAが処理されない部分が発生している。 (こんな感じになります。DMA転送されない部分は前の 処理のデータが残ってしまっているようです。そもそもフレームの偶数と奇数もずれ ているように思われます。)もうそろそろあきらめかけているのですがだれかヒント がある人は教えて欲しいです。しかしAppleのPCIのDDKにあるサンプル(SCSI)は私が 知るAppleのもののなかでは一番ひどいものである。このようなドライバのサンプル の場合当然同じ環境は用意できないので、バーチャルな環境を対象にした機能説明に するべきと思われるのだが、完全にデバイスに依存したコードのサンプルで非常に分 かりずらいものになっている。
