Re: Mirage v0.49a emu - reiria

2016/01/17 (Sun) 13:25:01

■通常版と何が違うの？

・常駐サイズが 16 bytes 多い。(64 + 16 = 80 bytes)

・るなえみゅパッチ第Ⅹ版相当のコード変更。
(常駐コード本体には変更なく、速度は通常版と同じはずです)

・リセットベクタテーブルのアドレスが決め打ち。

・割り込みの BIOS-ROM の入口のアドレスが決め打ち。

※オプション traceint を指定すると、通常版同様に BIOS-ROM の入口を探しますが、
一部のエミュレータでうまく動かないため、おすすめ出来ません。
(シングルステップ実行の挙動が実機と何か違うぽい)

実機で実行すると、通常版同様にデフォルトで traceint になります。

これは Mirage.exe 組み込み時に必要な処理で、組み込み後は関係ありません。

Re: Mirage v0.49a emu - reiria

2016/01/17 (Sun) 17:52:59

以前、Mirage v0.43a が T98NEXT20100518 版頃からなぜか動いていたのですが、
Mirage v0.48a 以降はなぜかハングしていました。

Mirage v0.43a に対しては、T98-Next 側で v0.43a に限定的な対策して下さっていたのか、
それとも単に何か運よく偶然で動いただけなのか、よくわかっていません。

Mirage 側でエミュ対策したのは今回の v0.49a emu が初めてで、
どうやら、Mirage v0.48a で追加した max の処理を消せばハングしないことまではわかったのですが、
それがなぜなのか、未だにわかっていません。

Re: Mirage v0.49a emu - ニボシ好き

2016/01/20 (Wed) 10:52:36

更新？公開？作成？変更？
お疲れ様です。m(._.)m　上の言葉のどれが当てはまるでしょう。

とりあえず動かしてみました。ずっとエミュで動けば面白そうだな～って、
思っていたので大感激です。(私の為に作られた訳じゃないですけど)
ありがたく使わせて頂きます。（^人^）

それでは失礼します。(@^^)/~~~

Re: Mirage v0.49a emu - reiria

2016/01/20 (Wed) 11:50:30

おお、何とか動いたようでよかったです。＼(^^)／

A5,A6,A7 は UMB にされていないようですが、そこに BIOS-ROM を移動してたりするのかな。
通常、Mirage 環境では BIOS-ROM を移動しないほうが UMB を広く取れます。

