雑記帳

電子計算機の"明後日"から、他愛もない話まで。

次世代MSX(MSX3?)に関する話

西和彦氏の次世代MSX(MSX3?)に関する話をチラホラ目にするようになりました。
どうやら、先月末より西氏がTwitter上で情報を小出しにリークしているようです。

https://togetter.com/li/1768118

これを見ると興味の方向性が人それぞれで面白いですね。懐古趣味として「かつて見たMSXの復刻・発展進化系」を期待する方もいれば、「今の時代にMSXのようなコンセプトのマシンを立ち上げるなら一体どんなものになるのか」という方向で期待してる方もいます。

私は後者の視点でこれを眺めていました。それもそのはず、リークされてる内容やそのリプライに、ところどころウチの電脳文庫プロジェクト(これを実現するシステムとしてのScrapstick)と近しいところがあって、内心落ち着かないからです。

前述の私の視点からもお分かりと思いますが、いわゆる"MSX"部分のような上っ面は全く関係ありません。それを実現する為の、想像されうる実装形態のところや、もっと未来志向の部分の話です。


ここで私がやっていることを簡単にまとめおきます。

「電脳文庫プロジェクト」といいまして、古今東西・時代を超越したあらゆるハードモジュール・ソフトモジュールを集結させて自由に組み上げられる混沌とした環境…という目標像を描いています。各モジュールは実在するハードかもしれませんし、或いはそのエミュレータ、或いは架空のデバイスを模したモジュール、或いはライブラリ、或いはもっと抽象的なもの、或いは単なるアプリかもしれません。プロジェクト名は、あまたのモジュールを本に見立てて、モジュールが集結している様を図書館になぞらえたものです。

計算機界のスマブラといいましょうか、バーリ・トゥードといいましょうか。

これをもう少し具体的に書いたのがこれの「例えばx64 PC上で、SPARC向けに書かれたアプリケーションが、68000向けに書かれたTCP/IPスタックとARM-v6向けに書かれたモデムドライバと実機モデムを経由して通信を行い、Z80向けに書かれたV9958を使うコンソールに結果を出力」…という下りです。また、同記事にもありますように、実機ハードウェアもソフトモジュールと等価に扱われますので、エミュレータ・実機を利用者都合で自由に切り換えたりできる構造になっています。*1

これを実現する為のシステム部分が「Scrapstick」です。所謂バスにあたる部分ですね。ハード的なアプローチ(バスプロトコル)とソフト的なアプローチの両方での実装を想定しています。

…ここまでは、説明の為に割と懐古なモチーフを出してきましたが、自分としては、過去も未来も何もかも対等に扱う、というコンセプトこそが重要であって、懐古の方にリソースを割きたい訳ではありません。むしろ未来指向のつもりでいます。その点はあしからず。


一方、氏がどういったアイディアの元に作ろうとしているのか探ってみますと、断片的ですが、

次世代のMSXを開発している。CPUはARMとR800FPGAの上で何にでもプログラムできるハードウェアでRaspberry Piと同じ大きさの基盤にした。

http://library.nishi.org/essay/?y=2018&m=08

私が今作っているのは巨大なFPGAを搭載し、高速のBUS構造を持ったアーキテクチャをソフトウェアでプログラミングできるワンボードコンピューターを設計している。

http://library.nishi.org/essay/?y=2019&m=06

といったものが見つかります。

この辺りの、ソフト的にごにょごにょできるバス構造…、さらに、複数アーキテクチャのプロセッサが共存できる構想や、I/Oサイドのマルチアーキテクチャ構想まで踏まえますと、そこからイメージされるシステムの姿は前述した私の目標像と近しいものに見えます(私のものよりも、もう少し地に足ついている印象ですが)。

さらに、こちらは他の方の質問ツイートがきっかけですが、Arm → MSXアドレス空間へのアクセスをできるようにするといったアイディアまで出ています。この手のARMサイドからの制御の話まででてくると、そこから先に一歩踏み出すだけで(ようは、相互にエミュレータが絡むようになるだけで)、Scrapstickの(将来の)実装面などとも近いところにきてしまいます。


正直「有名人と(部分的にでも)ネタ被りしてしまったぞ!!」という気持ちです。光栄に思うべきところかもしれません。

…しかし、そのせいで気が気ではありません。というのも、先程、雄弁と私のプロジェクトの概要を書きましたけど、実はまだScrapstickの最初のリリースすら漕ぎ着けていない状況で、あちらに先を越されてしまうのではないかと戦々恐々*2しているからです。


