超漢字V仮想マシンを動かすWindows機にFT232なUSB-RS232Cケーブルを繋ぎ、デバッグポートの出力をCH382なPCIe-RS232Cボードを載せたOpenBSD機で受けるのですが…ケーブルが壊れてしまい、CH380搭載のケーブルに替えたところこれがうまく動かない。送信だけできないとか、受信だけできないとか、とにかく不安定。

仕方がないのでCH382なボードをWindows機に移し、OpenBSD機にはTX382Bなボードを載せてみたものの、これもまたこれでTX382B側が送信中に止まるというトラブルが。単にPCI device IDを追加するだけでは足りないという指摘がパッチを送った半年後にあり、それに全く気付いていなかったという…

という訳で、まずはこれを直すことになりそうです。とりあえずFIFOを有効にすると送信が止まるという事態は避けられているようなのでこの部分はおそらくこれで良いとして、ブレークを受信したりフレーミングエラーが起こった場合にハングアップするかも（それ以前にどうやって再現環境を作るか）という問題をどうしたものか。

vmxscreenでQXLを動かせるかどうか試す件、QEMUで-trace events=./events-file（このファイルの中にはトレースしたいイベントの一覧を記載する：詳細は手軽にqemuのトレースを採るを参照）に加え-vga none -device qxl,debug=1,guestdebug=1,cmdlog=1でDebianを動かした場合の動きを見ると、こんな動きをしているように見えます。

1. VRAM上にsurfaceを作成する
2. RAM上に描画データとコマンドを配置し、surfaceに対するdrawコマンド(type:copy, effect:opaque)を発行する
3. drawコマンドの実行に伴い（別途updateコマンドは発行されていない様子）、update_areaが実行される

これでは確かに、surfaceに対して直接データを書き込み、update_areaコマンドを発行しても何も起こらないというのは当然と言えそうです。

なんとなくの動きは見えてきた気がするので、QXLの描画コマンドの発行方法やコマンドのフォーマット等を調べる必要がありそうです。しかし、先に述べたシリアルポートの問題により全然進んでいません。

2.4GHz LoRaモジュール(E28-2G4M12S)はブレッドボードに挿してArduino（wemos TTGO XIもどき）と接続し、RadioLibのサンプルにあるSX128x_Receiveの動作を試してみました。送信側が無い状態なので受信タイムアウトのメッセージが表示されますが、起動時にSX1280の初期化に成功した旨が表示されているので、おそらくピッチ変換基板周辺は問題ないように思われます。

E28-2G4M12Sとの結線ですが、サンプル通り(NSS→D10, DIO1→D2, NRST→D3, BUSY→D9)とした方が良さそうです。これ以外の配線を試してみてもうまく動きません…NSSの制御をGPIOではなくSPI側でやっていたり、信号線のデフォルトの論理(pull-up/down)等による可能性があるのかなと想像しているのですが、詳細は不明です。

aitendoのプロトタイプシールド基板も届いており、一部を切り取ってサイズを調整し、どこにLoRaモジュールを載せようか悩んでいるところです。

大陸の覇者は、溜まった討伐受注書を簡易討伐で消化できるようになったので助かっています。相変わらずシナリオは進めずに、ログインボーナス(?)のルビーだけもらって何もしない日々。

★5

ギルデロイ(槍), ハンイット(弓), ニコラ(短剣), トレサ(槍), ドロテア(槍), ティキレン(剣), リュミス(斧), グロッサム(扇), ステッド(杖), サイラス(本), ヴァルカン(本), アデル(短剣), イデア(剣), リトゥ(短剣), ムールゥ(本)

★4

ブリジット(杖)

あれだけ大盤振る舞いしたので、そう簡単に新キャラはやらぬわという意思表示なのでしょうか。とはいえ、キャラ被りでもらえるキャラ導石でもかなり助かるんですけどね。

半導体不足が叫ばれ、これ以上メモリの価格が上がってしまうのも困るのでDDR4なメモリを発注してみました。2年くらい前に買ったB250 MINING EXPERTで使うためのものですが、一体いつになったらマシンが完成するのかは全く分かりません。

