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

2020-07-28 13:17:50

テストありがとうございます！既にStreet Fighter 2のノイズ問題は解決していたんですね。ちなみに、格闘ゲームは「Iron Fist」とプレステで「鉄拳」をやった以外の経験が無いので、Muscle BomberとStreet Fighter 2はまったくクリア確認できる気配がありません。というか決定的に記憶力に自信が無いもので、技のレバーとボタンのコンビネーションをぜんぜん覚えられないんですね。

Fate of Atlantisは、とりあえずプレイは可能なレベルでしょうか? 雰囲気的に、マウス座標を直接読まずにマウス移動量を見ているのではないか、という印象ですね。

ここ数週間で結構タイミング問題とか直したので、シャーロックホームズの探偵講座の動画の音が変になる現象も直っていないか？と、思ったのですが、こっちは直ってませんでした。

今からテストを流すので、全部通ったら後程リリースを更新します。

2021-07-22 07:18:09

>>187 WINDYさん
よく見てみると、下端だけではなく上端でも吸い付きますね。
下端は吸い付いてズレる、上端は吸い付いてズレが直ります。

>>197 山川機長
Fate of Atlantisですが、ズレ幅も小さいですし直すことも出来るのでプレイ可能なレベルだと思います。

2021-07-24 13:04:35

>>197 山川機長さん
>>198 fuzzballさん

IndianaJonesに関してはLastCrusadeでは画面上部のみ,Fate of Atlantisに関しては画面上下でマウスが吸いつく様な動作です。
Fate of Atlantisに関してはずれを治す方法が有るのですが、LastCrusadeでは一度ずれると治す方法が無いのでずれたままとなりますがプレイに支障が出る物でもありません。

2021-07-28 09:29:57

>>199 WINDYさん
Last Crusadeをv20210721で試してみたところ、上端は吸い付いてズレる、下端は吸い付いて直る、となりました。
Fate of Atlantisとは逆ですが直すことは可能でした。
あと、カーソルが左端まで行かないのは元々の仕様でしょうかね？

2021-07-30 23:49:39

>>200 fuzzballさん
私もv20210721で試しているのですが、下端には吸いつかないです。 何が違うんだろ?
カーソルが左端まで行かないのは実機でも同様です。(今まで気づきませんでした)

2021-07-31 12:34:03

>>201 WINDYさん
うーん、なんでしょうね。
下端というのは、絵が表示されているエリアの下端ではなく画面全体の下端ですが、間違いないでしょうか？
念のためのスクショ https://postimg.cc/bZ7R8BDf

エミュはRelease版のCUIをそのまま使っています。オプションは -KEYBOARD TRANS のみです。
CDから起動しているのでT-OSはV1.1L20です。

この前別件で、v20210716を使っているつもりがv20200716を使っていて悩んでいたことがありましたがｗ

2021-07-31 14:25:57

> 192 山川機長さん

v20210721でオペレーションウルフをコンティニューしながら4周クリアまでやってみましたが、音声の不具合は出ず快適に遊べました。
(前回ブログで3周クリアと書きましたが、4周クリアの間違いです)

https://nas-serizawa.at.webry.info/202107/article_5.html

前版までの津軽だと、私の環境では音声の不具合は100％出てました。対処ありがとうございます。
これまで不具合が出ていた音声ですが、MENU「MUSIC TEST」のSOUNDを聞く所で確認したところ、28番の音声っぽいです。
v20210716で28番を再生したら、鳴りやまなくなりました。
v20210721だとちゃんと一発だけ音がします。

2021-07-31 16:39:08

>>202 fuzzballさん
判明しました。 GUIで試していたのですが、fuzzballさんのスクショを見たら下側のウィンドウが自分のよりもやや大きい事が気になって、ウィンドウサイズをグラブして下側に大きくするとマウスカーソルが下側に吸いつきました。

2021-08-01 11:08:08