……あぁ、まって、まだページ閉じないで! 与太話じゃないんですよ! ちゃんと作ってるんですよ!


今作っているのはWindows上で動くシェル兼用のScrapstickバス実装です。なので、初回リリースの段階では直接ハードウェアを叩くことができません。Scrapstickバスの機能を適当な1チップマイコン辺りに移植した段階からそういった話ができるようになると思います。最終的にOSとして機能する代物の実装を目指してはいますが、Windows版以降をどういう順序で作るかはまだ具体的に決めてません。何ならハイパーバイザ版作るかも(実験環境ができたので)。それくらい流動的です。

そして、そのWindows版実装がまだまだリリースできる代物ではない…という状況です。

電脳文庫プロジェクトのページの初出は2015/02/08、その直前に某イベントの敗者復活戦に簡単な可動物を持ち込んでいて、当然開発はそれよりも前から進めてますので…自分で言うのもアレですが、相当難産です…。

尚、その時以来「○○頃に出せそう」→「延期」を繰り返してたんですけど、まぁ端から見たら「出せる出せる詐欺」状態ですよね…。なので、現在では(2019年末以来)「いつ頃出せそう」とは言わないようにしてます…。*3

では、何がそんなに難航してるのか…なんですが、もうとにかく、やりたいことに対して実現できない/面倒くさいパターンが発覚して再設計…を繰り返してるんですよね…。直近ですと、上記記事で述べた「複数のScrapstickインスタンス間で連携する機能」の実装にあたって、当時のバスシステムだと色々問題があることがわかって、かなり大規模な再設計に入りました。結局これ、丸1年近く「天使待ち」状態になった挙げ句、なんとか大半の課題を解決できる妙案を捻り出せたのですが、1コだけくすぶり続けてる問題が残っています。なのでまだ天使待ちですね…。枝葉末節の実装はサラサラ進むんだけどなぁ…。

今まで趣味でも仕事でも、ある程度用途や目的が具体的に決まっているものばっかり作ってきたので、こういう真に汎用的な道具を作るというのはとても難しく感じています。何かもう禅問答とか哲学の世界ですよ、これ。もしかしたら単に端から見てどうでも良いところで高望みしてるだけなのかもしれないですけど、なのに端から見て重要なところが片手落ちだったりするんです(動かしてみて / 使ってみて気付く。毎度このパターンです…)。変な拘りが強すぎるのかなぁ…。

尚、2018年の総括で書いた考え方からは変化してません。あくまでもScrapstickバスの構成がゴリゴリ変わっただけです。仮に今後また大幅な変更が入ったとしても、この点がブレることはありません(でないと作る意味が無い)。


最後に、もう少し両者を掘り下げて見てみます。

氏の次世代MSXはハードウェア実装が主体であることが伺えます。前述のように、高速性をウリにしてる節があること、外バスに追加CPUをぶら下げられる設計にすることを示唆していること、エミュは嫌だと仰っていることなどが論拠です。

一方私のScrapsticは、バスを模すことができるソフト実装が主体です。エミュレータを多段に繋ぐ前提で、遅く、タイミングに依存するアプリには不向きです。でも目茶苦茶自由度があります。さらにいえば、私の方は物理的なハードウェアバスを自作するプランを持っていません*4

恐らく、「遥か遠くに見いだしている姿」こそ似通っているものの、そこに至るまでに想定している経路は違う道なのではないでしょうか。なんとなくそんな気がしてきました。

ただ、今後Scrapstickが育ってFPGAとの連携を考えようとしたとき、きっと似たようなFPGA SoCを使ってごにょごにょやることになると思うので(というかそれを見越してZynqボード買ってたので)、そうすると実装形態面でモロ被りしそうだなぁ…という印象です。また、他の方の意見等も取り入れて方針が変わって来たりしても、同様のことが起こりそうです。まぁそうなりそうになったらなったで、こっちが次世代MSX向けにブリッジを作るとか、そういう共存関係で良いのかもしれません。


最初に挙げたTwitterまとめを見ますと、今なお根強いファンのアツさを感じることができて、改めて凄いなと感じました。私が物心ついた頃にはもうMSXの黄金時代が終わってしまった後だったので、当時の趨勢を直接見聞きすることはできなかったのですが*5、今回その熱気の一端を覗き見ることができた気がします。

