FMTowns新エミュレータ Tsugaruの情報交換用スレッドです。
Tsugaru : http://www.ysflight.com/FM/towns/Tsugaru/j.html

2020-07-28 12:41:40

なんとFM77AVのスペースハリアーの爆発音は、SSG_EGをLFOのように使ってるんですね。エンベロープは今までミリセカンドのオーダーで計算していたのですが、スペースハリアーだとせいぜい数ミリの周期になっていて、1/32ミリセカンドにしたら、今度はリリースが変になって、半日ぐらい調べたらエンベロープからdBを計算するところでオーバーフローが発生してて、直したら良くなったようです。スペースハリアーみたいなSSG_EGの使い方をされた場合と普通に音を出す場合だと1000倍も時間に差が出るのでは、スペースハリアーに合わせたらオーバーフローもしますよね。

それから、せっかくBCCさんにCONNECTIONごとのYM2612の出力を調整していただいたのですが、これだとSuper大戦略、Emerald Dragonその他のBGMがどうしても違うもので、CONNECTIONごとに出力を調整するのはRevertさせていただいて、どのCONNECTIONも無調整(?)にしました。多分、FMとPCMのバランスが合ってないんだと思うんですよね。実機があるんだから、時間をかけて調整すればいいんですけどね。

2022-08-31 09:34:11

> WINDYさん、

ありがとうございます！陰影処理が再現できてませんでしたか。シルフィードはテストしてたんですが気が付きませんでした。YM2612はSSGは無かったのにSSG_EGだけ残ってたんですよね。しかし、SSG_EGを使ったからと言ってエンベロープ作るのが簡単になるかというとそんなこともなかったようなので、多分使う意味が無かったのかもしれないですね。一応、SSG_EGは津軽でも有効になりました。YMで残ってるのは効果音モードと音声モードですね。PCM積んでるTOWNSでは音声モード使う意味はなかったろうなあ。

2022-08-31 09:39:23

なお、Silpheedの陰影らしきものは、ハードウェア直線補間のラインスタイルで描いてました。サポートするのを忘れてました。その機能を追加してソースをPUSHしたので、シルフィードのグラフィックスは直ったと思います。しかし、当時、どうやってグラフィックスを描いているんだろう？と、思ったもんでしたが、直線補間だったんですね。最初VRAM論理演算でなにか工夫してるのか？と、思ったらそうではなくて、VRAMに書き込んでる個所でブレークさせようとしても自機の描画で止まらなくて、結局残りは直線補間しかなかろうと思って直線補間のI/Oでブレークさせたら見つかりました。

2022-08-31 12:05:51

>388 山川機長さん

元であるPC-8801では恐らく普通に描画していたと思う(調べたことが無いので憶測です)のですが、77AVでは直線補間を使っていましたね。
遥か昔に勝手にTOWNSに移植しようと思ってXM-7で延々とトレースした記憶があります。 DMAとMMRも使って殆どフル機能だったので当時感心させられました。
移植しようとした動機? それはTOWNSであの声が聞いてみたかったと言うだけの事です。

2022-08-31 16:54:16

先ほどPUSHしたソースで、スクリーンショットクロッピングとマップXY座標計算機能を追加してみました。陸奥を作ってて、ふと、メモリフィルタ機能を使えば簡単にRPGとかのマップの全体のどの部分が画面に表示されてるか検出できそう、ということに気が付いて、YsとかYs2とかで、左右に移動しながらメモリフィルタで増減したアドレスを抜き出したら、これが簡単に見つかるんですね。だったら、クイックスクリーンショットを取るときに、座標をファイル名にエンコードすれば、外部プログラムで正しい位置にスクリーンショットを張り合わせることができるのではないか、と、思って、そういう機能を追加してみました。で、それを津軽にも持ってきてみました。試しにエメラルド・ドラゴンでやってみたら、あっさり座標を書いてあるアドレスがわかって、自作の2次元レトロマップツール（github/captainys/publicの中に入ってる）で、ファイル名の座標に対応してみたら、マップ作製が簡単に進む進む。ただし、物理アドレス指定する必要があるので（読み取ったときCSがどこにあるかわからんから）プログラムが同じ物理アドレスに読み込まれるように同じ設定で起動しないと正しい座標が出ません。例えば、物理アドレスをメモリフィルタで発見した後で、搭載メモリ量を変更してしまったら多分プログラムやデータが違うアドレスに配置されてしまって、探しなおしになります（か、メモリを戻すか）。それから、スクリーンショットを張り合わせてマップを作るとき、マップ表示してる領域外のグラフィックはいらないので、出すときクロップしてしまおうということで、そういう機能も追加してみました。多分、おもしろい使い方ができるのではないか、と、思います。よかったらお試しください。

2022-09-12 11:24:51

陸奥書いてて思ったんですが、津軽で音楽の再生とか実機より2.6%ぐらい速い、とかありますかね？陸奥を書いてわかったのが、TOWNSのYM2612のマスタークロックは2MHzであるということと、だとすると、ひょっとすると津軽がタイマーを走らせる速度が実機よりも2.6～3.5%速いかもしれない、ということなのですが、実機手元にあるんだから計測すればいいんですが、ちょっとおもしろいプロジェクトが多すぎて手が回りません。どなたか、お手すきの方がいましたら、EUPファイルとかの再生時間を実機と津軽で比べるとかしていただけると非常にありがたいです。

2022-09-21 11:07:27

おおお、FM音源のマスタークロックが解明できたからタイミングとかそれに合わせて修正したら、シャーロックホームズの探偵講座のビデオの音声が最後まで崩れずに流れるようになった！ハイパープラネットの星座落語も途中から音声再生の順番？が狂ってしまう現象が無くなったけど、途中ノイズが入って聞こえない部分があるのは、CDのイメージ化に失敗したのかな。でも、タイミングずれなくなったから結構最後の方まで聞けるようになった。陸奥開発って結構津軽にも役に立ってるな、と自己満足。

2022-09-22 11:25:44

TownsRenderingThread::ThreadFunc内でFlipUpsideDown()という画像を反転する関数がありおそらくglDrawPixelsで描画を行っていた際に必要だったのかもしれませんが、
glTexImage2Dで描画している現在ではFsSimpleWindowConnection::RenderBeforeSwapBuffers内の
DrawTextureRect(this->dx,this->dy,this->dx+img.wid*scaling/100,this->dy+img.hei*scaling/100);
を
DrawTextureRect(this->dx, this->dy + img.hei * scaling / 100, this->dx + img.wid * scaling / 100, this->dy);
と置き換えれば不要かと思いました。

2022-09-26 02:04:51

おお、たしかに！修正します。ありがとうございます！

なお、Windows版もFM/PCM音源をストリーミングで鳴らすようにしてみました。今までだとときどきタイムリーに次のWAVEを送り出せなかったタイミングで「ぷつっ」とノイズが出る傾向がありましたが、解消されていると思います。PAUSEかけてもリングバッファが流れ続けるという副作用が出てますが、まあ、本来TOWNSは一時停止するものじゃなかったので、ほっといてますが。自分のメモにはDirect Soundはストリーミングで40ms未満の単位でデータを流し込むと捌ききれなかった、とあるのですが、今再度トライしたら20msで鳴ってしまっているのですが、ひょっとしたら他の環境だと鳴らないかも。

CDDAの再生もストリーミングにするかどうか考えてて、オーディオCD全体を再生するみたいな指示があると、今はDirect Soundにオーディオを送って放置しているのですが、それだとDirect Soundが再生できる限界の長さに制約されてしまって、CD PlayerプログラムがオーディオCD全体を再生できないんですね。TOWNSにはユニークなCDプレイヤーが多くて結構好んで使っていた人もいたような印象なので、ひょっとして需要があるだろうかとも思うのですが。ただ、普通ゲームのBGMなどはトラック単位の再生だったのでとくに問題は出ないわけですが。

