MMDVMHostのステータス表示用に使うSurenoo TFT LCDパネル（UARTで接続する）、ASCII以外の文字列も表示できるよなーと思って調べてみるとGB2312を受け付けるようです。とはいえ、GB2312なるものをきちんと知らないので…日本のようにJIS/Shift-JIS/EUC-JPのようにバリエーションがあるかどうかとか…以前作ったテスト用のコードをいじって実際に文字列を投げてみることにしました。

詳細はテスト用のコードを見れば分かるので割愛しますが、雰囲気としてはEUC-JPのような0xa1a1〜のバイト列を送るのと、当然ですがEUC-JPとは異なるグリフの割り当てになっています。EUC-CNとも呼ばれるもの、ということになりますか。

…で、あれば。イマドキのシステムはUnicodeで動いていますし、UCS(Unicode)→EUC-CNに変換してLCDに投げれば日本語の文章も多少は表示できるはず？

libkkcの辞書の素(data.arpa)を作成する際にEUC-JP←→UCSの変換テーブルをJIS0208.TXTを使って作っているので、EUC-CN←→UCSについてもGB2312.TXTを使えば作れるのでしょう（これが何故unicode.orgに置かれていないのかは謎として）。という訳で作ってみましたが…

変換テーブルの内容を見直すなどして記号類の対応を改善しないといけないのと、完全な変換は望めない以上kakasiを使って漢字を減らしていく等の方法を考えないと、実用は難しそうです。まあ、21世紀も20年以上が経過していますから…JISで書かれた日本語の文書をGB2312環境でどうにかして表示するようなツールが既に作られていてもおかしくはないはずですし（多分ある気がします）、未だに作られていないのならかなりの困難があるのかも。54.8kg(22:40)

28-Dec-2023補足：jis2gbというそのまんまなツールがあるのを見つけましたが、ライセンスの設定が無いのでこの変換テーブルを使うのは避けることにしました。代わりに、Unihan-2.txtを使って拾えるだけ文字を拾ってみるようにして、こんな感じ。

それでもまだ〓の出る場面があって、一番困っているのは「円」(U+5186)→「圆」(U+5706)の変換。これ、U+5186のkZVariantから「圓」(U+5713)を参照し、このkSimplifiedVariantでU+5706へ繋げるので…現状の、単にkSimplifiedVariant, kZVariantを見るだけ、という対応ではどうにもなりません。

とりあえず試作品のソースコードは現時点の物に更新してありますが…「japanese chinese kanji conversion」で検索してみるとKanjiChineseConverterやKanconvitがあるようなので、Unihan-2.txtで無理矢理やるよりも（ライセンスに問題が無ければ）こちらの成果を使った方が良い結果が得られるのかもしれません。

03-Jan-2024補足：kanji_chinese_converter/ja_zh_cn.rbをC言語化して組み込んでみました。このファイル自体にライセンスの文言は記されていませんがGitHub上のKanjiChineseConverterのライセンスがMITとなっているため、当日記サイトに置いた変換元(ja_zh_cn.rb)および変換後のファイルはMITライセンスとします。このテーブルがあるからといってUnihan-2.txtが不要になるという訳ではなく、これでもまだ〓になってしまう文字はあるようです。

JMH（船舶向け天気図）の電波予報を受信してみました。毎月20/21日にしか放送しないので、予定が合わないと受信できません（と前にも書いていますね）。

同じ信号強度だと7795kHzよりも13988.5kHzで受信する方がクリアに受信できるので13988.5kHzで受信してはみたのですが、なんかボロボロです。前回（二度目）の受信結果の方が遥かに綺麗です。

周波数の低い方がクリアでは無いというのもすごく気になっています。無線機のAGCの設定をoffにすることで状況が変わることもなさそうですし、何か調整が必要なのかもしれません。

少し前に移動しない局（JumboSPOTとIC-7200が配下にある）で14MHzが出せる免許がおりたので、実際に電波を出せる状態にあるのですがまだ試していません。来年はFT8が出せるように環境を整備しないといけませんかね。54.4kg(19:15)

/usr/sbin/sshdがOpenSSH 3.1と非常に古く、イマドキのSSHとの鍵交換がうまくいかずtelnetログインしないといけないのが面倒なので、Dropbearに替えてしまいます。