>>204 WINDYさん
原因が分かってスッキリしました。CUIでもちょっとだけウィンドウを小さくするとWINDYさんと同じ症状になりました。
GUIで起動したときのウィンドウがちょっと小さいようですね。下部のステータスエリアの高さが考慮されてないのかも。

2021-08-01 18:50:27

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

では、手始めに私の困ったことから。
我が家の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

TOWNS用DOOMの記事がGIGAZINEに出てましたね！

https://gigazine.net/news/20210711-doom-fm-towns/

DemosplashのRetro Gaming Room、春のRetro Gaming Nightでは必ず一台DOOMを走らせるようにします！

2021-07-12 08:01:42

なお、せっかくDOOMを移植していただいたので、Wikiの動作確認リストに追加したいと思いますが、津軽は動作ランクA、うんづではノイズが乗るということなのでランクBという感じでしょうか？ノイズも気にならない程度であればAランクとして良い感じでしょうか？

2021-07-18 11:08:53

>256 山川機長さん

私自身は実機では試せていないのですが、うんづで試した限りではノイズに関してはさほど気にならなかったのでAで構わないのではないかと思います。
皆さんはいかがでしょう? ご意見を頂ければ助かります。

※動作確認表の動作ランクについては測定する事も出来ないので記載された方の感覚で入力していただいて構わないと思います。

2021-07-18 16:45:04

了解しました！では、津軽、うんずともにAランクということで、動作確認リストに追加させていただきました！

2021-07-18 22:53:41

Defenderのソースが公開されたんですね。たしか、FM TOWNSフォーラムにTOWNSに移植したものが一瞬アップロードされたことがあったと思いましたが。

https://github.com/mwenge/defender

これって6809なんですね。FM77AVに移植できんかなあ、と、思ってソースコードを読み始めてしまいましたが、そんなことを始めたらまた恐るべき時間を楽しいことに浪費してしまう、と、思って封印しましたが。

2021-07-23 03:32:25

>>259 山川機長
Defenderありましたね。出来が良かった覚えがあるのですが、どうだったでしょうか。
以前、フリコレに入っていないかと探したことがあるのですが、試作品のような（ちょっとした技術検証程度の）ものしか見つかりませんでした。同じ作者ではないかも知れませんが。
解像度が292x240のようなので、FM77AVへの移植は手間が掛かりそうですね。

2021-07-24 12:42:56

Defenderの後にDARIUSの自機のデモも有りましたね。両方とも非常に良くできていましたが、版権絡みの問題で早急に取り下げられたのではないかと記憶しています。

元BeOS, 現HAIKUがベータ3だそうですね、TownsOSにも夢が欲しいなぁと考えてしまいます。

https://www.haiku-os.org/get-haiku/r1beta3/release-notes/

2021-07-27 11:33:09

ちなみに、3次元グラフィックスライブラリを作ってたころちょうどパトレイバーの劇場版が公開で、二次元の回転ぐらい簡単に作ってやるぜ！と思って「篠原HOSの起動画面」を作ってTOWNSフォーラムに上げたことがありましたが、TOWNSフォーラムから取り下げにはならなかったのですが、フリコレには没になりましたね。あのソースもまだどこかにとってあったかな？

2021-07-29 03:16:18

>>262 山川機長さん

そう言うお遊びは大好物です。互換ROMの起動画面に・・・・(以下自粛)

2021-07-29 07:55:06

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

2020-07-28 12:41:40

すみません、GUIはバッチでテストを仕掛けのが面倒なもので、Profileのセーブとロードの確認を忘れてました。GUIの方も複雑になってきたので、もう少しユニットテストとか考えた方がいいですね。

ソースをPUSHする前には一応ユニットテストを走らすようにしているのですが、GUI関係はすべてのパターンをテストできないので、試してエラーを報告していただけると非常にありがたいです。

なお、ソース修正したものをPUSHしました。

