◎ あけおめ。

◎ [XM6改] XM6 復習ちう。 つーか memory.cpp って、I/O デバイスでない いわゆる主記憶および ROM のデバイスとしてのコンポーネントと、 CPU から見たメモリ空間全体というコンポーネントとが混在してる気がする。 Memory::MakeContext() はメモリ空間全体についての操作だが、 Memory::ReadWord() とかはその MakeContext() が作ったテーブルを 参照した結果 Memory デバイスが担当してる空間を読み出すルーチンの ような気がするが、なぜか (他のデバイスの ReadWord() メソッドがそれぞれ自分の担当する 空間しか読み出せないのに対して) Memory::ReadWord() は I/O 空間も含めた全メモリ空間が読めるので 話がややこしい。 さらに全メモリ空間が読めるわりに、ここにスーパーバイザ保護は 実装されておらず、スーパーバイザ保護は STARSCREAM_DATAREGION で 実現しているので、ここが今回のトラップ。

StarScream のメモリアクセス(例えばワード読み込み) は、 star.c の gen_readbw() で生成されるアセンブラルーチンの readmemoryword が担当している。これは超ざっくり書くとこんな感じ。

readmemoryword(addr)
{
   addr &= 0x00ffffff;
   if ((addr & 1))
       アドレスエラー;

   STARSCREAM_DATAREGION readword = (SR.S) ? s_readword : u_readword;
   for (; readword.lowaddr != -1; readword++) {
       if (readword.lowaddr <= addr <= readword.highaddr) {
           if (readword.memorycall == NULL) {
               // 直接参照
               return *(readword.offset + (addr - readword.lowaddr));
           } else {
               // 関数コール
               return readword.memorycall(addr);
           }
       }
   }
   // 見付からなければバスエラー
}

で、STARSCREAM_DATAREGION の s_readword (スーパバイザ空間ワード読み込み) と u_readword (ユーザ空間ワード読み込み) を ダンプ表示してみるとこうなっている。 このテーブルを作っているのが Memory::MakeContext()。 s_readword[0]〜[3] は主記憶と ROM。 s_readword[4] が I/O 空間で、 ここを担当するのが core_asm.asm の ReadWordC (このダンプでいう 0x80985cc)。 こいつはアセンブラで書かれていて、指定されたアドレスから テーブル (core_asm.asm::MemDecodeData) を引いて 担当するデバイスクラスの ReadWord() をコールする。 ついでにこいつは一見 I/O 空間担当のようだが 0x000000〜0xc00000 を渡すとちゃんと(?) Memory::ReadWord() をコールする。 というかメモリ空間担当のように見える Memory::ReadWord() も I/O 空間を指定してもちゃんと(?) 各 I/O デバイスの ReadWord() をコールする。 ええっと、なんでこんなことになってるんだろうな、ややこしいな。 ちなみに ReadErrC はバスエラーを発生させるルーチン。

s_readword[0] = { 000000-bfffff, offset=0xb417000, memorycall=0x0 }
s_readword[1] = { f00000-fbffff, offset=0x9fe4000, memorycall=0x0 }
s_readword[2] = { fe0000-ffffff, offset=0x9fc4000, memorycall=0x0 }
s_readword[3] = { fc0000-fdffff, offset=0x9fc4000, memorycall=0x0 }
s_readword[4] = { c00000-efffff, offset=0x0, memorycall=0x80985cc(ReadWordC) }
s_readword[5] = { ffffffff-ffffffff, offset=0x0, memorycall=0x0 }

u_readword[0] = { 002000-bfffff, offset=0xb419000, memorycall=0x0 }
u_readword[1] = { 000000-001fff, offset=0x0, memorycall=0x80b3d40(ReadErrC)  }
u_readword[2] = { c00000-ebffff, offset=0x0, memorycall=0x80b3d40(ReadErrC)  }
u_readword[3] = { ec0000-ecffff, offset=0x0, memorycall=0x80985cc(ReadWordC) }
u_readword[4] = { ed0000-ffffff, offset=0x0, memorycall=0x80b3d40(ReadErrC)  }
u_readword[5] = { ffffffff-ffffffff, offset=0x0, memorycall=0x0 }

で、本題に戻って、 この s_readword と u_readword の違いがスーパバイザ保護なので、 一見すると Memory::ReadWord() でも ReadWordC でも全メモリ空間が読み出せるにも関わらず、 CPU から見たメモリアクセスは 必ず star.c の readmemoryword の通りに実装しないといけない、と。 スマンカッタ。

