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

2020-07-28 13:17:50

＞WINDYさん
上のコメントを書いた後にOh!FM TOWNSの該当記事の断片が上がったので自分なりに解釈すると、
・CRTCのレジスタFA0,FA1やTBIOSでのVRAMの表示位置指定では65536(16ビット)通りしかなく、画面画素数よりも少なくて最小でも2ドット単位でしかスクロール位置を指定できない。
・が、HAJ0,HAJ1でドットクロックを微調整出来てレジスタの値を増減させると、ハイスキャン時0.5ドット、ロースキャン時0.25ドット、インターレース時0.2ドット分ズレて表示されるので1ドット、更に少なくすれば0.2～0.5も行える。
という原理のようでした。

ランザイバーじゃないけど、横1ドット単位でスクロールできているタイトルを見ればある程度分かるのか。

2022-01-14 11:11:13

最新版のソースで、-APP DAIKOUKAI とすると、問題の無限再帰バグにパッチを当てて、さらにBusy WaitでなくI/O 6Chでタイミングを取るようにして、ダイアログ位置を書いてある箇所を特定したので、なんでもすべてマウスで操作しなくてはならない(特にYes/Noのためにいちいちクリックするとか方向の変更と数字入力が苦痛)問題を津軽のイベントログ機能を使ってショートカットキーで操作できるようにして、二日がかりでもう一度最初から最後まで通してプレイできることを確認しました！もしも、あまりの操作性の悪さに当時挫折した人(の中で最近の復刻版をプレイしてない人)には快適にプレイしていただけると思います！当時心残りだったゲームがもう一本クリアできてよかったです。

まだもうひとつの無限ループに陥ったパターンのパッチは難しく、それは直せないのですが、ただ、これは宝探しの依頼が来た時、まだ仲間になっていない登場人物合計3人を経由する必要があり、その3人を探そうとするものの見つからなくて永遠に探し続けているようです。ただ、二度目の通しプレイではこの無限ループにはヒットしませんでした。最初に通しプレイしたときは、イスパニアの同盟港をどんどん取ってしまって、イスパニア艦隊から付け狙われて、仕方なく撃破していた関係で生存してる人が足りなくなったのかもしれません。そう思ったので2度目の通しプレイは他国の同盟港は手を出さず、海戦は海賊に限ってプレイしました。

ただ、最後に王女様を救出した時点のグラフィックが崩れるんですね。いまだに本来どういう絵だったのかわかりません。それと、最後の決戦後、いったんセーブしてリセットしてロードしないと国王に謁見した時点で先に進まなくなるとか。さきほど実機MXでも試したらやっぱり崩れるんですね。誰か最後までプレイテストしたのだろうかと心配になってしまいました。当時だとプレイテストの方法論とか今に比べてまったくできていなかったので、効果的にバグ出しできなかったのかもしれないですね。

2022-01-16 08:52:28

FISTP対応しました！今テストを流してるので、全部通ったらアップロードします！

G ENFORCERって、木村君の作品じゃないですか！多分青森県立弘前高校の後輩の木村君と同一人物だと思うんですが。彼は元気にしてるかな。

2022-01-18 05:52:50

大航海時代のバグ問題の対処の程有り難うございます、お疲れさまでした。

しかし、これってどういう経緯で入り込んだのでしょうね、元はPC98でリリースされた商品ですし恐らくはC言語で組まれているのでしょうが機種依存部分を除く部分は共通のソースを使用すると思うのですが、PC98版ではそのような事象はWEBを見る限りは無さそうですのでTOWNS版のみのバグのような気もします。
確かにグラフィックの崩れる問題は機種依存部分に近い領域ですのでバグが混入するリスクは高いわけですが、恐らくは共通部分である進行やイベント部分に関してはTOWNS版で新たに追加された要素でも無い限りこの様なバグが入り込む余地が無いような気がしないでも有りません。

何はともあれパッチ当てで全てでは有りませんが重要な不具合を回避できることは有り難いことです。

2022-01-21 09:07:35

大航海時代は逆アセンブルを見たところ明らかにHigh-Cでコンパイルされたようだったので、他機種用で同じバグが出ていないかという点は僕も考えたのですが、TOWNS用にせっかくだから何か改良を加えようと思ってしくじったんですかね。なお、ここに書いた後で結局グラフィックが崩れるバグ、最終決戦後リセットが必要になるバグの原因も究明してパッチが書けてしまいました。別の友達に、演出もBGMもプロットも優れた傑作で、すごく楽しかったけど、プログラミングが学生さんが書いたみたいなレベルだったんだよね、と、話したら、当時は学生のアルバイトがたくさんゲーム書いてたから本当に学生が書いたんじゃない？と言われて、なるほどと思いました。

