ゲーミングキーボード Logicool G512r-TC 有線 RGB タクタイル

自作OSの作成に疲れたのもあって、しばらくSteamのゲームをして遊んでいた。それなりに継続して遊んでいるのは、DEAD OR ALIVE6だが、ゲームパッドを持ってないので、キーボード入力で操作しているが、Dランクから全然上達しない。というのは、反射的な操作をした時に、思った通りの動作をしてくれないからだ。昔は自分の入力ミス、指が追い付いてないと思っていたが、二年近くも操作して、指が慣れた今は、キー入力の順番が入れ替わったような動作やキー入力の無視、遅延などが発生していると確信している。最近、ゲーミングキーボードというゲーム用のキーボードがあることを知り、複数キー同時押しやゴーストインプットを防ぐ機能があるとのことで、自分の所為なのか、キーボードの所為なのか、疑問を解消するために、ゲーミングキーボードを衝動買いしてしまった。普通のキーボードなら二千円もあれば買えるのに、自分でも馬鹿みたいに思うが、自分の感じる怪しい現象が本当のことなのか、違うのかどうしても知りたいと思った。

ゲーミングキーボード Logicool G512r-TC 有線 RGB タクタイル

選択したポイントは、26キーロールオーバーという複数のキーをどの順序で同時押ししても、狙い通りのコマンドを発動できることと、アンチゴースティングとかいう機能によって、複数のゲーミングコマンドを同時に押した時に確実にコントロールすることができる、などと説明に書いてあったことだ。
流石に数万円の高機能品は買えなくて、ぎりぎりキーボードに出せる金額のこのキーボードに決めた。一万円以上したので、これで問題解決しなかったら、自分の技術不足、思い違いだと認められるかと思った。

最初の感想は、ずっしり重い。キーボードが打鍵で動かないようにしているのだろうが、重すぎる気がした。それと、USBコネクタが二股になっているのに驚いた。片方はUSBパススルーで給電のためらしい。全く有用でない光る機能のためらしいが、それらを省いて、もっと安くしてもらいたいと思う。専用の常駐ソフトは使わずにいたが、むやみにキーボードが点滅し続けるのでうざい。不本意だが、Lghubとかいう専用ソフトを入れると、点滅が止まった。

タッチタイピングが変わって違和感があったが、これは慣れの問題なので仕方ない。使ってみると、キャラ操作がスムーズになり、キー入力の入れ替わりが無くなったように感じた。同時押し技のホールドが決まり易くなったが、キー入力の無視はそのままだった。ネットで調べてみると、DEAD OR ALIVE6は連続キー入力の無反応時間が他の同類ソフトと比べて長めで、コンボ技の途中キャンセル機能やコンボ技の最後のタイミングをずらす遅延機能があって、それに当てはまらない連続的なキー入力は切り捨てるような仕様になっている、というような書き込みがあった。もしそうなら、高性能なゲーミングキーボードを買っても改善は見込めない。ホールドはキャンセルや遅延入力の受け付けがないので、このキーボードで改善されたのだろう。正直これでは、一万円のコスパには合わない。五千円くらいで充分だった。しかし、ゲーミングキーボード自体は悪いことはないので、できるだけ長く使って、コストに合うようになることを願いたい。

(2023/4/10追記)Dead Or Alive6をずっとプレイしていたが、もう「S」と「D」のキーの表面の塗装が少し剥げてしまった。ゲームで連打しているので、文字が薄れたりするのは仕方がないが、早すぎないだろうか。コストのために塗装剤の質の悪いものを使っているのかもしれない。選択を失敗したとまでは言わないが、正直、がっかりした。

(2025/2/27追記) 二週間前くらいから「M」のキーが二重入力するようになった。内部の軸か何かが摩耗してしまったのだろう。ゲームで一番叩いていたキーなので仕方ないが、サイトのログインなどで、パスワードの中に「M」が含まれる場合、何度もログインエラーとなってしまい、困ってしまう。結局、購入から二年程度で、ゲーミングキーボードは使えなくなるということが分かった。修理できるのか調べて、ダメなら買い替えするしかない。痛い出費だ。(2025/3/1解決)ネットでの情報で、キー入力が二重になる場合、埃やごみが詰まっている可能性がある、と書いてあった。確かに二年間一度も掃除していなかった。エアダスターで「M」キーの周辺の埃を綺麗に吹き飛ばしていったら、二重入力はなくなった。まだ買い替えはしなくて良いらしい。ちなみに、このキーボードを修理しようと思ったら、修理用の専門の道具と、はんだを除去する溶剤が必要で、素人だと難しいらしい。どうせ捨てるなら試してみる手もあるが、失敗した場合、道具代と修理部品の余計な出費が上乗せされることになる。ホットスワップ対応のキーボードなら、壊れたキーだけ自分で修理することもできるらしいので、次に購入する時には、それも検討しようと思う。(2025/3/23再発)「M」の入力が二重になるチャタリングが、また再発しだした。今度は、エアダスターで噴いても治らない。完全に内部の故障だろう。残念だが、新しいゲーミングキーボードを購入するしかない。ネットの書き込みなどを見ていると、ゲーミングキーボードは、毎日激しく使用している場合、一年か、二年で、良く叩くキーが壊れてしまうらしい。次回は、できるだけ安い物を買うか、壊れたキーだけを交換できるホットスワップ対応の物を買おうと思っている。