お互い良い形で世に出すことができると良いですね。関係者各位、是非頑張っていただきたいです。私の方もそうできるべく頑張りたいと思います。

*1:一例を挙げると、uPD765Aのエミュレータ(ディスクイメージを読み書きする)と互換ハードウェア(実機FDDが繋がる)の切替とか。これを、FDCへアクセスするアプリの側で予め準備工事をしておかなくても共存・切替できる仕組みです。というか普通に組むと自然とそうできる仕組みといいますか。

*2:それに、前掲の例のように、猛者達が氏に寄せるネタの中に鋭いものがあったりして、加速度的にアイディアが「育って」しまうのでは…という底の見えなさも怖いポイントです。

*3:ちなみに西氏の次世代MSXの方も、何度も「○○頃に出せそう」状態だったようです…。そんなとこまでシンクロしちゃってましたよ…>私。

*4:ハード側との連携は、既存のバスをScrapstickバスとして取り込んで見せたり、既存の通信経路の上にScrapstickバスの通信を流したりする方式を考えています。例えば、あるチップ ⇔ JTAG ICE ⇔ Scrapstickと繋いで、対象のアドレス空間レジスタをScrapstickバス上にマップしてアクセスできたり。各モジュール間の伝送経路がUSB-COMだったりTCP/IPだったり。ゆえにハード側では、バスではなくバスプロトコルの開発を目標としています。

*5:私は辛うじてPC-98x1の最後っ屁を見届けた世代です。また、やや遅れてFM TOWNS系やFMR系の残滓にも触れることもできました。

FMV-KB613 + 親指の友Mk-2 / Oyayusbyの動作確認

やっとこさFMV-KB613を入手しましたので、表題の通り動作確認を行ってみました。 結果、拍子抜けするほど普通に、FMV-KB611相当品として使用可能であることが確認できました:

以上のように、公称通り「FMV-KB611相当」として機能しているようです。

尚、以前KB611を解析したときに実施したような、コマンドを総当たりするような大規模な調査はまだ行っていません。ひょっとしたらKB613固有の機能が追加されていたりするのかもしれませんが、少なくともKB611のつもりで制御する分には、全く等価に扱うことが期待できると思います。

また、動作検証に使用したKB613は前回の記事を書いた後に発注したものです(Rev.03A、2020年製…令和生まれのブロックキーボード!!)。上述の挙動については、恐らく古いKB613でも同様と考えられます(わざわざ変える意味がないので)。もし、この辺の情報が不確定なせいでKB613の購入を躊躇っていた方がいらっしいましたら、これを機に如何ですか。今月いっぱいであれば、まだJapanistも新規購入できまっせ(何度目だこれ)。

富士通が親指シフト関連製品を終息させるそうです

f:id:kiyoto-y:20200522014120j:plain
FACOM6130KF1

表題の通り、富士通から親指シフト関連製品を終息させる予定であることが発表されました。また、このお知らせには含まれていませんが、富士通コンポーネントThumb Touchも終息予定に変更されています。

遅かれ早かれ終息するんだろうなぁ…というのは目に見えていたので*1、このタイミングだったこと以外に驚きはないです。むしろ、よくぞここまで頑張って頂いたと思います。関係者各位に「お疲れさまでした」と伝えたいです。

 

40年ともなれば、非常に多くの方々が関わったことと思います。好調な時代に携わり、発展させてくれた方々の成果はいわずもがなですが、実はここ15年以上の「延命」に携わった方々の仕事も、今後の親指シフト界隈にとって非常に重要で、埋もれさせてはいけない功績なのではないかと考えています。ちょっとこの辺の話を掘り下げてみます。

まずソフト関連で具体的に挙げると、謹製キーボードドライバやJapanist 2003のx64対応やWin8~10対応、そしてJapanist 10*2の開発といったところでしょうか。なぜこれをわざわざ強調するかというと、この一連の対応によって、Windowsのドライバ・入力周りの例外的な目まぐるしい変化を乗り越えることができたためです。当時、これらの変更によって、野良のキーボード関連ツールの多くが振り落とされ、マイナーな配列やIMEを使っていた方にとっては大きな問題になりました。富士通だって、ハナから親指シフトを継続するつもりが無いならこのタイミングで終息させるという判断だってできたはずですが、結果的にそうはしませんでした。おかげで、現在ではサードパーティツールに頼らず純正品を買い揃えるだけでも、随分とお手軽に親指シフト環境を構築し、使うことが可能です。