とりあえず、メモリが届いたらケースに組み付けてmemtest86くらいは動かそうと考えていますが…って、電源あったっけ？55.00kg(20:30)

2.4GHz帯のLoRaモジュールであるEBYTE E28-2G4M12S、そろそろMassDuino UNO LCに繋げようかなということで作業してました。

ところが今更気付いたのですが、Arduino系のボードってプロトタイプシールド（プロトシールド）なんて名前の専用基板が作られて売られているだけあって、その辺にあるユニバーサル基板をシールドとして使えるようにはなっていないんですね。まさかサンハヤトまで専用基板を出していたとは…

という訳で、aitendoのプロトタイプシールド基板[UBD-ARD53X68-HL2]を発注し、届くまで作業は止めることにしました。E28-2G4M12Sはピッチを変換してピンヘッダを付けたのでブレッドボードを使用すればすぐにでも動かせそうだと日記を書きながら気が付いたのですが、慌ててやる必要は無いかなということで手を休めることにします。

今悩んでいるのが、E28-2G4M12Sを昨年作ったPM1280搭載基板のように取り外し可能にするかどうか、という点です。壊した場合の対応が容易になる反面、サイズが大きくなるのと配線が長くなる点で直付けにしちゃおうかなーという気分ではあるのですが…どうしましょうかね。54.25kg(21:30)

いわゆるV2V(Virtual to Virtual)ってやつなんですが。

virtio等の支援を受けられないのでパフォーマンスはそれなりなのと、拙作のvmxscreenを組み込んだ状態での話なのですが、qemu-system-i386 -enable-kvm -boot c -drive file=brightv-vm.vmdk,format=vmdk -rtc base=localtime -net nic,model=pcnet -net user -serial stdio -vga stdな構成で一応動きます。

いつの間にi82550(Intel PRO/100), rtl8139(Realtek RTL8139), tulip(digital 21142/21143), pcnet(AMD Am79C970A)のネットワークアダプタをQEMUがエミュレーションできるようになったのかは知りませんが、VMWare Playerと同じpcnetを使うのが一番安心でしょう。それ以外のアダプタでも動いてはいるみたいですが…

とはいえVMware Player上でできていたことのうち、ホストOSとクリップボードの共有や全画面表示/仮想ディスクの圧縮ができません。時刻は-rtc base=localtimeを付けないとRTCの設定値をそのまま拾ってきてしまうようです。

今のところ問題は無さそうですが、VMware互換部分の動作に難があった場合は-machine vmport=offを追加することで機能を殺すことはできるようです（とはいえホスト〜ゲスト間のマウスポインタのシームレスな動作もできなくなってしまうのが辛い）。ちょっと納得できないのは-vga vmwareを指定すると何故かvmxscreenが動かないことで、これは-vga stdでBochs BGAを使うなり素直にシステム標準のscreenドライバを使うしかなさそうです。

折角なのでQXLデバイスへの対応を試してみました。しかし、何をどうやっても全然動いてくれないのでしばらく放っておくことにします。ROM regionに定義された解像度/色数のインデックスをQXL_IO_SET_MODEで指定すれば使えそうに見えるものの、好き勝手な解像度を使う場合はこれの代わりにQXL_IO_CREATE_PRIMARYでsurfaceを作る必要があるようです。ところが、実際にsurfaceを作って描画してみても表示されないんですよね…何かを間違えているのは確かとして、二週間ほど格闘しても何を間違えているのかが分かりません。

OpenBSD標準のftpdだとNLST -LFの動作ができないので、超漢字のファイル変換小物でファイル一覧が全く取れないという問題があったりします。

仕方がないので他のftpdを色々試してみたのですが…どうもvsFTPdくらいしか選択肢は無さそうです。pkg_add vsftpdして、どうせ自分しか使わないので/etc/vsftpd.confにwrite_enable=YESとchroot_list_enable=NOを設定。

あと、/etc/motdがやたらと長いと開発用コンソールのfgetがうまく動作しないのでこれも適当に編集しておきます。

…という訳で、進捗ダメです。54.00kg(21:50)

19-May-2021補足：vmxscreenがQEMUのVMware SVGA IIで動作しない件ですが、いくつかの要因が絡んでいるようです。