カテゴリー: PC周辺機器, ゲーム | コメントする

FatFSの移植(FDへのファイル作成) — 自作OS

ステップローダーの作成と本番用ブートローダーの分離と制御移行に成功したので、FatFsのファイル書き込み機能の実装を行った。これまでの経緯については、以前の記事を参照して欲しい。

disk_write()コマンドは、disk_read()コマンドの時と同様に、既に作成済みのDMA処理でディスクへ書き込む関数を流用して簡単に作成できた。
テスト用の簡易コマンドを作成して、コマンド実行で短いテキストファイルをフロッピーディスクイメージ内へ新規作成を行い、そのフロッピーイメージをManjaro Linuxでマウントすると、正常に認識され、Mousepadでも開いて中身を表示できた。一部を修正して保存。アンマウントして、再度、VirtualBoxで起動すると、簡易lsコマンドで一覧表示され、簡易catコマンドで修正した通りの内容が表示された。

直接関係ないことだが、FatFsをコンパイルする時に、i686-elf-gccでは8-bbyteのQWORDが選択され、エラーとなってしまって、付け焼刃で、QWORDを使用しないように勝手に修正している。/usr/lib/gcc/——-/stdint.hというインクルードファイルが必要だった。stdint.hから必要なものをリライトして、pseudo_stdint.hというファイルを作成して対応しようと思ったが、中身は#ifdefなどのマクロ判定の塊で、ロジックを追うのが面倒だったので、ff.hを手作業で32bit用に修正した。
確証はないのだが、コンパイルエラーの原因は、i686-elf-gccの問題だと思う。英語のサイトを調べ回って理解できた限りでは、Manjaro Linuxのi686-elf-gccのオリジナルはgcc-11.2.0なので、標準C言語の2011年仕様に準拠していて、FatFsは変数の型を選択する際、#defineマクロの__STD_VERSION__などで、1999L以上かどうかでstdint.hと8-byte=QWORDを採用するかどうか判定していて、i686-elf-gcc自体は32bit限定のgccなのだが、#defineマクロの判定のために、stdint.hとQWORD型を採用してしまっているように見えた。stdint.hを参照するようにすれば、エラーはなくなるのかもしれないが、i686-elf-gccがQWORD型へ対応できているのか分からない。

一応、目標とするところは終えた。Timer割り込みとカレンダー機能とか、共通ルーチンのライブラリ化と分離もやっておかないとソースが重複したり複雑になったりするので、今やっておいた方がいいし、必要なら簡易なシステムコールを作成するか、いろいろな事情があって迷っている。

カテゴリー: Linux, VirtualBox, 自作OS | コメントする

FatFsの移植(FD書き込みの挫折) — 自作OS

今度はFDDへの書き込みのためのdisk_write()、disk_ioctl()を作成する。
テストのために、フロッピーディスクイメージの空きセクタへ1セクター書き込むアセンブラのサブルーチンを作成し、writefdという簡易コマンドを作成して、バイナリエディターでフロッピーディスクイメージの指定したセクタへデータを書き込んでいるかテスト確認してから、FatFsへ移植することにした。

FDDへのDMA転送設定は、DMA回路のモードレジスターへの設定値を変えるだけなので、read用の関数をコピーし、5分で修正できた。
FDDへのWRITE-DATA(0x05)の制御コマンドのシーケンスもREAD-DATAと同じような流れで、IRQ6割り込み待ちとSENSE INTERRUPT STATUSコマンドの送信など、ほとんどコピーし、違いとしては、コマンド処理ステータスのST1のNW-bit(bit1)がフロッピーディスクが書き込み禁止であることを通知するためにONになるので、それをエラーチェックすることぐらいしかなかった。そんな風に、disk_write()は三時間ほどで簡単に作成できた。テスト用書き込みコマンドを作成し、指定したセクターへ設定したデータを書き込むことを確認した。
disk_ioctl()は、ドライブ情報得る時やフォーマット操作をする時など、ディスク操作関数の内部で使われるらしい。ブートモニターにはフォーマット機能をもたせる必要がない(起動ドライブの自分自身を消去することになる)ので、最低限の処理だけならドライブ情報を通知するだけで、簡単に作成できた。

