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

2020-07-28 12:41:40

陸奥書いてて思ったんですが、津軽で音楽の再生とか実機より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

RF5C68についてです。
再生周波数を元のサンプルより上げるのは問題ないのですが、下げると音程がおかしくなるようです。
9.6kHzのサンプルを２つ（それぞれ基音C4とF4）、1オクターブごとに鳴らした動画を撮りました。
https://twitter.com/kashiwa/status/1599424155111239680

2022-12-05 00:47:45

おおなるほど！貴重なテスト情報をありがとうございます！RF5C68は録音した周波数は意識していない（と思った）ので、おそらくFDの値が小さいときに起こる現象鴨しれないですね。確認してみます！

2022-12-06 05:39:39

うーん、JSOUNDでTownsOSに入ってるPMBをいくつかトライしたのですが、同様の現象が確認できないですねえ。おそらく、テストに使われたPMBファイルが、低い音と高い音で波形を切り替えているのだと思うのですが、そのPMBファイルってどこかでダウンロード可能でしょうか？

2022-12-07 11:27:50

https://app.box.com/s/lyiug282aqvuxnh4pdwtwjon9hfrvhwu
PMBファイルはこちらになります。
そういえば私は長いこと「うんづ」でしかTOWNSを触っていないので、もしかすると実機では津軽と同じ挙動なのかもしれません。
# そうだとしたら、うんづは内部でFDH/Lか何かの精度を上げているということになるのかな

2022-12-08 11:29:26

ありがとうございます！津軽で波形の切り替えがあるとき何か間違ってるの鴨しれません。Towns System Softwareに入っているEUPでも微妙に音程が合ってないような？と思うことがあるので、これで解明できるといいんですけどね。

確認してみます。

2022-12-09 03:41:42

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

ありがとうございます

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

