FMV-KB611のページ

FMV-KB611に於いて106キーボードから拡張された領域は、外から見る限り、二つのブロックで
構成されていると考えられます。一つはFMV-KB211由来のブロック(以下互換ブロック)で、
もう一つはKB611以降で追加されたと思われるブロック(以下611ブロック)です。

それぞれのブロックの概要を下記に説明します。

・互換ブロック

キーボードマイコンによる親指シフト動作を行うブロックです。
この親指シフト動作は、106キーボードとの互換を取るように作られており、
親指シフトの入力は、「106キーボードの対応する刻印を入力する操作」として
出力されます。

(例):「親指左」＋「W / え / か」 → 「5 / %（JIS配列で『え / ぇ』)」を通知

このとき出力されるキーコードは、完全に106キーボードの範囲内となります。
当然ながら親指キーを単独打鍵しても、「親指キー」を示すコードは出てきませんし、
英字や取消などについても、意味合いの近いキーのコードが出力されます。

また、「CapsLock」や「カタカナひらがな」の打鍵など、「ユーザが入力モードを遷移させた」と
思われるようなキー操作が行われた場合、その遷移先モードに合わせて、
自動的に親指処理を有効/無効にするようになっています。

即ち、JISかな入力に対応した環境であれば、このキーボードを接続するだけで
すぐに親指シフト対応環境となるように作られています。

しかしながら、前提とされる遷移操作はOAK/Vの操作が基準になっていて、
現代に於いて一般的な操作では内部のモードを連動させることができませんし、
入力モードがキー操作以外で変わってしまう環境では、計算機側の入力モードと
キーボードの内部モードが食い違って、所謂「モードずれ」が発生する可能性があります。
このため、当初よりこの内部で保持しているモードを計算機側から変更することができるような
コマンドが用意されており、これを利用して常時意図したモードにすることができます。
実際、Windows標準のFMV-KB211用ドライバでも、この制御が行われています。

これらの親指シフト動作は、完全に無効化することが可能です。
無効に設定した場合、キー操作によるモード遷移は起きなくなり、
親指キー等も固有のコードを返すようになります。

また、親指シフトの同時打鍵判定自体はするものの、106配列に変換して出力するのではなく、
「同時打鍵マーカー方式(NICOLA規格書の実装例を参照)」と似た形で行うモードもあります。
この設定にした時も、各キー固有のコードを返し、キー操作でモード遷移しないようになります。

・611ブロック

互換ブロックの動作に変化を加えたり、出力するキーコードの設定など、
拡張部分に関して設定を行うブロックです。
OASYS用に拡張されたキーのコード出力を行うかどうかといった設定はもちろんのこと、
互換ブロックの親指シフト動作について、使い勝手を向上させるような設定なども存在します。

互換ブロックの設定は、(自前親指動作をしない限り)モード遷移の度に制御を行う
必要がありますが、こちらは、起動時に設定を済ませてあとは弄らない、という
スタンスの設定ばかりです。

キーボードの制御には必須の知識なので、一応ここでも説明しておきます。
PC/AT互換機でPS/2キーボード(ATキーボード含む)にデータを送るには、

1. I/Oポート0x64のビット1が0になるまで監視
2. I/Oポート0x60に、送信したいデータを1バイト書き込む
3. I/Oポート0x64のビット0が1になるまで待つか、キーボード割り込みが来るまで待つ。
4. I/Oポート0x60を読んで、0xFA(ACK)が読めれば送信成功。0xFE(RESEND)が読めたら失敗なので、1に戻る。

という手順を、送りたいバイト数分繰りかえします。

参考:
OS Wiki内の(AT)keyboard
B級なi8042の研究(ミドルウェア編)

FMV-KB611で拡張された機能を制御する為には、以下の3バイトを送ります。

    0xF0 0x8C (コマンド)

0xF0は、一般のキーボードでは「スキャンコード変更コマンド」で、次に送る1バイトの
引数によって、キーボードが送信するキーコードの形式を変更するものです。
FMV-KB611では、このコマンドを拡張する形で制御コマンドを実装してあります。

「スキャンコード変更コマンド」の引数は、0〜3(0は現在値を通知)の範囲で取る為、
上記形式のコマンドを一般のキーボードへ送ろうとすると、0x8Cがエラーデータとなり、失敗します。
また、(コマンド)として設定するデータは、PS/2キーボードの仕様に規定されるコマンド番号と重複しない
範囲しか取らないので、この送信も一般のキーボードではエラーデータとなり、失敗します。