◎ [XM6改] で、ようやく昨日からの SEGV の原因発見。 そこではなくて、memorycall == NULL の場合、 データ空間は .offset + (addr - .lowaddr) で、 プログラム空間は .offset + addr らしい。 なぜ統一しなかったのかと小一時間…。 これどんなトラップなんだよorz。 で、次はメモリ空間アクセスが C やアセンブラルーチンを通過する ようになったので C++ で throw したところがお亡くなりになる。 あれ、本家 XM6 の ReadErrC、WriteErrC (アセンブラルーチン) っていらない気がするな。 うむ、これで UAE 68000 でもアドレスエラーもスーパーバイザ保護の バスエラーも出来たっぽい。 やっと昨日の状態まで戻ってこれたので、 68030 でのダイナミックバスサイジングもいんちき実装してみる。

◎ [XM6改] [NetBSD/x68k] 昨日飛ばしすぎたのか今日は体調悪め。 今日は UAE の読みづらい例外処理をきれいに分解掃除。 あのコードのまま読める人は頭がいいのか、 もっとましなコードに出来ないのが頭が悪いのかよく分からん。 それはさておき、 そろそろ俺様 XM6 に NetBSD のインストールフロッピーを突っ込んでみる。 素の XM6 に NetBSD/x68k のインストールフロッピーを入れても 「エラーが発生しました」になるだけだけど、 俺様 XM68030 だとフロッピー上の /boot までは辿り着く。 ただし多分 XM6 が 2HC フロッピーイメージをサポートしていないため、 カーネルの読み込み途中で失敗する。 いんちき 2HC サポートを実装してみたら、 もう少し長く読み込むようにはなったけど成功しなかった。 さてどこらへんだろう。 というか逆に NetBSD のインストールフロッピーを (X68000 の) 2HD 形式で作ったんじゃだめなんだっけ。

◎ [XM6改] [NetBSD/x68k] ところで、「エラーが発生しました」はどこで出るんだろうと思って、 エミュレータ使ってステップ実行してみた。 sys/arch/x68k/stand/boot/srt0.S の start0 の2命令目の LEA が 020 以降の拡張アドレッシングを使っているので、 68000 では PC がずれてしまい、さようならということらしい (次の命令が DOS _CHANGE_PR ($FFFF) になる)。へー。

◎ 去年作ったコーヒータイマー第二弾の 昇圧回路がお亡くなりになったっぽい。

◎ [NetBSDとか] ずっと参照してた自分の日記の値が間違ってたり、 それとは別に NetBSD/x68k 側のインストールフロッピーにも なんかまだ問題がありそうだったり、全部が開発中…。 sys/arch/x68k/stand/libsa/Makefile の USTAR_SECT_PER_CYL の 16 (= 8 * 2) セクタ/シリンダは N=3 (1024バイト/セクタ) の 2HD の値のはずで、 2HC なら (15 * 2) セクタ/シリンダが正しいんじゃないかと思うんだが、 どうしてこれで動作してたんだろう。後で調べる。 2HQ イメージも作ってみたが、どうやら 18 セクタあるうちの 15セクタまでずつしか読んでいないようで、これも読み込みに失敗する。 これは NetBSD のブートローダがカーネルを読み込むところの制約かな。 よく分からんが。 てことで 2HC のままで挑戦。 NetBSD のフロッピーイメージは必要最小のセクタサイズで出来上がるが、 XM6 はイメージファイルの大きさによってフロッピーのメディアを 決定しているので (まあ当り前だわな)、 このまま XM6 に突っ込んではいけない。 気付くのに随分かかったよ orz。 XM6 にももうちょっと分かりやすいエラーを吐かせたほうがいいか。 ということで 2麻衣目の sysinst2.fs は dd とかで 1228800 バイトに揃えるよろし。

◎ [XM6改] うひょー、カーネル、キタキタキタ━━━━(゜∀゜)━━━━!!。 でも一瞬見えただけで即 panic、再起動。 そしてまだ実装してない PTEST を踏んだ形跡。