2022-09-27 03:07:08

掲示板のタイトルからは外れますが、兄弟エミュレータと言うことで。
FM-7/77/AVエミュレータ Mutsu[陸奥]の情報交換用スレッドです。

2022-08-31 16:57:32

＞CSMモード、効果音モード
ゲームではないですが、フリコレ10に収録されているEUP曲「かがやき」(F-OKESHI氏作曲)で聞こえていなかったパートが聞こえるようになったようです。対応ありがとうございます。

2022-09-10 00:37:42

CSMモード,効果音モードの実装を有り難うございます。

せっかくなのでシルフィードの第一中間デモまで、訳あってキーボードで行って参りました。
CSMモードの発声に関しては"あと一息"といった感じで、全体的にノイズが入っているのか声の"明瞭さ"が低く聞き取りにくいと感じました。("そもそもCSMで明瞭なんて無いだろ"って声が飛んできそうですが、実機やXM7と比べてです)
それ以外は、FMもPSG(SSG)も良い感じでした。 XM7と比べると双方で高音部で違いが感じられますが、大した違いではなくそれぞれの"味"と思える程度です。

2022-09-14 11:11:23

そういえば、Alltynexの鳴ってないパートがあった件、ひょっとしたらCSMだったりするのではないかと思ったんですが、どうですかね？CSMモードだとKey On/Offをタイマーがコントロールするので、音が鳴らなかったかも。CSMとSSG＿EGは陸奥で作ったやつを津軽にも持って来れたので、よかったですね。

シルフィードの音声は、まだエンベロープの速さをスロットごとに計算しなおしてないので、それを直すとちょっと違うかもしれないですが、多分、津軽弁ライブラリは本物よりもサイン波がスムーズになってしまってると思います。あと、時間解像度も速いかもしれないので、なかなか他のOPNエミュレータに追いつくのは難しい鴨しれません。

2022-09-15 03:43:47

CSMモードですが、3ch用のF_NUMとBLOCKが3個余計にあるけど、そのうちのどれがどのスロットに対応してるのだ？というのが探してもわからなくて当てずっぽうだったのですが、FM Towns Technical Databookの212ページについに発見しました。間違いも多いけど、FM音源について他には載ってない情報がかなり載ってるので、この本は奇跡的です。それで、対応を直したところ、シルフィードの音声はかなり良くなったように思います。YMのコードはTOWNSEMUのレポジトリに入ってるので、そのソースをPULLして陸奥をビルドしていただけると確認できると思います。

2022-09-15 11:20:24

>7 山川機長さん

対応の方、有り難うございます。

CSMモードですが、劇的に良くなったと思います。
XM7比ですが、多少低音側が強くなっており声が野太い印象ですが随分と良くなったのは確かです。
実機の記憶ではXM7の音に近く、解りやすいのはゲームアーツのロゴの部分でもう少し子供の声に近いような高い声が正しいような気がします。

また、Alltynexの方は正直、違いが判らない状態です。

2022-09-15 16:49:20

そうですねえ、CSMの理屈を勉強した、というか教えてもらったんですが、フーリエ変換してDominant Termsを上から4個を拾ってきてるわけですね。で、声は聞こえるけど低く聞こえる、ということは低周波成分のボリュームが大きいのかな。しかし、FM音源には、高い音のエンベロープの変化を速くするという機能があるものの、現在まだ津軽弁はCSMモードではスロットごとに対応してないんですよね。これをスロットごとにすると、直観的にはかえって低周波成分の減衰が遅くなってもっと低くなるような気がするのですが、とか言ってる間にやってみりゃいいんですよね。今日の晩はボウリングの試合があるので、明日ミーティング中にやってみます、と、思ったら明日から普通に会議室で集合になってしまった。週末はフライトが入ってるし、案外時間ないなあ。とりあえず時間できたらやってみます！

2022-09-16 00:06:44

うーむ、スロット事にエンベロープのスピード変えてみたけど（時間が無いんじゃなかったのか）変わらんですね。実機やXM7のPresented by Game Artsを聞くと、抑揚がついてますね。ひょっとしてMULTIをいじってるのかと思ったけどそのようでもないし。はて、何が違うんだろう。

2022-09-16 05:47:02

さんざん調べた結果、結論は、Wave生成の時間解像度が足りないということがわかりました。2msにしてたのを1msにしたらかなり改善しましたが、まだ実機と違うので、500usまでトライしてみます。謎なのが、以前1msにしたら最後のWave生成からWaveをデバイスに送るまでの時間があまりにも小さかった影響で（多分）再生が間に合わないという現象が起きてたと思ったのですが、起こらなくなってました。

津軽の方はCSMを使ってるソフトがまだ確認できてないので、引き続き2msで行こうと思ってますが、、、、あそうか。津軽だと486のエミュレーションが厳しくて間に合わんかったのか。77AVだと余裕があるから500usまで下げても大丈夫な気がしてきた。

今日は時間切れになってしまったんですが、明日やってみます！一応、今のソースPUSHしたので、改善を確認していただけるかと思います。

2022-09-18 12:59:38

さらに調べた結果、YM2612のタイマーエミュレーションが間違ってたということが判明しました。津軽でここまで使われてきてるのに、まだこの違いが残っていたとは。XM7のopn.cを参考にさせていただきました。これでシルフィードのPresented by Game Artsはほぼ実機と同等になったと思うのですが、どうでしょう?

2022-09-20 13:34:33

雑談スレッドでハードウェア解析や考察が話題となっていますが、個人的に別途スレッドを立てた方がよいと思ったので立てました。
強制はしませんが、今後のハードウェア解析や考察についてはこちらのスレッドで話題にしていただけると助かります。

2020-09-24 09:40:33

そうなんですよね。このサイトは僕も相当お世話になったのに、まさかタワー型の電源のピン割り当てまで載っているとは思いませんでした。

2022-07-28 02:01:32

機械翻訳: 多くの海外ユーザーが成功裏に使用している代替電源を作成しました。 第2世代、第3世代、第4世代は動作確認済みです。

https://github.com/cyo-the-vile/FMT-ATX-TOWER

ほとんどの場合、ストック電源は修理できると思います。 修理が困難な場合は、この PCB を使用できます。

2022-08-10 07:15:11

>56 cyoさん

有用な情報を有り難うございます。
初代(model1,model2)に関しては、集積化が未発達で大量のTTLが使用されていますので消費電流が大きいのかもしれませんね。
初代機(model2)と中間機(MX)と末機(HC)を所持していますが、どの世代でどれだけ集積化が行なわれたかがよく解らないのです。
出来ればこの辺りも文章化出来れば良いと考えていますが、コレクターと言う訳でも無いので今のところは難しいのが現実です。

2022-08-17 09:24:34

Windyさんへのお返事です.

あなたの仮定は正しいです。 それは正直なところ効率的な設計ではなく、富士通はそう結論付けたと思います。 Gen1 (Model 1、Model 2) の 5V ラインは非常に大量の電力を使用します。 ディスクドライブの問題が解決したら、問題を再検討するかもしれません。

"ME" と "MF"タイプのデスクトップしかありません。 実際、メイン ボードの高解像度写真がまったくないことに驚いています。 このドキュメントにそのような要件はありますか?

2022-08-18 02:10:08

>58 cyoさん

メインボードを含む基板の高解像度写真が無い事は現時点では大きな問題にはなっていませんが、将来的には必要となるかもしれません。
私は手持ちのHCとMXのメインボードを過去にカメラで撮影しましたが、カメラを手で持って撮影した関係で公開できるような絵が撮れなかった事から公開していません。
照明やカメラを固定するブラケットを用意して取り直す必要が有るとは考えています。

ただ、MX位の世代となると多数のゲートアレイが使用されていることや、ゲートアレイの機能が公開されていない事からもメインボードの写真が有っても用途が無いのではないかとも思います。

