<pre>表示

-

ポチ - reiria

2017/01/01 (Sun) 21:17:26

個人スポンサー元日ポチっとな。

Re: ポチ - reiria

2017/04/02 (Sun) 21:30:37

祝ミクAMGスパ参戦

個人スポンサー追加御祝儀ポチっとな。

Re: ポチ - reiria

2017/04/09 (Sun) 21:07:58

祝ミクAMG岡山優勝

個人スポンサー追加御祝儀ポチっとな。

Re: ポチ - reiria

2017/05/03 (Wed) 17:09:02

祝ミクAMG富士PP

Re: ポチ - reiria

2017/06/12 (Mon) 22:08:23

SPA超漢ポチっとな(^^;;;;;;

Re: ポチ - reiria

2017/07/28 (Fri) 19:54:16

オールージュをやっつけろ緊急ポチっとな(;_;)

Re: ポチ - reiria

2017/11/12 (Sun) 23:27:17

祝ミクAMGシリーズチャンピオン

今年は過去最高額ポチったので掲示位置も1枚目だったし優勝出来て嬉しいヌ(;_;)

Re: ポチ - reiria

2018/01/01 (Mon) 18:01:21

個人スポンサー元日ポチっとな。

Re: ポチ - reiria

2018/07/27 (Fri) 12:40:50

10H提灯(小)ポチっとな。

Re: ポチ - reiria

2019/01/01 (Tue) 12:07:32

個人スポンサー元日ポチっとな。

去年の 1 月、勝手に電源オンオフを繰り返すようになった Ra266 を今年は何とか復活させたい。
この不具合、今まで何度か噂に聞いたことはあったけど、とうとううちの Ra266 もなってしまった(;_;)
仕方ないので 2018 年は Ra266 のコンセント抜いて放置、丸一年殆ど使わなかった。
新品購入から約 19 年間ほぼ毎日、よく動いたほうかも知れない。

症例と解決策を求めてネットをさまよい、
http://kokoromomori.blog103.fc2.com/blog-entry-12.html
によると、スイッチ清掃で復活したものの、放置してるだけで再発して症状も悪化したらしい。

当初は電源交換とかそこそこやる気あったものの、
今時、形状が 98 にぴったりな ATX 電源の現行品なんぞあるんかいなと途方に暮れ、
適当に健康そうな Ra43 とかゲットして Ra266 に移植したほうがお手軽に思えてきて結局何もしていない。
あと Xa16/R16 が思ってた以上に厄介で常用マシンに出来ていない(;_;)

Re: ポチ - reiria

2019/03/01 (Fri) 22:48:44

早速 TK-FCM103BK ゲットしましたが、PS/2 も 98 もばっちり使えました。
かなり満足というか、格安テンキーレスとしては我が人生初の歴史的キーボードではないかと(^^;
配列や筐体が至極普通というのが何より嬉しい感極まる一品ではないでしょうか(;_;)

当方は PS/2 状態の USB キーボードを AT(USB) 98 へコンバーターで共有する環境ですが、
TK-FCM084BK は切り替えタイミングか何かで認識されなかったり、オートリピートのスピードが変わったりで、
そのへん諦めて使う感じだったのですが、TK-FCM103BK は今のところ快調です。

あと、昨年末、やたら値下げされていた 400-SKB057BL をポチったのですが PS/2 では使えませんでした。
400-SKB057BL の軍資金で TK-FCM103BK を 5,6 枚買えたかと思うと悔やまれます(^^;

Re: ポチ - KAZ.K

2019/03/02 (Sat) 09:53:11

そういえば勝手に電源が入る不具合、ものすごく単純に電源スイッチ自体の絶縁不良という線はありはしませんかね。うちのとは別のXv(何かの計測器の制御用だったはず)の事例なんですが、たしか当初の症状は電源スイッチおしてもたまに電源が入らないで、それに時折勝手に電源が切れるが加わったあたりでうちに話がきて、マザー側でコネクタひっこぬいてテスター当てたら数十kΩくらいのオーダーで普通に漏れていたという。今にして思えば運用的に使っていない間はラックごと他の機材と入れ替えでいちいちコンセント引っこ抜かれて移動されていたので、勝手に電源が入る方は気がついていなかっただけじゃないかしらん。似たような症例が他でもあるというなら、もしかしたら使われているスイッチの基板が微妙に水を吸いやすかったとかあるのかも?

Re: ポチ - reiria

2019/03/02 (Sat) 12:19:52

> 当初の症状は電源スイッチおしてもたまに電源が入らないで、それに時折勝手に電源が切れるが加わった

いやあ、まさにその流れにそっくりでありまする(^^;;;;;

スイッチ押しても起動しないってのが何度かあって、たまたま何かの偶然かなぐらいに思ったものの、
でも長年こんなこと一度もなかったような・・・と一抹の不安を感じつつ(^^;

で、勝手にオンオフ繰り返すようになって、最初は発症する間隔が長くて 1 週間以上あった気がするのですが、
どんどん間隔が短くなり、メモリカウントも終わらずにオンオフ繰り返すようになって、
そうなると ITF が何か黄色のエラー表示してリセット掛ける場合もあるようで、
激しいオンオフ連射で HDD や CDD も物理的に壊れるんじゃないかと不安になって放置を決意(;_;)

Re: ポチ - reiria

2019/03/02 (Sat) 12:29:44

> メモリカウントも終わらずにオンオフ繰り返すようになって

これはオンオフ繰り返すというより、リセット繰り返すが正確な気もする、たぶん(^^;

Re: ポチ - reiria

2019/03/02 (Sat) 12:54:12

カレンダとメモリスイッチは保持されているので電池は大丈夫そうに思えますが、
自動電源オン機能のタイマが暴走して現在日時と時々一致してしまう可能性とかあるんだろうか、
でもそれなら勝手に電源オフはいったい何なんだという。

あ、タイマだけでなくて、モデムからの電源オン機能もありましたな。

Re: ポチ - reiria

2019/04/20 (Sat) 10:22:05

Ra266 が使えなくて RvII26 使う時間が増えたんですが、携帯を近くに置くとノイズが鳴ること発覚(^^;
僅かに聞こえる小さな音ではなく、通常のボリュームのスピーカーからはっきり ジリッ ジリリッ みたいに鳴ります。
最初は、とうとう RvII26 も壊れ始めたのかなと思っていたのですが、
明らかに毎時 10 分と 40 分あたりに鳴る(それ以外にも鳴るけど)ことに気づいて、確認したら携帯でした。
携帯放置しててもメール着信の通知の直前に鳴るっぽいので、何か激しく通信すると鳴るっぽい。
RvII26 のノイズで携帯のメールの通知が携帯より先にわかるという未来予知マナーモード状態になっています(^^;
Xa16 ではこのようなことはないみたい(通常の生耳で聞こえるレベルでは)です。

Re: ポチ - reiria

2019/10/19 (Sat) 22:15:45

> あと Xa16/R16 が思ってた以上に厄介で常用マシンに出来ていない(;_;)

今のところ、常用環境で困っているのは vfiler DPMI 版です。
ディレクトリ表示画面において、次の画面に移動すると同じファイル名をずらっと表示してハング(?)します。
Xa16/R16 の問題というより K6 のキャッシュの問題にも思えますが、再現性は 100% という感じです。

で、気付いた点は、テキスト VRAM が普通の RAM になっていると不具合は起きないみたいです。
Windows の DOS 窓がウィンドウ状態だと大丈夫で、フルスクリーンにすると駄目です。
WW のウィンドウでも大丈夫です。

K6 のキャッシュが無効の場合は、いずれでも大丈夫みたいです。

実テキスト VRAM だと何がまずいのか、そもそも通常の DOS 環境は実テキスト VRAM で普通に使えてるので、
vfiler DPMI 版に特有のコードとキャッシュに何か相性があるのかも知れませんが、よくわかりません。
まあでもハングしてくれるだけましで、すんなり動いてますよ風誤動作もあるやもです(^^;

Re: ポチ - KAZ.K

2019/10/20 (Sun) 23:32:22

山猫の呪詛に一票。
とりあえず適当にファイル数の多そうなディレクトリでふらふらしてみたけれど、うちのXv改(低速運転K6III@266)で特段の暴走はしてくれませんでしタ。

・・・と思いきや、あれ? K6系でTVRAM領域のキャッシュ有効にできたんでしたっけ? P6系はそもそもチップセット側を無視する(からTTwTに至った)けど、430/440系自体はそのへんプログラマブルになってないっぽい、あたりで投げた気がする・・・ものの、はて山猫とかK6とかちゃんと調査したんだったかどうか・・・

Re: ポチ - reiria

2019/10/21 (Mon) 20:45:11

うちも V166 + K6 では vfiler DPMI 版は問題なく動くようです。

> で、気付いた点は、テキスト VRAM が普通の RAM になっていると不具合は起きないみたいです。

改めて確認したところ、テキスト VRAM 全体ではなく A0 か A3 の一つだけで大丈夫ぽい。
また、普通の RAM でなくても、実テキスト VRAM 以外(?)なら大丈夫ぽい。

■ Xa16/R16 + K6 (HK6-MS400-N2) と vfiler DPMI 版の現状まとめ

・ディレクトリ表示画面で次の画面に移動すると同じファイル名をずらっと表示してハング(?)。
・CR0 でキャッシュ無効にすると大丈夫ぽい。
・メモリ全体をページテーブルの属性でキッャシュ無効にする方法でも大丈夫ぽい。
・テキスト VRAM のページテーブルだけキャッシュ無効にしても駄目。
・A0 か A3 の一つだけ実テキスト VRAM 以外(?)にすれば大丈夫ぽい。(A1 や A2 だけでは駄目)
・MSR C0000080h で L2 無効にしても駄目。
・MSR C0000085h でテキスト VRAM を UC や WC にしても駄目。
・16MB 4GB 空間のテキスト VRAM でも同様ぽい。
・各空間のテキスト VRAM を A0 ~ A3 に混在させるとハング時の表示が若干違うぽい。

Re: ポチ - KAZ.K

2019/10/23 (Wed) 16:46:28

うーん山猫さん自分で持ってないからなぁ・・・。
おそらくは遅すぎるTVRAMにPCIリクエストが山積みになった際に交通事故起こしてるんだろうけど、仮にそうだとして打てる対策はあんまり思いつかない。そもそも山猫のconfigスペースは公式情報が無いし。とりあえずpci latency timerのばしてみるとか・・・。

ただ一つ疑問なのは、別に16bitコードでもPCIバスを埋める程度の負荷はほぼ同程度にかかるはずで、他に再現事例が見つかって無いというのが腑に落ちない。その割に全画面DOS窓でも大丈夫(大丈夫じゃない)とか再現性高すぎて逆に不信感。そんなにvfiler@32のアクセスパターンが特異的なんですかねぇ。

・・・あいや、場合によってはP6でTVRAMをWBしようとしたときの即死と同根か??・・・とか思いついてみたものの、うちのRa改はいつの間にかピーになっていました、あばばば。自動電源ONエラー&メモリスイッチ蒸発&RTC大暴走・・・ってこれは電池が放電しただけか。しばらくしたら普通にあがってきた。最近ばたばたしていて電源入ってなかったからなぁ。通電してもまともに充電されないようなら電池交換ダダダ。前にXv改のを交換したときにもう一個買ってある:)

Re: ポチ - reiria

2019/10/23 (Wed) 23:37:20

djgpp なプログラムをあまり持ってないこともあり、当方の検証範囲ではあてにならないというか(^^;
いろいろ探しまくれば、他でも再現されそうな予感するけども・・・うむむ。

普段よく使う 32bit DPMI なプログラムは tasm32 ですが、
テキスト VRAM 直書き処理とかなさそうですし、vfiler とは比較にならなそう。

Xa? + HK6-MS400-N? って世の中ありがちな構成に思えるので、
vfiler 開発当時に誰か気付いてないかなと、vfiler のノート見てみると作者さん 1998-3-7 が最後のようで、
その頃はまだ K6 系の普及は微妙なような(;_;)
Xa7 使いの方の書き込みもあるようですし、あと数年続いていれば誰かが・・・うむむ(^^;

Re: ポチ - reiria

2019/10/24 (Thu) 03:34:31

■どうやら

・実テキスト VRAM 全体を 2 回連続して rep stosd するとハングするぽい。(ecx = 4000h / 4)
・rep stosw はハングしないぽい。(ecx = 4000h / 2)
・rep stosb はハングしないぽい。(ecx = 4000h)
・rep lods? はハングしないぽい。
・rep movsd はハングする場合としない場合があるぽい。(よくわからない)
・リアルモードや仮想 86 モードの use16 でも同様にハングするぽい。
・1 回目と 2 回目の間に wbinvd するとハングしないぽい。(invd だけではハング)
・vfiler の不具合が同様のコードなのかは不明。

; プロテクトモード 特権0
; use32
; es = 4GB flat data

cli

mov al, 0Ch
out 68h, al

xor eax, eax
cld

; 1 回目

mov ecx, 4000h / 4
mov edi, 0A0000h
rep stosd

; 2 回目

; wbinvd

mov ecx, 4000h / 4
mov edi, 0A0000h
rep stosd

sti

Re: ポチ - reiria

2019/10/24 (Thu) 10:40:03

> ・リアルモードや仮想 86 モードの use16 でも同様にハングするぽい。

; リアルモード / 仮想 86 モード
; use16
; es = 0A000h

cli

mov al, 0Ch
out 68h, al

xor eax, eax
cld

; 1 回目

mov cx, 4000h / 4
xor di, di
rep stosd

; 2 回目

; wbinvd

mov cx, 4000h / 4
xor di, di
rep stosd

sti

Re: ポチ - reiria

2019/10/24 (Thu) 12:21:19

vfiler のソース眺めただけで、コンパイルして確認したわけではありませんが、
djgpp 版 fast_flush_98() の movedata() がいかにもな感じで、これの連発(?)で不具合起きるのかも。

Re: ポチ - reiria

2019/10/24 (Thu) 17:35:15

> ・rep movsd はハングする場合としない場合があるぽい。(よくわからない)

ds:esi の先頭が実テキスト VRAM に入っている (ds:esi = 9FFFDh ~ A3FFFh) とハングしないぽい。

fast_flush_98() の movedata() は rep movsd を使って ds:esi は実テキスト VRAM に入ってなさそうですし、
ここが事故現場の可能性そこそこ高そうに思えてまいりました(^^;

Re: ポチ - reiria

2019/10/25 (Fri) 16:44:16

djgpp 版 fast_flush_98() に wbinvd を仕込めば大丈夫そうですが、CPU が 386 だとまずいので、
転送サイズを 4000h → 3FFFh にして、末端 3 バイトを rep movsb させるようにしました。
fast_flush_98() で A3FFFh への書き込みはたぶん無意味なので、動作に支障はないだろうと思われます。

vfiler.exe v1.21 のファイル先頭から 15080h ~ 150C7h に fast_flush_98() があります。
movedata() の引数の転送サイズは 150A7h ~ 150AAh の dword 値で、そこを 4000h → 3FFFh にパッチします。

これで一応、 Xa16/R16 + HK6-MS400-N2 で大丈夫そうですが真偽は謎です(^^;
実テキスト VRAM 全体に dword で連続書き込みしまくると闇の何かを呼び覚ますらしい(;_;)

Re: ポチ - KAZ.K

2019/10/25 (Fri) 23:20:07

うん。・・・・うん???

invdもたいてい時間かかるはずだけどそれでもクッションになりませんか。wbinvdにして何が違うと言えばライトバックが生じるところだろうけれど、それはたいてい関係ないメモリ宛であってPCI領域ではないだろうからPCIバス側に直接見える差はタイミング以外には無さそうに思えるけれど、うーん?

ともかくだとするとだ、推定としては
1) ライトバッファでくっつくのが間に合う程度に高密度のTVRAM書き込みが連続していて、
2) かつ書き込み位置がアドレス順でない位置に飛ぶと死ぬ?

1を満たすためにある程度以上の長さのrep stosd/movsdが必要で、だからあまり問題になっていなかった、と。これおかしいのが98GRPH側か山猫側かは微妙なラインですな・・・。

・飛んだ後の書き込みが小さくても死ぬかどうか
・3FFC→0000 以外の飛びでも死ぬかどうか
・死ぬパターンの間にPCIバスアクセスの無いウェイトをしこたま入れても死ぬかどうか
・死ぬパターンの間に別デバイス(Cバスブリッヂとか)宛のPCIバスアクセスを挟んでも死ぬかどうか

・・・ううーん。

Re: ポチ - reiria

2019/10/26 (Sat) 01:10:40

invd については、そもそもライトバックな CPU で invd すると死ぬ場合が多々あるぽいので、
上に書いた rep stosd のソースで invd するなら、1 回目の直前に wbinvd を入れる等しないとまずそうです。

プロテクトモード特権0 とリアルモードにおいて、

・1 回目の直前に wbinvd を入れ
・2 回目の直前に invd を入れ
・2 回目の rep stosd するとハング
・2 回目の rep stosd しなければ大丈夫ぽい
・2 回目の直前が wbinvd ならいずれでも大丈夫ぽい

ので、2 回目の直前が invd か wbinvd かによって違いはあるようですが、よくわかりません。
そもそもこの環境で invd 単体で実行すること自体何か駄目なのでは・・・?(^^;

仮想 86 モードの invd については、メモリマネージャ次第で wbinvd になるのであてにならなそうです。

Re: ポチ - reiria

2019/10/26 (Sat) 01:57:20

改めて確認しましたが、V166 + K6, RvII26 + P6 では 2 回目の直前が invd でも大丈夫ぽいです。

Re: ポチ - KAZ.K

2019/10/26 (Sat) 19:51:29

いやinvdでもというか、普通に正気の機械であれば間に何も入れてなくても暴走しないわけで(^^;

invdで無差別にライトバック放棄したらメモリ破壊だし、そのうちどこかで暴走するのはまあ道理だけど、そうすると特段にライトバックの溜まってない筈のwbinvdとinvdの差で状況が変わっているということに...? wbinvdはライトコンバインバッファまで放棄するものではなかった筈だしなぁ。

あ、でもP5バスだからFSBにチップセット側キャッシュのフラッシュサイクルは出ているのか。そのへんで山猫が正気を取り戻したり取り戻さなかったりしている...??

Re: ポチ - reiria

2020/01/09 (Thu) 10:31:19

<?del>恥ずかしくて今更聞けない感あるのですが、
config.sys で = 無くてもOKなのって正式な仕様なのかどうか公式の文章ってあるのでしょうか。
MS-DOS だけでなく DR-DOS もOKみたい。
処理的に「キーワードの次が = or 空白 or ? でなければ次のワードと見なす」みたいな流れになってると、
結果的に = 無くてもOKになってしまいそうには思えるものの・・・(^^;
世の中に散在する config.sys 設定例で = を書かないものも極稀に見かけるけれど、
DOS 付属マニュアル等の公式な文章として見かけたことは今までなく、
いや、昔からマニュアルに書かれてるじゃん、ちゃんと読めってオチの予感もなくもなく(^^;;;<?/del>

Re: ポチ - reiria

2020/01/09 (Thu) 12:43:37

<?del>DR-DOS (OpenDOS) のソースだと、キーワードと次のワードの間の = のチェックにおいて、
= の有無は気にしない (フラグを立てたりしない) ようです。この暗黙仕様(?)の起源が気になる(^^;
あと、config.sys だけでなく、adddrv.exe も = 無しOKなんですよね。<?/del>

Re: ポチ - KAZ.K

2020/01/14 (Tue) 00:23:51

むしろcommand.comからして実行ファイルの後が=でも通しているあたり、ファイル名に入らないはずの文字ならなんでもいいやが本音で、それが=だろうとスペースだろうと syntax sugar でしかないのかも。

今時のcmd.exeでもそうなのだけど、バッチの引数で環境変数的な ABC=DEF を受けようとしても = で切られてしまうので %1 とかでは絶対にパースできないという罠ガガガ。

Re: ポチ - reiria

2020/01/14 (Tue) 17:55:56

DOS 1.25 2.0 のソースをちょろっと眺めると、そのへん DELIM: ってルーチンぽいけれど、
= を判別するところであれこれ考えず全員迷わず進め的な雰囲気(^^;

CP/M 時代からの流れなのかなと、CP/M のソースもちょろっと眺めてみた結果、深入り回避を決意(;_;)

あぁ・・・ - KAZ.K

2020/02/10 (Mon) 17:56:19

Xv改のオンボード82557(Rev.1)/555がついに煮えてしまった気がする・・・。やたらパケット落とし始めたので調査したところ対向ポートのえり好みがやたら激しくなっているし、大丈夫そうな相手を選んでもやっぱり少しこぼすので時間の問題っぽい。

DOSで使うだけのうちの場合PCIスロットは余っているので、ひとまず在庫から82557(Rev.2)を引っ張り出して突き刺した。大丈夫、82557も82558もまだ在庫はいっぱいあるヨ。

煮えた石が短絡されると超あうとなわけだけど、かといって張り替える勇気はあんまりない。いやQFPだから理論上は半田ごてと吸い取り線だけでなんとかいけ・・・る・・・はず・・・だけど・・・。

Re: ポチ - reiria

2020/02/11 (Tue) 01:30:37

うちで最近壊れたものは、HDVS-UM って中身 IDE 外付け SCSI HDD ですな。
使用中に勝手に電源切れるようになって、症状出てから 2 日後くらいに起動すらしなくなり安心しました(;_;)
HDVS-UM の電源は Ra266 なんかよりパーツ少なそうだし、おお、これならもしや直せるのではと思い、
まずは中身を別の HDD ケースに移し、データを無事救出し終えたところで直す気力喪失(^^;

Re: ポチ - KAZ.K

2020/02/11 (Tue) 10:18:53

うちにも昔HDVS-UMはあった・・・はずなんだけど、いつの間にか行方不明に(--;;;
いや中身(確かさむそん)は速攻で死んで投げ捨てたのは確かなんだけど、とりあえずHIMAWARI基板だけ剥いでおいたはず、と思いきや、それはHDXG-Sのだったのでもう何も残ってない。ううーん・・・記憶が怪しい・・・

うちでは常用環境からは外付け箱は排除してますねぇ。中身剥いてリムーバブルベイに押し込んで本体内から電源とってる。外付け箱の電源ってどう見ても能率悪いし、何より邪魔くさい。

先日から久方ぶりに交換用に在庫している中古HDDの棚卸ししてるんだけど、うん予想通りというか、そもそも回らなくなってるやつが紛れ込んでいますね・・・めだりすととATAじゃないばらくーだ2本はだめっぽい。海門全滅か。ふぁいやーぼーるST(起動時のトレーニングでデッデッデッデッデデデデデデデデデってなる昔懐かしいやつ)は異音がする割には読み書き完全に正常。そしてDCASうるせぇ、ふぁいやーぼーるよりうるせぇ(@@;

Re: ポチ - reiria

2020/02/11 (Tue) 20:25:16

今までうちの 98 の IDE で壊れたのは Ra266 に最初から入ってた Quantum のやつですが、
読み書き出来なくなって、HDD 振るとカランコロン音がするんで何かのネジが外れたのかと分解してみたところ、
アームの付け根のほうにある樹脂製のパーツが砕け散ってました(;_;)
そのパーツはアームが外側に動き過ぎないように止めるストッパーみたいな役目らしく、
それが無いと通電した瞬間アームが外側に吹っ飛んで、読み書きしようとしても内側に戻って来ないようで(^^;
アームって目的に応じて正確な位置に止まるんじゃないんかいと思えましたが、
異常な位置に吹っ飛ぶと故障と見なし、それ以降何も動かさないような仕組みになってヌのかも。

Re: ポチ - KAZ.K

2020/02/16 (Sun) 10:21:42

んーどのタイプだろ、プラの長方形の穴の中をアームから出っ張ったツノが通過する形のか?
Quantumのはけっこう早いうちから余計な部品点数を減らす向きに突き詰めてヘッド位置を直接に測定する機構を捨てているので、ぶつけて止まった位置から基準トラック探すみたいな動作はしているかも。というか最近のディスクはたいていそうじゃないかな、能動的にぶつかるまでドライブしているかはともかく、ぶつかることはある前提っぽいゴムクッションついてるのよく見る。
同時期の海門だとレーザ測距してたり内周外周に位置検出あったりパーク固定専用の電磁どつき棒装備してたり、なんかこうむちゃくちゃなのが多い印象。でも一番の傑作はパーク固定機構が風車なやつじゃないかしらん。そりゃヘッドを飛ばしているのは風圧なんだから間違ってはいないんだけど。。。

Re: ポチ - reiria

2020/02/16 (Sun) 15:20:42

> プラの長方形の穴の中をアームから出っ張ったツノが通過する形

おお、ずばりそれっぽいです。

実物捨てずにあるので写真撮ってみました。

Re: ポチ - reiria

2020/02/16 (Sun) 15:23:51

> アームが外側に動き過ぎないように止めるストッパーみたいな役目らしく、

壊れてるのは外側じゃなくて内側ですな(^^;;;

Re: ポチ - reiria

2020/02/16 (Sun) 15:25:52

あと何か水色のパーツも壊れてますが全く記憶にない・・・
たぶん水色のパーツは分解していじって自分で壊したのではないかと(;_;)

Re: ポチ - KAZ.K

2020/02/16 (Sun) 19:22:37

いや捨てなさいよゴミ!!!www

Re: ポチ - reiria

2020/09/07 (Mon) 10:06:08

昨日気づいたのですが、98 DOS LANMAN から Windows 10 へのファイル転送が変になってる。
ファイル名は作られるけど中身の無いサイズ 0 のファイルが作られる。
一ヶ月程前 (Jack VHLT をアップした 7.25 ~ 26) に使った時は問題無かった。

98 がハード的に何か狂ったのかと思って他のマシンも試してみたけど同様。
LANMAN 以外組み込まないリアルモードでも同様。
98 DOS LANMAN ではなく、Windows 95 DOS 窓で net use して接続すると正常に転送されるっぽい。

98 DOS LANMAN の設定は変更していないので、Windows 10 側が更新で何か変わったのか・・・
とりあえずネットワーク関係を再設定してみたものの状況変わらず(;_;)

Re: ポチ - KAZ.K

2020/09/07 (Mon) 22:56:58

あー・・・Win10系のSMB1は試したこともないなぁ・・・というか設定したくらいで通るものと思っていなかった。へー通るんだ・・・いや通って「た」か。通らないのか。どっちだ(?)

うちは運用面はがちがちの保守的ですからして、中継兼バックアップ領域をHaswellに移植した3鯖に統合してボロマシンを3台潰した程度で、ぶっちゃけ前世紀から変わってないNetBEUIのままです:-)

Re: ポチ - reiria

2020/09/07 (Mon) 23:56:36

うちも Windows 10 を普通にインストールしたままでは駄目でしたが、
https://mikan.lunarscape.net/2019/10/cantconnecttosmb.html
みたいにいじったら使えていました。(あとは Windows 7 でやってたのと同様な設定)
が、この一ヶ月ほどの間に何かあったようで・・・(^^;

Re: ポチ - KAZ.K

2020/09/08 (Tue) 08:32:56

署名切るのとSmbServerNameHardeningLevelあたりだっけ。なんかもう一つ二つあったような気もする。
ともあれWin10は勝手に仕様が変わるのが仕様なので仕方ないヌー(投げやり

TCP/IPでいいならもはやSambaの方が後方互換性ちゃんとしているかもしれない罠。4.11あたりからSMB1の無効化を始めているけど、普通に設定すればまだ動いているはず。ただファイル数が多いとcaseまわりで足を引っ張られるのよなー。

Re: ポチ - reiria

2020/09/08 (Tue) 21:56:35

7.26 ~ 9.6 の Windows 10 更新履歴は、

KB4569073
KB4569751
KB4565351

の 3 個で、KB4569751 だけアンインストール出来るようなので消してみましたが特に変化無し(;_;)

今までうちで LANMAN 使ってきて今回のような症状は初の予感ですヌ(^^;
98 DOS LANMAN → 共有フォルダのファイル転送がサイズ0、逆の共有フォルダ → 98 DOS LANMAN は正常。
ファイル削除やディレクトリ作成/削除も正常。

Re: ポチ - KAZ.K

2020/09/09 (Wed) 12:42:02

うーん・・・うん? 内容が書き込めてないのにLANMAN側には特にエラーが戻ってきているわけではない??
実はDefenderがトンチキやらかしているだけという線は?

、と思ったけど、月例パッチ本体のロールバックが間に合ってないのか。これもう別の機体かVMで再現実験しないとわからんのでは・・・。

Re: ポチ - reiria

2020/09/09 (Wed) 22:01:13

どうやら、LANMAN の lanman.ini sizworkbuf の値以下のファイル転送がサイズ 0 になるぽい(^^;
ただ、常にぴったり「値以下」ではなくて値によって若干ずれるぽい。
もしや今まで気づかなかっただけで、Windows 10 はずっとこうだったのでは・・・(^^;;;;;;
となると直近一ヶ月とか無関係ということに(T_T)

思い返してみると、Windows 10 へ小さいファイル転送したのは、
先日 9.6 の VHLT のフォント (サイズ 1100 バイト前後) が初めてだったような気がしなくもない・・・。
で、ここ数日転送テストしていたファイルも小さいファイルばかりで、
今さっき何となく大きいファイル転送してみたら正常に転送出来ること発覚・・・。

Windows Defender の設定は今まで自分でいじったことありませんで、
とりあえずプライベートとパブリック両方無効にしてみましたが状況変わらないようです(;_;)

Re: ポチ - KAZ.K

2020/09/09 (Wed) 23:46:13

な、なんじゃそりゃ・・・。
でかいとコケるならぬ小さいとコケるとか、あからさまにプロトコルバグ踏んでる感が・・・。
SIZWORKBUF、設定範囲は確か128~4096あたりだけど、最低400くらいはないとどこかで詰まった気がする。

というか、そういうことならむしろ基本版の redir_4 とかで接続したらどうなりますかね? 基本的には通常版での net start workstation の直前までで止めて、その後 setname コンピュータ名 してから redir* を常駐させて、(net.exe use ではなく) use.exe で接続すれば動く・・・はず。たぶん。

Re: ポチ - reiria

2020/09/10 (Thu) 20:42:30

通常版使ったことなくてインストールもしておらず、今日と明日はちょっと無理で土曜以降の決意ですヌ(^^;
ってこれ、ディレクトリ basic と redir の使うファイルを expand して実行すればいいのかな。

Re: ポチ - KAZ.K

2020/09/11 (Fri) 07:37:38

です。
もちろん普通に別のconfig宛で最初からインストール走らせ直してもいいんですがそれはそれで面倒だし。

けっこうコマンドの組み立て方が違うので何か変わるかなー、と。ぶっちゃけバッファリングが甘い(というかたぶんほぼ無い)ので速度は出ません。

Re: ポチ - reiria

2020/09/14 (Mon) 21:25:29

basic と redir を expand してあれこれやったら NetBEUI は接続出来たものの、
TCP/IP がうまくいかず、結局普通に通常版インストールして拡張版とファイル比較した結果、
protocol.ini [TCPIP_XIF] LANABASE=1 だったのが敗因のようで(T_T)

で、TCP/IP redir_4 も何とか接続出来るようになりまして、
Windows 10 へのファイル転送も正常に出来て、拡張版のようにサイズ 0 になることも無いようです。

あと、これは Windows 10 どうのこうのとは関係無さそうですが、
TCP/IP redir* /EMS:YES だと use がエラーやハング(?)するのを何とかしたいとこヌ(;_;)

Re: ポチ - KAZ.K

2020/09/15 (Tue) 07:17:55

あー。EMSまわりは私もよくわかってないんですよねぇ。いかにもバウンス失敗っぽい挙動はそこかしこに見られるんで何かしら制限が残っているのは確かなんだけど。
emsrwとかいういかにもそれっぽい名前のあるけど、何やってるのかさっぱりわからないし、挙動的に役に立った気がしたことが一度もないヌ。

Re: ポチ - reiria

2021/01/01 (Fri) 18:18:59

個人スポンサー復帰元日ポチっとな。

Re: ポチ - reiria

2021/01/28 (Thu) 15:41:33

RvII26 WSS DMA 演奏中に実 TVRAM GVRAM に xchg 命令を実行すると頻繁にハング(?)する症状が発覚。
BIOS 領域でも変になるようだけど、TVRAM GVRAM と何か違って、暴走しているような印象。

今のところ RvII26 でのみ再現し、Xa16/R16 では再現しませんが、
リアルモードと仮想 86 モード、複数の WSS 演奏ツールで再現するので、当方の環境の問題ではなさそうです。
CPU なのかチップセットなのか DMA の使い方なのか・・・
HELP メニューの DMA クロックは関係無いぽい。
根本的に何に対策すべきかよくわかりませんが、xchg 使わないしかない予感ヌ(^^;;; movナラダイジョウブポイ?

例えば、wp03b.lzh (http://www5.airnet.ne.jp/kajapon/tool.html https://sites.google.com/site/kajapon/pmd)
の wp.asm において、演奏中にループしている main_loop2: call put_vol あたりで、
実 TVRAM GVRAM に xchg 命令を実行するとほぼ確実にハング(?)します。

当方のプログラムで、この症状で実際にハングするのは Jack LAMD のアクセスランプ表示です。
WSS DMA 演奏中のディスクアクセスでアクセスランプを表示すると・・・(;_;)/~
他にもあるかも知れませんがソース確認しないとわかりません。とりあえず Jack LAMD は対策したいです。

Re: ポチ - KAZ.K

2021/01/29 (Fri) 09:04:52

うーあー・・・ ちゃんぴょんのPCI周りで既知のglitchというとMWIがまともに動かない件が最初に思い付くけど、WSS←98 DMA←C-busブリッヂ←PCI←ちゃんぴょん←メモリ と CPU→ちゃんぴょん→PCI→98Grph→[TG]VRAM のシナリオであるならMWIは関係な・・・さそう・・・? ともあれチェックするとすれば

-録音でも再現するかどうか
-FDDのDMAでも再現するかどうか
-DMAの宛先もVRAMだと爆発するかどうか

くらいですかねぇ。

追) ひとまず手抜きして pv_03: のTVRAM書き込みのあたりにxchgをぺちぺち増やしてみたけど、430HX 440FX 共に何も起こりませんヌ。未解決のTVRAM WB即死もだけど、あんまり手がかりがないのん・・・。

Re: ポチ - reiria

2021/01/29 (Fri) 21:22:58

おお、他機種の情報ありがたいですヌ(;_;)

うちの Ra266 は未だ使えないままで、今回の件も RvII26 と Xa16/R16 しか試せていないもので。

> -録音でも再現するかどうか

録音も同様にハングするようです。

こうのたけしさんの wsspcm18.lzh wssrec.asm wssplay.asm の wait_pcm_lop: あたりで xchg を実行すると、
wssrec wssplay いずれも RvII26 だとハングし、Xa16/R16 では問題無いです。

xchg 以外の命令も試し中ですが、とりあえず xadd cmpxchg cmpxchg8b はハングしないぽい。

インテルの資料見ると、xchg って lock がらみの命令の中でも更に特別扱いみたいなポジション(謎)で、
マルチプロセッサマシンだと、そのへんの事情が何かあらぬ動きとか・・・(;_;)

> -FDDのDMAでも再現するかどうか
> -DMAの宛先もVRAMだと爆発するかどうか

むむ(^^;

Re: ポチ - KAZ.K

2021/01/29 (Fri) 23:16:38

xaddやcmpxchg(というか狭義のxchg以外の全て)は既定では普通のRMWサイクルで、明示的にlock prefix付けなければLOCK#は出ないはず。というか、普通のRMWにlock prefix付けてもコケないのであれば、本当にxchgだけがピンポイントで頭おかしい事になるので、それはそれで問題。

PCIバス上のLOCK#ってのはそんなに難しい話ではなくて、要はLOCK#付きでバス握ったら Latency Timer を無視してでも二度とAbortしないという *だけ* の代物なので、少なくともLOCK#付きのやりとり自身は一方的に得するだけで不利益は一切無い、というか、それですらコケるようだとたぶんもう何もまともに動かないレベルで有り得ない筈なんですよね。なので推測としてはLOCK#で待たされた方がoverrun/underrunでコケたか、あるいはちゃんぴょんが交通整理を間違えて自滅したかの二択、ということに。

もっともそもそもPCI側のLOCK#ってのはその後結構すぐにdeprecatedになった程度の代物で、確か Rev.3 あたりで既に順次実装禁止が始まっているんですよね。PCIブリッジ経由のトランザクションが書き込まれる側からAbortされると即死するという既知の仕様バグの回避に役立つ場合がちょっとだけあるから一応残してあるけど原則使うな的な雰囲気。

・・・うん? ということはいわゆる oh no don't do that なの?? つまりlockに特権がいらないIA32系でPCIバス空間を非特権ユーザランドにマップできたらその時点でアウト??? それってDAXとか普通にだめなのでは・・・いや今時のPCIeでは大丈夫になってるのかもしれないけど・・・ウウーン

Re: ポチ - KAZ.K

2021/01/30 (Sat) 21:30:14

いちおう念のためにTRoLLsを改造して1次DMAバッファをB000に配置した上で2次→1次の書き込みを全部xchgにしてみたけれど、やっぱり何も起こらないヌ。

というわけでやっぱりちゃんぴょん1.0の呪いなのでは・・・(^^;
RCCちゃんぴょん3.0 (= ServerWorks ServerSetIII) まで下るとlinux方面でも稼働実績があったみたいで色々quirksしこんであるのが見えるけれど、1.0や2.0はそもそもPCI IDが書かれてないし存在ごと無視されている感。1.0はともかく2.0はそれなりに実運用に使われていたはずだけど、98年頃だとlinuxのほうが2.1~2.2あたり・・・あーSMPにまだ穴がいっぱい残っている時代かー。そりゃあ無いかもなぁ。UPならちゃんぴょん使う意味ないし。

Re: ポチ - reiria

2021/01/30 (Sat) 21:35:54

> 他にもあるかも知れませんがソース確認しないとわかりません。とりあえず Jack LAMD は対策したいです。

ソースいろいろ探したところ fr v0.04a が xchg TVRAM していました。
あと、La10 は xchg でハングしませんでした。

Re: ポチ - reiria

2021/01/30 (Sat) 22:11:25

あと、master.lib のテキスト関係の関数で xchg してるぽいけど、
当方のプログラムで master.lib をリンクして、それらの関数使ったものはなかったはず。

Re: ポチ - reiria

2021/01/30 (Sat) 22:12:22

> というわけでやっぱりちゃんぴょん1.0の呪いなのでは・・・(^^;

今後軍事機密として処理しようかと(;_;)

Re: ポチ - KAZ.K

2021/01/31 (Sun) 11:08:04

そういえばDMAで思ったのだけど、メモリキャッシュが手動で何かしないと不整合を起こすもの(≒WBINVDが必要なもの)って、ほぼほぼ厳密に a) PCI/RAM間の切り替え、b) PCI空間がMMIOの場合、c) 16MB/4Gシステム空間と下1MBのaliasing、の三通りだけで、それ以外には無いよね。・・・よね? あ、TLBとかの内部状態類は別として。

SMPの文脈で出てくるのはキャッシュライン上に反映される順序自体が入れ替わるのが問題なだけで、実際にキャッシュから書き出す必要は(パフォーマンス上の理由を除いて)無い筈。だから後からキャッシュフラッシュしないFENCE類が追加されたわけだし。

勝手にCyrixInsteadした時の大惨事と9801FAのやらかしのせいでついついDMAとかまずそうな気がしてしまうけど、設計通りのIA32ならDMAだろうとなんだろうと全てのアクセスはsnoopされているわけで、snoopの目をかいくぐって書き換える方法はたぶん無い・・・んだよね。あんまり自信ないけど。

PCIバスも原則みんながsnoopし続けている前提なわけで(というかだからこそ物理的にバスではなくP2PなPCIeでややこしいことになった)、書き込み操作自体がPCIバス上に流れている限りは自動的に整合性は維持されていなければならない・・・ように思える。ISAなり98なりの伝統的DMAだってPCIの顧客に過ぎない以上は問題を起こす余地が無い、はず。

補足:
a) SMM遷移がこれに該当する点に注意。
b) ただのRAMではないもの全てという意味で。この意味においてROMやGVRAMは実質的にMMIOと解するべき。
c) ただしその領域にただのRAMは実在しないので、aliasingが無くても問題は起きる。
c1) TVRAMだけは画面表示という副作用があるものの、CPUから見える挙動はただのRAMだと言い張れる・・・かも。

追) しまったA20のアホを忘れていた(^^;;;

Re: ポチ - reiria

2021/01/31 (Sun) 20:48:42

これはもしや PCI マシンなら DMA のキャッシュフラッシュしなくてOK的なお話ですかヌ(^^;

いやほんと、それで通常大丈夫そうなら大賛成です。

LEMM -!C で DMA のキャッシュフラッシュしなくなるのですが、FDD アクセスも体感でわかる差が出るので、
PCI マシンはデフォルトで -!C にしていいなら是非そうしたいです。

Re: ポチ - KAZ.K

2021/01/31 (Sun) 22:46:40

大丈夫なんじゃないのかなぁ。というか、PCI以前であっても、少なくともCPU側のsnoopは486の最初から実装されているわけだし。
まあメモリコントローラが独自品だった時代のやつがそこはかとなく不安な気は確かにするけれど・・・(01FAから目を背けつつ)

実のところうちのLEMMは導入当初からずっと-!Cで、まあFDDなんて一度か二度しか使ってないけど (下手すると壊れていても気付かないまである)、少なくともWSSが変とか経験ないですし。Xvの方は全SCSIなのでPCIバスマスタも常に動いているはず...? BIOSが勝手にフラッシュしているとかまでは知らない。

Re: ポチ - reiria

2021/02/01 (Mon) 23:03:00

うちは VX21 から Ra266 になって、その間の 386 486 Pentium な 98 事情って実は殆ど知らないんですよね(^^;
DMA にキャッシュフラッシュが必要かどうか何かうまいこと正確に判別出来たらよいのですが。
とりあえず 286 386 → 486 にしたマシンでなければ -!C でいいヌかなあ、うむむ。

Re: ポチ - reiria

2021/02/01 (Mon) 23:04:22

; PCI BIOS があるなら -!C にするこーど(^^;

.model tiny
.386
.code
.startup

xor edx, edx
xor edi, edi
mov ax, 0CC01h ; 0B101h
stc
int 01Fh ; 01Ah
.if (!carry?) && (edx == " ICP")
or ebx, -1
xor ecx, ecx
bts ecx, 15 ; -!C
.else
or ebx, -1
;; btr ecx, 15 ; -C
xor ecx, ecx
.endif
xor edx, edx
mov ax, 0DEF1h
int 067h
bt edx, 15
.if (carry?)
mov dx, offset _iC
.else
mov dx, offset _C
.endif
mov ah, 009h
int 021h

ret

_C db "-C$"
_iC db "-!C$"

end

Re: ポチ - KAZ.K

2021/02/02 (Tue) 01:22:15

486以降のバス上でのCPU変更もしょっちゅう問題あったけど、PODPにせよPMMXにせよ、単に速くなりすぎてC-busがコケたとか、伸びたプリフェッチのせいでBIOSのバンク切り替えが迷子になったとかで、大半はキャッシュ絡みの問題ではなかったはず。

実際にはWBに対応していない母板上でWBEiDX2のWBを有効にしてしまったケースってのはあったような気がしないでもない、けど、これは確か明示的に何かのI/Oつつかなければそうはならなくて、差し替えただけで自動的に爆発する組み合わせは無かったはず? うろ覚えだけど理屈からすると積み残しのWBを見落とすのが問題なわけだから、DMAの起動前にWBINVDしとけばいいのかな、たぶん。

いずれにせよ、ぶっちゃけ必要な人は自分で-C付けろでいいような気もする・・・。いやだって、-Cでないと爆発する環境ってのは、事と次第によってはLEMMが起動する前に既に爆発しているという意味なので、むしろ明示的に-C書かせた方がココマデキケンが明確になって良いような。

Re: ポチ - KAZ.K

2021/02/02 (Tue) 09:53:41

> DMA にキャッシュフラッシュが必要かどうか何かうまいこと正確に判別

寝ながら考えていたのだけど、機種判別をベースに白黒リスト構築するっていっても、そもそもCPUの載せ替えが改造な時点で「外見上は同じだけど実は回路構成が違う」の発生余地があるので、確実な判別は原理的に不可能と思われる。いや実際、たとえば動いているCyrixInsteadの大半は要-Cだろうけど、確かC-busあたりからDREQか何か引き戻してきてFLUSH#駆動するみたいな改造も一応あったはずなんですよね (詳細うろ覚え)。いえ世のCyrixの何パーセントがその処置されているんだって言ったらほぼゼロだとは思うけれど。

かといって実際に事故が起きるかどうか試してみるにしても、8237A的なDMAにせよそれ以外のバスマスタにせよ、原則全ての環境で存在するデバイスなんてフロッピィコントローラくらいしか無いし、かといって765に用も無いのにDMAREQを出させる方法なんて少なくとも合法的には存在しないので、うん無理じゃね?

それだったら8237Aをメモリ・メモリ転送モードで自走させるほうがまだしも可能性がありそうな気がする・・・。といってもメモリ・メモリ転送って青本だろうと何だろうと絶対に禁止って書いてある例のやつだけど。実のところ禁止の理由はマニュアルにほぼほぼ明確に書いてあって、要はこれ絶対にバンクセレクトがまともに動かないんですよね。実際にはたぶんどれか特定のチャネルのバンクセレクトが動くと思うけど、どのチャネルになるかは周辺回路依存 (マニュアルに書いてある例の通りならCh.0になるけど絶対にそうとは限らない) だし、なんなら本当に出力不定になる可能性もゼロではない。なお自分ではその昔に禁止の理由が納得できた時点でそれ以上の追求をやめてしまったので、本当にだめかどうかとか実機実験はしてないですん。

あ゛ - KAZ.K

2021/02/02 (Tue) 23:21:54

話の流れとは関係ありそうで全く無いんだけど唐突に思い出した。

ものすごく今更なんだけど、TiBPのちゃんぴょん対応っていります? っていっても自分で何かしたわけじゃなくて、まりも氏のE800RAMのソースにちゃんぴょんのPAMがしれっと書いてあるんです。おぅぇ・・・。
というわけでうちではテストも何もできないけど、その通りに書き足すだけならちょちょいとできる気がする。まああんな程度の小物、適当にパッチ当ててくれたのでも・・・というか勝手に作り直してくれてもいっこうにかまわないんですが。ぷるり。

Re: ポチ - reiria

2021/02/03 (Wed) 00:54:44

> 必要な人は自分で-C

まあ、純正 EMM386 だと DMA のキャッシュフラッシュとか何それって眼中にない感じ(たぶん)なので、
デフォルト -!C にして純正 EMM386 互換じゃと言い張ればよさげな気もしなくもないヌ(^^;;;

> TiBPのちゃんぴょん対応っていります?

おお、いただけるものなら何でも(^^;

RvII26 もメモリマネージャで安直に移動すると PCI BIOS 実行出来ないので、そのへん出来たらいいですな。

p4 - KAZ.K URL

2021/02/03 (Wed) 17:41:36

- たぶんちゃんぴょん対応
- 山猫でD8以外は開けなくした

ぶっちゃけこの二点のみなのでTiBP以外はほぼ何も変わってないはずだけど、混ざるのも気持ち悪いので一応TiBPN含めて再アセンブルしときましたにょ。

Re: ポチ - KAZ.K

2021/02/03 (Wed) 18:34:58

いいこと思い付いた。
プロテクトメモリモードを持っているハードウェアEMSボードをC-busに突き刺せばVRAM以外でPCIの先にあるただのRAMのlock実験ができるヨ!
ESC-HELP-5リセットでリフレッシュ出せばPCI機でも動きはするはず。

WSS DMAとC-bus RAMで再現するなら「98Grphは主犯では無い」という証拠にはなりそう。
逆に再現しなくなった場合は・・・それだけだと確定的では無いかなー。も一つPCIバスマスタを他に用意して順列組み合わせするしかないかも。SCSIでもUIDEでもいいから適当につないで読み書きしている間に割り込みで割り込んでlockしまくるとか?

Re: p4 - reiria

2021/02/04 (Thu) 00:22:45

RvII26 Xa16/R16 で D8-DB 移動してさくっと PCI BIOS も実行出来まヌた!(;_;)

Re: p4 - KAZ.K

2021/02/04 (Thu) 01:14:49

にゃ。
実は2bitのうちどっちがRでどっちがWかわかってないので安全策の判定がガバガバだけど、実用上は特に問題無いかと思われます:-)

Tieeep - KAZ.K

2021/02/11 (Thu) 12:43:59

あれ?
もしかしてP6系のL2の設定値ってNDA対象で公開docには書いてない???

いやほら、うちみたいに前期3桁RaにKatmaiぽんのせしただけの状態って、ひとまず問題なく動いているように見えるけれど実はL2の設定は間違っているという説があって。実際レイテンシ設定をのばしてやった方が至極微妙に速いというのは経験的にはわかっているのだけど、そもそもintel的に正しい値はいくつのつもりだったのかと若干疑問に。

まあFSBが2/3のダウンクロック稼働で定格では無い (からこそレイテンシ1などという無茶な設定でもひとまず動いてしまう) のだし、無意味だと言ってしまえばそれっきりなんだけど、どういう範囲のモデルに対して一定の設定値でいいのかの目安にはなるかなー、と。

どうせ元が間違っていることは確定なんだから当てずっぽうで弄っても悪化は無かろ・・・と、言い切れればよかったんだけど。L2レイテンシって、減しすぎたら死ぬのはまあわかるとして、実は増やしすぎても死ぬんですよね。何故か。自分の機械だけならともかく、公開するにはちょっと怖くない?

Re: ポチ - reiria

2021/02/11 (Thu) 23:36:37

うちの Ra266 も Katmai でしたが、そのへん全く何もいじらずぬる~く使ってました(^^;
んー、やはり Ra266 は何とか復活させたいなあ、やっぱ PentiumIII な 98 ってのは輝いて見えますですヌ(;_;)
それでオク眺めてるといつの間にか EPSON マシンをポチっと・・・危ない。

Re: ポチ - reiria

2021/02/12 (Fri) 22:54:01

というわけで、今やらなきゃこの先ずるずると一生やらないんじゃと思えてきたので、
昨夜から Ra266 に通電して様子見中ですが、ここまで 24 時間ほど全く問題なく普通に動いてます(^^;;;;;;;;
なるべく余計な操作はせずに、カレンダの日時合わせて後は放置。
自動電源オンタイマは 12-65 65:61:65 って狂ってますが、これは合わせず放置。
HELP メニューも出さず(出すと何か再設定されかねないので)そのまま。

最後に通電したのは 2018 年 6 月頃だったような気がしますが、その時は確かに駄目だった思い出があります。
それからコンセント抜いて昨日まで約 2 年半ほど全く何もしなかったはず・・・(^^;

てか、電源かどっかのコンデンサが逝かれてたのなら、
時間が経っただけで自然に平気なるんなんてこと有り得るのだろうか・・・うむむ。

まあまだ全く安心は出来ませんので、このまま何かの奇跡が起きて1ヶ月くらい動いてほしいヌ。
もし復活したら毎年 2 月 11 日は祝日にしようかと思いますですヌ。

Re: ポチ - KAZ.K

2021/02/13 (Sat) 02:09:39

えぇ・・・。
電解はあんまり放置されると酸化膜が溶けて漏れ電流が増えるですよ。漏れは正しい向きで電圧かかってしばらくするとそのうち治る、けど、繰り返す度に寿命を食いつぶして劣化するので・・・。

追) 現状のTieeep・・・の439HXの設定にはやっぱり問題があることがわかったので撤去(ぉ。あーもー一年くらい大丈夫だったのに何で表に出したとたんに発覚するかなー。

Re: ポチ - reiria

2021/02/13 (Sat) 21:19:12

うむ、今日もつつがなく Ra266 生存中(;_;)

> 一年くらい大丈夫だったのに

うちの Ra266 に憑いてた悪霊がそちらに引っ越したのでは・・・(^^;;;

TieEEP - KAZ.K URL

2021/02/14 (Sun) 21:00:11

結論: 439HXで58:55(r2w2)は何やってもPCIが無☆理

本来は高速再起動時に82557が野放しになっているのを刺し殺すやつなので、原則なるべく前、少なくともメモリマネージャよりは前に入れるでち。

なおうちで使っているのは全部SECの60ns品です。・・・たぶん? 最近ふたあけてないから覚え違いは有り得る。NとかHとかMとかの往年の国内勢も少しはあるんだけど、数が揃わなくて結局投入してない筈・・・あ、Hのは偽60nsモジュールだ (真ん中のECCだけ容量半分の60ns品で残りが全部70ns。よって片面に石が10個ある(--;)。

Re: ポチ - reiria

2021/02/23 (Tue) 09:09:33

RvII26 リアル/仮想 86/プロテクトいずれも、VSYNC やマウス割り込みで TVRAM に xchg し続ける状態で、
FDD の scandisk クラスタスキャンや dskbench がほぼ確実にハングするのを確認しました。
FD BIOS 内の軍事機密なので、とりあえずアクセスランプのタイミングでは再現しなさそうですヌ(^^;

Re: ポチ - reiria

2021/02/23 (Tue) 09:32:01

> VSYNC やマウス割り込みで TVRAM に xchg し続ける状態

2nd CPU で xchg し続けながら、1st CPU で FDD の場合も同様にハングします。

Re: ポチ - KAZ.K

2021/02/23 (Tue) 17:14:35

あー。おおむね想像通りというか、PCI側の問題なことはほぼほぼ確定ですかね。C-busブリッジから先の問題ではまず無いし、FSB側の問題なら・・・それだったらメインメモリでもコケそうじゃない?

今のところ当事者はC-busブリッジと98GRPHとちゃんぴょんの三者だけど、・・・C-busブリッジも98GRPHもリビジョンまで含めて同じ筈の石が他の機種で問題を起こしていない以上、いやこれやっぱり犯人がちゃんぴょんじゃろ()

Re: ポチ - reiria

2021/02/23 (Tue) 22:34:23

ここまで試した範囲では、FD BIOS の場合、read は問題無く、write でのみハングする(タイミングがある)ようです。
で、ただ単にハングするだけでなく FD にゴミか何か書き込まれて FD の中身滅茶苦茶になります(^^;;;
なので、もしこの掲示板見て自分もやってみようという奇特な方がおられましたら、そのへん十分ご注意下さい。
というかこれ、ただの VRAM アクセスで FD 破壊出来るとなるとそこそこ軍事らしくなってきた気がしなくもないヌ(^^;
この調子だと C-bus SCSI HDD もやれば再現しそうですが・・・うむむ。

Re: ポチ - KAZ.K

2021/02/24 (Wed) 09:07:13

WSSでは録再共に死んだという話に比べると FDD read が問題なさそうというのは微妙に不思議ではありますね。FDDのreadはRAMへのwriteなのでバスサイクルとしてはたぶんFDDのwriteよりは速いはずで、FDDは500k、たとえばCD-DAだと1411k、とするとある程度バス占有率が上がらなければ再現しない系か? WSSも同程度のレートにあわせて 16kHz 16bit stereo か 32kHz 16bit mono か 32kHz 8bit stereo にしたらFDDと同様に録音と再生で結果が分かれるかな。あるいは単にレート下げまくって 5510Hz 8bit mono にすると再現しなくなるとか。

・・・と思ったけれど、あれ? Rvなら2940相当のSCSIがオンボードで乗ってるのでは? そっちは問題起こしてないので?? だとすると転送レートそのものがトリガーという説は急速に萎むけれど。あと確か合法的にはROM殺せなかった筈だから、C-busにせよPCIにせよ、SCSIの増設はBIOSを移動してちゃんと動く板でないと正面衝突まっしぐらで面倒くさそう。

もっとも所詮C-busブリッジから先は(自前バスマスタでも)16bit幅・システムクロック5MHzの世界で、PCI上でバーストになっているとは思えず、C-busブリッジ経由だと見た目上のデータ転送レートに比してPCI側のバス占有率はべらぼうに高いという線は捨てきれないんですよね。まあそこをソフト側から確認する方法はあんまり無いんだけど。(ぶっちゃけ帯域を青天井で消費できる第三のデバイス宛にどれだけ帯域が残っているかを測るくらいしか手がない)

Re: ポチ - reiria

2021/02/26 (Fri) 00:51:47

FD BIOS を↓みたいにぶん回しても read は今のところ一度もハングしないのでなぜか大丈夫のようです。
write はほぼ確実にハングします。

VSYNC やマウス割り込みで xchg しても大した頻度じゃないので、read は何かタイミングがいいだけかもですが、
2nd CPU で強烈に xchg しまくってもハングしないので、タイミングは関係ないのかもです。

.model tiny
.8086
.code
.startup

.repeat
mov ax, 07690h
mov bx, 02000h
mov cx, 00300h
mov dx, 00001h
mov bp, 08000h
mov si, cs
mov es, si
mov ss, si
mov sp, 0FFFEh
int 01Bh
.break.if (carry?)
xor ax, ax
mov es, ax
.until (es: byte ptr [ 00528h ] != al)

ret

end

ってやたらほいほいぶん回すと FD や FDD の寿命縮めてる気がしなくもない(^^;

> レート下げまくって 5510Hz 8bit mono にすると再現しなくなるとか

wssrec wssplay の /f2 と /f15 において、/b /w /m /s の有無で試してみました。

wssrec:
bm wm bs ws
f2 〇〇 〇× 〇× 〇×
f15 〇〇 〇× 〇× 〇×

wssplay:
bm wm bs ws
f2 〇× 〇× 〇× 〇×
f15 〇× 〇× 〇× 〇×

左: xchg 無
右: xchg 有 (wssrec.asm wssplay.asm の wait_pcm_lop: のところで実行)

という感じで、/f の値には関わらず(たぶん)、/b /m の場合だけ xchg 有 wssrec はハングしないようです。
Ra266 では全て〇でハングしませんでした。

> Rvなら2940相当のSCSIがオンボードで乗ってるのでは? そっちは問題起こしてないので??

xchg しまくりながら scandisk クラスタスキャンや dskbench 実行しても特に問題無い感じです。

Re: ポチ - KAZ.K

2021/02/26 (Fri) 17:04:01

あー・・・、レートには関係なく1サンプルあたり1バイトならほんのちょっとだけ大丈夫で、それ以外は全滅、と。WSSはPIO/DMA共通で16バイト分(だっけ?)バッファがあるので、1サンプルが2バイト以上あるとその分は完全にback-to-backでDMAが連続するのかな。

その点少なくともディスクリート時代の765には1バイト分たりともバッファが無かった筈(少なくともDMARQ#からRD#/WR#応答までの許容最長時間がデータ転送レートとほぼ1:1)なので、よっぽど切羽詰まらないとDMAの連続にはならなさそう(だし、万が一詰まった次の瞬間にはunderrunまっしぐら)ではある。

そのわりに2940は大丈夫という点については・・・、うん、まあ、それも有り得る・・・のか? つまりバス占有率が高いこと自体は問題なくて、バーストで中身がちゃんと詰まっている分には構わないけど、バイト単位のちまちまDMAでバスを連続占有すると、バス幅までマージする処理がタイムアウトする前でくっつける気満々のところにPCIに出るLOCK#と衝突して交通事故発生とか、そういう流れかな。

それだと普通に今まで誰も気付いていなかったという線もあるかもしれないなぁ。ちゃんぴょんの製品仕様からしてもぶっちゃけサウンドカードなんか無いサーバボードの方が多かったんだろうし。

441FX的に(←訂正: 439HXは機能固定)マージ処理が選択可能になっていればそこ止めることで回避できる可能性がほんのちょっとだけあるかも・・・? あるかどうかすらわからないけど!

Re: ポチ - reiria

2021/02/27 (Sat) 21:14:25

一応、WSS PIO の処理にも xchg を仕込んで試してみましたが問題無さそうです。

内蔵 SCSI が大丈夫なのは・・・どうなんでしょうねえ。
DOS 使ってるとたまにある謎の SCSI ハングなんて特に深くも考えずさくっと再起動してさらっと忘れる(^^;;;ので、
今までにあった謎の SCSI ハングのいくらかは xchg がらみだったかも知れませんな。

そんなこんなで、当面の対処療法は xchg を使わヌしかないかなと、あれやこれやを mov に変更決意(^^;

Re: ポチ - KAZ.K

2021/02/27 (Sat) 21:28:37

> DOS 使ってるとたまにある謎の

ないよ!
いやCD入れ替えのタイミングで死ぬパターンとかわかっているのはあるけど、謎なんてないよ!!

Re: ポチ - reiria

2021/03/03 (Wed) 10:37:16

Ra266 の勝手に電源オンオフ症が再発しましたゆえ、2 月 11 日祝日化法案は却下されました(;_;)
早朝 4 時頃発症し、ピポピポ うるさくて目が覚めました(^^;

Re: ポチ - KAZ.K

2021/03/03 (Wed) 22:16:59

とりあえず電源スイッチのケーブル引っこ抜いてみようよ。うん、なんかちょうど二年前くらいに同じこと書いていた気がするけど、わりと本気なんだよ。

個人的に確認してみたのですが… - リウ URL

2022/08/01 (Mon) 21:20:56

>実テキスト VRAM 全体を 2 回連続して rep stosd するとハングする

この問題にチャレンジしてみたところ
PCI VENDOR IDが1033:0009のrev01のものでだけ発生する という可能性があるようです。
このデバイスはconfig spaceの44hが他のものとは違って00になっていますが、他の違いは私には今のところわかりません。
しかし手持ちではXb10 Cx13だけがこのデバイスIDになっており、同様のフリーズが起こります。
検証はこれしかできていませんが、ハードウェアバグの可能性があるとのことですので発見者さまへ報告を致します。

Re: ポチ - reiria

2022/08/01 (Mon) 23:27:41

いろいろな機種での調査ありがとうございます。
早速、当方の Xa16/R16 の PCI 情報を確認したところ、ばっちり 1033:0009 Rev 01 で 44h=00 でした。
これはもしや K6 系に換装しているという条件は関係なかったのかな。
当時、元の Pentium にも戻して確認したような気はするものの・・・すこぶる忘却の彼方(^^;
後日改めて確認してみたいです。

Re: ポチ - KAZ.K

2022/08/04 (Thu) 19:08:51

問題は今のところ Rev 01 の98GRPHがついてたのってどれも山猫機なんですよねぇ。どっちがあかんやつなのか区別が付かぬ。

オンボードではなく抜いちゃだめボードの Rev 01 なら、Ra系から引っこ抜いた抜いちゃだめとろいでんとがたぶん Rev 03 なので、それで差し替えを試みるくらいか。ただ組み合わせによってはITFを通過できずに上がってこないので本当にそれで実験できるかどうかはやってみないとわからない (見かけた限りの経験談では他種の抜いちゃだめからとろいでんとに差し替えた場合には上がってくることが多いようだけど絶対ではあるまい)。

ちなみにうちのXvのオンボードは Rev 02 でした。何が違うのか知らない(

追) ってしまった、Xb10って前期Vと同じでフタあけてみないとどっち出てくるかわからない怖いアレか! うん430FXでも頓死するんだったら98GRPHが悪いでいいんじゃないかな(((

Re: ポチ - reiria

2022/08/04 (Thu) 23:20:34

> これはもしや K6 系に換装しているという条件は関係なかったのかな。
> 当時、元の Pentium にも戻して確認したような気はするものの・・・すこぶる忘却の彼方(^^;

Xa16/R16 を元の Pentium と MMX (V166 のやつ) にして確認してみたところ、さくさくっと再現しました。
どうやら当時全く確認してなかった疑惑濃厚説(^^;;;

> 抜いちゃだめからとろいでんとに差し替え

うむ、これはさくっと猛者の方々に(^^;

Re: ポチ - リウ

2022/08/05 (Fri) 00:36:58

ごめんなさい うちのXb10は2台ありまして
どちらも430FXで、片方はMMXODPなITFにアップデートされてます。もう片方は初期状態っぽいです。
山猫に限らないと思いました。
ノート機でもrev01のものが出てくるとおもしろいのですが… また色々漁ってみます。

Re: ポチ - リウ

2022/08/05 (Fri) 08:23:21

Na13/H 96年3月発売
http://www.pc-9800.net/db_98/data/pc-9821na13.htm
でRev 01でした。暴走しました。
既報のものはたいてい95年発売のようです。このあたりの機種かと…

Re: ポチ - reiria

2022/08/05 (Fri) 23:00:43

おお、ノートでも再現するんですね。うちの La10/5 は Rev 02 で再現しませんでした。
La10 の発売は96年3月と7月があるようだけど、どっちなのかは不明です。3月なら Na13 Rev 01 と同時期ですが。

ただ、この La10/5 は液晶が 800x600 (7月発売の La10/S8 同等) に交換されているので、
もしかすると、元は3月仕様だったとしても、液晶交換時に密かに7月仕様化された可能性あるかもです(^^;

Re: ポチ - リウ

2022/08/09 (Tue) 12:19:34

なんと非PCIなこの機種でも暴走しました。
http://www.pc-9800.net/db_98/data/pc-9821xe10.htm
95年6月発売

http://ematei.s602.xrea.com/cgi-bin/bbs39_ris3/bbs39.cgi
98システム解析スレッド2022年8月-1
にあったようにキャッシュフラッッシュが必要なのではなく純粋に待ち時間だけが必要なようです。
Xe10/4でも
push ax bx cx dx pop dx cx bx ax
を1000h回繰り替えしてから戻ると暴走しませんでした。

Re: ポチ - reiria

2022/08/10 (Wed) 00:39:34

> 非PCIなこの機種でも暴走

Xe10 で再現するとなると、中身が似てるらしい BX4 あたりも再現しそうですな。
逆に、95 年より古い初期の PCI マシンはどうなのだろう。

> キャッシュフラッッシュが必要なのではなく純粋に待ち時間だけが必要

Xa16/R16 で確認してみたところ、out 5Fh なら 4 回くらい、nop なら 900 回くらいのようです。

Re: ポチ - KAZ.K

2022/08/17 (Wed) 19:07:54

ついにというかようやくというか、Ra改の電池を交換した。前にXv改のを交換したときに最初からML2430二つ買っておいたので・・・ってもう何年前だ・・・? ともあれコネクタ付け替えてブチルゴムでぐるぐる巻きにして適当にケーブルの上にポイで工事完了。恐ろしいことについさっきまで充電されていたはずの元の電池の方が、買ったきり年単位で放置していた新品より電圧が低い。うんそりゃあボケもするだろうよと。

作業内容的にはC-bus籠を抜くだけで足るのでそれ以上はばらしてない(ぶっちゃけ一番面倒なのは元の電池が付いていたスポンジ両面テープの残骸清掃である(--;)が、いちおう表から見ただけでわかるような異状はまだ無さそうであった。むしろXv改の方がまたぞろ下駄の給電不良を起こしかけている予感。むぅん。

Re: ポチ - reiria

2022/08/18 (Thu) 21:57:01

うちの 98 はどれもカレンダほぼ駄目(長いのでも 2 日くらい)ですが、電池交換ってまだ一度もしたことないですヌ(^^;
2015 年頃だった気がしますが、ML2430-CJ1 って DigiKey でたくさん売ってるぽかったので、
クククッいずれ大量に仕入れて売りさばいてやるぜウェヘヘヘ... と何年か油断しているうちに終わってました(;_;)

Re: ポチ - KAZ.K

2022/08/18 (Thu) 23:16:21

確かに今検索してもなんか怪しげなのしかかかってきませんなー。まぁ今時の設計だとふつー一次電池ですからねぇ。充電回路つける方がめんどくせえという。それこそ98みたいな骨董品の補修部品としてしか需要が無い・・・。

そういえばしばらく前のいんてるSoCのErrataにもそんなのがありましたな、RTC電池の充電制御を有効にして使うと耐圧不足的な劣化で想定寿命より前に自壊しそうとかいうやつ。確かAPLだったか?

Re: あるぇー・・・ - KAZ.K

2022/12/16 (Fri) 18:54:00

Xv改がいよいよまともに動かなくなった。ピポる前に既に死んでいる、メモリカウントの途中で死ぬ、ディスク探し途上で死ぬ、なんとか起動してもほぼほぼアイドル状態ですらわりとしょっちゅうCPUが頓死する感じで、いっぺん死ぬとNMIも通っている気がしない。

どちらかといえば暴走すらせずにきれいに即死している感じで、画面にゴミの一つも出ないしメモリスイッチが飛んだのも一回だけ。ぴぽすらしない場合がわりとあるのはともかくそれ以外は微妙に前回の給電不良と症状が違う気もする・・・ものの、かといって接触不良を疑い続けるのも面倒なので、とりあえず下駄側の給電コネクタを半田直付けにした。が、やはり予想通りというべきか、症状は改善しない。

これはいよいよCPUがボケてきたのかと、ひとまず様子見程度の軽いノリで下駄をガジガジこじ開けて倍率をx4からx3に下げ、ついでになんとなく電圧も (元々下げ設定にしていたのを前回の給電不良事件の途中で普通設定にしたままだったので) 下げ設定に戻してみた、ところ・・・あれ? なんか普通に動いている感?? なんで???

1) 定格400MHzのCPUが266MHzですら動かなくなった (が200MHzでならなんとか動く)
2) やっぱり電源系統がどっかでへたっているので消費電力が減ってどうにかなった
3) 抜き差ししている間にソケ5自体の接触不良がなんとなく治った
4) 電波

さてどれだ。

Re: ポチ - reiria

2022/12/17 (Sat) 00:07:33

アイドル状態で死といえば 5) さがじぇんヌ(;_;)

そういえば久しぶりに VX21 動かしたら、拡張メモリを全く認識しなかったり、認識しても不安定だったりで、
どうやら 2 枚刺してた EMJ のうち 1 枚目の EMJ-4000L + EXJ-2000S が何か駄目になったぽくて、
電源弱ってるせいかとも思ったけど、そのボード 1 枚だけ刺しても同様でした(;_;)
2 枚目にしてた EMJ-8000 は大丈夫だったようで延命中。

あと、RvII26 の筐体前面のファンあたりから時々ジーって異音がするようになったものの、
筐体叩くとなぜかしばらく静かになるのでまだまだいけそうですヌ(^^;

Re: ポチ - KAZ.K

2022/12/17 (Sat) 10:14:58

だからファンくらい交換しれと前から(

EMJ-4000L・・・って世代的にもしや昔のおおらかなタンタルコンデンサの山なのでは? あれ故障モードがたいてい短絡なので、焼き切るだけの電流が流れないとむしろ電気を吸い込み続けて電源を弱らせる側になる場合ががが。

うちの死蔵品箱にも一枚二枚あった気がしないでもない、けど、正確にどれだったか覚えてないし引っ張り出すのも面倒くさい。EMSシリーズとか基板の世代が大量にあるわりにあの頃のはどれもプラカバー付きで遠目には全部同じに見える・・・。実際問題うちで自分で使ったことは無いんですよねぇ。

Re: あるぇー・・・ - KAZ.K

2022/12/18 (Sun) 10:10:25

負荷テストかけてたら今度は確実に MEMORY ERROR であがってこなくなりました(^^;;;;;;;;;;;

Re: ポチ - reiria

2022/12/18 (Sun) 20:38:03

みんな同じ顔ぽいですが記念に遺影撮っときました(;_;)/~

思えばうちの 98 で初めて買ったメモリがこの EMJ-4000L で、
当時何となくこれ買っちゃったせいか、その後、SCSI もメルコ、GA もメルコ・・・
メルコと心中ルートに迷い込む元凶アイテムだった気がしなくもないヌ(;_;)

Re: ポチ - KAZ.K

2022/12/26 (Mon) 10:11:01

うちもGRのメモリはめるこでしたが、ソフト面ではXMSCACHEにHDDぶっ飛ばされた恨みしかありません(^^;;;;;

でXv改。なんとなく治っては再発を繰り返していてどうにもならぬ・・・、というかだな、そもそもCPUが起動しない状態(=電源スイッチを長押ししなくても電源が落ちる)から、他には一切触らないようにそーっとソケ5のレバーを上げ、ただけで何もせずにそのままレバーを下げると、何故か何事もなかったかのように普通にピポって起動するんですよ。まじでなにこれ。

Re: ポチ - reiria

2022/12/26 (Mon) 15:37:14

弊社の市場調査に関する内部資料によりますところtowernmiのtowerはXvのtowerに他ならヌとの蓋然性に予断を許さヌもいささか時期尚早との
報告も上がっておりますゆえに事は火急を極めかねヌ由々しき事態でございますヌ(^^;

Re: ポチ - KAZ.K

2022/12/26 (Mon) 22:55:21

ひとまず今日は無事に動いていたけどいつまで保つやら。むーん。

プログラム名なんてだいたい頭文字そのまんまだし基本何も考えてないヨ。頭のTつけたら一文字はみでるなー、あーでも頭すげ替えても読めるからこれでいっかーくらいのノリだった気がする。

見返してみるとなにやら捻ったっぽい名前が付いているものもある、けど・・・実のところ自分でも何でそんな名前にしたのか覚えていないやつがあって、そういうのに限ってソース見ても由来が書いてないし、今となってはどこから何が湧いて出たのやら見当も付かない(^^; 特に自分で使うつもりが無く書いたコードはだめですね、中身も何だったかまるっきり記憶に無い。うん普通に頭ボケてきてるのでは(((

Re: あーるぇー・・・ - KAZ.K

2022/12/28 (Wed) 11:11:55

まあ当然のように一日保たずに再び死んだわけですが。

もうここまでダメなら仮に手が滑ってとどめを刺しても何も変わらぬということで、開けたまま通電してあちこちつんつんモミモミしてみた。ところ・・・、わかった、わかっちゃったよ。VRMソケットのあたりをちょっと押すと100%確実に即死するw これパターン割れか半田クラックかどっちかだww

幸い(?)押すと死ぬツボも引っ張る分には大丈夫っぽいので、VRMソケットの真横あたりで母板の裏側から押し上げる向きに枕を押し込んでみた。現在様子見中。ひとまず起動はしているしツボを押しても死なない。死んでない!

・・・えぇー・・・。

Re: ポチ - reiria

2022/12/28 (Wed) 13:14:08

ツボと経絡秘孔に違いはあるのか一抹の不安も拭えないところですヌ(;_;)

Re: ポチ - KAZ.K

2023/01/05 (Thu) 22:09:08

フタ閉めて一週間経過しました、今のところ元気です。

最後の方は長くとも二日は保たなかったところからの改善なのでひとまずは大丈夫かなーと。どこかに亀裂が潜んでいる想定である以上はそのうち再発するだろうけど、ヒートガンで炙ってワンチャンってのもそれはそれで侵襲的だし、枕でごまかせているうちは問題先送りということで一つ。

そのままフタ閉めてしまったので速度落としたままだけど、今更余計な力かけたくないしもうこのままでいいや。Xv20改(200MHz)。改とはいったい。いやまあそれでもHELPだけではセットアップメニューに入れない程度には速いんですが。

Re: ポチ - reiria

2023/01/06 (Fri) 17:10:39

何か調子が変なとき安易にガンガン筐体叩かないほうが良さげな気配は把握いたしました(^^;

そういえば - KAZ.K

2023/01/21 (Sat) 23:21:28

APM BIOS の実処理部分(の一部または全部)はSMMに追い出されていて、普通のリアル空間のF680に出ているBIOSには要約すると jmp $ しか書いてない。その直前でなにやらごにょごにょやっているのがSMI発射操作なわけだけど、なんとなくXvのBIOSを見ていたらそこに out 43F, A0 つまりキャッシュフラッシュがしれっと紛れ込んでいることに気がついた。思わず二度見したけれどRaにはやっぱり入っていない。

・・・もしこれが残っていれば、W?2 とか TTwT とかしなくても、少なくとも電源断くらいはそのままで何となく動いたのでは・・・?

ただしこのフラッシュが本当に役に立っているのかどうかはだいぶ謎である。何しろフラッシュしているのはSMI発射前だけで、SMMから戻ってきた後には入っていないので、後片付けにはほぼ確実に漏れがある。つまりこのフラッシュだけではSMRAM領域をキャッシュ有効にできるようにはならないし、キャッシュしていないなら最初からフラッシュしていなくても問題なさそうな気がする。・・・なんとなくノリと勢いでフラッシュいれちゃったんだろうか。NECのすることだしなぁ。

結局のところSMRAMはキャッシュせずに逃げ切るのが王道であって、手動フラッシュが必要な時点で何かがおかしい・・・筈、なんですよね。外からSMIきたらどうするんだっていう。なればこそ TTwT p1 でSMM乗っ取りに至ったというのに、実は歴史ある伝統的なBIOSの方が実質的に p0 相当の劣化版だったという・・・なんだろうこの、なんかモヤっとする感・・・。

そういえばA08は前後の文脈からしてSMIの配送保留マスクですかね。A09/A0Aの見た目二段階I/Oはなんとなく碁盤目に並んでそうでいて実際には値固定のところが多くて微妙に判断に困る。

Re: ポチ - KAZ.K

2023/01/22 (Sun) 10:24:16

そういえば長押しタイマーでない即時の電源断は推定SMI経由だったような・・・と思い至って試してみたところ、うん、予想通りA08=0で電源スイッチからの即時電源断が無期限に保留されますね。1に戻したとたんに電源断が走る。だからCPUが死んでいたら即時電源断が利かないのも当然なわけですナー。

[00]&80 → [03]&1でSMI発射 (入出力両側マスク)
[32]=0or3 → スイッチ無動作っぽい?
[32]=1 → スイッチでSMI発射
[32]=2 ![30]&1 → スイッチ無動作っぽい?
[32]=2 [30]&1 → スイッチでNMI発射
[30]&2 → [03]&2でNMI発射

[02]&2 ← スイッチ入力#

[01]&2 ← スイッチからSMI発射待機中
[01]&80 ← [03]&1からSMI発射待機中
[31]&1 ← スイッチからNMI発射待機中
[31]&2 ← [03]&2からNMI発射待機中
[01],[31] → ビット毎に0の書き込みで発射解除

うん、やっぱり単純な碁盤目ではないな。[03]が手動発射入力(NMI:SMI)、[32]がスイッチ入力の接続先選択(ここはビットマスクではない)、[30]が各入力→NMI出力のマスク、と。SMIは発生源がどちらでもA08=0の間は配送が保留される。NMIも同様に50/52で配送が保留される。

他に [00]&07 と [20]&10 も値を変更して読み戻せるけれど今のところ手がかり無し。電源スイッチの長押し0.5秒目あたりで [10][11] が 02:00→03:08→03:F7→02:08 と変遷するあたり、これECのステータスか何かが見えているのかな。でも[11]はたまに違う値になることもある。謎。このへん油断すると電源が落ちてしまうので(^^; A08とかで阻止できない部分は調べようがないぬー。

Re: ポチ - reiria

2023/01/22 (Sun) 13:03:12

SMM タイプの APM BIOS でキャッシュフラッシュしてる機種があるってことは、
その手の機種で DOS 同梱の power.exe なんかを組み込んだ場合、
9A05h のぶん回しで hlt するだけではなくキャッシュフラッシュしまくってることになりそうですな(^^;
(off か std の時はぶん回されない)

Xa16/R16 は発売時期が Xv に近いし、早速 APM BIOS 眺めてみたところ、これは SMM タイプではないようです。
/W 型番以降だと SMM タイプだったりするんですかヌ。

Re: ポチ - KAZ.K

2023/01/22 (Sun) 14:40:43

えー/Wと/Rって IDE BIOS がINSD/OUTSDかINSW/OUTSWかだけじゃないのん・・・。むしろ山猫ではSMM避けてたのほうがありそう。

ともあれRaだと fn 9A の時点で迷わずSMM直行ですが、Xvは subfn 02,03,05 は表BIOSで処理が完結していて、一応そこまであかんことにはなっていない模様です(^^;

ただこれ、subfn 02 03 で表からSMRAM開けて何かしているところでも、開ける前だけフラッシュ入れてあるんですよねぇ。いったい何を気にしたのかいまいち理解できぬぅ・・・。

追) 発射解除も判明したので上にまとめた。
追2) ってあーそうか、Xaは枝番で中身が別物に変わったやつだ。合ってるけど間違ってるよ、紛らわしいな!

Re: ポチ - reiria

2023/01/22 (Sun) 18:14:55

Xa16/R16 APM BIOS を改めてよく眺めてみましたが、SMM は使ってないと断言してよろしいのではたぶん(^^;

Xa16/R16 の 9Axxh の各ファンクションのポインタが用意されているのは、

00 ~ 0B
24
25
3A ~ 3F

で、これら全てのファンクションにおいて SMM に移行するようなコードは皆無ですね。

そもそもこの機種は SMM に移行出来るのか疑問に思えてきたというか、
BIOS 全体に 0A08h ~ 0A0Ah で I/O するコードが無いっぽいし、0A08h ~ 0A0Ah の in がどれも FFh っぽいし、
仮に SMM に移行出来るとしても、手順は Xv や R 系とは違うんじゃなかろうか・・・(^^;
まだ確認していませんが、マシン起動時の BIOS コピー元に SMRAM 用のコード自体無いのでは疑惑。

Re: ポチ - reiria

2023/01/22 (Sun) 18:56:07

> Xvは subfn 02,03,05 は表BIOSで処理が完結

とりあえず 05 が大丈夫なら大丈夫そう(?)ですな(^^;
ただ、05 みたいなぶん回しではないものの、0B もちまちま実行され続けるという・・・。

そういえば、Xa16/R16 APM BIOS はプロテクトモード絡みのファンクションはサポートしていないようで、
やはり SMM タイプじゃないとそのへん駄目なんだろうなという印象です。

> 追) 発射解除も判明したので上にまとめた。

おお、貴重な激レアアイテム情報ありがとうございます(;_;)

Re: ポチ - KAZ.K

2023/01/22 (Sun) 20:27:15

SMMなんてハードウェア的にSMIを発生させる仕込みがなければ基本なんもできない役立たずなので、本来のROMに使っている形跡が無いとなると見込みは薄いかもしれませんねぇ。だいたいSMMはCPUの機能ではあってもチップセット側の協調動作を要するわけで、いんてるでいうところのSMRAMレジスタ(PCI config 72h)相当が山猫だといったいどこにあるのやら。

ノート機だとSMIの横やりが仕込まれているI/Oがもう少しあったりするのかもしれないけれど、今のところXvとかRaとかで明らかなのは手動発射と電源スイッチだけだしなぁ。強いて応用を考えるとすればSMM乗っ取り方式で電源断をリセットに化けさせるくらい? 理論上はNMIをプロテクト側で拾うよりさらに強靱なリセットになるはずだけど、そこまでする意味あるんかいな・・・(^^;

Re: ポチ - reiria

2023/01/23 (Mon) 21:16:41

・V166 (青札) は全て SMM 直行、キャッシュフラッシュ無し。

・RvII26 は 02,03 だけ SMM 使わず表で SMRAM 書き換え、キャッシュフラッシュ無し。
(05 は SMM というのが Xv と微妙に異なりますな)

ちなみに、RvII26 の AP (CPU2) の SMI の飛び先は BSP (CPU1) とは異なって A8000h なのですが、
そこに APM BIOS は存在せず、RSM する(戻りアドレスそのまま)か、SMM 内で HLT するようになっています。

なので、AP で DOS を BSP 同様に動かそうとする場合、
BSP の SMRAM の APM BIOS を AP の領域にコピーし、BSP 用の A0000h 決め打ちコードをパッチすると、
AP でも何となく APM BIOS が使える(?)ようになって、power.exe や電源オフや Windows95 は動くっぽいものの、
意味不明で危ないだけのネタで常用出来るような代物とは思えませヌの・・・(^^;

Re: ポチ - reiria

2023/01/23 (Mon) 22:05:02

> そこに APM BIOS は存在せず、RSM する(戻りアドレスそのまま)か、SMM 内で HLT するようになっています。

これ、正確には BSP との同期待ち無限ループがあるので、

・SMM 内で BSP との同期待ち無限ループ
・SMM 内で HLT
・戻りアドレスそのまま RSM

のいずれか。と書くべきですな(^^;

Re: ポチ - KAZ.K

2023/01/23 (Mon) 22:25:58

MP環境だとAPICが生きているから特段の外部回路無しでも手が滑ってSMI送りつける可能性がなきにしもあらず? でもHLTは何のための仕込みじゃろ。・・・電源スイッチSMIがAPにも行っていてBSPが電源落とすの待ってるとかか?

Re: ポチ - reiria

2023/01/24 (Tue) 00:56:21

AP が活性化している場合、BSP で普通に APM BIOS を実行すると BSP と AP 両方に SMI が発生します。
で、AP 側 SMI ハンドラは BSP 側 SMI ハンドラと同期待ちした後、そのまま RSM するような流れのようです。
(要するに AP 側のプログラム等はそのまま実行再開される)

ただ、APM BIOS なんか実行しなくても SMI が発生する場合もあるようで、よくわかりません。
(power.exe 等のソフトではなくて何かの BIOS 内で APM BIOS 実行してる可能性はあるかも知れない)

HLT する場合ですが、これもまだよくわからないです。
APM BIOS とは違う要因で発生した SMI への処理っぽくも見えて、よくわかりません。

ともあれ、AP 側 SMI ハンドラの挙動は、BSP 側 SMI ハンドラからの指示によって決められているようです。

Re: ポチ - KAZ.K

2023/01/24 (Tue) 08:23:53

はほー。とすると外部回路からの SMI# 駆動はとりあえず両方につながっていて撃ち分けが無い感じか。

> APM BIOS とは違う要因で発生した SMI

そもそも(中身の詰まっている方の)SMIハンドラの入り口からしてだいぶ作りがいい加減な感じで、ぶっちゃけAPMとかの想定されているBIOSでないところから勝手にSMI手動発射すると「余計なことをしてから」RSMするんですよね。Xvでsymdebが一番おもしろくて、SMIの発生に至る o を実行すると ^ Error が出る(^^;;;; out命令にエラーステータスがあったとは初耳であるなー(^^;;;;;;;

Re: ポチ - KAZ.K

2023/01/24 (Tue) 08:49:17

ってーあー何でこれ見落としてたの、[00]は他のビットもSMIの発射マスクですね。02おとしたら電源スイッチ沈黙した。今から上のやつ編集しま・・・、と思ったけど見にくいので書き直した! これでどうだ!

--------
[x0] ←→ 入出力マスク 0=入力無視+発射保留
[x1] ← 発射(待機)中ステータス
[x1] → 0=発射待機解除 1=nop
[0x] SMI
&80 [03]&01 手動発射
&04 たぶんSERRあたり
&02 [32]=1 ← スイッチ
&01 たぶんMMDUMP
[3x] NMI
&02 [03]&02 手動発射
&01 [32]=2 ← スイッチ
--------
[02] &02 ← スイッチ入力#
[32] ←→ スイッチの接続先選択
0or3 無接続っぽい?
1 → SMI (&02)
2 → NMI (&01)
[03] → 手動発射トリガー
&02 → NMI (&02)
&01 → SMI (&80)
--------
[10] ← たぶん電源EC
&02 EC DATA WRITE READY
&01 EC DATA READ READY
[11] ← EC DATA READ ???
[13] → EC DATA WRITE
80 06 00 00 初期化っぽい
80 07 00 02 電源断前準備?
80 01 00 00 電源断
--------
[20] ???
--------

補) たぶんSERRあたり: チップセットにメモリECCエラーが記録されていたらNMIを発射するように書いてあるように見える。チップセットがSERR#→SMI送出設定になっている場合でも従来の挙動を維持するためのshimっぽい。ただし少なくともXvではSERR#→NMI送出設定になっているのでこの機構が実際に働くことは無さそうに思える。(Raというか440FXだとSERR#からNMI#/SMI#への接続は本来PIIX3の領分らしくちょっとはっきりしない)

補2) たぶんMMDUMP: SHIFT+CTRL+STOP+スイッチSMI と等価。

Re: ポチ - reiria

2023/01/24 (Tue) 20:14:34

> 撃ち分け

RvII26 の AP 側 SMI ハンドラのあまりのシンプルさを見た感じでは、撃ち分けは無いのかも知れませんな。
AP 側 SMI ハンドラには SMI の発生要因を判別する処理が無く BSP 側からの指示待つだけぽいので。

で、AP 側 SMI の挙動が HLT かそのまま RSM かの二者択一しかないとなると、
AP を HLT させる場合の「AP を止めて構わない何らかの SMI」は正確に判別出来るようになってるんでしょうね。
でないと、マルチプロセッサで動いてる OS で突如 AP だけ沈黙みたいな妙なこと起きそうですし(^^;
(まあ普通そういう状況は BSP も一緒に止まりそうですが)

> これでどうだ!

壮観になってまいりましたな(;_;)

Re: ポチ - KAZ.K URL

2023/01/25 (Wed) 01:07:02

> SMM乗っ取り方式で電源断をリセットに化けさせる

ぼーっと眺めていたら比較的シンプルにいける方法を思い付いたので、そんな感じでいちおう作ってみた。たぶんMMDUMPっぽいやつを踏み潰し+論理反転しています。なのでスイッチ単体でリセット、SHIFT+CTRL+STOP+スイッチで電源断です。キーボードリセットしてキー入力判定が入るのでNMI方式よりは若干時間がかかります。

ただこれ、原理的な危険性に見合うだけの意味があるのかどうかは定かでありませんな(^^; 単にCPUが迷子になっているだけならSMIで生還できない条件はほぼ無いはずだけど、キャッシュとかFSBから先とかがぐにょんぐにょんになっていたらどうにもならないんですよねぇ。だいいち誰かが手を滑らせてSMI止めていたらそれだけで詰むわけで。正直「長押ししないと電源が落ちない」状態なんてわりとしょっちゅうよくあるのでは()

追) 上に電源ECを書き足した。二段階I/Oがだいたいわかって読めてきたおかげでそれっぽい感にはそれなりに自信があるものの、そもそも EC DATA READ のように見えるコードはバグっている気がする・・・が呼び出し元も見あたらないような。なんぞこれ。

追2) うんECひっぱたいて電源落ちるのは確認とれた。実際の電源断コードでは初期化からやり直しているけれど、とりあえず最後の電源断コマンドだけで電源は落ちる。
初期化コマンドの実際の意味は不明。初期化の流れで送られているというだけ。同様に前準備コマンドの意味も不明で、特段に電源スイッチが無力化するわけではないし、割り込みの発生や長押しタイマーの動作にも変化無い気がする・・・、けど、あんまり電源ばちばちしたくないし、これ以上の追求は後の人に任せます:-)

Re: ポチ - KAZ.K

2023/01/25 (Wed) 16:19:06

む、むむむ・・・何らかの(作られた)事情でNMIが一度不発、した状態からTowerNMIを実行しても、リセットできる状態にはならないことに気がついた。

要はA09/A0A近辺からの出力が、システムポートC近辺でもう一度ラッチされて、からさらに50/52でマスクという流れなので、A09/A0A側での発射保留はSMIと同じようには働かないし、portC&10も落とさないと不発弾が残り続けるぞ、と。・・・なるほど確かに50/52でエラーは解除されないと書いてあるな、めんどくせえ!

普通にTowerNMIしているだけだったら気にするほどのことではなさそうだけど、TowerSMIを作ってしまった以上は今やNMIはそれなりに自由の身(?)であって、もしかしたら好き勝手な他の用途()に使われた結果として不発したままになっている可能性が無きにしもあらずんずん・・・? いや正気か?? (:_;)

まあ気が付いてしまったからには仕方がないので後で更新しておきます・・・おきました。ぐすん。

Re: ポチ - reiria

2023/01/26 (Thu) 10:42:49

早速頂きました~ (^^)/ > Tower 系一族

この機会に今度こそ Ra266 を蘇生させたい・・・ってここ数年毎年同じこと言ってるような(^^;;;
今回はモチベーションがちょこっと上昇中なので何とかしたいところですヌ。
といいますか、RvII26 APM BIOS の AP 化で派手に書き換え中で、Ra266 でも比較検証しないとまずいかなと(^^;

しかし今回の件でデスクトップ系の APM BIOS にも微妙な違いがあるのがわかってよかったというか、
今まで、デスクトップ系の APM BIOS は Windows とかで何となく AT 互換機っぽく装いたいだけの表面的なもので、
デュアルプロセッサ以外全機種全く同じコードだろくらいに思い込んでいたヌで(^^;

Re: ポチ - KAZ.K

2023/01/26 (Thu) 12:23:01

危険物シリーズは基本ネタの種のPoCな感じで労力最小な必要最低限、なんぞ使えるネタがあればいつも通り煮るなり焼くなりお好きにどうぞ的なアレなので、あんまり細かいところを気にしても意味ないような気はしないでもない。贅肉ばっかり増えても読む人からしたら何の嫌がらせかって話だし。・・・おまえのことやぞNEC! なんなんだこの藪コードの山は!! (^^;;

# なお自分で書いたコードの方がもっと酷い有様な模様(ぁ

> 数年毎年

えーピポピポRaでしょ?
前から言っているけど、まずは電源スイッチを引っこ抜いてもまだ勝手にピポるか試そうよー。勝手に電源が入ったり切れたりする不具合なんだから、最重要容疑者は至極当然に電源スイッチ本人に決まっているじゃないか。勝手に入る方はそのままで実験できるし、勝手に切れる方は・・・電源入れてから引っこ抜くなり、なんか金物で適当につつくなり?

追)改)、というか、だ。
50と37,8でNMIせき止めて[32]=2 [30]=1にして[31]を監視すればスイッチ暴発の証拠を押さえられるのでは? 押してもないのに1になったらもう絶対にクロじゃん。[02]の監視でもいいけど短いパルスの取りこぼし偽陰性の可能性が残る。長押し判定くらったら電源落ちるのは止められないけれど、少なくとも長押しカウントダウン中までは観察できるはずだし、感があったら七色にフラッシュしてけたたましくbeepならす的な。

ぉゎ - KAZ.K

2023/01/28 (Sat) 13:30:20

いつのまにか openwatcom.org (V2 fork じゃない方) が息を吹き返してい・・る? そうとしている? ちからをためている? いや単に手が滑ってブックマークを間違えてつついただけなんだけど。

Re: ポチ - reiria

2023/01/29 (Sun) 11:49:38

というわけで 2 年ぶりくらいに Ra266 に通電していますが、またしても全く問題なく普通に動いてますね(^^;;;
前回は 3 週間ほどピポピポせずに動き続けましたが、今回はさてどうなることやら・・・
普通に動いているうちに早速 TowerSMI も試してみまして、さくっとリセット出来ました~ (^^)/

Re: ポチ - KAZ.K

2023/01/29 (Sun) 13:47:16

ピポピポさんはまずは真犯人の特定が先決だと思いますだギャーT_T

TowerSMIで現実的な範囲内の手間でSMIを取れるという実証にはなったと思うけれど、他の用途に使うにしてはSMMっていうほど便利じゃないですからねぇ。表が何modeだろうと容赦なく飛んでくる代わりに、表がどういう状態なのかSMMの内からはほぼ何もワカラナイ。

なので、どちらかというと今回の探索の成果はそれ自体ではなくて、「たぶんノート機で使っていたはずのSMIトラップ配線はデスクトップ系にはおそらく存在自体していない」という知見のほうですかね。どう見てもSMIマスクの動くビットに余りが無いので。もちろん全く別の回路がある可能性は否定されないけれど、いくらなんでもねぇ。要はAT機でいうところの USB Legacy みたいな仕込みをする余地はどこを探してもたぶん無いぞ、と。

お、ぉお・・・? - KAZ.K

2023/02/17 (Fri) 10:59:50

メインエンジン点火してからのabortはそこそこレアな気が。

Re: ポチ - reiria

2023/02/17 (Fri) 13:35:59

このスレが39とロケットとA代表のスレだったような記憶を思い出しましたヌ(;_;)
会見の内容次第ですが、些細な問題なら実は妨害工作あぶり出しのフェイントだったり・・・(^^;;;

Re: ポチ - KAZ.K

2023/03/07 (Tue) 10:46:00

2nd stage が死んでいる!

Re: ポチ - reiria

2023/03/07 (Tue) 10:59:24

うむむ残念(;_;)
てか2段エンジンが点火しないって今まであったっけ・・・

Re: ポチ - KAZ.K

2023/03/07 (Tue) 11:26:03

2ndでコケたのっていうとH2無印の5ですかねぇ。点いたけどけっこうすぐに壊れて止まった的な。余所のだと(再)点火失敗ってけっこうよくあるパターンだけど、点火に失敗したのか点火を拒否ったのか、さてなにがどうしたやら。

LIVEのタイムライン表示が実際のテレメトリをちゃんと反映しているのに数秒待っても 2nd 点火がクリアにならない時点で「あ、おわった」ですよね・・・。前回の中止の時は 1st cutoff の表示がすぐに飛んできたから、あこれは正常の範囲内での abort だってある意味安心したものだけど。

Re: ポチ - reiria

2023/03/07 (Tue) 12:09:12

ログ見てさくっと原因絞り込めたらよいのですけれどもねえ・・・
H2A,B の試験とかでも今まで経験したことのないような不具合だと時間かかりそうですヌ。

Re: ポチ - KAZ.K

2023/03/08 (Wed) 13:58:45

H3って1stのメインエンジンを除けば他はおおむねH2Bの小幅改修程度って思われがちだけど、本質的にやっていたのは制御系の全交換ですからねぇ。いわゆる初物キケンを地でやっちまった感はしないでもない。

いやまあ仮に制御系の問題ならそれは地上でちゃんとしとけよという話なので、これんぽっちも言い訳にはなりませんが。SpaceX的な「とりあえず燃やしてみよう」みたいなやり口は技術面とは一切関係ない諸々の事情で採用できない以上、昔ながらのひたすら品質管理でどうにかするしかないわけで。

しばらく前に制御ミスでいきなり自爆した観測衛星とかもだけど、宇宙機っちゅうやつはどんな些細なポカ一つでもわりと簡単に即致命傷になるわりに、飛行機ほどの台数稼ぐ余地はまだどこにも無いからなー。そうして余計に立ちはだかる予算の壁・・・!

Re: ポチ - reiria

2023/03/08 (Wed) 15:25:34

昨日の会見だと、点火コマンドが出たのかどうかもまだはっきりしていない雰囲気でしたな。
まあもし単純な問題で順調に調査進めば1,2週間以内に何か発表ありそうだし、何とか頑張ってほしいところですヌ。

Re: ポチ - KAZ.K

2023/03/08 (Wed) 18:39:17

今日の資料の書き方だと着火命令に対するackまではとれてるっぽい? そしてまたもや電源異常!

Re: ポチ - reiria

2023/03/08 (Wed) 20:59:56

そのようですね。何らかの異常がちゃんと記録されていたっぽいのは朗報に思えますな。
地上の実機でさくっと再現してくれるとよいのですが。

ML2430 - KAZ.K

2023/04/02 (Sun) 11:56:06

今更に考えてみたらmaxell供給のML2032で済ませてもよかったような気がしてきた。FDK供給のML2430と比べると定格容量が2/3、標準放電電流が2/5だけど、そもそも動かすの時計だけだし、組成は同じだから電圧は完全互換で何の心配もない。最初からちょっとへたってるML2430だと思えばどう考えても足りるじゃろ・・・。

まあ普通に売ってるのだとリードなしの裸品だからソケット(っぽいなにか)は用意しないとだけど、ぶっちゃけ絶縁ごしにクリップで挟んでやれば用には足りそうな気が()

Re: ML2430 - reiria

2023/04/02 (Sun) 14:33:27

それでうまいこといけばもうそれで98電池枯渇問題消滅する神の一手なのでは・・・(^^;
ソケット的なの使うほうが交換も簡単そうですし、誰か試してそうな気もしますがどうなんですかねえ

Re: ML2430 - KAZ.K

2023/04/02 (Sun) 16:19:30

大雑把計算だけど、もし本体の消費がML2032の標準放電電流0.2mAを超えているなら、元のML2430でも満充電から空っぽになるまで20日以下になるはずですからねぇ。どう考えても新品ならもちっと保ってたじゃろ普通。

ML2032はなんとyodoに普通に在庫があるので、ついでにソケット的なのも調達するなら UM-CR2032NH あたりですか。元の電池から剥がした本体側のコネクタ電線くっつけてから適当に足畳んでテープ止めしとけばいいんでね? ノート機だと電池転がすスペースに余裕ないとかあるかもだけど、デスクトップなんてどうせ中身スッカスカなんだし。

この手で実用上問題ないなら、むしろ交換が詰んでいるのはVL系の連中ですか。いやVL2330はまだPから供給あるのか・・・な? 3pinの中央空きでVL系の母板は黒(-)ピンを中央に移動すればMLでもいいらしいけど。NiCd/NiMH系のは単三か単四かつないで作ればいいだけなので、置き場所の都合さえ付けばどうでもいい。

・・・などと色々言ってはみたものの、うちの手元の二台は両方とも電池交換済みなんだよなー。もう一度電池がお馬鹿になるよりもっと別のところが再起不能になる方が早い気がする・・・。

Re: ML2430 - reiria

2023/04/03 (Mon) 09:36:09

ちょろっと検索すると CR2032 でやってみた人はちらほらおられるようですが、
なぜか ML2032 での実例は見当たらないような・・・話として単語は出てくるので認知はされているようですが。

とりあえず保存用、観賞用、布教用、炎上用、誤用とかでいくつかポチってみようかと思うものの、
ソケット的なやつの接点のメッキ云々はこの際見て見ヌふりしてもよさげですかヌ(^^;;;
maxell 公式の ML2032 の端子付製品の資料 ml2032tw_12j.pdf にはスズメッキとの記載がありますが、
これは電池と接触してる部分のメッキのことではなさそうですね。

VL2330 は Panasonic 公式の法人用二次電池商品一覧に出ていますが、お手軽に流通しているかは謎ですな。

Re: ML2430 - KAZ.K

2023/04/03 (Mon) 11:03:46

メッキ不適合? 仮に多少囓られたところで実害が生じるほどの電流が流れるわけもなし、ほぼほぼ机上の空論だとおもうけどなー。

それよりソケット的に交換できる状態だとどうしても導電部が露出になる方が気になる。余計なところに触って短絡しないようにせんと。

Re: ポチ - reiria

2023/04/03 (Mon) 11:21:44

うむ、では早速ポチりますかヌ(;_;)

とりあえずリード線長くしてソケットは筐体外に出そうかと思ってるんですよね。
って 50cm くらい長くしても大丈夫?なのか?たぶん(^^;;;

Re: ポチ - KAZ.K

2023/04/03 (Mon) 11:56:12

元々電池の内部抵抗高いからちょっとやそっとなら誤差のうちじゃないかぬ。平行で引き回す分にはそうそう毒電波拾ったりもせんでしょ、たぶん(^^;;;;;

データシート見てるならわかるだろうけど、ML系って元々それほど耐久性の高い構成じゃないんですよね。特性としてはほんのちょっと放電してほんのちょっと充電しなおすの繰り返しに特化していて、全放電・全充電だとせいぜい30~40サイクル程度しか保たず、空っぽになるまで使い切るような使い方には全く向かない。この点どうやっても多少はメモリー効果のあるNiCd/NiMH系とはまるっきり逆ですなー。

Re: ポチ - reiria

2023/04/04 (Tue) 22:18:10

ヌ~ (;_;)/~

Re: ポチ - reiria

2023/04/14 (Fri) 21:08:09

で、4日間連続起動してもカレンダ消滅する Xa16 を ML2032 にしてみることにしました。

Re: ポチ - reiria

2023/04/14 (Fri) 21:09:07

電池はこんな感じ。

Re: ポチ - reiria

2023/04/14 (Fri) 21:10:16

これもポチりましたが今回は使いませんでしたヌ(^^;

Re: ポチ - reiria

2023/04/14 (Fri) 22:04:47

先ほど Xa16 に取り付けて、まだ 30 分くらいですが、ばっちりカレンダ保持出来ておりまする(T_T)

Re: ポチ - KAZ.K

2023/04/14 (Fri) 22:57:13

あー本体側のコネクタも新品調達してたのね・・・?

あとは寿命がどうなるかだけど、とはいえどうせ元が完全にアカン状態からの交換なんだし、ねぇ。少なくとも無理矢理CR突っ込むよりはお気楽でしょー。

Re: ポチ - reiria

2023/04/15 (Sat) 10:51:47

きっとやる気出るのは今しかないなと思って本体側のコネクタも作ってみました(^^;
寿命はどうですかねえ、今日から2日間連続起動した後、カレンダ消滅した時はここで報告したいですヌ。

あと、画像見て誰か真似するかもなので、一応注意点としては、
画像の電池ホルダ(あちこちで大量に売ってるけど謎の業者回避なら共立エレとかでも売ってる)のリード線ですが、
芯線が細くて画像のお手軽コネクタで普通にやると芯線を噛まず導通しない場合があります。
なので被覆を剥いて巻きつけて噛ましてあります。画像拡大するとちょろっと銀色に光ってるのが芯線です。

ぅーんぅーん - KAZ.K

2023/06/08 (Thu) 18:57:19

何かおかしいなぁと思いながら今までずっと放ったらかしにしていたんだけど、

autoexec組込の LAMD Dx において、0.46a までは放っておいても最初からダミードライブが隠蔽されていたのが、0.47a 以降だと組込時点で _ を明示してもなお隠蔽されず、組込後に再度 _ してようやく隠蔽されるのは想定通りでありましょうや?

そしてごちゃごちゃやっているうちに 0.47a 以降の LAMD を H B で組み込むとTATOKDが常駐部作成に失敗することに気が付いた・・・のでこっそり直しておいた。こっそりこっそり。

あーぁー - KAZ.K

2023/06/24 (Sat) 22:57:32

> 何かおかしいなぁと思いながら今までずっと

これ、なんでこんなに放置していたかというと、その頃に一通り更新を試みたらUMBへの詰め具合が致命的にずれて、結果当たり前にGVRAMを踏み潰して暴走という初歩的なミスをしでかしまして。とりあえず全部巻き戻してふて寝したあたりで以来そのままに()

で、今になってそもそも何がずれて事故ったのか調査したところ、・・・よく見たらLEMMの直後初手でDEVICEHIGHしているJACKがもうずれてるじゃないですかヤダー・・・。そして初手がずれたらその後のも釣られてずれてるーヨー・・・。

まあ言われてみれば、更新と共にJACKの外形サイズは変わっているんだから、DOS側の謎ブロック選択論理が突然に変心を来したとしても何ら不思議は無くて、いくら常駐量“は”変わって無いと言ってもそんなの気休めにすらならないのであった。あうち。

ただし。・・・ただし、である。元々 -UD.,E[8-F] のUMBに対して、JACK が 0.53a の時点では堂々と D0 の頭にロードしていたのに、なんでJACKが少々大きくなったとたんに元の D0 より狭い E8 に移動したくなったのか、コレガマッタクワカラナイ。こんなの突然に変心を来したとしか言いようがないのでは???

まあそんなこんなで理由はともかく状況は理解した、ものの、かといってUMBUTYとかで八方塞いで詰めるのも平たく言って面倒くさいし、さてどうしてくれようかと悩むことしばし。そういえばDEVICEHIGHのメモリ確保計算はオーバーライドできたはずと思い出したので、適当に SIZE=32768 と書き足したら無事に D0 に戻ってきた。おぉー。のでそれでいいことにした。はい終了! 解散!

・・・え判定が転ぶ値を調べるべきだって? んなもんどだい意味不明論理な時点で何が何に影響するのかわかったもんじゃなし、調べても何の役に立たないよ!(--;

Re: こっそり - reiria

2023/06/25 (Sun) 02:10:05

あれ・・・ 2023/06/08 の書き込みって削除されてませんでしたっけ???(^^;;;
書き込みあるとメール来るので内容は把握していたのですが、その時掲示板確認したらなぜか見あたらなくて、
削除されたのかなと思ってスルーしておりました(^^;;;;;;
ブラウザキャッシュだったのか・・・何だか今まで無視してたみたいになっちゃっててすまんです。

LAMD のコマンドライン組み込み時に指定した _ が無力なのはばっちり処理不足でした(;_;) 次版で修正したいです。

Jack の UMB 常駐位置が変わったのは Jack 自身の UMB 常駐処理がこっそり変わったからかもです(^^;
実はここ数年更新した常駐物のいくつかは UMB 常置処理がこっそり変わっていて、
Jack v0.55a 以降の場合、UMB 常駐方針を指定するオプションとして、

UL → UMB 最下位から探して常駐
UH → UMB 最上位から探して常駐
UM → UMB 最小領域から探して常駐 (default)
UA4 → A4 への常駐を回避しない (default 回避する)
!U → UMB に自力常駐しない (DEVICEHIGH なら UMB ロード位置そのまま(v0.54a 以前互換))

を追加したのですが、ドキュメントには記載しておりませんで、次版にはこっそり書いておきたいですヌ(;_;)

Re: ポチ - KAZ.K

2023/06/25 (Sun) 05:17:26

ナヌー。突然の変心は冤罪だった!!! ・・・まあよくある話や(ぇ

しかしそれならそれで、なんで SIZE= 書き足しただけで挙動が変わったのかが謎なような? 別に SIZE= してもそれ自体に自力探索の邪魔をしそうな効力は無さそうな気が。

Re: ポチ - reiria

2023/08/12 (Sat) 11:21:02

今まで使ってたエレコム TK-FCM103 の Enter が時々押下したまま引っかかって戻って来なくなってきて、
打鍵感も飽きてきたし、久しぶりに Filco のやつでもポチるかと最近のやつ調べてみると、
現行の Majestouch 3 テンキーレスにかな有りが無い? いやそんなまさか・・・
かな有りの需要って今そんなに少ないヌ?(^^;;;

で、何となくロジクール K835 をポチってみたところ、さくっと PS/2 では使えませんでした(;_;)
まあ今時 PS/2 でも使えちゃう自称 USB キーボードのほうがおかしいかもですが、
エレコムの格安のやつとか、USB PS/2 両対応が普通だった頃の古いパーツ在庫処分的な中身なんじゃたぶん(^^;

Re: ポチ - KAZ.K

2023/08/12 (Sat) 12:35:37

今のご時世、お高いキーボードになればなるほど文章入力用じゃなくてゲーミングデバイス扱いなのん・・・キーを特定する記号なんて一つあれば十分なんなー・・・

、というのを脇に置いても、いや私もJISカナ使わないんで(^^;;;;; いくら打鍵数が減る分だけ理論最高速度は出るはずといわれても、訓練不足の分を差し引いてもなんかリズムが乗らないんですよねぇ、句読点にシフトいるのとかなんか引っかかる。まあそもそも日本語叩き続けることが実はあんまり無いんですが・・・。

Re: ポチ - reiria

2023/08/13 (Sun) 11:43:22

平仮名を高速で入力せざるを得ないゲームを大ヒットさせるしかありませんヌ(^^;;;

というわけで結局またエレコムのやつで今度は薄いほうの TK-FCM107 をポチってしまいましたが・・・
打ちにくひ(^^; 打鍵感の違いを求めてはいましたがこういうのじゃない(;_;)

今まで普通のキーを使ってると、

・キーの凹みの少なさ (ぱっと見平面だけど一応僅かに凹んでる)
・最下段のキーを親指で押す時の違和感 (側面が直角なので)

に慣れが必要ですねえ、薄くても普通のパンタグラフみたいなキーだといいんですけども。

で、もう少し何かないものかとサンワサプライ SKB-SL38 もポチってみました(^^;
まだ来てませんが、カーソルキーの縦サイズをわざわざちょっと小さくする謎のこだわり・・・ (;_;)

Re: ポチ - KAZ.K

2023/08/16 (Wed) 00:51:14

ここ数年・・・よりはもちっと前からか、多いですよねぇ、キートップの断面形状が台形じゃなくて□だったり凸だったりするやつ。しかもそういうのに限ってたいてい角の面取りも甘いので油断すると指にチクチクくるという。

今時たいていの人は最初が安物ノートの奇天烈キーボードでそれに慣れてしまうので、古来のキーボードの方がむしろ変に感じるという理屈はわからんでもないけど、それにしたって物事には限度というものガガガ・・・。

Re: ポチ - reiria

2023/08/16 (Wed) 23:56:47

やっとこ到着した SKB-SL38 を早速使ってみたところ、ばっちり PS/2 で使えませんでした(;_;)
サンワのキーボードは 2018 年末に 400-SKB057 も PS/2 で使えなかったのですが、
格安のこれならもしやと期待したものの駄目でした(^^;

で、まだ1週間も使ってない TK-FCM107 ですが、もうすでにカーソルキーの ← が時々戻って来なくなっていて、
分解してどこか削ったり潤滑剤的な何かを塗れば直るのかもですが、
キーの凹みが少ないのでキーの真ん中を押しにくく、
真ん中からずれて斜め方向から押し下げがちなことが構造的によくないような気がしなくもないヌ(^^;

Re: ポチ - KAZ.K

2023/10/25 (Wed) 09:28:22

更新して詰め直した!
<?pre>
MCB PSP Size Owner name Param/Dev Hooked Vectors
---- ---- ------- ----------------- ---------- -----------------------------
0586 0000 632688 <free> 30

MCB PSP Size Owner name Param/Dev Hooked Vectors
---- ---- ------- ----------------- ---------- -----------------------------
D001 D002 16 jackpot! 1B
D004 D005 25856 n100b N100B$
D655 0000 64 <free>
D65A D65B 6288 netbeui 5C
D7E4 D7E5 4768 redir_4 /EMS:NO /P 05 1A 28
D90F 0000 192 <free>
D91C D91D 16784 mscdex /D:CD_101 2F
DD36 DD37 10480 umbbuf
DFC6 0000 896 <free>
DFFF E000 32768 <gvram>
E800 E801 352 atok8a ATOK8A%%
E818 E819 13568 atok8b CON 29
EB69 EB6A 112 protman PROTMAN$
EB71 EB72 5184 melcdu CD_101
ECB6 ECB7 1232 isurendr /P /T /E 08 E9
ED04 ED05 1696 minses /n /q 2A
ED6F ED70 1024 buffers$ CON
EDB0 EDB1 1792 30sys149
EE21 EE22 2688 tatd_tsr 18 6F
EECA EECB 352 tips_tsr 09 0A 0B 0E 14 15 1C 21
EEE1 EF38 1360 command.com (*ev)
EF37 EF38 2640 command.com mu 22 23 24 2E
<?/pre>
今のご時世telnetする(できる)相手が電話機くらいしかなくT3Exの出番が消失しているのでdis_pktを撤去、結果netbind時点で出現するPROTMAN名義も無くなるので下位メモリが完全に真っ平らに・・・すると昔何かに不具合があったような気がしないでもないけどまあいいや (たぶん鮪ぱれっとあたり?)。なおmscdexが若干浮いているのは使うときだけ後のせする運用のせい (でないとredir_4を/rして拡張版に移行する手が使えない)。

Xv改は純SCSI環境なわりにIDE(というかPCIその他というか)BIOSを撤去したら使い物にならないのでせまっくるしい。その点内蔵IDEのままのRa改は基本どうとでもなるので略。

---

ねっと通販、というかクレカ決済というか。しばらくEMV3D認証中になった後でそのまま認証失敗: パスワード不正とかでてくる・・・いやそもそもまだパスワードの入力を求められてないんだけど。いったい何をどうしろと。決済代行業者が阿呆なのかクレカ側がスカポンタンなのか、かといってわざわざ闘うだけの元気も出ないし、とりあえず他のカードで突っ込んだら通った。容疑者不詳。だから不法増築でせきゅあ()は無理なんだって、いっぺんクレカ自体をこの世から滅ぼさないとだめだって・・・。

Re: ポチ - reiria

2023/10/25 (Wed) 17:16:36

おお~、LANMAN + FEP + MSCDEX + その他諸々全部 UMB ってことですかヌ(^^;
こんな UMB マップはもはや地球から失われたロストテクノロジーの幻影として教科書に載せましょう・・・ (^^;;;

そういえば、LANMAN 拡張版が Windows 10 で小さいファイルがコケる件は現時点でも駄目ぽい(;_;)

あと、Xa16 に入れた ML2032 が半年ほど経過しましたが普通に順調です。
カレンダが保持されているかどうか、date time をほぼ毎日 1 回実行する以外は電源スイッチオフで放置中。

以前検索した時は見つからなかった(というか今もまたヒットしないぽい?)のですが、
2016 年にヤフオクで ML2032 に交換済みと明記された 9821Cx が出品された記録がヒットしました。

なので、上のほう 2023/04/03 09:36:09 のレスで ML2032 での実列が見当たらないような・・・と書きましたが、
とっくの昔にばっちり実列あったぽいですヌ(^^;

Re: ポチ - KAZ.K

2023/10/25 (Wed) 19:02:30

LANMANなー・・・ あとはもう [workstation] の WRKHEURISTICS いじって回避できるのかどうかくらいですかねぇ・・・。

これまともに網羅的なドキュメントがたぶん残存してないのであてかんするしかないんだけど、デフォルト値はNETWKSTA.EXEを覗き見してコピペすればなんとか? なんかそれっぽい見た目のが二つあるけど、一つ目の途中に9が混じっているやつはどうもまともに動かないので二つ目のほうで。なお本当にそれが既定値に等しいかどうかは定かでありません:-)

ちなみにMSKBの残骸とかで断片的に WRKHEURISTICS に言及されている文脈で「bit」と言われているのは、実際には「0スタートの先頭から勘定した文字数」の意味なので注意。つまり「bit 14」=前から15文字目。びっととはいったい・・・。

って - KAZ.K URL

2023/10/25 (Wed) 20:10:09

長らく諦めてたのに今更それっぽいの見つけたよ!
Download options の7zに展開済のlanadmr.txtが入ってる!

追) NETWKSTAの既定値っぽいの、やはり二つ目の方でドキュメントの記述と (書いてある範囲内では) 一致しますな? むしろ一つ目の方が何者なのか。
ドキュメントが2.0相当と古いので14以降にナニカガフエテルのは今のところ謎。もちっと新しいのどっかに転がってないかぬー。同世代のworkstation/requesterであれば他社製でもそれほど差がないっぽいけど、DOS版とOS/2版は同じバージョンでもまるっきり別物なので要注意なのん。

Re: ポチ - reiria

2023/10/26 (Thu) 11:03:27

貴重な情報ありがとうございます。

lanadmr.txt ってオリジナルのファイル名なんですよねたぶん。
ありそうな名前というか文字列なのに、関連情報検索してもまさかの一つもヒットしないぽい?(^^;;;
gocgle に支配された世界の片鱗を見ましたヌ・・・ (;_;)

手持ちの 98 版 LANMAN (NT 4.0 Server 同梱) で wrkheuristics に言及してるドキュメントは、
readme.txt (disk5) の「WRKHEURISTICS の 14 桁目」ってのだけ(?)ぽいけど、
本家 LANMAN の Supplemental Disks とやらには、
https://www.betaarchive.com/wiki/index.php/Microsoft_KB_Archive/76297
みたいなドキュメントが入ってたのかヌ・・・。
これの Example configuration の wrkheuristics は lanadmr.txt の default と 6 12 が異なりますが、
このほうが速度より安定重視で汎用的みたいな何か意図あるんですかねえ。

まあともあれ、設定値いじって小さいファイルがどうなるか試すしかなさそうですな。

Re: ポチ - KAZ.K

2023/10/26 (Thu) 13:04:58

元データは謎TSR専用の謎データベースで.dbと.ttrのペアですねぇ。出自的にはQuickHelp系でも良さそうなものなのに、どうも全く関係ない別フォーマットっぽい。これ下手したら謎TSRからスクリーンショット経由で再構築した.txtなのでは。

いちおう.isoが元のCDそのままのダンプっぽいけど、ISOなのは名前だけで中身がどう見ても High Sierra (^^;;;

Re: ポチ - reiria

2023/10/26 (Thu) 16:02:16

で、早速やってみたところ、嘘みたいにあっさりと小さいファイルの転送成功するようになりました(^^;;;;;;;

とりあえず試した設定値は、

111121101221200000000000000000000 lanadmr.txt default
111121001221000000000000000000000 KB 76297 example

これら二つだけですが、いずれも転送成功するようになりました。
wrkheuristics を設定しない状態に戻すと、再び転送失敗することも確認しました。

具体的にどの値の影響なのかはまだ調べていませんが、
これはもしや、wrkheuristics 無しで何とかなってた今までが運良かっただけというオチもあるのかヌ・・・ (^^;;;

てか、wrkheuristics の設定が example として載ってるとなると、
本家 LANMAN ユーザーの皆さんは wrkheuristics を設定するのが普通だったりするんですかのう。

Re: ポチ - KAZ.K

2023/10/26 (Thu) 17:14:52

おぉお・・・? ひとまず何とかする手がかりにはなったっぽい?

LANMAN相当品ってOEM的に他社経由でも供給されていて(IBMとかDECとか)、供給元やバージョンが食い違った状態での相互接続の要求がそれなりにあり得たので、バージョン固有バグの回避とかでごそごそする必要がわりと昔からずっとあったのかなと。つまり設定値名がheuristicsなのは伊達でも洒落でもなく人力で試行錯誤しろと言う意味なのでは(@@;

Re: ポチ - reiria

2023/10/26 (Thu) 17:26:30

どうやら、netwksta.exe に埋め込まれている値の 16=2 が原因ぽいです。16=0 にすると転送成功します。

01234567890123456789012345678901234567

11112110122120002000000000000000000000 失敗
11112110122120000000000000000000000000 成功

長さを lanadmr.txt や example と同じ 33 文字にしても、

111121101221200020000000000000000 失敗
111121101221200000000000000000000 成功

となり結果は同様でした。

うむむ、16=2 は何者なんでしょうねえ(^^;

Re: ポチ - KAZ.K

2023/10/26 (Thu) 18:30:09

・・・この件に関しては動いてさえいるならどうやって動いているのかは気にしない方が幸せだと思うよ・・・? (^^;;;

ぶっちゃけ残存しているかどうかも定かでないドキュメントを探すより端からパケットダンプ見比べた方がまだしも早いまでありそうな気がしている、けど、それをしたところで・・・ねぇ・・・(^^;;;;;

Re: ポチ - reiria

2023/10/26 (Thu) 18:30:26

あと、lanman.ini で wrkheuristics を設定せず、netwksta.exe をパッチすることも試してみました。

000111AFh 32h → 30h

ここ 1 箇所パッチするだけで転送成功するようになりました。

00011C5Dh 32h → 30h

ここは影響無い(?)ようで、30h にしても転送失敗します。

なので、初期値は 0001119Fh ~ 000111D4h ("LANGROUP" という文字列の直前) にある、

111120101211210020000000000000000000000000000000000000

という 54 文字なのかもですヌ(^^;

Re: ポチ - KAZ.K

2023/10/26 (Thu) 19:32:39

うむ、何故か1個目はごく普通に見落としてたのです(ぇ
つまり2.1cの既定値は2.0のドキュメントとは微妙に違うという話になるわけだけど、まあそれくらい変わっていても不思議は無いか。むしろ最初に言っていた後の方の二組はなんじゃろなぁ、接続相手の様子次第で切り替えとかしているのかしらん? なんかこう全般的に黒魔術臭が・・・。

追)
ていうか見た目に54桁はむしろ2.0ならOS/2版の長さなんですよねぇ。2.1ではDOS版もOS/2版と共通のコードベースに移行していた・・・という線は有り得なくもないけれど、単に何となく伸ばしただけで中身は旧DOS版のままという線も捨てがたいというか、後半が0だけになるのが早すぎる気が。んむー・・・?

Re: ポチ - reiria

2023/10/26 (Thu) 21:21:39

そういえば、この 54 文字のやつが実際に使われてる値だとすると、左端を 1 桁目と表現するなら、
readme.txt (disk5) の「14 桁目を 1 から 0」って表現とも辻褄が合う気もしますな。

readme.txt (disk5) の文章は lanman.ini に wrkheuristics の設定があること前提みたいな雰囲気なので、
どこかの lanman.ini には 14 桁目に 1 と実際書かれていたんでしょうねえ。

というか、NT 4.0 Server 同梱版がそのへんいい加減な状態での寄せ集めなのかもな予感・・・ (^^;

Re: ポチ - reiria

2023/10/26 (Thu) 22:35:24

よくわからないことをよくわからないまま書いてしまいましたが、
lmrsetup.exe (disk5) にも wrkheuristics の値らしきものが埋め込まれているぽくて、
readme.txt (disk5) が言うところの lanman.ini の wrkheuristics というのは何か別物やも知れませヌ(^^;;;

Re: ポチ - KAZ.K

2023/10/26 (Thu) 23:04:52

版によっては最初からデフォルト値のwrkheuristicsを.iniに書いておいてくれるインストーラもあったらしい? でもOS/2方面か?

そもそもLANMANに最盛期というものがあったとしてもWin3.1(というかWfWというか)より前の話ですからねぇ。確かこの時点で既に386enh側での再実装に切り替わっていてもうLANMANを名乗ってなかった筈 (逆にWin95~MEでの実装はほぼWfWのまま)。つまりOS/2がMS的にポイになった時点で実装としてのLANMANの系譜はまるっきりお荷物に成り果てていたのでは・・・。

もっともそうはいっても、外形的には現行のWindowsにすらそのまま残っている net.exe の原型は何をどう言い繕ってもLANMANにあるわけで、その意味ではOS/2の発展的解消()から始まったNT系列の中核として名前を捨て実装を捨てて残り香だけになって尚存外にしぶとく生き延びている。なんせ sc.exe の方が後付けだからね!

Re: ポチ - reiria

2023/10/28 (Sat) 10:40:17

とりあえず、ここまでの現状をまとめておくと、

・LANMAN → Windows 10 の転送で lanman.ini sizworkbuf の値以下のファイルがサイズ 0 になってしまうぽい。
・常にぴったり sizworkbuf の値以下ではなく値によっては若干ずれるぽい。
・Windows 10 → LANMAN の転送は正常ぽい。
・LANMAN 拡張版の問題で、基本版は大丈夫ぽい。
・wrkheuristics 16=2 (たぶん既定値) が影響してるぽい。16=0 にすると正常に転送されるぽい。
・wrkheuristics 16=2 の意味は不明。16=0 にして大丈夫なのかも不明。
・lanman.ini に wrkheuristics を設定しない場合、netwksta.exe の 0001119Fh ~ 000111D4h になるぽい。
・16=2 の位置 000111AFh を 32h → 30h にパッチすると正常に転送されるぽい。
・98 版 LANMAN (NT 4.0 Server 同梱) 以外は不明。

という感じでしょうかヌ(^^;

Re: ポチ - KAZ.K

2023/10/28 (Sat) 14:41:43

> 16=0 にして大丈夫なのかも不明

=0の側にも別の地雷が埋まっているかどうかはともかく、少なくとも=2の側には確定で地雷が埋まっていてそれは避けられたのだから、それはそれでもうよしとすべきだと思うんですよ(-_-;

どだいこの世代のLANMANなんてはなからまともに規格化もされていない代物なので、下手したらどっち側のバグなのかすら明らかではない線が普通にあり得る。後から制定されたSMB1としてプロトコルを解釈するならどちら側の挙動が間違いなのかは言えそうだけど、それが当時のLANMANの期待と等しいかどうかは別問題ですし。ひとまず現時点で断言できることは「この組み合わせは協調性に欠く」という程度で(--;;;


編追) 過誤修正、なんか読みにくいなあと書き直しているうちになぜか逆になっていた(^^; というわけで、むしろ生のNetBIOSのEthernetフレームだけは IEEE802.2 LLC2 として規格化されている。ただしこれは NetBEUI Frame protocol (NBF) の全体では無く、強いて言えばTCP/IPから/IP部分がどっか行った根無しTCPみたいな代物 (MAC直打ちでの疎通のみ)。NBF全体の規格は無い。NetBIOS over TCP/IP (NBT) はまた別。いずれにせよここまでは汎用の(いわゆる)トランスポート層的な部分で、ファイル共有プロトコル部分(=いわゆるSMB)はその内側。
事のついでに書いておくとCIFSはSMBの改訂版ではなく、NT3の時点で既に世に放たれていたいわゆるNTLMプロトコルの「文章化」がCIFSである。中身に変更は無いしNTLMと違うCIFSも実在しない(記述漏れの類は別として)。よってそれこそLANMAN以前の過去の遺物と化した部分もCIFSにはばっちり含まれており、NTLMの上澄みがCIFSだなんて主張はまるっきり幻想である。仮にCIFS時点での最新の定義だけを実装した“純粋CIFS”を作ったとしても、それで接続できる相手はこの世に実在しないので役に立たない・・・将来的にはできたらいいね? と、CIFS spec 自体に書いてある:-)。なお現実の将来はSMB(1)自体がポイになってSMB2/3への切り替えとなったので、その意味でも純粋CIFSは実在しない。
ややこしいことに、Win2kの時にはNTLMを含むSMB全体の正式名称がCIFSで、何かが新しくてすごい偉いという(実質的に虚偽の)主張がされ・・・たものの、後にほぼ撤回されてSMB2以降に対してのSMB1(通称CIFS)みたいな空気になった。マーケティング上の都合である。

Re: ポチ - reiria

2023/10/28 (Sat) 19:31:40

lanman.ini wrkheuristics 16 の設定値で 0 2 以外も試してみたところ、

0 転送成功
1 転送失敗
2 転送失敗
3 ~ 9 エラーが表示されて使えない
X or x netwksta.exe 内の最後の組と置換されるぽい
その他 エラーが表示されて使えない (全ての文字を確認したわけではないけれど)

という感じでした。

X は lanadmr.txt default 的な値に戻したい箇所に指定する感じなのかもですヌ。
なので、16=X の場合、netwksta.exe 内の最後の組の 16 を 32h → 30h にパッチしとかないと転送失敗します。

> 後の方の二組はなんじゃろ

11=9 の組は何者なんでしょうねえ(^^;

Re: ポチ - KAZ.K

2023/10/28 (Sat) 19:46:16

あー。言われてみれば他の桁を x で埋めている作例は確かに見た覚えがありますなー。・・・ドキュメントには書いてないよな? 記述漏れ的な隠し機能なのか2.1の新機能だったのか。

Re: ポチ - reiria

2023/10/28 (Sat) 21:15:58

> 11=9 の組

これ各桁の有効範囲の最大値ぽいですな。lanadmr.txt の記述と一致しています。
この文字列は設定値チェックに使ってるだけかもですな。で、最大値を超えるとエラーが表示されると。

Re: ポチ - KAZ.K

2023/10/28 (Sat) 22:27:47

あーなるほど? その発想は無かったな?
・・・でもそれって、全部に合法的な最大値を突っ込んだだけでなんだか普通に暴走したってことに、なるん、だけど・・・。実は設定できてもせいぜいで既定値近辺しか動作テストされて無いのでは?? (^^;;;;;;;;;;;;

Re: ポチ - reiria

2023/10/29 (Sun) 11:35:13

今更どうでもいいかもですが、2023/10/26 17:26:30 のレスでわざわざ 38 桁の設定値を書いたけど、
何でこんな妙ちくりんな桁数を書いたのか全く思い出せません・・・ (^^;;;

手元に当時のメモが残っていまして、
ちゃんと桁数を明示して 33 38 42 54 桁という 4 種類の設定値が書いてあります・・・ 38 42 って何これ?(^^;
メモを残してもメモの意味がわからない、たった数日前なのに・・・ これはいよいよやばいですヌ(;_;)/~

Re: ポチ - KAZ.K

2023/10/29 (Sun) 13:48:52

まあそれ言ったらなんでわざわざreservedにして余剰桁を確保していたのかも意味わかんないですが。将来にわたって桁数を変えたくなかったと言えばそれっぽ、いだけで現に2.0DOS→2.1DOSでたぶん増えているし。

指定の桁数が足りていない場合の残り部分は既定値ですかね? それともx扱い? いや手元では明確に挙動が分かれて確実に判別できるポイントがいまいち特定できていませんで・・・。

追) 3=2とあと何かが組み合わさるとどこかで即死するっぽい? デフォに3=2だけ入れても死なないし、逆に全部最大値から3だけ1に戻しても死なない・・・たぶん・・・んがー・・・? 死ぬのも微妙に再現性があるような無いようなで実験しにくいんだよ??

Re: ポチ - reiria

2023/10/29 (Sun) 18:55:10

> 指定の桁数が足りていない場合の残り部分

16 桁しか書かない(17 桁目の 16=? を書かない)場合、転送結果がどうなるか試してみたところ、
16=? は既定値(netwksta.exe 内の最初の組)になってるぽいですな。

Re: ポチ - KAZ.K

2023/10/29 (Sun) 19:31:48

おー。そうなると雰囲気としてはxの方が後付っぽい感じですねぇ。単に桁をスキップして本物の既定値のままでも良かったはずですし。そもそも実動作の既定値と文書上で既定値を名乗っているナニカが別というのがもうなんのこっちゃという話なんですが。

いえMS的にはむしろ逆で、たぶんxを指定しないと出現しない方がMSが言うところの真の既定値で、ただし実際に出荷されている製品はOEMによって無指定時の動作がカスタマイズされている場合があります、みたいな言い方をしていたんじゃないかと。想像は付くんですよ? うん、「無指定時の動作」は「既定値」とは別物なん、だよ。という、・・・既定値、既定、default とはいったい・・・、。原義に立ち返って債務不履行・・・! ・・・いやでもここでいう債務=値の入力なんだから、それならやっぱり入力不在のことで、普通にそれが無指定時の動作というものなのでは・・・?? あれ???

これマルチベンダ版2.1cのARが万が一にも書かれていたならなんて言い訳していたんですかねぇ。あ、いや、だからx自体がundoc? ・・・えぇ・・・。

Re: ポチ - reiria

2023/10/29 (Sun) 21:22:44

lanadmr.txt default 的な既定値ははっきりマニュアルに記載しつつ、
カスタマイズ既定値(?)は netwksta.exe 埋め込みじゃなくて lanman.ini に、

xxxxx0xxxx1xx1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

みたいにインストーラが書いてくれれば、もうちょいわかりやすそうなんですけどもねえ(^^;
現状は netwksta.exe を覗くしかないという難易度・・・ (;_;)

Re: ポチ - reiria

2023/12/13 (Wed) 12:53:30

RvII26 の軍事機密の件ですが、Rv20 では今のところ全く再現しないようです。
Rv20 の CPU とチップセットいずれも RvII26 と異なりますが、やはりチップセットが原因ですかねえ・・・。

> 内蔵 SCSI が大丈夫なのは・・・どうなんでしょうねえ。
> 今までにあった謎の SCSI ハングのいくらかは xchg がらみだったかも知れませんな。

あとこれ、マジかも知れませヌ(^^;;;

2021 年に RvII26 環境から xchg を駆逐(たぶん)した後、嘘みたいに謎のハングは一度もなくなった気がします。

以前は謎のハングの後、たまに一部のファイルが壊れていることがあって、
SCSI HDD 読み書きのタイミングでハングしていたことはほぼ間違いないと思われるものの、
再現頻度がかなり低く、数ヶ月に 1 回あるかないかくらいで、どうにもこうにも原因不明な感じでしたが、
xchg を駆逐してから 2 年以上、そのようなハングは一度もなくなった気がします。

なので、

> xchg しまくりながら scandisk クラスタスキャンや dskbench 実行しても特に問題無い感じです。

以前このように書きましたが、もっと長時間やりまくれば再現する可能性あるかも知れません。
が、見事再現した時に HDD がどうなっているのか怖くて躊躇しております(^^;

Re: ポチ - KAZ.K

2023/12/14 (Thu) 00:09:18

あー・・・でもまあWSSでの結果を踏まえれば、所定のタイミングさえ踏み抜けば読み書きはどちら向きでも再現しそうに思えるので、HDDに書かないように再現を試みる分にはそこまでの危険はないのではたぶん? いえもちろん保証の限りではありませんが:-)

原因が以前の想像(転送をバースト化するためのマージ処理とLOCK#がかぶると死ぬ)通りであるなら、
- DMA要求の間隔は詰まってないと再現しない (さもなくばWSSの1byte/sampleのように通ってしまう)
- DMA要求一つずつの所要時間はたぶん長い方が再現しやすい (Cbus経由とPCI直の差がたぶんここ)
- PCIバス自体の総稼働率が高い方が再現するのか低い方が再現するのかは不明。関係ない他の要求が有れば事故らないという可能性もある。
ってことだと思うけれど、問題はこれSCSIの同期転送だとペースが安定しすぎで何かしゃっくりでも無いと再現閾値を超えないのでは。SCCTLのバッファ転送テスト(だっけ?)的なのでメディア転送なしでバス負荷だけ目一杯かけつつ、一旦何らかの手段でPCIを詰まらせてHBA側のバッファに溜まるように仕向けて、十分に溜めたところでxchg連打に切り替える・・・とかですかねぇ。

そういえばxchgのアラインをわざと外してsplit lockにしたら症状は悪化する? それとも再現しなくなる? どっちも有り得る。いやそもそもここでいうアラインはPCI側のdwordアラインなのかキャッシュラインのアラインなのか、どっちだ・・・?

(追) あとHBAの Latency Timer を短縮しないと再現しないかも? 少なくともCbusブリッジにバーストは無い。

Re: ポチ - reiria

2023/12/15 (Fri) 01:24:47

とりあえず、RvII26 内蔵 SCSI の設定を同期と非同期の場合それぞれ、

mov ebx, 0A0000h
.repeat
xor eax, eax
xchg [ ebx ], eax
xchg [ ebx ], eax
inc ebx
.until (ebx > 0A2000h - 4)

こんな感じのコードを 2nd CPU でぶん回しながら内蔵 SCSI HDD に scandisk クラスタスキャンしてみましたが、
今のところハングしませんヌ・・・ HDD はまだ無事です(^^;

FDD と WSS も改めて確認してみましたが、以前同様、ほぼ確実にハング(+ FD データ破壊)ですな。

Re: ポチ - KAZ.K

2023/12/15 (Fri) 15:47:08

98の如き色物()を抜きにしても、いちおう特定の方面ではそれなりに実稼働で使われていたはずの石なので、そうお気軽にどこでも再現するような事態ならもすこし知られていそうな気はするんですよねぇ。たぶんデバイスの応答速度が特定のクロック数以上に遅くない限りはそんなに発生しないとか、なんかそういう系の条件があるんじゃないかと・・・、まあ想像を逞しくしたところで真相は藪の中なんですが:(

PCIを詰めるには何したらいいんだろうな。45FをFFにのばして out 5F 連打? でも実際にはだんまりでバスを握りっぱなしにできるわけではなくて一旦Retryになっているはずで、そこで正しく Delayed Transaction 扱いされてしまうとバス自体はたいして埋まらない。DTするか単に bus lock して待つかはホストバスブリッジの自由だけど、はて初代ちゃんぴょんはどうだったか...?

Re: ポチ - reiria

2023/12/16 (Sat) 22:59:00

とりあえずただ単に 045Fh を FFh や 00h (RvII26 起動時 6Fh) にしてみましたが、特に変化なさそうですのう。
Rv20 は起動時 6Dh だったので、RvII26 と同じ 6Fh にしてみましたが、特に変化なく。

あと、TVRAM を WC や WT にしてみましたが、特に変化なく、
それと逆に普通のメモリを UC にして xchg しまくってみましたが、これはさすがにハングしないようで(^^;

POWER MCB - reiria

2023/12/17 (Sun) 10:34:14

DOS 付属 POWER.exe を DEVICE= で組み込んだ場合、POWER.exe が UMB 自力常駐部を作るようですが、
その UMB 自力常駐部に SD と 'D' の MCB が自力で作られることに気付きました。

これはもしや config.sys 内の状況に合わせた特殊なメモリ確保ファンクションがあるのかと調べてみましたが、
普通のメモリ確保ファンクションで確保して、POWER.exe が自力で書き換えているだけのようです。

で、その UMB 自力常駐部は 'D' なのにデバイスチェーンに含まれないブロックになりまして、
これを何かおかしいと判断してしまって fmap と A4.com の表示が途切れてしまいます。

A:\>fmap u #
A:\>A4 u debug

みたいに実行するとデバッグ情報が表示され、エラーを確認出来ます。いずれも次版で修正したいです。

いやしかし長らく DOS を使ってきてこんな MCB が実在することを今頃知ったのですが、
デバイスチェーンに含まれない 'D' なブロックを作るのって POWER.exe の他にもあるんですかいヌ?(^^;
DOS 付属品がやっているとなると他にごろごろあっても不思議ではないですが・・・ (^^;;;

ただこれ、結果的に MCB を一つ無駄に作ってる気もしなくもないですが、それなりの意図があるんですかねえ。
メモリマップ表示で UMB 自力常駐部もデバイスに分類出来るとか? (DOS 付属 mem /d や mem /m:power も)

Re: ポチ - reiria

2023/12/19 (Tue) 22:26:38

RvII26 の xchg と WSS のハングについて、wp.asm を改めて確認してみました。

1) wp.com 実行開始 → ここから 3) までの間は xchg してもハングしない
2) DMA プログラム
3) WSS 0F44h に 20h を out ← ;MCE off のところ
4) ここから 6) までの間で xchg するとハングするタイミングがある
5) DMA 割り込み待機 (待機中に再生データをディスク読み込み → 旧 Jack LAMD アクセスランプ xchg)
6) DMA 割り込みハンドラに移行 → ここから 8) までの間は xchg してもハングしない
7) DMA プログラム
8) WSS 0F46h に out ← ;FIFO割り込みフラグリセット のところ
9) 4) にループ

という感じのようです。

xchg は 10 回くらい連続実行するとほぼ確実に即死ぽいですヌ(^^;

Re: ポチ - KAZ.K

2023/12/20 (Wed) 09:12:51

うん、まあ、出るDMAREQが無いタイミングは大丈夫というだけの話で、それはそうよね。むしろ今更そうでない別件だったらその方がびっくりするわ。

そういえばしばらく前にちょろっと出た接続デバイスなしにDMAREQを出させる方法の話、純正8237的にはコマンドでトリガ入力の判定極性を反転してしまえば動きっぱなしだぜぇヒャッハーという手はあったらしい? でもどこかに混載された8237相当機能で同じ手が使えるのかどうかはまだ試してないですん。

Re: ポチ - reiria

2023/12/20 (Wed) 10:30:46

8237 といえば 82557 の活動を止めるプログラムという認識でOKでありましょうか(^^; > TieEEP

LANMAN 使ってる最中に高速再起動すると USB I/F 等と同様にあかん状態になってる(たぶん)気がしまして、
いちいちリセットしているのですが、TieEEP 実行すれば大丈夫でありましょうか。

実行時に 82557 の活動有無的なのを表示していただけると安心出来まする。

以前、例の Crywnr のパケットドライバのソース眺めて何とかしてみようかと思ったこともあるのですが、
やはりその手のプロにお任せしようかと・・・ (^^;;;

Re: ポチ - KAZ.K

2023/12/20 (Wed) 12:44:46

はい、基本機能はソレで合っています。ただし注意点があって、そもそも高速再起動前の側でドライバをUMBに上げていない場合、位置によっては何をする間もなくDOS自体をぶち壊す目が残るので、予めUMB経由で1MBより上に追い出しておくことが肝要です。厳密に「再起動前の側でドライバがUMBに上がっていること」「再起動後の側でメモリマネージャより先にTieEEPすること」の両方を満たさないと大丈夫になりません。うん、本気でUMBに上げた方がまだしも安全なんだよ。

で安心の件ですが、これねぇ、事前知識なしを前提にするとどう考えても活動しているかどうかを判別しに行く方が危ないんですよ、困ったことに。なので「intelがNICを名乗っている→I/Oベースが開いている→問答無用でリセット」という風にしていまして。さすがにI/Oベースが開いていないままで稼働中というケースは悪意を持って罠を仕掛けたのでない限りは有り得ないはずなので、実用上はこれくらいで問題ないかなと。

まあそういうわけで、いちおう大丈夫は大丈夫なのだけど、大丈夫になる前提条件がちょっとややこしいんですよねぇ。そういう意味でTiBP+TIreとかより質が悪い。本来的にはやはり高速再起動ツール自体に埋め込まないとダメなんじゃないかとー。

Re: ポチ - reiria

2023/12/20 (Wed) 14:40:18

ぬー、やはりそこそこそあかん状態だったわけですな(^^;

たまに LANMAN 使用中なの忘れて無意識に高速再起動しちゃって、再起動後に謎の [Y/N] とかあったりしまして、
でも再起動前のことはもう忘れてる(ぉぃ)ので・・・ あれ?おかしいな?まいっかー、みたいな(^^;;;

とりあえずおまじないで実行しておきますヌ(;_;)/

Re: ポチ - KAZ.K

2024/02/18 (Sun) 07:36:49

今度は無事に飛んだようでなによりですな。
これでひとまず使える状態にはなったはず、といってもまあメインエンジンがまだ仕上がってないわけですが。

もっともそれをいうと0SRB形態なんて実際に使うことあるのか? という疑問はあるんだけど。H2の頃も細い方のサイドモーターとか設定したものの結局まるで使わなかったやつありませんでしたっけ...?

Re: ポチ - reiria

2024/02/18 (Sun) 12:31:45

いやあほんと良かったですな(;_;)

SRB 無しの打上げは一度見てみたいですねえ。SRB の派手な発光ともくもくが無いとどんな感じになるのか。
細いやつは空中点火がロマンというか、今ならネット中継でコメント盛り上がる瞬間かも(^^;

Re: ポチ - KAZ.K

2024/02/18 (Sun) 19:18:45

液酸液水エンジンだけで離床っていうとぱっと思い付くのはデルタIV系(のブースター無し形態)とかですけど、あれ不思議と水素炎とは思えない赤い炎吐くんですよね。ノズルが蒸発冷却なのでそっちの炎色ですかねぇ。

Re: ポチ - reiria

2024/02/18 (Sun) 23:12:36

そんなこんなでデルタIV蛇ぃの動画巡りしていましたがロケット本体焦げまくりで派手ですなあ。
ってこれは派手とかそういう問題じゃないような気もしますが・・・ (^^;;;
H3 も月計画用に 3 本束ねる構想はあるようですが実現しますかねえ。

H3 の計画見たらもしや次の 3 号機が SRB 無しかも? 当初の計画では今回の 2 号機がそれだったらしく(^^;

Re: ポチ - KAZ.K

2024/02/19 (Mon) 10:23:09

そもそもはカタログ上の最小構成価格を下げる話から始まっているわけだけど、幅広い需要に対応というのは先に需要があっての話であって、架空の幅広い需要を夢想して進める話ではないというか。実際問題、打ち上げ余力なんて有ればあるだけ食いつぶして衛星の設計が大型化するだけな気もするんですよねぇ。技術革新によって軽くても実用“的”なのができるようになった・・・ような気がしたのは技術実証段階では確かにそうなんだけど実用衛星としてはたぶん気のせいで、結局は主に電力需要の増大で食いつぶし直している。いわゆる小型ロケット類 (空中発射系含む) が商業的に思ったほど成立してないのも結局はそこですし (残り半分は相乗り山盛り方式に負けている分)。

3本束は・・・機体設計がどうとか以前の問題でまず射点整備が無理ゲなのでは。H3時点でも既にだいぶ無理した感があるのに・・・。少なくともMLはまた新造になるだろうし、かといって作ったところで車庫が足りない罠再び(^^;;;;;。第2射点自体はH2初期の3本束机上計画に対応しているつもりだったという話だけどどうなんですかねぇ。

Re: ポチ - reiria

2024/02/19 (Mon) 17:57:06

射場といえば再使用型研究の CALLISTO も今年ギアナで打上げ予定みたいですがどうなりますかねえ。
このカリオストロ城って 13.5m だとちょうどイプシロンの半分くらいの大きさですかヌ。
NVS の中継は行くんだろか・・・ 以前一度ギアナ行ってたはず(^^;

日本でやるにはさすがに今の種子島の射場じゃ危なくて駄目そうだけど、ちょうど隣に使えそうな馬毛島基地が(^^;

Re: ポチ - KAZ.K

2024/02/19 (Mon) 19:40:43

研究段階はともかく実用化となるとなぁ・・・再使用型の最大の問題って、いくら再使用できるように作ったところで、実際にすぐに再使用する見込みが立たなければ贅肉にしかならない点だと思うんですよ。次いつ使えるか解らない中古機体の倉庫だなんて悪夢でしかない。実際F9が回っているのも自前(?)でStarlinkという最大顧客を抱えているのが突っ込みどころなわけで、普通なら需要と供給の鶏卵になるところを自前資金で両方えいやっと用意してしまったところをこそさすがと言うべきなのかなと。生中な公的開発でそうはいかんですよ・・・。

エンジンブロックだけ回収とかいうわりとセコい()案してたのはどこでしたっけ。Vulkanか。最適化問題と一言で括ってしまえばまあそうなんだけど、どんなもんですかねぇ。

名前
件名
メッセージ
画像
メールアドレス
URL
編集/削除キー (半角英数字のみで4~8文字)
プレビューする (投稿前に、内容をプレビューして確認できます)

Copyright © 1999- FC2, inc All Rights Reserved.