やっぱり需要がゼロと思われるWindows 3.1ですが、pinさんがJCXZとLOOP命令のエラーを発見してくれて(まさかここだけCXとECXの切り替えがオペランドサイズじゃなくアドレスサイズと思わなかった）、さらに先に進むようになりました。が、現在

INT 47H

の中で固まってますね。INT 47Hって、何をするのが正しいのかまだわからんですね。INTの40H番台は、原則デバイスのI/Oに使っていて、47HはPICのブリッジで本来発生しないはずのINTということになってますが、なんかで使ってるようです。手動でNOPにしてAXに0F386Hをセットして先に進めてやるとさらに進むようなのですが、その先でクラッシュしてしまいますね。BRKON INT 47としてデバッガ仕掛けて実行すると、その場所までたどりつけます。

もしも何かヒントになりそうな情報があったらよろしくお願いします！

なお、Windows 3.1を（途中まで）実行するには、i486.hの中の、

// #define TSUGARU_I486_UPDATE_PAGE_DA_FLAGS

個々のコメントをはずしてコンパイルする必要があります。

2022-12-07 11:34:16

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

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

> 本堂さん、

一応、漢字入りのファイル名は、システムのエンコーディングをShift JISからUTF-8に変更すると読めるようにはなっているのですが、そうすると日本語のフリーソフトとか文字化けして使えなくなるものが続出するので、しばらく移行は難しいかもしれないですね。しかし、Shift JISが残ってるのはWindowsだけになりつつある（と、思ってるのはアメリカに住んでるからなのか？）ので、いずれはWindowsもUTF-8が標準になるのではないかと思うんですがね。

2022-10-29 01:27:51

アメリカ東部時間の明日夕方と明後日午後、日本時間土曜日午前と日曜日午前、カーネギー・メロン大学でDemosplash 2022が開催されます。コンピュータ・アートとヒストリーの祭典で、僕もFM TOWNS 2F, HR, MX, FM-7, FM77AV, FM77AV40を展示します。ここ2年COVIDの影響で縮小開催だったので、3年ぶりの全力展開となります。

詳しくは、https://demosplash.org をご参照ください。

オンラインでの視聴も可能なので、是非ご視聴ください。僕は、東部時間土曜日午後7時半、日本時間日曜日午前9時半から、ゲーム保存協会と共同研究しているFM-7、FM TOWNSシリーズのコピープロテクトの研究の成果を発表します。

その前に、FM-7シリーズの歴代デモを流して時間をつぶす、という任務も入ったのですが、その準備をしていたら、なんと！FM-7のデモプログラムをFM77AV以降で流すとBGMが鳴らない！という驚愕の事実を発見したんですが、これって既知でしたかね？FM-7界では有名なApolloさんと原因の究明を試みたのですが、陸奥で追ったところ、Reg 7に FF -> FE -> F8 と値を書きこんでいるはずなのに、なぜかReg 7を読んだらBFが帰ってきたので、F-BASICコードのいろんなところに SOUND 7,&HB8 を追加したところ鳴るようになりました。

FM Techknowによると、FM77AVではPSG Reg 7の上位2ビットは必ず 1 0 である必要があるとのことだったので、内部的にフィルターをかけているんでしょうかね。そして、FM-7デモプログラムはその微妙な非互換を踏んでしまっていたんでしょうね。こんなところにFM77AVとFM-7の非互換があったとは。という発見がありました。

2022-11-18 00:09:56

え? あぁ、もう終わってるのか・・・ 見れませんでしたが、如何だったでしょうか?

FM-7/77/AVの非互換部分については、知りませんでした。AVで7のデモを走らせるという発想が今まで有りませんでしたので気づいていませんでしたが、今更ながら原因が気になったので軽く調べてみたらAY-3-8913(PSG)は、元々のAY-3-8910のIOポートなし版で,そのIOポートの入力イネーブルコントロールがReg#7の上位2ビットだったようですね。
AY-3-8913では機能として存在しないので特に値としてはなんでも良かったようで、当時のドキュメントからもReg#7の上位2ビットに関してはなんの説明も有りませんが、YM2203をではIOポートにパッドコネクタが接続されており、Reg#7の上位2ビットは'10'である必要が生じています。
読みきれないのですが、AVの回路図ではFM音源のデータバス(YDATABUS)からREG07信号を生成してFMDB6信号やFMDB7信号を生成している事から怪しいですね。

2022-11-21 09:49:51

今年はDemosplashはかつてないぐらい盛況で大成功でした。現在燃え尽きて真っ白な灰になってます。当時の模様はScenesatの録画がもうすぐアップされると思うので、興味がありましたらご視聴ください。

FM77AVの非互換の件ですが、PSGのreg7にFD0D,FD0Eから値を書き込んだ場合、問答無用で上位２ビットが 10 に固定されるようです。例えば実機AVでFFを書き込んで、読み戻すとBFが帰ってきました。それを陸奥で再現してみたのですが、それでもまだ陸奥上では音が鳴ってしまうので、まだ何か違うようです。IRQがかかってしまっていてF-BASICがPLAY文と勘違いしている説、F-BASICインタプリタが値を書き換えてしまっている説などいろいろ考えたのですが、どれも正しくなさそうで、やはりなんらかの理由でReg7への書き込みが無視されているようです。結構新しい発見だったので、どういう条件でReg 7への書き込みに失敗するのか調べてみたいところなんですがね。

2022-11-22 03:18:28

回路図から辿る限りでは、REG#7のデコードはYDATABUS0～7(YM2203のデータライン,元はメインデータバス)を用いて生成されています。
そのREG07信号をデータとしてD-FFに入力,CKは*YMWR信号(出元はゲートアレーMB113T613),Q出力をMDB7(MainDataBus#7)とORされて、FMDB7信号としてD-FF(LS374)の入力として入ります。
Q出力の反転出力(Qbar)をMDB6(MainDataBus#6)とANDして、FMDB6信号としてD-FF(LS374)の入力として入ります。
両方のD-FFのCK(取込タイミング)は*WSGDATA(SSGポートへの書込タイミング?),OC(出力タイミング)は*YMWR(FM音源ポートへの書込タイミング?)です。

回路としては、REG#7への書込が発生した場合にYM2203に与えるデータの7,6を10に固定しているようです。
ただし、重要なタイミング生成をゲートアレーで行っていますので詳細なタイミングは判りませんけど。

2022-11-22 09:51:15

そうなんですよね。タイミングがMB113T613のゲートアレイということはカスタムチップだと思うんですが、これが正しいタイミングで書いているかというのがポイントですが、ひっかかってるのがFM音源に書き込むには本来Ready待ちをしなくてはならないのがPSGのI/Oで書き込むときは待ってないというポイントなんですね。なんらかの順にPSGレジスタに書き込んでしまうとYM2203Cが一瞬Busyになってしまってそのタイミングで書いてしまっているのではないか、と疑ってるんですがね。しかし、これ以外FM77AVでFM-7のソフトが動かないという話は聞いたことがないのでものすごく珍しい条件を踏んでしまってるのは間違いないはずなんですが。

2022-11-23 08:21:01

AVの回路図だとYM2203へのアドレス/データはLS374で制御していますが、これのCKには*WSGDATA信号が入っていますよね。
この*WSGDATA信号はゲートアレーから出力されているのですが、普通に考えると互換性のためにPSGのI/Oアクセスの際にも,FM音源のI/Oアクセスの際にもアサートされると思うんです。
(そうしないと、AVシリーズにはAY-3-8913が搭載されていないので従来のソフトを走らせた場合にPSGの音が鳴らない)
仰るようにそもそもFM音源を意識したコードが書かれている訳が無いFM-7のデモプログラムで、容赦なしにPSGのI/Oへ書込を行った場合にYM側がついてこれないのかも知れませんが、そんなコードは恐らく数多く有りそうなのに、現象が発生するケースは他で報告されていない事を考えると無さそうとしか思えないですよね。

因みにFM-7のFM音源カードはどうなっているか気になったので調べたらREG#7のbit7,6に細工してる気配は無さそうですね。
(そんな回路図が有るかな?と思って調べたら山川機長さんのサイトに載ってたと言うブーメラン的な事が発生しました。 貴重な情報を有り難うございます)

2022-11-24 10:03:55

ところで、Oh!FM創刊号からOh!FMTOWNS最終号までの目次をテキストかSpreadsheetに入力してどの記事がいつ載ってたか検索できるようにしよう、というプロジェクトがあって、この間ゲーム保存協会に寄ったときに全号の目次の写真を撮らせてもらってきたのですが、こういうデータってまだ誰もやってないですよね？フリコレに途中まで無かったかと思って調べたんですが、フリコレ8の表紙絵集ぐらいしかないですよね？既にあるのに再度やってもと思ったのですが。

フリコレ8の表紙絵集、津軽で実行したら画面の拡大間違ってますね。。。。そういえばアルシャークの起動時のRIGHT STUFFのロゴも横拡大率間違ってるってissueがgithubに上がってたんだよね。512x480モードで横の倍率が2倍に設定されてると津軽は思っているようだが、実際はこれ拡大しないのが正解なんだな。何で2倍と思ってるんだろうか？

2022-11-26 11:50:56

CR1が3なので、24kHz用のクロックを使っているのですね。
本来512x480の画面モード17ではレジスタセット31、CR1=2なので、各ドットは 25.175/21.0525 = 1.2 倍横にふくらむことになります。
ピクセル数(分解能)は 512x480 のまま、614x480 相当のワイドな表示を行うための設定だと思います。

この設定が、ゲームなどで同様の原理で256x240のスプライトを横に広げて表示領域を太らせるゲーム用の例外処理にヒットしたのではないでしょうか。

2022-11-26 22:35:13

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

2020-09-24 09:40:33

はじめまして。FPGAでFM TOWNSクローンを作ろうとしているプーと申します。
早速ですが、少し行き詰っている部分があるのでわかる方がいらっしゃれば教えてください。
SCSIを搭載し、HDDをエミュレーションしようと試行錯誤しているのですが、DOS6.2L10のboot時(IO.SYS内)でSCSIのセレクションが
終わった後(07bd:026b周辺)、データ転送フェーズに入るのをタイムアウトするまで待ち続けるループ(07bd:0270周辺)があります。
少なくともコマンドを送らなければデータ転送フェーズには入れないと思うのですがその様な動作をしているようではありません。
DMAでコマンドを送れば該当するプログラムは無くてもよいのだとは思うのですが、TOWNSのSCSI回路はコマンドもDMAで転送は可能なのでしょうか。
ちなみに該当(永久ループ中)時のDMAアドレス、カウンタともに0のままでしたので、DMAでコマンドを送ろうともしていないのではないかと思います。

2022-11-05 01:29:57

プーさん、

FPGA TOWNS、既にFDからの起動が可能ということで、すごいですね！TOWNSのSCSIコマンドは、I/O 0C30hのFIFOバッファのはずですね。DMA転送はしてないと思います。7BD:270付近というと、

07BD:0000026D 8B5402 MOV DX,[SI+02H]
07BD:00000270 EC IN AL,DX
07BD:00000271 A801 TEST AL,01H
07BD:00000273 7501 JNE 00000276
07BD:00000275 C3 RET
07BD:00000276 803EB70C01 CMP BYTE PTR [0CB7H],01H
07BD:0000027B C3 RET

ここですかね? DXは0xC32なので、これはデータ転送フェーズ入りではなくPERRフラグを見ているような感じがします。この付近ではループを組んでいるような感じはしないのですが、アドレスはここで合ってるでしょうか？津軽のデバッガで追ってみた感じだと、その後普通にCOMMANDフェーズに移行しているように見えました。

2022-11-05 06:24:57

山川機長さま：
返信ありがとうございます。山川機長さまは津軽・互換BIOSの作者様でございますでしょうか。
いつもお世話になっております。BIOSソースと動作を見比べながら回路のデバグを行いましたので大変お世話になりました。
おかげでFDDからのDOS bootまではたどり着けました。

上の話ですが、275番地のretで1e5番地に戻っており、1f3番地でREQ,MSG,C/Dを残してマスクし、1f5番地でREQのみ1の状態で
なければ1cb番地に戻り、ループする、と解釈しております。REQ=1,MSG=0,C/D=0の条件はデータ転送フェーズですのでここを抜け出すには
データフェーズに入るしかないように思えますがこのルーチンに入る前はコマンドは1バイトも送っておりません。

2022-11-05 09:30:20

プーさん、

> 返信ありがとうございます。山川機長さまは津軽・互換BIOSの作者様でございますでしょうか。

そうです。互換BIOSはCD起動までKasanovaさんが開発されていたものを、改変したものも公開が自由とのことでしたので、FD起動など僕が追加しました。互換BIOS作っておいたら津軽で使えるほかに将来誰かFPGA TOWNSを作る人が現れたら単体で動作するTOWNSとして配布できるであろう、ということを考えてましたがまさかこんなに早く現れるとは思ってませんでした！津軽は、中身を研究するためにデバッガをかなり強力にしたつもりなので、ご活用ください。

SCSIは、津軽開発自分ジャーナルにアノテートした逆アセンブルが残ってました。ここですが、01F0HからBUSY=0で抜ける可能性もあります。

07BD:000001EE A808 TEST AL,08H ; AL comes from IN AL,0C32H. 08H is BUSY flag
07BD:000001F0 741C JE 0000020E { SCSI Status BUSY=0:}

各フェーズに対する処理はSCSIのInterrupt Handler内で起こっているので、このループは単にInterrupt Handlerがフェーズを先に進めてそれに応じて回っているだけと思います。ですので、フェーズが変わるごとにSCSIのIRQを出して行けば抜けてくると思います。

SCSIのIRQ (48H)のハンドラは 07F9:00DF ですね。と、言ってもALに20Hを入れていったん全部07F9:125に飛ぶことになっていて、そこから分岐ですが。

参考になりましたでしょうか？

2022-11-05 11:46:40

どうも情報ありがとうございました。
どうやら割り込みが無効になっていたため、コマンドを送れていなかったようです。
というのも、テクハンP262、IMSK(bit6)の説明で0=割り込み許可、1=割り込み禁止 と記載されていたため
そのまま負論理で記述していましたが、次ページINT(bit1)の説明でIMSKは0でマスクできると記載されており
こちらは正論理記載です。どうやら263ページの説明が正しく262ページの記載が誤記のようです。
該当部分論理反転したところ、少なくとも該当部分は正常になったようです。

2022-11-05 16:46:04

おおなるほど！そのpp262の誤りは津軽書いてるときに解明していたはず、と、思ったらWikiの正誤表(https://wiki3.jp/fmtowns/page/11)に転載し忘れてますね。一応、津軽開発中に見つけた正誤表が、

https://github.com/captainys/TOWNSEMU/blob/master/FMTOWNS_Technical_Databook_Errata.md

ここにあって、大体はWikiにも転載したはずなのですが、IMSKフラグは転載してなかったぽいです。他にも漏れがある鴨しれません。よかったらこちらも参考にしてください！

2022-11-06 00:22:11

そのようですね。何処かに記載があった気がするけど。。。wikiには書いていないからテクハンが正しかったのか、と負論理で記述してしまいました。
そうですね。先に見たのは津軽のgithubでした。じっくり再度読ませて頂きます。
ところで津軽のデバッガの使い方をご教授頂けないでしょうか。

2022-11-06 23:58:32

そうですねえ、デバッガもコマンド追加するたびに一応HELPには簡単な説明を書くようにしていたのですが、ちょっとわからん機能も多いですかね。一応、デバッガ有効にする ena debug コマンドとか逆アセンブルのUコマンドとか、ブレークポイント設定のBPコマンド、一ステップトレースのTなどはわかりやすいと思うのですが。よく使うのはbrkon(イベントでブレーク)ですかね。メモリに書き込みがあったときブレーク brkon memw seg:offset とか、特定の値の書き込みがあったときブレーク brkon memw seg:offset value=??、とか、あるいは逆にmemrでメモリ読み込みでブレークとかできます。あと、ブレークしないけど通過したときステータスを表示する、mp cs:offset も結構最近多用してますね。現在実機でD77より多くの情報を抜き出すダンププログラム書いててBIOSの細かい動きを解析してるので、IO Monitorコマンド ena iomon IOPort も良く使ってますね。IO書き込み、読み込みでブレークさせることもできます。 brkon iow IOPort みたいな感じで。あと過去65536段階までCS:EIPのログを取っているので hist コマンドで表示できます。hist 1000とかやると過去1000ステップまで見れます。あと、calc eax+edi*4+0x100 みたいな感じで式の計算機能も付いていて、計算機能以外は数値は原則16進数ですが、CALCコマンドの場合は、なにもつけないと10進数、16進にするには$100, 100H, 0x100のいずれかのパターンを使います。あとは、使ってみてこういう機能が欲しいとかこのコマンドはなんじゃ？という疑問があったらその都度聞いてください。

2022-11-07 02:45:39

あ、そうだ。そういえば、津軽と陸奥のデバッガは実はシンボリックデバッガなんですよ。これが使うとめちゃくちゃ便利で（自分で言うな）、起動時に-SYMオプションでシンボルファイルを指定しておいて、デバッグ中に

ADDSYM 000C:0000 "Code Segment Top"

みたいに書くと、逆アセンブルしたときそのアドレスにヒットするとその情報を表示します。また、ADDREMを使うとコメントっぽく表示して、ADDLABだとジャンプラベルみたいな感じの表示になります。あと、I/Oをいちいち覚えるのが面倒だったので、MOV DX,0200h みたいになってるところに、IMMISIO seg:offset みたいに書くと、I/Oの意味をコメントに表示します。その他、.EXPファイルのシンボル情報を読み込む機能もあって、、、、うーん、コマンド忘れたけど、ヘルプで出ますんで。大航海時代のデバッグのときには重宝しました。案外製品のEXPファイルにもシンボル情報残ったままになってるんですよ。ここ数日のFDUTIL.EXEを書くための Disk BIOS 解析でも活躍しました。陸奥の方はまだ I/O のテーブルとかデータに持たせてないんで、そこまでの機能は無いんですけどね。

登録した内容は自動的にシンボルファイルに記録するので次回起動時も同じシンボルファイルを読み込めば続きの解析ができます。これは自作プログラムのデバッグにも多分便利だと思います。

あと、

SYMFIND keyword

でキーワードを含むシンボルを表示します。うーん、ワイルドカード対応してたっけかな？してたようなしなかったような。（書いてるコードが多すぎて端々まで覚えられない）

2022-11-12 11:13:44

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

2020-07-28 13:20:43

山川機長さん

うーん、やっぱり現実世界では様々な要素が有って難しいですね。
uPD71071のデータシートを見たのですが今のところ、"これだ!"と思える記述が発見できていません。
気になったのはDMAによるデータ転送後にバスフリーを行う処理が有るのですが、この時間が規定されていないようで100msのウェイトの件は此処にかかっているような気がします。
I/Oの00A9Hのデバイスコントロールレジスタのbit0にBHLDが有るのですが、TOWNSの場合は0(バスリリースモード)で使用している関係でDMAリクエストは実行中のDMA処理が終わった後にしか受け付けてもらえない("無視される"とは書いてないのですが、無視されると思われる)ので、バスフリーが終わらないうちに次のリクエストが入っているのではないかと思われるところです。
なぜバスフリー処理の時間が明確に規定されていないかについては、ターゲット側(HDD等)の処理時間が係わるからじゃないかと思っています。

SCSIのデータ転送が終了したかどうかは、データレジスタを見てターゲットがコマンドコンプリートメッセージを送出したかで判断するようですが、SCSIのデータレジスタはアクセスするとACKを送出してしまう事から見ることは出来なさそうですね。

2022-11-09 09:41:15

↑に色々書いたのですが、SCSIとDMACで混乱してますね。(汗)
バスフリー処理の時間に関してはDMACのバスフリーはCPUバスに対してだからSCSI側のターゲット側処理時間は関係無いですね。

CPUバスなので、DMACクロックに対するサイクル数で表現されてそうですが、それがmsオーダーなんてDMACとしてあり得ない数値ですね。
原因は何だろう・・・

2022-11-09 10:04:26

いやあ、でもSCSI書き込み後にFDCが方針してしまうわけなので、SCSIとなんらかの関係があることは間違いないと思うんですがね。ただ、タイムアウトを見てリトライさせたらなんとなく動くようになったので、公開してみました。

https://github.com/captainys/FM/tree/master/TOWNS/FDDUMP

ここにソースとバイナリがあります。D77フォーマットでは表現できないセクタ読み込み時間と、Track Readコマンドの結果を保存するために.RDD (Real Disk Dump)フォーマットというファイル形式を勝手に作りました。また、値が変化するセクタは12回マルチサンプルするようになってます。そのままだと津軽や陸奥で使えないので、RDD2D77なるプログラムも書きましたが、いずれ津軽・陸奥で直接サポートしようと思ってます。

まあ、あの手この手を試しているうちにだんだん複雑になってしまって、Watcom Cのインラインアセンブラを多用しているので、あんまり読みやすくないですが、もしも、何でFDCがときどき放心するのか、気が付いたことがあったら教えていただけると助かりますね。

なお、津軽と陸奥は.D77EXT (あるいは.D7X)というファイルを.D77ファイルと同じディレクトリに置いておくと、セクタ読み込み時間の情報をそのファイルから読むように作ってあるので、Ys2とかSilpheedとか三国志とか琥珀色の遺言とかプロテクトそのまま再現できるようになってます。今のところ、PaulineとかFDShieldでキャプチャしたイメージから問題のセクタの読み込み時間を計測して手作業で.D77EXTファイルを書いて実験していましたが、このFDDUMP.EXEで作ったディスクイメージからRDD2D77で .D77 + .D7X に変換したディスクイメージは、そのまま陸奥で使えるはず、という予定なのですが、実機によるテストはこれから本格的にやらないといかんですね。

本当はThexderとかFire Crystalみたいな、木の葉隠れプロテクトも検出してそれも読み込みに対応したいんだけど、Read Addressでタイムアウトが頻発してるっぽいから、ちょっと難しいかもしれんですね。

2022-11-09 15:58:46

なお、FDDUMP.EXE、実機MXで琥珀色の遺言のディスク１のセクタ読み込み時間の計測成功しました！陸奥で起動からチェッカーの通過まで確認できました！

そうか、あと木の葉隠れに対応できればFM-7系に使われたプロテクトは（伝説の複数インデックスホールプロテクト以外)対応可能になるかな。というか、3.5インチではそもそもインデックスホールプロテクトは存在できないし。なんか考えよう。

2022-11-10 01:03:55

木の葉隠れプロテクト、なんと対応できましたというか対応できてました。少なくともMXのディスクドライブだと、Read Trackコマンドでセクタデータが化けないので、Read Trackした結果から解析するとあっさり隠れた本物セクタが見えてしまいました。（というか、なんでFM-7だとRead Trackであんなにデータが化けたんだろう？同じMB8877なのに。）最初Thexderの隠れセクタのうちのひとつがインデックスホールをまたいでいるので取れないかと思ったんですが、それは気のせいで取れてました。これだと、FM-7シリーズのプロテクトは僕の知ってる範囲ではすべてFDDUMP.EXEでキャプチャできますね。

あとは、ときどきFDCが放心状態になるのが格好悪いのでなんとかできれば完璧なんですけどね。Disk BIOSの動きを見てできるだけ同じになるようにしているつもりなんですが。一応今のところタイムアウトしたらリトライすればほぼ確実に読めてるので実用的には問題無いようです。

2022-11-11 04:16:10

FDCの放心問題を解決するためにFM Towns Technical Databookを見直してるんですが、248ページの表 I-7-18の、2HDモードのモータ起動時間、"1000mS以上" って、"以下"の間違いですかねえ。少なくとも1秒かかる、だとあまり有益な情報じゃ無いような。

2022-11-11 05:56:34

原因解明！タイマーでした。Disk BIOSの逆アセンブルを見ていたら、最初にタイマーをふたつ解除していたので、試しにタイマーをマスクしてみたらすべてがスムーズに動くようになりました。考えてみたら初期のTOWNSにはDisk Changed BitがI/Oになかったので、タイマー割り込みで定期的にディスクが抜けたことを確認して、そうなったらディスク交換があったと判定していたと思います。最も考えられるのは、そのタイミングでドライブセレクトを0と1に切り替えるのでFDCが止まってしまったの鴨しれません。津軽だとそういえばFDCコマンドを出した後でドライブセレクトを切り替えるという状況は想定してなかったですね。

ということで、FDDUMP.EXE安定して使えるようになりました。

2022-11-11 08:45:04

無事解決できたようで安心です。
タイマーかぁ～、確かにタイマー割り込み先でドライブセレクトされたらと考えると説明がつきますが、ウェイトとの絡み(ウェイトを増やすと安定方向へ行く)がよく解らないですね。
でも、まあタイマーをマスクしたら安定するのならタイマー割り込み先での処理が原因だったと言えるので、解決ですね。

モーター起動時間の件は2DDと2HDで違う(と言うか逆)事は無いと思いますので、2HD側の誤植でしょうね。
3.5インチFDDの資料を何点か見ましたが、1000msって言うのは無くてMAX500msばっかりでしたので1000msってのは搭載するドライブが変更される事を見越して結構な余裕を持たせているのかもしれません。
ただ、Over1000msってのはあり得ない表現なので。

2022-11-11 09:30:45

タイマーを増やすとエラーが減るのが、そこがわからんところなんですよね。タイマーと気が付いたのは、MON IOR 200 20F, MON IOW 200 20F とした状態で DIR A: とすると、読み込みが終わって少し待ってから208と20Cにアクセスするような動きがあったので、BIOSの逆アセンブルの最初の方を見たらタイマーのキャンセルの処理があったのでわかった、という感じなんですね。しかし、このタイマーの挙動はBIOSでFDを読んだ後に起こるようで、津軽上ではI/Oを直接いじってる限り再現しないんですよね。何か実機の挙動で解明できてない点があるみたいなんですが、おそらくTOWNS実機を使ってディスクイメージを作るプログラムを書こうなんて人は僕以外にいないと思うので、そこまで解明する必要は多分無いですね。昨日は試しにFM77AV用のマンハッタン・レクイエムのイメージをFDDUMPで作ってみましたが、陸奥でばっちり起動確認できました。どうやら起動中にF6セクタを読んでいるのでチェッカーも無事通過していたようです。

2022-11-11 23:07:25

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

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

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


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

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

2022-07-07 01:57:49

質問です。
IC Memory Card 救済IPL書き込みユーティリティ(ICMWRITE.EXP)はFRAMカードに使えるのでしょうか。
“書き込み内容が一致しませんでした。”というエラーが出るのですが、この場合書き込みはされているのでしょうか。

何方かご教授頂けますと幸いです。

2022-09-30 23:54:54

使えます、というかそれ以外今のところユーティリティが無いですね。ただ、書き込み内容が一致しなかったというのは、ベリファイに失敗してますね。ライトプロテクトがかかっていた場合は、ライトプロテクトエラーになるはずなので、書き込みに失敗していると思います。それって、先日送ったFRAMカードでしょうか？アメリカの知り合いにもひとつ送ったところ、コネクタのはんだ付けが甘くて輸送中に取れてしまったらしく、彼はハンダを溶かしなおしたら直ったと言ってたんですよね。同じ状況になってないと良いのですが。

2022-10-01 09:36:49

>山川機長様
そうです。先日送って頂いたものです。Townsが非常に使い易くなりました。ありがとうございます。
今は2022511cが正常に動作しているのですが、そこに同じバージョンの上書きを試しています。
icmwriteの使い方は何処かに書いてありますでしょうか。

起動方法を幾つか試したのですが、普通にダブルクリックで起動したり、
run386 -nocrt icmwrite.exp icmimage.bin
を実行したりしたのですが、同様のエラーメッセージでした。

icmimage.binがカレントドライブになくてもエラーに変化が無いので、パラメータに問題があるのかもと思っています。

なお、ライトプロテクトスイッチはunprotectに切り替えたままで、cmosバックアップとリストアがエラーなく動作しています。
FRAMカードは段ボールを切り抜いて頑丈なパッキングが施されていたので大丈夫だと思いたいところですが、
悪あがきしても駄目だったらはんだを溶かすのもやってみようかと思います。

2022-10-01 21:03:57

私の環境でもFRAMカード、SRAMカード共に同じく“書き込み内容が一致しませんでした。”と表示されます。

run386 icmwrite.exp
を打ち込んで、メニューに従って書き込みを選択しています。

エラーが表示されるものの、書き込みは行われているようで、そのまま救済IPLとして使用しています。

普段書き込みに使用しているユーティリティでもFRAMカードではエラー表示されますが、書き込みは出来ているようです。
同ユーティリティでSRAMカードへ書き込む場合、容量64KB程度の小容量を指定した時だけエラー表示され、書き込みは正常に行えていた記憶があります。

2022-10-02 12:19:39

> aochanさん
あの状態で書き込みはできているのですね。
Towns本体の故障も疑っていたのですが、安心しました。
情報ありがとうございます。

2022-10-02 20:04:32

おおなるほど。それは、ICMWRITEのバグっぽいですね。確認してみます。ありがとうございます！

2022-10-03 03:15:58

コロナ陽性とその後の延期になった仕事の火の粉で大変でしたので暫く見れていませんでした。

プログラムを見ると、FRAMカードに書き込むIPLはICMWRITE.EXPに内包されているようですので実行ファイルの実行のみで良いようです。
確認できていないのですが、書込時はアセンブラ内のTRANSFER_TO_ICMルーチンを呼ぶのに対し照合時の読み出しはDiskBIOSのコールとなっていますが、これが原因では? > 山川機長さん

2022-10-06 14:38:58

WINDYさん、

おおたしかに。うーん、これはなんでこうしたんだったか、記憶をたどっていくと、書き込みは直接書くとして、読み込みは起動しなきゃならないんだからBIOSが読めるように、とかそういうことを考えたような気がします。MXだと動いたはずなんだよなあ。すみません、Towns OS V2.1 L31で試してみていただけるでしょうか？ひょっとするとBIOSのバージョンの違いに影響受ける鴨しれません。

2022-10-26 08:42:58

掲示板のタイトルからは外れますが、兄弟エミュレータと言うことで。
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

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

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