Category: Debian

DOSBoxメモ (2)

なかなかうまくいっていません．

DOSBox自体は，ARM (32bit/64bit)を含む多くのdistroでインストール可能なことを確認しました．

Manjaro ARM (64bit)で起動したDOSBox

また，DOSBoxにXの飾りをつけたDOSBox-Xというのがあるようで，DOSを動かすことに関してはほとんどDOSBoxと同じですが，インストールするため，Flatpakというパッケージマネージャーのインストールが必要です．これはRaspberry Pi OS (RPiOS)を含むDebianでは問題なくインストールできましたが，Slackware AArch64ではインストールできませんでした．

ただし，昨日は何もメモしないで作っては壊し的な作業をしていたので，記憶違いがあるかもしれません．

DOSを動かす部分が一緒ならDOSBoxで良かろうという結論に達しましたが，そこから先がなかなかうまく行きません．

かつてDosemuで動いていたFreeDOSのサブディレクトリーをDOSBox組み込みのDOSでマウントしてもbootしてくれません．

どうもホスト(Linux)のファイルシステムのサブディレクトリーではNGなのかと思い，それではディスクイメージを仕立てて見ようということになりましたかが，qemu-imgでイメージをこさえてqemu-nbdで/dev/nbd0に接続してああしたりこうしたりしてさんざん仮想マシンのディスクをこさえてきましたが，全くその流儀ではだめなようです．

一旦落ち着いて， “How to create bootable HDD image for DOSbox”で検索してやり直してみます．

後の注: Flatpakを使わないDOSBox-Xのパッケージが用意されているdistroもあります．
“かつて” でなくて先日もDosemuでブート可能なことを確認しました．
今回はいつものqcow2でなくてraw．

Slackware AArch64でSDDM動く

当社調べ

当サイトの情報はすべて「当社調べ」であり，これらの情報を直接的あるいは間接的に利用して直接的・間接的な損害が発生しても，当サイトの保有者および運営者および記事の執筆者は一切の責任を負いません．

V3D instead

これまで，気づいていたことは，同じRaspberry Pi 5 Model B (RPi5)やRaspberry Pi 4 Model B (RPi4)で動かしていても，Slackware ARM/AArch64よりもRaspberry Pi OS (RPiOS)方がデスクトップ環境もアプリも動作がきびきびしているということです．

そして，Slackware ARM (32bit) 15.0やSlackware AArch64 CurrentではSDDMが動かない．

Firmware的な違いとしては，RPiOSではGraphics ProcessorがV3Dなのに対し，Slackware ARM/AAarch64ではllvmpipeであるということです．

そんなものなのかなあと思って使ってきましたが，昨日のことですが，Slackware ARM/AArch64の/boot/config.txtでは，

# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2

なのに対して，RPiOSでは，

# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d-pi5
max_framebuffers=2

となっているのに気が付きました． “-pi5” が必要なのか! ということで，Slackware AArch64にも “-pi5” をつけたところ，ちゃんとKDEのAboutでV3DがGraphics Processorとして使用されていることが確認できました．

同様に，RPi5におけるManjaro ARM(64bit)とRPi4におけるSlackware ARM(32bit) 15.0でもV3DがGraphics Processorになっていることを確認しました．

V3Dだと，Slackware ARM (32bit)およびAArch64でSDDMが動きますし，KDE Plasma DesktopのいくつかのDesktop Effectが利用できるようになります．

そして，Firefoxが付いてないSlackware ARM 15.0のWebブラウザーであるFalconとKonquarorがなんとか耐えられるレスポンスで動くようになりました．

ただし調子に乗ってFalconでhttps://fast.com/を開くとデスクトップが固まります😅

当然ながらRPi4の場合は， 
# Enable DRM VC4 V3D driver 
dtoverlay=vc4-kms-v3d-pi4 
max_framebuffers=2

です．

Enscriptのトラブル(Courierの字抜)の解決策

序