実は冬休みに2本レトロゲームをプレイしようと思ったので、12月中はFM77AV用「夢幻戦士Valis」をやってたんですが、こっちもマップを抜き出すぐらいにしておこうと思ったのに、結局一大解析作戦になってしまって、結局開発した人に聞くわけにもいかないので真相はわからないのですが実機で実験した結果も踏まえてFM77AV用ValisのAct 6はクリア不能、よってAct 5でワープを使ってAct 6を飛ばす以外にクリアできないという結論になりました。興味がありましたら、http://ysflight.com/FM/Valis/j.html に上げたので御覧ください。

次は夏休みかなあ。当時プレイしてなくて心残りになってるゲームはあるものの、あんまり長くかかりそうなやつは手が出せないんですよね。またWizardry 1,2をやってみたいけど、それを始めたらえらいことになるから老後の楽しみにしようと思ってます。

2022-01-22 02:46:57

はじめまして。
大航海時代は起動FDにEXPファイルが入っていてそこから起動したように思ったのですが、確認しようとしたところFDにカビが生えていました。
クリアしたことがないのでそれが修正版だったかはわかりません。

付属FDが無くても津軽のパッチでクリアできそうなので安心しました。
むしろ大航海時代の記事が凄くて殆ど理解できないながらも興奮気味です。
ありがとうございます。

2022-01-22 15:53:24

aochanさん、

KOEIのゲームはそのパターンが多いみたいですね。KOEI.COMがFD上にEXPがあったらそっちを、無かったらCDのEXPを読み込むように作っているようです。そして、FD上のEXPはバグ修正版であることが多いようです。どのタイトルだったか忘れたのですがFDを入れずに起動すると必ずクラッシュするので調べたらそのようなつくりになっていたものがありました。信長覇王伝だったかな？(うろおぼえ)ただ、大航海時代のFDはデータファイルで半分以上埋まっているのでおそらくFD上にEXPファイルを置く余裕は無かったと思います。

それで、FDにカビとのことですが、100%アイロプロピルアルコールでクリーニングして、もしもNEWGAME.DATだけ復活できればなんとかなるかもしれません。TIZU.DATという640000バイトのファイルが一本入っているのですが用途不明です。綺麗に640000バイトなので、多分無圧縮だと思うので、同じサイズのデータファイルを置けばなんとかなるような気がします。解明した航路図を張って行く前の世界地図のデータではないかと見ているのですが。FDのNEWGAME.DATというファイルがマップデータなど重要なデータファイルとなっているので、このファイルが無いとプレイは不可能と思います。

大航海時代はかなりハマる傑作なので是非再度プレイしてください！

2022-01-23 00:45:28

なるほど、付属FDはゲームプレーに必須でしたか。
カビ取り作業を行いイメージ化のためFDを読み込ませたのですが、半分程度のところで止まり、FDにキズが付いてしまいました。
カビの大きい箇所が２つありましたので達人級でないと復旧は難しかったかもしれませんね。

中に入っているファイル名だけは分かりました。

SAVE.DAT 61,756 #2
TIZU.DAT 640,000 #63
NEWGAME.DAT 70,677 #688
MAIN.EXP 376,570 #758

#は開始クラスタ
MAIN.EXPが修正版かもですが真相は闇の中へ・・・
もう一度洗浄してキズのついた部分以降が読み出せればNEWGAME.DATを取り出せそうな気がしますが、もう少し検討してからチャレンジしてみます。
コーエーテクモゲームスがFDイメージ販売サービスをしてくれたら嬉しいのですけどねぇ。

2022-01-23 17:52:07

おおなんと！FDにmain.expが入っているバージョンがあるとは！こちらのCDに入っているMAIN.EXPは376572バイトなのでサイズが2バイト違いますね。ただ、ゲームをプレイしようと思ったら、MAIN.EXP以外の3本のファイルだけあれば十分のはずです。ディスクにコピープロテクトはかかっていないので、空のディスクイメージを作って、その3本のファイルをディスクイメージに持っていければ大丈夫と思います。

しかし、カビが大きかったということはMAIN.EXPは無事では無さそうですね。惜しい。しかし、とくに最後の艦隊戦後のグラフィックは通してプレイしたなら見ればわかるレベルなので、さすがに直してそうですね。