つまり、上記コマンドを受け取るかどうかで、FMV-KB611か、それ以外のキーボードかが
判別できることになります。

しかし、近頃の粗悪なキーボードの中には、変なデータを送りつけてもACKを返すひどいキーボードも
あるようです。このような場合は、上記の方法で判別が効かないので注意する必要があります。

尚、FMV-KB611では、複数バイトをパラメタとするバイト列を送信中に、再送要求のやり取りが生ずると、
自動的に1バイト目を受け付ける状態に戻ってしまうので注意が必要です(コマンドごと再送し直す羽目に…)。

まず始めに、制御コマンドの一覧を載せます。

互換ブロックのコマンドは、コマンド0x00を除いて、全て内部モードの遷移を行う
コマンドとなります。互換ブロックコマンド一覧表の見方は以下の通りです。

以下に表を示します。

LEDが拡張されているキーボードでは、上記モードに合わせてLEDも連動すると思われます。
ちなみに、やたらめったら入力モードの指定が細かいのは、キーボード操作によるモード遷移を
確実に処理できるようにする為です。
例えば、ローマ字入力ON・英大入力のときに「カタカナひらがな」を押してかな入力へ遷移させても
親指シフト入力はできないようになっています。

また、後述するように、親指シフト入力中に、本来JIS配列に於いて英字側でしか入力できない
文字を入力しようとしたとき、一時的に英字入力へ切り換えて当該文字のキーコードを送り、
再び元の入力モードへ切り換えるような操作を送ってきますので、内部モード0x09以降を使わない場合は、
このモード設定を正確に行っておく必要があります。

リセット時には、内部モードは0x01(変換後の値は0x43)になっています。


続いて、611ブロックのコマンドです。
互換ブロックと別の内部モードを保持していますが、個別にON/OFFのコマンドを
送って制御するものもあります。
内部モードが互換ブロックとは違う為、表の見方も少し変わります。

以下に表を示します。

このように、内部モードの遷移を伴わないコマンドに関しては、
それぞれ単独で有効/無効に設定できます。

尚、リセット時には、各種設定は無効になっており、内部モードは0xA1に設定されています。

106キーボード等に対して拡張されているキーのキーコードをまとめました。
キーコードは全て16進数表記です。

まず、コマンド0x09(又は0x0A)と0x11を送ったときのキーコードをまとめたものです。

※表中の「同時打鍵」は、互換ブロック内部モード0x0A時に当該親指キーとの同時打鍵を検出したときに
  通知されるコードです。文字キーコードをメイクとブレイクで挟んで通知されます。
  具体的な取り扱い方法については後述します。

次に、コマンド0x1Eを送ったときのキーコードをまとめたものです。

※コマンド0x1E時のコード表のうち、「取消」は「Esc」の、「親指左」は「無変換」の、
  「親指右」は「変換」の、「英字」は「CapsLock」の拡張フラグ付コードになります。
  「実行」も拡張フラグ付ですが、当該コードは一般的なキーボードには存在しません。
  拡張フラグが使えないスキャンコード3では、これらのキーの区別ができませんので注意してください。

なお、うちの機械では、マザーボード上でのスキャンコード2->1変換が有効な場合も、
これらの表の通り正しく変換されました。というか富士通のドライバやサニコンのドライバも、
スキャンコード変換を有効にした状態で使っているようです(当該ドライバを使ってシステムを立ち上げたあと、
切替器で別の計算機に切り換えて、キーコードを吐かせたところ、スキャンコード2になっていたので)。

ここから、具体的に親指シフト入力を実現する為の制御方法などを説明します。

FMV-KB611では、先のコマンド一覧にもあるように、キーボードでJISかな操作に変換して
出力させる方法、キーボード側では同時打鍵の判定のみ行わせ、NICOLA配列への変換は
ソフト側で行う方法、そして、キーボード側にはキースイッチのメイク/ブレイクのみ送らせ、
同時打鍵の判定からかなの出力まで全てソフト側で処理する方法、の3つが考えられます。

既にJISかなによる入力に対応している環境では、キーボードにJISかな操作への変換を行わせて
出力させるのが一番楽なように思えますが、後述のように、内部モードの辻褄合わせに
思いの外苦労しますので、「互換性確保の手段」と割り切るべきだと思います。
ただ、この方法では、出力されるキーコードを完全に通常の106キーボードと等価にできますので、
切替器を挟んでいる等、使えるキーコードに制限がでる場合は非常に強力な「最後の手段」となり得ます。