2022-08-18 17:36:53

各種アプリケーション動作報告スレッドで話題に上がったスプライト縮小時の描画についての補足
(- を透明ピクセル、それ以外を不透明ピクセルとすると

X方向を縮小した場合
|-|x| => x
|x|-| => x
|x|y| => y

X, Y方向を縮小した場合(どう回転しても同じ結果)
|a|b|
|c|-| => c

優先順位をもってピクセルを選択する必要があるようにみえるが、スプライトRAMの先頭から透明ピクセル以外を順に描画すれば同じ結果が得られる。
|-|x| => - は塗らない、x を塗る => x
|x|-| => x を塗る、- は塗らない => x
|x|y| => x を塗る、y を塗る => y

|a|b|
|c|-| => a を塗る、b を塗る、(次の行で)c を塗る、- を塗らない => c

2022-09-12 05:09:25

(続き)
SPYSビットが立っているときも同様で、従来同様の描画処理(パターンが透明色でないとき、最上位ビットを立ててピクセルを描画)をパターンの全ピクセルに適用すれば問題ない。
(画面上の差異はないが、0x8000を描画する、ではないことに注意!)

2022-09-12 05:29:45

なんと、そんな複雑なことをしていたとは。早速調べていただきありがとうございました！Pull Request、Mergeさせていただきます。

2022-09-12 07:38:44

前の行・ピクセルを覚えておく必要もなく、ただ書き込み先のアドレス計算を工夫してあるだけなので、よくできた仕組みだと思います。
(transformの実際の実装は、8bitカウンタ1個、4bit XOR2個、4bitセレクタ2個、4bitの右1bitシフタ2個でしょうか)

2022-09-12 12:09:42

FMTownsのアプリケーションの動作報告用

2020-07-28 13:17:50

ああ、原因わかったかも。publicレポジトリPUSHするのばっちり忘れてました。今PUSHしたので、試してみてください。

2022-06-18 16:12:40

おお、鳴りました。対応ありがとうございます！

2022-06-18 21:32:54

ゆみみみっくす、放置してすみません。忘れてたわけではないのですが。とりあえず、原因は、Shadow of the Beast 2対策が邪魔してました。

Shadow of the Beast 2が何をやってたかというと、CD-ROMのIRQハンドラが、Data ReadyのSIRQとDEIが交互に入ってくることを期待していて、直前のDEIが処理される前にSIRQが出てしまうと永遠にDEIを待ち続け先に進まない、という状況に陥りました。そのため、直前のInterrupt RequestがConsumeされていない場合はData Readyを出さない、という方法でShadow of the Beast 2が走るようになったのですが、ゆみみみっくすの場合、直前のInterrupt Requestが処理されてなくてもData Readyが出ないと先に進まないという状況ですね。

さてどうしたもんか、と、思ったのですが、ここまで書いてて、直前のInterrupt Requestが処理されてなくて、かつDEIが1のときだけ待たせればいいのではないか、ということに気が付いたのでやってみます。

2022-09-05 08:19:57

ゆみみみっくす、起動できるようになりました！ソースPUSHしたので、よかったら試してみてください！

2022-09-05 08:40:22

ゆみみみっくす対応ありがとうございます！
起動できるようになりました！

2022-09-08 22:01:29

仮想ゲーム機エンジン「PICO-8」向けに作られていたフリーゲーム「CELESTE Classic」をFM TOWNSに移植してみました。
https://bcc.hatenablog.com/entry/2022/09/10/234539
エミュレータ「津軽」「うんづ」及びFM TOWNS MARTY実機上でクリアまでいけることを確認したんですが、「津軽」上だと髪の毛や吹雪の表示が問題ないのにMARTY実機で試したところ髪がズレて表示されたり吹雪がすべて2ドット分の大きさで表示されてしまう現象が発生しました。
おそらく津軽の再現性の問題かと思いますので、確認をよろしくお願いします。
TOWNS版CELESTEの表示方法は
・画面は全てスプライト表示。表示枚数は最大448枚。
・スプライトは縮小表示で8*8相当に縮めている。
・128*128で描いたスプライト面を3倍拡大して384*384にして画面中央に表示
という手順をとっています。

2022-09-11 14:25:28

髪は知りませんが、雪は縮小アルゴリズムの実機との差異ですね
CELESTE側ではスプライトを定義する際に2x2ドットの境界をまたがないようにするか、
そもそも縮小を使わない(左上8x8のみ使用して残りを透過色で埋める)ようにしてはどうでしょうか

2022-09-11 21:13:21

なるほど！津軽上では問題なかったけど、実機に持って行ったときと動作が違うということですね。

たしかに、津軽上で実機用ソフトを開発するときにそれに当たると困りますね。FM77AV上でコード書いてて、FM-7に持ってきたらVRAMアクセスフラグ立て忘れてて画面が変、みたいな状況ですね。（違うかもしれない）

動画拝見しましたが、チップチューンのBGMがいい感じですね。

縮小は単に１ドットずつ飛ばして書いてるだけだろうと思ったのですが、実機だと何か複雑なことしてるのだろうか。あと、Martyと他の実機では違いがあるのだろうか。MXでテストコード書いて試してみます。X=奇数のピクセルが白のスプライトとX=偶数のピクセルが白のスプライトを縮小表示してみれば何かわかるかな。

2022-09-11 21:40:45

通常スプライトRAM側で奇数番目(あるいは奇数行目)のピクセルが表示されるのですが、透明色の場合に偶数番目を参照するようです。
件の雪は(-: 透明ピクセル, x: 不透明ピクセル, |: バイト境界)
+56 ...|-x|x-|...
+64 ...|-x|x-|...
のように定義されていたため、1x1で表示して欲しいところ2x2になっていました

SYPSが立っていた場合の優先順位はまた違うかもしれません。
また、X, Yともに縮小の際の候補4ピクセルの優先順位も調べる必要があります。

2022-09-11 21:46:42

他愛もないない事から、悩み事までなんでもお書きください。

では、手始めに私の困ったことから。
我が家のTowns・・・ モデル2FとMXとHC(MXは実家に置き去りにしていますので手元には無い)ですが、MXとHCはCD-ROMが弱っているようでCD-Rが読めなかったり、
特定のCD-ROMから起動できなかったり・・・・ FDDはメディアが悪いのか,安定しない状態です。
かといってSCSIのCD-ROMドライブを持っている訳でも無いので、Windowsとのデータのやり取りに苦慮する場面がチラホラとあります。
真剣に内蔵CD-ROMを何とかする手だてを考えないといけないのだろうか・・・・ みなさんのTownsの状況は如何ですか?

2020-07-29 10:03:48

これはうんづですと代替IPLを使用する必要があるソフトで、うんづで実CDをWindowsPCにセットする場合もこの設定が必要でした。
色々なソフトでイメージ化を試しても上手くいかず、バイナリエディタでイメージ修正も試したことがありますが、何も解決も出来なかった苦い思い出があります。
TOWNSのBIOS経由だと読めるのですね。
一体どんな構造をしているのだろう。
レインボーアイランドエクストラ以外にエンジェル、EVOLUTIONが同様だったと思います。

2022-05-08 11:48:59

レインボーアイランドエクストラは持ってませんがスプラッターハウスやプリルラといったRIE以降に発売されたVINGタイトルは問題なく吸い出せたり、同じようにセクター0で止まる現象はザ・マンホール・ぷよぷよ・フリコレ1で発生したことがあります。止まるタイトルのディスクデータ面に傷や汚れがついているわけではなく、吸い出すドライブを変えると正常に吸出しが完了しました。

2022-05-08 12:47:50

おおなるほど！だとするとほぼ確定ですね！うんず＋物理ドライブで使う場合だと、CRCエラーが出る影響で、IPLセクタが読めなかったものと思います。だとすると、少なくともセクタ0のエラーは僕が持ってるディスク固有のものではないんですね。偶然できたエラーにしては出来すぎなので、多分意図的なコピープロテクトですね。

ただ、Evolutionはうちのドライブだと普通にイメージ化できましたね。

ありがとうございます！

2022-05-08 13:05:45

マスタリングソフトのバグを踏み抜いてしまったが、TOWNSのドライブのEDC/ECCチェックもいい加減だったために気付かれず世に出てしまった…なんてことはないですかねえ

2022-05-09 03:05:37

代替IPLを使用しない設定にしたうんづで、Evolution、エンジェル、ぷよぷよ、ザ・マンホールを試した所、どれも起動しました。
私の勘違いだったのか、それともOSやドライブが変わって読めるようになったのか・・・。
レインボーアイランドが見つからなくてテスト出来ませんでしたが、このソフトも当時は代替IPLが必要で、私のメモ書きにもそう書き残されていました。

2022-05-09 08:02:53

レインボーアイランドエクストラを、代替IPLを使用しない設定にしたうんづで試した所こちらも起動しました。
実機＋救済IPL＋外付CDドライブで試した所、レインボーアイランドエクストラ、Evolution、エンジェル、ぷよぷよ全て起動しました。
起動してくれて嬉しいのですけども、あの当時苦労した記憶とのギャップに困惑しております。
イメージ化をした場合のみIPLが消えるのかな。

2022-05-09 20:53:10

SHSUCDXをTownsOSで使用されている方いらっしゃいますか？
TownsOS V2.1L20とL31で作成した起動FDにSHSUCDXを組み込んでみたのですが、Must be DOS 3.3 or later.と表示されて使用できませんでした。

AUTOEXEC.BATに記述した内容は SHSUCDX.COM /D:TOWNS_CD,Q です。
互換ROMに入っているSHSUCDXを取り出して置き換えても同じ結果でした。

過去の投稿を検索していた所、SHSUCDXの時間取得に関する部分を互換ROM側で調整したように思える報告がありましたので、エラーメッセージのとおりDOS5、6.2専用でしょうか。

2022-09-03 10:06:21

SHSUCDXは DOS 3.3 以降専用ですね。しかし、TOWNS用プログラムの中には3.1であることを前提にしているプログラムがあります。そこで、YSDOS.SYSは、SHSUCDX起動時のみ自身は3.3であるふりをして、それ以外では3.1であるふりをしています。実機で使うためにはSHSUCDXのソースを書き替えてビルドするか、バイナリにパッチを当てる必要があると思います。

2022-09-04 10:55:49

ありがとうございます。DOS3のマイナーバージョンをチェックしないようにしたところ、DIRとTYPEコマンドのみの確認ですがTownsOS V2.1L31で使用できました。
25KB程メモリが空いたようです。

2022-09-04 14:50:39

FMTowns実機や各種FMTownsエミュレータを使用する上での質問事項

2020-07-28 13:20:43

>KtJ Dragonさん

そうなんですね、NetWareだとメモリをあまりくわないのですね。 でも、入手できそうに有りませんね。残念。
通信プロトコル近辺はチンプンカンプンに近いので、難航することが予想されるわけですが、一度(過去にやったことが有るような記憶が有りますが)トライしてみようと思います。
でも、DOS関連で何かと古いので情報も然りなんですが、サポートの問題も有りなんですね。

WindowsでもSMB1が廃止されたと言うことですが、ひょっとしてこれっってPCと直接接続できないって事かな?って思ってます。
まあ、NASが見れればNAS経由でファイルは送れるから大丈夫かなとは思っています。

2022-05-13 18:13:28

昔はWindows95のLANでファイル転送をしていましたが、今は電池切れもあってBUFFALOのASPIマネージャを使用するようになりました。
TOWNS本体にはSCSI接続のPCMCIAカードリーダー(I-O DATAのCARDDOCK EX/SC)を接続し、起動用FDはMS-DOS6.2で作成してASPIマネージャ、ASPIディスクドライバを登録して、
専用フォーマッタで2GBのフラッシュメモリ（SD、CFなど）の127MBだけ確保します。
Windows10では挿すだけで127MBのフラッシュメモリとして使用可能です。

フリーのASPIFMらしきドライバも入手したのですが、フリーのディスクドライバSCSIDISK.SYSを読み込んだあたりで「ブロックデバイスが多すぎます」のエラーが出て止まっていました。
他のディスクドライバも試しましたがダメでした。
MO、CD用であったのか、それともHDDは32MB未満でないと行けなかったか、ASPIFMが別物であったか、正式バージョンでなかったかもしれません。

2022-05-13 23:52:54

>WINDYさん

NetWareのクライアント(とログインに必要な実行ファイル)はNetWareサーバ4以前の日本語版に付属しており、時々ヤフオクに出品されているようです。FM50L186/187のODIドライバもついてきます。

SambaのドキュメントによればこちらもSMB1(やLM認証)はいずれ使えなくなるようです。そのうちにNASもDOSやXP以前のWindowsから参照できなくなりそうです(今のNASはまだLM認証にできるんでしょうか？)。

2022-05-14 00:30:02

>26 KtJ Dragonさん

情報を有り難うございます。
NASのLM認証に関しては、QNAPではNTLMv1認証が最低ラインのようでLM認証は駄目なような気がします。

VirtualBOXにWinXP等をを入れてTOWNSと接続する・・・ しかない?? 出来るような気がするが、これは面倒くさいような気がする。

2022-05-16 09:35:56

実機～PC間のデータのやりとりの続きになりますが、
KtJ DragonさんのサイトでKUMADSKなるディスクドライバの紹介を見つけて使用したところ、MS-DOS6.2+CardDock EX/SCの環境で、Windows10で初期化した2GBフラッシュメモリの読み書きに成功しました。
MS-DOS6.2専用ながらも大変便利です。
BUFFALOのASPIマネージャですとDOS3.1ベースのTownsOSでも128MB以下(未満？)で使用可能ですが、販売終了のようで誰でもお手軽にとはいかずお勧めし難いところでした。

2022-07-24 12:22:27

>28 aochanさん

情報を有り難うございます。
SCSI接続のPCカードアダプタにSCSIドライバの組み合わせですね、なるほど! これは結構便利かもしれませんね。

残念ながら私はSCSI接続のPCカードアダプタを持ってませんのでそのままの形で利用することは出来ませんが・・・・・
SCSI接続のCD-ROMドライブは有るので、WINDOWSで焼いたCD-RWが使えるかも知れないので試してみようと思います。

折角なんでFRAMメモリカードから内蔵HDD起動して、SCSI接続のドライブのCD-RWを読んでみよう。

2022-07-25 09:07:43

CD-RWいいですね。
外付けCDドライブだからCD-RWが読める可能性が高そうですし、FRAMカードを使えばドライバも不要ですね。

2022-07-26 21:28:45

CD-RWを使うメリットが「メディアが無駄にならない」と言う一点だけなのですが、素直にTownsOSをCD-RWに焼いてFRAMカードから起動する事自体は可能でした。
ただし、我が家のHCはDOS6ベースなのでその状態ではHDDには一切アクセスできないので意味がない事も思い出しました。

FRAMカードから立ち上げて内蔵HDD起動した場合には、当然のことながらYSSCSI.SYSが効かないのでSCSI接続のCDドライブはアクセスできないので、CONFIG.SYSにYSSCSI.SYSを登録して起動してみたのですが、今のところはMSCDEXでドライバが見つからないとのエラーが出ています。

それはさておき、上記の作業を色々と行なうにあたりFDを1.2MBでフォーマットする事が有ったのですが現在のWINDOWS10では普通にはフォーマットできないのですが下記のURLにあるツールでUSB接続のFDDを用いて1.2MBフォーマットが出来ましたので報告しておきます。

http://bauxite.sakura.ne.jp/software/dos/freedos.htm
(Driver and Tools for FreeDOS(98)の一番下、[おまけ]にあります)

2022-08-24 11:24:17

1.2MBフォーマッタって存在していたのですね。
今まではコマンドプロンプトでフォーマットして（失敗のメッセージが表示される）、フォーマット済みの1.2MBイメージファイルを書き込む2段作業をしていました。

YSSCSICDはTownsOS対応ソフトに的を絞っているのでしょうね。
私もMS-DOS6.2でYSSCSICD.SYSを試しまして、外付けCDドライブが認識されない事を確認しました。

MS-DOS6.2で外付けCDドライブを使用するには、ASPIマネージャーを使用するほか無いのかな。
BUFFALOのASPIマネージャーとそれに付属のCDドライバやCDSD-miniでは使用できました。

試したことは無いのですが、MS-DOS6.2で使用できるCDドライバが無い場合は
YSSCSICDまたはFRAMカードとTownsシステムソフトウェア、それに加えてVectorにある128MB以上の区画を読み書きするドライバEXTDRVで、CD-RWからMS-DOS6.2領域へファイルコピー出来るかもしれませんね。

2022-09-03 09:55:37

スレッド分けました。内蔵CDが故障してしまったTOWNSをフロッピーディスク経由でSCSI CDから起動するブートローダープロジェクト用スレッドです。一応、フロッピーディスク経由の場合と、SCSI2SDや変換番長のような仮想SCSIデバイスからの起動の両方を想定してます。似たようなことは既にYSSCSICD.SYSでできていますが、TownsOS起動ディスクに組み込む必要があるので、ディスクの再配布していいか微妙なのと、特殊なドライバを組み込むタイトルでは専用起動ディスクが必要などの問題がありましたが、このプロジェクトはその2点の解消を目指してます。

まだ津軽上の実験ですが、SCSI CDドライブからIO.SYSを読み込み、INT 93Hなどをインストールして、MSDOS.SYSまで読み込んだところで処理を迎撃することに成功しました。まだ青森県地図の表示はできてません。

しかし、迎撃地点ではMSDOS.SYSは読み込んでいるものの、まだINT 21HがEnableされていないようで、INT 21H AH=48Hでメモリを確保してやろうと思ったら固まってしまいました。これ、INT 21がまだ使えないのではなく、実はPSPとかが存在してないからという可能性もあるんですがね。ただ、考えようによってはBIOSのRedirectorをインストールしようと思ったらこの迎撃地点は悪く無くて、IO.SYSには内蔵CD-ROMから起動したと思い込ませているはずなので、ここでINT 93 AL=C0HがすべてSCSIにリダイレクトされるようにすると、IO.SYSは何事もなかったかのようにSCSI CDから起動してくるはずです。

問題は、リダイレクタをインストールしたとして、リダイレクタが使用するアドレスがその後別のプロセスに上書きされてしまうことを防止しなくてはならない点です。そのために、その後さらに調べたところ、どうも、MSDOS.SYSにジャンプするときのDXの値がMSDOS.SYSが使ってもいい最後のアドレス (DX=B800Hだと物理B8000Hまで使える)になっているようなのですが、どなたかこの解釈が正しいかご存知の方いませんか？また、そうした場合、DOS ExtenderがB8000～BFFFFを使わないと言えるのかという問題もあるのですが。nabeさんとか知ってそうと期待していたりするのですが。もしもこの解釈が正しければ C000H をDXにセットしている場所にパッチを当ててやれば、BIOSリダイレクタ置き場を作ることができるはずです。

これまで津軽のデバッガでMSDOS.SYS入り口で止めてLET DX B800H として放流してやった上でV2.1 L20上で何本かEXPファイルを走らせてみた限りではB8000～BFFFFは守られているようでした。

別な方法としては、もともとのCD-ROM BIOSはいらなくなるので、IO.SYSを識別して、もとのCD-ROM BIOSが書いてある場所にリダイレクタをインストールしてしまうという手もあるのですが、やや乱暴な方法で、多分CD-ROM BIOSは一か所に固まっているのですが他のINT 93Hがその部分のPROCを使っていたらこの手は使えないですね。

また、できればC0000H直前ではなくもっと下の方のIO.SYS直後あたりにインストールしたいところなのですが、どこでIO.SYSが使っていい領域の最初のアドレスをMSDOS.SYSに渡しているのやら。それはまだ見つかってません。ただ、IO.SYSのサイズはTownsOSのバージョンによって異なってもどのTOWNSのMSDOS.SYSを使っても起動できるということは、どこから使っていいかという情報もIO.SYSはMSDOS.SYSに絶対渡しているはずなんですがね。

2020-09-24 09:22:42

了解しました。ありがとうございます。

今メールを送りました。よろしくお願いします！

2022-07-03 18:04:31

早速SNと初代機で試したところ共に外付CDドライブでライザンバーを起動でき、オーディオINも有効になっていましてなんら問題なさそうです。
しばらく挿したままで運用しようと思います。
外付CDドライブだと読み込みが速いから、初代機でも快適になりますね。

2022-07-06 01:10:47

>291 aochanさん

無事届いて良かったです。(昨日は結構な雨だったので少し心配でした)
初代機でも快適・・・・ そうか! そう言うメリットもアリなんですね。
私もまだなのですが、Wikiの方にレスキューIPLの動作確認リストが有りますのでもし確認が取れていないドライブやソフトが有ればそちらに書き込むか、この掲示板でお知らせください。

2022-07-06 08:59:25

aochanさん、

おおー、初代機で成功しましたか！SCSIカード搭載の初代機はなかなか無いので貴重品ですね。

テストしていただきありがとうございます！

2022-07-06 14:35:30

山川機長さん、WINDYさん、頒布ありがとうございます。本日無事にFRAMカードを受け取ることができました。
これはスマートで素晴らしいですね！

FDのように摩耗を気にする必要もないですし、非常に快適です。
CMOS設定、バックアップ、リストアも手軽で使い易いですね。
一々OSを起動して設定しなくてもジョイパッドで設定可能なのが便利です。

先ず、HCとCXでTownsOSV2.1L51とアフターバーナーIIを起動しましたが問題なく動きました。
後でmodel2を引っ張り出して動かしてみます。

とりあえずご報告まで。

2022-07-06 18:59:39

先程Model2で動かしてみたところ、問題なくICMCでブートができました。
ソフトはTownsOSV2.1L51とアフターバーナーIIを試して問題ありませんでした。

Model2のメモリーカードスロットはただの穴だと以前何かで見たのですが、
本当にレールもイジェクト機構もないので、試す方がいらっしゃったらお気を付けてください。

2022-07-06 21:09:13

D-Typeさん、

テストしていただき、ありがとうございます！これで、初代、CX、HCで動作が確認できましたね！うちのMXと2Fでも入れっぱなしで使っているので、どうやらTOWNSの386SXを除くすべてのモデルで使えそうですね！

しかし、model2のスロットは、ただの穴なんですね。2Fは、一応脱落防止のためのレールと、Ejectボタンはありますね。

2022-07-06 22:58:55

>295 D-Typeさん

無事届いたようで安心しました。
初代のカードスロットはほんとに危険ですよね、もし内部に落としてしまったら結構バラさないと取り出せないし。
初代は完全に分解したことは無いのですが、話によるとそれはまさしく箱根細工のような構造だとどこかで見た覚えが有ります。(なので分解してません)

今更なのですが、メモリカードスロットは結構汎用性が高いスロットなのかもしれないと考えてます。
「MCUかFPGAを繋げたら何か出来るかなぁ」等と野望が頭をもたげます。 割り込みがかけれないのが欠点ですけど。

2022-07-06 23:02:34

>296 山川機長さん
こちらこそありがとうございます！無事テストができて一安心です。
本当にこれは素晴らしい技術ですね。流石です！

メモリーカードスロットを使う方法は使い方が簡単でいいですね。


>297 WINDYさん
送って頂きましてありがとうございます。
縦型Townsの構造はどれも複雑で、開けるのは難しそうですね。
職人さんが書いた本を見てCXの調整をしたことがありますが、プラスチックが弱くなっていて苦労した記憶があります。

メモリカードスロットの活用法は考えるだけでも夢が広がりますね。

2022-07-07 01:57:49

現在Windows 3.1の起動までこぎつけられないかと思ってCPUコアをいじってるのですが、まずLARインストラクションで詰まってたのでそれは単にLARを実装して突破したのですが、INT 91Hで詰まってます。

どうやら、Windows 3.1は、リアルモードのバイナリのうち処理を奪う必要がある個所に 63H (ARPL)を書き込んで、Virtual 86モードでINT 6を出させて処理をいったんカーネル側に移して、その後、IP+1から処理を再開、としているようです。最初ARPLを見たときは何かの間違いではないかと思ったのですが、最初のうちそのままで順調に進んでいるようだったので、どうやらARPLを書き込むこと自体は正しいようです。ARPLが書き込まれる場所の多くは、書き込み前は90H (NOP)になっているのも多分この書き換えが意図的なものであると考えて問題なさそうです。

INT 6ハンドラは、0048:00000102ですが、どうも169Cセグメント(DOS?)内でARPLが起きることを想定しているようで、INT 6を受けて、Exceptionが起きたインストラクションが63Hであった場合、Exception発生個所＋2バイトに飛び、その場でリアルモードへの切り替えが起こるように書いてあるようです。0048セグメントはひょっとするとEMM386かも。

しかし、あるタイミングでIDTが書き換わって、INT 6をハンドルするのが0028:80006E5Cに変わり、再度0048:00000102に変わった後で、INT 91Hのハンドラの入り口(07F9:000023F4)のARPLでINT 6が出た後、00B8セグメントのあらぬ場所にジャンプしてクラッシュしてます。INT 91Hのハンドラは先頭にARPLが書かれているのですが、+2バイトではリアルモードに切り替わるように書かれていない上に、00B8セグメントのベースは169C0Hを指したままなので、違うセグメントの無意味なアドレスにジャンプということになってます。

MSDOS.SYS以外のINTのARPLは0028:80006E5Cだとうまくさばけるようなので、IDTが書き換わるべきではないのか、INT 91Hは別の処理の仕方であるべきなのか、そもそももっと前の時点で何かがこわれててINT 91Hが出るべきではないのか、なかなか難しいですね。どうもこの INT 91H (コンソールBIOS) はコンソールに1BHを書き込もうとしてるようなので、すでにコンソールは表示されていないことを考えると実はINT 91Hが出ていること自体が間違ってるのか。

なお、Core i9のPCを買いました。最近シングルコア性能は世代が変わってもほとんど変わらんと思っていたのですが、案外変わってたんですね。多分486SXの66MHz近いスピードが出てるようでStrike Commanderが快適になりました。ただ、nVidiaのGPUだったので、OpenGLのVSYNC待ち（なぜかnVidiaはデフォルトでオンにしている)をオフにしないと待ちが入ってスピードが落ちるという問題がありました。

