探索日記

2002年12月 ← 2003年01月 → 2003年02月




2003-01-01(水)

元日にょ

 家の中と近所にある親の実家でだらだらと。

2003-01-02(木)

本日のチェキ!

 一時ファイルを削除しても画像が bmp 形式で保存される場合の対処

2003-01-03(金)

2ch の

 半角二次元板がブラクラ化されました(ワラ。

 好き放題やられてるのでとりあえずスクリーンショットをチェキ。 これの応用でブラクラのコードも書き込まれてます (このような書き込みが現在もできるかどうかは未確認)。

ウンコビーム

 技術的には基本中の基本、window.open()+mailto ストーム。 角煮を見に行く場合は JavaScript 切っておくように。 ただしそれでも、ブラウザによっては <img> タグに仕込まれた mailto が幾つか発動してしまうので注意しる。

 いやー新年早々笑わしてくれるわ。

 参考スレ:【緊急事態】半角二次元ブラクラ化!!【危険】

2003-01-04(土)

M@D

 落としたっきりで放置してた MAD アニメが閲覧・整理。 不完全ファイルや重複ファイルを削除したら HDD が結構空いた。

 今まで知らなかった動画で、出来のいいものはあんまりなくてしょぼーん。 ダンシングレンちゃんが面白いけど画質悪い…。

2003-01-05(日)

本日のチェキ!

 ロード・オブ・ザ・リング 旅の仲間について野良犬の塒)。 冬コミ頒布物をウェブで公開。

やふBB

 電話かけると受話器からモデムのネゴ音が聞こえるんだがこういうものなのか?(まさかな…。

 結局、交換用モデムを送ってくることになった(;´Д`)。 親父はうるせーし、いつになったら接続できるんだ。

2003-01-06(月)

むー

 朝飯食って夕方まで寝て夕飯(;´Д`)。

2003-01-07(火)

本日のチェキ!

 idhcpc.x version 0.11idhcpc0.x version 0.10いがらしのとりあえず)。

 超連射68K オリジナルサウンドトラック(2002βVersion)全曲解説 @寒さに弱いるざりんHP(ネタ元:HK-DMZ PLUS.COM)。

 『X680x0電源装置復活でバビンチョ!』訂正情報XPS)。

2003-01-08(水)

アニメ新番組

 ゴミばっか…。

2003-01-09(木)

本日のチェキ!

 りあるユーシィ by 山本麻里安。 萌え。

 最近 ETERNAL DIVIDE の ZONOKA909 がいい感じです。 冬コミではうっかり忘れてて一冊も買えなかったので、夏コミでは必ずチェキしたいと思います (機会があればそれ以前でも)。詳しくは公式ホームページの http://www.ete-div.com/http://www.ete-div/com/http.//www.ete-div.com/ あたりを参照のこと。表示されないけど(ぉ

 話は変わるけどスキーのジャンプ・ペアの動画を落とし損ねたので持ってる人がいたら下さい。 おながいします。

やふBB

 予想通りモデムを交換しても認識せず。 遅くなってしまったので明日テクニカルサポートに電話することにする。

2003-01-10(金)

Nereid

 今ごろになってようやく Nereid を第二期配布版のものに交換する。 usbmon の UI まわりを少しいじってからセットアップを試みると、 速度判別で失敗する。 自分ではしっかりとしたコードを書いたつもりだったが、 SL811HST のリビジョンによる挙動の違いに引っ掛かってしまったか。

 この件とは関係ないと思われるが、エラッタも一新されているので、 とりあえずエラッタ情報の翻訳をしてみようかと思う。

SL811HS/T エラッタ情報

 情報源は 2002/04/04 発行の Errata 1.6(sl811errata.pdf)。 Nereid に関係するエラッタのみ(Revision 1.2&1.5 のスレーブモード)。 無保証。かなり適当。

 Revision 1.2 にあるエラッタ

・USB-A / USB-B をトグルで使用できない

 SL811HS/T にはレジスタセットが A と B の二通り用意されていて、 片方のレジスタセットに設定した命令を実行中に、 もう片方のレジスタセットに次に実行させたい命令を設定することができ、 これにより素早い命令発行ができる。 しかし、Revision 1.2 ではバグのためトグルで使用すると正常動作しない。

 対処方法:トグルで使用せずに、どちらか片方だけを使う。