一番簡単と思われるのは、同時打鍵の判定だけキーボードに行わせる方法です。
実装が簡単なだけでなく配列の変更(例えば、TRON配列や飛鳥配列にしてみたり)なども容易なので、
少ない手間で融通の利く親指シフト環境を簡単に作り上げることができます。

もっとマニアックな行為をしようとすれば、もはや自前判定を行うしかありません。
即ち、キーボードにはただのスイッチに徹してもらい、これを全てソフト側で処理する方法です。
例えば、拙作「親指の友」ドライバのように、同時打鍵判定時間を自由に変えたりするような場合や、
或いは連続シフトを実現したりするには、これで太刀打ちするしかないでしょう。

それでは、これより各手段について具体的に説明します。

(1)JISかな操作へ変換させる場合

基本的な制御のスタイルは、システム側の入力モードに合わせて、
コマンド0x01〜0x08をキーボードへ送ることです。常時送りつづけてはどうしようもないので、
例えば、システム側の入力モードが変わったらキーボードへ通知する、
という形にすれば良いでしょう。

これだけ書くととても簡単なように思えますが、あるキー操作を行うと、勝手に内部モードが
変わってしまいますし、かな入力中に「JIS配列の英字側にしか存在しない文字」を入力した
ときに少し特殊なキー操作が通知される為、これに対する対策を取らねばなりません。

まず、前者について説明します。内部モード遷移が発生してしまうキー操作としては、
以下のようなものがあります。

  ・CapsLock、カタカナひらがなの単独打鍵
  ・英字の単独打鍵(CaosLockの打鍵として通知される)
  ・無変換、変換の単独打鍵(直前にカタカナひらがなの打鍵が通知される)
  など。

一般にWindows上では、これらのキー操作は(意図する動作かは別として)何かしら入力モードの遷移と
絡むように働いていますので、すぐさま入力モードの変更が発生する為、上記スタイル通りに
対処すれば、何事もなく対策できます。
しかし、例えば「CapsLockとCtrlの入れ換え(システム側でのコードの読み替え)をしている」等、
当該キーを操作してもシステム側で入力モードの変更が発生しない状態にされている場合、
このままでは確実にモードずれを起こしてしまいます。

KB211との互換性を捨てても良いのであれば、コマンド0x16を送ってモード遷移が発生しないように
してしまうのが、一番手っとり早い解決方法です。
しかし、KB211と処理を共通化するのであれば、この方法は使えません。
ここで上記の操作を見ると、いずれも必ずCpasLockかカタカナひらがなを含む操作なので、
キーボード割り込みのハンドラ等で、これらのキーコードを発見し次第、現在の入力モードを
キーボードへ通知するのが無難な対策でしょう(但し、後述の問題に引っかかる)。

続いて、かな入力中に「JIS配列の英字側にしか存在しない文字」を入力したときの問題についてです。
例えば、かな入力時に「フルキーの1」を入力すると、以下のような操作が通知されます。
  ・CapsLockのメイクとブレイク
  ・「1」のメイク
    (ここまで、キーメイクと連動)
  ・「1」のブレイク
  ・カタカナひらがなのメイクとブレイク
    (ここまで、キーブレイクと連動)

即ち、システム側を一瞬だけ英字入力モードへ切り換えて、キーを離したらかなモードへ戻る意図の
キー操作を、勝手に送ってきます。しかもこの処理は、JISかな配列に無い英数字・記号を入力する
必須の処理である為、コマンド0x16を送っても無効になりません。

これは一見すると、元に戻るコードまで送ってきているので特に問題無いように見えます。
しかし、先程の対策をとっているとしたらどうでしょう。最初の一発目を見つけた時点で
CapsLockのコードがあるので、コマンドを送って入力モードの同期をとるはずです。
「1」のメイクまでは連続でコードを送りつけてくるので、こちらからコマンドを送れるように
なるのはこの後ですが、ここで、例えば(いまCapsLockが押されたので)英小に切り換えるコマンド
を送ったとすると、後半の「カタカナひらがな」に関する操作が送られずに処理が終わってしまいます。
しかも、以降の内部モード遷移が若干挙動不審になるようです(かな入力に遷移させても、
カナ入力時の操作が出力される、等)。

これは、まさしくWindows NT系標準のKB211用ドライバにおける「フルキー部の数字を入力すると
英字入力になる」問題の原因であります。