◎ [XM6改] どっちが先かとか分からんけどとりあえず現象の確認。 何をしてるところかまだ見てないけどアドレス変換した結果、 GVRAM らしいアドレスへのアクセスがバスエラーになったっぽい。 ここまででもすでに突っ込みどころが多い気がするが。 で、バスエラーハンドラの中で SSW を入念になめ回しているので もうちょっとちゃんとエミュレーションしないといけなさそう。 さらに例外スタックは UAE MMU パッチや Aranym と同様に 適当に 0 を詰め合わせているのだが、 スタックのどれかを取り出して PTEST に掛けている。 PTEST はいんちき実装してみたものの、 当然 0番地を PTEST しても結果は思わしくないわけで、 それで MMU fault の panic に至ったらしい。 さて、どっから行こうか。orz

◎ [Perfume] かしゆか、毎日ブログ更新プロジェクトらしい。 忙しいだろうから毎日とまでは言わないが、まめには更新してほしいところ。 そんな中、PTA から年賀状が届いた。 オフィシャルの年賀状が4日に届くって…。

◎ 最近眠りが浅いのか、連日明け方のお年寄りの独り言で目が覚めるのが ボディブローのように効いてきて、今日はノックアウト。 朝から夕方まで爆睡。

◎ [XM6改] MMU 続き。例外スタックを少しだけちゃんとしたので、 panic の理由が MMU fault から Bus error に変わった。 でも、それ以前にバスエラーが起きること自体がおかしげ。 ページテーブル (変換ツリー) をメモリダンプしてみると pmap_bootstrap の作ったテーブルの値が変な気もして、 こうなると例外処理でも MMU でもないそれ以前の問題のような。 とりあえず、やっとこさ MMU の動作もわりと分かったことだし、 pmap_bootstrap.c でも読んでみるべか。

◎ [XM6改] XM6 + 68030。 昨日二人がかりで pmap_bootstrap() の C のソースコードを片手に CPU デバッガで全部ステップ実行してみたけど、 pmap_bootstrap() の作るテーブルは間違ってはなさそう。知らんけど。 で、それは間違ってないとして、 panic の原因が uvm_pagefree() が3回くらい呼ばれたところで リストっぽいパラメータがあさっての方向を指していることなのは分かった。 ただ、その要因が MMU 部なのか命令の解釈実行部なのかがまだ分からん。

◎ ナイナイのオールナイトニッポン。 10年弱ぶりに聞いてるわけだが、相変わらず新年一発目の放送は、 岡村さんが正月に大阪に帰省した時の土産話。 10年前も毎年聞いてたけど、10年ぶりに聞いてもまったく違和感がない。 なんやろうね、これ。

◎ 「平野綾だけTV」 #10。 ナレーションの松尾翠タンが喋ってる時間のほうが長いような気がしてきたのだぞ。

◎ [航空] コンタクト、東京コントロール、ワンスリースリーデシマルエイト (133.8)。 広島アプローチ(?)あたりから (たぶん東に向かう機が?) 次にハンドオフする先、 だと思う。よう知らんけど。 133.8 は「東京コントロール近畿西セクタ」の周波数らしいんだけど、 「東京コントロール」の「近畿」の「西」てあーた、 それ東京やない、もはや中国地方や、と聞くたびにいつも思ってしまう。