• regCONFIG=1とし、FIFOは有効にしないといけない
• regENABLE=1はregCONFIG=1の後に設定する必要がある
• regFIFOSIZE_MINは0x00010000に修正する必要あり（VMwareの戻り値がこの値になっている）

これらへの対応を行い、QEMUの起動オプションを-vga stdや-vga vmwareではなく-device vmware-svga,vgamem_mb=32を使うとなんとなく描画するようになるものの、動くとは言えないレベルです…素直に-vga stdを使うことをお勧めします。

残念なことにロールバックを伴うトラブルが発生してしまったようで、ルビー500個に加えて10連×10回が無料という状態になっています。富を授けし者第1章のデベッキオ戦でぶん投げたまま半月以上放置している（部下を盾にしてくれるおかげで全然デベッキオにダメージが入らず、しかも倒しても倒しても部下を呼び出してくれるので心が折れた）身には「おいおいそこまで大盤振る舞いして運営は大丈夫か？」とも思うのですが、頂けるものは頂いて使うことにしました。

…で、こんな感じ。

★5

ギルデロイ(槍), ハンイット(弓), ニコラ(短剣), トレサ(槍), ドロテア(槍), ティキレン(剣), リュミス(斧), グロッサム(扇), ステッド(杖), サイラス(本), ヴァルカン(本), アデル(短剣), イデア(剣), リトゥ(短剣)

★4

ブリジット(杖)

本来なら売り物のはずのアニエス(杖)については複雑な気分ですが…初期実装64人における★5の一人であるソフィア(本)がやっと来ました。残すはギルデロイだけ。★4勢もレヴァン(杖)がやって来て残すはブリジットのみ。そういえばライオネルも来ていますね…

★5なのに★4（★4.5と呼ばれる者）

リネット(扇), テレーズ(本), カージェス(弓), ライオネル(剣)

とはいえあれだけガチャ回しても既に居る★4.5については★5を引けない、というのが何とも。その割にスケアクロウ(弓)やテオ(斧)は今回★5で引いていたりするのですが…権力キャラ★5登場時の演出を見てリネット来る？来る？？テオでしたー！には流石に「お前は呼んでねえ💢」という気分になりますね。

当然といえば当然なのですが、キャラクタが増えれば増えるほど狙いのキャラクタを引ける確率は下がりますので、初期実装だけは揃えたいとなるとサービス開始時に完成させ、新キャラ登場時はその時点で確実に取らないとダメなのでしょう。また、10連でも内容が★3と★3.5だけだったというのもあったので、10連だからといって★4〜5が出やすいということは無いように見えます。54.35kg(05:05)

エルヴィスだけ加入させてイデア/アデルは見送り。流石に10連前提なんてやられてしまったら手の出しようが無い…エルヴィス抜きも考えたのだけど、★5まで化ける可能性のある学者(本)な上に「導きの下に」功績には抗えなかった。

★5

ギルデロイ(槍), ソフィア(本), ハンイット(弓), ニコラ(短剣), トレサ(槍), ライオネル(剣), ドロテア(槍), ティキレン(剣), リュミス(斧), グロッサム(扇), ステッド(杖), サイラス(本), ヴァルカン(本), アデル(短剣), イデア(剣)

★4

レヴァン(本), ブリジット(杖)

チェルナ(槍)★4が来たのですが、なかなかブリジット来ません。レヴァンも。

授けし者編は頓挫しているので、引き続きログインボーナス(?)だけもらって寝る生活です。そろそろ真面目に討伐とかやらないと駄目ですかねー…54.45kg(07:30)

そこそこの性能を持つDebian11マシンが手に入ったので、とりあえずQEMU上にNetBSDな仮想マシンを構築しておけば遅くてもなんか使えるでしょと試してみました…が。今使っているSSD搭載なWindows10マシン(Athlon X4 845)上のVMware Player上のNetBSD仮想マシンよりもなんかきびきび動く気がします。

NetBSD-currentのsrc.tar.gzをtar zxpfで展開するだけという雑なベンチマークを取ってみると、

Pentium E6700/Seagate Barracuda 7200.12(HDD)/Debian11/QEMU-5.2.0(virtio-blk, KVM)