キーボードについても、最後までフルラインナップが維持されていたことは特筆すべきことだと思います。

  • FMV-KB613 -- 現時点でリテール唯一のブロックキーボード。メカキー。
  • FMV-KB232 -- Libertouch譲りの機構を持つ。ゴム感を感じさせないメンブレンキー。
  • FKB7628 Thumb Touch -- 薄型コンパクトタイプ。ギアリンク+メンブレン
  • アクセスのカスタムノート -- ノートPCに親指シフトキーボードを搭載できる。

少なくとも、使えるキーボードが無いから使用を諦める…なんてことにはならない位で、マイナー配列としては奇跡的に恵まれた状態と言えるのではないでしょうか。特に、公式にも快速親指シフト機能があったりして、必ずしも親指シフター全員が純正の専用キーボードを買うとは限らない状況の中で、これだけのラインナップを維持し続けてくれた訳ですから、まさに関係各者の尽力の賜物でしょう*3

 

さて、純正品を使う利用者目線で見ると、確かに現状は何の問題もないかもしれませんが、終息に伴って開発が止まるせいで、今後またすぐ環境が変わって使えなくなったりするんじゃないの? と心配する人も居るかもしれません。個人的な見解をいうと、それについては当面大丈夫なのではないかと考えています。

 

まずソフト観点(つまりWindows環境)での話です。先程の話と少し矛盾しますが、Windowsの歴史を追っていくと、伝統的に互換性を相当重要視している形跡が節々に見受けられます。一例を挙げると、Win32sに同封されてたフリーセル(1995年!)が、現行のWin10でも問題なく遊べてしまうのです*4。また、x86版とx64版でドライバ署名に対する態度が異なる点などは、この互換性意識に対する強い意思表明にさえ感じます(先発たるx86版では強制されない)。

では、なんでキーボードツール界隈で大問題になるように大幅な非互換をやらかしてしまったのかというと、当時セキュリティ関連の問題が数多く出ていて、伝統的な態度よりもそちらへの対応を優先したためではないかと考えられます。すなわち、保護が難しいカーネルモードを気軽に使わせないためにドライバの署名強制化を行い、Win32アプリの「粗野な」動きをUACなどでじわじわ締めつけつつ、恒久対策として、セキュリティリスクを低減させたUWPへの移行を進める…という流れです。UWPアプリでは旧来のIMEが使えなくされているというのも、恐らく同様の側面があるのではないでしょうか*5

翻って現在はどうかというと、MicrosoftWindowsに対する変更方針はかつてのようなドラスティックなものではなく、小規模な改良をちまちま入れていく方向に落ち着いてきました。アプリケーション環境も同様に、UWPへの移行圧が弱くなり(というか失敗し)、旧来のWin32環境を生かし活用する方向に変わりつつあるようです。恐らくセキュリティの問題も、前述の大改造によって以前ほど問題が出にくくなっていると見え、残りはDefender等による力業で個別に確保するつもりなのかもしれません。となると、今後も互換性を大きく切り捨てるような変更が行われる可能性は低いと考えられ、ゆえに、前述の山を乗り切った親指シフト環境が再び脅かされることは、しばらく無いのではないかと考えています。というわけで、これまで純正の組み合わせを使ってこなかった方々、これを機にJapanist 10は如何ですか。今ならJapanist 2003もオマケで付いてきまっせ。

欲を言えば、Japanist 10のアップデートが全くないことが心残りです。再変換機能とかは正直もう無理なんでしょう。しかし、2003では実施した令和対応とか、微妙にOAKっぽくない動き(デフォルトがIME OFF状態で、そこから無変換でかな遷移できない等)を改善する程度のことはして欲しかったです。実のところ、既に2003/10併用→10へ完全移行して半年以上になるのですが、やっぱりこの操作系の差異だけは慣れません(他は快調なのですがね)。まぁ趣味人の嗜みとしては、ごにょごにょ解析してこっそりパッチ配布とかやるべきところかもしれません(こら)。でももうそんな牧歌的な時代じゃないよなぁ…(それに、電子署名潰したらUWP環境周りで問題が出そうな気がします。…あんまし関係ない?)。