アーカイブはbzip2形式ですが、tar xpf dropbear-2022.83.tar.bz2で展開できます。make時に-Wextra, -Wdeclaration-after-statement, -Wsystem-headersなんてオプションは知らぬわとgcc-2.95.3の機嫌が悪くなるので、libtommath/makefile_include.mkからこの三つのオプションを削除しておきます。あとは./configure; makeでビルド。dropbearconvertのリンク時に-pieも知らんなあとも言われますが、これは無視して構いません。最後にmake installで/usr/local/sbin, /usr/local/bin, /usr/local/share/manにファイルが格納されます。

/etc/sshにはssh_host_key(RSA1), ssh_host_rsa_key(RSA), ssh_host_dsa_key(DSA)がありますが、これは無視して/etc/dropbearに鍵を作ります。Ed25519鍵があれば十分なのでmkdir /etc/dropbear; cd /etc/dropbear; /usr/local/bin/dropbearkey -t ed25519 -f dropbear_ed25519_host_key | grep ssh-ed25519 > dropbear_ed25519_host_key.pubとして作成します（公開鍵は不要ですが念のため控えておきます）。もちろん、必要に応じECDSA鍵などを用意しても良いでしょう。

動いているsshdをkillで殺した後、/usr/local/sbin/dropbear -wでdropbearを起動し、外部からSSHログインが可能なことを確認しておきます。

sshdの起動は/etc/init.d/sshdで行われているので（/etc/rc?.d/{K25,S55}sshはこのファイルへのシンボリックリンクです）、chmod -x /etc/init.d/sshdとでもして起動しないようにしておきます。本来ならきちんとした起動用スクリプトを書かないといけないのですが、今回はecho "/usr/local/sbin/dropbear -w" >> /etc/rc.localとしてお茶を濁します。/etc/inetd.confからtelnetdを起動しないようにして、telnetログインも防いでおきます。

これでOpenBSD機からVine 2.5仮想機へsshでログインできるようになった訳ですが…X11 forwardingの設定方法はsshdと異なる点に注意が必要です（ここでは設定方法について触れません）。あるマシンで試しにdropbearをインストールし、そのことをすっかり忘れてssh -YでX11 forwardingができず半年以上悩んでいたことがあったので。

あとは、sj3-2.0.1.20のインストールを…これは20-Jul-2000の日記に任せます。55.3kg(22:10)

30-Dec-2023補足：dropbearの起動オプションに-wを追加しました。家庭内LANの中にある仮想マシンとはいえ、rootログインは禁止しておいた方が良いだろうという理由です。

また、default_options.hを以下のように修正し、

• #define DROPBEAR_X11FWD 0 → 1
• #define XAUTH_COMMAND "/usr/bin/xauth -q" → "/usr/X11R6/bin/xauth -q"
• #define SFTPSERVER_PATH "/usr/libexec/sftp-server" → "/usr/libexec/openssh/sftp-server"

X11 forwardingとsftpを利用可能にしておくと良いでしょう。

03-Jan-2023補足：dropbearビルド後の動作テストにおいても、dropbear -wで起動するよう修正しています。あと、dropbearの存在するパスも間違えていたのでこれも併せて修正しています。

実は今の今までRISC-V環境を持っていなかったのですが、Milk-V Duoなるものが安かったので買ってみました。I/Oボードもセットで。

ボードの大きさはいわゆるRaspberry Pi Picoサイズ、かなり小さいです。この大きさで64MBのメモリが載ったLinuxの動くプロセッサが載る時代なんだなと、箱を開けて驚きましたよ。

何かに使おうと思って買っていたRaspberry Pi向けのケース（2-layer transparent acrylic clear case等の名称で売られている）があったので、一部を拝借してこんな感じに組んでみました。CPUボードとI/Oボードをつなぐためのヘッダピンの無いセットを買ってしまったようで、これは4月に買ったRP2040搭載ボードに付いていた物を流用しました（どうせnsdemuしか動かさないので無くても困らないし）。

CPUボード単体で使用する場合はUSB越しにRNDISデバイスとして見えるものの、I/Oボードを付けてしまうと見えなくなってしまいます。ボードを見れば分かると言われそうですが、I/OボードがCPUボードのUSB信号線を横取りするような形になっています。I/OボードのUSBハブを使う予定が無ければ（Ethernetだけ使えれば十分という用途であれば）、CPUボードのUSB_DP/USB_BMのパッドを絶縁テープ等でマスクするのが良いのかもしれません。