作成中に思わぬコンパイルエラーが発生した。今まではFatFsをリードオンリーの最小構成でビルドしていたのが、リード/ライトに設定変更したら、stdarg.h、math.h、string.hのstrlen()が存在しないというエラーメッセージだった。math.hはf_printf()で浮動小数点処理を組み込むようになっていたからで、それを取り外した。strlen()は64bitサイズの変数を扱うためで、また新たに作成しても良かったがlonglong型を使うことはないので、これもffconf.hの設定を変更して、64bitサイズを組み込まないようにした。
問題はstdarg.hで、初めて見るヘッダファイルだが、va_listやらva_startやらva_argとかの関数を提供しているらしかった。調べてみるとprintf()やscanf()など引数の個数が可変の関数のためのマクロ定義だと分かった。gccの内部で対処できる事前定義された処理なので、ヘッダファイルをそのまま利用しても問題ないらしかった。念の為、/usr/lib/gcc/——-/stdarg.hを探し出して、中身の正味6行分をリライトして、pseudo_stdarg.hを作成した。それでコンパイルエラーは出なくなった。しかし、今度はリンクエラーが出るようになった。前にも経験した「relocation truncated to fit: R_386_16 against `.data’」で、オブジェクトのサイズが以前より10K-byte以上増えて、0xffffまでの16bitリアルモードのラベルシンボルの範囲に収まらなくなっていた。回避方法を模索してみたが、調べても何もわからず、f_printf()などの関数の動作確認は断念し、DMA書き込みルーチンの検証はできたので、FatFsをリードオンリー構成へ戻した。

メモリマップを見直してみたが、10K-byteを空けるのは難しく、何とか収めたとしても、プログラムの追加や修正をしたら、また同じエラーが出るのは目に見えている。スタック領域として使っている領域も、30K-byte程度しかなく、スタックへローカル変数を大量に確保する高級言語でのプログラミングでは少なめで、削るわけにもいかない。
さんざん考えた挙句、二段階ローディング(?)ともいうべき方法をとることにした。今のブートモニターはリードオンリーだけで機能拡張はせず、16bitモデルのシンボルを含まない32bitプロテクトモードの別個のモジュールバイナリをフロッピーイメージからRAMへロードして、制御をそちらへ全て移す。FatFsのモジュールなどは重複するが、現在の方法ではこれ以上、機能を拡張できないので、もう行き詰まっている。現在のブートモニターはステップローダー(仮称)という名前にして画面表示やコマンド実行などの不要な機能を削除し、32bitプロテクトモードへの変更とプログラムロード機能だけに特化し、0x00010000以降へFatFs(リードオンリー構成)で本番用ブートモニターをロードし、そこへジャンプする。本番用ブートモニターには制限がなくなるので、ステップローダーのメモリ領域も含めて、作業用に利用することができるはずだ。かなり大きな改修だが、自作OSという試行錯誤に必要な試練だと思うことにする。
しかし、8bitから続くx86系CPUは至るところでアーキテクチャーにツギハギ感がある。ARMやMIPSなどは、同じような問題は起こらないのだろうか? とちょっと興味を持った。

ステップローダー(仮称)を作成中に、gnuアセンブラの変なjmp命令の書き方を知った。本番用ブートモニターへジャンプ(ステップローダーへは戻らない)する時、0x00010000という絶対アドレスへジャンプするのだが、movl $0x00010000,%eaxでジャンプ先アドレスを設定して、jmp %eaxだとエラーになる。こういう場合、jmp *%eaxと書かなくてはいけない。ちゃんとgnuアセンブラが、’*’を付けるよう警告してくれる。癖のあるgnuアセンブラのよく意味の分からない古い記述、みたいな書き込みが英語のサイトにあった。まあ、滅多に使うことのない記述だが、覚え書きとして残しておく。

本番用ブートローダーは、16bitのプロテクトモード変更処理の部分だけ削除し、メモリ配置だけ修正して機能はそのままにした。ステップローダー(仮称)から自動でロードされ、最初に再度ハードウェア関連の初期化処理をして、コマンド入力の画面まで表示された、と思ったら、キーボード回路の初期化に失敗した。ステップモニター(仮称)の方でも必要ないのにキーボード回路の初期化をしていたので、そちらを削除したら、ブートモニターがキー入力を受け付けるようになった。何度初期化をしても問題ないと思っていたので、腑に落ちないが、時間がある時に原因を究明しようと思う。ブートモニターでもlsやcatなどのコマンドが正常に実行できた。やれやれだ。次はFatFsをリード/ライト構成にして、フロッピーディスクへファイルを作成しようと思う。

カテゴリー: Linux, VirtualBox, 自作OS | コメントする

FatFsの移植(読み込みだけできた) — 自作OS