さいきんはずっとエミュレーター作ってるます。
Web MIDI に対応しました。
MPU-401 UART モード互換インターフェースのつもりなので、いろんなソフトから MIDI 機器を制御できるはずです。
また、 iPad で Web MIDI に対応したブラウザと Sound Canvas for iOS などがあれば直接鳴らすこともできます。
Mac と無線で繋ぐこともできますが、タイミングが厳しくて雑音になりました(´・ω・｀)
また、とある MIDI プレイヤーがタイマー割り込みの関係でうまく再生できなかったのでタイマーを補正するようにしました。従来より負荷が少し上がってるかもしれません。
テストも書き始めましたが、演算命令のテスト項目が山のようにあってどうやってまとめるか試行錯誤中です:;(∩´﹏`∩);:
IBM PC の BIOS は通常、約 55ms / 18.2Hz ごとにカウントしています。
この数値は一体どこから来てどんな意味があるのでしょうか？
まず、 IBM PC で使われているタイマーIC 8254 PIT の動作クロック入力が約 1193182Hz となっています。
すごく中途半端な値に見えますが、これはよく使われている周波数で部品が入手しやすいらしいです。
この 8254 PIT で設定可能な 16bit の最大値である 65536 を設定してみます。
すると約 55ms (約18.2Hz) の周期でタイマー割り込みが発生するようになります。
さらにこのタイマー割り込みで BIOS データエリアの 40:6C にある WORD 値をインクリメントすると、 16bit の限界である 65536 回カウントしたところでおよそ 3600 秒、つまり1時間になります。
40:6C の値がオーバーフローしたら 40:6E にある WORD 値をインクリメントし、そこが 24 になると 24 時間ということで 40:70 に 1 をセットします。(ここだけなぜかカウンターではなくフラグです。)
なるほどうまくできてますね。
55ms という謎の数字にはこんな意味があったのでした。
WASM で PC エミュレータ作りました☆（ゝω・）vｷｬﾋﾟ
※ 現時点では自作のOSすら起動しません。
すでにいろんなエミュレータが存在しているので今更感あるかもしれないですが、このエミュレーターは WebAssembly を使っているのが大きな特徴です。
もともと Web ブラウザーで動作するPCエミュレーターを探していて、いくつかあることはあるのですが、どれも不満がありました。
筆者は数年前に Web で動作する PC エミュレーターを試作したことがありました。
サーバーサイドで既存のエミュレーターを動作させて WebSocket で入出力だけブラウザ側が担当する実装でした。
クライアントの処理が軽いので軽快に動作しましたが、動作するサーバーの問題があって公開前に開発中止になりました。
クライアント単体で完結できるものとして JavaScript を利用したものがよくありますが、パフォーマンス的に満足できるものはひとつもありませんでした。
WebAssembly の環境も整ってきたので自作するかーということになりました。
技術調査をしていて一点気になっていたことがありました。
一般に GUI 環境では GUI イベントを処理するためのスレッドがあります。
JavaScript の場合は GUI イベントとメインのスクリプトが同じスレッドで動作するので、重たいスクリプト処理が走っていると GUI イベントに素早く反応できずに操作性が悪くなります。かといって GUI イベントのために小刻みに動作を中断するとエミュレーターのパフォーマンスが非常に悪くなります。
こういう場合、重い計算処理は GUI スレッドとは別のスレッドで処理するのが普通です。
JavaScript では Worker という仕組みを使ってマルチスレッドを実現できます。
Worker スレッドで動作するスクリプトは GUI スレッドとは別のスレッドで動作するため、 GUI スレッドは GUI イベントに、エミュレータスレッドはエミュレータ処理にそれぞれ専念することができます。
しかし一方で、エミュレーターは常に処理しているわけではありません。
全力で処理したい時もあるけど、ユーザーの操作待ちなどで休んでる時もあります。
こういう場合、 JavaScript では SharedArrayBuffer と Atomics を使って待ち合わせを行うことができます。
エミュレータースレッドで入力待ちが発生した場合は Atomics.wait を使ってスリープし、 GUI スレッドで入力イベントを受け取ったら Atomics.notify を使ってエミュレータスレッドを起こすことができます。
これで、全力で処理するときは全力で処理し、入力待ちで休んでるときはほとんど CPU を消費しないようになり、ぼくの要求するパフォーマンスを満たすことができるようになりました。
しかし、 SharedArrayBuffer はセキュリティ上の理由により Chrome 以外のほとんどのブラウザーでは無効になっているという悲しいニュースがありました。これを解決するには別の手段を探す必要があるかもしれません。
実装上の問題としては、筆者は過去に 80 系 CPU のような単純なエミュレーターは自作したことあるのですが、 x86 系の本格的なエミュレーターを作るのは初めてでした。
8086 の特徴として多くの汎用命令で ModR/M と呼ばれるエンコーディングが使われています。
しかしこの ModR/M が曲者で、 8086 エミュレーターで一番面倒な場所だと思います。ここだけで１日くらい消費しました。
ModR/M デコーダーを実装して多くの命令が動作するようになりましたが、今度はフラグの動作にハマりました。
OF や CF が実機と結果が異なるのです。
これらのフラグは条件分岐でよく使われるフラグなので正しく実装しないとほとんどのプログラムが動作しません。
自作 VM なら比較命令と条件分岐命令を統合させてフラグの動きを考えないようにできますが、実際の CPU をエミュレーションするので真面目に実装する必要があります。
そんなこんなでとりあえず簡単なタイプライター的動作をする BIOS が動く程度にはなったので公開します:;(∩´﹏`∩);:
フォントエディタにいろいろと不満があったので自作することにしました☆（ゝω・）v
現在は base64 エンコードした ASCII 形式の FONTX2 のみ入出力できます。
オリジナルフォーマットも考えてるけど実現可能性は未知数です。
Electron で作ったので Web でもほとんどの機能が利用できます。
https://nerry.jp/fedit95/src/
iPad でどこでもフォント編集できるぜ(?)
ソースはこちらにあります。
github.com
ある日家にあった Surface 3 で moe を起動してみたら、画面が真っ黒のまま進みませんでした。
現在の moe はウィンドウシステムが起動する前は基本的に何も画面出力しないので何が起こっているのかさっぱりわかりません。
こういう時はどうしたらいいでしょうか？
まずは適当な間隔で画面に進捗がわかるように何かを表示するデバッグコードを配置して実行します。
進捗表示が途中で止まったり期待と違う表示がされたら、その付近に問題があることがわかります。
最初は大雑把に配置し、怪しい関数がわかったらその中に更に配置し、その関数の更に奥に配置し...というのを繰り返してどこで問題が発生しているか突き止めます。
printfデバッグの結果、 SIPI という SMP 初期化時に送信する割り込みに問題があるらしいところまで目星がつきました。
そこで、 SIPI 送信処理をコメントアウトして実行してみるとシングルプロセッサ状態で普通に起動したので SMP の初期化に問題があることは特定できました。
次に、 SIPI の送信方法がおかしいのか、それとも SIPI 受信側に問題があるのか特定するために SIPI 側にデバッグコードを挿入します。
しかし、 SIPI を受け取るハンドラはリアルモードで起動するので、ロングモードで動作する printf 関数はそのままでは動作しませんし、 VRAM はリアルモードからアクセスできないアドレスにあるので何も表示することができません。
そこで、どこまで正常に動くか試すためにまずは SIPI を受け取った直後に無限ループするコードを追加して起動してみます。
moe のスケジューラーは SIPI ハンドラの初期化が終わって割り込みを受け取れるようになったコアにしかスレッドを分配しないので、シングルプロセッサ状態で起動しました。
SIPI を受け取って初期化する処理に問題があることがわかります。
次に、 SIPI ハンドラ内の無限ループの位置をあちこち移動してみます。これを繰り返して起動しなくなった箇所に問題があることがわかります。
最終的に SIPI ハンドラからロングモードに遷移するために EFER MSR に書き込む WRMSR 命令の前後に問題があることがわかりました。
しかし、この WRMSR 命令で EFER を変更しないとロングモードに遷移できません。 WRMSR 命令自体に問題はないように思います。
よくみると EFER に設定する内容がロングモードに遷移するための LME フラグの他に NX ビットを有効にする NXE フラグもセットしています。
NX ビットというのは、ページングに実行禁止属性をつけることで不正な実行を防いでセキュリティを向上させるための仕組みです。
試しに NXE フラグをはずして起動してみると、見事に起動しました。犯人は NXE フラグだったのです！
これを証明するために moe で cpuid の情報が見れるプログラムを実行してみます。
確かに cpuid の NX feature bit は 0 でした。この CPU は NX ビットをサポートしていないということですね。
サポートされていない NXE フラグを EFER に書き込もうとして例外が発生し、ロングモードに遷移前なので例外処理が実装されていなくてそのままトリプルフォルトでシステム停止したということですね。
・・・本当かな？
そもそも同じ型番の Atom を搭載している GPD では普通に NX ビットが使えますし、さいきんの Windows は NX ビットをサポートしていない CPU では起動しないはずです。
ということで、 Windows を起動して cpuid の情報が見れるアプリケーションを実行してみます。
NX サポートしてますね。
意味がわかりません。
釈然としませんでしたが、その日はそれ以上わかりませんでした。
後日、 MSR にこんなフラグがあるという情報をいただきました。
XD bit というのは NX bit の Intel 方言で、実体は同じものです。
このフラグを操作するコードを追加して起動してみると、 cpuid の NX feature bit がセットされた状態で起動して EFER MSR の NXE フラグをセットしても例外が発生することなく動作するようになりました。
地獄のデバッグを経て一連の問題は全て解決しました。
cpuid の feature bits はモデル固定ではありません。 MSR 等を操作すると実行中に変化することがあります。
前回の ACPI 記事が当初の予定より長くなってしまって説明を省略した部分の補足したいと思います。
FADT というのは Fixed ACPI Description Table の略で、 ACPI のもっとも基本的で重要なテーブルのひとつで、電源制御などの多くの情報が記述されています。 ACPI ではこのようなテーブルが他にも多数登場します。
FADT を実際に取得するにはまず RSDP (RSD PTR) という構造体を探します。
RSDP の取得方法は efi_mainの引数の EFI System Tableの中にある ConfigurationTable という配列をスキャンします。
ここには ACPI 以外のファームウェアのテーブルも含まれており ACPI 1.x 系と ACPI 2.x 系でも内容が異なるので、例えば以下のように GUID が一致するかどうか調べながらスキャンします。
なお、 ExitBootServices API を呼び出すと ConfigurationTable の内容は無効になります。ExitBootServices API を呼び出す前に RSDP のポインターを保存しておきましょう。
#define EFI_ACPI_TABLE_GUID \ {0x8868e871,0xe4f1,0x11d3, {0xbc,0x22,0x00,0x80,0xc7,0x3c,0x88,0x81}} void* efi_find_config_table(EFI_SYSTEM_TABLE *st, CONST EFI_GUID* guid) { for (int i = 0; i < st->NumberOfTableEntries; i++) { EFI_CONFIGURATION_TABLE* tab = st->ConfigurationTable + i; if (IsEqualGUID(&tab->VendorGuid, guid)) { return tab->VendorTable; } } return NULL; } EFI_STATUS EFIAPI efi_main(IN EFI_HANDLE image, IN EFI_SYSTEM_TABLE *st) { rsdp = efi_find_config_table(st, &efi_acpi_20_table_guid); }
レガシーBIOSのやり方はここでは省略します。(UEFI の方が簡単です！)
RSDP を取得できたらその中にある RSDT または XSDT のポインターを取得します。 RSDP は以下のような構造になっています。
typedef struct { char signature[8]; uint8_t checksum; char oemid[6]; uint8_t revision; uint32_t rsdtaddr; uint32_t length; uint64_t xsdtaddr; uint8_t checksum2; uint8_t reserved[3]; } __attribute__((packed)) acpi_rsd_ptr_t;
レガシーBIOSの時代はメモリを広範囲にスキャンする必要があったので signature を確認したあと checksum や revision を確認する必要がありましたが、 UEFI では最初から GUID で ACPI のバージョンを特定しているので細かいチェックは省略して構いません。
rsdtaddr が RSDT のアドレス、 xsdtaddr が XSDT のアドレスとなります。
RSDT というのは Root System Description Table の略で、他のテーブルへのポインターの配列が格納された ACPI のすべてのテーブルの起点となるテーブルです。
XSDT は RSDT を64ビットに拡張したもので、以下のような構造になります。
これ以降のほとんどの ACPI テーブルは先頭に Header という共通構造があります。
typedef struct { char signature[4]; uint32_t length; int8_t revision; uint8_t checksum; char oemid[6]; char oem_table_id[8]; uint32_t oem_rev; uint32_t creator_id; uint32_t creator_rev; } __attribute__((packed)) acpi_header_t; typedef struct { acpi_header_t Header; uint64_t Entry[]; } __attribute__((packed)) acpi_xsdt_t;
古い ACPI 1.x の時代は RSDT しかサポートされていませんでしたが、現代の PC は ACPI 2.x になり XSDT をサポートしています。特別な事情がない限り通常は XSDT を使いましょう。
XSDT が見つかったら Entry の中には ACPI Header を持ったテーブルのポインターが並んでいるので、必要なテーブルのシグネチャをチェックしながら探します。
void* acpi_find_table(const char* signature) { for (int i = 0; i < n_entries_xsdt; i++) { acpi_header_t* entry = (acpi_header_t*)xsdt->Entry[i]; if (is_equal_signature(entry->signature, signature)) { return entry; } } return NULL; } fadt = acpi_find_table("FACP");
注意点として Entry の要素数は XSDT では直接定義されておらず、 Header にある Length フィールドからオフセット (36) や要素のサイズ (64bitなので8バイト) を考慮して計算する必要があります。また、 64bit 値の配列ですが直前のヘッダーが 64bit でアラインされていないので注意が必要な場合があります。
なお、 ACPI のテーブルはほとんどが名称とシグネチャが一致しますが、 FADT は歴史的な事情で名称が「FADT」でもシグネチャは「FACP」という異なる名前になるので注意が必要です。
ここまでの手順で FADT が取得できました。
S5 オブジェクトには SLP_TYPx に出力するべき値が格納されたパッケージになっているというのはすでに書いた通りですが、これを AML にすると「08 5F 53 35 5F 12」 という並びから始まるバイト列になります。 ACPI では名前に「_」(0x5F) を詰めて強引に４文字にするルールがあるようです。
FADT にある DSDT というテーブルに格納されている AML から該当するバイト列パターンを検索します。ほとんどのオブジェクトはもっと複雑なツリー構造になっているのでこのような手段でアクセスできるオブジェクトは限られています。
なお、 0x08 と 「_」 (0x5F) の間に「\」(0x5C) が入ることもあるようです。（筆者はまだ見たことないです）
S5 のパースに必要な AML バイトコードは 0x08 (NameOP) 0x12 (PackageOP) 0x00 (ZeroOP) 0x0A (BytePrefix) の４種類です。
いくつかの S5 オブジェクトの例を見てみましょう。
実機では以下のパターンがよく見られるようです。
08 5F 53 35 5F 12 07 04 0A 07 00 00 00
これを展開すると以下のようになります。
08 (NameOP)
5F 53 35 5F (名前 "_S5_")
12 (PackageOP)
07 (以下の長さ)
04 (要素数)
0A (BytePrefix)
07 (値１)
00 (ZeroOP)
00 (ZeroOP)
00 (ZeroOP)オブジェクト名「S5」で { 0x07, 0x00, 0x00, 0x00 } のパッケージということがわかります。
QEMU では以下のような内容になります。
08 5F 53 35 5F 12 06 04 00 00 00 00
これを展開すると以下のようになります。
08 (NameOP)
5F 53 35 5F (名前 "_S5_")
12 (PackageOP)
06 (以下の長さ)
04 (要素数)
00 (ZeroOP)
00 (ZeroOP)
00 (ZeroOP)
00 (ZeroOP)オブジェクト名「S5」で { 0x00, 0x00, 0x00, 0x00 } のパッケージということがわかります。
VirtualBox では以下のような内容になります。
08 5F 53 35 5F 12 06 02 0A 05 0A 05
これを展開すると以下のようになります。
08 (NameOP)
5F 53 35 5F (名前 "_S5_")
12 (PackageOP)
06 (以下の長さ)
02 (要素数)
0A (BytePrefix)
05 (値１)
0A (BytePrefix)
05 (値２)オブジェクト名「S5」で { 0x05, 0x05 } のパッケージということがわかります。
なぜか要素数が２になっています。
このように環境によってたった３ビットの SLP_TYPx の値は異なることがわかります。
たったふたつの OUT 命令にたどり着くまでにはこんなに色々あるのでした。