・Hub を介して Low Speed デバイスから読み込むと不正なパケットを発行する

 Hub に接続された Low Speed デバイスからデータを読み込む手順は以下の通り。

  1. SL811HST が自動的に、Hub に PRE パケットを送信する(Full Speed)
  2. デバイスに IN パケットを送信する(Low Speed)
  3. デバイスから DATA パケットを受信する(Low Speed)
  4. SL811HST が自動的に、Hub に PRE パケットを送信する(Full Speed)
  5. デバイスに ACK パケットを送信する(Low Speed)
  6. 本来ならこれでトランザクションが完了するが、Revision 1.2〜1.3 ではバグのため、 不正なパケット("3C" と呼ばれる)を Low Speed で勝手に Hub に送信してしまう。

 いくつかの実例では、EOP において Full Speed モードへの復帰が失敗し、 次回の転送が誤って Low Speed で行われる。

 対処方法:ACK パケットを送信した直後に、ダミーの IN パケットを Full Speed でデバイスに送信する。この IN パケットは、16〜17 マイクロ秒以内に送信 (パケットを書き込んで ARM ビットをセット)する必要がある。

 備考:デバイスから NAK パケットが返ってきた場合は問題はない。

・Hub を介して Low Speed デバイスに送信または受信すると不正なステータスを発生させる

 PRE → SETUP or IN or OUT → DATA → ACK or NAK or STALL からなるトランザクションを実行すると、Revision 1.2〜1.3 ではバグのため、 D+/D- のデータ信号が不正な電圧になる(USB2.0 では SE1 と呼ばれる状態)。 これにより、SOF が破壊される。

 対処方法:なし。 Hub 以降の転送速度が遅くなる。

・SOF の開始とほぼ同時に SETUP/IN/OUT を発行すると無視される(ことがある)

 SOF が開始する瞬間の前後各 4 マイクロ秒までの間に、SETUP・IN・OUT パケットを書き込むと、 Revision 1.2〜1.3 ではバグのため、ときどき無視されてパケットが発行されない。

 対処方法:もう一度同じパケットを設定してやり直す。

 Host Control Register の SOF ビットをセットしておけば、 ハードウェアによる SOF 生成を妨げることはない。 しかし、SOF の直前もしくはその頃にコマンドを書き込んではいけない。

・基本方針

  1. SOF カウンタの値が小さすぎる時はコマンドを書き込まない
  2. 前回のパケットが転送完了したか、USB_Done 割り込みで調べる

 Revision 1.5 にあるエラッタ

・Interrupt Status Register の Babble Detection が廃止された

 Revision 1.5 以降では、ゲートレベルのネットリストのゲート数を削減する為に Interrupt Status Register の Babble Detection が廃止されますた。 もうサポートされてません。読み込むと 0 が返ります。

 対処方法:使わない。

・EOF1 中に Hub から SE0 を送信されると SOF を発行しなくなる。

 Hub によっては EOF1 時間中に SE0 を送信してくるものがあるが、 Revision 1.4〜1.5 ではバグのため、クロックが停止して SOF を発行しなくなる。 Hub に Low Speed デバイスを繋げた時に、この問題が発生したという事例がいくつかある。

 対処方法:EOF1 時間中に SE0 を送信してくる Hub を使わない。

 Cypress の全ての Hub 等いくつかの Hub には、EOF1 時間中に SE0 を送信しないようにするオプションがある。

 EOF1 時間中に SE0 を送信しない Hub の一覧や、Cypress の Hub でこの機能を停止させる方法については、Cypress USB サポートに連絡をとること。

 Revision 1.2 及び 1.5 の両方にあるエラッタ

・Low Speed モードでは SOF に対する同期が適用されない

 Revision 1.2〜1.5 では、Host Control Resister の SYNC to SOF ビットは Full Speed モード用に設計されている。このビットは、ソフトウェアが 1ms フレーム以内に完了できない場合にのみ使用するべきである。 このビットをセットすると、パケットの送信を自動的に次の SOF まで遅らせる。 Low Speed モードで SOF ビットをセットするとパケットが送信されないかも知れない。

 対処方法:Low Speed モードでは SOF ビットをセットしない。パケットが 1ms フレーム以内に完了しない場合は、代わりにファームウェアで次の EOP の後までパケットを送らないようにする。