◎ [XM6改] [NetBSD/x68k] あれ、NetBSD/x68k カーネルってば MMU イネーブルにした後で PFLUSHA 実行してるけど、順番逆くね?。 x68k の場合 IPL が MMU 動かした時のエントリが ATC に残ってるはずで、 イネーブルにしてから PFLUSHA までの間にたまたま 0x200000 番地台を触るとか すると即死のはずだけど?。 と思ってわざと locore.s の MMU イネーブルした直後で 0x200000 番地を読み書きしてみたら、案の定バスエラーになって エミュレータは二重バスフォールトで停止した。 実機も (二重バスフォールトかどうかは外からは分からないが) 見た目は XM6 と同じになった。 これ、MMU を ATC ごとを実装しないと再現しないバグだけど、 これがちゃんと再現するよー、かかってこいや(何、ってことでよい?

◎ [XM6改] XM6。今日はデバッグ環境の整備。 メモリダンプに論理アドレスを指定しても MMU に従って 正しく物理アドレスに変換してダンプしてくれて超強力とか。 あと、フロッピーを読み込んでカーネルを起動するまでの時間が長すぎるので 本家 XM6 にある VM 高速モードを実装。これで随分デバッグが楽になると思う。

◎ [XM6改] 巷で密かに期待されてる俺様専用 XM68030 は、 あまりに俺様専用にしすぎてて、 人に見せれるレベルにまで整備するのはちょっと気が遠くなる感じ。 でも MMU も煮詰まってきたし、ちょっとやってみるべか。

◎ [お天気] 今日も積雪は3cm程度ながら道路は昨日以上に凍結。

◎ [RD] 東芝がブルーレイ対応のレコーダを発売するらしい。 意外と早かったな。 これでブルーレイも選択肢には入るか。 どっちにしろ来年までにはアナログレコーダを買い換えないといけないからな。

◎ [アニメとか] 永井さんの液晶ディスプレイ購入レポがぽきゅーん☆なのが 突っ込まずにはいられない私はもうだめですかね。 しかし、あのアニメ、ぽきゅーん？はい、いいえ、だったら「はい」 なんだけど、面白いですか？はい、いいえ、だったら「いいえ」かなあ。 (ぽきゅーんって言いたいだけ)

◎ [XM6改] [NetBSD/x68k] XM6 で NetBSD。GENERIC カーネルは spc (SCSI コントローラ) あたりで 死ぬらしい。SCSI コントローラに書き込もうと spc が用意した バッファがあさっての番地なのでそれで死ぬっぽい、 というあたりまでは分かったけど、誰がそのあさっての値を用意したのか 逆に戻りながら探すのが大変。デバッガにスタックトレースがほすぃ。 で、これはちょっと気が遠くなるので目先を変えて、 spc を抜いたインストールフロッピーを突っ込んでみた。 スーパーバイザ状態で SFC=1 の空間 (ユーザ空間) からの MOVES でバスエラーが出たけど、 例外スタックに積む SSW は、例外処理の中でステータスレジスタの S から FC2 を再構成してるから MOVES 以外ではたぶん常に正しいはずだけど、 MOVES では正しくないね。 うーむ、バスエラーの発生した MMU から一回 XM6 の CPU を通って UAE の例外処理ルーチンまで延々 FC 入りのオブジェクトを 持ち回らないといけないのかな。 あ、それ以前に現在の FC とは違うメモリ空間へのアクセス関数も用意しないと いけないのか。うひょー。 というか MMU に気を取られてて気付かなかったけど、UAE って GPL だね orz。 結局 MMU はフルスクラッチしたから UAE である必要はなかったような…。

◎ [XM6改] [NetBSD/x68k] XM6 で NetBSD。何が効いたのか分からんけど、spc は通過した模様。 そして NetBSD カーネルってアイドルで割り込み待つのに STOP 命令使ってるのな。 UAE の STOP 命令は割り込み上がるまで while ループで待ってるけど、 XM6 は CPU と VM とが時分割多重で動いているので、 これでは VM に制御が戻らなくて割り込みが上がらない。 そこを直すと spc 入りカーネルでも MOVES までは到達した模様。 で、この MOVES がどこかと言えば、 start_init() で最初のプロセス init(8) さんを生成しようと ユーザ空間にアクセスしてるところの模様。 これ、天地創造の6日目くらいかなあ。

◎ [XM6改] それはそうと、UAE はライセンスが GPL で、 XM6 のように他のライセンスのソースコードとの 抱き合わせ配布について考えるのが面倒くさいので (そしてその面倒くさいライセンスの普及に一役買いたくないので)、 せっかくここまで動いたのに CPU コアを MUSASHI に変更中。 GPL 氏んでくれないかな。

◎ [Perfume] Perfume ファンクラブ限定ライブハウストゥワー、当たった ＼(^o^)／。 ファンクラブ限定つってるだけに当たってくれないと困るけど。 発足前夜祭以来だな。 Perfume チケは過去8イベントに対し抽選6勝9敗、その他も含めると計7勝14敗。

◎ [XM6改] XM6+MUSASHI。メモリ、割り込み、バスエラーまで接続完了。 オリジナルの MUSASHI にはバスエラーが実装されてなくて、 3年前は右も左も分からずここで挫折したけど、 今回はさすがに必要な知識はあったらしく何も困ることなく通過。 で、フロッピーブートは出来るけど、SxSI から起動しようとすると Human が COMMAND.X を起動できないようなエラーが出る。 しれーっと VM 内で結果が異なるケースが一番大変なんよね。 どうしたらええんじゃろ、これ。 あー、1回のバスエラーで2回バスエラー処理してるわ。なんでだ?。 あー、MUSASHI は例外処理の所用サイクル数もきっちり加算するのか。 XM6 VM は CPU のバスエラー例外処理で CPU 時間が変わらないことを前提に ロングワードアクセスでのバスエラーをごまかして実装してあるからな。 さて、これどっちに丸めたらいいんだろうか。

◎ [XM6改] XM6+MUSASHI。UAE 版と並べて実行とかもやってみたけど、 いかんせん、SxSI から Human に入ったあたりのどこかで動作が違うって いうくらいしか分からんので特定が困難。 フラグとかの動作にバグがあるんじゃなかろうか…と思って グーグル先生してみたら、 MUSASHI 3.3 という名前のコアはたくさんあるとか、 DIV 命令がバグってる版があるとか、ああそうですか。 ありがとうございました。 うちにある入手経路不明の MUSASHI 3.3 と名乗る 68020 まで サポートしてるコアはクロックテーブルが間違ってる版と判明。 まあこの調子じゃ、フラグ1つ間違えてても不思議じゃないな。 一発で動いた UAE はそこそこの完成度だったのか。 気をとり直して MAME のソースコードをダウンロード。 あれ? MAME の 680x0 コアは 68040 までと 68851/68030 MMU を サポートしてるっぽいな。えーっと??。 調査重要。ああそうですか、すいませんでした。 ソースをチラ見したところ、こっちの手持ちの MUSASHI よりは 幾らか洗練されてる香りがする。 ライセンスは大丈夫っぽいけど、後から読んでみる(←先に読め)。

◎ [XM6改] XM6+MUSASHI 改め XM6+MAME。 68000 はわりと動くところまで来たようだ。 自分の環境の入った SxSI イメージもすんなり起動。 やっぱりあの MUSASHI 3.3 と名乗るコアがバグ入り版だったみたい。 にしても、XM6 の CPU コアの付け変えはもう何回目かしらね。 もう目つむってても付け変えれるよ(嘘。 ただ、 それとは別にいつの頃からかスケジューラが固まる率が高くなってる気がする…。

◎ [XM6改] [X680x0] 68000。特権違反例外とか未実装命令例外で、スタックに積む PC が 次の命令位置なのか現在の命令位置なのかが分からん。 たぶん 68000 のグループ1と2の例外は全部次の命令位置なんだよな? つか MAME の 68000 の F 系未実装命令例外は該当命令位置を渡してるように 見えるんだが…。 って、Human68k の F 系未実装命令例外ハンドラは、 スタックに積まれた PC 位置の命令ワードが $FFxx なら スタック中の戻り番地を +2 してあるから、どっちでも動作するのな。 000 は次命令位置だが 030 は該当命令位置をさしてるはずだからどっちでも動くように ってことかしらん。

◎ [XM6i] 巷で密かに期待されている俺様専用 XM6 いろいろ改造版 (XM68030?) は、 XM6i という名前にしてみますた。 i はイカの塩辛の“い”です(違。 そしてなぜか GTK 版が MacOSX で動いた模様。 すげーな。意味分からん。 ただ、とても人に見せれるには程遠い感じ。

◎ [XM6i] cmake 訳分からん…。 それはさておき、ようやく MAME で 68EC030 モードまで戻ってこれた。 EC030 でも PFLUSHA や PMOVE をそれなりに実装しないと X68030 IPL ROM の MMU 搭載判定ルーチンを通過できないのよね。 てか手持ちのモトローラのドキュメントでは EC030 で PFLUSHA や PMOVE to CRP が動作しそうには読めないんだけど…。

◎ [XM6i] XM6i。MAME で 68030 モード復活。 お、NetBSD のインストールフロッピーは init が起動できないという エラーメッセージでとまった。 UAE/68030 より先に進んだっぽい。

◎ [XM6i] [X680x0] XM6i。てか結局現物合わせ。 データシートには EC030 に TC、CRP、SRP の各レジスタがあるとは書いてないけど、 動作するので、書き込んでも 0 が読み出せるのか、 値は読めるけど動作しないのか、 どっちなのか気になる子ちゃん。 手もとに気軽に起動できる状態の EC030 がないので 誰か試してください。お願いします。→ ec030_1.lzh (1927 bytes)

◎ [NetBSDとか] うげ、FreeBSD 2 か 3 の頃からもうかれこれ10年間愛用してる jvim3 が UTF-8 に対応してた。うひょー。今の今まで知らなんだ…。 それなら XM6i のリポジトリは最初から UTF-8 にしとけばよかったか。