2021-06-20 06:55:47

山川機長殿

212の書き込みを拝見して、
GITを使用してプロジェクトに参加されている方が
結合テストくらいはしていることを前提とした
ソース管理システムな印象を受けました。

どのタイミングでソースファイルを取得しても
問題ないことを前提としているようですので。

新規開発のプロジェクト初期には
使いづらそうです。

2021-06-20 07:55:24

ヘルムートさん、

昨日の問題はプロファイルのセーブとロードを自動テストに含めていれば検出できたはずなので、追加しました。新しい機能を追加したときなどはクラッシュ予防になると思います。

津軽の開発体制はあまり製品開発の参考にはならないと思います。Githubも有料アカウントだともっとできることが多いのですが、現在津軽はすべて無料アカウントでやっているので、結構な制限を受けています。本来であれば、GithubにPUSHするたびに自動的にコンパイルテストが走って、ユニットテストが走ってエラーがあったら通知が来るようにしておくと良いのですが、コンパイルテストしか自動化していません。

仮に有料アカウントを使ってテストなど自動化を進めたとしても、GUIのデバッグは難しいですね。製品の開発であればテスターさんを雇うところなのだと思いますが、この点は、ユーザの皆さまからのレポートが頼りです。また気が付いたことがありましたら、ご報告をよろしくお願いします。

2021-06-20 10:58:16

ありがとうございました(^^)/

2021-06-20 11:22:17

山川機長殿

ソフトの修正とGITに関する助言くださりありがとうございます。
GITについては早速調べてみます。

モジュールのテストはどこまで自動化できるんでしょうね。
単体や結合をソースを見て、自動でテスト条件を設定して、テストしてくれるAIができたら
晴耕雨読の生活になるかもしれません。

あまり助力になりませんが、書き込みいたしますのでよろしくお願いいたします。

2021-06-20 16:47:00

新バージョン(6/24)を使用しての要望です。
1点目はHot Keysタブ内のQuick State-Save File Name:の指定で
ファイルがない場合もパスが有効ならOKとできないでしょうか。

報告事項としては、Separate Processが有効な場合は、
Virtual Machineを起動してPower Offすると、Hot Keysなどのメニューを表示できない現象は
現バージョンでも発生しています。

よろしくお願いいたします。

2021-06-27 11:09:12

将来に向けた要望2点(回避策あり)
Quick State-Save File Nameをゲームプレイ中に
変更できるようにメニュー表示の調整願えないでしょうか

現状は、State(S)メニューからのセーブで対応できます。

ゲームプレイ中にScroll Rockキーを押下し、
Power Offした際、表示されるウィンドウサイズが小さく、HotKeysなどが表示されません。
可変ウィンドウサイズに設定くださっているので、問題はありませんが、
起動時と同じウィンドウサイズにされてはいかがでしょうか。

御多忙のところ要望ばかりですが、よろしくお願いします。

2021-06-27 11:24:07

ご報告ありがとうございます。

えーと、Quick State Saveのファイル名指定が無い場合というのは、ファイルダイアログですね。あれ？指定できなかったかな？Openモードでファイルダイアログを開いてしまってたかもしれないですね。確認してみます。プレイ中のファイル名変更は簡単なのでそれは対応しましょう。

Separate Processで起動した場合のダイアログは、リリースにする前に確認するのを忘れてました。確認してみます。

2021-06-27 11:51:09

こんな感じの設定になるのでしょうか。
SaveFileDialog.CheckFileExists = false;

2021-06-27 17:36:21

スレッド分けました。内蔵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

ご報告ありがとうございます！多分初期化さえできればあとのコマンドは同じだと思うので、初期化のタイミングが何か違うのかもしれませんね。あるいは、デバイスの種類の判別で想定しない値が返っているのかもしれません。ヤマハのドライブは残念な結果でしたが、他のドライブではまずまずの結果でしょうか。

2021-06-13 08:54:15