一方、Windows周りで一つだけ先行きに不安があるのは、ARM版Windowsの存在です。これがどこまで広がるのかが気になります。一応、ユーザモードアプリにはx86エミュレーション機能が入っているとのことなので、多分IME親指シフトエミュレータは影響無いはずです(実機を持ってないので未確認)。問題はドライバで、カーネルモード側のモジュールにはエミュレーションが利きません。今のところWindows搭載のARM機はごくわずかなノートタイプしか出ていないので、PS/2接続専用であるFMV-KB613との組み合わせはあり得ないですが、これがデスクトップ機に進出してくると後々問題になるかもしれません。まぁでも最悪はOyayusbyみたいな方法もありますし、親指の友 Mk-2をARM向けに移植するのはたやすいので、あまり心配しすぎるような話ではないと思います。

 

続いて、ハードの接続形態に関する話です。まずはPS/2キーボードから(現行品ですとFMV-KB613が該当します)。

かつてPS/2→USB移行が盛んに語られていた頃もありましたが、蓋を開けてみると、USB HIDクラスのあまりにも野心的(?)すぎる設計のおかげか*6、今に至るまでPS/2キーボードの完全な代替は行われていません。デスクトップ機であれば現在でもPC側にコネクタが用意されている場合がほとんどではないでしょうか。PS/2自体は簡単なプロトコルですし、デスクトップPCでよく使われている「スーパI/Oチップ」にはPS/2ポート機能が標準で組み込まれているので、PCメーカから見ても、機能提供し続けることについてはそれほど負担になるような代物ではないのかもしれません。よって、こちらも当面安泰のように思えます。それに、いざとなったらOyayusby(注: 611と同じ制御が使えるか要確認)(2020/09/22追記: 動作確認済。使えます)を使ったり、市販のPS/2→USB変換アダプタを使ってキーボードマイコンにJISかな出力させる(注: 613にこの機能が残っているか要確認)(2020/09/22追記: 確認済。残ってます)…という逃げ道もありますし。

残るはUSB接続タイプの親指シフトキーボードですが、こちらは最初から何の心配も要らないと思います。というのも、あれはキー配置が特殊なだけで、出力的には一般的なUSB HIDキーボードと何ら変わりは無いので。それに、今後USB HIDの後継規格が出ることも考えにくいです。

一方、現行製品を見るといずれも有線接続のものばかりで、無線(Bluetooth)に対応した製品は存在しません。では、有線が全滅したらどうなるのか…ですが、USBキーボードであれば、市販のプロトコル変換アダプタみたいなものを使うことで簡単に移行できるではないかと考えています。Bluetooth HID仕様書をナナメ読みした限りですと、Usage code(キーコード)の定義はUSB HIDと同じもの(というかUSBのものを参照している)のようですので、例え特殊なUsage Codeを吐くキーボードだったとしても変換できないということはないはずです。PS/2接続の場合も一旦USB化してしまえば同様だと思います。

 

最後に、キーボードの寿命に関する話です。今後新たな新品が手に入らなくなるせいで、どこかのタイミングで使用を諦めなければいけなくなるのでは…と心配する向きもあると思います。しかしそれについても、なんとか終息までの間に新品の予備機をいくつか調達しておけば一生分困らないのではないかという気がしています。というのも、富士通のキーボードって全般的に恐ろしくタフなんですよね…。

特にブロックキーボードでは顕著で、今この文章を書くのに使っているのは1989年製のFMR60KB201ですし、15年モノのFMV-KB611も未だ壊れる気配がありません。これらに使われているメカスイッチは公称5000万回耐久を誇る代物なので、スイッチがダメになる心配はほぼ無いと言えます(利かなくなったり暴れたりしても、皿ばねの固着やサビなどが原因なら簡単に直せますし)。しかし、使えなくなることは考えにくいですが、コンディションは使った分だけ確実に悪化していきます。例えば、スライダ / スライダハウジングの磨耗による引っ掛かりやぐらつきの悪化、キートップの黄変*7、テカリなどです。ただ、スライダハウジング等の機構部品は簡単に交換できる構造になっています(Libertouchも同様です)し、黄変についてもRetr0brightで復活可能です。つまり、あまり使わないキーとの間で部品交換し続けてけたり、黄ばみがひどくなったところで漂白…を繰り返すことで、単体のコンディションを随分マシに保ち続けることができるはずです。そしてそれでもいよいよダメになってきたところで次の予備機へ…みたいなサイクルを続けていけば、向こう70年位は使い続けられそうな気がするのですが…どうでしょう*8