ソフトウェアについてはGitHubのmilkv-duoにある、duo-buildroot-sdk, duo-filesと公式のドキュメントが参考になりそうです。 milkv-duo-v1.0.6-2023-1201.imgを書き込んだmicroSDを見るとFAT区画にはfip.binとboot.sdのみがあり、使用uboot引导自己的操作系统を見るにfip.binをどう構築するかが鍵…ということで、fiptool info fip.binで覗こうとしたところ「ERROR: fip.bin is not a FIP file」という無情なメッセージが。さて、どこから攻めたものか…56.4kg(08:05)

21世紀も20年が過ぎたというのに、K&RスタイルのC言語で書かれたコードと格闘するような事態になっております。ANSIスタイルを使うのが日常の身には、かなりやりにくいですね…

それはさておいて、VMware Player 17.5上のVine Linux 2.5、VMware SVGA IIで表示ができていても日本語表示がなんとなくおかしいのが気になっていました。今になってやっと気付いたのですが、FontPathの設定で日本語フォントのパスが通っていなかったのが原因でした。03-Dec-2023のXF86Configを修正しておきます。

とりあえずこれで当時物の環境ができたってことで…良いですかね？55.5kg(22:40)

VMWare Playerの超漢字なディスクイメージをQEMUに食わせたり、QEMUでQXL関連のイベントを取るなんてことをしていたのだから、pcnetの動きだってトレースで取れるでしょということに何故今の今まで気付かなかったのか…

なので、取りました。どういう操作をすると問題が起こるかという要点（再現プログラム）、簡単に作ってみましたけどこれ明らかにVMWare Playerの問題な気がしますよ？二回目のリセット後に誤動作しちゃうとか…リアルなAm79C970では起こらないはずなんだけど。

まあ、こちらではこれ以上どうにもならないのであとは然るべき人に丸投げです。54.8kg(05:45)

$(BD)/tool/tool/bzcomp.c（実行プログラムの圧縮）があるのに、圧縮されたものを復元する手段が無いのが前から気になっていたのででっち上げてみました。

作ってみましたではなくでっち上げてみましたとしているのは、超漢字開発環境(BV-GSDK)のlibg.aに入っているbzuncomp.oを利用しているからです。超漢字向けのライブラリとはいえ、i386-elfなオブジェクトなので他の環境でも使うことができてしまうようです（利用規約でも「BV-GSDKや関連情報の利用、用途に関しての制限は特にありません」とあるので、こういう使い方をしても問題は無いはずです）。

真面目にやるのであれば$(BD)/tool/tool/src/comp.hにある圧縮部分の本体を読み解いてこれに対応するコードを書くことになるのですが…そこまで手が回らないのでLinux-i686向けのバイナリを作ってお茶を濁します。

使えるものは使えるに決まってるじゃんではあるのでしょうけど、ライブラリを切り出したものが実際にリンクできて動いちゃうことにはちょっと驚いています。54.0kg(19:50)

お仕事が忙しいのは時期柄仕方ないとして（COVID-19以外の感染症、去年は蔓延していなかったのに…）、他にも何だかんだ手を出してしまったので大変です。

• Nostr Advent Calendarは昨日片付いたところ
• 例のデータ入力の進捗は止まっているのと、ライセンスも適切なものをそろそろ設定しないといけない
• FUJIMI-IMのお手伝いをしたい
• 超漢字VをVMware workstation Player 17.5で動かした際の問題は何とかならないの？

流石に最後のは非常に困っているんですよね。仮想化されたAm79C970(PCnet-PCI, vlance)にネットワークドライバがアクセスするとVMware Playerが機嫌を損ねるということは把握しているものの、何をするとそうなるかまでは分かっていません。何故今までは問題なかったのに、VMware Player 17.5になってからおかしくなったのか…

比較対象としてVine Linux 2.5(kernel 2.4.18)をVMware Playerにインストールしてみたところ、こちらではpcnet32ドライバでvlanceが問題なく動いています。

CannaやWnnを手っ取り早く動かせる古いLinux環境を用意する必要があったのでVine Linux 2.5を使ったのですが、これより古いものはSCSIやIDE周りが正常に動きません。またXFree86がVMWare SVGA IIのドライバを持っていても、ホスト側の色数(bpp)とゲスト側の色数が同じになるようXF86Configを記述する必要があるとエラーメッセージに出ます。解像度の設定もModesの設定が効かないようなのでHorizSync/VertRefreshで強引に合わせています。