2021-01-21 00:40:27

まさにその通りで、Windows 3.1はとりあえずこの間実機のHDDから既にインストール済みのイメージを抜き出すことができたのでやってみている感じで、Windows 3.1そのものにはあまりモチベーションが無いんですよね。Windows 3.1が動作しなければWindows 95も動作しないと思うのでやってるというか。ひょっとするとLinuxの方が素直にできているかもしれません。

それにしても、本来であればタスクを切り替えるとき、Page Faultが起こらないようにページをマップしたうえで切り替えるべきな気がするんですけどね。試しにIRETしたところでPage Faultを出してみたのですが、これで正しくメモリがマップされて戻ってきたらPage Faultをわざと出させている可能性が高まったのですが、ぜんぜん無関係の領域がマップされたので、それほど単純でもなさそうです。

春学期も始まってしまったので、多分この問題はしばらく放置状態になりそうです。

2021-02-03 00:41:18

ありがとうございます

2021-02-04 11:18:48

うーん、どうしてもWindows 3.1が起動しない原因が解明できないですね。Windows 3.1を起動させるために本来のTOWNSアプリケーションのパフォーマンスが落ちるようであればあきらめようと思っていますが、原因がわからんというのが気に食わないんですよね。原因が解明できた上で、これをサポートする価値は無いという結論だったらそれはそれでいいのですが。