キーボード趣味人視点で一点気になるのは、ブロックキーボード(FKB2500)の製造がFMV-KB613の終息後も続くかどうかなんですが…続いて欲しいなぁ…。70~80年代設計の富士通のキーボードって、結構外人さんの食いつきが良いみたいなんで、レトロで無骨なデザインのまま、海外向けを考慮して上手いことやったらワンチャンあるんでは? と無責任な与太プランを思っていたりするんですが…リテール出てくんないかなぁ…。

 

ひとまず2021年5月をもって、富士通としての親指シフトは一区切りを迎える予定のようです。しかしながら、NiftyServeのサービス終了時なんかと違って突然消えたりはしない訳ですから、私を含め親指シフター各位はその日を過ぎても、きっと相も変わらず粛々と、手元のキーボード・ソフトを使い続けるだけのことでしょう。そのうちまた何か問題が出てくるかもしれませんが、そん時ゃいつも通り、何か逃げ道を考えりゃ良いんです。作り手の人間が一人でも残っていれば、大体どうにかなります(します)。現に親指シフト界隈は、私を含めて野良の開発者が結構居ます。Windows環境に複数の実装があるのもそうですし、Windows環境以外で使えているのもそういった方々の功績です。キーボードコンバータなどを作ったり売ったりしてる方や、富士通以外で親指シフトキーボードを企画・設計開発・製造・販売された方などもそうですね。その人たちが飽きたり嫌気が差したりしない限りは、今後も何気なく使い続けられるものだと確信しています。

きっと将来、キーボードを使い続ける環境よりも、キーボードを使わずに済む環境の方が利便で勝ったとき、やっと親指シフトにも引導が渡るのだと思います。その時までは付き合ってやりましょ。とりあえず、総員、予備機の調達に急げ(…と思ったら、アクセス / 富士通WEB MARTは軒並み売り切れてやがる…皆さん早ええな…)。

 

一応、OASYSにも触れておきましょう(学生時代は個人的にお世話になったので)。あれこそただのWin32アプリなんで、後年まで一番問題出にくいんじゃないかと思います。ただ、それ以前に最大の問題は、ワープロ専用機やFM-OASYSを使ってた場合などのOASYS文書FDですよね…。Windows版のOASYSには文書の吸い出し機能があるので、内蔵FDDを持つ中古PCでも調達してWindows 2000/XPとOASYSをインストールしてやれば、サルベージマシンを仕立てることができます。なので、手元にOASYS文書ディスクが残っている方などは今のうちにOASYS V10.0を入手しておくのもアリだと思います。尚、3.5インチ2HDの吸い出しは使える機材が相当制限されるので、その点はご注意を。3.5インチ2DD経由ならどの機体でもできます。頑張れば5.25インチ2HD/2DDもいけるはず。

*1:具体的には、Japanist 10のリリース時に予告されていたアップデートが、いつまでも行われなかったこと。

*2:ボリューム的には一番こいつがヤバいはずです。ほんと、よく出したなぁ…。

*3:尤も、私自身最後に買った新品は15年程前のFMV-KB611で、以降はFMR/FM TOWNS/OASYS専用機のキーボードをV機に繋ぐ遊びへ走ってしまったクチなので、あまり偉そうなことは言えないのですが…。

*4:ちなみにx86版であれば16bitコードも走るので、Windows 1.0同封のリバーシなんかも動くそうです(1985年!!)←これ、どうも私がWin3.0同封のリバーシと勘違いしてた疑いが強いため、訂正します。3.0は1990年リリースなので、確実に動くと言える最古のものは、その頃のアプリです。きっと昔のOASYS/Winだってそこそこ使えるんじゃないですかね。

*5:単に新しいAPIへ移行してね、というだけなら、エミュレーションモジュールなり間に挟みゃ良いだけで、現にWin32環境ではそういう機能が提供されていたはずです。それをあえてしなかったということは、互換を捨ててでも旧来のコードを走らせたくない理由があったと考える方が筋が通るように思います。

*6:これ、デバイス側の自由度が高すぎるので、そのまま真に受けるとホスト側の実装がものすごく面倒になるんですよ…。Windowsとかメジャー所はどうやらちゃんと解析してくれるみたいなんですが、USBの仕様書が全般的にフワッとしてるのもあって、しばしば「解釈違い」による問題が出るようです。一応、それを回避するために、ガチガチに固めたHID Boot protocolなんてものが定義されているのですが、これが逆に「モディファイヤキー以外の同時押し6キーまで」といったよく聞くUSBキーボードの制約を生み出してしまいました。あとWindowsのUSBキーボードドライバレイヤは非常に雑で、規格書で定義されたUsage Code(キーコード)のうち、一般的なキーボードでは使われていない定義値の大半が扱えません(スキャンコード変換時に捨てられる。この変換テーブルをハックする方法が無い)。USBキーボードに変わり種が少ないのは、ほぼこいつのせいだと思って良いと思います。

