確かに、遭難(distress)という語の定義はあるし遭難に伴う通信停止要求はseelonce distress (QRT distress)の定義もあるけど、遭難呼び出しにおいてはmaydayなんだよな。
https://www.tele.soumu.go.jp/horei/law_honbun/72393000.html

…ほぅ？

（研究発表）遭難通信と緊急通信 緊急事態を "PAN-PAN" で宣言できますか https://www.japa.or.jp/public_data/36th-ATS2014-10-Rev1.pdf (第36回ATSシンポジウム 2014/10/25, page28~)

やっぱ海も空も遭難通信はmaydayでいいんだよな。distressじゃなく。

流石にバッテリーバックアップのSRAMカートリッジというのは…すみませんなんでもないですごめんなさい

漢字の筆順のフォント https://www.nihilist.org.uk/

ワード単位で処理するようなバスインタフェースだとまた事情が変わってくるんじゃないかなあ。

big endianだと厄介な物の例…M32R(32176)のシリアルインタフェースとか？ https://assets.sourcengine.com/datasheets/4b6ec8de-4b42-46e6-8baf-63dab816e41b.pdf (page 415～)

page 427にあるS0TXBレジスタが良い例かなあ。
16bitアクセスする場合のアドレスは確かに0x00800112になるけど、8bitアクセスを認めているのでこの場合は+1して0x00800113でアクセスしないといけない。

まあこういうのは特殊事例なので…

メモリマップドI/Oなデバイスを触る際は、アクセス幅が変わっても書き込み先のアドレスが変わらないという利点がありますよね、little-endian。

big endianの場合はそうはいかない。

libze-devがインストールされてなかったというのがやっぱ敗因か。これは何かにメモしておこう。

$ export _GLIBCXX_USE_CXX11_ABI=1
$ export USE_XPU=1
$ export TORCH_XPU_ARCH_LIST="ats-m150"

まずはこれでいってみるか。USE_KIETO=0は設定しない方向で。

$ gmake triton
python3 -m pip uninstall -y triton
WARNING: Skipping triton as it is not installed.
Looking in indexes: https://download.pytorch.org/whl/nightly/
ERROR: Could not find a version that satisfies the requirement pytorch-triton-xpu==3.2.0+91b14bf559 (from versions: 3.0.0+1b2f15840e, 3.0.0+cc981feba1, 3.1.0+91b14bf559)
ERROR: No matching distribution found for pytorch-triton-xpu==3.2.0+91b14bf559
gmake: *** [Makefile:55: triton] Error 1
$

optionalってんだから無視するか。

TV-NETも分解用にオークションで落としたけど、まだこっちの方がROM引っぺがしてフォント吸出しはやりやすそう（DIPなので）。とはいえ…吸い出してもjiskan16なんだよなあ。ANK領域はなんか特徴あるフォントっぽいけど。

この時間のJSCって120rpm/20msecなのか。他の時間帯は60rpm/45sec。

ファミコン通信アダプタのフォント吸出しはちょっと興味ある。

JRA-PATって確かリコーのフォント入ってたよね

# apt-file search zel_tracing_api.h
libze-dev: /usr/include/level_zero/layers/zel_tracing_api.h
#

これはどこのパッケージから来たものなんだろうか…intel-level-zeroなのか、level-zeroなのか…分からぬ…

いや、インストールされてはいるけど/usr/include/level_zeroであって/opt/intel/oneapiの下じゃない…

メモ：
intel-oneapi-base-toolkit
intel-level-zero-dev
intel-level-zero-gpu-dev
intel-level-zero-gpu-raytracing
intel-for-pytorch-gpu-dev intel-pti-dev
libze1 intel-level-zero-gpu intel-opencl-icd clinfo libze-dev intel-ocloc
level-zero-dev
level-zero
これらを突っ込んでも<level_zero/layers/zel_tracing_api.h>はインストールされない（何故だああああ）

メモ：760×500, 1140×750, 2280×1500

FEP bridge、DOSBox-XによるPC-98x1エミュレーションができるようになった今、見直されても良いのかなあ？という気がする。今まではDOS/V(PC/AT)向けのFEPしか使いようがなかったけど、PC-98x1向けのFEPならDOS/V向けより選択肢があるんじゃないか…って（とはいえEmacs lisp部分のメンテナンスが必要だろうし簡単に動かせるような代物ではなさそう）。

FEP Bridge... #そうじゃない

m68k→PowerPC→x86→Arm（→RISC-V?）と、採用する石をコロコロ変えるし過去のソフトウェア資産も割とあっさり捨てるのでどうもAppleは信用ならん…と考えてしまうんだけど（個人の感想です）。

Windows/Intel(AMD)の、過去の資産に対するこだわりの方が凄いと考えるべきなんだろうあ。

Apple Siliconって元P. A.Semiな人達の力によるものが大きいらしいけど（って今はAppleの中に居るんだろうか）…RISC-V化することがあったとしたら、Apple自らが手掛けるのか（それだけの体力とかありそう）、それとも他の優秀なメーカーを食っちゃうのか、どうするんだろう。

https://www.itmedia.co.jp/news/articles/2008/31/news061_3.html