現在、

00A7:0000C7B8 INT 31H
AX=0602h Mark Real Mode Region Pageable
BX:CX=Starting Linear Address (0003:5410)
SI:DI=Size (0008:ABE0)

それで、このときはアドレスサイズ、オペランドサイズともに16という半端なプロテクテドモードで動作していて、Windows 3.1のDPMIインターフェースによると、INT 31H AX=0602Hは、リアルモードの線形アドレスをページ可能にするというもののようです。

この関数の中で、BFFFFHまでのリニアアドレスのページテーブル情報をごっそり消してしまうのですが、問題は、このINT 31Hの発射地点はリアルモードだとAE84:C7B8、物理アドレス=線形アドレス=BAFF8Hにあたり、戻ってきたときページが無くなっててそのままクラッシュになってしまいます。

ひょっとしてページフォールトを検出してマップしなおすのかという可能性も考えたのですが、多分それは正しくないように思います。スワップアウトするでもなく、ハイメモリ領域に移動するでもなく、いきなりページを消してしまったのでは、ページフォールトが起きてももともと何があったのかわからんと思うんですね。なので、使用中のページは消すべきではないと思うんですね。

その仮定が正しいとすると、

(1) INT 31Hを出すときのサイズ(8ABE0H)が間違っている。ちなみに、このサイズは起動時にチェックしたリアルメモリ実装量、TOWNSの場合はC0000Hから計算されている模様。
(2) そもそもこのコードがC0000H以降に置かれるべきコードが何かの間違いでBAFF8Hにある。
(3) INT 31H AX=0602hは本来使用中のリニアアドレスのページは消さないはずだが、間違ってBAFF8H付近は未使用と思ってる。
(4) INT 31Hから戻る前に本来であれば使用中ページはハイメモリに移動してページテーブルもそれに対応して更新してから戻るべきところが、なぜか移動とテーブル更新が起きてない。

