微妙に気温が下がった気がする 6 月。 気象庁アメダスによれば東京府中では 20 時時点で気温が 19.2 度、数字上もちょっと冷えてる感じ。
去年、松屋が閉店してカレー屋がオープンしたのは知っていたが、どこか松屋っぽさが漂っていて一度も入ったことがなくて、今日初めて入った。 予想通り、松屋系列だ。 どうやら以前渋谷にあったものが移転してきて、全国でここだけらしい。 食券販売機といい、出てくる食券といい、松屋らしさ全開だし、店内の座席配置も前の松屋のままだ。 さすが、松屋フーズの本社ビルから 100m も離れていないだけのことはある。(関係ない。)
辛さが 3 種類、それぞれ「無料」と書いてあるのがおもしろい。 辛口にしてみたが、そんなに辛くない。 グリコの LEE でいえば 5 辛ってところだ。 ビーフカレーか何かそういうのを食べたが、味自体は悪くはない。 松屋のカレーよりおいしいのではないか。
カレー屋というと、牛丼屋やハンバーガー屋とは違って少し落ち着いて食べるような印象があったが、ここは違う。 座席は少ないがとにかく回転が速い。 辛さを聞かれてから 1 分くらいだったか、あっという間に出てきた。 まるで都市部の立ち食いそばのようだ。 もしかすると松屋の牛めしより早かったりして... さすがにそれはないか?
この近辺では、草の実というカレー屋さんがよかったが閉店してしまった。INDRA というインド料理のカレー屋さんの小さな店もあったが、別フロアでの火災により閉店してしまった。 カレーうどん・カツカレーうどんをやっていた、とよくにといううどん屋さんも閉店してしまった。 線路を越えれば、クラウンというところの田舎カレーっていうのもあったが閉店してしまった。Bam Bou deux 3 丁目という店にカツカレーがあったが閉店してしまった。 ココイチはあるがココイチだ。 最近よく食べるカレーは、福家というトンカツ屋のカツカレー程度である。 これはこれでホテルカレー風の感じでなかなかのうまさである。
そういえば、Android Wear な腕時計 Gear Live は、一泊二日を充電無しで乗り切れた。 といっても、一泊の時に電源を切っておいたが、それだけ。
PCjr の DOS などのディスクイメージは、なんと QEMU でも動作する。 それなら JX (日本語環境) でも動かせるんじゃないの、と思うわけだが、ひとつは signature のチェック内容が違うので動かない。55 aa ではなく、"IBMJ" というキーワードで行われている。
もうひとつは、というかそれがひとつなのかどうかもわからないのだが、INT 17h (プリンター?) のところでメモリーがぶっ壊されてうまく動かない様子。 何これ、BIOS の呼び出し仕様が違うのか? いや、なにやら、JX の BIOS はプリンター用のデータを置くのにセグメント 120h を使うらしいぞ。 確かに制御コード変換などずいぶん特殊な機能を持っているが、まさかこんなところを作業領域にしていたとは。 そして DOS は起動時にプリンターに何かを送信していたんだな。
で、まぁ、INT 17h を乗り切ってもその先が動かない。 意外と差があるんだなぁ... おっと、ビデオ BIOS INT 10h がスタックセグメントに 1a0h を使っているぞ。 すげぇ大丈夫じゃない予感 (笑) INT 10h は単にスキップするわけにはいかないしなぁ。
というわけで、BIOS のインターフェイスは同じでも、メモリーの使い方がだいぶ違うので、DOS を動かすのさえも難しいのかも知れない。 まして、グラフィック画面を扱うソフトに関しては、VRAM がどこから割り当てられるかが違ってくるので、全然動かなくても不思議ではない。 ま、そのために英文モードカートリッジがあったということだ。
なお、オーストラリア版の JX などは、YouTube で見つけた動画を見る限り、BIOS は PCjr に近いものになっているように見えたので、この特殊事情は日本版 JX に限られたものであろう。
C で複数のソースファイルでグローバル変数を共有する場合:
$ cat a.c
int a=100;
$ cat b.c
extern int a;
main(){return a;}
みたいな感じで extern で外部参照を宣言して使うのが普通だが、実は extern はなくても動くという話。 もちろん、この例でいうと a.c がなくても動くようになってしまうけど。
$ cat a.c
int a=100;
$ cat b.c
int a;
main(){return a;}
$ cc a.c b.c
$ ./a.out ;echo $?
100
$ cc b.c
$ ./a.out ;echo $?
0
これは C FAQ 1.7 にも書かれているように、C の文法としては何も間違っていないのだが、長年 extern を当たり前のように使ってきたために、今更こういうのを見せられると、そういえば昔見た何かの C の本にそういうのが書かれていたんだっけなぁ、みたいな、そんなぼんやりした記憶の中であった。 長年っていっても、C をそれなりに使い始めてからまだ 20 年ぐらいだけどね。
ちなみに、ひとつのファイル中で、後のほうで初期値を設定する書き方も可能だ。
$ cat a.c
int a;
main(){return a;}
int a=100;
こうしてみると、どこか関数のプロトタイプ宣言に似ている感じがする。 これも、最初の宣言に extern をつけても OK だ。 そういえば、関数のプロトタイプ宣言にも extern をつけても OK だな。 何の役に立つかと言えば、以下のような初期化をしたければ必要になる、といっても、これも初期化のない宣言はわけて、extern をつけるのがよいか。 いや、そもそも、こんな初期化が必要になる機会はないと思う。
void *q, *p=&q, *q=&p;
なお、ちょっと試してみたところでは、C++ では extern をつけない書き方は許されないようだ。
藤野。3 回乗ってベストタイムは 40.2 秒ぐらい。
10 時過ぎに中央道で藤野へ向かうも、結構混雑していて時間がかかった。 圏央道の合流の先で少しよくなったものの、小仏トンネルを過ぎても引き続き混雑しており、事故もない割には何かの連休のような混雑だ。9km 20 分の表示のところ、バイクの小ささを活かして車線変更しまくって 15 分であった。 適切な渋滞情報であったといえよう。
12 時過ぎに中央道・首都高で秋葉原に向かう。 外苑-三宅坂 JCT の渋滞 2km という表示を見て、ちょっと引っかかる程度かなと思ったが、工事渋滞でひどいことが判明。 途中で諦めて都心環状線の逆回りに入って神田橋、昌平橋経由であきば食堂に寄って昼食。 一方通行の道をぐるぐる回ったので、ドスパラ秋葉原本店横の T-ZONE・ドスパラ跡地が更地になっているのも確認した。 噂によるとここにアパホテルが建つんだってね。 しかし、このあたりは観光地で歩行者が多く車はほとんど通らないので、皆歩行者専用道と勘違いしているかのようで非常に通りにくいのだが、あきば食堂の前の道は歩行者も少なく、異空間にワープしたかのようでいつ来てもおもしろい。
14 時過ぎに首都高で渋谷へ向かう。 首都高は神田橋が近いのかと思っていたが、Google Maps は 5 号線に案内した。 これはこれでわかりにくい道のりだった。 しかも乗った直後にジャンクションで車線変更が必要ってね。 都心環状線の途中で Google Maps はいつの間にか一般道と勘違いし、渋谷方向へは一般道が併走しているため勘違いが解消されないまま。 渋谷で来週の祭りのボランティアの説明会に参加。 警備担当らしい。 警察・警備員のお手伝いってとこかな?
16 時頃から一般道経由で帰宅。246 号線もかなりの混雑でいまいち、登戸経由より二子玉川経由がいいかと思ってみたがそれもいまいち、新宿出て甲州街道のほうが早かったかなぁ。 いや、首都高に乗ってしまったほうが早かったに違いない。
梅雨入りだとか! 九州はきのう、関東はきょう。 まぁ先週の土日の鹿児島の天気はすでに梅雨っぽかったけど。
JX エミュレーターに PCjr カートリッジのイメージの代わりに本物の PCjr の ROM イメージをそのまま突っ込んでもなんと動くらしいのだが、拙作のエミュレーターは、ソフトウェアから読み取れない CG1 (キャラクタージェネレーター1) の ROM の代わりに CG2 の ROM を代用しているので、そこのところのフォントがちゃんとしていないと文字がちゃんと出ないとか。 そんな話なので、BIOS のフォントを読み取って埋めるプログラムを作ってみた。PCjr の BIOS にフォント読み出しのインターフェイスがあったかどうか、互換性を考えると面倒なので、2 色グラフィック画面に BIOS で文字を表示させて、それを VRAM から読み出すという風に作った。VRAM の構造が 1 行ごとに交互に別のアドレスに飛んでるやつで、そんなんだったっけ。 まぁいい。 そういう作りなので PC 互換機なら何でも動くわけだが、驚いたことに、QEMU や dosemu などの仮想環境で実行しても、実機 (JX) と全く同じデータが得られるのだ。 たった 256 文字とはいえ、もともと IBM の ROM に入っていたものと全く同じものが QEMU やら何やらの BIOS イメージとして世界中に流通しているということみたいだ。 いいのかどうかは知らない。
さて、目の前にある、IBM からの流れをくむであろう Lenovo ThinkPad X201 でフォントの読み取りを試したところ、微妙に異なるデータが出てきた。 スペード、クローバー、音符、クォーテーションなどの記号から数字・アルファベットに至るまで、全体的に細部が異なる文字が多い。 へぇー。
自宅の Windows 10 PC がいつの間にかご機嫌斜めになっていて、スリープ後、数分でなぜか復帰し画面も表示されないまますぐに休止状態に移行するという状態になっていた。 イベントを見ても「システムがスリープ状態になります。」の項目に「スリープの理由: スリープ状態から休止 - 固定タイムアウト」という意味不明なログがあるのみ。 スリープ後に指定時間で休止状態に移行するという、そういう設定項目は確かにあるのだが、その設定はオフのままだ。 再起動しても同じ状態で、理由がわからないままで、休止状態をオフにしよう、と思ったが、GUI で休止状態をオフにできるのは Windows XP あたりまでか?
探すと powercfg コマンドで設定できることがわかったので、それで休止状態をオフにしたところ、謎の復帰挙動はなくなったっぽい。 どうせハイブリッドスリープはオフにしていたはずだし、高速起動にも興味はないので休止状態はオフでよい。
職場で聞こえる不良 HDD らしき不穏な音。 あれこれ自分のマシンからじゃねーかw 幸いカーネルのエラーログがひとつあっただけで SMART にも何も残ってないという状態ではあったが、状況が悪化する前に対処しなければ。
たまたま rsync で気づいたんだけど、ひょっとして -S (--sparse) つけてても、ゼロデータはネットワークを流れるのかね? ひたすら ssh プロセスの CPU 使用率があがってたということはそういうことなのかなぁ。 なんかいまいち。 そして rsync プロトコルにしたら ssh よりも遅くなってますますいまいち。
近所を歩くと結構一戸建ての新築分譲が建っている。 どこかの一戸建てがなくなったと思ったら、土地が半分になって分譲が、どこかのアパートがなくなったと思えば土地が半分になって、そしてどこかの会社の建物が取り壊され始めて、みたいな感じで、意外と変化している。 だいたい 4000 万前後のものが売れ残り、しばらく売れないとちょっと値下げされて、みたいなパターン。 しかしこれ、いくら霊園が近くても東京都内なわけで、場所柄半分以上土地代なのではって感じ。 このあたり中古物件でも 2000 万以上という感じだもんなぁ、駐車スペースがあるような一戸建ては。
カレーが食べられるお店が閉店しまくった話を書いたのは記憶に新しいが、火災で閉店したカレー屋さんがあったところの隣にインドカレー屋ができていた。 そういえば最近チラシ配ってたんだよなー (ぉぃ)。 前に別の飲食店が入っていて何回か入れ替わっていた場所で、そこそこ広いし、カレーは美味しかった。 ナンのついているランチセットはちょっと多いくらいだ。
朝までは降るかもみたいな、曇りの天気予報だったが、Yahoo! の天気情報の実況を見れば、全力で (?) 雨らしいことはわかった。 ひどい雨ではなかったけど、結局、霧雨みたいな感じのやつが昼過ぎまで続いていて、全力で梅雨っぽい。
中央道が集中工事だそうで一般道にも渋滞の影響があるという、京王バスの掲示を見かけて、ふうん。 調べてみたら車線規制かな、それで一般道に迂回する車がどれだけあるかといえば、微妙な気がするけどねぇ。 朝の甲州街道なんて、普段からあまり流れがいいほうではないと思うし。 今日は、おそらく中央道というよりは雨の影響でかなり混雑していた。
JX のフォントは 16x16 でも左端が 1 ドットあいているデザインである。 何となく探してたら東雲フォントの 16 ドットゴシックがちょうど左端が 1 ドットあいているデザインみたいだ。 へぇー。
半角文字はというと、罫線のところは 8x16 めいっぱいで隙間がないが、制御文字を除く JIS X 0201 の部分は左端が 1 ドットあいているように見える。 東雲フォントの 16 ドット版だと ASCII の部分でも 8x16 めいっぱいにデザインされている記号もあるし、アルファベットなどは右端が 1 ドットあいているように見える。 ちょっとデザイン方針が全角文字とは違うのかも知れない。
16 ドットビットマップフォントで好きなデザインは jiskan16 で未だに KTerm のデフォルトとして使っているのだが、コイツは 16x16 めいっぱいのデザインである。 権利関係で SONY がどうのこうのというのを思い出したがそれは 8x16 のほうで、16x16 はどうやら一般的にパブリックドメインと認識されているようである。
なお、フォントのプレビューはこんな強引なコマンドでやってみた:
zcat /usr/share/fonts/X11/misc/shnm8x16r.pcf.gz | dd skip=5 | convert -size 32x4096 -depth 1 gray:- png:- | display -
ibmpcjr rom で検索すると...!?
拙作 JX エミュレーターに PCjr の BIOS で起動するモードを実装してみた。 オーストラリア等で売られたという JX はこういうスタイルだったのかな。JX 用に改変された BIOS を使っていたのか、JX でオプションになっている RS-232C カードが標準装備された上で PCjr の BIOS をそのまま使っていたのか、どうなんだろうか。 あと、PCjr は BASIC カートリッジがあったらしく、DOS から BASIC を立ち上げるにはそれが必要だったらしい。 日本版の JX の英文モードカートリッジは、再起動等の処理に一部変更の加わった PCjr の BIOS と BASIC カートリッジが一緒になったものということのようだ。
あとテキストモードの 16 色がちゃんと出ない & ブリンクしないつくりになっていたのでなおした。 ビデオのところではないが、変な workaround 的なものがノーコメントで混ざっているとか、我ながらいい加減な実装である。 早く何とかしないと。 と、15 年前から思っている。
PCjr では Ctrl-Alt-Insert で再起動をかけるとテストモードみたいなのに入れるらしい。 そういえば JX でも BIOS のコードにそういうような記述があったっけ、JX にはそのテストモードみたいな機能はないんだけど、Ctrl-Alt-Insert でも再起動するようにはなっていた。
原付にしばらくぶりに乗ると、後輪ブレーキを離した時にぺたぺたというような音がする。 ブレーキシューがひっつく? しばらくブレーキを使えばぺたぺたしなくなり、普通になる。 ききが悪いわけでもないし、ドラムブレーキだからそういうこともあるのかな。
前輪ブレーキはだいぶ鳴くが、ドラムブレーキなので仕方が無い。 しばらくぶりに乗ると最初だけいわゆるカックンブレーキと呼ばれる症状が激しいキーキー音とともに極端に出るが、ドラムブレーキなので仕方が無い。 しばらく使ってればだいたい落ち着くけど、もし路面が濡れていたりしたら、どこまでブレーキをかけたらタイヤがロックするのかまったく読めない。 そんな安定性のなさも、ドラムブレーキなので仕方が無い。 原付でも前輪にディスクブレーキを採用している車種も多いが、その理由は自動二輪にも乗る今ならよくわかる。 車重が軽い原付は雑な運転操作でも乗れるけど、前輪ドラムブレーキってのは逆に雑な操作を強要してくるというか、精密な操作をしたくてもディスクブレーキよりも難しい感じ。
JX の ROM カートリッジの仕様を眺めると、ROM のアドレスはピンで指定するようになってるんだな。96KB (96KiB) までで、32KiB ごとのチップが 3 つ載った絵が時代を感じさせる。
試しにテストプログラムを書いた。 前に作ったブートセクターにおさまるゲームを移植。 ふんふん。CRC が必要なのだが一般的な CRC-16-CCITT らしい。 へぇー。
それで作れたはいいが、ゲームオーバーの時の表示がおかしいぞ? あれ? QEMU では期待通りに動いているけど... これは何のバグだ? BIOS の挙動が違うのか? それとも CPU のエミュレーション? ('A`)
そうそう、どうやら ROM カートリッジは D0000h 以降を使うようで、その手前の、C0000h からの部分には拡張カードの BIOS などが置かれて、チェックサムがあっていれば初期化ルーチンが呼び出される仕組みがあるらしい。 あるらしい、っていうか、これって PC/AT 互換機で未だに VGA BIOS などが置かれているのと同じ仕組みじゃないか? そして、JX にも HDD が搭載できたという話を見たことがあるが、それもこの領域を使っていたに違いない。 なるほど納得。 なお、この拡張カードの ROM 部分は、GA-08 とかいう JX ならではのアドレス・デバイスマッピングの仕組みは通らず、メモリーアクセスは直接カードに届く仕掛けのようだ。
いつの間にか、中古購入時からのオドメーター一周、10,000km 走行していた。 ここまで来てもあんまり状態は変わっていないことから、購入時点で一周していた可能性も否定できず、ほんとの走行距離はもはや不明だ。 相変わらずエンジンだけはまだまだいけそうなものだが (スーパーカブと同じエンジンだし)、車体はどうだか。 普通のベルトドライブのスクーターとは違って、ドライブチェーンが伸びるという地味な症状はあっても、ドライブベルトが切れるっていう派手なイベントはないしなぁ。
きのうのやつは移植ミスというか、512 バイトにおさめようとバカなまねをしたせいで困ったが、結局 ROM 上で実行することで何とかなった。
何となく JX のフォント ROM をダンプして眺めていたらロシア文字が範囲外の変なところに紛れ込んでいて本来の位置にないことが発覚。 何だろうと思ったが実際に BIOS で文字出力するとコード変換されてる。 うわー、知らなかったw 文字コード表を見るとロシア文字の後ろのところは大きく間が開いているので、ROM 圧縮の都合だったんだろうな。 何しろ 256KiB のアドレス空間なのに実際の ROM は 128KiB らしいからなw
自宅ノート PC の SSD 容量が少々物足りなく感じられる今日この頃。 まだ買ってから 4 年ちょっとしか経っていないのだが、どうしようかな。 まぁ我慢できないほどではないが。
職場の ThinkPad X200 は冷却ファンが動いたり動かなかったりという状態、Fan error を Esc キーで無視してしばらくファン回ってないまま使ってから電源を入れ直すとか、そのときに本体をどこか押さえつけながらやるとか、電源だけでなくバッテリーの着け直しをするとか、いろいろ工夫するとまた回り出すんだけど、いつか自宅の ThinkPad X201 もこうなるのかなと思うと、あんまりお金かけないほうが良いかなという気がしてくる。 不具合といえば自宅の ThinkPad X201 は時々無線 LAN の接続が切れることがある。
JX エミュレーター用のフォントをフリーフォントから作成する方法を前々から考えていたのだが、重い腰をあげて実装し始めた、ら、丸 1 日かかったw 例によって 8x8 ドットの英語フォントをどうしようかと考えると、やっぱりビデオ BIOS から取得するでしょ、となって、そうすると DOS プログラムってことになる。 日本語・全角フォントは東雲フォントが最適とわかっているから、それを使うことにする。 半角は同じく東雲フォントの 7x14 サイズを使うことに。8x8 ドットの日本語フォントは英語フォントと 7x14 フォントの縮小の合わせ技で。 みたいな感じで方針は決まる。
さて実際の ROM はどうなってんのかな、というと、結構トリッキーだ。JX の内部コード・フォントの配列は基本的に Shift_JIS なのだが、Shift_JIS で漢字が始まるのは 889fh のところからだ。JX は罫線文字などを持たないから、その手前は 8491h のロシア文字で、だいぶ間が開いている。 後ろは第二水準を持たないので 9872h が最後ってことになる。 フォント ROM の領域としては計算上は 9fffh が最後だ。
で、ハードウェア的に圧縮って何だよと思っていたが、まず目立つのは、b0000h からの 64KiB と 90000h からの 64KiB が完全一致ってところだ。 ソフトウェアからこう見えるということは、ハードウェアには片方しか載っていないのは間違いない。 こんなとんでもない事実に今まで気づいていなかった。 ついでに、上に書いた 889fh よりも手前の空き部分に、9840h からの最後の部分が押し込まれていて、これが b0000h からの領域でアクセスされる最後の部分であり、その後ろに第一水準の漢字が再び始まっていても誰も使わないから問題ないということだろう。 そのほかにも 87800h からの 2KiB が 9e000h から (と、当然 be000h から) にも見えているとか、80000h からの 2KiB が a0000h からにも見えているとか、そういう小さな単位での重複も結構ある。 さらに、外字用の SRAM が 88000h からの 2KiB に配置されていることの対策として、8440h からのロシア文字が、8100h からと 8200h からの空きスペースに押し込まれていて、これはソフトウェアで変換されている。
それと、BIOS の挙動からするとチェックサムがあるらしいのだが、これがまたへんてこな形で、最初の 32KiB だけはシンプルなのだが、それ以降は 2KiB ごとにとびとびにチェックサムを計算するっぽい。 あ、あれ? 32KiB + 2KiB * 3 * 16 = 128KiB だ。 なんと、BIOS は ROM にハードウェア的に含まれているところだけのチェックサムをとっていたんだ。 へぇー。 メモリー空間 256KiB のうち、b0000h からの 64KiB と SRAM 用と空き領域の 32KiB を引いて、残りの 32KiB を、Shift_JIS の 2 バイト目で使われない 00h-3fh のところがちょうど 2KiB だから、そこを飛ばすことで減らしたんだな。
で、DOS プログラムで作りやすいのは COM 形式だ。COM 形式はヘッダーがいらないのでそのへんの x86 アセンブラーを適当に使えば簡単に作れる。 でもスタックを含めて 64KiB までにおさめなければならない。 フォントデータだけで 100KiB を超えるわけで、困る。 仕方がないのでフォントデータは別ファイルにすることにして、それを読み込みながらファイルを作るプログラムを書く。 最初はチェックサムを計算しながら作ればいいかと思っていたが、構造上、後から計算しないと厳しい。 そこで BIOS フォントを埋めるのも含めて後からそういう処理は行うようにした。 チェックサムを合わせるだけで一苦労、さらに、半角の制御文字のところにある罫線文字やら何やらを他のデータから生成するコードを書いていたら日が暮れてしまった。
なんか、きのうのニュースで小林麻央が乳ガンで闘病中であることが発表されたとか。 小林麻央・小林麻耶姉妹は、たまたま兄者の影響で見ていた頃のテレビ番組『恋のから騒ぎ』からテレビ出演が始まったふたりで、よく見たら小林麻央のほうは自分と同学年じゃないか、そうだっけ、そうだったかもねぇ。 テレビでしか知らない人ではあるけれども、同い年でガンというとやっぱり大変だろうし、何とか良くなってほしいところではある。
小林麻耶のほうはたぶん、『新チューボーですよ!』の 1000 回記念が去年あった時に、4 代目アシスタントとして登場して、確かそのときだったと思うんだが、妹の家に遊びに行くだとか、甥姪がかわいいだとか、そういう話をしていたような記憶がある。 今にして思えば、あの時すでに妹のガン発覚から半年くらい経っていたことになるわけで、そのことは把握していたに違いないし、遊びに行くというのもむしろ手伝いに行くということだったのかもと。 でも、暗い表情などは全くなかったと思うし、極上空間などのアナウンサー業もついこの前まではやっていたもんなぁ。 家族の心労もすごいだろうな。
小林麻耶は極上空間にゲストとしても出演していたみたいだが 9 月 1 日が土曜日といえば 2012 年だからだいぶ前だな。 縁結び大社とかいってるのなんか記憶にあるけど。
ボランティア担当は明治神宮前駅近くの超わかりにくいところにある建物に 9 時集合。 新宿での私鉄・JR 乗り換えが決まって検索していたものより 1 本早いのに乗れた。 たぶん初めてな気がする原宿駅下車で徒歩で向かってちょうどいい時間。
軍手やら何やらを受け取り、9 時台なのに早くも昼食をとる。 そこから徒歩で会場へ移動し (1.2km)、お祭り本番。 終わったら徒歩で最初の建物に戻り (1.2km)、返却・片づけ等をして、徒歩で渋谷へ移動し (1.2km)、高校の同窓会の連の打ち上げに参加し、帰宅。 帰りは吉祥寺行きの急行待ちの列に並んだらいい感じに座れたので、遠回りして終点まで乗って帰った。
何が疲れたって少なくとも 4km は歩いたってことだよ! 普段そんなに歩かない (たまにせいぜい 1 駅 1.6km 歩くくらい、それを朝晩で往復するのもまれで、それからまた行くなんてことはない) 者にとってはなかなか厳しい移動であった。 一人だったらバスか地下鉄にでも乗っているところw
日焼け対策は、SPF50+ PA+++ な日焼け止めを顔・耳・首・手首あたりに塗ったのと、長袖 T シャツで行ったのと、もらった帽子 (後ろ側メッシュ) をかぶっていたのと、もらった手ぬぐいを帽子に挟んでいたのと、もらった軍手をつけていた程度。 熱中症対策は、もらった飲み物を最初の建物に置き忘れ、まーいいかと思っていたけどさすがに直射日光を受けていたら体調の変化を感じ始め、スマートウォッチで心拍数測定してみたら、ろくに動いていないのに 133 回/分程度の数字が出て、普段よりも高めだと思ったので近くの自販機でジュースを購入した。 また、買ったジュースを脇に挟んで体温を下げようともしたが、その程度。 心拍数が数字ではっきり出るのは、自分が冷静になれるのでよいと思う。
あ、そうそう、打ち上げ会場は渋谷駅からほど近い飲み屋なのに、ドコモは圏外 (高く持ち上げても圏外)、au は使えたらしく、ソフトバンクモバイルは不明、ワイモバイルの PHS は弱いが一応使える (ポケットの中では厳しいが高く持ち上げれば問題なく通信可能) だった。
歩く→問題ない。 外で立ってる→問題ない。 外で座ってる (しゃがんでる)→視線に気をつければ問題ない。 上のほうを見ようとすると、めがねをかけている関係で、首を上に向けてしまいそうになるので注意が必要だ。
飲み会→若干肩こりみたいな症状が現れる。 前回もあった。 後ろの人を見ようとして首だけを回す、ことがないようには気をつけているのにな。 猫背か? 猫背は下を見るならむしろ適しているのだが、猫背で前を見るには首をあげることになり良くない。 というのも気をつけているつもりなんだけどなぁ。 あとは頭の前後位置か、頭だけ前に出すみたいな、そういうことをやっちゃってるのかなぁ。 とにかく日常生活でのちょっとした動作が刺激するので、今後も気をつけねば。 少なくとも刺激を続けて炎症を起こしてしまうのは避けなければと。
朝は完璧に雨だった。
夜はムーバスに乗ってみたら小田急バス運行の車両だった。 案内放送の声が小田急バスだ。 車両は少々くたびれている感じで、すごく早めのシフトアップをする AT が、シフトアップのたびにエンジンの回転数がふわっと上がってからギヤが変わるみたいな動き。MT ならアクセルをゆるめずにシフトアップしているような感じ。 あと今のエルガ AT とは違って後部扉が閉まりきっていなくてもクリープ現象で動き出せるようだ。 へぇー。
これを参考にちょっと作業をしようかなと思ったらこれ SDL2 じゃーん! ってなわけで拙作 JX エミュレーターを SDL2 に移行してみるテスト。 音関係は何も変更無し。 キー入力関係は SDL_KEYDOWN イベントを使うのは同じだが、スキャンコードとキーコードが選べるようになったみたいなのでスキャンコードを使うことにする。 まーエミュレーターでどっちがいいかは善し悪しなのだが、例えば US 配列と JIS 配列でも : の入力にシフトキーを押す必要があるかないかが違うわけで、そして JX は US 配列に JIS 配列のキーを足した特殊配列なわけで、もしシフトキーを押さずに : が押されたときに : の入力をエミュレートするなら、シフトキーを押して : を入力してシフトキーを離すという流れをやらなくちゃならない。 これは面倒なのでスキャンコードにしようかと。
あと SDL_KEYDOWN がキーリピートの時に何度も飛ぶように変更になっている。 リピートかどうかは判定できるようになっているのでそれを見るようにする。
一番やっかいなのは画面出力まわりだ。 テクスチャーがどうのこうのと言ってなんか面倒だ。 アクセラレーションが使えて云々というのだが、こっちが使いたいのは 8 ビットカラーのビットマップ画面をパレットを変えまくりながらがんがん全面更新したいというだけで、基本 CPU 処理になるのはそもそも避けられない状態なのだ。 こういうときどうするのかと思えば SDL_GetWindowSurface() というのを使うといいらしい。 ただしこれに 8 ビットカラーを設定するわけにはいくまい。 そこで別途 SDL_CreateRGBSurface() (RGB とあるが 8 ビットカラーも OK だ)、SDL_AllocPalette()、SDL_SetSurfacePalette() などを用いて裏の作業場所を作っておいて SDL_BlitScaled() で転送する。
ここにトラップがあり SDL_BlitScaled() は 8 ビットカラーではうまく動かないらしい。 そこでもう 1 枚 SDL_CreateRGBSurface() で 32 ビットカラーを用意しておきそこに SDL_BlitSurface() した上で SDL_BlitScaled() を使う。 メモリーコピーしまくってそうなのに余裕で動くのはさすが今時の PC だ。 あと、パレットは直接 colors 配列をいじってもだめみたいで、SDL_SetPaletteColors() を呼ぶとうまくいったからこれもコピーだな。
まぁそんな感じで SDL1→SDL2 はドキュメントがいまいちだが使ってる機能が少ない分作業はそんなに難しくはない。 むしろ 15 年ほど前に書いたとおぼしき自分のクソコードがいろいろと意味不明で笑った。 変数名は意味不明だしアルゴリズムもいい加減だしなんかよく動いてんなこれ、みたいな。 バージョン管理システムも使ってなかった頃のコードで、いろんなところにコメントで古いコードが残っている。 謎なコンストラクターがあると思ったらこれもともと継承していたのをくっつけたかな? だとしたらくっつけたのは 8 年ほど前だとは思うが、みたいな感じでとにかくいろいろと雑でもう。
先月に似た事象、ただし最寄り駅到着時点で、乗り換え先路線の運転見合わせの案内放送が聞こえていた点と、人身事故が快速ではなく緩行線のほうという点は違った。
歩く気力がなかったため乗換駅で数分様子を見る。 しかし運転再開見込みが 30 分後で先が思いやられる。 外でバスを待っていると駅ホームの放送が漏れ聞こえてくる。 先が詰まっているからしばらく動かない見込みというふうなことを案内している。 ふむふむ、バスで正解か?
バスに乗って発車を待っていると、駅ホームから発車メロディーが聞こえ、ドアーが閉まります、が聞こえ、発車していったよおいおい! バスが発車した後にも次の列車が発車していくのが見える始末。 しばらくって 5 分ってことだったのかよー。
まーそんなわけでおそらくいつもならあり得ないレベルの混雑したコミュニティーバスで移動したのであった。 一時停止をすべて徐行で通過していたのはさすが。
きのうの SDL2 移植時に発見したキーボード処理のクソコードを書き直すも手こずっている。 どうも理解しがたい動きをするなと思ってデバッグしていると、最近書き換えた Makefile にミスがあり、必要なコンパイルがされていないことが発覚した。 それをなおしていい感じに動くぞ、と、とあるゲームを試そうとしたら入力がちゃんと処理されていない風で、キーボードを使う、って入力しているのに、ジョイスティックがないみたいだからキーボードを選んでね、とか出てくるのである。 あれれれ。 今までいい加減に手抜きしていたせいで動いていたみたいで...
SDL2 対応が済んだので Windows バイナリーを構築してみたのであった。 MinGW(Msys)でSDLを始めるというサイトを参考に、SDL2 のソースコードをアーカイブでゲットして ./configure --prefix=/path/to/prefix --host=i686-w64-mingw32 して make して make install したら SDL2 の Windows 版のライブラリー構築完了。 どうも --host なのかどうか理解できなかったができてるっぽいからいいや。
で make するんだけど環境変数 PKG_CONFIG_PATH=/path/to/prefix/lib/pkgconfig/ を設定しておくことと、CC=i686-w64-mingw32-gcc と CXX=i686-w64-mingw32-g++\ -mconsole をつける。 リンク時に -mconsole をつけないと GUI アプリになるみたいで、少々強引だが CXX につけてしまった。 拡張子 exe は確か今時はつけなくても動いたと思うけど、わかりにくいのでつけるようにしよう。
そして実行時ライブラリーが必要だ。/path/to/prefix/bin/SDL2.dll はもちろん必要だが、そのほかに libgcc_s_sjlj-1.dll と libstdc++-6.dll というのが必要で、このふたつはどうやらソースコードなしで再配布して良いらしい。 これらは /usr/lib/gcc/i686-w64-mingw32/4.9-win32/ にあるが、/usr/lib/gcc/i686-w64-mingw32/4.9-posix/ にもあるので迷った。 どうやら winpthread なるものを使う場合は posix のほうで、それを使わないなら win32 のほうらしい。 というような説明を Debian/Ubuntuでmingw-w64を用いてWindows向けのプログラムをコンパイルする - kakurasan で読んだ。 大変参考になる。
ってなわけでひさびさに Windows 版を自分でビルドしたので (以前は Cygwin だったかなぁ)、Windows 環境で動かしてみたがいたって普通である。 性能の低い Athlon 5850 でもちゃんと動くんだなと感心した。 なお、おそらく画面サイズがピクセル単位で固定なので今時の高解像度画面な人は涙目になりそうな仕様であるw
ちなみにきのうのキーボードまわりのクソコードであったが、見やすく書き直した。 キーコードの各ビットの送信タイミングの数字に何かごまかしをしていたんじゃないかと思ったが、なんとマニュアルぴったりで、我ながらよくここまで正確にエミュレートできたなと感心するところである。 ゲームが変だったのは、最初の質問に Y と答えた直後の画面切り替えに伴う NMI 禁止時間が長く、Y キーを離したという情報が失われてしまい、その結果ジョイスティックを使うかの質問で Y キーを押したことになってしまっていたようだ。 実用性を考え NMI 禁止時間が一定時間内であればキーコード送信を遅らせるという、実機では絶対にあり得ない機能をつけておいた。 そもそも、高速操作の対策として内部にキーバッファーを持っている時点で実機とは違うのだし、細かいことは気にしないことにしよう。
画面サイズが 10 型前後 (対角線 25cm 前後) のタブレット端末を探していて、うさんくさいメーカー (?) の KALOS2 というのを見つけた。 価格帯は Lenovo のタブレットよりもちょっと高額で、iPad Pro よりは低額。Lenovo のやつもよさそうだが今更 Android 5.1 というのが引っかかる。 だって 3 年以上も前に買った Nexus 10 でさえも今は Android 5.1 なんだよ? わざわざお金を出して古いやつを買うかっての。
安心感でいったら iPad Pro なのだろう。 もう何代目かになるし 2 年くらいは問題なく使えそう。 画面はさらに大きいから、漫画も読みやすそうだ。 欠点は日本語入力だろうな。 画面の大きさは十分だが、JIS かな入力ができないのは頂けない。API は今は公開されているのだから誰か作っていないかと思ったが見つからなかった。
KALOS2 はストレージサイズも余裕があって、そのへんスペック的には良い。USB Type-C というのも時代の先を行く感じで良い。 あと画面がこのサイズなのに有機 EL で、そこも興味深い。 特に YouTube 等の動画鑑賞は、残像が見える Nexus 10 より良いのでは?
スペック上の欠点はバッテリーか。Nexus 10 は 9000mAh だが KALOS2 は 5800mAh しかない。Android のバージョンが新しいし、液晶でもないのでそれほどつらくはないのかも知れないが、他社製と比べるとちょっと見劣りする数字だ。 その代わり軽い。
値上げしたってのは悔しいが、実物を見てみてよさそうだったら買っちゃうつもり。
本田技研工業株主総会。 東京臨海高速鉄道りんかい線経由。 東京テレポート駅から無料送迎バス (一般路線バス車両の貸し切り)。 タカタのエアバッグ問題は引き続き、だけどこれはタカタ側の問題に関してはタカタ側に請求をしているとのことなので、まるまる損失というわけではなさそうだ。 後は無難に (?) 二輪の新型車とか四輪の新型車とか、うん。 ホンダジェットの話があまりにも軽くて質問で突っ込まれていたが、これはやっと数機が顧客のもとに届いたくらいの頃のようで、現段階では赤字。 たくさん売って、しばらく飛んで、部品交換まで来てやっと事業として回るということで長い目で見てくれって。 まぁ小型の航空機なんて、持っていてもどういうふうにお金がかかるのかまるで想像がつかないので、へぇって感じだ。 モータースポーツに関しては突っ込み無し。 役員に F1 担当の人が増えるということでそこだけ。
今回は副社長が交代だったみたいで、前回の社長交代と同様、取締役会で決定するようだった。 展示はアフリカツインと電動カブと、NSX, 燃料電池車など。 電動カブはユニットスイングなんだな。 でもそりゃそうか? まさか電動なのにチェーンドライブってわけにもいかないしな。
また東京テレポートまで戻り、メガウェブ行ってレンタルカート Fun カートライドのところを見に行ったら、平日で空いていそうなのにもかかわらず前回同様またしても 1 時間半待ちなどと言われ、やる気をなくす。 なお、ここは 25 日をもって運営を終了するとのこと。 あと 1 週間ちょっとじゃないか。 乗る機会はなさそうだ。
めしくって新宿行って迷いながらビックカメラにたどり着き、KALOS2 を触る。 タッチパネルの感触がいまいちだ。 単にタップしたつもりでもスクロールすることが多々ある。 動きもちょっとぎこちないところもある感じがする。 画面はいいのかな。 とりあえず購入。
とりあえず Google Play 開発者サービスがクラッシュしまくって操作不能になるが、クラッシュの OK をかきわけて再起動ボタンを何とか押して再起動すると操作可能になる。 アプリのアップデートをすると今度はハングアウトが同様にクラッシュしまくるが、アンインストールして入れ直せば OK だ。IME は言語と入力に出てこないので Mozc for Android みたいに設定画面を出してくれる IME を入れて設定画面を出せば有効化できる。 これは Nexus 10 も実は今はそうなっているかも知れない。
最初はクラッシュしまくるトラブル等不審に思いつつ IME の有効化もできずによくわからずに再起動したらそのまま KALOS2 ロゴ画面から先に進まなくなった。 早くも起動しなくなるとはね、と思いながら FAQ 見て音量ボタン両方を押しながら起動し全消去。 もう一度再設定していった結果が上の解決策で、結局クラッシュはするが起動しなくはならなかった。
Google Play ムービーは端末自体が対応していないんだそうで使えない。YouTube は使える。 問題ない。
しかし起動しなくなるなどのトラブルからすると 4 万円くらいが妥当な価格なんじゃないかという気がする。 タッチパネルといいソフト面といいクオリティーがいまいちだ。 これ、バイブレーターがないのかな、あと、スピーカーが上のほうについてる。 はっきり言うと Nexus 10 ほどの全部入り (気圧計・国内 GPS・バイブレーター等も含む) 機能とクオリティー (安定性・長期保守) を期待すると裏切られるので期待しないほうがいい。 画面だけはよさそうだ。 あと本体が軽いのはいい。
自分が書いたクソコードを見ていると、やっぱり C++ のオブジェクトの参照関係が何とかならないかと思えてくる。ROM と RAM をいくつかのオブジェクトとして生成し、画面表示、音声出力、キー入力、ディスケットドライブ、その他 I/O 等をそれぞれ別々のオブジェクトとして生成するが、例えば画面表示にはフォント ROM と VRAM 共用 RAM へのアクセスが必要であり、その他 I/O においても双方へのアクセスが必要であって、あるいは、ディスケットドライブのアクセスランプ表現のために画面表示の呼び出しが必要というのもあって、こういうのをどう表したらすっきりするものか、C++ 初心者な自分にはよくわからない。
今は各コンストラクターにポインターを渡しまくっていて、デストラクターが順番に実行されて正常に動作するよう { } で囲いまくって変な参照がされることのないようにしてある。 実際のところはデストラクターでそれらのポインターを使うことはないので、順番は気にしなくても大丈夫なんだけど、なんかデストラクターの実装を仮定するのも気持ち悪い気がして、それでこんなふうになった。
まず考えるのは継承関係で何とかならないかというもの、親クラスの protected にオブジェクトを置けば、親クラスと子クラスの双方からアクセス可能というのは確かに書ける。 しかし、継承すると例えば画面表示とその他 I/O の双方に VRAM 共用 RAM が含まれることになるから、それらを別々のオブジェクトにするわけにはいかなくなり、菱形継承問題になるのかな。 菱形継承の場合、仮想継承というのを使うことで、親クラスのオブジェクトを共通のものにすることができるらしい。
次に考えるのは、かなり開き直ってグローバル変数という手段。 グローバル変数にオブジェクトを置いておけば、extern 宣言だけでどこからでもアクセス可能。 確かに画面表示の内部で SDL を使っているなら、そのオブジェクトを複数作れるようにする意味はあまりない。 ただし、グローバルというだけあってどこからでもアクセス可能になるので、可読性は微妙か。 それと、例えば画面表示に使う SDL 初期化をコンストラクターでやって、終了処理をデストラクターでやるには、SDL の全体初期化を先にやらないといけないから、グローバル変数はポインターにしておいて、SDL の全体初期化が終わった後でオブジェクトを生成する、みたいな工夫が必要になる。 そんな感じで結局これも、変なタイミングで参照されることのないよう気を遣う必要はあることになって、うーん。
その次に考えたのは、今の普通のポインターの代わりにスマートポインターを使う方法。 スマートポインターであれば不要になった時点で解放されるのだから、デストラクターの実行順に悩むことはないだろう。 素直に順番に new していって、後処理は任せた、というやつだ。 いい感じかと思ったが標準で用意されるスマートポインターは C++11 と古いやつとで違うっぽい? 明らかに複雑な用途ではないから自分で実装してしまうのも手なのかも知れないが...
さらに考えたのは、friend class を使う方法。friend には private な情報へのアクセスも許しますよという、大変邪道な感じの機能だが、何か使えそうな感じがしないでもない。 けどやっぱ使わないほうがいいかな。
みたいな感じで C++ というかオブジェクト指向には未だに慣れないな。
DeNA 株主総会。 おみやげは今年から無し。 質問は結構時間が長く、リワード広告 / ダウンロード数の代わりにユーザー数を示せないか、配当性向? が低すぎないか / 株主優待を使いやすくしてほしい、自動運転で事故が減るか / 南場さんの本を買った、動画配信 SHOWROOM の問題 / AKB・乃木坂関連 / 管理の問題、任天堂協業のゲーム飽きるんだけどどうなの、優待の選択肢を広げてほしい、ヘルスケア (マイコード) の現状・優待に入れられないか、ベイスターズの横浜球場が最近満員で拡張できないか、キュレーションどうなの、球場を別の場所に作らないの / 拡張しないと日本シリーズできなくない、今後の東アジアの成長、優待で見学はどうか、SHOWROOM の課金 / ゲームの優位性、子会社が増えている? / WAPTX はタックスヘイブンで云々 / 海外の収益 / 休眠会社はないのか / 水がどうのこうの?、AI が流行ってるけどどうか / ベイスターズは日本シリーズなんて出られるかわからないが今年の目標は?、採決が拍手なのはどうなの、みたいな感じで、結構ベイスターズ絡みがやっぱり多いな。
去年同様? 穏やかな株主総会であった。 ベイスターズのファンが結構いるんだろうなという感じはあるが、任天堂協業のゲームもさっそくやってみた人もちゃんといたし (自分はやっていないどころかリリースされていたのを知らなかった)、海外ゲームはヒットが出ればって感じだったが国内は少しはマシになっている様子だった。
朝目覚めた時点で久しぶりにはっきりと風邪らしい症状が出ていた。 のど痛い。 のどスプレーを使ってごまかす。 一日自宅でおとなしくしていよう。
のどの痛みはお昼頃には気にならなくなっていたが、ちょっとトイレに、みたいな感じで、体を動かそうとしたとたん、全身のだるさを感じて、これがまたいかにも風邪っぽいし、自分の息が熱い気がするというか、体が発熱している感じがする。 がんばれ、自分の体よ。
夕方ちょっとスーパーに買い物に行ったら大混雑だった。 ラジオでアベレージやってたから 17 時頃か? かなり多いんだな。 これが 21 時台になると割と余裕になるのである。
そうそう、風邪の潜伏期間を考えれば、感染したタイミングとして一番疑わしいのはちょうど先週の渋谷・鹿児島おはら祭かなと。 渋谷なので当然のことながらものすごい人混みだし、いつになく体力も使ったので、もらったウイルスに免疫が対応しきれないまま今にいたり、発症しちゃった、みたいな感じかな、素人考えだけど。
なんか調べていると関数オブジェクトとか一部オブジェクトとか右辺値参照 (rvalue reference) とかいろんな未知の内容が出てくる。 そういえば、C++ って高校の図書館にあった本か何かで少し勉強した程度で、それは確か STL の話はあったと思うから C++98 か。 そもそもそれだってちゃんと覚えてはいないのに、その後 C++03、C++0x (→C++11)、C++14 が出ていて、いろいろ変わってきているようである。
へぇー。
朝目覚めた時点でやっぱりのど痛い。 熱もちょっとあるのか頭も痛い。 そんなわけで職場に休みの連絡を入れる。
午前中はそれなりに寝た。 熱はもう落ち着いてきたか、しかしやっぱりのど痛い。 そして立ち上がると頭痛い。 うーん。
午後もゆっくりしていたが、少ししか眠れなかった。 結局夜になってもあまり症状は変わらず。 のどの痛みは何もしてなければ気にならないが、唾液等を飲み込むと痛みがある。 頭痛も静かにしてれば気にならないが、立ち上がると痛みが走る。
一時オブジェクトというのは使ってみたが、結局 rvalue reference などというものは使わず、必殺 (?) 値渡しでの実装を行った。 どうせ初期化の時だけだから多少のメモリーコピーがあってもかまわないし、簡単なデータ構造だからコピーコンストラクターを自分で書く必要もない。
とりあえず C っぽくリストを書いてみたのだが、当然のことながら STL を使うのが普通であろう。 しかし、STL を見ていたらちょっと C の感覚と違うことに気づいた。C の双方向リストの場合、例えば struct hoge に struct hoge *prev, *next; などと宣言を加えて、それでゴリゴリやるわけだから、確実にリストに入っているとわかっている struct hoge のポインターを扱っているならば、リストを探索することなく要素の削除ができるわけだ。 これが std::list <struct hoge> でできるのかと言うと、struct hoge の中に std::list<int>::iterator を入れておかないとできないんじゃないかなぁ。 そうすると C のやり方より無駄が増えている感じがする。
そうそう、他にも C の感覚だと違和感があるのは、private のメソッドだ。 メソッドは private であっても class の記述の中に含めなければならず、そうすると、ちょっと処理を書きやすくするために作った内部用の小さなメソッドでさえも、class を書いたヘッダーファイルの中に現れることになる。 対策案としては Pimpl idiom と呼ばれているらしい方法があって、ヘッダーファイルの private メンバーとしては構造体またはクラスのポインターのみを置いておき、その構造体またはクラスの中身を本体のほうに書いてしまおうというやり方である。 これはこれでいいんだけど、new delete が必要になるので頻繁に自動変数でオブジェクトの生成削除が繰り返されるようなケースでは向いていないのではないかと思う。 って、それは C でも同じか。 それより外側のオブジェクト (ポインターを持つだけ) の new と内部用オブジェクトの new が別々に必要になることを心配するべきか。
まだのどの痛みが残っているが、きのうの朝よりはマシ。 というわけで普通に出勤。
風邪の症状は何となく徐々によくなってきているように思う。 のどの痛みがあまりにひどいようなら耳鼻咽喉科に行こうと思っていたが、この様子なら数日で治るだろう。
std::list がああなっている理由、ひとつはたぶん、offsetof が使えないことにあるのかも知れないと思った。C でリストを書く場合には:
struct mydata {
struct mydata *next;
int weight, height;
};
みたいにするのが普通に習う方法だと思う。 こういう単方向リストはまだいいけど、双方向その他は共通化しておきたい、となった時にはマクロに頼ることになって、それをやったのが BitVisor の include/core/list.h である。
bitvisor / bitvisor / ソース / include / core / list.h - Bitbucket
ま、これはこれで有りだと思うのだが、LIST1 を実装した後、複数のリストに入れたい構造体のために直接 ->next を参照するわけにいかなくなって、その名前に指定したキーワードを追加するようにした別バージョンを実装する羽目になったのが LIST2 であるw
で、ものによっては以下のような手法を使っているものがある:
struct list { struct list *next; };
struct mydata {
struct list list;
int weight, height;
};
この場合は struct list という型で扱えるのでマクロにしなくても普通の関数定義で扱える。 しかし、降ってくるのが struct list のポインターなので struct mydata のポインターに変換する必要が出てくる。 この例では先頭にあるので単にキャストすれば通るわけだが、実際には先頭にない場合もあって、そこで offsetof の登場となる。 もちろんその部分はマクロで定義することになるし、リストの要素をたどるたびにアドレスの減算が必要なのは無駄といえば無駄かも知れない。
で、std::list もこの struct list に似た状態になっているのではないか。 いや、テンプレートだから当然違うわけだけど、仮に std::list <struct mydata> とした場合の各エレメントのデータ構造想像図 (C で書くとこんな風になってそう) は以下になる:
struct list_internal_data {
struct list_internal_data *prev, *next;
struct mydata element;
};
ここで struct mydata * から struct list_internal_data * を得たいとなれば offsetof の登場だが、C ならそれで良いところ、C++ だと offsetof が使えるところに制限があるらしく、本当に C の構造体っぽいもの、全メンバーが public で、メソッドはあってもいいけど virtual 等を使っていない、といった条件みたいなので、おそらく std::list はそのへんの都合で要素のポインターからリストのイテレーター等を得ることができないのではないか。 もちろんマクロの嵐は C++ でも書けるわけだけどねぇ。
今日は症状は変わらなかったかな。
職場にも同じような風邪を発症している同僚がいる疑惑。 潜伏期間を考えると誰が持ってきたのか... いや、発症しないまま退治できた人がばらまいていたかも知れない。
アドレス変換みたいな仕事を担うデバイスのエミュレーションがだいぶ強引だったので、コードを整理して、ハードっぽく「バス」を導入し、そこに各デバイスがぶら下がるようにして、まぁまぁきれいにしたらパフォーマンスに影響が出てしまったので、対処した。 コンピューターのバスってのはようするに CPU とメモリーやデバイスの間をつなぐ線のことであり、そこを流れる信号は基本的にはブロードキャストなのでつながっている全デバイスに届くわけであり、そういうつもりでエミュレーションするとオーバーヘッドが大きすぎたみたいだ。 それでアドレス範囲を 16 分割して各デバイス側でアドレス範囲を主張できるように変えた。
○ード○ンナーというゲームで遊んでいるとやたら動作が速かったのだが、コードを整理したことで原因が判明。VRAM と共用の汎用メモリーはアクセスに平均で 1.5 倍の時間を要するらしいのに、B800h の VRAM 空間のアクセスだけをその時間にしていた。 そこを直したところ動作速度がいい感じになったので、それが原因だったみたいだ。PCjr 互換モードでは下位のアドレスに VRAM と共用のメモリーが割り当てられているため、おそらくそこに読み込まれているであろうゲーム本体のプログラム実行速度も遅くなるようだ。
そして、まさかと思ったが、よく遊んだ○ンチ○ールというゲーム、なんと 128KB 拡張メモリーカード (VRAM との共用不可、すなわち速い) を 3 枚とも全部取り外すと遅くなるようなのだ。YouTube で他機種の同ゲームの動画を見た感じからすると、どうもその遅いほうが正しいスピードみたいだ。20 年以上前に遊んだけどまさか速い状態だったとは今まで考えもしなかった。 アチャー、これはメモリー容量の変更機能も付けないといけないかもなー。 しかし 128KiB RAM (基本メモリー 64KiB + 拡張メモリー 64KiB) だけではさすがに動かないゲームも多いようだ。
のどの症状はちょっとずつ良くなってきている感じがする。 立ち上がったときの頭痛もほぼ解消か。 もう最後の症状が残っているくらいな感じだ。 ひたすらのどに来る風邪だったということか。
小田急バスの降車ボタンを押したときに流れる放送「次 とまります。危険ですから...」の音声が女声から男声に変わったのはいつだったか、去年くらいだったような気がするんだが、これが最近また変わったのである。 今度は子供の声になっていて、さらに、「自転車や歩行者に注意してください」などというせりふが追加された。 ちょっと滑舌が悪い感じで「電車や歩行者」みたいに聞こえて、えっ、ってなる感じが、まぁ、そういう注意喚起が狙いか。 そういう意味で適度に変えないと効果がないのかも知れない。
小田急バス運行のコミュニティーバスはというと、あえて乗ってみたところ、男声のままだった。 そして、乗ってから気づく、ドアーを閉めた時の「発車します。おつかまりください」みたいな放送も男声だ。 そういえば路線バスのほうはこっちは子供の声には変わってなかったんだっけ。
そして具体的なせりふを思い出そうとすると、どうしても「バスがよくとまるまで」を思い出してしまうのであったw 関東鉄道バスがかつて使っていたやつ。
風邪を引く前から予定通りの休暇。 風邪のほうはというと、のどの痛みに多少波があって、平均するとここ 2 日ほど結局あまり変わっていないような気がする。 手持ちの風邪薬は期限を 5 年くらい過ぎていたので処分しよう。 手持ちの薬の中にのどの痛み用の薬があったので、夜に飲んでみたところ、効いているようだ。
三菱自動車の株主総会。 会場は幕張イベントホール。 人数が多くなることを見込んでだったようだが、さすがに大きすぎたか、1 階部分の前半分で足りそうなくらいだった。
三菱自動車、話題の会社である。 会場周辺にはカメラを構えた報道関係者らしき人をちらほら見かけた。 監査報告は燃費不正があったことをふまえつつ、それ以外に問題は無いというような内容。 決算報告のビデオでは燃費不正問題を淡々と説明している。 さらに会長の益子修から再発防止策等に関して直々に説明がされる。 最大の疑問はなぜ益子修はやめないのかというところ。 一応本人が言うには再発防止策の筋道を立てるまでは自分がやる、その後は日産との資本提携の後で株主総会で? 取締役会で? 決めることで自分が決めることじゃない、みたいな、そんな言い分だった。 何だよコラと言いたくなるような話だが、そのときが来るまでの役員報酬は自主返納する、というようなことも言ったので、それでまぁいいかと思った株主も多いのではないだろうか。
議案の上程までされてから質疑応答が始まる形式。 それまでに 1 時間弱が経過していた。 様々な質問があったが、外部有識者による特別調査委員会について詳細は、という質問の答えが一番興味深かった。 別に秘密にしているわけではないようで (当然か)、元検事? か何か、弁護士の 3 人ほどと、それでは自動車の専門的な知識を持つ人が足りないとして、元トヨタ自動車の人も加わっているらしい。 そして関係者が (?) 毎日のようにインタビューをしているほか、これらの委員も週に 1, 2 度は岡崎に行って終日インタビューをしているとか、何かそんなような話。 中間報告は無く、詳細は来月の下旬あたりに出てくるんだとか。
質問で、三菱自動車の企業体質を問う声も。 社外取締役もほとんどが三菱の関係者だとか、縁故採用があるんじゃないのかとか。 当然、縁故採用は無い、って答えになるが、これって、三菱グループの関係者くらいしか三菱自動車に入りたい人がいないのではなかろうか、なんて思った。 益子修は経営の最高責任者なのだから辞任するべき、とか、問題の軽自動車は益子修が社長の時代に出た車種だろ、とか、様々な厳しい指摘も当然あったが、会長は極めて穏やかに誠実に答えている感じではあった。 そういえば、舛添要一のやったことは不正ではないが不適切 (正しくは違法ではないが一部不適切)、三菱自動車のやったことは不適切ではなく不正だという、時事ネタ指摘もあった。
違和感があった点。 以前の不祥事かな、2004 年頃とか言っていたと思うが、そのときに数百人が辞めて、人手不足になったというような話があった。 人手不足ってね、他人のせいか? 問題だらけの会社でも、高い給料を出せば必ず人は入ってくる。 それをやらなかったのは誰だい? みたいな。 それと、再発防止策、今回走行抵抗の机上計算があった (この問題自体はスズキに近い、数車種が挙げられていたが燃費を良く見せるものではなかったそうな) ということで、そういう不正行為がないように徹底する、教育する、みたいなそんな感じの言い方があったんだけど、あの言い方だと開発部門の技術者にまで強制されないかな? 開発段階の内部用データとしては机上計算だろうが何だろうがやっていいんだよね。 そうしないとデータのばらつきもあるから開発がなかなか進まなくなる。
天気が怪しげでめんどくさいので、車で高速フル利用。 中央道から永福にかけてが一番渋滞していた。 中央環状線では事故現場を通過、発炎筒が左側に置かれていて、ああ、右に行けってことかな、と右ミラーを見ると無灯火で結構なスピードで迫ってきそうな車があり、勘弁してくれよと思いながらさっさと右合図を出して車線変更、先の見えないカーブを曲がると左側で事故処理中だった。 事故だって表示が出ているにも関わらず、カーブの多いトンネルで制限速度 +20km/h 以上な車が走っている世界、首都高だと事故処理の人もめっちゃ危険そうな感じがする。
帰りも高速フル利用、調布 IC 出口ランプが渋滞していた。 調布 IC からだと手頃な給油所に行くのが面倒くさいのと、窓がだいぶ汚れていたこともあって、セルフじゃない給油所に寄って給油。 窓を拭いてくれた。130 円/l。 燃費計算 20.4km/l。 燃費表示 21.8km/l。 もしかして、計算よりも表示の燃費のほうがやたら良くなることがある原因は、例の 1NR-FE の燃料噴射装置の不具合問題が確か、冷間時にコンピューターの計算よりも燃料を噴射しすぎているという話だったと思うので、冷間時の分はそういう傾向になるのではないか。 修理をすれば解消するのかも。
ブックオフの株主総会。 本以外に手を出した結果、赤字だとか? まぁ今期はシステム開発等にお金がかかったって言うけどね、本以外では遅い参入なのだから、同業者に勝ち目があるのかどうか。 利益が年々減ってマイナスってことで、今年は質問でも厳しそうな指摘があったね、本がおろそかになってどうすんのみたいな。 今回は取締役の任期満了のタイミングではなかったし、採決に興味は無かったので 80 分くらいのところで退出した。
CRTC HD46505SP-2 (MC6845) のエミュレーションを JX エミュレーターに実装し、それをもとに VRAM の読み出しなどを行うようにして、いい感じに動くなと思っていたのがきのう。 そして何となくスーパーインポーズを試したら... 適当に screen 1,1:screen 7,1,1 を試したら、合成された VP1 のグラフィック画面が崩れているのであった。 あれ? あれれ?
原因は CRTC の MA (メモリーアドレス) と RA (ラスターアドレス) を、テキスト表示の VRAM アドレスとフォントアドレスに使用するだけでなく、グラフィック表示の VRAM アドレスにも流用したことだ。 いや、VRAM のアドレス計算が、1 ラインごとにバンクが違うなど少々トリッキーなことを考えれば、これは流用されてしかるべきものではないかと思うし、パラメーター値からしてたぶん PCjr はそういう設計になっているのではないかと思われる。VP1 のページレジスターにだけ、画面モードに合わせて設定するビットがあるが、これはアドレス計算に関係しているようである。 問題は、VP1 のグラフィックと、VP2 のテキストを合成する場合、CRTC のパラメーターはフォントアクセスの関係でテキスト表示に合わせられるから、MA と RA はテキスト表示用のものになり、グラフィック表示に使う VRAM アドレスとは無関係のものになる。
さて、謎を解くために回路図を開く。RA をたどっていくと... まずメインメモリーのところだ。 さりげなく CG1 のフォント ROM が見えている。 フォント ROM のアドレスラインの下 3 本が RA に直結だ。2KiB のはずなのだがアドレスラインが 13 本 (!) あり、一番上はプルダウンのようだ。 その下は RA3 がつながっているが何のためか? フォント ROM の出力は D フリップフロップ (!) によりラッチされる、というか、フォント ROM のアドレスラインにつながる文字コード読み取り用、CPU アクセス (読み取り?) 用と、属性読み取り用のラッチがあって、これでタイミングを合わせているみたいだ。 文字コード読み取り側は RA3 がクリアにつながっていて、これで縦 8 ドットを超える時には強制的に文字コード 0 になるのかも。 へぇー。64KiB 拡張メモリーを搭載するとインターリーブとなり、奇数アドレス・属性が拡張メモリー側になる。 とまぁともかくそんな感じで、そのほかは VP2 用と思われる漢字 ROM の近くと、拡張表示カードにつながるところか。 あと RA0 だけ何か別のセレクターっぽい回路にもつながっているようだがよくわからなかった。
MA はすぐ隣の LSI に直結だ。 メインメモリーは RAS CAS を用いた 8 ビットのアドレス指定になっており、その LSI がアドレスを出しているようだ。 詳しくはわからんけどその LSI に RA が入力されていないことから、やはり VRAM のアドレス計算に RA は使われていないと見るべきだろう。
ってちょっと待て、じゃあこのスーパーインポーズの時の VRAM アドレスはどこで計算されるんだ。 ってこの LSI しか無いと思うんだけど、RA は使ってないしいったいどういうことだろう。 どこか巡り巡って RA が入っているとか? と思ったけど拡張表示カードの端子説明でも RA はテキスト表示用だとある。 あれれ?
そうそう、きのうはじゃがいも掘りだった。 今年はそんなに多くはなかったような? でも、腐った感じのは無かったから、いいかも。
あと、准組合員なので今年も配当金があったわけだが、またしても普通貯金の残高から特別配当金、これがまた 0.15% もあるから下手な銀行の定期預金より利率が良いわけで、わずか 3 万円の出資で至れり尽くせりである。 引換券は醤油だったかな、くじを引いたら見事に当たり! うどんとそうめんがそれぞれ 500g x 2 入っている。
スーパーインポーズ対策は、グラフィック画面の時は DISP 信号と VSYNC 信号をもとに、最初だけ MA をもらって、その後はアドレスを独自に計算する方式でごまかし実装。 次に、ボーダーカラーが出るようにするのと、画面をずらすことができるようにするために、画面表示回りをさらに改変する。 要するにブラウン管の縁に隠れる部分を含めて構成し、必要部分を表示しようってわけなんだが、いざ作ってみると画面モードによって画面の位置が意外と大きくズレる。 特に PCjr の画面がやたら右にズレる。 何でかというと、CRT コントローラーに設定される水平同期信号のタイミングが違う。
例えば横 40 桁 (低域モード) では水平トータル 57 桁、表示 40 桁 (当然)、水平同期信号の長さが 6 桁というのはいずれも同じだが、水平同期信号の位置が、基本モードでは 40x25 テキスト画面で 47 桁、2 色グラフィックモードで 46 桁となっているのに対し、PCjr では 40x25 テキスト画面で 44 桁、2 色グラフィックモードで 43 桁となっている。 そうすると水平同期信号の終わりから左端の文字が出るところまでの長さ + 右端の文字の終わりから水平同期信号の始まりまでの長さは、それぞれ 4 + 7 桁、5 + 6 桁、7 + 4 桁、8 + 3 桁となる。 さすがにここまでズレたらどうしようもないな。 なお、英文モードカートリッジならズレないみたいなので、パラメーターを日本向けに変えてあるようだ。
いろいろ調べていたら、ビデオ信号をソフトウェア側から確認できる仕掛けが存在するらしいことを見つけた。VP1 のステータスレジスターのビットに、ゲートアレイのアドレスに応じて IRGB のいずれかが現れるらしい。 起動時に画面の一番上にチラッと線が見えていたやつ、あれは何かというと、40x25 モードで背景色白・文字色白? で画面の一行目に _ を 40 桁並べ、その信号をステータスレジスターから得てテストしているらしい。 今までその部分をちゃんとエミュレートしていなくて、何か返さないと POST で引っかかるのでとりあえず毎回ビット反転しておくというあり得ない実装をしてあったので、おかげでテストを一瞬でパスしてしまい、白い線が見えなかったわけだ。
垂直帰線時割り込みの頻度が狂うようなバグを作ってしまい、動作確認中に某ゲームのデモの動作がなんか変だと思ったらデモ中にワールドレコードが更新される事案が発生w 垂直帰線時割り込みを音と時間計測に使用していたらしく、2/3 くらいの頻度になっていたもんだから、ゲームの進行ペースは変わらないのに時間がなかなか進まないことになってそういう結果になっていたようだ。
拙作エミュレーターの 16 ビットの IN/OUT 命令の実装をミスっていて、上位 8 ビットから先にアクセスしていた。 こういうのは little endian らしく素直に下位 8 ビットからアクセスするのが正解である。 そうしないと CRT コントローラーへの書き込みを 3d4h への 16 ビット OUT 命令で実行できなくなってしまうのである。 って、そんなことを子供の頃に試した記憶はあるが、一般的な方法ではないのかと思っていたら、実際に使われていたらしいことを知ったのであった。
なお 8088 は外部バス 8 ビットなので、こういうのは CPU 内部で行われるが、その後の外部バス 16 ビット以上の機種では CPU は 16 ビット幅でそのままバスに流してしまう。 当然ハードウェアがそれを許容するようにできていなければちゃんと動かないのだが、おそらく IBM PC 互換機というのは、IBM PC が 8088 だった名残で、これを 8 ビット幅のアクセスに変換するような仕掛けがどこかについていて、未だにそういうのが動くものと思われる。PC-98 シリーズなんかは最初から 8086 だから、8253 タイマーなど 8 ビットでやりとりする同じシリーズのチップであっても、IBM PC とはアドレスの割り当て方が異なり、偶数アドレスだけを使用するなどになっている。
一週間経っても違和感があるのは変だから、明日は耳鼻科に行ってみよう。
マルハニチロの株主総会。 おみやげを帰りにもらった記憶があって、それはあっていたが、おみやげだけもらって帰るという選択肢も用意されていた。 すなわち、早めに行っておみやげをもらって、その足で FFRI なりミクシィなりの株主総会に行くという選択肢はあった。 しかしながら、2 年前に行った時に使った駐車場はなくなっており、手頃な駐車場を見つけるのに手こずったため、それはしなかった。2 年前の時の子会社の農薬混入事件についてあらためて質問している人もいたが、安全管理については以前にも増して注意が注がれているのではないかと思う。 チルド事業だったかな、魚肉ソーセージとかゼリーとか? そのへんだけ減収減益だとかで、それ以外はずいぶんと好調みたいだったんで、満足して 1 時間ほどで帰った。
一般道で甲州街道に出て、バスタ新宿の前を通った。 出入り口は信号のある交差点になっているのね。 タクシーも一掃されて、良い感じであるが混雑していたw 初台あたりから首都高・中央道をちょろっと使って帰宅。
耳鼻咽喉科へ。 のどが腫れているとのことで、薬を処方された。 とりあえず 4 日分、あんまり調子が良くないようなら週末また来てくれとのこと。
拙作エミュレーターの遅いところはどこか、gprof を使ったら時間がちゃんと出てないし、インライン展開されているような関数も回数を数えるらしくすげぇ CPU を食っているっぽい。 うーん。 代わりに oprofile と思ったが、カーネルに機能は入っているけどユーザーランドのプログラムが Debian パッケージに無いっぽい? 今時は perf というツールを使うらしい。 これは linux-tools というパッケージでサクッとインストールでき、使うのも簡単だ。 仕組みがよくわからないけど特に CPU 使用率も上がらず、それでいていい感じに情報が取れている。 早速見てみたら、画像処理ではなく音関係の処理がトップに来た。 予想外。 どうも妙ちくりんな構成のループに CPU がついてこれないらしいw
for(i=0;i<n;i++){
a++;if(a>=A){a-=A;...;}
b++;if(b>=B){b-=B;...;}
c+=x;if(c>=C){c-=C;...;}
}
i, n をローカル変数、その他の小文字をクラスのメンバー変数、大文字を定数として、こんなようなループを書いてあったのだが、実は c のところの条件が成り立つ頻度が一番低い。 もちろんコンパイラーにはそんなことはわかりようがなく、3 つを同じようにコンパイルしてくれて、その結果、それぞれの足し算と条件比較の回数がものすごいことになっていた。 このクソループをゴリゴリと書き換え... るのではなく、c のところの条件に引っかかるまでの間だけ、a と b のところを単純なループでゴリッとすませるようにしたら、コンパイラーも CPU も素直に動いてくれるようになった。
そうそう、JX のビデオ・ゲートアレイのリセット・レジスターの説明には、メモリー・リフレッシュをしてから同期リセットをすればメモリーの内容が消えないよ、みたいなことが書かれている。 某所で見つけた PCjr のほうでも同様の、いや、より詳細な説明があり、同期リセット中はメモリーへのアクセスができないといったような説明があるし、そういえば BIOS のソースコードにもそういうコメントがあった。 要するに、メモリー・リフレッシュがとまってしまうという話なわけだ。
しかし、しかしだ。 昔試した記憶では、BASIC プログラムや RAM 上の機械語プログラムから同期リセットをかけてモード変更をすることが、できた記憶がある。 少なくともそれで、POST 処理を RAM 上に移して一部書き換えて実行することで、7.2MHz のまま拡張表示モードから基本モードへ遷移させるプログラムを動かしたことがある。 モード切替時の同期リセットは、とうていプリフェッチキューに乗るサイズではないので、実際 RAM へのアクセスはできていたわけである。
単純に謎だなぁと思っていたけど、最近になって謎が解けた。 内蔵の 64KB メモリーと 64KB RAM カードのメモリーは、VRAM と共用のものでシステム基板側でリフレッシュが行われる。 しかし、拡張チャネルに接続される 128KB RAM カードは、リフレッシュ回路を内蔵しているのだ。 つまり、ビデオ・ゲートアレイのリセットでメモリー・リフレッシュがとまるのは実は VRAM と共用の 128KB 部分だけで、残りの拡張メモリーはリフレッシュ回路を内蔵しているのだから、電源供給が途絶えでもしない限りはリフレッシュがとまることはあり得ない。 と思ったんだけど、リフレッシュ用の端子が拡張チャネルに存在するみたいなので、そこの信号が途絶えてしまえばリフレッシュはとまるかも知れない。
とはいえ、おそらく、VRAM 共用かどうかは重要なところで、英文モードではその VRAM 共用メモリーが下位 128KB に来てしまうので、これが飛ぶということは割り込みベクターやら何やらといった重要情報がすっ飛んでしまうことになりうまく動かない。 ところが基本モードや拡張表示モードであれば、このメモリーは上位に来るので、128KB RAM カードを 3 枚さしてあったはずのあのマシンでは、ちょっとしたテストプログラムはほぼ確実に下位の拡張メモリー側にのっていたに違いなく、そのときに VRAM 共用メモリーの内容が失われていたかどうかは確認していないんだけど、おそらく失われていたんじゃないかなーと。
なお、エミュレーターではリセット・レジスターの処理はまともにやっていない。 モード切替の時に使うらしいのだけど、一部のレジスターは変更が即座に反映されないとでも言うのかな? とにかく具体的にどういうことなのかいまいちわかってないのだ。 しかも、そんなふうに扱いづらいレジスターだから、おそらくこれを触るソフトウェアは BIOS 以外にはほとんど無くて、ちゃんとやってなくても動かないソフトウェアはまずない。
薬を飲んでいるけどいまいち効き目が感じられない。 このまま行くと土曜日再受診かな。 この薬が効かないとすればおそらく抗生物質の種類が変えられるのではなかろうか?
きのうは効き目が感じられない (キリッ なんて書いたけど、今日になったら急に薬が効き始めた気がする。 よしよし。
夕方は雨とか言っていたけど全然降らず。 きのうもそんなんだったような。 関東はそんな感じだが、九州地方は大変な大雨が降ったらしい...
Bochs のシリアルポートのコードを借りて JX エミュレーターに移植しようとしたが、いや、してみたんだが、BIOS の Power On Self Test が通らない。 あれれ。 このテストって結構厳しいんだよなー。 なお、JX では RS-232C カードはオプションで (2F8H-)、接続すると 8255 のビットが落ちるようになっているが、PCjr ではどうやら標準で (2F8H-)、モデムを拡張 (3F8H-) すると 8255 のビットが落ちる仕掛けのような感じっぽいらしい。 あと、どちらもボーレート計算に使用するベースクロックが IBM PC とは異なるらしい。JX にも PCjr のモデムの名残と思われる 3F8H のポート割り当てが MODM という名前で残っているが、その拡張自体は存在しないっぽい。
拡張表示モードの表示タイミングを計算する。 テキストモードは水平 102 桁、水平表示 80 桁、水平同期 88 桁、水平同期の長さ 12?、垂直 27 行、垂直の補正 2 走査線、垂直表示 25 行、垂直同期 25 行!?、一行 21 走査線? グラフィックモードは水平 57 桁、水平表示 45 桁、水平同期 49 桁、水平同期の長さ 6?、垂直 72 行、垂直の補正 0 走査線、垂直表示 64 行、垂直同期 65 行!?、一行 8 走査線? か。 ちょっと設定値がよくわからないところもある。 一行の走査線は通常、数値から 1 を引いた値を設定するが、インターレースでは -2 なのか? そして垂直同期の開始と垂直表示の終わりのタイミングが同一って有りなのか!? それとも垂直同期のも 1 引いた値なのかな。 で、テキストモードは一桁 9 ドット、グラフィックモードは一桁 16 ドットになる。 ビデオ周波数は 20MHz、それでかけ算・割り算をすれば 76.68Hz と 21.930kHz が出るはずなのだが...
20000000/(102*9*(27*21+2)/2) 76.57818057900762335787 20000000/(102*9) 21786.49237472766884531590 20000000/(57*16*(72*8+0)/2) 76.14522417153996101364 20000000/(57*16) 21929.82456140350877192982
うーん、微妙にズレるな。
Powered by Tomsoft Diary System 1.7.4
Hideki EIRAKU