*7:富士通のは結構ひでぇんだよなぁこれが…。

*8:ええと、何が言いたいかというと、こういう代物なんで、貴様ら焦ってバカみたいに無駄な買い占めすんじゃねーぞ、俺の分取っとけ、という話です。

2019年総括

今年は本体サイト・ブログ共に新天地へ移転するなどして、サイトとしては大きな転機を迎えた年でした。長く使っていたアドレスが立て続けに失われたことでなごり惜しくもありますが、心機一転のチャンスかもととらえることにします。

他に大きな進展があったのは富士通キーボード関連のページです。大昔に書いたまま長らく放置していたものの、英語圏のキーボードファンの方とのやりとりをきっかけに、これを相当拡充させることにしました。ちょうど手元にあったはずの資料が散逸していたのに気づいたのもあって、改めてコピーをもらったり再調査し直したりして多くの情報を発掘できました。こちらに関してはまだ全部を書き切れていません…(FES-1/2/3とか、ピアレスの由来とか)。こりゃ来年前半のテーマだな…。この辺はDaniel Beardsmore氏が先行してまとめてくれていますので、興味のある方はどうぞ。

しかし、目的の為に平然と言語の壁を乗り越えてきて、積極的にコンタクトを取り高速に情報をまとめあげる彼の人の様は横で見ていてとても衝撃的でした。久々に本物のマニアを見た気がしました。あのアグレッシブさをぜひ見習いたいです。また、こういう古き良き個人サイトを作る方が、ちゃんとまだネット上に居たことが嬉しく思いました。一見偏執的にも思えてしまうマニアックな情報の集合体こそ「私が見たいネット」です。それに何かしら寄与できるなら喜んで情報提供するし、自分のサイトにもその役割を負わせ続けたいなと思える気がしました。

一方で、今年はソフトの新たな成果物を出すことができず、からっきしでした。特にScrapstick。もうすぐ出すみたいな文章書いといて結局出せてないでやんの。

…このままだとこっ恥ずかしいので少々弁解させて下さい…。端的にいうと、大きな手戻りが発生したのが原因です。

具体的には、

  • バスの列挙・制御I/Fを作り直した。
    • システムで扱う3つのアドレス空間それぞれで、管理構造も制御方法もまるで違う状態だった。ある程度決め打ちで使う限りは自然だったものの、これをエミュレートしたり動的に対象を探して処理したりする場合には相当厄介な仕組みだった。
    • これを、一番自由度の高いアドレスツリーの構造に寄せることと、制御用の動詞部分を別途列挙可能なパラメタとして切り出すことで、統一させることができた。
  • バスの例外処理を作り直した。
    • 例外処理の伝達方法は元々、通常のバスアクセスを多段にしたような形式だった。送出側観点から見ると問題ないのだが、デコードや伝達経路の管理・制御などがすごく面倒だった。
    • これを、受信サービス側での応答制御を追加・整理することで、通常のバスアクセスと全く同等に扱うことができるようできた(つまり、例外処理用の特例的な処理をほぼ抹殺した)。

といった改変を行いました。 元々残機能として今年作るつもりだったのは以下です。

とりあえず、ここまで作りゃ何かしら日常的に使えるものにはなるでしょ、という考えのもと定めた目標でした。いずれも実装に際して、前述した例外処理の機能を使ったり、列挙・制御I/Fのエミュレートをしたりする必要があります。ところが、実際に使用側・エミュる側の立場で使ってみると、前述の通り「今後もこれ使い続けるんか…」という状態だったので、このまま突き進んで公開するよりかは時間かけて作り直した方が良いなと考えました。で、結果的にこれらの改良までしか完了せず、前述の機能はほとんど未着手…という状態です。*1

今度こそ、来年こそは…とは毎度思うものの、まぁーた何にブチ当たるかもわかんねーしなぁ…。もういつ頃までに出すとかいわずに粛々と作るモードに戻ってしまうべきかと考えています。私的なタイムリミットがあるせいでずっと焦っているのですが、結果的に、外堀を埋めて自分のケツをたたくように仕向けても大した効果が無い(結局仕事で作る時ほど色々割り切れない、そして宣言した期限を守れないことで自身への嫌悪感が増す)ことが学習できたので、リミットに対して余裕を持たせて出したい拘りはもう捨てて、進むペースに身を任すようにしようと思います。先にリミットが来てしまったら、そん時ゃそん時で考えるとして。