などの可能性を考えているのですが、いかんせんWindows 3.1の内部という難敵を相手にしているもので、なかなか難しいですね。

このINT 31H AX=0602hの本来の挙動というのはどうあるべきか、誰か知ってますか?

2021-11-02 10:47:44

(ほぼ需要がゼロなのに)あきらめずにWindows 3.1が起動できないか試しているのですが、自爆しているプログラムがKRNL386.EXEであることまでわかりました。どうやら普通にINT 21H AH=4BH (プログラムのロードまたは実行)を使って起動しようとしているのですが、ただし、既にWindowsが起動しかかっているので INT を使うかわりに INT 21H ハンドラにCALLFを使って飛んでいるようです。その中で、どうやらBFFFhセグメントからバイナリサイズ/10hを差し引いたセグメントにKRNL386.EXEをロードして実行するのですが、上に書いた通り自身の中でリアルモードメモリ0～BFFFFhをページ可能にする、というシステムサービスを使って自分を見えなくしてしまって自爆します。

リアルモードメモリをページ可能にするというシステムサービスは正しい動きをしているようなので、KRNL386.EXEがC0000h未満にロードされる以上、必ずクラッシュするらしく、なぜC0000h未満にKRNL386.EXEをロードしてしまうのか、という謎は、アドレスを計算している場所は特定したものの、BFFFhの出どころがまだ解明できていないため、解決には至ってないという現状です。しかし、INT 21H AH=4Bh のデフォルトの挙動としてはプログラムをC0000h未満にロードするはずなので、何か特別なことをしてないとハイメモリには展開されない気がします。