さらに、上記のストロークでは、「CapsLock」が「英字入力への遷移」、
「カタカナひらがな」が「かな入力への遷移」と決めうちして使用されています。
つまり、これらのキーが上記以外の目的で使われている場合、この入力は破綻することになります。

これらの問題を解決するためには、機械的に出力されたコードとユーザの手操作を判別して、
それぞれ別系統で処理することが必要不可欠です。
しかし、上記ストローク中のCapsLock/カタカナひらがなを、ユーザが本当にキーを押して
出力されたコードと区別する方法は、少なくともキーコードを見ただけでは分かりません。

ここで、キーコードが送られてくる時間に注目します。
上記ストローク中の、CapsLockメイク〜「1」メイクまでは一気に送られてきます。
かなり遅く見積もっても(データが化けて再送要求が頻発したときなどでも)、数十ms以内には
全て受信できるはずです。
一方で、ユーザが手でこのストロークを入力したとしても、通常ここまでの速さで
入力することは無いと思われます(CapsLockの単独打鍵だけならあり得ると思いますが…)。

これを踏まえると、CapsLockのメイク、ブレイク、任意のキーのメイク(フルキー部の
文字キー以外にも、左Shiftが出現する場合あり)が、この順かつ連続に、
一定期間内に通知されたときに、これを機械的な出力であると見なし、
それ以外の場合はユーザ操作の入力とみなせば、おおむね上手く行くと考えられます。
「親指の友」ドライバでも、V1.0L20よりこのロジックで対策するようにしています。
同じような方法かはわかりませんが、サニコンのドライバでも何かしらの対策を取っているようです。

このように、ちゃんとやろうとすると非常に面倒な実装が必要になってしまいます。

(2)同時打鍵判定のみさせる場合

こちらの場合も、システムの入力モードに合わせて、モード遷移コマンドを
送る必要があります。ただし、先の場合と違って、かな・カナ入力時にコマンド0x0A、
それ以外の場合はコマンド0x09を送信します。

モード0x09のとき、フルキー部分のキーは全て固有のキーコードを返すようになります。
このときのコードは先の表に示した通りです。
親指キーも固有のキーコードを出力するようになりますので、英小・英大入力モード等では、
スペース文字の入力などに割り当てると良いでしょう。

モード0x0Aのときは、モード0x09の動作に加えて、親指シフトの同時打鍵監視・通知動作が
追加されます。このモードで同時打鍵の操作を行った場合、以下のような順番で
キーコードが通知されます。
  
  ・親指キー メイク
  ・同時打鍵マーク メイク
  ・文字キー メイク
  ・同時打鍵マーク ブレイク
  ・文字キー ブレイク
  ・親指キー ブレイク

これを見ると、「同時打鍵マーク」が、あたかもモディファイヤ(ShiftやCtrlなど)のように
文字キーを挟む形で出力されることがわかります。即ち、このコードを仮想のモディファイヤキー
として使い、「同時打鍵マーク+文字キー」に対応する文字を割り当てれば、親指シフト入力を簡単に実装できます。
あとは必要に応じて、計算機側で濁音や半濁音を追加出力すればOKです。

尚、同時打鍵マークは同時打鍵した親指キーによってコードが
変わります(先のコード表を参照)ので注意が必要です。つまり、ストレートシフト(同じ側の手との同時打鍵)
なのかクロスシフト(反対側の手との同時打鍵)なのかは、計算機側で判別してやる
必要があります。また、親指キーのコード自体も一緒に通知されるので、
同時打鍵時はこれを無視する必要があります。こちらは、親指シフト入力時の
親指キー単独打鍵を無視するように実装することが多いので、それに倣えば特に問題ないと
思われます。

ちなみにモード0x0Aの状態では、親指キーとの同時打鍵監視の為、フルキー部の
文字キー単独打鍵通知がもたつくようになります(JIS配列変換を有効にした状態で
親指入力しているときと同じ位)。
なので、親指シフト入力をしない入力モードのときは、モード0x09に切り換えておかないと
使い勝手が悪くなってしまいます。

同時打鍵判定のみさせる場合は、これだけでOKです。JIS配列へ変換させる場合と
比べても遥かに簡単な実装で済むことがわかると思います。

(3)全て自前で行う場合

この場合は、キーボードの制御は一番簡単です。システムの起動時に、
一度だけコマンド0x09を送るだけです。これで、フルキー部の全キーを把握できます。