>>83 nanさん
なんとYAMAHAは起動しませんでしたか。自分のはYAMAHAのドライブでした。参考になります。

2021-06-17 22:25:33

>Type.dさん
Panasonic KXL-RW10AN-S、ポータブルですが騒音も静かで使いやすいです。
今はこれをメインに使っています。
PLEXSTORは騒音の面でちとうるさいです。
YAMAHAは繋いでいないので全ての確認ができていません。

2021-06-19 04:52:58

PanasonicのCD-R/RWドライブで朗報があります。
PLEXTORとI-O DATAはハングアップしてTownsがSCSI-0から起動しませんでしたが、
PanasonicとMOドライブをONにしてHRを起動するとMOドライブが生き返りました。
同様をブートローダーで試すとSCSI CDがWAITのままで起動せず。
Towns HRでMO起動を試したかったのですがそれは無理でした。
そこで、Towns OS V2.1 L10はV2.1 L51を立ち上げてからMOにインストールしました。
しかし、メモリ不足でMOのV2.1L10の再起動(REIPL)はできません。
やりたかったことはできませんでしたが、Windows機とMacBook Proとのデータの受け渡しはMO DISKで可能になりました。

2021-06-19 07:21:02

nanさん
SCSI機器は同時に繋いでるドライブの種類や電源のON/OFFによって相性のようなものが発生する上に、変換アダプタを挟むだけでも影響が出るので結構な作業ですよね。調査お疲れ様です。

2021-06-19 23:54:27

>87 nanさん
TOWNS OSをMOにインストール後、メモリ不足で再起動は出来なかったとの事ですが、DOSのエラーが発生したのでしょうか?
V2.1 L51で起動後に、V2.1 L10をMOにインストールされたのは何故でしょう? V2.1 L51をMOにインストールしては駄目だったのでしょうか? この辺りのバージョンの違いや手順の違いで上記のメモリ不足が発生しているのではないかとも思うのですが・・・ (私自身は上記のように起動時とは違う版をHDDなりMOにインストールした事は無いので経験は有りません)

TONWS/FMRの場合、MOの取り扱いについてはリムーバブルとするかどうかで起動ドライブに指定できるか(OSのインストール先として指定できるかだったかも)が決められると記憶していますので、起動に使用する場合はMOドラブ側でDIP SW等で切り換えてやる必要が有ったと記憶しているのですが、違いましたっけ?

2021-06-21 09:51:17

>WINDYさん
ご指摘ありがとうございます。
Panasonic CDドライブと MOドライブがONの状態の時だけ
MOドライブが使えたので試してみたのです。
Towns OS V2.1 L51のCD-ROMは起動しますが、HDインストールでMOに書き込めません。
書き込み時にMOのエラーが出てきて続行できません。
唯一、V2.1 L10のみSCSI HDDで起動して、Qドライブからインストールできましたので
MOの再起動を試みました。
起動しようとするのですが、メモリ不足、EMS、またはHMMを解除してくださいと出ます。
KドライブにはDOS V6.2とWindows3.1がインストールしてあります。

また、MO[MOS-640]にDIP-SWはついていません。
９０年代は MOにインストールしていました。
DIP-SWはついていなかったように思います。

2021-06-21 11:46:55

MOの起動はHDDモードで初期化してあれば起動するようですね。

また、CD-Rに
CDSDMINI.SYS
CDISC2.SYS
ASPIFM.SYS
が書き込んでありました。
使い方はすっかり忘れております。今はもう必要ありませんですよね。

2021-06-22 06:25:00

>91 nanさん
記憶では、MOをリムーバブルメディアとして認識させるのにはセミIBMフォーマットでフォーマットする必要が有ったと思います。
それ以外、DOSやT-OSでの区画設定とフォーマットで認識させた場合はHDDと同じ論理フォーマットとなったと思います。 すっかり忘れているので実機で試すのが一番ですが、我が家のMOは生きているのだろうか・・・

