コグノスケ

Might and Magic Book One TASのその後

目次: Might and Magicファミコン版

以前（2023年9月3日の日記参照）にMight and Magic Book One TAS US版の更新版（7m 19s）のTASをTASVideosに投稿して、Acceptされました。その時に「2023年に遊んでみる人はいても、TASに挑む人はまずいないと思うので、20年くらいは記録をキープできるんじゃないですか。はっはっは。」なんてことを書きましたが、1か月くらいでTaoTaoさんが大幅に更新（JP版5m 28s、US版5m 00s）してくれました。

大幅更新ポイントの紹介

時間が掛かるはずのJP版と、US版がほぼ同じクリアタイムになっているのが大きな特徴です。クリアタイムの大幅短縮にはMight and Magic Book Oneのクソデカバグ「イドの迷宮はクリア不要」が大きく貢献しています。

アストラル世界の最後にイドの迷宮をクリアしたかどうか判定する床（X:7, Y:8）があり、クリアしていれば通過でき、クリアしてなければソーピガルの町に戻される仕掛けです。ところが床のイベント設定がバグっていて南向き以外で突入すると発動しません。つまり北向きのまま後ろ向きに歩けば素通りしてしまいます。とんでもないバグですね。

詳細は発見者のTaoTaoさんのサイト（マイトアンドマジック（FC）攻略/解析 - マップ - アストラル世界）を見てほしいです。

その他のテクニック

他にもいろいろと工夫されていて非常に短時間でのクリアとなっています。わかる範囲で紹介したいと思います。

扉の突破（JP版、盗賊への転職を不要にする）

JP版は盗賊がソーピガルの宿屋に居ない＆Lv.1の場合は盗賊以外は扉の鍵の開錠に成功しないため、誰か1人を盗賊に転職させなければなりませんでした。しかしわざと扉の罠に掛かってダメージ0の判定を引き扉の鍵を突破すると非常に早く突破できます。言うだけなら簡単なんですけど、試行錯誤だけでやろうとすると全然引けません。

そらとぶじゅうたん（JP版、魔法使いなしで「ひこう」を使う）

JP版はキーカードを手に入れる（オーラのクエストをクリアする必要がある）ため、いくつかマップをめぐる必要があり「ひこう」の魔法が欲しいところです。これを魔法使い＋魔法の泉ではなく、ポートスミスの「ひふきあり」から「そらとぶじゅうたん（使うと「ひこう」の効果）」をドロップさせタイム短縮しています。Lv.1で「ひふきあり」をワンパンKOできるんですね。知りませんでした。

エンカウンター予約

モンスターとのエンカウンターがイベント発生後にも発生するという仕様を利用して移動回数を減らす工夫です。例えば、移動→イベント→エンカウンター、という順序で発生します。動画だと火山の神と話すときがわかりやすいですね。

降参ワープ

モンスターとの戦闘を回避する方法には「逃げる」と「降参」があります。逃げる、もしくは、降参時に一定条件を満たすとマップ依存の固定座標にワープします。なぜかいくつかのマップでは逃げた後の座標と、降参した後のワープ座標が異なり、近い方にワープすればタイム短縮できます。これはバグじゃなくて仕様だと思いますけど、降参だけ特別扱いする意味はさっぱりわかりません。

これらはいずれもTaoTaoさんの詳細に渡るプログラムや乱数解析の賜物です。いやーすごい。

PCBを設計して注文

目次: Arduino

シューティングの練習でいつもお世話になっているTARGET-1秋葉原店に、6つの的を撃つシューティングゲームが設置されています（TSS？だったかな、名前は忘れました）。10年くらい頑張って稼働してくれたそうですが、製造元が既になくて壊れたら修理ができないんですと困っていました。

シューティングゲームのボードとターゲットの回路を見た感じ、素人の電子工作でもなんとかなりそうな作りだったので、代わりとなるおもちゃを作ることにしました。最初は簡単かなと思っていましたが、意外と時間を食ってしまって結局2か月くらい電子工作をしてました。