コマンド0x09の代わりに、コマンド0x15を送ることでも実現できます。
コマンド0x09だとKB211と互換がとれますが、KB211ではこのモードにおいても
「親指右+後退/取消」の処理の為、親指右の単独打鍵確定に時間が掛かってしまうので、
自前親指処理が困難です。なので、この場合はKB211との互換を捨てても問題は無いように思います。
また、こちらのコマンドの場合は、データが化けたり、計算機側の問題で誤って互換ブロックの
コマンドを送ってしまったとしても、互換ブロックの内部モードは固定されたままですから、
幾分か安全であろうと考えられます。
よって、むしろコマンド0x15の方が良いかもしれません。

あとは、送られてくるキーコードのタイミングに合わせて、同時打鍵判定などを行うだけです。
結局やることはエミュレータを実装するのと全く同じです。
このあたりの実装については、親指シフトエミュレータ「親指ひゅんQ」に付属する
「親指ひゅんQの同時打鍵ステートマシン」解説文書、日本語入力コンソーシアムの
「NICOLA配列規格書」内にある実装例、JIS規格案などが参考になります。

他にも、対象となるプラットフォームに親指エミュレータが存在するのであれば、
そちらで都合が良いようにキーコードを置き換えて出力する、という処理でも良いかもしれません。
この場合、出力されるコードが106キーボードとなじみ易い、コマンド0x1Eを使うのも良いでしょう。

2006年7月12日現在、FMV-KB611でここに掲載したような制御を行える
OSは、WindowsとMS-DOS以外に存在しないようです。マルチタスク/マルチウィンドウな環境では、
互換ブロックの制御すら行わない状況だと特に使いにくいことでしょう。
この情報を参考に、是非完全対応してみてください。
また、親指キーのコードや同時打鍵監視モードを使って、TRON配列や飛鳥配列の
エミュレーションをするのもいいかもしれません。
FMV-KB611は親指シフト環境を簡単に実現できる、優秀かつ弄り甲斐のあるキーボードですので、
よりいっそう普及してくれればと思います。

記載内容に対するご意見等ありましたら、ゲストブックかメールにてお願いします。
(アドレス等は帰還先のメインページに記載)。

ノートマシンに搭載されている親指シフトキーボードって、親指キーと変換/無変換が
統合されたりしてしまってますが、全く同じ方法で制御できるんでしょうかね?

泊何水さんの情報によると、親指ノートのキーボードは内部的に
通常のJISキーボードのようです。うーん残念…。

何度かさらりと触れていますが、上記互換ブロックの動作は、FMV-KB211と
ほぼ同じ実装になっています。即ち、KB211でも、JISかな配列の出力を止めたり、
親指キーに固有のコードを吐かせたり、同時打鍵の監視だけさせるモードにしたりできるということです。

このとき、親指キー等で出力されるコードは、KB611のコード(コマンド0x09時)と全く同じになります。
また、Tabキーのコードも英字キーのコードに変わります(つまりTabキーが消滅する)。

但し、親指右と後退/取消を同時打鍵することで、BackSpaceやEscのコードを通知する
機能を無効にすることが出来ない為、親指右のコードが出力されるまでにもたつきが生じます。
結果として、KB611のように自前で同時打鍵の判定を行うと使い勝手が非常に悪くなります。
また、「後退」/「取消」は基本的に「* :」/「} ]」キーであり、モード0x09/0x0A時には必ず
これらのキーに相当するコードが出力されます。後退や取消として使いたい場合は、
システム側でコードを読み替える必要があります。

これ以外の動作に関してはほとんど同じなので、例えば同時打鍵判定をキーボードにやらせて、
JISかな変換の弊害から解放させる、ということも可能です。こちらの制御の場合ですと、
今までの場合だとほとんど不可能に近かった、CapsLockとCtrlの入れ換え等も問題なく行えるはずです。
この方法で実装するドライバが現れれば、KB211の株も少しは上がるのでは無いのでしょうか。

以前公開していた版では、サニコンのFMV-KB211用ドライバでかな入力をしているとき、
英数字を入力するとモードずれが起きやすい云々の記述がありましたが、
これは誤りで、正しくは、「Windows標準のドライバではかなモード時の英数字入力に
対策をしていない為、これを行うと以降の入力がおかしくなるが、サニコンドライバでは
これに対して対策をとっているため、問題がおこりにくい」でした。

説明書の注意事項に書いてある項目を、何も考えずにそのまま読み取ってしまった
ことが原因でした(対策をとっているドライバだが、まれに対策しきれないことがある、
という主旨だったのに、対策をとっているドライバであるという部分を理解せずに読んでしまった)。

関係する方々にお詫び申し上げます。