YBB

 夕食の後、やふぉーBBがまだ開通しない件の関係で姉貴とぷち喧嘩。 俺が液晶モニタ蹴り飛ばしたら、奴は飛び蹴りしてきた(ワラ。 液晶モニタは安物だから別にどうでもいい。

 馬鹿兄弟よのう…。

2003-01-11(土)

本日のチェキ!

 「ごきげんよう」は本当に使われてるの? お嬢様のお部屋 (ネタ元:HK-DMZ PLUS.COM。上のネタとは違うページの Xboxでか過ぎ生えてこないんです・・・ も(・∀・)イイ!)。

 秋葉原のパーツ激戦区にステーキ店がオープン?。 エロ本屋 → ステーキ屋 → パーツ屋(;´Д`)。

はー

 気分がおさまらないので(馬鹿…)、ナノカ&パルフェ抱き枕カバーをメールで注文してみた。

2003-01-12(日)

電源修理オフ

 まぁそういうことで。気が向いたら後で何か書くかも。

2003-01-13(月)

あー

 一日中寝てた。

2003-01-14(火)

本日のチェキ!

 横浜に出来たメイド喫茶かふぇ・あるふぁいんを偵察する教官。 うちからだと横浜は遠いので自分は行かないであろう。

2003-01-15(水)

本日のチェキ!

 ITL Factory、ひっそりと閉鎖。

うーむ

 某エミュレータの作者様から、某 RetroPC の新年会にて小一時間問い詰めたいとの召喚状が届く。 (( ;゚Д゚))ブルブル

 問題は新年会には招待されてないってことだが。

2003-01-16(木)

本日のチェキ!

 3人打ちオセロ (情報元:かーずSP)。 1P vs CPU vs CPU でプレイすると、CPU がコンビ打ちしてきてキツイ。 意図的にやってる訳じゃないだろうけど、 片方が暴牌切ってもう片方がすかさずそれを回収しつつ盤面を荒らしてくれるのでムキー!!

うぷ板…

 infoseek に置いた CGI に直リンすると 403 吐かれるみたいですな。 Proxomitron でリファラいじってたから今まで全然気が付かなかったよ。 というわけで修正。

2003-01-17(金)

本日のチェキ!

 [local.etc]。 ADPCM の周波数上げはあまりメリットが無い為、一般には見向きされなかった模様。 資料漁ってたら SaTa. さんが PRO を改造した時のドキュメントが出てきた(・∀・)。 うちだと MDXWin+MXDRVg で BUBM15.MDX がコケる。ぴろぴろぴろ〜。

RetroPC の

 根回しされますた(( ;゚Д゚))ブルブル。 主催からは何も言ってこないけど…。

2003-01-18(土)

本日のチェキ!

 ダイアモンドアプリコットが mankai.co.jp 取得 (ネタ元:X68000スレ@2ch)。

 ちさーんの何かするページ-かふぇ あるふぁいん訪問記。 激しく微妙に違う模様…(ネタ元:HK-DMZ PLUS.COM)。 もいっちょ。 Un happy new year. (ネタ元:BRAINSTORM)。

mint

 ヒストリファイルまわりをずんずん改造。激しく今更の予感。 しばらく動作試験して、大丈夫なようなら公開するにょ。

 そのあと、windrv.sys の改造。 Human68k 内蔵のデバイスドライバでは、 DOS _FILES で存在しないディレクトリ下のファイルを検索した場合 -3 が返り、 実在ディレクトリ下の存在しないファイルを検索した場合 -2 が返る。 ところが、windrv.sys ではどちらの場合も -2 を返してくるので、 エラーコードを厳密に解釈するソフトは期待通り動作しない。

 例えば、mint v3 で windrv に対してディレクトリをコピーしようとすると、 この仕様相違にひっかかってコピーに失敗する。 コピー先ディレクトリを作成するかどうか調べようとして DOS _FILES を使うと -2 が返ってくるので、既にディレクトリが存在していると誤認し、 その結果ディレクトリを作成せずにファイルをコピーしようとしてしまう。

 今のところ mint 以外に、この仕様相違が影響するソフトがあるのは分からない。 mint 以外で windrv を操作するような作業はあんまりしないし。
 で、面倒だったので、エラーコードが -2 だった場合は全部 -3 を返すように書き換えてみた。 とりあえず mint でディレクトリコピーが出来るようになったのでよしとする。 本来ならエミュレータ側で修正すべき問題なので、 あんまり真面目にやる気にはならんのですよ、少佐。

 他にも、DOS _CHMOD でディレクトリの属性を取得しようとすると必ずエラーになり -2 を返してくれるので、mint や rm、rmdir 等でディレクトリの削除が出来ないなどの問題がある。 激しく面倒なのと、削除出来ない分にはむしろ安全な気がするので、こっちは放置ぷれい。

 あと、windrv.sys については、せっかくだから実機で実行しても帯らないようにしてみた。

RetroPC 新年会

 池袋で See-Saw とかの CD と同人誌を買う。 秋葉原でジャンク扱いだけどケーブル二本入りでお買い得な1000円の ATA/133 増設カードと、 DVD-R メディアを買う。

 そのあと両国に行って RetroPC の新年会。なべー。 XM6 の話(というか EX68 由来の windrv の仕様の話)したり シャープ MZ シリーズのエミュレータの話を聞いたり。

2003-01-19(日)

アタマ痛て〜〜〜

 風邪を引いてしまったのか…、寒さと頭痛で目が覚める。 ヒーターと加湿器をつけて、ホッカイロを二個布団に投入。 台所に転がってたレモンの切れ端とはちみつでレモネード作って飲んで寝る。

 三時間ごとくらいにつらくて目が覚めるので、加湿器の水タンク(っていうかペットボトルだけど) を補給してまた睡眠。

 電車に乗ったらどうやら乗り換えを間違えたらしく、見慣れない風景に。 だんだん山の中に入っていくみたい。 帰れなくなりそうだったので慌てて降りて朽ちかけた案内板で現在地を確かめると、 ここは蔵王らしい。そうは見えないけど。 ちなみにあのまま電車に乗ってたらすて山というところに行ってしまうようだ。 すて山?(;´Д`)。どうやって帰ったかは覚えていない…。

 という夢を見たりしながら一日中くたばってますた。

2003-01-20(月)

ふにゅー

 引き続き寝まくる。 ハッと目が覚めると全身ものすごい汗をかいたりする。 ウォータースライダーに水が流れて無くても下まで滑れそうなくらい。 こんなに汗をかいたのは久しい。

 ずっと寝てたおかげで、夜にはかなり楽になった。

2003-01-21(火)

本日のチェキ!

 WinX68kv0.65u01 (ネタ元:RetroPC.NET)。 ソース有り。WinX68k の ROMEO 対応版ですが、ROMEO が刺さってなくても使える模様。

 風邪(・∀・)完治!。

2003-01-22(水)

本日のチェキ!

 カフェ・あるふぁいん関係まとめ。 教官殿ちさーんさんHamurabi さんEFA さんhisagi さん(1/18)MU-6 さん求人情報Google 検索。 レポートは結構あるけど、他の客は一組のみってパターンが多い。大丈夫か(;´Д`)。 みんな監視プレイに(( ;゚Д゚))ブルブルしてますな(ワラ。

2003-01-23(木)

 雪、雪だよ〜。カキ氷食べて学校行くよ〜。(行かねえよ

 XM6 version 1.05。

MZ エミュレータ

 新年会でシャープ MZ シリーズのエミュレータの作者さん達と同じテーブルになった記念リンク。

機種 エミュレータ HP 作者
MZ-80B
MZ-80B2
MZ-2000
MZ-2200
EmuZ-2000 EmuZ-2000のホームページ EmuZ-2000 さん
MZ-2500 EmuZ-2500 EmuZ-2500 - MZ-2500 Emulator for Win32 武田さん
MZ-700 MZ700WIN Marukun's Web まるくんさん
MZ-80K
MZ-80C
MZ-80E
MZ-1200
MZ80K MZ-80K/C/E/1200 エミュレータ EM-Z さん

 この四人で TEAM MZ 結成らしぃ。

2003-01-24(金)

本日のチェキ!

 Seagate製「Barracuda」シリーズに1プラッタ80GB採用の新モデルが登場!Akiba2GO!)。 80GB プラッタ キタ━━━━━━(゚∀゚)━━━━━━ !!

2003-01-25(土)

はー

 だらーり。

2003-01-26(日)

DivX5.0.3

 インストール → 右下のあたりの画像が壊れる → アンインストール → 萎え。

2003-01-27(月)

本日のチェキ!

 UNIX MAGAZINE のみるく氏の 68 の世界で有名なみるく氏とは別人らしい。 つーか某ぺけろく教のログを読んでみたんだがかなりアレな人物だな。

 DivX5.0.3 は DivX の Decoder Configuration を起動し、 Quality Settings タブの Disable Logo にチェックを入れるとノイズが載らなくなるらしい。 まだ試してないけど。

2003-01-28(火)

本日のチェキ!

 WinX68k高速版 v0.75。 状態セーブの互換性がややこしいが、 バージョンアップしたら状態セーブを持ち越さないようにするのも一つの手。

HAPPY★某

 本屋でたまたま目に付いた『HAPPY★LESSON ママ先生は最高!』(森真之介)、 パラパラと見てみたらなかなか良かったので買ってみた。 一般向け漫画単行本を買うのは久しぶり。その前はラポートの Kanon のアンソロジーの19号だったか… (一般向け漫画単行本とは言わない気もするが)、更にその前に何を買ったかはもう覚えていない。 成人向けならコンスタントに買ってるけど。

 HAPPY★LESSON は年上ばかりの上に、義理とはいえママという近親関係に嫌悪感があり (妹は好きなくせにとかゆーな)、 ささきむつみの固めの絵柄にも飽きてしまい、正直好きではなかったのだが、 この漫画は良い。

 柔らかい絵柄で、話も面白いし、原作の設定の無茶さ加減もうまく消化できてると思う。 あ、ちょっと誉めすぎかも。OVA のアレな品質に比べてずっと良かったので好印象を受けたので、 そのあたりを差し引けばまあ普通の出来か。

 ただ、既に HAPPY★LESSON という企画を知っている人を読者層と見なしてるのか、 なぜ五人のせんせいと同居生活を送るようになったかの描写が完全に省かれていて分かりづらい。 知らない人は入っていけない世界になってる。 目次に一頁も使ってるのを半分にして、文章でプロローグいれればいいのに。 それから、高校教師の筈なのになんでこんなに自由時間があるんだとか、 綾波せんせいなんてただ居るだけの存在になっちゃってるとか、いまいちなところもちらほら。

 著者、というかクレジットは作画ということになっている森真之介先生のホームページはここ → ラブラブ天玉セット。 同人は佐野倉隆紀という名義で活動しているそうだ。

 いやーそれにしても商業誌で連載してる作家なのに、 検索してもほとんど情報が出てこないのは驚いた。 最近は雑誌・作家・作品といったものの絶対数が多くて、その分読者が分散しているのだろうか。 単に人気ないだけだったらどうしよう。俺は結構好きになったんだが。

2003-01-29(水)

windrv

 WinX68k v0.61 における windrv の挙動について (EX68・WinX68k 高速版・WinX68k うさ版各最新版も同じと思われる)。

ITA TOOLBOX の rmdir で windrv 上のディレクトリの削除に失敗する
 ITA TOOLBOX の rmdir や、rm -r で windrv 上のディレクトリを削除しようとすると、 「このようなファイルやディレクトリはありません」と表示されて削除が行われない。 mint v3 の &delete でも「error failed!」となる。

 rmdir の動作を trace で調べてみると、以下のようになる。
setblock(0x1708f0,1802(0x70a))=0
malloc(11(0xb))=1511440(0x171010)
chmod("RMDIR_TEST",4294967295(0xffff))=4294967294(0xfffffffe)(No such file or directory)
write(2,0x170e8c,7)=7
write(2,0x171010,10(0xa))=10(0xa)
write(2,0x170e91,2)=2
write(2,0x170da0,34(0x22))=34(0x22)
write(2,0x170ef7,2)=2
exit2(2)=?

Exit code 2 (9 System Calls)
 削除に先立って指定されたパス(ここでは RMDIR_TEST)の属性を取得しようとするのだが、 RMDIR_TEST ディレクトリが存在するにも関わらず DOS _CHMOD が -1 を返してくる。 これにより、rmdir が存在しないディレクトリを指定されたものと判断して終了してしまう。

 ちなみに、DOS _CHMOD を使わずに削除を行うツール、例えば COMMAND.X の rmdir コマンドなどでは削除に成功する。

 Human68k ファイルシステム上のディレクトリを削除する場合は以下のようになり、 rmdir が成功する。
setblock(0x1708f0,1802(0x70a))=0
malloc(11(0xb))=1511440(0x171010)
chmod("RMDIR_TEST",4294967295(0xffff))=16(0x10)
chmod("RMDIR_TEST",16(0x10))=0
rmdir("RMDIR_TEST")=0
exit2(0)=?

Exit code 0 (6 System Calls)

 windrv を処理するソースファイル windrv.c を見ていこう。 まず、DOS _CHMOD を呼び出すと windrv.sys 内で winport(0x00e9f000)に 0x46 が書き込まれて、WinDrv_Write が呼ばれる。
void FASTCALL WinDrv_Write(DWORD adr, BYTE data)
{
  if (adr>=0xe9f800)
    CDROM_Write(adr, data);
  else if (adr>=0xe9f000)
    WinDrv_Command();
(以下略)
 WinDrv_Write() から WinDrv_Command() へ。
//----------------------------------------------------------
// コマンド解析して各ルーチンを呼ぶ
//----------------------------------------------------------
void WinDrv_Command()
{
(中略)
    //ファイル属性
  case 0x46: case 0xc6:
    res = file_atr( a5+13, Memory_ReadD(a5+14) );
    Memory_WriteD( a5+18, res );  //result status
    break;
(以下略)
 WinDrv_Command() から file_atr() へ。
// -------------------------------------------------------
// file_atr(int atr_adr,int pname)
// ファイル属性の読み出し、書き込み
// -------------------------------------------------------
int file_atr(int atr_adr, int pname)
{
  int atr = Memory_ReadB(atr_adr);  //-1なら取得
  char lpszSearchFile[MAX_PATH];  // 検索するファイルの名前のアドレス
  HANDLE file;
  WIN32_FIND_DATA lpffd;  // 返される情報のアドレス

  gen_file_name(lpszSearchFile, pname);  //namestsからpath+8.3形式へ変換
  file=FindFirstFile(lpszSearchFile, &lpffd);
  if (file==INVALID_HANDLE_VALUE)
    return -2;

  if (lpffd.dwFileAttributes&FILE_ATTRIBUTE_DIRECTORY)
  {
    //ディレクトリなら無効。
    FindClose(file);
    return -2;
  }
 と、このように、ディレクトリが見つかった場合は問答無用で -2 を返している(この値がそのまま DOS _CHMOD の返り値となる)。 これが原因なので、ここは何が見つかってもそのまま処理しなければならない。

 ちなみにその直後のコード。
  FindClose(file);
  if ((atr&0xff)==0xff)  //問い合わせ
  {
    //読み取ったファイルの属性をattr_adrに設定する。
    Memory_WriteB(atr_adr, (BYTE)conv_atr(lpffd.dwFileAttributes));
  }
(以下略)
 引数の下位バイトが 0xff かどうかで属性の取得・設定を切り分けているが、 引数の1ワードが 0xffff かどうかを見るようにすべきである (Human68k ファイルシステムの場合は 0xffff かどうかを見ているので)。

 Human68k ファイルシステムではディレクトリからディレクトリ属性を外したり、 ファイルにディレクトリ属性を付けたりといった危険な設定が可能だが、 windrv であればそういう指定だけ無視して、 他のビットは(ディレクトリでも)そのまま変更してしまえばよいのではないかと思う (xconv_atr() の変更も必要だ)。

mint v3 で windrv に対するディレクトリコピーに失敗する
 mint v3 の &copy/&move 系で windrv に対してディレクトリのコピーを行おうとすると 「error failed!」と表示されてコピーに失敗する。 同名のディレクトリを予め windrv 上に作成しておくと、コピーは成功する。

 メッセージを注意深く見てみると、Human68k ファイルシステム上にコピーする場合は 「make dir」を行ってから「copy file」となるのだが、windrvの場合はいきなり 「copy file」となる。コピー先ディレクトリを作らなければならないのに、 スキップしてしまっている。

 例によって trace で調べてみる。 G:/ にある COPY_TEST ディレクトリをマークして、T:/ にコピーしようとしているところ。 長いので必要な部分だけ掲載。
files(0x13037e,"T:/*.*",255(0xff))=0
super(NULL)=33636(0x8364)
super(0x8364)=33570(0x8322)
mvdir{getid}(0)=1299596393(0x4d764469)
files(0x1301bc,"G:/COPY_TEST",255(0xff))=0
files(0x13037e,"T:/COPY_TEST/*.*",255(0xff))=4294967294(0xfffffffe)(No such file or directory)
files(0x1301bc,"G:/COPY_TEST/*.*",255(0xff))=0
nfiles(0x1301bc)=0
nfiles(0x1301bc)=0
files(0x130176,"G:/COPY_TEST/foo",255(0xff))=0
conctrl{color}(2,7)=0
print(" copy file : ")=0
conctrl{color}(2,3)=0
print("COPY_TEST/foo")=0
newfile("T:/COPY_TEST/foo",32(0x20))=4294967295(0xffffffff)(Invalid function call number)
conctrl{color}(2,2)=0
print("\x09 ・・・・・ error failed!")=0
 mvdir というのは独自に拡張したファンクションコール DOS _MVDIR で、 &copy/&move 系の共通初期化ルーチンから呼び出されている(これは別にどーでもいい)。 その二行下、files(0x13037e,"T:/COPY_TEST/*.*",255(0xff)) というのが今週のビックリドッキリメカニズムである。 実は T:/COPY_TEST が存在するかどうかを調べずに、いきなり T:/COPY_TEST ディレクトリ下にファイルがあるかどうか検索を掛けている。 というか、実はこのコールで T:/COPY_TEST が存在するかどうかを調べていたりする。

 さて、その DOS _FILES で -2 が返されているが、mint のルーチンでは -2 が返った場合 T:/COPY_TEST は既に存在する、という解釈をする。 その結果 T:/COPY_TEST ディレクトリを作成せずに newfile("T:/COPY_TEST/foo",32(0x20)) を実行してしまい、あえなく失敗に終わる。

 windrv ではなく Human68k ファイルシステム上で同じ操作をした場合は、以下のようになる。
mvdir{getid}(0)=1299596393(0x4d764469)
files(0x1301bc,"G:/COPY_TEST",255(0xff))=0
files(0x13037e,"D:/COPY_TEST/*.*",255(0xff))=4294967293(0xfffffffd)(No such directory)
conctrl{color}(2,6)=0
print(" make dir : ")=0
conctrl{color}(2,3)=0
print("COPY_TEST")=0
mkdir("D:/COPY_TEST")=0
chmod("D:/COPY_TEST",32(0x20))=0
open("D:/COPY_TEST",1)=11(0xb)
filedate(11(0xb),775815592(0x2e3e01a8))=0
close(11(0xb))=0
chmod("D:/COPY_TEST",16(0x10))=0
print("\x09 ・・・・・ completed.")=0
print("\x0d\x0a")=0
files(0x1301bc,"G:/COPY_TEST/*.*",255(0xff))=0
nfiles(0x1301bc)=0
nfiles(0x1301bc)=0
files(0x130176,"G:/COPY_TEST/foo",255(0xff))=0
conctrl{color}(2,7)=0
print(" copy file : ")=0
conctrl{color}(2,3)=0
print("COPY_TEST/foo")=0
newfile("D:/COPY_TEST/foo",32(0x20))=11(0xb)
open("G:/COPY_TEST/foo",0)=12(0xc)
 まず、files(0x13037e,"D:/COPY_TEST/*.*",255(0xff)) の返り値が -2 ではなく -3 となっている。 mint のルーチンでは -3 が返った場合 T:/COPY_TEST は存在しない、 という解釈をする。そして DOS _MKDIR でコピー先ディレクトリが作成されて、コピーが成功している。 windrv へのコピーが失敗するのは、本来 -3 が返るべきところで -2 が返っているのが原因である。

 ちなみに mint の方の該当部分はコレ。cpmv.s から。
* ディレクトリ存在検査 ------------------------ *
* in    d0.l    DOS _FILES バッファ
*       a0.l    ディレクトリ名
* out   d0.l    0:存在する -1:存在しない
*       ccr     <tst.l d0> の結果

is_exist_dir::
.ifdef NO_LNDRV_BUG
                move    #$01_ff,-(sp)
                pea     (a0)
.else
                move.l  a1,-(sp)
                move    #$00_ff,-(sp)
                pea     (a0)
                lea     (a0),a1
                STREND  a1
                lea     (files_wild,pc),a0
                STRCPY  a0,a1
                movea.l (sp),a0
.endif
                move.l  d0,-(sp)                ;バッファ
                DOS     _FILES
                addq.l  #10-4,sp
                clr.l   (sp)
                tst.l   d0
                bpl     @f                      ;ディレクトリ有り
                addq.l  #2,d0
                beq     @f                      ;$fffffffe でもディレクトリ有り
                subq.l  #1,(sp)
@@:             move.l  (sp)+,d0
.ifndef NO_LNDRV_BUG
                sf      (-(.sizeof.('*.*')+1),a1)
                movea.l (sp)+,a1
.endif
                rts
 0 以上の数または -2 が返った時はディレクトリがある、と解釈する。

 Human68k がどのように DOS _FILES を処理しているかも解説しようかと思ったのだが、 ここに貼るには長すぎるので残念ながら省略する。 Human68k ファイルシステムを処理する内蔵のルーチンでは、 DOS _FILES で指定されたディレクトリが存在しない場合は -3、 ディレクトリはあるが指定されたファイルが存在しない場合は -2 を返すようになっている。

mint v3 で &change-drive-menu に windrv が出てこない
mint v3(恐らく v2 でも)で &change-drive-menu を実行しても、 ドライブ一覧に windrv が表示されない(&change-drive t: 形式で直接指定したり、 &drive-increment/decrement を使えばドライブ変更は出来る)。

 これは Human68k の仕様で、windrv のようなリモートファイルシステムは DOS _GETDPB が必ずエラーになるのが原因。windrv 側では対処できない (2003/01/09 訂正。詳細はこちらを参照)。

 というのも不便なので、自分は Human68k と windrv.sys にパッチをあててリモートファイルシステムでも DOS _GETDPB を使えるように改造している…。

 mint で DOS _FILES の返り値が -2 と -3 のどちらかを見ているのは、 ちょっとやりすぎだったかも知れない。 なんでそんなややこしいルーチンを書いたのか今ではもう覚えていないが、 多分その方が面白くてコンパクトになるからとか、そんな理由だろうか。 そのせいで windrv 上では不都合が出たわけだが、windrv 以外では(知る限りでは) 問題は起きていないし、windrv 自体が全体的に適当なエラーコードを返してくれるので、 windrv に起因する症状ということにして、mint を変更するという方向には行っていない (ただし要望があればすぐに mint を書き換えるつもり)。

windrv 上の (V)TwentyOne、lndrv、execd

 考えたこと無かったが…。 TwentyOne の +C は効かないような気がする(Windows 自体、大文字小文字同一視してるし)。 lndrv と execd は、windrv がリンク属性と実行属性に対応してないから全く効かないっぽい (windrv 上のファイルをリンク先にするのは出来るか)。

 結局、厳密な挙動を知る為には Human68k を解析した上で各ソフトのソースコードを読んでいくしかないと思われ。

2003-01-30(木)

本日のチェキ!

 X1版「テトリス」隠しメッセージ (ネタ元:BRAINSTORM)。

2003-01-31(金)

あー

 だらだらと。




goto ../index.html