IRCS hardware

インテリジェントリモートコントロールシステム概要
ＩＲＣＳ (Intelligent Remote Control System)

著作者ＦＥＺこと吉村哲郎

●はじめにハードウェアありき

　赤外線リモコンをコンピュータで制御する。たったこれだけなのになぜか難しい。その理由を端的に述べよ。

　ずばりは、
　「ハードウェアは規格化されているのに、ソフトウェアは規格化されていないから」
　という単純な理由に他ならない。

　そもそも、赤外線リモコンをいじくる事はそうそう難しい事ではないはずだ。やろうと思えば誰にだって出来るはず。ただ、管理するとなると話しは変わってくる。将来を見越して設計したソフトウェア体系が必要になってくるのだ。既存の規格なんてものは存在しない。どうせ作るなら最初から美しい規格を！

　…というわけで今回めでたくＩＲＣＳ規格を発表する運びになった。

　IRCSの特徴としては、

アプリケーションはホストコンピュータに依存しない
ハードウェア依存するのはドライバのみ
現存する赤外線リモコンの規格に全対処することが可能

　という極めて当たり前な、しかし一番重要な事項を全て押さえている。

　IRCSは３つの階層からなり、

低位：ハードウェアドライバ
中位：ライブラリ・言語翻訳処理サーバ
高位：アプリケーション

　にそれぞれ分割される。
　勿論、中位に当たる部分はさらに何層かに分かれる可能性があるわけだが。

●基本データ形式

・raw data（生データ）
　76800bpsで取り込んだデータをLSBから順に並べたもの。いわゆるビットデータの羅列がそのまま 1 と 0 の意味を為す。ここでの１ビットは76800bpsでの１ビットに相当する。
　この形式はデータ量が膨大になってしまう上に、データ加工も面倒なので、IRCSでは基本的には使用しない。構想初期の名残として残っているだけである。

・ＩＲＤ（ランレングス形式）
　そこで、ランレングスで符号化したものをＩＲＤとして定義する。実際の定義としては次のようになる。

_IRD	struc		; assembler
  _on	dw     ?
  _off	dw     ?
_IRD    ends

struct _IRD {		/* C */
    word  _on;
    word  _off;
};

　上の構造体をＩＲＤ構造体として定義する。即ち、最初のワードにビット１の個数が入り、次のワードにビット０の個数が入る。ここで云うところの個数とは、生データでいうところのビット数に他ならない。
　一般にＩＲＤと呼ぶデータはこの構造体を必要な数だけ並べたものであり、必然的にデータの大きさは必ずダブルワード単位になる。

　ハードウェアドライバに対するアクセスはこのデータ形式を用いる。一見簡単ではあるが、このＩＲＤ構造体の定義こそがIRCSにおいて最も重要な定義なのだ。

●ローレベルドライバの詳細

　ここでは、既存のドライバである IRCS98.COM を解説する。全てを理解するには少なからずＤＯＳとデバイスドライバの知識が要求されるだろう。

・ドライバの構造　一般的なＤＯＳのキャラクタデバイスという形式をとる。インストールするには、CONFIG.SYS内に DEVICE=ステートメントで記述すれば良い。ADDDRV等でのインストールも可能だ。デバイスドライバの構造そのものの情報に関しては膨大な量に及ぶので既刊の解説誌等を参照されたし。

・ＡＰＩエントリの取得
　ＤＯＳを介したアクセスでは何かしら不便な現場に遭遇するので、IRCSでは独自のAPI(Application Programming Interface)を搭載している。このＡＰＩを呼び出すには、まず呼び出すためのエントリアドレスを取得しなければならない。具体的にＣ言語でのソースを例に挙げてみよう。

    handle = open("IRCS",O_RDONLY);
    ioctl(handle, 2, APIentry, 4);
    close(handle);

　デバイス IRCS をオープンし、そのハンドルに対する４バイトの READ IOCTL を実行すればエントリアドレスが得られる。あとはハンドルをクローズして終了。勿論、実際にインプリメントする際にはエラーチェックも忘れてはならない。
　open()や ioctl()で失敗した場合は、IRCSローレベルドライバがインストールされていないということになる。

・IRCS APIのアクセス法
　APIには _IRCS(IRCS Control Structure) という制御構造体が用意されている。その構造体へのポインタをスタックに積み、ＡＰＩエントリを呼び出せば良い。
　ＡＰＩエントリはＣ言語インターフェースになっているので、ダイレクトにＣ言語からの呼び出しが可能である。アセンブラコードでは次の４命令に相当する。なお、呼び出し後のレジスタ、フラグは全て呼び出し前の値が帰ってくる事が保証される。

    push    ds
    push    offset IRCSstruct
    call    dword ptr APIentry
    add     sp, +4