ともあれ、Mirage はエミュ環境でも無駄に重くなりますし、
もともと UMB を広く取れるエミュ環境でメリットあるんかいなという根本的な謎が(^^;

Re: Mirage v0.49a emu - reiria

2016/01/20 (Wed) 11:52:12

lemm_emu.exe の readme.txt と、それを貼り付けた公開ページに Anex98 と書いてあって、
更にそれを使い回した Mirage v0.49a emu にも Anex98 と書いてありました(^^;;;
lemm_emu.exe 初版 2006-11-23 から今まで 10 年近くもずっと気づきませんで大変失礼しました。
readme.txt を訂正してアーカイブを差し替えました。
実行バイナリ内のメッセージは初版から正しく Anex86 になっています。

タトなうえに没 - KAZ.K

2016/01/27 (Wed) 20:49:58

一瞬、X-B02で全SCSI化した環境だったら、4ページ使っているとはいえバンクは無いのが特徴なのだから、IDE跡地にSCSI BIOSを上書き移転してやれば、IDE裏のPCI BIOSその他を見かけ上の専有面積なしに活かせるんじゃないか？
・・・と、思いついてみたのだけど。とりあえずTiBPのソースをコピーしたあたりでやっぱりダメなことに気がついた。

いやたぶん動くには動くだろうけれど、IDEはBIOS自体はUCで動いているわけで、だからrep ins/outsだけシステム共通域でやっているわけで、故にバンク切り替え時にWBINVDは必要ないので当然していない。一方X-B02の方はBIOS全体をC有効にすることで速度を稼ぐ方針なわけで、それをそのまま引き継いで引っ越し先のIDE領域でC有効にしたらPCIその他があばば一直線だし、かといってUCのままだと微妙に遅くなる予感。

SCSI裏はいけてないにせよ、むしろGLIO裏あたりに出せばいいのではと思ったあたりでだんだん面倒になった。そもそもやったところでIDE裏の3ページ占有が消えるだけなので空くのはA5-A7の飛び地だけだし、デメリットあっていいなら最初から素直にMirageすればいい話なのでやっぱり没。むー。

Re: タトなうえに没 - reiria

2016/01/28 (Thu) 13:39:58

むむ、X-B02 は持ってないでござる(^^; その前後の 01 と 03 はかなり収集したのですが(^^;;;
RvII26 内蔵 SCSI は 4 ページだし、02 と似たようなものかも知れず。

Re: タトなうえに没 - KAZ.K

2016/01/28 (Thu) 15:30:10

NEC純正のPCI SCSIは全部例外なく2940相当の石で、当然RvIIも同じです。Xt（だっけ？）あたりもそのはず。Etherがどれもこれも82557なのと似たような感じ。

実のところDOSだけなら腐れIDEのままでいいんじゃとは思うのだけど、残念ながらPATAで生きているCDROMの余りがもう無い罠。うーん。その昔に捏造した偽UIDE-66（廃棄品の66からBIOSをアレして133Lに上書したやつ）も出番を無くして箱の底。

Re: タトなうえに没 - reiria

2016/01/28 (Thu) 19:48:27

ふむふむ、そういえば今まで長らく 98 使ってきたのに PCI SCSI はあまりゲットしてないなあ。
内蔵以外で今持ってるのは SC-PCI と LHA-521UA の2枚だけという寂しい有様で(;_;)

Re: Mirage v0.49a emu - reiria

2016/01/31 (Sun) 23:19:14

> 以前、Mirage v0.43a が T98NEXT20100518 版頃からなぜか動いていたのですが、
> Mirage v0.48a 以降はなぜかハングしていました。

ようやく原因箇所を特定出来ました。
v0.49a emu 版を作ってしまったので今更感もありますが、
通常版をなぜか T98NEXT20100518 版頃から動くように出来ると思います。
もう少し動作テストしてからアップします。

Re: Mirage v0.49a emu - reiria

2016/02/01 (Mon) 01:02:29

> Mirage v0.43a に対しては、T98-Next 側で v0.43a に限定的な対策して下さっていたのか、
> それとも単に何か運よく偶然で動いただけなのか、よくわかっていません。

動作テストの結果、単に何か運よく偶然説が鰻上り中(^^;
Mirage より先に何かの常駐物が BIOS をフックしてたりすると確実に暴走します。
これならハングのほうが比較的安全に思えます。

前レスで通常版を動くように出来ると言い切ってしまったけれど、
v0.43a 同等の偶然方式ではなく、v0.49a emu 方式にしようと思います。

調子にのってさらにタトる - KAZ.K

2016/02/01 (Mon) 01:08:25

著者がUndoc2と同系の本にはout5Fのウェイトは何が根拠か最低0.6usと書いてあるけれど、うちの実機では45FのITF規定値は6Fであって、LSBのデコードフラグを除いて設定値55をPCIの33MHzで割ると1.67usに見える。実際out5Fのみ連続の所要時間をARTICで測ると1.75us弱で、PCI57クロック程度とまずまず一致する。

一方ウェイトが足りないとすぐコケる代表格のOPNに対して、5Fが2つだと不足気味、3つならだいたい大丈夫という経験則からすると、out-2×out5F-out＜4.25us＜out-3×out5F-outであって、out自体の所要時間を無とすれば2.1us＞1×5F＞1.4us、とてもじゃないけど0.6usにはほど遠い。まさかこれ1.6usの誤植なんじゃないか？ と思い付いてスパテク本文を全部見直してみたところ・・・キーボード編で37usの要求に18h×out5Fしてるじゃないですか。オイ。本当に1.6usの誤植だったのかよ！！

もっともその割にはパラレル編ではわざわざ一つ0.6usとコメント付きで1usの要求に対して2×out5Fをおいているあたり、この誤植がかなり初期に紛れ込んだもので著者グループ内部でも既に誤植に踊らされた人が出ていたのではないかという気もする。実際、特にウェイト回路になっているわけではないVXあたりでは1.2us程度だったはずで、もし誤植なく1.6usと書いていればさすがに目の前での説明文の矛盾にアルェ？ となっただろうし。（1.2usしかないVXでもOPN相手に3個で平気なのはout自身や他の命令の所要時間の分であろう）

ただし実際のout5Fの動作にはさらに全く別の問題があって、たとえばうちの実機で45Fの設定値が十分に大きい場合、out5F-in60-out5Fの所要時間とout5F-out5Fの所要時間が完全に同じになるのに対して、out5F-in08-out5Fは絶対に同じにはならない。ここから素直に推測すれば、少なくともPCI機ではout5Fは本当にFSBをストールさせる訳ではなくCバスブリッジから先をストールさせる効力しか無いことになる。つまりout5Fを単体で1つだけおいた場合には45Fの設定値には一切関係なくブリッジ宛のout1回分の時間しかとらないので、Cバスブリッジの下ではないデバイスへのウェイトとしては単発のout5Fは微妙に役立たずである。一方out5Fに後続するCバス宛(out5F自身を含む)には45Fの設定値がきくので、要はout5Fは2回連続で発行して初めてその間隔が保証される。

もっとも45Fの設定がどうであろうと、Cバス(ブリッジ)宛のoutはそれ自体がかなり遅く、Xv改で0.48us、Ra改に至っては0.75usも食っているようなので、実際にこの仕様が問題になることはまず無いのであろう。てかまあ主要な内蔵デバイスは自力でストールして待たせるようになっているので、そもそもリカバリタイム全無視でもまず問題ないんですが。ぷるぷる。

いやまあ余計なウェイト削ったらちっとは速くならないかなーという程度のせこい話でした。ええ。どうせわかっている人は言われずともわかっていた程度のことなんだろうけど。・・・てかなんでRa改がXv改より大幅に遅いんだ？ どっちも全く同じ STAR ALPHA2 だし、いくら440FXがどうあがいても430HXより遅いとはいえそこまでの差は無いはずじゃ・・・。

（追記）
・・・書いたら思い出した。妙に遅いのの一部はLEMMのせいだった（笑）　けどreal同士で比べてもやっぱりRa改の方が遅い（0.42us vs 0.65us）。なんだろなーこれ。

（追記２）
別解としては18hという回数が先にあって時間の方が後付だったという可能性もある。そもそもTDBには37usという数字はなくて15usで、18h×0.6usなら14.4usと概ねそれっぽい。ただしTDBは何故かステータスリードを始める前にも15us入れろと書いている。意図不明。コマンド受信直後にゴミが出るとかいうような話でもないし。

Re: Mirage v0.49a emu - reiria

2016/02/01 (Mon) 01:31:12

うむ、これは縦読みに違いない(^^;;;