今日は電子工作の集大成となるPCBの発注です。発注先はJLCPCBです。ボードだけなら5枚でたったの$3、恐ろしい安さです。今回は部品も実装してもらうので合計$67（円安のせいで1万円近い）ですが、それでも安いです。便利な時代になったなあ。

KiCadからJLCPCBに設計図を出す方法

KiCadのプラグインFabrication Toolkitをインストールします。

JLCPCB Fabrication Toolkit

PCBエディターのツールバーの右端にアイコンが増えるはずです。

JLCPCB Fabrication Toolkitのボタン

ツールバーのボタンを押すとダイアログウインドウが出るのでGenerateボタンを押します。

JLCPCB Fabrication Toolkitのダイアログ

KiCadのプロジェクトがあるディレクトリの下にproductionディレクトリが生成されるはずです。productionディレクトリの下にある*.zipをJLCPCBのWebサイトの見積もりウインドウにドラッグ＆ドロップします。

JLCPCBのウェブサイトのZipファイルをドロップする場所

見積もりページが表示されます（ボードの外観も表示されます）ので、ボードを製造する際のパラメータを選びます。右側には見積もりが表示されます。JLCPCBのシステムは非常に使いやすいですね。

モジュラージャックの規格

目次: Arduino

古くは電話線で、今だとEthernetで良く見かけるモジュラージャックというコネクタとレセプタクルがあります。モジュラージャックの種別はRJなんとか（RJ11など）という名前で呼ばれます。数字が違うと何か違うのは知っていましたが、今まで気にしていませんでした。

最近、趣味で早打ちターゲットを作っていて電子回路＆基板を書いているんですが、部品の1つにRJ14（6極4芯）を使っていて、そのときRJ11〜18までRJなんとかシリーズがたくさんあることを知りました。電子回路作成ツールのKiCadの部品リストによれば、下記の種類があるそうです。

• RJ11: 6P2C（6極2線）
• RJ12: 6P6C（6極6線）
• RJ13, RJ14: 6P4C（6極4線）

どの規格で定められているのか？RJなんとかとは何か？RJ13とRJ14は何が違う？と気になったので規格に当たってみました。

1976年の規格、RJなんとか＝USOCのこと

最初のどの規格で定められているのか？ですが、RJなんとかは41 FR 28699, July 12, 1976（PDFへのリンク）にて定義されています。古そうだなとは思いましたが、まさか50年前の規格だったとは……。

FR（Federal Register）は連邦官報のことです。FRはPDF形式で配布されていますが、PDF形式と言いつつ中身はスキャン画像の羅列でした。古い文書だと仕方ないですね。ところがOCRを掛けてくれているらしく文字列検索ができます。大変ありがたい。アメリカ政府ありがとう。

次にRJなんとかとは何か？ですが、この記号はUniversal Service Order Code（USOC）です。§68.502の説明を見ると、

These USOCs are generic telephone company service ordering codes. If a telephone 
subscriber wishes to have the telephone company install a standard jack other 
than the one depicted in § 68.502(a)(1) below, he shall specify the appropriate 
USOC when requesting the installations.

（適当訳）
これらUSOCは一般的な電話会社のサービス注文コードです。電話加入者が電話会社に対し、下記の§68.502(a)(1)に
記載されているジャック以外の標準ジャックの設置を希望する場合は、設置を要求するときに適切なUSOCを指定するものとします。

とあります。§68.502(a)(1)というのはRJ11のことを指しています。RJなんとかは電話会社に設置を頼むときの注文番号だったんですね。へー……。

RJ14は書いてあるがRJ13は見当たらない

次はRJ13とRJ14の違いを調べます。FRからRJ14Cの規格を見つけました、こんな定義です。手書きの図が良い味出してますね。

RJ14の定義

しかしRJ13は載っていませんでした。後で追加された規格なのか？残念ながらRJ13とRJ14の違いはわからないままです……。

Code of Federal Regulationsのほうが見やすいかも

黄ばんだ画像のFR 28699, July 12, 1976より、CFR（Code of Federal Regulations）のTitle 47 Vol.3 1996年（PDFへのリンク）の方が見やすいかもしれません。

