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

2020-09-24 09:40:33

現在、去年ヤフオクで落としてアメリカまで輸送したまままだ未処理だったHRの電源を修理しようとしてます。コンデンサは全部交換しますが、なんかリレーが死んでるような気がするのでリレーも交換してみて、それでもだめだったらAT電源化する予定です。

当然のごとくバッテリーも死んでいるはずなのでソケットに変換しようとしてます。一応、MX、MAがCR2450だったのでHRも同じだろういう予想はできましたが、確認しました。同じCR2450でした。一応、報告でした。

2020-09-27 03:51:19

旧スレッドからのネタです
・モデルHC(たぶんMシリーズやFreshも?)のCD-ROMについて、読み取り不良を何とかしたかったのでえすびさん方式(ピックアップのトリマ調整)を行いました。
結果としては上々で、いままであれ程読めなかったCD-ROMが確認した限りでは全て読めるようになりました。
私の場合はトリマを右に10°程度右に適当に回して当たりでした。
CD-ROMが不調な場合の1つの方法としては有効ではないかと思います。(http://sbeach.seesaa.net/article/475985723.html)

・モデルHCのFDDについて、以前ジャンクで購入してきたドライブに交換して3モード共に正常でしたのでWIKIの方に記載しておきました。
交換したドライブは YE-DATA製 YD-702D-6238Dですが、1点だけ注意点が有ります。 (ドライ部側コネクタのバンプ溝が天地逆となっていますのでドライ部側コネクタを加工する必要があり)
同時に購入してきたMITSUMI製 D63119は正常動作しなかった為、原因を究明中です。(非常に綺麗なのでドライブの不良とは考えにくい)

2020-09-28 00:19:19

上記ネタでTOWNSを久しぶりにバラした時に今更気づいたのですが、HCにはPLCCソケットでH8マイコンが搭載されていました。
赤本等の資料には一切その様な記載が有りませんが、どなたか情報をお持ちでしょうか?

逆に赤本ではCDCとしてMB88505が搭載されていると記載されていますが、こちらは見つけることが出来なかった(そもそもよく見ていなかった)のでひょっとしたら2倍速化の際等にCDCがH8に変更されているのか? とも思っています。
(今度機会を造ってH8のピンとCD-DRIVEのピンをテスターで計ってみようかな)

2020-09-28 13:10:57

>4 WINDYさん
遡ると確かHRでHD64180系マイコンに変更されていた記憶があります(おそらく64KB先読みキャッシュのため?)。
その後6代目(白TOWNS)でH8マイコン(Oh!誌のDr.ちゆきの分解記事の写真(暗いですが)によると「H8/325」)に変更され、それが7代目(Oh!誌の分解記事の写真によると「H8/324」)にも引き継がれているものと思われます。
なお、V-TOWNSではATAPIから独自I/Fへのエミュレーションの関係上、CD-ROMコントローラエミュレータもTOWNSカード上のVM386SXで実行されるファームウェアに実装されています。このあたりを更に深掘りしてみれば白TOWNSにしか実装されていないADPCMデコーダ以外の仕様が見えてくるかもしれません。

2020-09-29 19:04:50

>5 りうさん
有り難うございます。 Oh!誌はFM-7を使っていた頃から欠かさず購入していましたが・・・・
そのような記事が有ったことはすっかり記憶から欠落していました。

深堀ですか・・・ 深堀ですね。 流石に回路図を起こす事は出来ませんが、なるべく高精細で写真を撮る事は出来ると思います。(LANカードとかMIDIカードとかの写真は撮ったのですが、メインボードは途中で面倒くさくなって・・・)
何せASICが結構使われていますので配線を追ってもそこで手の打ちようが無いのが残念ですが想像は出来そうな気がします。
ビスが異常に多いのでバラすのには時間がかかりますが、初代のような箱根細工風でもないのが唯一の救いです。

2020-09-29 23:55:36

昨日SCSI CDbootのために内蔵HDDを外すついでに見てみたら、私のHCでは「H8/325」が搭載されていました。
詳細な形番が判らないのでPROMなのかMaskedROMなのか判別できませんが、恐らくソフトの版のシールが貼ってあったのでどちらかでしょう。

「入出力ピンからCD-ROMドライブに行っている信号線のIn/Outが判るかも」と思いましたが、H8のGPIOはIN/OUTなのですね・・・・
プログラムも吸い出せそうに無いのでそっち方面からの解析はおあずけです。
ドーターカードの配線がCD-ROMドライブのコネクタを避けて通ってましたので少なくともCD-ROMドライブはSCSIでは無い事は確かです。
(HCのドライブはCD-ROMを挟むように内蔵HDD用のものとファイルスロット用(HC53MはMO内蔵のため)のSCSIのコネクタが存在しています)

2020-10-01 17:57:03

メモリカードの件ですが、手を換えてos-wikiで検証用に使用しておられたpcctolをHCで使用してみました。
結果としては、CFカードアダプタに挿したCF(32MB FAT16)と4in1アダプタに挿したSD(16MB FAT16)でアクセスに成功しました。
ファイルのコピーとかもやりたかったのですがドキュメント通りにタイプしてもdrive errorになってしまうのは私のミスだろうか・・・・
もう少しやってみたいと思います。

pcctoolは、下記のこめんと欄の一番下の川合さんのコメント先よりソース付きで入手できます(ソースはASKAになります)
http://oswiki.osask.jp/?pcctol

2020-10-10 00:32:59

おお、読めたんですね！詳しくリンク先は読んでいないですが、読むときウェイトかなにか必要なんでしょうかね？今でこそ高速なCFやSDがありますが、当時のRAMだと486DXの66MHzで読んで追い付くのかな？と疑問はあったのですが。ただ、SYSROMは普通にMOVSBを使ってアクセスしているようなのですが。引き続き何かわかったら教えてください。

2020-10-10 23:50:13

>9 山川機長さん
取り敢えず小さなファイルをSDとCFに書いたり、SD,CF上の物を読んだりしてみましたが、全く問題がありませんでした。
しかしながらCF上に同じファイルを名前を変えてコピーして行ったときに、2.36MBを超えたときにエラーとなった事からたとえCFやSDが大きな容量を持っていてもある程度までの大きさまでしか書けないような印象です。
この制限がプログラム上の物なのか、TOWNSの機能による制限なのかは不明ですがPC用の同名ソフトではより大きな容量をカバーできている記載がpcctolのドキュメントに記載されている事から、プログラムの制限では無いような気もします。
オリジナルのソースを眺めてみようかと思います。

CFやSD等のスピードに関しては、PCMCIAカード自体がコントローラを内包している事から問題はないのではないかと思います。(カードのBusyが端子に出ているので、それに従うタイミングでOK)

2020-10-11 17:40:42

CFが読み書きできると大きいですね。TOWNS側でBUSYフラグ見て調整ですかね? 赤本だとBUSYフラグはEPROMの書き込みREADYとあったので読み込みは関係ないかと思いました。SYSROMは何もせずにMOVSBしていたような気がしたのですが。PHYSDUMPは何も考えずにMOVSBでリアルメモリにプロテクテドモードメモリをコピーしてダンプしているので、もしもWAITが必要とするとその影響で意味のない値が出てきたのかも。いや、でも、それだとTICMFMT.EXEでフォーマット失敗したなあ。実はMXの問題なのだろうか。

ちなみにブートローダーですが、PCとクロスケーブルでつないでXMODEM経由でCMOSダンプをやりとりできるようにしようとしてます。ゆくゆくは、XMODEMでROMも送れるようにして、CDもFDも動かないTOWNS→仮想SCSIドライブで起動してROMファイル抜き出し→エミュレータ上でHDDイメージ作成、CMOS設定→XMODEMで実機にCMOS送信→仮想SCSIドライブにエミュレータで作ったイメージをマウント→実機復活という流れができないか(SCSI CDドライブが無くても仮想SCSIドライブだけで復活可能)、というようなことを考えてます。

この間ヤフオクでFDが動かないというUXが出てましたね。そういうのもこれで復活させられれば、と、思うのですが、ただUXに関しては依然としてなんで386SXでブートローダーが動かないのか(それともUX特有の問題か)特定できてないですが。386DXで使えて386SXで使えない命令なんてあったかな?

2020-10-12 08:25:46

>11 山川機長さん
pcctolのソースを読んでいます・・・ 私にとってはASKAは慣れないとX86以上に読みづらいかも・・・
ですが、readとwriteの最小ループ部分は512バイトを連続して読み取っている事は判明しました。特にフラグを参照している節は有りません。
もう一段上のループでは、400nsのウェイトが入っていますのでセクタの切替時には待っているようです。(R/W共に同じ400nsです)
また、バンク切替レジスタはオープン時にバンク0に明示的に切り替えていますが、R/W中に切り替えてはいない様子です
上記オープン時には明示的にメモリマップドモード,デバイス番号0を指定していますが、タプルを辿った様子は無く決め打ちでメモリカード側を設定しているようです。

2020-10-12 13:18:38

Amaranth3対応のためI/O FF82H(Memory-Mapped I/O CFF82H)について実機で(今引っ張り出してきた2F)で実験していたのですが、非常に興味深いですね。

まず赤本ではFF82Hに書き込むときはビット6は必ず1にすることとありますが、TBIOSがAH=06Hで27Hを書き込むので0でも1でも関係ないようです。

ビット0～2、ビット5で表示プレーンを指定できることになっていますが、2Fで画面モード1,3,13,17 (なぜかTBIOSが32K色モードで2ページにしたら何も書いてくれないのだが、どうやれば書いてくれるんだったか忘れた。Towns現役当時ほとんど自作のConcorde Graphics Library使ってたもんな。)で試したところ、どうやら16色モードで、カラーインデックスに対するマスクとして機能するようですね。

ビット4で表示ページ指定ということになっていますが、CRTCのVRAMオフセットを切り替えるのかと思ったら、どうやらこのオフセットはCRTCとは別にあるようです。多分CRTCとVRAMのアドレスバスに割って入って、CRTCがVRAMレイア0の上半分(00000H～20000H)にアクセスするときのみオフセットが適用されるようです。1画面モードではVRAMを互い違いに読むので、このオフセットが適用されると縦じまが入るみたいに画面が乱れます。が、本来FM-R互換モード以外でこのビットを使うことは無いはずなので2F以外だと動作が違うかもしれません。

さらに、画面モード1(FM-R互換モード)以外では明らかにオフセットはちょうどVRAMの半分, 20000Hなのですが、画面モード1だと縦方向に12ピクセル、横方向に320ピクセルずれるんですね。計算すると、画面モード1のときだけ203A0Hのオフセットになるという謎な挙動を示したのですが、この3A0Hがどこから来たのか謎です。

ただ、おそらくこの3A0Hのオフセットを気にするアプリケーションは無いだろうと思ったので津軽では画面モードにかかわらずちょうど半分20000Hで割ってます。それから画面が互い違いに乱れる状態も実機に忠実に再現しようかと思ったのですが、それだとレンダリングでピクセル単位で加算と論理和が増えるし、そもそも未定義の動作なので再現してません。

2020-10-19 03:08:07

>13 山川機長さん
I/O 0xFF82のbit6って何だっけと思ってXM⑪のソースを見てみたところ、400ライン/200ライン設定でした。おそらくFM16β/FMR-50との互換性を持たせるために必ず1(=400ライン)を書き込むことになっているんだとは思いますが、TOWNSでは何の意味もないですね。

2020-10-20 16:59:52

なるほど、FM11のI/Oを見て意味を確認するという手があったんですね。さすがです。いやあ、意味がないかどうか、とりあえず4ピクセルまたは2ピクセルずつ互い違いになる現象を利用したプログラムは確認できてませんが、400/200ラインの選択も非公式にできるのであれば、4段階で画面を崩すことができるので、その気になればこれを使って画面がDissolveするようなエフェクトを書くことも不可能ではないかもしれません。ひょっとするとそれが意味を持つプログラムも見つかるかもしれないですね。見つかったら面白いですが、エミュレータ泣かせですね(^_^;)

2020-10-22 01:11:17

ポートff82hのPS2ビットは、画面モード1でも20000hではないでしょうか

C000:0000にffを書くと画面右上に短い白い線が引けるのですが、
out 0ff82h, 37h
でどこかに飛んで行ったものが、
out 440h, 11h
out 443h, 80h
で元の位置に戻ってきますので。

CRTCには画面0, 1共通にアドレスの最上位を反転する機能があり、
画面0側はPS2ビット、画面1側はスプライトコントローラに繋がっているのかなという気がしています。
(赤本には44chのPAGEビットでスプライトコントローラ側の表示ページがわかるようなことが書いてあるのですが、これはかなり怪しいですね。SPD0=1のBUSY中にSPENを変更していると、描画中の側が表示されているような…)

2020-12-09 03:05:39

×右上
〇左上

2020-12-09 03:10:28

pinさん、

PS2ビットがVRAMのアドレスにどういうオフセットを加えるのかは、ちょっと謎です。ひょっとすると機種ごとに挙動が違う可能性もあるかもしれません。Towns 2Fで、EGBを使って画面モードを16色モードに設定して、仮想画面全体の左端に16ピクセル単位で上から下までY座標を書き込んだうえでPS2ビットで表示がどのように変化するのか見たのですが、もしも、20000Hのオフセットなのであれば、文字は左端で"256"が見えると予想していたのですが、256は見えたものの、文字は画面中央に寄ってしまいました。このことから、PS2ビットを反転させたときのオフセットは20000H＋数ライン分＋半ライン分のバイト数という推測をしているのですが、なぜこの半ライン分のずれが起こるのか解明できていません。おそらくVRAMとCRTCの間になにかひとつ噛んでいて、アドレスを変換しているのではないかと見ています。が、とりあえず今のところPS2フラグによって発生するVRAMオフセットを具体的に前提としているソフトウェアは発見できていないので20000Hということにしてました。

2020-12-10 10:49:33

ちょっと試してみました https://github.com/pinterior/ff82ps2

https://imgur.com/a/Yd9y1zR
MA では 20000h bytes = 40000h pixels = 409 lines + 384 pixels という計算結果とあっているようです。
(画面モード1では1ライン320バイトなので)

2Fでは256が画面最上部付近に表示されていたのであれば加算量は 14000h程度 + 左右位置の分でしょうか。

2020-12-10 23:17:17

おおなるほど！あ、そうか。画面モード1だと1ラインが2^Nバイトじゃなかったですね。確かに。ということは20000Hで合ってるんですね。

テストプログラムは、確かX,Y=0,0に数字の0の左上端が来るようにプリントしたと思います。僕はPS1=1にしたとき256がちょうど画面左上端に出るものと予想してパッドのボタンでPS1を1に切り替えたら右に半分ずれたので面喰いましたね。謎が解けました。ありがとうございます！

2020-12-11 05:17:33

津軽弁をなんとかしようと思って、F-BASIC386に入ってる FM_1.FMB を使ってUNZと津軽で音を比べながら何が変なのか探していたのですが、ひとつはリリースの時間の計算がオーバーフローしていたので、それは直して、Feedbackの計算で /16 とするべき(多分)ところを /32 としていたようで、実際 /16 にしてみたら、FM_1.FMBとほとんど同じになりました(と、思う)。Emerald DragonのBGMはまあ大体前から結構自分では十分と思っていたし、Strike CommanderのBGMもこの修正で結構本物に近い歯切れの良さが出るようになった、と思うのですがSuper大戦略のイントロがどうしても似ないんですね。うーん、何が違うんだろう。一番最初の「ドゴドゴドゴドゴ」と入ってくるところが、津軽弁だとどっちかというと「ぶくぶくぶくぶく」と溺れてるような音になってしまいますね。メロディももう少しシャキシャキっとした音になるべきところがちょっと弱いですね。

立ち上がりが遅いのかな。Attackの立ち上がり以外のそれぞれのセグメントの時間の計算はデシベルスケールで線形でよさそうなのですが、Attackだけは非線形ですよね。XM7のCiscさんのソースを見ると明示的に時間を計算せずにボリュームを増やしていってそれが一定の値になったところでAttackの終わりと書いているようだし。

2020-12-14 13:28:03

しばらくこちらの方には顔を出していませんでした。申し訳ないです…

GitHubのソースにはまだ津軽弁の更新が反映されていないようなのでこちらでフィードバックの実装だけ変えて試聴してみたのですが、ほとんどのデータではエンベロープを除いてはいい感じになる一方で、FM音源によって矩形波を近似する際にAlgorithm 5を使ったデータで試してみたら変調過剰になったようでかなりノイジーな音になってしまいました。また、版権の問題から公開できない某データに関してはFM音源でノイズ(っぽい音。FM77AVのプリセット効果音の波の音(@59でしたっけ?ワイングラスの@65は結構多用するのですぐに出てくるんですが)みたいな感じです)を出しているはずが妙な音になってしまいます。

確かAttackのみ非線形であとはdBスケールで線形、前回のKey Offで完全にキーオフされていた場合に限りEGを最初から計算、完全にKey Offされていなかった場合は前回のEGの計算結果を元にして変化させていく…でだいたいあってたと思います(最近fmgenをいじってなかったので自信がない)。

特に版権的に問題無さそうなMSVデータ+ViVA(MSVプレーヤー)をまとめたディスクイメージがあるので、UnzのFM音源コア(fmgenではなくMAMEのfm.cベースのようですが)と津軽弁の音の違いで検証のために必要であればメールで送ります。

あと、fmgenを参考にするのであれば、XM7カスタム版と一緒にciscさんオリジナル版を参照されてはどうでしょうか?
XM7/M88max用カスタム版fmgenは概ね最終版のfmgenと一緒ですが、波形補間機能が再実装されているほか、SSG-EGの実装がオリジナルfmgenと異なる独自実装で、繰り返し波形などに対応しています。なんでこうなったのかというと当初XM7で使われていたfmgenはほぼciscさんオリジナル版ベースだったのですが、「FM77AV版スペースハリアーの爆発音が違う」とのご意見をいただき、調査してみたところ当時のfmgenにはSSG-EGが実装されていなかったため、こちらで独自解釈して実装を進めたためです。この後オリジナルfmgenでもSSG-EGの機能は一部実装されたのですが、繰り返し波形などには対応していないため、PC-8801用ゲームでも「FIRE HAWK」の4面(…だったかな)の曲ではオリジナルのM88とこちらでWindows Mobileに移植したM88(M88max)の最終盤では音が違う、と言うことになってしまっています。

http://retropc.net/cisc/m88/download.html

2020-12-15 13:14:55

いえいえ、こちらも学期末でかなりいろんなものが放置状態になっていました。

SSG_EGは津軽弁もまだ実装してないです。あと、FM77AVのプリセットの@59ってFM_1.FMBの@59と共通ですかね？その音だったら結構似るようになったと思います。あ、でも波の音ではなかったような気がしますね。というと違う音かな？あとでPUSHしますね。

今朝、Sustain/DecayからReleaseに移行するとき20msロスする(したがってReleaseに入った瞬間にガクっと出力レベルが階段状に落ちる)バグを見つけて、Super大戦略の音はかなり良くなってきました。メロディの音がちょっとひ弱に聞こえる問題はまだ手をつけてないですが、オープニングの「ドゴドゴドゴドゴ。。。。」という音は、FB=7でslot 0が発散してしまう問題 (XM7で同じ音を出してみたら slot 0 は発散してない)問題を解決するとほぼ本物と同じに響くようになりそうです。

フィードバックに関しては、7月8日のメモでかなり調べて、発散が始まる条件は、

dt<-dY {dt=1/samplingFreq, dY=C*(y(i+1)-y(i)), CはFBの値によって決まる}

であるということまで究明して、同じフィードバックでもサンプリング周波数によって発散しやすさが変わること、また、出力の解像度が低いと dY=0 で踏みとどまることで発散の発生が遅れるかもしれない、ということまで解明しました、ということをさっきメモを見て思い出しました。

サンプリング周波数dtが小さくなると、左辺は小さくなり、単位時間が小さくなるとYの単位時間あたりの変化 dY が小さくなるのでマイナス符号がついている右辺は大きくなり、条件が満たされやすくなるので、発散しやすくなると見ています。

というと、このサンプリング周波数 dt はなんであるか(厳密には1/dt)、ということになるのですが、津軽弁の都合で44.1KHzの整数倍以外にしようと思ったらちょっと大変(もやもやと大変じゃない実装があるような気がしているものの、いまいち脳内で具現化しない)なので、最も近い dt を選ぶしかないのですが、MHzのオーダーではないはずなので、YM2612に入っていくベースクロックでは無いと思います。

というところで止まってますね。

オリジナルのfmgenは、参照するといいのかもしれないですがとりあえずFM77AV用にFM音源のトーンを出してサンプルするためのF-BASICのコードを書いてしまったので、とりあえずXM7で調べられる範囲ではこちらを使おうと思います。(またFM77AVのエミュレータによってFM TOWNSエミュレータが良くなるというのがなんとなくうれしい)

ディスクイメージはあるとありがたいですね。ひょっとして、Ch3, Ch6の特殊モードを使っているデータもあるでしょうか？まだ対応していないのですが、使ってる例題にまだ遭遇していないので、入っているとありがたいです！

2020-12-16 07:22:21

Super大戦略のイントロのBGMなのですが、いまいち音が弱い原因を探していたのですが、壁に当たってしまいました。以下のような設定なのですが、Slot 0のTLは33、Slot1,2のTLは42,36となっていて、これはdB Dropなので、数字が大きい方がAmplitudeは小さくなるはずです。ところが、XM7で同じ設定で音を出すと、Slot0のAmplitudeがSlot1,2よりもはるかに小さくなってしまいます。

試しに津軽弁でSlot0のTL=40としてみたところ、XM7とほぼ一致する波形が得られました。fmgenも津軽弁も1.0=8192のスケールで出しているようで、絶対値を比べても Slot1,2,3は津軽弁と一致しているのに、Slot0だけfmgenが出すAmplitudeは津軽弁が計算するAmplitudeのほぼ半分になってしまっています。何か思い当たることありますか？今fmgen.cppを読んでいるのですが、Slot0だけEnvelopeの計算に特殊なことをしているようでもないですし。多分向こう数日はこの問題で悩み続けそうな勢いなので、何か思いつく点がありましたら、よろしくお願いします。

CH:1 F_NUM= 1098 BLOCK=5 FB=7 CONNECT=2 L=1 R=1 AMS=0 PMS=0 ActiveSlots=0F
SLOT:DT=3 MULTI= 2 TL= 33(24dB) KS=1 AR=29 AM=0 DR=31 SR= 0 SL= 0( 0dB) RR= 5 SSG_EG=0
SLOT:DT=5 MULTI= 6 TL= 42(31dB) KS=1 AR=29 AM=0 DR=31 SR= 0 SL= 0( 0dB) RR= 4 SSG_EG=0
SLOT:DT=1 MULTI= 4 TL= 36(27dB) KS=1 AR=29 AM=0 DR=31 SR= 0 SL= 0( 0dB) RR= 5 SSG_EG=0
SLOT:DT=0 MULTI= 4 TL= 7( 5dB) KS=1 AR=10 AM=0 DR=31 SR= 0 SL= 0( 0dB) RR= 6 SSG_EG=0

2020-12-16 12:41:02

YM2612についてはメガドライブ方面での研究成果があるようです。

http://gendev.spritesmind.net/forum/viewtopic.php?f=24&t=386

面白いハードウェアですね。

http://gendev.spritesmind.net/forum/viewtopic.php?f=24&t=386&start=105#p5716
http://gendev.spritesmind.net/forum/viewtopic.php?f=24&t=386&start=150#p6096
http://gendev.spritesmind.net/forum/viewtopic.php?f=24&t=386&start=705#p27098

2020-12-16 23:40:25

ありがとうございます！一応、メガドライブでの研究成果とする資料は参考にしているのですが、多分そのフォーラムから出た資料かもしれませんね。

しかし、何が違うんだろう？とさんざん頭を悩ませていたんですが、

873: // Should consider DETUNE.

まだDETUNE実装してなかった！という根本的な問題にたどり着きました！

実装したつもりだったんですが(^_^;)つもりは恐ろしいですね！音が似てるんだけど微妙に違うのはこれが結構大きかったかもしれないので実装してみます。

2020-12-17 08:20:40

やっぱ先人は偉大ですね。fmgenのソースで、フィードバックに入れる値を過去2度のサンプルの平均にしている(しかもビットシフトに組み込むことでゼロコストで平均取ってる)ので、なぜだろう？と、思っていたのですが、津軽弁のSlot0がどうしても発散する問題で、発散の仕方が1サンプルごとに上下に振れて間を取ると大体滑らかな曲線になるので、Ciscさんは過去2サンプルの平均を取ることで平滑化してたんですね。

発散する波形を見ながら、これスムージングかけてやれば良さそうなんだけどもう出しちゃった波をしかも発散してる箇所だけスムージングかけるなんてできないしなあ、と、考えているうちに過去2サンプルの平均を取る意味が理解できました。

この方法で発散問題も解決できました。まだいまいちな音もあるんですけどね。数日前より結構良くなってきたように思います。後ほどPUSHしますね。

2020-12-17 14:19:26

DETUNE実装していまいち響きが変だった音もかなり良くなり、Feedbackに入れる値を過去2サンプルの平均にすることでpremature divergenceも防止できて、よく聞くと「ちゃちゃちゃちゃっ」と鳴ってたノイズが消え、F-BASIC386のFM_1.FMBでここまでトーンが似てきて、、どうしてSuper大戦略のイントロの音の深みがいまいち出ないのか、と、思って、UNZでCh3 (僕はチャンネル0番から数えるからUNZ上だとCh4)以外をMuteしてWindows+Gで動画撮ってVLCでMP3にしてAudacityで波形見てみました！

見ると、一つ目のトーンではトーンの途中から変調がかかり始めるのですが、二つ目のトーンはトーンの先頭から変調がかかっていることが判明しました。ということは、モジュレータスロットは止めずにキャリアスロットだけオフ・オンしているっぽいですね。Super大戦略って二曲しかないのにそんな凝ったことしてたのか。印象的な曲になるわけだ。というか98バージョンよりも88バージョンよりもTOWNSバージョンのSuper大戦略の曲が一番良いと僕は思ってます。

ついに、スロット単位のオン・オフを実装するときが来てしまったか。。。。というわけで、引き続き精進します。冬休みになったし。

2020-12-18 03:05:34

自己フォローアップです。

すみません、Super大戦略が特殊なことをしているのかと思ったら、実はそうでも無いんですね。さっきXM7で波形を出して確認したのですが、Key Off->Key Onしたとき、前のトーンがまだ鳴ってる途中だと、新しいトーンをゼロから始めず残ってる音のレベルから音を始めるんですね。いずれにしても、その場合だとスロットごとにタイマーを分ける必要があるので、やっぱりスロット単位でのコントロールが必要なのでその部分は必要ですね。(しかし音が鳴ってる途中から次の音を始めたらどうなるとかはさすがにマニュアル見ても書いてなかった)。多分、この修正を加えたらSuper大戦略もあの力強い音色が再現できるのではないか、と、思ってます

2020-12-18 07:30:45

リリース出しました！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

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

CD-ROMエミュレータの制作のためにCD-ROMドライブのコネクタ～ドーターカード間の波形を計測していましたが、いまいち納得がいかないのでMX本体側の回路を見るためにMXを分解しています。
良い機会だと思ったので、メモリカード周辺やその他の回路を見ていたのですが、MXの基板に少々大きめのソケットに刺さったP-ROMが有ることを今更気づきました。

SYSROMにしては容量が大きいので、?と思っていたのですが、漢字ROMやCドライブ等を考えるとある意味納得のいく大きさなのかもと思っています。
(CPUバスに直結せず、メモリコントロールのASICにぶら下がるのであればCPUから見たアドレスは如何様にもなるはず)

折角ソケットに入っているのですから、機会があれば是非吸い出したいと思っていますが、場合によってはSYSROMの内容を改変してブートプロセスや何かのコントロールを変更する手だてが出来るのかもしれません。 なお、全てのモデルでP-ROMがソケットかどうかは確認していませんので、あくまで現時点ではMXに限りますけど。

2022-03-14 15:00:16

HDDから発掘された太古の .com ファイルに基づき、CMOS 3c1ah についての情報を wiki に記載しました。
1を書いておくとメモリカウントが速くなります。

エミュレータで不良メモリが積まれていることは考慮しなくてよいので、CMOSファイルが無いときのデフォルトは1でもいいかもしれませんね。
(ROMファイル吸いだし元の世代によっては機能しないかもしれませんが)

2022-03-21 20:03:37

CFカードのアクセスを調べていました。 やっとそれらしい事が判りました。

まず、PCカードアダプタに刺そうがCFカードはCFカードであり、CFカードとしてのアクセス手順を踏む必要が有りました。
CFカードはカード内にコントローラが搭載されていますので、メモリカードとしてのSRAMカードのようにメモリがそのまま見えているわけではないのでメモリに対する
アクセスはステータスを参照しながらてコマンドを送る必要が有りました。 その、コントローラのコマンドやレジスタの配置についてはCFカード自体のデーターシートに
記載されています。

問題は、#REG信号を操作する必要がありますので、CX以降でないと駄目だと思いますが・・・・ 元のツールだとモデル2でも読めたような気がするので此処は再確認が必要です。

また、上記のようなアクセスとなりますので当然のことながらブートメディアとしては使用できる筈が無いことは明白です。

もう少し詰めてみて進展が有れば報告します。

2022-06-06 18:31:45

知り合いが2Fをゲットしたのですが、電源ボタンを押しっぱなしにしないと電源が落ちてしまうそうです。他のモデルと同じ構造だとすれば、電源オンのラッチは電源ユニット内にあるのではないかと思うので、電源を交換するか、あるいは電源ボタンを押しっぱなしなら動くのであれば、電源ボタンを物理的にラッチするものに交換してはどうか、という修理案が出ていますが、電源を交換する場合、本体側のコネクタ形状、ピン配列ってどこかに情報ありましたっけ？CXだと修理マニュアルなるものが売っているようなのですが、果たして2Fの電源が同じものなのかどうか。電源ユニットを修理しようとしないでAT電源から12V, 5Vを取ってくるようなケーブルを製作するのが無難ではないかと思うのですが。誰か知ってます？

2022-07-19 23:19:58

>48 山川機長さん

2Fではなく20Fですが、下記に修理をされた記事が有ります。

https://ameblo.jp/hibikipc/entry-12722401133.html

この方の場合、セラミックコンデンサの交換で復活したようですが参考になるかもしれません。
取り敢えずは似たような状況になっていないか目視チェックをしてみたらどうでしょう?

2022-07-21 09:23:55

おおなるほど！ありがとうございます。リンク送ってみます。

2022-07-22 02:09:47

きっちりとした資料を残していないので間違えているかもしれませんが、2F、20F、CXは同じ電源だったように思います。
メモに取っておいたコンデンサリストが同じでした。
どこかのサイトでピンアサインを見た事があるのですが思い出せません。どこだろう。
20Fの電源写真は検索で見つかるので、写真で比較すると良いかもしれませんね。

「FM TOWNS II CX/HR 修理マニュアル」につきましては、主な内容は分解手順とコンデンサ交換でして、これから分解するとかコンデンサリストが欲しいのでしたら丁度いいかもしれません。
電源のピンアサインやAT電源化の記事はありませんでした。

2022-07-24 12:27:57

ピンアサインは下記でしょうか?

http://hp.vector.co.jp/authors/VA018718/towns/connect/pinasgn.htm#POWERTOWNS20F

ただ、3代目,4代目と記載されていますので2Fと同じかどうかは不明ですのである程度テスターと目で2Fのパターンを辿って確認した方が良いと思います。

2022-07-25 15:44:32

おおなるほど！このリンクも送ってみます。まだ時間の都合で解体できていないようです。

2022-07-26 07:02:00

ありがとうございます。
ここです！
よく参考にさせて頂いているサイトなのに気づけませんでした。

2022-07-26 21:29:36

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

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

はじめまして。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