USB外付けキーボード利用時の便利な操作をまとめたメモです。
ELECOM TK-UP84CP にて確認しています。
■一般操作
[ALT]+[半/全 漢字]
IME ON/OFF
[F1]
ソフトキー1 (左-)
[F2]
ソフトキー2 (右-)
[Win]+[F6]
(OK)ボタン相当
[Win]キー
スタートメニュー
[ALT]+[カタ/ひら/ローマ字]
ローマ字入力、JISかな入力の切り替え(MS-IMEのみ、ATOK不可)
[SHIFT]+[CapsLock/英数]
CAPS LOCK On/Off
■Today画面のみ
[F6]/[F7]
ボリューム Up/Down
一日中、暇があれば GeForce8800 の記事ばかり眺めていました。
D3D10 世代、ShaderModel4.0 世代の GPU の発表です。
http://www.nvidia.com/page/geforce8.html
GeForce8800 はアーキテクチャ自体が完全に異なるフルモデルチェンジです。
nVIDIA の GPU はだいたい2世代ごとに完全に生まれ変わります。
NV3 RIVA128, RIVA128ZX
NV4 RIVA-TNT, RIVA-TNT2
NV10 GeForce256, GeForce2 hwT&L
NV20 GeForce3, GeForce4 SM1
NV30 GeForceFX5800 SM2
NV40(G70) GeForce6800, GeForce7800 SM3
G80 GeForce8800 SM4
失敗作(?)だった FX を除いて大幅なアーキテクチャの刷新と、マイナーバージョン
アップによる高速化を繰り返しています。なので 7800 を買っても機能的には 6800
とほとんど同じだけど、8800 は完全に違います。速度ではなく機能を求めるプログ
ラマ的には今が買いです。
アーキテクチャの改変時は、機能が大幅に増える代わりにあんまり速くなっていない
ことが多々ありました。新しい機能を使えばもちろんパフォーマンスというかできる
ことは比較にならないのですが、例えば DX7 未対応のアプリケーションでは
GeForce256 より TNT2 の方が高速でした。
しかし 8800 は、新しい Shader4.0 を使わなくても従来の 3.0 アプリケーション
でも 2倍の速度で動くらしい!! これで D3D10 のアプリケーションが走ったら、
一体どこまでできるのやら。本当はすぐにでもほしいんだけど、
もしかして Vista が出るまで D3D10 は待ち？
もしかして DirectX10 SDK のリリースまでおあずけ？
もしかして Vista 用の 88 対応ドライバがまだ？
全部揃うまでもうちょっと我慢がいるみたいです
http://ch09144.kitaguni.tv/e310975.html の続き
GPU でもプログラミング言語が走るようになって怒涛の勢いで進化しています。
ですが、PC でいう x86 や組み込み機器でいう ARM やゲームコンソールでいう
PowerPC のようにバイナリレベルで何らかの共通化が行われているわけではありません。
(もちろん ARM や PowerPC は結果そうなっただけなのですが)
nVIDIA の GPU や ATI(AMD) の GPU では、ほぼ同じシェーダーの機能を使うことが
できるものの、内部のバイトコードは全く別物だと考えられます。
HLSL で書かれたシェーダープログラムは、vsa, psa, fxc や D3DX によって
Direct3D の仕様として決められた仮想 GPU のバイトコードに変換されます。
このバイトコードは D3D のアセンブラ命令とそのまま対応しており、D3D の仕様
そのものでもありました。
ビデオカードのドライバは、D3D のバイトコードを受け取ってから実行前にそれぞれ
のネイティブのバイトコードへ変換が行われます。
もしかしたらほとんど D3D の仕様とそのまま同一なのかもしれませんし、メーカー
ごとにもっと大胆な最適化が行われていて非常に異なったコードに変換されている
のかもしれません。
ですが HLSL のコンパイラは D3D の命令への変換だけ考えればよく、最適化もこの
共通コードに対して行われます。
この仕様のおかげでドライバは独自の最適化を行うことができて、かつ命令セット
アーキテクチャ ISA にとらわれずに機能の向上が図れるのだと考えられます。
そう考えると .NET Framework に搭載されている CLR はいわば、CPU のための
デバイスドライバなのかもしれません。
CLI という統一された仕様の MSIL のバイトコード上ですべての処理を考えておけ
ばよく、実際にプログラムが走るときはデバイスドライバが勝手にネイティブのコード
に最適化を行います。CPU 毎の差を吸収できるので、GPU のように ISA レベルの
互換性にとらわれずに性能の強化を図れる・・のかもしれません。
ZERO3[es]のバッテリーメーターの減りが早くなってきたのでリフレッシュして
みました。いったんバッテリーを完全に空にしてからフル充電して、これを2回
くらいやっとけば元に戻るはずです。
バッテリーを空にするために試したのがネットのストリームラジオの連続再生です。
iPAQ のときは CF アダプタに LAN ケーブルつないで、よくデスクサイドの
プレイヤーとして使ってました。
[es] の場合は PHS 接続なので、最初は 24Kbps あたりからおそるおそる実験
開始です。使ったソフトはGSPlayer、回線はデータ定額 (4x 最大128Kbps)。
24Kbps は結構余裕で、48Kbps も OK。予想以上に結構いい感じです。
64Kbps も窓際など回線状態が安定している場所でじっとしていれば大丈夫でした。
64Kbps は MP3 のモノラルなので、音質的にはステレオだと 128Kbps 相当だから
もう十分です。
96Kbps のステレオもサーバーや回線状態によってはたまに途切れたりするものの、
条件さえ安定していればなんとかいけそうな感触です。
ブラウザ使ってるとあんまり速い印象は無いのですが、レイテンシを無視できる
ストリーム再生だとそれなりにスループットが出てるみたいです。少々意外でした。
年末には W-OAM 対応の W-SIM が出るそうなので、これだと速度は 204Kbps まで
出ます。非常に楽しみになってきました。
これ
http://www.willcom-inc.com/ja/lineup/rx/420al/index.html
http://ch09144.kitaguni.tv/e310974.html の続き
CPU 依存の無い共通のバイトコードといえば昔 WindowsCE にもありました。
WindowsCE は小規模な組み込み向けに使われる OS でプラットフォームを選びません。
HandheldPC や PocketPC など、PDA でも当初は SH3, SH4, MIPS などさまざまな
CPU が使われていました。プログラムを作る側も使う側も、同じ OS だけど CPU の
違いを意識しなければならずたいへんです。
そのため一時期 CEF と呼ばれる共通のバイナリ形式が登場しました。やはり仮想の
バイトコードの形にコンパイルされて、実行前にネイティブなコードに変換されます。
一度変換すると以後はネイティブコードのアプリケーションとして振舞います。
しかしながらあんまり使われることは無く、その後のバージョンで PocketPC は
ARM アーキテクチャに統一されてしまったので、CEF の意味もなくなってしまい
ました。ZERO3 も HTC の WindowsMobile 機も全部 ARM です。
WindowsCE 向けにも .NET Compact Framework が登場しています。やはり PC 版と
同じように共通のバイトコード MSIL を使うので、今だったら CPU の種類が多くて
もそんなに困らなかったのかも、、しれません。
(続く)