・IRCS 制御構造体
　その名の通り、IRCS APIへの様々な要求はこの構造体を通じてのみ行える。関数ごとに使用する変数はまちまちであるが、変数名の通りの役割を持つ事は間違いない。

_IRCS		struc
  _APIcmd	db	?
		db	?	; alignment adjust
  _APIcount	dw	?
  _APIsrcptr	dd	?
  _APIdstptr	dd	?
  _APIstatus	dw	?
_IRCS		ends

struct	_IRCS {
    byte	_APIcmd;
    byte	_APIdummy;	/* alignment adjust */
    word	_APIcount;
    IRD far*	_APIsrcptr;
    IRD far*	_APIdstptr;
    word	_APIstatus;
};

・IRCS API ファンクション詳細
　これは解説すると膨大な量に及ぶため、付録の IRCSAPI.INCを直接参照されたし。

●IRCS API 使用アプリケーション解説

・IRDE.COM (IRD Encoder)
　このソフトウェアはいわゆるサンプラーである。赤外線リモコンからのデータを受信し、それをファイルとして記録する役割を持つ。やってることはＤＯＳのファイル処理とIRCS APIの呼び出し処理程度であり、大した事はない。それは即ち、IRCSが素晴らしいインターフェースを供給しているということの証明でもある。
　このエンコーダは次のようなＩＲＤファイルを吐き出す。なんてことはない。

  00000000  C5 00 25 00 37 00 26 00-36 00 27 00 63 00 28 00   %.7.&.6.'.c.(.
  00000010  62 00 29 00 34 00 29 00-62 00 29 00 61 00 2B 00   b.).4.).b.).a.+.
  00000020  31 00 2B 00 32 00 2B 00-60 00 2B 00 32 00 2B 00   1.+.2.+.`.+.2.+.
  00000030  32 00 2B 00 60 00 2B 00-32 00 2B 00 60 00 23 06   2.+.`.+.2.+.`.#.
  00000040  BC 00 2C 00 31 00 2C 00-31 00 2B 00 60 00 2C 00   ,.1.,.1.+.`.,.
  00000050  5F 00 2C 00 31 00 2C 00-5F 00 2D 00 5E 00 2E 00   _.,.1.,._.-.^...
  00000060  2E 00 2F 00 2E 00 2E 00-5D 00 2F 00 2E 00 2E 00   ../.....]./.....
  00000070  2F 00 2E 00 5D 00 2E 00-2E 00 2F 00 5D 00 00 00   /...]...../.]...

・IRDD.COM (IRD Decoder)
　IRDEでサンプリングしたデータをIRCSを通じて吐き出すためのもの。やっている事がIRDEの逆になっただけで、プログラムの構成は大して変わらない。元々はIRCS API呼び出しのサンプルプログラムだったのだが、以外に実用性があるらしい:)

・IRRC.COM
　ubora 氏作。メモリに常駐して、ホットキーで起動する普通のリモコンみたいなもの。半年経ってまだ完成してない。なんとかしてくださいね:)

・MKS.EXE
　ZORK氏作。カラオケ曲リストから選択して一発送信出来るデータベース検索ソフトみたいなもの。一応の完成はしているのだが実用に耐えないので改良を求む。

・IRLIB.EXE
　thomas仙人作。ライブラリ・言語翻訳処理サーバ。IRCSでは中核を成す非常に大事な部分。…なのだが、本人多忙により完成していない(泣)

・MDINPUT.COM
　SONYのMiniDiscのタイトル入力を簡便にするために作成した、即興作成アプリケーション。ファイルからの情報取得など、ちょっと面倒な事をしているが、ネタ的には余り面白くないソフトだ。しかし実用性は◎。

・MKSINPUT.COM
　各社通信カラオケの曲番号入力を一元的に管理するために作られた。解析データを自前で組み立てる事によって小型化を実現している。結果的に、歪みの無いデータを送信する事が出来るのも特徴。メーカーモジュールという概念の前身になったソフトウェアでもある。

・TERM.COM
　G-HAL 氏作。IRCSを用いてデータ通信をしようという試み。別紙で解説されていると思う。現在試験段階だが、実用化は近いかもしれない。

・IRD.COM
　後述する Advanced IRD に対応したエンコーダ兼デコーダ。メーカーモジュールを結合する事により、将来的な拡張性が保証される。メーカーモジュールの概念を初めて取り入れたアプリケーション。メーカーモジュールはIRCSの中核を成すべくして作られた。thomas仙人のサーバが完成しないのでそれに対抗して製作を始めたもの。