あとキーボード関連のソフトの方も、来年はいくつか公開したいですね。ついにPS/2ポートが無い環境を使うハメになってしまったので、これに伴ってOyayusbyやOASYS(13ピン) to PS/2 キーボード変換器とかに親指の友Mk-2の親指シフトエンジンを移植したものを作ったりして絶賛テスト中です。これは専用のレイアウトファイルが必要なので、その辺の公開準備ができ次第の予定です。

それと、本体サイトの方で使っているサイト名が若干子供っぽい気がしてきたので、近々変更しようかなと考えています。本当はブログの移行時にセットで変えるつもりだったのですが、良いのが思いつかなかったので、暫定的にブログ名の方だけアタマを削って無難なものにしてあります(しかしこれじゃ何のサイトかわからんな…早急に決めねば)。

こんなところでしょうか。それでは皆様良いお年を。来年もよろしくお願いします。

*1:まぁ2インスタンス間通信の実験準備までは進められましたが…。

ブログの移転が完了しました

Yahoo!ブログのサービス終了に伴いブログの移転作業を行っていましたが、本日作業を完了しました。

新: https://kiyoto-y.hatenablog.com/

旧: https://blogs.yahoo.co.jp/development_room/

旧アドレスからの転送を有効化しましたので、以前のアドレスでは直接記事を参照できなくなりました。今後は、こちらの新アドレスから参照して頂くようお願いいたします。尚、この転送サービスも2019/12/15いっぱいで終了するとのことですので、もし旧ブログの記事へリンクを貼っていただいた方がいらっしゃいましたら、恐れ入りますがそれまでにリンクの更新をお願いいたします。

また、本体ページ側の旧アドレスからの転送も、今月いっぱいで終了するとのことです。こちらもまだの方がいらっしゃいましたら更新をお願いいたします。

移転に際してカテゴリの整理や書式の修正(特に、元々ジオログYahoo!ブログへ移転した段階で既に変に間延びしてたもの)を行いましたので、以前よりも記事を探しやすく / 読みやすくなっている……と思います(特に、1記事に対してカテゴリを複数登録できたり、脚注記法が使えたり、正式に箇条書きが使えたりするのは便利ですね)。それに、何かデザインの方も、本体サイトと似たテイストのテーマがあったおかげで統一感が出ましたし…。

去年から今年にかけて両サイト共バタバタと所在が変わってしまいましたが、これを機に少し新鮮な気持ちで再出発しようと思います。新たな場所でも引き続き宜しくお願いいたします。

(予告)ブログを移転します

Yahoo!ブログのサービス終了に伴い、はてなブログへ移転することにしました。
移転予定先は以下です(まだ移転が完了していないので表示されません)。

https://kiyoto-y.hatenablog.com/

実際の移転は9月に入ってからを予定しており、それまでは現行アドレスでの閲覧が可能です。恐れ入りますが、移転が済みましたら、リンクの更新等を宜しくお願いいたします。

尚、移行ツールの説明によれば、これまで投稿していただいたコメントの移行はできないそうです…。大変申し訳ないですが、ご了承頂ければと思います。

本体サイトの移転が完了しました

以前から予告していました通り、Yahoo!ジオシティーズのサービス終了に伴い、メインサイトを移転しました。

本日、旧アドレスから新アドレスへの転送設定を入れましたので以前のアドレスでは直接ページ参照できなくなりました。今後は上記アドレスから閲覧して頂くようお願いいたします。

で、今度はこのブログ*1なんですが…こっちも2019/12/15いっぱいでサービス終了らしいんですよね。

今のところ今後の方針は未定です。メインサイトの更新作業が少しやりやすくなったので、ブログサービスを使わずそっちに記事ページを追加していくスタイルでも良いような気がしてきましたし。一方、また1社に色々集約しておくとサービス終了時に面倒なことになるので、その対策として別のブログサービスに移行することも検討しています。

Scrapstick関連が書きかけで情けない状態になっているのが少々心残りですが…場所がとっちらかっててもしょうがないので、こっちはブツ公開後にリポジトリの方へ文章を集約して書いてく方針にしようと思います。

*1:移転前の、Yahoo!ブログ時代の話です