CDSDMINI.SYSやCDISC2.SYSは、YSSCSICD.SYSで置き換える事を目標に山川機長さんが開発されている物ですが、何かの役には立つと思います。

2021-06-22 09:11:23

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

2020-09-24 09:40:33

リリース出しました！Super大戦略のオープニングはほとんど本物になったと思います！

悦に入って何度も聞いてしまいました。

2020-12-18 13:27:08

エンベロープを実機に近づけようと、実機MXを使ってDecay期間だけ音がなるようにして音の長さを計測していますが、実に興味深いですね。FM TOWNS Technical Databookの208ページの表は、まず「レート」のコラムが二つに分かれている意味がなくて(右半分がKCだと仮定してもKCは31段階)、レート0の場合は無限大になるのですが、何も書かずに省略してますね。この表、同じものをYAMAHAのYM2612じゃないチップのマニュアルで見かけたと思ったのですが、どこで見たのか思い出せずにいます。実測値と比べると208ページのdecay/sustain/releaseの時間は1割程度短い(速い)ですね。とりあえず、津軽弁は実測値ベースに修正しようと思います。

あと残っているのはAttack期間の計算とKCの最下位ビットの計算方法ですね。AttackはDecayでガクンと急激に落ちるようにパラメータを工夫してサンプルすれば長さを測れるし、KCはKS=3として実測を取ると解明できると思います。エンベロープを実測ベースにしたら、ほぼ本物を再現できるようになるのではないか、と、思います。あと、エンベロープを明示的に計算する方法をドキュメントできれば後世の誰かがYMチップを再現しようとするときに使えると思います。

しかしFM TOWNS Technical Databookは結構誤植や間違いとかあって、エミュレータ作りながら「まじかよ」と思ったことが何度もありましたが、10%の誤差があるとしてもYM2612のフェーズの長さの表を出していてくれたのは助かりました。それに10%だからそんな大きな誤差じゃないですね。ところどころで「おお、これは！」と思う情報が出てますよね。

引き続き精進します。

2020-12-20 00:51:51

ソースPUSHしました。今日は朝から実機でいろいろ設定を変えてトーンをサンプルして正しいattack/decay/sustain/releaseの時間を計測して、また、謎だったNOTEの計算方法も多分解明しました。YM2608公式マニュアル(YM2612と基本互換のはず)とFM TOWNS Technical Databookには、

N3=F11*(F10+F9+F8)+~F11*F10*F9*F8

と、あるのですが、多分F11がビット10なのはわかるとして(F_NUMBERは11ビットだからビット11は存在しない)、どうやら正しくはこうですね↓

N3=F11*(F10+F9+F8)

F_NUMBERをいろいろ変えてDecayにかかる時間を計測したのですが、F11がゼロのときは、続く3ビットを変えても時間に変化はありませんでした。具体的にどういうエンベロープになるのか、これで解明できたと思います。

多分津軽が出してくるエンベロープもかなり実測と合うようになったと思います。(が、ソースの中のテーブルその他は実測に合わせたつもりだけどまだ津軽弁出力と実測と波形比べてない)。

2020-12-20 06:38:29

ちょっと実機でスプライトの動作をみてみました。
こういう感じのようです。
https://imgur.com/a/6GVk68S

- SPEN: スプライトレジスタの1番にあるもの
- DP1: スプライトレジスタの6番にあるもの
- SPD0, PAGE: はI/Oポート044Chのもの
- display: CRTCのFA1は0として、スクリーン1の前半が表示されている場合は0、後半が表示されている場合は1

VSYNC:
- I/OポートFDA0hのVSYNCビットが0から1に変化するタイミング、すなわち垂直帰線区間に入った時
- （赤本のスプライトBIOSのところにはVSYNC終了のタイミングから画面消去・転送が始まるように書いてありますが…）
- VSYNCのアークがない状態ではこのタイミングで何も起きない
Finish:
- スプライトの転送が終了したとき