●拡張データ形式（Ａdvanced ＩＲＤ）

　通常の赤外線リモコンのデータは、パルス数２４個～６４個程度で構成されており、単純にデータ化した場合は９６バイト～２５６バイト程度のＩＲＤになる。

　ここで、赤外線データというのは何等かのデータに変調をかけたものである、という事実に基づき、データを直接バイナリデータとして扱うための手法を用意した。
　「Advanced IRD」がそれである。

　現在のところ IRD.COMというエンコーダ・デコーダが供給されているがこれは、メーカーユニークな信号を解析・保存・復元するための「メーカーモジュール」を結合する事により、各社データの解析等を行っている。
　実際に IRD.COMは、メーカーモジュールの結合・IRCSの管理・共通ユーザーインターフェースを供給するためだけに存在しており、実際のデータ解析・構築処理などは全てメーカーモジュールが行う設計になっている。

　ユーザーに手間をかけさせないのはプログラミングの基本中の基本であり、気の利いたプログラムと呼ばれるものはこの辺がしっかりしているはずだ。

●メーカーモジュール

　モジュールはインストラクションから成る実行ファイルであるが、ＤＯＳからは直接実行することは出来ない。例えるなら DLL(Dynamic Link Library)に似ているかもしれない。アプリケーションはそのモジュールを適宜結合することで、解析・送信処理を行う事が可能になる。

　さて、次を参照していただきたい。

offset 00h:	db	'IRCS IMM'
offset 08h:	offset	build_start
offset 0Ah:	offset	build_repeat
offset 0Ch:	offset	build_end
offset 0Eh:	offset	analyze
	build_start:
		retf
	build_repeat:
		retf
	build_end:
		retf
	analyze:
		retf

　ファイル先頭には 'IRCS IMM' という８バイトの識別子が存在する。この識別子により、このファイルがメーカーモジュールであるという決定的な証しとなる。
　次の４ワードには、データ構築・解析のための各プロシージャに対するオフセットが格納されている。即ち、処理を行いたい場合には任意のプロシージャのオフセットに対して far call するだけで良いのだ。

○メーカーモジュールの仕様

メーカーモジュールはリロケータブルではない。オフセット０から配置すること。
構築処理は解析処理の前にある。そうすることにより、解析処理部分が不要な場合は切り離すことが可能になり、メモリ使用量を減らす事が出来る。

○各プロシージャの役割

proc	build_start		; ボタンを押した時のデータを構築する
; entry  : ds:si=data ptr, cx=byte count, es:di=buf ptr
; return : cx = _IRD count, (ax=sign)=error
; broken : ax, cx

proc	build_repeat		; ボタンを押し続けた時のデータを構築する
; entry  : ds:si=data ptr, cx=byte count, es:di=buf ptr
; return : cx = _IRD count, (ax=sign)=error
; broken : ax, cx

proc	build_end		; ボタンを離した時のデータを構築する
; entry  : ds:si=data ptr, cx=byte count, es:di=buf ptr
; return : cx = _IRD count, (ax=sign)=error
; broken : ax, cx

proc	analyze			; IRD データを解析・構築する。
; entry  : ds:si=data ptr, cx=_IRD count, es:di=buf ptr
; return : cx = byte count, (ax=sign)=error
; broken : all (but segment register)

○NEC.IMM

　このモジュールは、ＮＥＣのチップをトータルにサポートする。
　ＮＥＣのチップはカスタムコードと呼ばれる１６ビットのベンダユニークなデータを含んでいるため、カスタムコードを変えるだけでコンフリクトのないデータを簡単に作成する事が可能である。この手軽さ故に、ＮＥＣのチップを使用した一般家電メーカーはかなりの数に及んでおり、事実、このモジュールを適用可能なメーカーは相当な数にのぼる。

・データ解析
　先頭に($2AC,$156) のリーダがあり、それに続いて１６ビットのカスタムコード、８ビットのデータコード、データコードのビット反転８ビット、ストップビットが並ぶ。_IRDの個数は占めて３４個。
　エラー検出は正論理と負論理のデータを比較する事で行う。ただし、エラー訂正能力は無いので受信に失敗する可能性はある。

・対応メーカー
　東芝, PIONEER, SANYO, 日立, 通信カラオケ各社, その他このモジュールでカバー出来るメーカーは予想以上に多い。PIONEER は独自拡張を施しているがそのデータにも対応している。

○SONY.IMM

　このモジュールはSONYの赤外線リモコン全般をサポートする。