2022-01-24 01:41:33

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

2020-07-28 12:41:40

スクリーンショットありがとうございました！あ、そうか。同じプロセスにしたからコマンドのエコー出ないんですね。コマンドのエコーが出るように書き換えますんで、少しお待ちください。

とりあえずなのですが、Profileのセーブとロードは普通にできますか？

2021-11-06 23:58:54

Profileのセーブとは、[Files(F)]メニューにある[Save Profile(S)]や[Save as Default]のことでしょうか？
それでしたらセーブは可能です。

Profileのロードとは何を指してるのでしょうか？理解不足で申し訳ありません。

2021-11-07 13:43:02

早速ありがとうございます！それです。

もう一点確認をお願いできますか？VM起動中にメニュー(FD0->Select FD Imageなど)からCDやFDイメージの切り替えはできますか？

2021-11-07 23:32:51

確認しました。

[FD(0)]から[Select FD Image]の切り替えは可能です。
上記操作後、コンソールウィンドウには「VM:Loaded FD image.」と表示されます。
この後、[FD(0)]->[Select FD Image]で、Open FD0 Imageのウィンドウを表示すると、切り替え後のイメージに変わっています。

[CD-ROM(C)]から[Select CD image]の切り替えは不可でした。
上記操作後、コンソールウィンドウには「Loaded Disc Image:(フォルダやファイル名が続く）」と表示されます。
この後、[CD-ROM(C)]->[Select CD Image]で、Open CD0 Imageのウィンドウを表示してもイメージは変わっていません。VM上でも切り替え前のCDイメージが動作し続けます。

2021-11-08 13:58:20

ご確認いただきありがとうございます！CDの切り替えができないのも変ですね。

状況を整理すると、

(1) FDはロード可
(2) CDはエラーが出ないのに入れ替わらない
(3) ステートファイルはコンソールにエラーが出て読み書きできない、というか書けないので読めるか確認できない

という状況ですね。FDでエラーが出ないということは少なくともVMにファイル名は渡っているはずですね。なぜCDが変わらないのか、なぜステートファイルだけ書けないのだろうか。ちょっと今週はDemosplashなので、来週になると思いますが、詳しく見てみます。少しお待ちください。

2021-11-11 02:16:21

遅くなりましたが、ついさっき出したリリースで、Windows 8でGUIからステートセーブ・ロードができない問題は多分解決していると思います。お時間のあるときにでもご確認ください。

2021-11-26 08:12:08

v20211125にて、Windows 8.1のGUIからステートセーブ・ロードができることを確認しました。
ご対応いただきありがとうございました。

2021-11-26 17:32:13

そういえば、津軽開発開始から2周年が経過しました。1月16日からだったとうろ覚えだったのですが、1月16日はメモに大雑把な概要を書いただけで、Gitのログによると1バイト目のコードを書いたのは1月17日だったようです。これまで、多くの方々に助けていただいてここまで続けて来れました。ありがとうございます！

引き続き津軽をよろしくお願いします！

2022-01-18 04:27:28

> 85　山川機長さま

> (略)実家から回収してきたOASYSのフロッピーディスク読めなかったし。

OASYS FDですが、トラックゼロのフォーマットだけがフツーの倍密度「MFM」フォーマットではなくて
単密度「FM」でフォーマットされていたような気がします。その他のトラック1以降はMFMだったような。
今確認したら、TOWNSテクニカルデータブックのディスクBIOSのパラメタにMFMとFMのビット指定がありますね。
BIOSを駆使すればセクターの抽出はできそうな気がします。

AH=00h; ドライブモード指定で、
・AL=20h; デバイス番号 上位ニブル=2(FDD), 下位ニブル=0(ドライブ番号)
・DL=??h; b7=1(FM), b4b3=00(2HD), b1b0=??(セクター長:128,256,512,1024)←OASYS FDのトラックゼロのセクター長がわかりません…。トライアンドエラーで確認…でしょうかね。
・BH=02h; ヘッド数:2
・BL=28h; セクタ数:40…OASYS FDのセクター数が不明ですが、セクター長が最小の128バイトと仮定して、短密度だとトラックに5000バイトぐらいデータが書けるとして40セクターぐらいを暫定で指定でしょうか。

AH=07h; セクターの検査で、CX=0：シリンダー番号、DH=0：ヘッド番号、DL=1；セクター番号、BX=40：セクター数で実行して、
BXの返却値を読めば、何セクターあるかわかるかもですね。

セクター長が AH=00h で指定したときのものと異なる場合 AH=07h でエラーがあるかもですが、その場合は
セクター長を AH=00h で変更して(128→256→512→1024)からのリトライでしょうか。

ところで以下に書いてあったフォーマットの件ですが、
http://ysflight.in.coocan.jp/FM/towns/writefdimage/j.html

IOCTL_DISK_FORMAT_TRACKS_EX の例題が見つからなかったとありましたが、
IOCTL_DISK_FORMAT_TRACKS の例題なら以下にありました。

「DeviceIoControlを使って、フロッピーをフォーマットするには？」
https://okwave.jp/qa/q153911.html

こちらの FormatPara.MediaType = F3_1Pt44_512; を
FormatPara.MediaType = F3_1Pt23_1024; // ※
(※： https://docs.microsoft.com/ja-jp/windows/win32/api/winioctl/ne-winioctl-media_type )
に変更すればいけるかもしれませんね。
IOCTL_DISK_FORMAT_TRACKS の部分も IOCTL_DISK_FORMAT_TRACKS_EX にして
エラートラック用のメモリーを渡せばいけそうな気がします。

すべて仮定の話ですみません(汗)

2022-01-22 11:37:03

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

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

まさにおっしゃる通りでございます(^_^;)glDrawPixelsは使うのが簡単だから使っているのですが、遅い関数ですね。ですが、おそらく内部ではテンポラリなテクスチャを作って、転送して、テンポラリテクスチャを削除するというステップで実装されていると思うので、テクスチャを使ってもビットマップの転送が入る以上そんなにパフォーマンスは変わらないように思います、とか書きながら案外テクスチャのリソース確保と削除に時間かかってたりして？と、思い始めてしまったので、後でテクスチャを使う方法も試してみますね。それに、最近のシェーダーがテクスチャを多用するので、案外テクスチャの転送はglDrawPixelsとは別の最適化された方法があるかもしれないですね。

本当はOpenGLの依存もなくするといいんですけどね。クロスプラットフォーム化するのに楽だからという理由でOpenGLを使っているのですが、多分直接ビットマップをウィンドウに転送する関数を使った方がオーバーヘッドがかなり少ないはずなので、しかもビットマップが小さいので、時間は稼げると思うのですが、GUIのWidgetを全部OpenGLで描いているもので、これを全部OpenGLを使わないように書き直すのが大変という問題があって、なかなかOpenGL依存からの脱却はできないですね。。。。。DOSBoxとSnes9XってOpenGL使ってたんですか！？だったら案外OpenGLのままでもいいか。

ただ、一応FREQ 66で画面を描画しなかったらどうなるかというもの試してみたところやっぱりCPUも追いつかないので、CPUのスピードはなんとか工夫して上げていかないとと思ってます。一応目標はMXの再現なので、多少ハイエンドなPCが必要になったとしても66MHzは出るようにしたいところです。いや、待ってればそのうち勝手にホストPCが速くなっていくという消極的な考え方もあるにはあるのですが。

CPUにかなり手を入れたので、テストを増やしてみました。去年作った救難IPLのイメージだと僕が書いたものだから、その起動テストは外部依存無しに実行できるので追加して、FPUのテストを強化したかったのでPoly RacerとPower Driveをテストに加えてみました。Power Driveって良くご存じでしたね！FPUのテストにありがたいですね。あとAlltynexの起動とEASTRAYもテストに加えようと思ってます。

2021-12-10 01:42:39

自分のPC環境で確認した限りではglTexImage2Dでの描画の方がtimebalanceの遅れが殆ど目立たない値になっていました。対応ありがとうございます。

他に報告ですが、PCM音源が鳴っている最中にVMをリセットするとPCM音がループで鳴り続けTownsOS起動時にフリーズしてしまう不具合があるので、TownsSound::State::Reset内にrf5c68.Clear();を追記したほうがいいのかもしれません。

2021-12-20 19:15:54

おおなるほど！その問題は、気が付きませんでした！そのように対応します。ありがとうございます！

2021-12-26 13:18:04

githubにMDS/MDF対応版ソースをアップロードしました。まだ数本しか試してませんが、正しく動作しているように見えます。

僕はAlchol 52%をイメージ作成に使ってるのですが、やっぱりPre Gapをバイナリに書かないんですね。BIN/CUEファイルの場合、ディスク長の情報も、トラックがバイナリファイル内のどこから始まるのかの情報も全くないため、Pre Gapが書いてあるのか判別する方法がありませんでした。が、MDF/MDSだとファイル内のトラック開始位置がわかるので、ディスク長はバイナリファイルの長さから最終トラックのファイル内開始位置を引いて、セクタ長で割ったものを最終トラックのセクタ開始位置に加算することで計算できるということがわかり、これにより、Operation Wolfに合わせるとEmerald Dragonのイベントシーンが流れず、Emerald Dragonに合わせるとOperation Wolfが起動しないという問題をついに解決できたと思います。これからは全部MDS/MDFでイメージ作ろう。Fuzzさん、情報ありがとうございました！

皆さま、アメリカではあと6時間ほど良いお年をお迎えくださいですが、日本では新年おめでとうございます！

2022-01-01 07:59:58

新年明けましておめでとうございます。

景気やコロナウィルスの事もあって、世界的に見てもあまり手放しでおめでとうございますとは言えない状況では有りますが、TOWNS界隈においては旧年は"津軽"の登場は素晴らしいトピックであり、本年はさらなる飛躍を期待させる物でも有りました。
山川機長さん並びに皆様の努力に対し感謝します。

ところで、最近の(と言うかかなり前から)グラフィックスカードって、CPUから見るとどう言うアクセス方法なんでしょう?
TOWNSのようにV-RAMが直接的に見えていると言うのは所謂旧世代的な方法で、CGAやVGAではそうなっていたと思うのですが・・・・・
中途半端な世代である、SEGA SATURNだと、ドローリストでスプライトやグラフィックの描画を管理しているようなので、同じようなもので出来ているのかな?とか思うのですが。

え? 何のためにそんな事を考えているか? いや, その・・・ 新年早々 TOWNSに拡張グラフィックスカードを開発するなんて妄想を・・・・・

2022-01-01 08:41:11

明けましておめでとうございます。
こちらハワイもようやく年が明けたところです。（嘘ですすみません）

>>332
実装するのに十分な情報が含まれているのか心配していましたが、無事に実装出来たようで良かったです。
私はmds/mdfフォーマットは使っていないのでテスト出来なくてすみません。

それでは本年も宜しくお願い致します。

2022-01-01 19:55:10

明けましておめでとうございます。
今年も津軽の更なる発展を期待しております。

ディスクイメージはccdもメジャーでいいと思いますよ…自分はclone cdで取り込んでます。

2022-01-02 05:57:50

冬休みだからゲームしよう、と、思ってMDS/MDF対応のテストを兼ねて、遥か昔高校生だったころ友達がプレイしてるのを指をくわえてみていた「大航海時代」をやってみよう！と、思って始めたのですが、誰かクリアした人います？割と順調に進んだかに見えたのですが、「海賊ホアンを討伐せよ」と国王からの指令があったものの、待てど暮らせど出てこないホアン。それどころか、海賊自体が滅多に出てこなくて、果たして何か自分がフラグを立ててないのか、それとも津軽のCPUの問題なのか、あるいは例えば乱数の発生にRTCとか使ってると2022年にもなると絶対発生確率が0になってしまうのか、などいろいろな仮説を考えているのですが、この手のゲームはシリーズものだけに新しいシリーズの攻略情報が出てしまうんですね。うーん、セーブデータのディスクイメージを書き戻して実機でやってみるか。。。。

2022-01-05 15:08:13

妄想のネタを書いておこうと思います。

OSSC(Open Source Scan Converter)と呼ばれるスキャンコンバータが有ります。(https://github.com/marqs85/ossc)
主な用途としては、HDMIを持っていない旧世代のゲーム機器の映像及び音声をスキャンコンバートしてHDMI出力するものなのですが、これを購入しました。

機能的にはラインダブラー方式で、VGAやSCART(RGB21pinの場合はSCART→RGB21の変換が必要)で入力された映像を2倍や3倍にして出力する物で、垂直及び水平周波数の変換等は行わないものです。
wikiを見るとPC-9801やPC-8801でもパラメータの調整により、PCモニターであれば対応できるものも存在するようで、願わくばTOWNSでも使用できるかと思い購入しました。
今のところは31KHzや16KHzの画面モードでは問題なく使えるようで、これらについては多くのテレビでも大丈夫だと思います。
パラメータの詰めが出来ていないので、24KHzの画面モードについては手元ではPCモニター,テレビ共に表示できていませんが、PCモニターについてはなんとかなるかもしれません。
テレビについては、HSYNCが55Hzとなる事からテレビ上の表示で対応しない周波数である旨のメッセージが出ていることから恐らくは表示することは出来ないものと思います。

OSSCの主な回路構成は、TI社TVP7002(ビデオ&グラフィックデジタイザ),ITE社IT6613(HDMIトランスミッタ)とFPGAと言う非常にシンプルな作りで、FPGA内のCPUコア(RISC-V)で双方の素子に対しての初期化や設定及び表示用のLCDとOSDの制御をしている形となります。

ここで、ふと考えたのが、「これにホストCPUとのI/Fを加えて、拡張カードを作れないだろうか」と言う考えですが、簡単なものであれば充分に実現可能な様に感じます。
でもTOWNSのスロットに関しては情報が無いので、まず此処から着手する必要が有りそうです。 しかも世代によって違うという短所まで・・・・

2022-01-11 09:55:55

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

2020-09-24 09:40:33

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

I/Oポート 47ch
画面モード27が使用している。
4を書くと以下のようにCPUから見えるハイレゾ側VRAMレイアウトが変更される。
(CPUキャッシュの影響を避けるため、VRAMキャッシュ無効化が必要)

data = switch (address & 3) {
case 3: return 0;
default: return vram[(address >> 2) * 3];
}

ビット0 の 状態で 124:0(ハイレゾ1画面) に 0 1 2 ... f を書いてから...
ビット1 で 124:0 を読む: 0 1 2 0 3 4 5 0 6 7 8 0 9 a b 0
ビット0 で 11c:0(ハイレゾ2画面) を読む: 0 1 2 3 8 9 a b
ビット1 で 11c:0 を読む: 0 1 2 0 3 8 9 0 a b

セレクタ 10c, 104 でアクセスする従来VRAMには影響しない

2021-09-28 03:36:11

47a, 47b: レジスタ番号(リセット時0, 全ビット保存される)
47c, 47d, 47e, 47f: データ
CRTC2と同様の、2バイトのレジスタ番号と4バイトのデータという感じでしょうか。

0000: リセット時00000000, 変更可能なビットは 00000006
0001: リセット時00020208, 変更可能なビットは 00020e00
0002: リセット時ffffffff, 変更可能なビットなし
以下未調査

XFree86のパッチには 0x047a と 0x47c はビデオカード3のポートだと書いてありますが、はてさて…

2021-09-28 04:08:44

d0000-effff の空間についてのメモ

調査プログラムと素のDOS6での実行結果( https://gist.github.com/pinterior/6ddd1b6794900f37945ba36b993fbbc2 )からみると
・I/O 404h の「MAINMEM」が立っている → RAM
・「MAINMEM」が立っていないが、I/O 480h の「辞書ROM」が立っている→ 辞書ROMとCMOSが見え、その他の領域は書き込み不可の ffh
・どちらも立っていない → 何もない (書き込み不可の ffh)

2021-10-01 22:38:48

コメントしてなくてすみません、この結果、ぜひWikiの方にも書き込んでください。

そういえば、I/Oと言えば、MXって高速シリアルのためのFIFOが増えたと赤本に書いてますが、RS232CのI/Oは増えてないですよね。高速シリアルというのがどうやったら使えるのか115.2Kbpsが使えるんだったら実機にファイルを転送するのが3倍速くなるのに、と、思っているのですが。ひょっとしてMXだとi8551互換の速いチップだったりして、と思って試しにタイマーのインターバルに１を書き込んでみた(76800bps)けどやっぱりだめなんですね。それにタイマーのインターバルを最低値の1にして76800bps相当なので同じタイマーを使ってるんだったら仮にチップが受け付けたとしても76800bpsが限界だし。

2021-11-02 04:38:15

>42 山川機長さん

記憶では別にシリアルの最高速度が速くなったわけではなく、FIFOが無いと19.2Kbps位でも割と頻繁に取りこぼすのでFIFOを付けた程度だったと思います。
取りこぼす主原因は割り込みに対する反応が遅かったからではなかったでしょうか? 記憶が曖昧です。 プロテクトモード←→リアルモードのモード切り替えが根本?

2021-11-04 23:29:37

> WINDYさん

返事書くの忘れてました。取りこぼしの要因はまず間違いなくプロテクテド←→リアルモードの切り替えだと思います。津軽でRS232CのエミュレーションでXMODEMでホスト側のファイルをVMに送ることができるようになってますが、この機能を作ってるときだったと思いましたが、VMの動作を調べていて、考えてみると1バイト受け取るのにものすごい無駄な処理してる、と、思った記憶があります。

2021-11-28 10:16:03

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

うーん、どうしても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

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

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