I/OポートFF82hのPS2ビットと同様に、SPEN/DP1による表示領域の切り替えは表示期間中にも起こりうるので、
スプライトコントローラを画面消去に使うソフトの対策は手間がかかりますね

2021-02-15 00:33:29

フリコレ11の「股を愛したいですねぇ」( \T_OS\DEMO\MOTPLAY )を津軽で動かすための調査の続きです

SPD1とPAGEレジスタの値を実機同様にVSYNCで変えてやると、とりあえずアニメーションが進むようになります
SPEN、描画、FA1の変更を観察すると、こんな感じのようです
https://imgur.com/a/sptRolL
- 上段: 改造した津軽がプログラムに提示するるポートの状態
- 中段: motplay.exp の動作
- 下段: 表示状態の推測
- w/o FA1: >>33 の観察結果に基づいたFA1の影響を加味しない表示ページ
- Display: FA1(0000 or 8000 が設定される)の影響を加味した実際に表示されると思われるページ

描画ピクセル数自体はそこまで多くないので高速なTOWNSだと1INTで描いているのに2INTの表示になってしまいそうですが、これはまた実機で試してみます

2021-02-22 03:05:17

pinさん、

Pull Requestありがとうございました。

なお、最新版ソースですが、シンボルテーブルの検索機能が増えました。今まで pri sym または dm sym で全部ドドーっと出てましたが、新しいやつをコンパイルすると、symfind (wildcard)で検索できたり、sym SEG で特定セグメントのシンボルが表示できたり、symproc/symlabelを使うと、プロシージャのみ、ジャンプラベル＋プロシージャのみの表示ができて、いずれもセグメント指定できます。よかったらご活用ください。

自作MSDOS.SYSは、FAT12/FAT16のクラスタ取得とバッファリングを自作プロシージャで置き換えに成功しました。CHARデバイスからの読み込みをひとまず無視すれば、FREADもなんとかなそうです。FOPENだと今度はまたディレクトリ探したりいろいろ解析し甲斐がありそうですが。しかし、CDドライブとROMドライブのみ対応版だったら案外早くできるかもしれない、そこまでできたらフォントROM空にしてもFractal Engineとか動くかもしれないという気になってきてます。MASMで書いてますが、うーん、しかし最近だとNASMにした方がいいのかな。でもシンタックス良く知らないし書き換えるの面倒だし。

2021-02-22 09:37:28

>>35
元々、MASM（や386|ASM）で書いててNASMに移行した経験から言うと、NASMに移行したほうが相当楽に書けると思います。コード部はほとんど一緒ですし、MASMですとCPUコード以外の部分が面倒くさくてしょうがないです。あとNASMのマクロ便利。

2021-02-23 01:32:46

FREAD (INT 21H AH=3FH)を独自コードに置き換えることができました。CHARデバイスからfreadしようとするととりあえず止まるようにしてあるのですが、あまり使ってる場面なさそうです。試しにリダイレクトとか使ってみたけどその部分に入ってこないし。

> [email protected]さん、

なるほど！NASMにするとDOSBox を使わずにアセンブルできるのが楽そうなんですよね。アセンブルしてMSDOS.SYSと混ぜて津軽起動するまでが一本のScriptでできるようになるし。FMT_SYSの方は既にNASMだし。確かに、それほど大きな書き換えせずに移行できそうな感じもしますね。一念発起して移行してみようかな。

2021-02-25 02:28:39

"そう言えばTOWNS用のNASMが有ったなあ"と思い出しました。

頭脳圧搾工場 in 仙台さんの所でまだ公開されているようですね、PharLap簡易OMF-386オブジェクトフォーマット出力に対応しているので今後EXPファイルを作る際に役立つかもしれませんね。

2021-03-11 15:53:35

現在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