・データ解析
　先頭に($C0,$30) のリーダがあり、それに続いて６ビットのデータコード、６ビットの機器コードが並ぶ。このデータを３つ連続して並べた物。_IRDの個数は占めて３９個。データ自体にエラー検出・訂正能力はないが、繰り返して送信する事でエラー訂正を行っている。
　エラー検出が出来ないので誤信号を受信してしまう可能性はあるが、受光部は単発データでは動作しないので、誤動作する可能性は無いに等しい。

・対応メーカー
　SONY全製品。但し、ごく一部のデータに対してはこのモジュールは適用出来ない。

○VICTOR.IMM

　このモジュールはVICTORの赤外線リモコンをサポートする。

・データ解析
　先頭に($28E,$140) のリーダがあり、それに続いて８ビットの機器コード、８ビットのデータコードが並ぶ。このデータを２つ連続して並べた物。_IRDの個数は占めて３５個。
　データ自体にエラー検出・訂正能力はないが、繰り返して送信する事でエラー訂正を行っている。エラー検出が出来ないので、誤信号を受信する可能性はある。

・対応メーカー
　VICTORの一部の製品に適用。

○PANASONI.IMM

　このモジュールは Panasonic のごく一部のリモコンをサポートする。

・データ解析
　先頭に($115,$105) のリーダがあり、それに続いて５ビットの機器コード、６ビットのデータコード、負論理機器コード、負論理データコード、最終ストップビットが並ぶ。_IRDの個数は占めて２４個。
　データのエラー検出は正論理と負論理のデータを比較する事で行う。ただしエラー訂正能力は無いので、受信に失敗する可能性はある。

・対応メーカー
　Panasonic, 松下の一部の製品に適用。

○SHARP3.IMM, SHARP5.IMM

　このモジュールは SHARPのリモコンをサポートする。

・データ解析(SHARP3)
　リーダ無し。３ビットの機器コード、９ビットのデータコード、トレーラ、３ビットの機器コード、９ビットの負論理データコード、トレーラ、の順に並ぶ。このデータを２回送信。_IRDの個数は占めて５２個。
　データのエラー検出は正論理と負論理のデータを比較する事で行う。エラー訂正は複数回送信する事により実現されている。

・データ解析(SHARP5)
　リーダ無し。５ビットの機器コード、１０ビットのデータコード、トレーラ、５ビットの機器コード、１０ビットの負論理データコード、トレーラ、の順に並ぶ。このデータを２回送信。_IRDの個数は占めて６４個。
　データのエラー検出は正論理と負論理のデータを比較する事で行う。エラー訂正は複数回送信する事により実現されている。

・対応メーカー
　SHARP 全製品に適用。…のはず。

○FUNAI1.IMM

　このモジュールはフナイの一部のリモコンをサポートする。

・データ解析
　先頭に($150,$150) のリーダがあり、それに続いて８ビットのカスタムコードが２つ、８ビットのデータコード、データコードのビット反転８ビット、ストップビットが並ぶ。_IRDの個数は占めて３４個。
　データのエラー検出は正論理と負論理のデータを比較する事で行う。ただしエラー訂正能力は無いので、受信に失敗する可能性はある。リピートコードは ($150,$150),($2B,$80),($2B,$1CE0)。
　リーダとリピートコードを除けば NECのチップアーキテクチャに酷似している事に気がつく。少なからず何等かの影響は受けているだろう。

・対応メーカー
　フナイの一部の製品に適用。

○FUNAI2.IMM

　このモジュールはフナイの一部のリモコンをサポートする。

・データ解析
　先頭に($260,$130) のリーダがあり、それに続いて８ビットの機器コード、トレーラ、８ビットのデータコード、トレーラ、の順に並ぶ。このデータを２回送信。_IRDの個数は占めて３８個。
　データのエラー検出は出来ない。エラー訂正は複数回送信する事により実現されている。エラー検出が出来ないので、誤信号を受信してしまう可能性はある。

・対応メーカー
　フナイの一部の製品に適用。

●今後の発展

　これまでに述べたデータを多角的に管理するための、赤外線リモコン管理言語というものを作成予定。一応、構造化ＢＡＳＩＣをベースに構築するつもりだがどうなることやら。

　この言語が完成すれば、指定時間に指定機器の電源を入れる、などの応用は朝飯前に出来るようになる。送信系・ファイル処理系・時間処理系、この３つがあれば、当分は遊べる言語になるかな。

●文中alias

　thomas : 佐藤益弘様
　ubora : 松本　学様
　G-HAL : 覚張陽則様

1997/03/11

インテリジェント リモート コントロール システム 概要 ＩＲＣＳ (Intelligent Remote Control System)