はるかなり東京庵

そういえばもうないんだよね、東京庵…。
あのもてあますほど長い蕎麦がよかったのに。東京庵と壷といすゞがなくなったのは秋葉原にとって大きな損失だった（やや言い過ぎの気配が）。
ところで大晦日に神田に行くと年越しそばを買う行列で「おお、こんなところにも蕎麦屋があったのか」と新たな発見をすることもしばしば。蕎麦屋って目立たないけどけっこういっぱいあるんだよね。

タイマ問題

qemu

前のつづき。
よく考えたらタイマ関係の分解能をきちんと調べたことがほとんどなかったような気がしたので、ちょっとやってみた。
サンプルプログラム : win32timercaps.zip

で、手元の環境（Win98SE）だと

  • timeGetDevCaps によるタイマ最小分解能は 1ms
  • GetTickCount の増分は 1ms 単位（あれ、50ms じゃないんだ？）
  • timeGetTime の増分も 1ms 単位
  • ただし、ときどきつんのめったように 10〜20ms ぐらい間があくことがある。GetTickCount より timeGetTime のほうがつんのめり時間は相対的に短いようだが、正直どっちもどっち。
  • timeSetEvent はきっちり 1ms 単位でコールバックできるようだ
  • _ftime は 50ms 単位の増分しか取れない。GetTickCount は 1ms 単位で取れるのに…

こんな感じでした。
結果は動作環境によって異なる可能性があります。（ちなみに、NT3.5 時代の古い SDK ヘルプには「タイマの精度は、 Intel(R) システムでは16ミリ秒まで、 MIPS(R) システムでは10ミリ秒までです」と書かれています）

…とりあえず qemu 的には、_ftime 使ってるとこを GetTickCount か timeGetTime に直す方向で……

タイマ問題つづき

qemu

初代 Win95 が入っているノート(486DX4-100) があったので、試してみた。

query periodic capabilities...
Minimum Periodic Resolution     1ms
Maximum Periodic Resolution 65535ms
testing GetTickCount resolution...
Minimum Periodic Resolution     6ms
Maximum Periodic Resolution    41ms
Average Periodic Resolution 14.337243ms

testing timeGetTime resolution...
Minimum Periodic Resolution     1ms
Maximum Periodic Resolution    15ms
Average Periodic Resolution 1.036168ms

testing timeSetEvent resolution (per 1ms)...
Minimum Periodic Resolution     0ms
Maximum Periodic Resolution     5ms
Average Periodic Resolution 0.999022ms

50ms sleep ... 55ms

んー、GetTickCount のほうが timeGetTime よりだいぶ「粗い」みたい。