100秒くらい

Athlon X4 845/SanDisk SDSSDA-480G-J26(SSD)/Windows10/VMware Player 16(IDE)

200秒くらい

Athlon X4 845/SanDisk SDSSDA-480G-J26(SSD)/Windows10/VMware Player 16(SCSI)

150秒くらい

何の冗談？と思うくらいLinux+QEMU上の仮想マシンの方が速いのです…古いマシンを使っているにも関わらず。今までWindows上の仮想マシンの方がパフォーマンスが良いとばかり思っていたのですが、これは驚きです。

Linux+QEMUの安定性についてはKVMベースの商用VPSサービスが多々ありますし、サーバー屋さん自らが【図解】Linux KVMの仕組みとは？という記事も書いているくらいですので、これは心配する必要はないでしょう。

となると、今後は必要最低限の仮想マシンのみWindows上に残し、パフォーマンスが必要な作業はLinuxベースの仮想環境専用機へ移行した方が良さそうです。DebianもしくはArch Linuxのような汎用的なディストリビューションを使うか、Proxmox VEのような仮想環境の構築に特化したものを使うか、間を取ってAlpine Linuxのような軽量なものを使うか…慎重に考える必要がありそうです。

Big endianな環境、ARM向けというのはNetBSD/evbarmでbig endianな環境を楽しむの影響を受けたからなのですが、もう少し簡単な方法がありました。

Debian上で、crossbuild-essential-mipsやcrossbuild-essential-powerpcといったクロスコンパイラを使ってbig endian向けのバイナリを作成→これをQEMUのユーザーモードエミュレーション(qemu-user-static)で動かす、という方法です。コンパイル時に-staticのオプションが必要だったり、特殊なライブラリをリンクさせる際は面倒なことになりそうですが、ちょっとしたツールの動作確認程度であれば十分使えそうです（これが目的で今まで足掻いていました）。

たとえばepiconで試す場合、CC=mips-linux-gnu-gcc CFLAGS=-static ./configure; makeなんてことをするとMIPS(R3000)向けのバイナリが生成できます。そのまま./epiconで実行すると/usr/libexec/qemu-binfmt/mips-binfmt-Pの力を借りてMIPSバイナリが動きます。QEMUのユーザーモードエミュレーションの利用は昔から言われていた話ですが、今までこれに気付かなかったのは何故…55.35kg(21:25)

06-May-2021補足：Hyper-Vを有効にした状態でVMware Player 16を実行し、NetBSD-currentな仮想マシンを動かして同じような（雑な）ベンチマークを取ってみるとこんな感じです。

Athlon X4 845/SanDisk SDSSDA-480G-J26(SSD)/Windows10/VMware Player 16(IDE):ulm.disableMitigations="TRUE"

415秒くらい

Athlon X4 845/SanDisk SDSSDA-480G-J26(SSD)/Windows10/VMware Player 16(IDE):ulm.disableMitigations="FALSE"

780秒くらい

Athlon X4 845/SanDisk SDSSDA-480G-J26(SSD)/Windows10/VMware Player 16(SCSI):ulm.disableMitigations="TRUE"

345秒くらい

Athlon X4 845/SanDisk SDSSDA-480G-J26(SSD)/Windows10/VMware Player 16(SCSI):ulm.disableMitigations="FALSE"

440秒くらい

ちょっと…これは…

disableMitigations、"TRUE"→サイドチャネルの緩和を無効（パフォーマンス優先）、"FALSE"がサイドチャネルの緩和を有効（セキュリティ優先）という、ちょっとまぎらわしいオプションです。デフォルトは"FALSE"のようで、「サイドチャネルの緩和を有効にして」いる旨がHyper-V有効時に表示されるのを見ると、Hyper-V特有のオプションなのかもしれません。

VMware Playerを使う際は、WSL2（→Hyper-Vや仮想マシンプラットフォーム等のWindowsが備える仮想化支援機能を使用するもの）をなるべく使わない方が良いように思われます。