日本語だとFR（Federal Register）は連邦官報、CFR（Code of Federal Regulations）は連邦規則集という名前だそうで、CFRはアメリカ政府が発行している規則集です。法律に準ずるものらしいですが、法律の専門家ではないので詳しいことはわかりません。

Title 47はTelecommunicationの話題で、Vol.1からVol.5まであります。Vol.3の一部しか見てないですけど……。

画面のブランクを無効にする

目次: Linux

ROCK 3 model CのDebian bullseyeイメージは10分ほど？放置していると画面が消えてロック画面に戻る設定になっています。これはこれでありがたい動作ですが実験用に使っていてキーボードを繋いでいないことがあるので、ロック画面への移行と、画面が消える動作を無効化する方法をメモしておきます。

ロック画面の設定

ロック画面を無効化するには、Xfce4の[アプリケーション] - [設定] - [スクリーンセーバー]（xfce4-screensaver-preferences）の、

xfce4-screensaver-preferences

タブ[ロック画面] - [ロック画面を有効にする]をOFFにすれば良いみたいです。再起動後も設定を覚えてくれています。

画面が消える（DPMS）設定

画面が消える機能はDPMS（Display Power Management Signaling）といって、Xfce4の設定パネルからだと[アプリケーション] - [設定] - [電源管理]（xfce4-power-manager-settings）の、

xfce4-power-manager-settings

タブ[ディスプレイ] - [ブランク画面にするまでの時間]などから設定できます。しかしロック画面と違って設定を覚えてくれない？みたいで、再起動すると元に戻ってしまいます。理由が良くわからない……困った。

xsetとXDGで起動時にDPMSを設定

Xfce4は良くわからないので降参して、X Windowに頑張ってもらうことにします。DPMSの状態の設定と取得にはxsetを使います。リモートから実行するなら他のX Window Systemのアプリと同様にDISPLAY=:0などのように、どのディスプレイか指定する必要があります。

DPMSのStandby, Suspend, Offを一気に無効にするにはdpms 0 0 0と指定すれば良いです。DPMSの設定は最後の方に表示されます。

$ xset dpms 0 0 0

$ xset -q

Keyboard Control:
  auto repeat:  on    key click percent:  0    LED mask:  00000000
  XKB indicators:
    00: Caps Lock:   off    01: Num Lock:    off    02: Scroll Lock: off
    03: Compose:     off    04: Kana:        off    05: Sleep:       off
    06: Suspend:     off    07: Mute:        off    08: Misc:        off
    09: Mail:        off    10: Charging:    off    11: Shift Lock:  off
    12: Group 2:     off    13: Mouse Keys:  off
  auto repeat delay:  500    repeat rate:  20
  auto repeating keys:  00ffffffdffffbbf
                        fadfffefffedffff
                        9fffffffffffffff
                        fff7ffffffffffff
  bell percent:  50    bell pitch:  400    bell duration:  100
Pointer Control:
  acceleration:  2/1    threshold:  4
Screen Saver:
  prefer blanking:  no    allow exposures:  no
  timeout:  0    cycle:  300
Colors:
  default colormap:  0x20    BlackPixel:  0x0    WhitePixel:  0xffffff
Font Path:
  /usr/share/fonts/X11/misc,/usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/75dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/share/fonts/X11/100dpi,/usr/share/fonts/X11/75dpi,built-ins
DPMS (Energy Star):
  Standby: 0    Suspend: 0    Off: 0
  DPMS is Disabled

これだけだと再起動すると元に戻ってしまいますから、XDG autostartで毎回起動時に勝手に設定する仕掛けにします。システム全体ならば/etc/xdg/autostart/に、ユーザーごとに設定したいなら.config/autostart/に設定ファイルを作成します。ファイル名は何でも良いですが、今回はxset.desktopという名前にしました。

[Desktop Entry]
Name=xset
Comment=Disable DPM
Type=Application
Exec=/usr/bin/xset dpms 0 0 0
X-GNOME-Autostart-Phase=Initialization

ファイルを作成したら再起動して、DPMSが望み通りの設定に変わるか確かめます。

Xfce4の設定パネルからだと[アプリケーション] - [設定] - [セッションと起動]（xfce4-session-settings）からも作成＆設定できるはずです。たぶん。