一度、SETUP2.EXEを使ってハイメモリを有効にする必要があるのではないか、という指摘があったので、試しましたが結果は変わらなかったですね。しかし、これが設定の問題である可能性もゼロでは無いので、TOWNSでWindowsを起動するときなにか設定が必要だったとかもしもおぼえてる人がいたら情報をお願いします。

しかし、津軽でWindows 3.1を実行する需要がほぼゼロという問題はあいかわらずあるんですがね。

2022-01-29 02:05:09

自分ではTownsについては良く判かりませんので 参考になるかも判りませんがTownsで Windows 3.1を起動させているサイトの情報がありました。
http://www43.tok2.com/home/cmpslv/Konjo/019/019.htm

2022-02-15 23:26:42

ありがとうございます。参考にさせていただきます。たしかにMAMEのデバッガで正しい動作がどうなのか追ってみるのも手かもしれませんね。

2022-02-16 12:13:56

MAMEで動くのならCPUでしょうか。
CPUで気付いた点で、おそらくほとんどのプログラムに影響しないのでわざわざ報告するのもなぁと放置していた点が何点かあって、

・NEGがAフラグを変更しない
これに依存するプログラムはおそらく地球上にはないので、こっちはどうでもいいと思います

・オペランドへのストア前に状態を更新している
ちゃんと検証できていないのですが、 push/pop mem で PF が起きるとページをマップして再実行した結果、esp が本来の倍変化するのではないかなあと思っています

2022-02-17 01:26:02

なるほど！CPUコアの問題であることは間違いないと思うのですが、現状津軽のCPUコアはFractal Engineを走らすための必要最低限のExceptionしか対応していないので、多分PUSHでExceptionが起こるとそのままVMがAbortしてしまうかも。

が、考えてみるとWin3.1の問題個所ではPFが出るかと思ったらCS,EIPその他をスタックに詰めないのでDouble Faultになりそうな気がしてきました。実はここはDouble Faultを出すと先に進んだりして。というか、それだとするとやっぱり真面目にInstruction Fetchの段階でもException見ないといかんのかな。これを入れるとTownsネイティブアプリに効いてきそうでちょっとやだな。

2022-02-19 00:02:59

おそらく需要がゼロと思われるWindows 3.1対応ですが、DOSBOX上のDOS用Windows 3.1との動作比較の結果、現在ひっかかっている箇所の問題が特定できました。ページテーブルのbit 5, bit 6 (0x60)をチェックしてるから何かと思ったら、Dirty bit (書き込まれると立つ)とAccessed bit(読み書きで立つ)でした。そういえばDOS Extenderでは使って無さそうだから対応してなかった！

しかし、これ対応しようと思ったらメモリアクセスするたびにフラグ立てなきゃならなくなって、(ただでさえ遅いと言われてる津軽なのに)Townsアプリの実行スピードに影響が出ると思ったので、これはビルドするときにマクロ定義かなんかで対応するとして、Windows 3.1を動かしてみたい人は各自ビルドしてもらう方向にしようかな。

それにこのフラグに対応してもまだ起動までこぎつけるかどうかは不明だし。

2022-04-01 22:53:14

CMOSの件だけでも長くなる可能性があるかと思ったのでスレッド作りました。YSSCSICD.SYS開発時、津軽開発時に調べたメモに残ってるのが、

CMOS RAM
起動デバイス
[3182H] 起動デバイス種類が (Floppy:1 Harddisk:2)
[3184H] 起動デバイスユニット番号
MX ROMの逆アセンブルでも確認。2020/05/20参照。

臨時起動デバイス
[3C28H]
MX ROMの逆アセンブルによると、パッドAボタンを押して起動すると08H (AL=08,AH=00 に分解されてCD-ROM), Bボタンで 02H (AL=02,AH=00に分解されてFD0)

シングルドライブモード(多分)
[328CH] 0:解除 1:シングルドライブモード -> [33CEH]がこのバイトを含むチェックサムになってるみたい

ドライブレターをどうやったら割り当てられるのか調べてます。

2020-10-01 23:31:01

Zoomミーティング中暇だったので(不良研究員)調べました。comp_romのソースではCMOSの後半にチェックサムがあるということですが、どうもドライブレターとかシングルドライブモードが書いてある領域は、33CEHを使ってチェックサムが変わらないように調節しているようです。そういえば津軽初期のころは、なんとかシングルドライブモードの意味を解明して津軽初回起動時のCMOSの初期化はSYSROMにさせてホスト側でシングルドライブモードを解除させようと思ってたけど、このチェックサムの意味がわからなくて断念したんだよな。今ならわかる気がする。

ちなみに、ドライブレターの割り当てですが、割り当て後、31D0～31DAに「富士通」が書き込まれます。が、これは多分いつも一定だと思います。(たまたま昨日パーティションテーブルを解析しててこれと同じ文字列をチェックしていたのでわかった。すごい偶然。)

IO8:[31D0] 95 <- SJISで「富士通」
IO8:[31D2] 78
IO8:[31D4] 8E
IO8:[31D6] 6D
IO8:[31D8] 92
IO8:[31DA] CA

それで、ドライブレター割り当てですが、以下のようになっているようです。33CEHはシングルドライブモードの変更でも値が変わって、それ以外が増加した分減らして全体のサムが変わらないように調節しているように見えます。

ということで、これをもとにHD Image用ブートローダーにCMOS設定機能を追加してみます! 実現すれば津軽またはUNZ上で作ったHDイメージとSCSI仮想化ツールだけあればCMOSが死んだ状態から起動可能まで持っていけるはずです！

。。。。今日と明日はミーティングが山のようにあるんだよな。さすがにミーティング中にMASMプログラミングはできんから週末の作業だな。

IO8:[31DC] 00 <- 多分Aドライブ
IO8:[31DE] 00
IO8:[31E0] 00 <- 多分Bドライブ
IO8:[31E2] 01
IO8:[31E4] 05 <- 多分Cドライブ
IO8:[31E6] 00
IO8:[31E8] 02 <- ここが変わった (割り当て前FF)
IO8:[31EA] 00 <- ここが変わった (割り当て前FF) 上位4ビットがSCSI ID, 下位4ビットがパーティションぽい
IO8:[31EC] FF
IO8:[31EE] FF
IO8:[31F0] FF
IO8:[31F2] FF
IO8:[31F4] FF
IO8:[31F6] FF
IO8:[31F8] FF
IO8:[31FA] FF
IO8:[31FC] FF
IO8:[31FE] FF
IO8:[3200] FF
IO8:[3202] FF
IO8:[3204] FF
IO8:[3206] FF
IO8:[3208] FF
IO8:[320A] FF
IO8:[320C] FF
IO8:[320E] FF
IO8:[3210] FF
IO8:[3212] FF
IO8:[3214] FF
IO8:[3216] FF
IO8:[3218] FF <- 多分Pドライブ
IO8:[321A] FF

IO8:[33CE] 45 <- ここも変わった。↑で増えた分減ってるっぽい。多分チェックサム一定化調整。

2020-10-02 00:32:27

随分と前のことですが、モデル2のブートロムを追っかけたことが有って、その時に作成した使用CMOSの資料が有りました。
何分素人が逆アセして目で追いながら作成した資料ですので、間違っている部分も多いとは思いますが役に立てばと思い此処に書き込んでみます。