Hyper-V(WSL2)を有効にするとVMware PlayerではLILOによるLinuxの起動がやたらと遅くなる問題については、ArchWikiの説明にあるようにlilo.confにcompactを追加することで対処できます。Slackware-15.0の場合はインストール時にこの設定を行っておかないと、全く起動ができなくなります（それくらい遅いです）。

そんな訳で、「やること」の整理が必要そうです。55.5kg(22:30)

10-Dec-2023補足：XF86Config、日本語フォントへのパスが通っていなかったので修正しておきました。修正前のをこちらに置きます。

29-Jan-2024補足：デフォルトでは/sbin/halt -pで（仮想マシンの）電源を切ることができません。/etc/lilo.confのkernel2.4のカーネルオプションに、append="apm=realmode_power_off"を記述しておくと良いでしょう（kernel2.2については未調査です）。参考：Shutdownコマンドで電源断とならない問題の対処方法

※Nostr Advent Calendar第一会場参加記事です：01-Dec-2023の記事はDonさんのNostrで伺かのキャラクターBOTを作った話…Advent Calendarは第二会場もありますので、こちらも併せて御覧下さい※

Nostr秘密鍵を格納するUSBドングルであるNostr singing device (NSD)の真似事をするnsdemuなるものの作成を25-Mar-2023に、RP2040(Raspberry Pi Pico)への移植を09-Apr-2023に行いました。NSD(nsdemu)と組み合わせて使うNIP-07プラグインは現在もhorseのみしか存在せず、horseの元となったnos2xはNIP-26対応などを実装して現在も開発が続いているようですが、horse自体の開発は止まっているように見えます。

NIP-07対応Nostr webクライアントであれば何であってもhorseが使えるはずですが、実際は何故かうまく動かなかったり動作が不安定なケースは多いです。以前はirisをテストで使っていたものですが、いつの間にかirisとsnortが同じようなものになってしまったせいなのかiris/snortどちらでもなんとなく動いています。rabbitも大丈夫そうですが、nostterはNIP-07ログイン後に何故か固まってしまう状況が以前から変わらず続いています。これはどうやって直せば良いんですかね…？

nsdemuは、使用しているsecp256k1ライブラリをv0.3.2→v0.4.0に更新しました。そのままでも動くものではありますが、細かい修正が大量に入っているために念のため上げています。ライブラリ更新に伴う動作への影響も無いようです。

オリジナルのNSDはuBitcoinライブラリを使っているので、このライブラリを使えばもう少し小さなマイコンでもnsdemuが動くかなー？と考えた時期はあったものの結局何もせず今に至っています…という訳で、ライブラリを挿げ替えたものを作ってみました。

RP2040向けのオブジェクト(nsdemu.bin)のサイズを比較すると、secp256k1版は178784バイト、uBitcoin版は108916バイトになっており、少しは小さくなっているようです。256kB程度のROM容量を持つマイコンでないとこの手の処理を行うコードは収まらないのではないかと考えていましたが、128kBでも実現できる可能性があるのかもしれません（とはいえ、あまり余裕はなさそうです…Raspberry Pi Pico SDKの最適化オプションは-O3がデフォルトなので、-Osを使うことができればもう少しサイズを詰められるはず）。

ただし、サイズが小さくなった代償として実行時間はかなり遅くなっています。16-Apr-2023で行ったベンチマークを試してみると、secp256k1版（ECMULT_WINDOW_SIZE=2, ECMULT_GEN_PREC_BITS=4として全てQSPI FlashROM上に配置）では2m2.355sに対し、uBitcoin版では11m40.313s。pico_set_binary_type(nsdemu copy_to_ram)でコード全体をSRAMに置いても11m30.511sと、5倍以上の違いがあります。流石にこれは遅すぎるので、nsdemuは今まで同様secp256k1の使用をデフォルトとしています。

元組み込み屋であるが故にどうしてもJavaScript等を使ったwebサービスよりもこういうマイコンいじりの方に目を向けてしまうのですが、Nostrには「自分の足で立ち上がり、歩いていく」という気風があるように見えるので来年は（苦手な）web周りをいじれたらいいなーという雑な感想で次のJunさんへバトンを渡すことにします。55.1kg(06:55)

03-Dec-2023補足：次の記事（Nostr Advent Calendar第一会場）は、Schnorr 署名に使われる数学 - 初等整数論です。よろしくお願いします。