だからといって何か特別なことがあるわけでもないが。
ASCII の制御文字は ESC。
きのうは映画の前に The Typing of the Dead を 軽くプレイしてみたのだが、1,000 円以上の食事のレシートで 100 円分サービス って出る時気づいたよアチャー。 というのはともかく、1→2→5 でいい感じに進んでいたのだが、 やっぱ 5 は甘くなかった。
きのうの映画館は、 前に RealD 方式の 3D 映画を見たのと同じワーナーマイカルだったが、 きのうの映画はアナログフィルム上映っぽかった。 時折右上にフィルム切り替えのパンチが出て、 その後必ず映像が上下にぶれる現象が出ていたからである。 いくらアナログでもちょっといい加減すぎじゃないかと思うが、 ディジタル上映でそんなことをやっていたら、あまりにもお粗末である。
SN76489A のエミュレーション部分は、事前に調べていたこともあって、 比較的簡単に実装が完了した。 後は他の部分をちょっとずつ直しているのだが、 大きく変えたいのはビデオ部分で、HD46505 のレジスタ等を ある程度まじめに解釈して画面の位置なんかを反映するようにしたいところ。 なのだが、今の手抜き実装でも描画処理はかなりの負担になっていて、 普通に 60Hz 描画をさせると処理が間に合わないのが現状。 ある程度、軽量化のことを考えて実装しないといけない予感。
今日は夜に飲み会があり、遅くなってしまったので、 調布行きの最終バスからの乗り換えで京王線を使った。1 年前くらいまで 毎日使ったつくばエクスプレス (TX) の記憶は薄れてきているが、 京王線のインバーター式の電車は LED 表示板が TX のものとそっくりだし、 電動機も TX の交流車と同じ日立製ってことで、 停車直前の電気ブレーキの音なんかもそっくりなわけで、 ちょっとだけ親近感がある。
が、加速音を聞くとなんか TX とは違うような気がする。TX はもっと、 何て言うか、音の変化がスムーズだったような。 ブレーキだってかかり始めや停車はガックンと衝撃があったが、 途中の減速はコンピューター自動制御ということもあり極めて安定していた。 その代わり、モーター音は明らかに TX のほうがうるさかった。 やつは一部ポイント通過を除いて低速時の惰行をやらず、 基本的に全力で加速し多くの駅間で 120km/h に達するわけで、 騒音は相当なものだった。
まあそれはともかく、電動モーターのトルクときたら相当なものだ。 電車の場合、鉄道の特性上、加速-巡航-減速が割ときれいに分かれているので、 いいんだけど、これが電気自動車となると、アクセルペダルだけで 加速-巡航-減速を扱う (従来の自動車はアクセルペダルを離すことにより 弱めの減速を行うことができる) ので、その境目の制御がやっかいらしい。 というのをどっかで見た。 いっそのこと電車みたいに単純に、アクセルペダルは加速のみを扱い、 ブレーキペダルが減速のみを扱うってのでもいいんじゃないかとも言いたくなるが、 微妙な速度調整が重要な自動車ではそうもいかない。 実際にどんな風になるのかは電動カートにでも乗って... って、 そんなものに乗れる機会はなかなかない。 トロリーバスには乗ってみたいな。 遠いな。
今朝は ACPI S3 状態からの resume に失敗。 ダンプも残っておらず、原因は不明。 わずか 1 か月弱でクラッシュしてしまうのは、7.1 よりも不安定になっている証拠。
とはいえ 7.1 の時は ata のドライバーを 6.2 の時のものに 差し替えて使っていたせいで、安定していたという可能性はある。 ダンプが残っていなかったのを見ても、ata は極めて怪しい。
今日は雪がかなり降ったが気温が摂氏 2 度程度までしか下がっていないため、 路面はうっすらと白いものの水浸しでぐっちょぐちょな状態。 牛乳やら食用油やら食器洗い洗剤やら米やら、 底が見えてきたので買い物に行きたかったんだけど、 車のフロントガラスは真っ白けになっていたので今日はあきらめた。
VirtualBox に久々に Solaris を入れて触ってみるなどした。 最新版のはずなのに、いろんな意味で、古い。 楽しめるのは、本物 (?) の vi や ed や sh なんかに触れるところ。 でも、この sh、何か変だぞ。
$ host ホスト: 見つかりません。 $ 'Command not found' コマンドが見つかりません。: 見つかりません。
何だ、このいい加減な多言語対応はw
朝にはアスファルトの雪は解けていて、 車につもった雪も半分くらいはなくなっていた。
夜には雪はきれいになくなっていた、が、 車動かそうとしたら、フロントガラスが微妙に凍っていた。 おかしいな、氷点下ではなかったのだが。 仕方なく 2, 3 分アイドリングさせつつ全力で暖房かけさせて、 少しガラスがぬくもったところで拭き取る作戦で。 雪の降る地域の人たちは、きっと毎日のようにこれより大変なことやってるんだよね。 大変だね。
なんか先週末あたりに、古い編成がひとつ追い出されて、 代わりに別の車両がやってきたらしい。 今は予備車なしということになってしまうので、 きっとあと 1 週間くらいで試運転を終えて運用開始されるのであろう。
今のところ黄色ではなくて、不気味な真っ白らしい。 まだ実物を見ていないのだが、 いよいよ 1976 年製の車両が 1980 年製の真新しい 中古車両に置き換わり始めたわけだ。 今度は何年使うのかなー。
MinGW 用の SDL。-I/path/to/SDL-x.y.z/include/SDL -L/path/to/SDL-x.y.z/lib -lSDL とかそんな感じで簡単に使える。 が、-mwindows をつけていなくても、WinMain() を要求されるっぽい。 実行時に使うライブラリは bin の中に入ってる。
JX のメモリーについて。
で。 基本モード時のビデオ周波数は 14.31818MHz であり、1 周期はおよそ 70ns である。 謎だったのは、ビデオ・サブシステムによるビデオ RAM からの読み出しが 間に合うのかどうか、CPU からの I/O と競合しないのかということだった。
まず、アクセス・タイム 150ns に注目。 これはビデオ周波数で切り上げると 3 サイクル 210ns となる。
それで、640x200 の 2 色のグラフィックモードを考える。 ビデオ RAM の 1 バイトで 8 ピクセルを表現するため、 ビデオ周波数 8 サイクルごとに 1 バイトの読み出しが必要となる。3 サイクルで 読み出しが終われば、残りの 5 サイクルは暇ということになり、CPU は そのタイミングでアクセスができる計算になる。
次に、640x200 の 4 色グラフィックモードを考える。2 バイトで 8 ピクセルを 表現するため、8 サイクルごとに 2 バイトの読み出しが必要となる。 さっきと同じように計算すると、残りは 2 サイクルしかなく、CPU が アクセルする暇がない。
実は、ビデオ・プロセッサー 1 (PCjr 互換) においては、 このモードは 64KB RAM カードが必須となっている。 計算上、メモリーは 32KB で足りるにもかかわらず。 重要な点は、64KB RAM カードをつけると、 標準のメモリーが偶数番地、64KB RAM カードが奇数番地に割り当てられることであり、 これによって 3 サイクルで 2 バイトが読み出せてしまうことになる。 「高域ビデオ周波数」というのはどうやらこのことを表しているらしい。
ビデオ・プロセッサー 2 は専用のビデオ RAM を用いる。 ビデオ RAM は 4 ビットのデータバスを持つモジュールを 4 個 使っているため、16 ビットをまとめて読み出せる。 つまり、こちらも 3 サイクルで 2 バイトが読み出せる。
というわけで、ビデオ RAM として使用しているメモリーには、 ビデオ・サブシステムと CPU が交互にアクセスすることによって、 画面を乱すことなくビデオ RAM へのアクセスができるようになっているというわけだ。 ちなみにフォント ROM にはそういう調停機構がついていないらしく、 説明を無視して VSYNC を待たずに読み出しを行ったら、 画面全体にゴミがちらついていた記憶がある。 グラフィック画面でもちらついていたのがおもしろいところだが、 フォント ROM へのアクセス回路がビデオ RAM の読み出しとも密接に関連している ところに原因があるのだろう。 なお、英文モード ROM カートリッジには、 フォントがすべて格納されているため、VSYNC を待つ必要がなく、文字表示が速い。
なお、CPU クロックは 210ns サイクルで、 バス・サイクルは 840ns、I/O の読み書きのバス・サイクルは 1,260ns、 ビデオ RAM は「平均 2 ウエイト・サイクルをとるため」1,260ns らしい。 が、2 ウエイト・サイクルの根拠がよくわからない。 さっきの計算だと、840ns もあったら、十分間に合いそうなんだけど。
ビデオ RAM まわりのアクセスタイミングのエミュレーションが いい加減だからかも知れないけど、本物より速くて遊びやすい。 速いと難しくなるゲームが多いんだけどな。
Powered by Tomsoft Diary System 1.7.4
Hideki EIRAKU