3180 ?(bit0をチェックしている)
3182 ?
3184 ?(3182とセットで使用 3184→AH,3182→AL)
318E ?(ジャンプテーブル?のベース)disk_command_04
3190 ?(上記テーブルで使用? 3198まで?)
3192 ?
3194 ?
3196 ?
3198 ?
319A ?(読んだあと、and al,0CFh xor cl,al jzと続く)
319C SS(現在のSS:SP)
319E SS
31A0 SP
31A2 SP
31A4 SI
31A6 SI
31A8 SP(ローカルSP)
31AA SP
31AC ?
31AE ?
31B0 ?
31B2 ?(起動時にクリアされる)
31B8 ?(起動時にクリアされる)
31BE ?
31CC ?
3A50～3A5A ?
3A64 ?SP(割り込み処理で使用)
3A66 ?SP
3A68 ?SS
3A6A ?SS
3A6C ?(MasterPIC IMR)
3A6E ?(SlavePIC IMR)
3A70 ?(割り込み要因レジスタの値)
3A98 ?
3B50 ?
3B60～3B6E CD_CMOS_PARA
3B70 CD_CMOS_DATA0
3B72 CD_CMOS_DATA1
3B74 CD_CMOS_DATA2
3B76 ?
3B78 CD-CMOS_DATA3
3B7A ?
3B7C ?
3B7E ?
3C22 ?
3C24 起動時のDX
3C26 起動時のDX
3FC6 ?
3FC8 ?

2020-10-02 11:09:53

ああ、ごめんなさい。
上の資料は元々モデル2で逆アセしてたのですが、途中でHCになったので混在している可能性が有ります。

2020-10-02 11:11:43

たまにはこっちにも書いてみます(?)

TownsOSや起動時の処理に影響するCMOSの内容を、既知の物も含め2点あげておきます。

3C1A 起動時メモリ診断モード(0=通常モード、1=簡略化モード) 3代目あたりから有効
3AD8 各種フラグ (bit7が1の場合、高解像度モードモードON) ハイレゾ機で有効(とはいっても起動時に参照するわけではない)

2020-11-07 12:31:39

SCSIのPhaseのMESSAGE_INとSTATUSの順を入れ替えたら、とりあえずSCSIのエラーは出なくなりました。
が、HIMEM.SYSインストール中に割り込みハンドラを破壊という現象が起きていて原因を調査中です。
なお、デバッガで BRKON INT 21 AH=3D としておくとfile openで止まるので、pri cst するとどのファイルを開くとこかわかるようになってます。

2020-07-28 12:59:54

VERR/VERWありがとうございます。VERRを通過して、CLTS（0Fh 06h）で死亡しました。T-OSはなぜタスク機能を使ってるのか……。
お盆あんまり関係ないんですよね。まとまった時間取れれば集中してドライバ書いてたいのですが。

2020-08-14 21:33:10

CLTS実装ありがとうございます。TBIOSLD.SYSとTOWNS.SYSを組み込んだ状態で起動するようになりました。
ですが、COCO で forrbios.nsd を組み込むとコードでない場所（V86モード）を実行して止まるようです。
（COCOを組み込まなくても適当なEXPを起動してると同じようなところで停止。同条件でEMM386を組み込まない場合は問題なし。）

なんとなく根が深そうなので、お時間あるときに見ていただけら嬉しいです。

2020-08-15 15:15:40

あらぬ場所にジャンプしてしまう現象は、考えられる可能性として高いのは、
(1) Exceptionを正しく出してない。
(2) Exceptionの出し方が正しくない。
(3) Task Gateを使ってジャンプしている。
(4) CPUコアに未発見のエラーがある。
と、このぐらいだと思います。多分、(1)だと思うんですね。なんとか環境を作って調べられないか検討してみます。

2020-08-16 02:51:32

>>40
TOWNS-OS on DOS6環境を作るには、DOS6をインストールしたHDD区画に対して、TOWNS-OS V2.1L40以降のシステムCDを起動して、アイコンから新規インストール先として指定すれば、DOS6上にTOWNS-OSがインストールされます。

これで128MB超えのHDD区画もバッチリ認識……じゃなかった。これで上に書いた問題も再現します（V2.1L50にて確認）。

2020-08-17 18:16:55

了解しました！詰まったら、多分実家から回収してきたFM Townsシステムセットアップガイドを見ながらなんとかできると思います。（一応共著者に名前入ってるけどDOS6の部分は全部武井先生が書いた）。やってみます！

2020-08-19 05:36:29

状況再現しました。クラッシュは↓ですね？

3FF8:000014E1 FFFF

この直前がIRETDで、NT=1となっているので、どうやらTask Returnというのを実装しなくてはならないらしいです。戻ってくるアドレス自体は正しいのですが、素直にStack ReturnsしてしまうとVMフラグをクリアしてしまって、3FF8をセレクタと解釈してとんでもないリニアアドレスだと思っているようです。

想像なのですが、ここはRUN386の中のようで、このTask Returnした先でVMフラグをクリアして3FF8:000014E1に戻してRUN386に続きをさせるということではないかと見ています。

どのぐらい簡単か難しいかまだわからないので、ちょっと勉強してみます。

2020-08-19 08:45:30

うーん、もはやどれを信じていいのかわからない。i486 Programmer's Reference ManualのPsuedo Codeによると、

(* Protected mode *)
IF VM=1
THEN #GP(0)
ELSE
IF NT=1
THEN GOTO TASK-RETURN

と、あるものの、下の説明では、

#GP(0) fault if the IOPL is less than 3, to permit emulation

しかし、VM86モードのIOPLは3のはずだから、'less than'にはあたらない。ので、Pseudo Codeとテキストの解説が矛盾してます。結構こういう誤記なのか手抜きなのかわからない表記多いんですよね。

ここの記述→では、https://www.felixcloutier.com/x86/iret:iretd

IF(EFLAGS.VM=1)
THEN GOTO RETURN-FROM-VIRTUAL-8086-MODE;
ELSE GOTO PROTECTED-MODE;

RETURN-FROM-VIRTUAL-8086-MODE:
(*Processor is in virtual-8086 mode when IRET is executed and stays in virtual-8086 mode*)

とあり、その説明では普通にNTフラグにかかわらずStack ReturnするがVMビットは影響を受けない。とのこと。しかし、そんなことはi486 Programmer's Reference Manualを見る限りまったく書いてません。POPFDではそういう記述があるんですけどね。VMフラグそのたいくつかのフラグはPOPFDによって変化しないそうです。

それで、Task Returnを調べたところ、TSSにReturn先のTRが書いてなければならないことになってますが、EMM386環境ではタスクはひとつしかなくて、ほかのタスクにリターンしたくてもそもそも戻り先タスクが存在しなさそうです。

一番都合のいい解釈は、VM86モード下のIRETではVMフラグが変わらない以外は基本的に普通のIRETと一緒、とする説なので、そのようにしてみたところ、DOS6上でTowns MENUが起動しました。例によって現在ctestを流しているので、全部通ったらソースをPUSHしますね。

2020-08-19 09:44:41

>44 山川機長さん
もうある意味解決しているのかもしれませんが、INTELのia32_arh_dev_man_vol2a_i.pdfの該当個所を見てみると、

RETURN-FROM-VIRTUAL-8086-MODE:
(* Processor is in virtual-8086 mode when IRET is executed and stays in virtual-8086mode *)
IF IOPL=3 (* Virtual mode: PE=1, VM=1, IOPL=3 *)
THEN IF OperandSize = 32
THEN
IF top 12 bytes of stack not within stack limits THEN #SS(0); FI;
IF instruction pointer not within code segment limits THEN #GP(0); FI;
EIP ← Pop();
CS ← Pop(); (* 32-bit pop, high-order 16 bits discarded *)
EFLAGS ← Pop();
(*VM,IOPL,VIP,and VIF EFLAGS bits are not modified by pop *)

とあります。

2020-09-02 14:39:35

そうですね。とりあえずDOS6を走らすレベルでは解決しましたが、ありがとうございます！一応、i486 Programmer's Reference Manualというのを参考にしていて、Intelの公式出版物のようなのですが、エラーが多いです。Intel公式のSoftware Development Manual (多分ia32_arch_dev_man_vol2a_i.pdfがそれかな?) を参考にする方が良い、と、とある知り合いの方から教えていただいたので今後はそのようにしようかと思ってます。

2020-09-03 05:33:45