のどはいい。 たぶん抗生物質が効いている。 これなら明日は診察してもらわなくてもいいかな?
ただ、抗生物質のせいか、今日はお腹が緩かった。 下痢にはなっていないが、午前中だけで何度かトイレに行く感じになった。
あまり FLAC の圧縮率って考えたことが無かったんだけど、ビットレートを見るには soxi というコマンドを使えば良いらしくて、それで手持ちの FLAC をちょっと調べてみた。
ほんの 1,200 個ちょっとしかなかったが、そのうち半分くらいは 1Mbps を超える。 もっとも高いのは 1.18Mbps ですべて Perfume だ。Perfume で持っているのは GAME というアルバムだけだが、もっとも低いのが 1.01Mbps で、ほとんどが 1.14Mbps 以上になる。 他にも TRF のベストアルバムがすべて 1Mbps を超えていた。
低いほうはというと、相川七瀬の ID というアルバムの中の曲で 7.41kbps なんてのがあるが、これって無音じゃなかったかな。 それを無視すれば globe のインストゥルメンタルで 557kbps というのがある。 そういう間奏とか何とか、静かな曲はビットレートが低くなりやすいかも。 意外なアーティストでは爆風スランプの『星に願いを』という曲、576kbps である。 ヒット曲 (たぶん) としては福山雅治『最愛』の 685kbps はかなり低い部類に入る。
例えば GLAY や B'z といったアーティストの曲もビットレートは高めの部類に入るが、そのへんは一応 1Mbps を割っている曲もある。 誰でも知ってるわかりやすいところでは B'z『いつかのメリークリスマス』が 955kbps である。 そういう意味で一つ残らず全部 1Mbps 超える Perfume みたいなのはだいぶ特殊なんじゃないかな。
なお、CD-DA は 44.1kHz 16bit stereo だから、1411.2kbps である。 だから 705.6kbps で半分になったと言える。 半分を切るほどの高圧縮率になる曲はそう多くはない。 でも一番悪くて 1.18Mbps ってことは 8 割程度にはなるってことか。
テレビでやってた映画『アリス・イン・ワンダーランド』(原題：Alice in Wonderland)。2010 年のアメリカ映画。 トレイラーは何度も見たが、本編を見たのは初めてだ。
トレイラーの流れは自分の妻になるかと言われるところから穴に落ちて小さくなってる感じ。 実際は子供時代から始まり、変な夢を見たなどと言う。 その後大人の場面に移り、トレイラーのあのシーンは婚約パーティーなどと言っているパーティーでのことで、待ってと答えて子ウサギを追いかけ、穴に落ちたあと、怪しげな薬を飲むことで小さくなったり大きくなったりするようだ。
アンダーランドには地上と同じような扉や鍵のシステムが存在する。 まるで地上のお古を持ってきたみたいな、いや、まぁワンダーランドだしな。 王様システムまで存在するんだから、異国という感じか。 ちょっとアメリカンな感じなのは、いろいろあってラスボス決闘シーンみたいな感じになるのだ。 しかも勝っちゃう、まるでヒーローものではないか。 アリス強い。
のどに痰が絡むような違和感が少し残っているので、もう一度耳鼻咽喉科へ。10 時台はまだ人が多かった。 いつものように診察はあっという間。 のどを見た時の先生の反応からして、先生の予想の範囲内で治っているのではないかと思う。 数日で良くなるでしょうとのことで、抗生物質は終了、痰が絡む時用の薬が追加。
原付のエンジンオイル交換。
バイクの任意保険の切り替え手続き。 グラストラッカーを買ったお店が取り扱っていたあいおいから、ディーラーが取り扱っている東京海上日動へ。 等級を引き継ぐのにちょうど満期のタイミングが良いと言われていたので、このタイミングになった。 まぁ正直基本的なところはどの大手自動車保険会社も差はない。 四輪車とは違ってバイクの場合は同一排気量であれば車種や免許証の色が保険料に影響しないのも同じだ。 後は搭乗者傷害を人身障害に切り替え的な感じで、これはまぁ、勧められたからではあるけれども、グラストラッカーの時よりも高速走行が多いので、妥当なところかと。
そういえば、車の任意保険は最初のヴィッツを買ったお店の三井住友海上を継続している。 車を買い換えた時、同じようにディーラーで切り替えを勧められた気がするんだけど、結局そのままである。
F1 オーストリア GP 予選観戦は Live Timing で。 天気が結構変わったみたいでおもしろいことになっていた。 有料会員の Live Timing にはコース状況も随時コメントされるのだが、雨が降ってきたーというドライバーの無線の後、どこどこのトラックセクター (わかりにくいことに sector 1, 2, 3 と track sector とは違うみたいで track sector 12 とかそういう風に出てくる。12 コーナーなら turn 12 という表現になるのでそれとも違う) が滑りやすい、という情報がずらずらと出始め、climate condition が変わった、となって、その後それらの情報が clear されていったw おそらく、ドライコンディションであれば、どこどこが濡れていて滑りやすいから気をつけろ、となるところ、ウェットコンディションとなれば、濡れて滑るのは当然だよね、みたいな、ちょうど扱いが変わるところだったのだろう。 しかも最終的には再びドライコンディションになったようで、最後の 2 分ほどでめまぐるしく順位がかわっていった。
きのうバイクの後輪のホイールとドライブチェーンを洗って、ドライブチェーンにオイルをつけておいたのだが、洗った後にしては足りないかなと思って、今朝もう一度つけてくりくり、つけすぎたぶんを拭き取って完了。
というところで、天気が微妙に曇り空でちょっと涼しげだったので、午前中のうちにレンタルカート。 藤野。3 回乗ってベストタイムは 40.02 秒くらい。
12 時ちょっと前の時点ですでにかんかん照りで結構暑かった。 高速使ってパーっと帰ったがバイクのエンジン付近からの熱気がすごかった。 帰宅後バイクを駐車場に入れるために一時的に車を動かしたとき、車の外気温表示がなんと 40 度だった! いくら炎天下に駐車していたといっても、40 度というのはめったに見られない。
結局、今日の最高気温は、気象庁アメダスの情報によれば、東京・府中で 36.7 度 (15:43) だった。 遊びに行くのを午前中にしておいて正解だった。
インターレースには偶数フィールド・奇数フィールドってあって、映像信号でどちらのフィールドかの区別がつくようになっているはず。 そうでないと、もし偶数・奇数が反対になればおかしな映像になってしまうし、ファミコンや MSX などの昔のゲーム機・パソコンは片方のフィールドだけを出力し続ける仕組みだ。 どうなってるのかというと...
垂直同期信号のタイミングが半分ズレているらしい。 半分? 何を言っているのか? と思ったが、CRT の走査は Z 字の形にされているものと思っていたのが勘違いだったようだ。 実際には、垂直方向の走査は水平方向の走査とは独立していて、連続的に行われていたのだ。 つまり、Z の横線は微妙に右下に傾いていて、水平の線と垂直の線を表示しても微妙に垂直に交わらないことになる。 それで、垂直同期信号のタイミングが半分ズレることで縦の位置が半分ズレるということだ。
具体的には垂直帰線期間とやらが、偶数フィールドがライン 1-20, 奇数フィールドがライン 263.5-283.5 とある。 偶数フィールドが 21-263.5、奇数フィールドが 283.5-525 になるから、偶数フィールドが 0.5 ライン長く、奇数フィールドが 0.5 ライン短くなってるのかな。 どっちがどっちだっけ? えっと、0.5 ライン長いフィールドの後が下になるのかな? だから偶数が上なのかな?
あと、同期信号は走査を端っこに縛り付けるものかと思っていたが、これも勘違いということになる。 単に、ひゅんっと一定量巻き戻す、そのタイミングを決めるだけってことみたいだ。 まぁこんな感じなので、偶数フィールドか奇数フィールドかを決める特別な信号線があるわけではなく、単に垂直同期信号のタイミングで決まっているということで、理屈の上ではずらす量の微調整もできるのかも知れないし、パソコン用のプログレッシブ CRT に対してインターレースの信号を食わせることも (どうなるのかは知らないが) できるのかも知れない。
もうひとつ、調べていておもしろかった内容:
最後のところで「明滅に合わせて画面が膨らんだり縮んだりする」話がある。 「高圧レギュレーションの悪い CRT で」起きるらしいw 自宅の 2001 年購入のサムスンの安物テレビでは起きている。 今時の (今?) パソコン用 CRT では起きない気がする。JX のディスプレイでは起きていて、しかも拡張表示モードはインターレースだったから、1 ライン飛ばしながら横線を描画することで、片方のフィールドを明るく、もう片方のフィールドを暗くすると、各フィールドの大きさが違ってしまいズレてしまうという現象があった記憶がある。
まぁ、そんなわけで、テレビは 1930 年代から実用化され始めた古い技術だけど、インターレースやら 60Hz の由来やらを知ると、おそらく当時としてはかなり未来的というか、10〜20 年くらい先の技術というか、無理をした技術だったんじゃないかと思う。 今のディジタル放送のほうが、技術的に無理のない、非常に素直な設計という感じである。 そう考えると、テレビというのは、本来はもうちょっと洗練された形で、もうちょっと後に普及するべき技術だったのかも知れないが、おそらくこの革新的な装置は人々の心を動かし、少々無理やりにでも普及させられてしまったのではないか。 そして一度普及してしまうと、置き換えるのは大変、というのはまぁインフラ全般にありがちな話で、電気の 50Hz/60Hz は結局混ざったままだし、狭い道はなかなか広くならないし、メタル電話線の廃止もこれから始まるのだろう。
今回ライブストリーミングは良いものを見つけられず、有料 Live Timing のみでの観戦。 その Live Timing が途中で不調になるもんだから、Formula One の運営はイケてない。
フェラーリ勢はライコネンが早めにピットイン。 ライバルに反応したのかな、と思ったが、ウルトラソフトのハミルトンがあれだけ粘れていたんだし、もうちょっと伸ばしても良かったのでは、と思うくらい、ピットアウトの位置が悪かった。 そして、セーフティーカー、"Vettel is in the wall!" の文字に驚いた。 映像が無いからね、何かやばいことが起きたっぽいということしかわからず、何が起きたんだよ! と思っていると、そのうちタイヤが崩壊したという情報が。 はぁぁぁ! ピレリはデブリ踏んだせいですみたいな、ほんとかよ。
まぁそんなわけでメルセデスの敵が 1 台脱落だ。 後はしばらくしてライコネンがレッドブルのリカルドを抜いて 4 位まで順位を上げた。 リカルドは今回あまり調子が良くなさそうで、結局タイヤ交換となった。 なんだかんだでメルセデス 2 台が先頭、続いてレッドブルのもう一台、フェルスタッペンはライコネンより古いタイヤでよく粘っている。 妙なタイミングでメルセデスがピットイン、しかも後ろのハミルトンより前のロズベルグのタイヤが柔らかいとは奇妙な戦略だ。 何だよそれと思っていたが最後の数周で 1 位と 2 位の差が一気に縮まった。 同時に 3 位と 4 位も縮まっており彼らは最終ラップに仕掛けるつもりなのか。
みたいな感じだったんだが、最終ラップに黄旗が出ていて、しかしタイム差が縮んだと思ったら表示が変になって、あれ? あれれれ? と、思っているうちにロズベルグがズルズルと順位を落とす! いつの間にか、ハミルトン、フェルスタッペン、ライコネン、ロズベルグの順番になっていた。 またしても映像が無いから、何なのと思っているとメルセデスが接触との情報、なんと!! 上空からの写真も出ていて、ロズベルグがわざとハミルトンを押しだそうとしたようにしか見えない...
そんな感じで天候が悪化しなかった割にはおもしろかったんだけど、接触に関するロズベルグのコメントはイケてない。 後で映像を検索して見てみたけど、ブレーキトラブルでとまりきれなかったという状況だけは理解するが、それで曲がれずに直進してしまってぶつかった、というのではなく、アウト側で少し前に出ていたハミルトンがターンインし始めたのを見てあわててハンドルを切って、それで左前タイヤはちゃんとグリップしていて、ちゃんと曲がり始めている感じなのである。 でも反応が遅すぎて衝突した感じ。 ブレーキトラブルが原因で減速しきれなかったのであれば、あわててハンドルを切っても左前タイヤはグリップせず、タイヤスモークがあがるに違いない。 ハミルトンが寄ってこないからと思い切り膨らんで曲がろうとしていた感じに見える。 極端なことを言えば、カーブの頂点ではなく、反対側のハミルトンだけを見ていた感じがする。
そして、ハミルトンはロズベルグが死角にいたというふうなことをコメントしていたようだ。 なので、何が起きたのかは見えていなくて、たぶんタイヤをロックさせちゃったんじゃないの、みたいな言い方になっている。 確かに、並んで少し前に出ていたからサイドミラーの死角に位置するかも知れない。 それで、イン側には十分なスペースを確保した上でターンインしたというのだから、納得である。
何度もチャンピオンを取るような人は、何かやらかした時のコメントも違うよね。 ロズベルグだって、トラブルで減速しきれずにぶつけてしまったとか、ミラーを見ていてライン取りを間違えただとか、そういういいわけならまだ同じことをしたとしてもごまかせると思うのに、相手がターンインしてきて接触したのには驚いた、とか言うから、コイツはあの位置で相手がターンインしてこないと考えているのか、というふうに周りは思ってしまうわけで。
エミュレーター。 インターレースの細かい実装は後回しにして、とりあえず拡張表示モードのテキスト画面から対応を始める。 っていうか、インターレースの細かい実装はしないかも知れない。 めんどくさいし、POST も拡張表示モードに関してはチェックしていないみたいだし、アクションゲーム等の影響のあるアプリケーションが無いので、20MHz のインターレースを 40MHz のプログレッシブにしてしまうかもw
そしてテクニカルリファレンスを見て、拡張表示モードの説明がめちゃくちゃ少ないのにショックを受けている。 レジスターを見ると単色グラフィックと 2 色グラフィックが別々にあるのだが、画面モードの説明には、グラフィックモードは 2 色と 4 色がある、みたいな説明だし、テキストモードの単色の時の輝度って確か背景色も明るくなってたよね、とか、昔の記憶を掘り起こして実装するしかない。 パレットは 4 色分しかないから、テキストモードではパレットは使われていなかったのだろう、たぶん。
ふと思ったんだけど、ひょっとして基本モードでもインターレースに設定してパラメーターを適切に調整したら 640x400 くらいの解像度で出せていたのかな? グラフィックモードに関しては VRAM のアドレス範囲の問題があって 640x400 の表示はできなかったと思うけど、テキストモードに関しては PC-98 みたいな 25 行日本語表示のチャンスはあったのではなかろうか。
拡張表示モードをテキトーに実装。 正確には拡張表示カードにあたる部分か。 そこにカートリッジを追加すれば拡張表示モードになるというわけ。 過去に自分が書いた BASIC プログラムを探したら、85 桁表示をするプログラムと、33 行表示をするプログラムが見つかった。 残念ながら 33 行表示はうまくいかないケースがあるが、まぁいいや。
一時期触った PS/55 用のプログラムもいくつかあったが、まだその頃はずいぶん意味不明なファイル名の付け方をしている。 その後、高学年の頃は JX でだいぶ無茶なことをやっている。33 行表示はまだ CRTC を触るだけだからいいが (でも CRTC の各レジスターの意味を知らずに手探りで調整したんだからかなりの暇人だが)、BASIC で I/O ポートを読み書きしまくって画面モードを切り替えてしまうプログラムなんてのがあって、我ながら相当むちゃくちゃである。
過去に使っていたディスケットのバックアップの中から、VZ エディターを含むやつを見つけられず。 どっかにあったはずなんだけどな、イメージ化しなかったのかな... パーソナルエディターがなぜか動かないとか、BASIC で ON TIMER がうまく機能していないっぽいとか、いくつか怪しいところも見つかっている。 某日本語ワードプロセッサーソフトは動いたが、テンキーが入力できなくてメニューが選べないところだった。 冷静にファンクションキーでローマ字入力で切り替えたところ操作できた。 ファイル一覧を見ると自分が使い始めるより前の頃の日付のものが残っていた。 某音楽演奏・編集ソフトは起動した。 このソフト、横 720 ドットの画面に対して 640 ドットしか表示しないところや、横線やロゴが縦 2 ドットになっているところを見るに、海外ソフトを移植したものっぽい感じがする。
というわけで夢中になっていたらモニターの電源が入り、何だっけと思ったらフォーミュラ E の時間だった。 最終戦は 2 日続けてになっていて、今日は初日の分の放送だ。 しかし、ニュースサイトでチャンピオンが誰になったかは知ってしまっていて、楽しみが薄れてしまっている。 とはいえ、なかなか激しいレースであった。
明日は 2 日目の放送、ニュースサイトでチラッと見た内容の記憶ではなにやらアクシデントがあって、ファステストラップによるポイントでチャンピオンが決定したみたいな話である。
JX には TIMDEV.SYS というのがあって、詳しくは知らないんだけど、要するに RTC を使って日時の読み書きをするデバイスドライバーである。 想像するに RTC は拡張チャネル経由でつながっていたのかな? 自分でセットアップしたわけではないのでその辺がどうなっていたのかは知らないけど、JX や PCjr って廉価版と言われる割には意外と拡張性が考えられていると思う。
で、TIMDEV.SYS をエミュレーター上で実行すればどんな I/O を行っているのかは見られる。PC/AT 互換機に今も残る CMOS RTC に近いものかと思っていたが、全然違った。NEC の PC-98 シリーズで採用されていたものとも異なる。I/O ポートの範囲は、贅沢にも 360h-36fh までを使用している。36dh に 1 を書き込んで (ラッチだろうか?)、読み取ってステータスの確認? そして 360h-36ch まで連続して読み取り、最後に 36dh に 0 を書き込むという仕掛け。 書き込みは 36fh に何か書き込んでから 360h-36ch に書き込み、最後に 36dh に 0 を書き込むという仕掛け。 どうやら 10 進数を 1 桁ずつ入れていく感じだが、一部書き込みの時だけ +8 されているところがあった。
このデバイスドライバーは、デバイスが無い時には機能せず通常通り 1980-01-01 のままで起動するため、デバイスの存在確認を行っているのは間違いない。 どうやっているのかというと、どうやら 1 秒以上の間隔を開けて 2 度「秒」の一の位を読み取り、正しく進んでいるかを確認しているようだ。 だから、実は起動時に少し待ち時間があったようである。
あと、そういえば、JX で TIMDEV.SYS を組み込んでも日時が設定されなくなっている時期があった。1990 年代のどこか、たぶん後半だったと思うが詳細な時期は忘れた。 あのときは、電池が切れたものと思っていたが、なぜかその後しばらくすると復活した。 デバイスドライバーにこの存在確認の仕組みがあるということは、もしハードウェアに何らかのトラブルが発生して秒のカウントが進まなくなると、TIMDEV.SYS にデバイスが存在しないと判定されてしまうので、そこに無理やり書き込んでリセットしてみるということはできなかったわけか。 なお、PC-98 ではキャパシターが使用されているらしく、電源を抜いて長期間放置した場合 0000-00-00 00:00:00 みたいなあり得ない日時のまま変化しなくなるが、しばらく電源をつないでおけば充電され、動き始める。 確か最初はぐちゃぐちゃに動き始めたんじゃなかったかな。PC-98 には必ず RTC が存在するので、日時を設定してみて復活したかどうか確かめるということも可能だったはず。
昔書いた作りかけのブロック崩しゲーム。1994 年 1 月ってことは小 5 か。 拙作エミュレーターで動かすとなぜか垂直帰線時割り込みが発生せず、中途半端に動かない。 なんだおかしいな、とソースコードを見ると、垂直帰線時割り込みを有効にする代わりに、割り込みコントローラーの初期設定をやり直していた。 えっ、初期設定をすると割り込み許可になっていたのだろうか? マジか...
ソースコードはもっと前の時期のものよりはマシだが、やっぱりなんかいろいろとひどい。 日本語コメントにやたら気合いが入っており、「テキストモードでの実行は保証されません」みたいに書いてあって、テキストモードじゃなくったって誰も保証なんかしないよ、みたいな気分になる。 あと、ただサブルーチンを call するだけのマクロを定義してあったり、サブルーチンにわけてある処理とわけていない処理の基準がよくわからなかったり、単に BIOS を呼び出しているのかと思いきや BIOS のデータ領域を直接書き換えていたり、いろいろおもしろい。 そんな変なとこにこだわるより、とっとと完成させとけよ、みたいな... ま、その 2, 3 年後に C とアセンブリ言語の組み合わせで、テトリス風のミニゲームクローンを遊べるレベルまで作ったわけだけどね。 全部アセンブリ言語ってのは性能の問題で DOS の時代はよくある話だったけど、やっぱり人間の労力で言えば C などの高級言語のほうがずっと軽かったんだよなぁと。
最終戦は初っぱなからチャンピオン争いのふたりがクラッシュして始まった。 その後ファステストラップ合戦だが、思ったより接戦だった。 残り数周のところで 1/10 秒未満の差まで詰めるとはね。 ファンブーストを使ったラップはポイントのつくファステストラップには数えないんだそうで、なるほど。
初めて触ったスクリーンエディターはたぶんパーソナルエディターである。 なぜか拙作エミュレーターで動かないのでデバッグする。 変な命令を実行し始めるので、どこから挙動がおかしくなっているのか追う。 どうもリターン命令で変な番地に飛んでいるらしい。
しかし命令を見ると push %bp や pop %bp があるし、%bp 相対のアドレス指定も多々あるように見える。 これは高級言語で書かれているのか? C か? しかしスタックポインターを caller じゃなくて callee が戻すスタイルだ。 チラッとファイルをダンプしてみたら、ソースコードのファイル名と思われるところに .PAS の文字... Pascal だー。
1980 年代はまだ C がダントツでは無かったのか。 実用的な Pascal といえば、Windows の開発環境として一時期流行った Delphi を思い出す程度だ。
ま、それはともかく、レジスターのダンプを繰り返すと、どうやらメモリーコピーみたいな処理でスタックを壊したり、スタックを使いすぎてデータ領域を壊したりしているらしいことが判明しており、それは何か自分が書いた CPU の命令解釈実行処理等に問題があるとしか思えない状態となっている。 すべてアセンブリ言語で書かれているであろう BASIC や DOS やゲーム等が動いているわけだから、Pascal コンパイラーが出力する特有の機械語に引っかかっているような、そんな感じがする。
どこかで変なところに飛んでいくってんだからログを出してさかのぼってみるしかない。 ひとつはテーブルジャンプ的なところでジャンプ先がおかしいことが判明。 どう見ても命令の途中にジャンプしている。
これは、どうやらこの Pascal コンパイラーはジャンプテーブルをジャンプ命令の直後に置くらしく、プログラムカウンター相対アドレス指定のない 8086 時代のプログラムなので、セグメントが違ったことで全然違うテーブルを参照していたことがわかった。CPU のプロテクション機能もないからリミットを超えていることも検出はできない。 じゃあどこでこの違うセグメントのコードに入ってしまったのか? さらにさかのぼると、一見普通に見えたがよく見るとまたしても命令の途中に飛んでいる部分が発覚。 その手前はというとリターン命令だが、ここでリターン命令を疑わずに、スタック破壊を疑ったものだから手こずった。
結局スタック破壊はこの時点では無く、リターン命令の実装を間違えていた (!) ことによるものだった。 スタックから取り出したアドレスを絶対アドレスとしてジャンプしなければならないのに、相対アドレスにしてしまっていた。 こんな致命的な問題が今まで発覚しなかったのは、near ret にオペランドを指定した形式で、これはリターン命令の中でもめったに使われないものだから。 この命令は callee がスタックポインターを戻す Pascal 呼び出し規約特有のものであり、C やアセンブリ言語で書かれたプログラムではほとんど使われないであろう。
ま、実は BASIC は Pascal 呼び出し規約だったと思うので、何かあっても不思議じゃなかったんだけど。 ちゃんと調べてないけど実際のところ ON TIMER がちゃんと動いていなかったのも同じ原因だったのかも。
懐かしのパーソナルエディター、少し触った感じでは良くできてるんだけど、デバッグ中に見たシステムコールから、これってもしかして DOS 1.x 用? みたいなところはある。 これ、vi ほどではないけどちょっとしたモード切り替えのあるエディターである。 操作なんかまるで覚えていなかったが、PF1 でヘルプが出たのでチラッと見た感じでは、ファイルを開くとか置換とか、そういうのがコマンド指定になっており、よく使う操作はファンクションキーに割り当てられている。 こんなの使ってたんだなー (使ってたのは間違いないがほとんど記憶にない)。
ついでに別のペイントソフトが動かない問題があったが、こっちは落ちる直前に特定のセクターへのディスクアクセスがあるので、どうやらコピープロテクトだな。
テレビでやってた映画『マレフィセント』(原題: Maleficent)。2014 年のアメリカ映画。
妖精マレフィセントが主人公。 子供時代から大人時代になると急にアンジェリーナジョリーになって老けた感じがする。 マレフィセントは、王になる前のステファンに裏切られて翼を失う。 子供からアンジェリーナジョリーになって受けるちょっと老けた印象と、メイクが、裏切られた後の心の闇のようなものをうまく表現している。 オーロラ姫という天使... じゃなかった、ステファン王の娘が誕生したところで、マレフィセントはステファンへの復讐を開始する。
復讐はオーロラ姫へ呪いをかけることによる。 そしてその呪いは本当の愛 (true love) によるキスでなければ解けないとする。 こういうの、なんで呪いが解ける穴を作っちゃうんだろうね! おかげで、話が進むにつれ、あっこれはこういうことになるのかな、って予想がついてきて、実際その通りになった。
翼が復活し、ステファンが死ぬところまでは予想できなかったが、オーロラ姫が天使なのでよしとしよう。 マレフィセントというタイトルからして名前が覚えにくく、あれっと思うことが何回かあったが、この主人公は死なないだろうな、って感じで安心して楽しめるタイプの映画だった。
なお、カラスは人間にされるとあんなに長生きするのか、とか、妖精は翼はなくても他人を宙に浮かせて運べるんだから自分も宙に浮けるんじゃね、とか、そういうしょうもない疑問は忘れることにする。
雨。
寝間着に使っている古びたジャージが少し暑い気がするし、ハーフパンツだとちょっと寝心地が悪いので、汗をよく吸う T シャツと同じような素材のジャージ (下) があればいいなと思って探した。 サンキにあるかなと思ったけど良さそうなのが見当たらず、スポーツ用品店で見つけて、30% OFF の値札のやつを購入。 イオンカードでさらに 10% OFF だとかで、10% ってデカくない? すなわち 37% OFF ということになるわけで、そんなに値引きしてくれていいのか。
先月のじゃがいも掘りのじゃがいも、毎年乾かして砂を落としてから段ボール箱で保存という感じにしていたが、今年は水で洗ってから乾かして段ボール箱で保存にしている。 例によって 7 月は何度か自炊をして消費するわけだが、洗ってあると使うときの印象がいい。 お店で買ってきたやつみたいだ。 よく、洗うといけないなんて言うのだが、洗ったほうが痛んでいる部分を見つけやすくなると思うし、土だって湿っているわけだから、要するにちゃんと乾かせば良いんじゃないかな。 今年は真っ暗にした風呂場で風をあてて乾かした。 もう 2 週間経つが問題はなさそう。
株主優待でもらったカレールウはバーモントカレーの中辛。 あまりに辛くないのでどうやって使おうかと思っていたが、水の量 750ml 指定のところ、500ml で作ってみたら、やっぱり辛くは無いけどだいぶ濃い感じのカレーができることがわかった。 ちょっと塩分が多いような感じの味付けになる。 ま、量も少ないほうが一人暮らしとしては助かるので。
ペイントソフト、音楽演奏・編集ソフトや電子回路学習ソフトなど、いくつかのソフトが、単純に一部のセクターを見つからないようにするというような仕組みのコピープロテクトを用いているらしい。 ディスクイメージをバイナリーエディターで開き、cd 13 で検索すると、それらしき機械語 (!) が見えるので、適当にごにょごにょすればパスできるかも知れない。
ペイントソフトはなんか必要ファイルが見つからないなど変な状態。 わざわざ PC-98 で昔使っていた HDD のバックアップまで見て確認したが (DOS のパーティションには古いものしか無くて、Windows のパーティションに入れてあった)、どうやら DSK から変換する際にミスったようで、そのプロテクトの周辺にあるルートディレクトリーエントリーが一部失われていた。 そこで QEMU で DSKMGR で変換。
-m1 -e0 -w1 -kdi と -o filename の他に、-s1 を付ける必要があった。 なお、FreeDOS では日本語が出ないのに何か確認メッセージが出てきて困ったが、y と答えると終了するので n と答えると良いようだ。
ペイントソフトはジョイスティックかマウスが必要。 エミュレーターにジョイスティックのエミュレーションを適当に用意したところ、何とか動作した。 そして出てきたしょうもない絵の数々... というほど多くはないが、年賀状用に作った絵が「なんでもディスク」とやらに残っていた。
なんと来年はまた酉年なわけだが、そういえばこれ、熱転写プリンターで印刷するのに苦労したんだ。 それで作った専用の画面印刷プログラムは MASM ディスク IV にあった。 ポイントは、はがきみたいな硬い紙に印刷する時にはヘッドの上の部分が接触しないので、ヘッドの下半分だけを使って印刷しようという代物だ。 コードを読むと、行送り量を減らした上で、24 ドットヘッドの下半分 12 ドットずつを画面から読み取って印刷するプログラムになっている。 最初はペイントソフトが出力する印刷データを変換して実現しようとしたが、あまりに難しいので画面印刷で妥協したんだった。LODSB の前に CLD を実行し忘れているのはご愛敬ということで。
Powered by Tomsoft Diary System 1.7.4
Hideki EIRAKU