今まで動いていた自作のPerlスクリプトによるQSLカード記入面のデータ出力(enscript入力形式) から，enscript により印刷イメージのPS(PostScript)を生成する手順で，それぞれは動くのですが，出力されたPS形式のファイルをGhostscript付属のps2pdfでPDF化すると，どうしても等幅フォントCourierがひどく文字抜けします．アルファベットに関しては，ざっと見て大文字だけ抜けるのかと思えばそうでもなく小文字も多数抜けています．また数字は “1” 以外全部抜けているようです．

This image has an empty alt attribute; its file name is %E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88-2024-03-17-13.14.45.png

解決策

enscriptに与えるソースファイル内で，フォント名を “Courier”, “Courier-Bold” などから，それぞれ， “Courier-New”, “Courier-New-Bold” などに変更するだけです．

これだけで，enscriptとps2pdfで正しいPDFができます．

This image has an empty alt attribute; its file name is 20240315-good-480x358.png

動作確認できたdistro

  • Slackware ARM (32bit) 15.0
  • Slackware AArch64 current
  • Raspberry Pi OS (64bit) Bookworm
  • Debian AMD64 Bookworm
  • Debian AArch64
  • Manjaro AMD64
  • Manjaro ARM(64bit)

Desktop環境はすべてKDE Plasma Desktopです．PDFの確認はOkularで行っています．

印刷も問題ありません．
Raspberry Pi OSでなく，UEFIブート用の本家Debian．Raspberry Pi OS (64bit)のもとで動く仮想マシン(KVM/QEMU)で稼働．

Debian ARM64をManjaro AMD64 (x86_64)で動かす

そう，Raspberry Pi 5 Model B (RPi5)のKVM/QEMUにて，Debian x86_64を動かしたら，まあ動くには動くけど使い物にはならないという状況でした．

それではx86_64側でARM64のソフトはもう少しましに動かないか試してみました．

x86_64でKVM/QEMUを動かすのは長年Manjaro AMD64でやってきましたから，そこにRPi5のRaspberry Pi OS上で仕立てたDebian ARM64のディスクイメージをコピーして，x86_64をARM64に持ってきたときのようにまじないをかけましたが，動いてくれません．

そこでクリーンインストールをしました．ものすごく時間がかかり，ようやく動くようになりましたが，まあ動くには違いないというレベルです．stressを動かしてCPUの占有率を調べる気にもなりません😥 日本語入力環境まで試していません．

いちおう “About” だけスクリーンショットを撮っておきました．

“Processors” 欄は空白でなく，Cortex-A57をエミュレートしていることがわかります．

RPi5でVM遊び (2) qemu-system-x86がマルチにならない

忍耐の限界を超える，と言いながら，その後も時々怖いもの見たさでDebian x86_64の仮想マシンをRaspberry Pi 5 Model B (RPi5)で動かしています．

先程気がついたのですが，仮想マシン側でCPUを上限の4個に設定し，実際仮想マシンでは4つのthreadをフルに使っていますが，ホストマシンではqemu-system-x86のCPU占有率は100%前後で，1つのコアしか使っていないようです．

このスクリーンショットは，仮想マシンのデスクトップの右端とその下のホストのデスクトップのデスクトップの右端で，どちらのデスクトップにもgkrellmがありCPUの動作状況などを表示しています．

左側の仮想マシンではたしかに割り与えられたCPU4個をほとんどフルに使用していますが（上4つのグラフ），ホスト側では1個のCPUがフルに使われているだけの状況（同じく上4つのグラフがCPU1〜4ですが，このスクリーンショットでは上から2番めだけがフルに稼働しています．使用されるCPUは時々で変わります）です．

もちろんネイティブのARM64の仮想マシンの場合は，仮想マシン側のCPU稼働率がそのままホスト側に反映します．

x86のエミュレーションでもホストの4個のCPUが使われれば，今のおそすぎる状況から4倍速くなることが期待できます．

しかし，ざっとネット検索したところでは解決策どころか，この状況を問題と取り上げている記事も見つかりません．

topで見ても同じです．