09-Aug-2021補足：その後しばらく使っていて分かったのですが、AthlonX4 845でVMware Playerを使用すると（いつ頃からかは分からないのですが）OS自体のハングアップやBSoDを起こすことが増えています。仮想マシンプラットフォームを有効にした状態ではこの現象はみられなくなるため、先に書いたことを覆すことになりますが、多少遅くなったとしてもこの機能を無効化しないほうが良いと考えを改めています。

居間のTVに繋げたAthlon64 3000+マシン、気付いたら4年くらいになりそうで、流石にちょっと非力さが目立ってきました。ということで、Pentium Dual-Core E6700なマシンに組み替え。このマシンも以前(18-Dec-2010〜11-Feb-2013)使っていたものです。

OSは以前Debian10/Raspberry Pi Desktopを使っていたのでどうしようか悩んだ末、テスト版ではありますが安定していると感じたDebian11を入れました。OS側の問題というよりは使用しているマザーボード(Intel DG41TY)の問題なのでしょうか、音が出なくて困っています。おそらくsda-hda-intelにoptionsで何か適当なmodelを教えてやれば良さそうですが…HD-Audio-Models.txtを見るにALC888では大量の選択肢の中から適切なものを探さないといけないので適当なUSBオーディオアダプタでもつなげた方が楽そうだと諦めています。

子供が遊びたいと言っていたのでこのマシンでイケるかなー？と突っ込んだMINECRAFT:JAVA EDITION無料試遊版は、流石に重くてゲームになりません。オークションで出ていたRADEON HD5450の512MB物を駄目元で試してみようと考えていますが、こちらも厳しい気がします（でも試す）。

そもそもこのマシンの組み替えはARM向けのBigEndianなNetBSD環境を構築する→build.shをひたすら繰り返す→計算機資源の増強が必要になったという、本来の目的から横に逸れた結果で発生しています。本来の目的については、kernel=RPIのevbearmv6hf-el, evbearmv6hf-ebとkernel=GENERICのevbearmv7hf-el, evbearmv7hf-ebのビルドを終えただけという状況で、動作テストができていないという…

とりあえずそこそこの性能を持つDebian11マシンが手に入ったということで、VMware Player上のDebian11なマシンは削除しました。ついでにRaspberry Pi Desktopな仮想マシンも潰して、Arch Linuxに一本化しています。Slackwareも以前はあったのですが、14.2→current化した際に何か操作を間違えたのか不調になったのでその際に捨てました。

これでホストとなるWindows10機のSSD使用率が60%くらいまでに改善したものの、480GBのドライブではやっぱり手狭なので次にマシンを組むときは1T近辺の物を使うことにしましょう。計算機資源の増強については、未だに転がっているだけのB250 MINING EXPERTとかPentium G4600とかを使ってそろそろ一台組みたいところですが、OSに何を載せるかを考えると頭が痛いです。無償版のVMware ESXiを使って、何でも載るようにしておくのが良いのでしょうか…？54.75kg(06:25)

07-May-2021補足：RADEON HD 5450の512MB物を追加してみましたが、MINECRAFTはチップセット(G41)よりはまだマトモに動くけどこれで遊べるかと聞かれると首を傾げたくなる感じです。やはり最低動作環境(AMD A8-7600/Intel Core i3-3210)程度は満たさないと駄目そうです。ある程度の性能を持つGPUはともかく、CPUのコア数が（論理コアでも良いので）4つという点が肝要という気がします。

音の出ない問題については、Radeon HD 4200をGNU/LinuxでHDMI接続した際の音声出力に関するメモ(前半)が参考になりました。HDMI(DVI)上に音声が乗っているが無音→この状態だとテレビ(SONY KDL-32EX550)はアナログ音声入力ではなくHDMI側を優先させる→Intel HDAがどう頑張ろうとも音が出ない、という理由でした。

Linuxのカーネルオプションにradeon.audio=1を追加せずとも、単純にxrandr --output DVI-0 --set audio offで音がアナログ音声入力側の音が出るようになりました。なお、G41側のDVIコネクタを使用した場合については未テストです。

10-Oct-2021補足：毎回コマンドを実行するのも面倒になってきたので、echo "xrandr --output DVI-0 --set audio off" > /etc/X11/Xsession.d/51disable-dvi-audioとでもして、Xorg起動後に実行してもらうようにしました。