JavaとM5Stamp C3とBluetooth LE - Bluetoothデバイスとの通信

目次: Arduino

M5Stamp C3をBluetooth LEデバイスにして、Linux PCもしくはRaspberry PiなどのLinux SBCとお話する取り組みの続編です。

今回はbluez-dbusを使ってBluetoothデバイスと通信します。

データ通信の仕組み

前回の話と少し重複しますが、Bluetoothデバイス特にBLEデバイスとはGATTプロファイルを使って通信します。BLEデバイスはサーバーになります。サーバーはService（＝提供する機能）を1つもしくは複数持っていて、Service、Characteristic、ValueとDescriptorが入れ子の構造になっています。

GATTサーバー（BLEデバイス）

Service

Characteristic

• Value
• Descriptor
• Descriptor
• ...

GATTのデータ送受信はCharacteristicのValueを読み書きすることで実現します。まずは簡単な送信側（Write）からご紹介します。

private BluetoothGattCharacteristic GattTx;

byte[] dat = new byte[len];

//送信するデータを用意する
//...

GattTx.writeValue(bpart, null);

バイト配列を用意してwriteValue()を呼びます。書き換え属性を持っているCharacteristicでないと書き込みが失敗します。

次は受信側（Read）です。writeValue()と同様にreadValue()も用意されていて、最後にReadした値を読み出せます。しかし一度読んだ値なのか新しい値なのか区別が付きません、つまり値の更新の有無がわかりません。

BluetoothGattCharacteristic GattRx;

byte[] dat = GattRx.readValue(null);

ではこの方法はダメなのか？というとそんなことはありません。一定時間ごとに現在値を見たい場合、例えば「温度計の値を1分ごとに読み出す」といった用途で役立ちます。

一方でストリームデータを扱う場合、新しい値がきたときだけ読み出したいので更新を検出する必要があります。検出には少しややこしい処理が必要です。bluez-dbusは何かの状態変化が起きるとPropertiesChangedというイベントで知らせてくることを利用します。使い方は、

• AbstractPropertiesChangedHandlerを継承したハンドラクラスを作成
• ハンドラクラスのインスタンスをDeviceManagerに登録
• BluetoothGattCharacteristicのstartNotify()を呼ぶ（BLEデバイスからのNotifyを検知できるようになる）

コードで書くと下記のようになります。

public class PropertiesChangedHandler extends AbstractPropertiesChangedHandler {
    @Override
    public void handle(Properties.PropertiesChanged props) {
    }
}

BluetoothGattCharacteristic GattRx;

DeviceManager deviceManager = DeviceManager.getInstance();
PropertiesChangedHandler handler = new PropertiesChangedHandler(...);
deviceManager.registerPropertyHandler(handler);

GattRx.startNotify();

PropertiesChangedハンドラはCharacteristicsの値の更新も、別の関係ないイベントも何でも受け取るので、何のイベントが発生したか判定する必要があります。bluez-dbusのBluetoothGattCharacteristicクラスと、PropertiesChangedクラスはいずれもD-Busのパス（/org/bluez/hci0/dev_xx_xx_xx_xx_xx_xx/service0028/char0029のような文字列）を返すメソッドを持っていますので、D-Busのパスが一致するかどうかで確かめます。

変化した値と名前のMapをgetPropertiesChanged()で取得できるので、全要素を調べて名前がValueであり、バイト配列を保持していればCharacteristicの値の変化を通知するイベントのはずです。

BluetoothGattCharacteristic GattRx;

Map<String, Variant<?>> mapProp = props.getPropertiesChanged();

if (GattRx.getDbusPath().equalsIgnoreCase(props.getPath())) {
    for (Map.Entry<String, Variant<?>> e : mapProp.entrySet()) {
        if (e.getValue().getValue() instanceof byte[]) {
            dat = (byte[])e.getValue().getValue();
        }
    }
}

自分でBLEデバイス側の実装をしているなら、意図しないイベントが混ざることはありません。上記のコードのように簡素なチェック（例えば単にバイト配列かどうかだけチェック）でも動作するはずです。