その後、どうやらクラッシュしてるのはWIN386.EXEが起動に失敗してDOSに戻ろうとする途中のような気がしてきました。なにやらPage Faultが起きてるんですね。そして、そのハンドラの中で同じ場所に突っ込んでPage Faultが起きて、それをハンドルしようとしたところでどうやらあきらめてDOSに戻る途中三度目同じところに突っ込んで、三度目はIDTがEMM386のIDTに書き換わっているようで対応しきれなくてクラッシュ、みたいな感じです。そのPage Faultは000C8000～のFM-R VRAMにアクセスしようとして発生しているので、その領域にアクセスしようとしたらPage Faultになること自体は正しいっぽいのですが、多分、その領域にアクセスするパスに入ってくるべきではなさそうです。

それで、WIN386.EXE （DOS6もだけど)の中で、RETFをCALLFとかJMPFとして使ってる個所がたくさんあって、コールスタックがめちゃくちゃになってしまうんですね。ということで、シンボルに情報としてJMPF_BY_RETF, CALLF_BY_RETFを記録してそこに突入したら適宜コールスタックの更新の仕方を変えてデバッガで流れが見やすくするところから始めようと思ってます。先は長そうですね。IRET_TO_VM86 （Stack Return to Virtual 86）は考えてみたら検出可能なので対応したのですが。

2021-01-23 02:25:01

↑の問題は、Page FaultでCR2にリニアアドレスを入れてないという問題でした。それを直して、今は、INT 31Hが出てるのですが、対応するIDTのエントリが壊れているらしい (80286の16-bit Trap Gateだと思ってる) というとこですね。一応、今Unit Testを流してるので、通ったらそのバージョンのソースをPUSHする予定です。

2021-01-24 07:51:07

異なるPrivilege間のINT/IRETは同じPrivilege間のINT/IRETと微妙に動作が違うことに気が付いて実装したら↑の個所は通過したんですが、INT 31H AX=0602H (Mark Real Mode Region as Pageable)の中で戻るべきリニアアドレスのページテーブルエントリのPresentビットを0にしてしまって、IRETでPage Faultになってるところで止まってます。ひょっとするとこれが正しい動作でPage Faultを出すべきなのかもしれないんですがね、ただ、そこらじゅうでPage Faultのチェックを始めるとCPUコアが明らかに遅くなることが想定されるので、やるならIRETで抜けるところでチェックかと思ってるのですが、しかしここでPage Faultを起こすのも何か変な気がするので現在 INT 31H AX=0602H の中身を見てます。いやな予感としては、メモリを十分搭載していればPage FaultでSwapは起こらないだろうとみていたのですが、V86モードのかたまりのWindows 3.1だとPage Fault起こしまくりでリアルモードメモリをスワップしてたりして。それだと、それに対応するためにTownsオリジナルアプリの動作を遅くするぐらいならWindows 3.1は対応しない方がいいかもしれないですね。ある程度はFractal Engineのために対応してはいるのですが。

2021-01-30 02:36:21

山川機長さんのお気持ちとしては、"FMTOWNSで動作していたソフトウェアは全て動作する"を目指されているのだと思うのですが、状況を見ていると仰る通りTOWNSオリジナルアプリの動作が遅くならない方法が見つかるまではWINDOWS3.1を先送りしても良いように思います。
幸いにしてTOWNSでWINDOWS3.1を動かさないとならない人もかなり少ないでしょうし、実際の所はWINDOWS3.1に対応してもインストールする人は(ほぼ?)いらっしゃらない物とも思われます。(個人的には、WINDOWS3.1<Linux<WINDOWS95の順のような気がします)

それにしても、WINDOWS3.1って相当アクロバティックな作りなんですね・・・

2021-02-01 15:27:12

まさにその通りで、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

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

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

2020-07-28 13:20:43

FMTowns新エミュレータ emufmtownsの情報交換用スレッドです

2020-07-28 12:45:08