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

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しようとするととりあえず止まるようにしてあるのですが、あまり使ってる場面なさそうです。試しにリダイレクトとか使ってみたけどその部分に入ってこないし。

> nabe@abkさん、

なるほど！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

Windows 3.1が起動したのにマウスカーソルが出ないのはなぜだろう？と、思ったら、どうもHigh-Res CRTCはハードウェアマウスカーソル持ってますね。しかも、どうやら、Reg0への書き込みが、Byte-WriteだとCRTC2 On/Offだったりするのに、Word WriteだとマウスのX座標になるようです。というか、HRのふりをさせればカーソル出るのかな？と、言ってないで津軽にも実装するかな。

2023-03-26 09:43:38

本体のメインDMAの謎が深まってしまいました。津軽開発メモを見てもこの点に疑問を持ったことは無かったようで、ドライバなどが転送バイト数-1を書いていたのでそういうもんだろうと思ったのですが、ハイレゾPCMのDMAと比べてみて、謎になってしまいました。

まず、メインDMAの転送バスサイズですが、起動時、I/O 00A0Hに3を書き込んでいることを確認しました。ビット1がバス幅を決めるビットということで、赤本によると1なら16 bit、0なら8 bitとあります。しかし、バス幅が16ビットだとすると、転送バイト数は(カウント値+1)*2になるはずです。ただ、デバイスが途中で転送を止めてしまったらカウントが途中で止まるだけで、メインDMAはIRQを出さないので問題は無くて、内蔵CDだけはDMAE INTを出しますが、DMAEと言ってるだけでDMAカウント関係なくセクタ読み込みが終わったタイミングでIRQを出しているかもしれません。

この仮説を確認するべく、CDからDMAでセクタを読み込ませる実験プログラムの最後にDMAカウントを表示させてみました。カウント値には0x7FFを書きますが、セクタ長は0x800バイト。1カウントあたり2バイト転送されているのであれば、最後にカウント値は0x3FFで止まっているはずです。

ところが、実機MXで確認したところ、0xFFFF(ターミナルカウント)に達していました。2048バイト転送してカウントは2048減っていました。だとすれば、DMAのバス幅は8ビットであるはずです。

そうであると、初期化時I/O 00A0Hに3を書いていたのは何だったのかということになるのですが、もしも赤本の情報が誤りで、bit1=0の場合が16ビットであるならば説明が着きます。ところが、DMA 71071のデータシートには、初期化コマンドのビット1が1のとき16ビット、0のとき8ビットとあり、赤本の情報と一致しています。

あるいは、DMACが1DMAサイクルでカウント値を2だけデクリメントする可能性があるならば、説明がつきますが、データシートのどこにもそんなことは書いてありません。

一方、ハイレゾPCM用DMAは16ビットバス幅ということになっていて、カウント値には常に(転送バイト数/2)-1が書き込まれるようです。0x7FFを書き込むと転送バイト数は0x1000になってます。I/OがほとんどまったくメインDMAと一緒なのでおそらく同じDMACを使ってるものだと思うのですが、どちらもバス幅16ビットならば、なぜメインDMAは転送バイト数-1を、ハイレゾPCM用DMAは(転送バイト数/2)-1を書くことになってるのか。

残る可能性ですが、I/O 00A0Hのビット1がDMAにつながってなくて、このビットには何を書き込もうがDMAは8ビットモードになっているという可能性もありなのですが。謎です。

2023-12-12 14:07:33

ちょうど今ヤフオクに出ている20Fのメインボードを見ると、それっぽい52ピンQFPがCPUの右下方向にありますね。
位置に違和感はありますが、赤本によく書いてあるPICの「8259A相当」、PITの「8253相当」とは違い、本物のμPD71071でしょうか。

ちなみにFMRの白い本においても16Bは「1:16ビットバス(固定)」となっており、カウントレジスタはバイト数とされています。(こっちはこっちで、-1が抜けている気がしますね)

2023-12-13 05:01:34

DMA問題ですが、CDREAD.EXPでDMAアドレスのログを取るようにしてみました。これが非常に興味深くて、2048バイト読む間に、DMAアドレスの変化は9回しか検出されませんでした。

最初が00067082Hとなってますが、これはI/O 00A4Hに00067000Hを書き込んだ直後に読んだ値なので、00067000Hが返ってくるはずが、132バイトも先に進んでます。
00000000 00067082 00067084 00067189 0006728E
00000010 00067393 00067498 0006759D 000676A2
00000020 000677A7 00067800

そもそも、2048バイト転送しているので、1バイト単位なら2048回、2バイト単位なら1024回変化を検出できるはずなのに、たったの9回しか変化が見えないとは。

DMAのアドレスのログを取って、2バイトずつ進んでいれば16ビットバス幅で転送しているはず、と、思ったのですが、なんとたったの10回しかログが出てこなかったということは、これは、DMACとCPUの間に何か挟まってる疑いですかね。16-bitバス幅で転送するけど、CPUからはバイト単位で転送バイト数を指定できるようにするみたいな。

ここまで書いておいてなんですが、MXだから倍速CDだから実はCDキャッシュにセクタが貯まった時点でものすごい勢いで流れ込んで来てる可能性もあるのか。なかなか難しいな。

いや、だとしてもDMAにアドレス書き込んだ直後にリードして130バイトも進んでるってのはいくらなんでも変だな。

2023-12-14 00:45:49

赤本とuPD71071のデータシートを読んでみたのですが、新PCM用のDMACと従来のDMACは別に考えた方が良いのかもしれません。

従来のDMAC(uPD71071)に関しては、データデータシートにカウンタのデクリメントはバイト転送,ワード転送に係わらず"-1"であると言う表が有ります(表4-4)のでこの記載に間違いが無ければワード転送時には転送バイト数の半分の値を設定する事となります。
ただし、データシートを読み返していて気づいたのですが、イニシャライズコマンド(I/O 00A0H)のbit1を"1"にして16bitバスである事を設定する事と、転送単位は別のようです。
転送単位(16bit or 8bit)は、モードコントロールレジスタ(I/O 00AAH)のbit0により行うようです。(要はI/O 00A0Hでバス幅を,I/O 00AAHで転送幅を設定)

新PCMのDMACに関しては、DMACとして最低限必要なI/O以外の従来DMACのI/O割付が無い事からuPD71071と同等のステータスレジスタを持った別のものの可能性が有ると思います。
これは、上記のイニシャライズレジスタやモードコントロールレジスタ等の外付けDMACとして必要なI/OがCPUのI/Oアドレスに無い事からも想像できます。
(勿論サブCPUなりが行っている可能性も有りますが、ゲートアレー化する際にその他のペリフェラルと一緒に手持ちのDMACを搭載したと言う方が理に適っていると思います)

最終的には機能的に同じものかも知れないのですが、今のところは最悪別の物の可能性も有ると考えた方が良いかもしれませんね。

2023-12-14 10:57:58

おおなるほど！そのビットは、津軽はばっちり無視してました。津軽書いてて、うっかり無視してたビットが動かない原因になってて何日も発見に苦しんだことがありましたが、このビットは無視したまま動いてましたね。

無視して動いていたということは、TOWNSのメインDMAは常に1バイト転送で運用されてるということですね。これは、多分データを受け取るメモリは32ビットバス幅を持っているので、送る側が対応していなかったということでしょうか。

ハイレゾPCM用DMACで00AAHに対応するI/Oは、0511Hですが、ビット0と1がDMA End Interruptの設定のビットになってるので、違ってますね。しかし、00AAH / 00BAHのビット1で転送単位を変更できるということは、ひそかに使ってなかったDMACのチャンネルのひとつをハイレゾPCMに使ってたりしないかな。とか思ったけど起動中に00BAHに何も書き込んでないようなので違いそうですね。

2023-12-14 13:19:28

TOWNS Linuxのパッチを見ると、以下の三条件が満たされるとcountを半分、モードの最下位ビットをONにしています
- WORD転送可能 or CX
- CONFIG_SCSI_FM_2BYTE_DMA有効
- 転送先とサイズがともに偶数

ところでWORD転送可能かどうかを示すフラグのI/Oポートですが、赤本(UG等の差分のところ)では 0034h となっているところ、TOWNS Linux では 0xc34 を使用しており、
これは赤本の誤植のにおいがします

TsugaruもWORD転送できるふりをすると、DOS6等新しめのIO.SYSはやってくれるかもしれませんね

2023-12-14 16:42:33

メモリは大丈夫なのでI/O側がワードアクセス可能か不可能かで転送単位を決める必要が有るのだと思います。
TOWNSのI/Oを見る限りではワードアクセスできるのは限られていますし、ワードアクセスしか出来ないI/Oも無さそうなのでバイトアクセスで問題が出ることは速度以外に無いのではないでしょうか?

DMACに関しては1992年当時で富士通としてIntel8237A相当のDMACを内蔵した素子や8237A自体もセカンドソースとして生産していたみたい(MB89237やMB89395)なのでuPD71071(Intel8237Aが基)と同じような物を作ることは技術的には出来そうな物ですが、uPD71071を使ったんですよね。 セカンドソースを作っていると言う立場上亜種(20bitアドレス対応)は作れなかったのかも知れませんが。

uPD71071のデータシート上では転送先のアドレスについても16bit転送時は偶数にするよう記載が有りますが、奇数の場合は-1して補正するとの記載も有りますので奇数アドレスでも受け付けてはくれそうです。 意図したアドレス-1のアドレスにもアクセスされちゃいますけど。

赤本のSCSIモードレジスタに関してはpinさんのにおいを私も感じます。 SCSI関連だしこのレジスタだけ0034Hなのは不自然ですよね。

2023-12-14 19:12:41

DMAのワード転送ってワード転送対応SCSI搭載機から使われるようになったのかな。
プリンターポートもDMA対応でしたよね。。。多分8bitでしょうけど。

>132バイトも先に進んでます。
これは何故なのでしょうね。
シングルモードでI/O→メモリの場合、カウント毎にカウント値を取得出来そうな気がするのですが。
DMAと周辺機器が爆速すぎて、CPUが71071へI/Oリードするより先に周辺機器(CDコントローラー？)がDREQ#をアサートして、バスの使用権をDMACに渡しているなんて事あるのかな。

2023-12-14 20:35:30

>80 WINDYさん
TOWNSのDMACがなぜμPD71071になったかを予想すると、単にベースとなったFMR-50/60/70がμPD71071を採用していたからだと思いますが…。

2023-12-17 11:34:23

> 2048バイト読む間に、DMAアドレスの変化は9回しか検出されませんでした。
> (中略)132バイトも先に進んでます。

CD-ROMから読み込んだデータはエラー訂正が完了してはじめて転送可能になるので、転送元はレーザーピックアップ(遅い)ではなくどこかのRAM(速い)なのだと思います。
一方CPUは(たとえ486でもDMAが動いている状況下ではキャッシュが invalidate されるはずなので)DMAとDRAM帯域の取り合いをこなす必要があり、、
命令の読み込みのみならず、レジスタに乗り切らなかった変数にアクセスのも一苦労という状況ではループ毎に100ほどカウンタが進んでしまうこともあり得るかな、と。

2024-01-25 20:48:34

今ヤフオクに出ている高速通信ボードなるものですが、

https://buyee.jp/item/yahoo/auction/f1128094475?conversionType=search_suggest

このヤフオクの記述を見ると115200bpsまで行けるようなことが書いてあります。これ、うちのMXにも同じものが入っていて、そんなに速いんだったら積極的に使いたいのですが、I/Oポートが何番か誰か知ってます? 総当たりでやってみるという手も無くはないですが、あらぬデバイスに変な信号を送ってしまうのも嫌だしというか。ポートさえわかれば8251互換ぽいのでなんとかなりそうなのですが。あー、でもBaud Rateの制御がわからないか。

この出品者、メーカーサイトの過去のアーカイブを参照できるって言ってるけど、archive.orgのWayback Machineでは何も見つからなかったけどな。

2024-03-11 22:01:26

>84 山川機長さん

このボード、私も使っていました。
一応、WaybackMachneで、www.urbancorp.co.jpを指定して1998年1月28日付けのアーカイブは有りました。
アーカイブには取扱説明書もあり、そちらにはI/Oアドレスやボーレートに関する情報も有ります。
どちらもDIP-SWによる設定ですね。(ボーレートは倍率)

2024-03-12 09:56:47

おおなるほど！今のアーバンコーポレーションと違うURLだったんですね！(そもそも会社も違うんだろうか?) ありがとうございます！やってみます！

2024-03-12 12:52:22

津軽でTOWNS用Linuxを起動しようとしているのですが、非常に興味深いんですね。CD-ROMドライバ(多分。I/O 4C0Hとかいじってるから)の中で、一定時間ウェイトを入れるために下のようなことをやってるんですが、

MOV EDX,[ESP+04H] ; Wait EDX*10ms
IN AL,60H (TIMER_INT_CTRL_INT_REASON)
SHR EAX,02H
AND EAX,07H
OR AL,80H
OUT 60H,AL (TIMER_INT_CTRL_INT_REASON)
LOOP:
IN AL,60H (TIMER_INT_CTRL_INT_REASON)
TEST AL,01H
JE LOOP
IN AL,60H (TIMER_INT_CTRL_INT_REASON)
SHR EAX,02H
AND EAX,07H
OR AL,80H
OUT 60H,AL (TIMER_INT_CTRL_INT_REASON)
DEC EDX
JGE LOOP
RET

このときIF=1でタイマー割り込みもマスクされていないので、本来であればTM0OUTが出た次のクロックには割り込みがかかり、割り込みハンドラ内でTM0OUTをクリアしなければIRET直後にまた割り込み発生の無限ループになるので、必ずTM0OUTをクリアしてからIRETするはずです。

そうであれば、このビジーループのINT AL,60HはTM0OUT (bit 0) をほぼ検出できないはずです。津軽の中ではそのようになっているので、このビジーループで果てしなく長い待ち時間がかかってしまうのですが、本当にそうなのかと思って、試しに実機で同じことをやってみました。

そしたら、実機だとポーリングできちんとTM0OUTが取れるっぽいんです。I/O 60Hから読んだ直後はタイマーの割り込みがかからなくなるとか? という仮説も考えたのですが、INT 40Hを_setpvectでテイクオーバーして割り込みがかかった回数をカウントしたところ、INT 40Hは普通に1秒あたり約100回入ってきてました。

INT 40Hが普通に発生しているのもおかしくて、ビジーループ内でもTM0OUTをクリアしているので、クリアされてしまった分については割り込みはかからなさそうです。が、10ms間隔できちんとかかってきてます。

したがって、割り込みも10msごとにかかるし、ビジーループでTM0OUTも検出できる、TM0OUTは割り込みハンドラとビジーループ両方でクリアしている、でも実機ではポーリングも割り込みも同時並行で実行できる、というまったく謎な状況で頭を抱えてしまったんですが、これはどう解釈したもんでしょうかね?

2024-03-19 12:47:38

実は公開されてないけどI/O 60Hを読むと 6CH みたいなウェイトがかかって、待ってる間にTM0OUTが発生したらそれが見えるとかですかね?それだったら実機でI/O 060H読み取りの時間を計測すればわかるのか。

2024-03-19 13:05:35

↑という仮説も実機での実験により否定されました。がっくり。

2024-03-19 13:13:58

的外れでしたらすみません。
割り込みハンドラ内でTM0OUTをクリアしていない説はいかがでしょうか。
INT信号は、8253のタイマ0OUT→8259→I/O 0x60H→CPUのルートで来ていると予想しまして、
割り込みハンドラへ飛ぶ直前に8259のINT信号はLに下がり、TM0OUTをクリアしなくてもIRETの直後にループをしないのではないかと考えました。
I/O 0x60HのTM0OUTは8259からのINTをラッチしているのではなく、素通しもしくはブロックのみを行っているのかも。

2024-03-20 21:22:12

うーん、その可能性(素通り説)はずいぶん以前に考えたのですが、モード3だとアウトプットはデータシートによるとカウントの半分はHIGH, 残り半分はLOWということなので、素通りさせてしまうと周期の半分でTM0OUTが出続けることになってしまって多分そうでは無さそうです。非常にもやもやしたまま、I/O 60HのReadでタイマーのポーリングを入れることで一応この部分は突破して、今、

DC F1 FDIV(m64real) ECX

という、本来メモリオペランドが来るべきところにECXが出てしまっているインストラクションをどう扱ったもんかで止まってます。プログラマーズマニュアルを見たところGPを出すのかと思ったのですが、それだと違うようでした。実機でどうやってテストしたもんか今考えてるところなんですが。

2024-03-20 22:39:38

もう少し補足させてください。
素通りは8253の出力ではなく8259の出力を素通りさせている、と考えました。
8253を素通りさせますと仰る通り、モード３ではカウントの半分がHになりCPUに拾われてしまいますので。

8259はエッジ入力で割り込みを確定している可能性はなさそうです？
8253のOUTの立ち上がりで8259のINTピンがHになり、8259のINT出力がCPUのINTRピンを通して入力され、実行中命令の最後のクロックでそのHが確定し、
CPUは8259から実際の割り込み元情報などを取得し、その後8259はINTをLにすると思いますので、
8253のOUTが割り込みハンドラ実行後もLにならなくても、8259のINT出力がLなのでIRET直後でもループにならないのではと考えました。

次の問題は私では考察する切欠すら見えない世界ですね・・・。

2024-03-20 23:24:57

おおなるほど。うーん、8259のINT出力って、0!=(IRR&~ISR)じゃなかったでしたっけ? IRRは外部からのリクエストなのでCPUがISRをクリアする前に割り込み要因を除去して立っているIRビットを消しておかないと、ISRをクリアした途端にINTがHになってまた割り込みがかかってしまうという解釈だったのですが。

どうもひっかかっているのが、300回ポーリングループを回している間に305回INT 40Hが入ってきてる点なんですよね。486の所要クロックは IN AL,060H が 14、TEST AL,1が 1、JE LOOPが 3なので、仮にIN命令の間にTM0OUTが立ったらポーリング成功なのであれば 14/(14+1+3)=82% の成功率、実際はIN命令後半でTM0OUTが立っても手遅れだと思うのでもっと低いはずなのに、取りこぼしはたったの5回、98%ポーリングに成功してしまってるんですよね。ただ、一応5回は取りこぼしているっぽいですが。

なお、FDIV問題は、Linuxのソースを見つけてきたら、対応箇所が __asm__("fldz ; fld1 ; fdiv %st,%st(1) ; fwait"); こうなってて、よくよく見たらopCode DChは次のバイトがF0～F7の場合は、FDIVR ST(1),ST(i)=FDIV ST(i),ST(1) ということに気が付いたので先に進めそうです!

2024-03-21 02:18:52

PITとPICについて調べて判った事を書き留めておきます。 間違いが有るかも知れませんのでそのつもりで読んでください。

PICのIRRについては、赤本のP58に"割込処理中は,その割込の情報はIRRとISRに保存され,割込ハンドラからのEOI(割込終了)コマンドを受けたとき消去されます。"とあり、EOI時にIRRのbitが消去されると理解できるように記載されていますが、他の資料やINTELのデータシートには"Upon receiving an INTA from the CPU group, the highest priority ISR bit is set,and the corresponding IRR bit is reset."と有り、該当の割込レベルが高い場合にISRのbitがセットされ、IRRのbitがリセットされると有りますので、IRRのリセットは割込処理を受け付けた時点でEOIとは関係なくリセットされるようです。(ISRのbitはEOIでリセット)

PICが割込を受けてIRRがセットされ、優先回路で割込通知が必要と判断された場合にISRのセットとIRRのリセットが行われISRなりのEOIでISRがリセットされる訳ですから次の割込が受け付けられる時間としてはISRなりの処理時間をも含む期間となり、山川機長さんの想定している時間よりもnsオーダーで見ると結構大きくなると思われます。

この辺の違いで実機との差異が発生している可能性は考えられると思われますか?

2024-03-21 13:09:39

おおなるほど。IRRは外からの入力そのままじゃなくて、内部レジスタなんですね。津軽だとIRRは8259への入力として実装してそれで動いてたから入力だと思ってました。ということは実機だとラグがあるので正しいということなんでしょうかね。

Linuxですが、一応FPU命令も突破して、ログイン直前まで来たのですが、CPUのハードウェアタスクスイッチングを使ってて詰みました。。。Linuxは相当初期のバージョン以外はソフトウェアタスクスイッチングを使ってると何かで聞いたと思ったんですが、バージョン見たら1.3.30。どうやらLinux for TOWNSはその相当初期のバージョンだったようです。さすがにWindowsよりもさらに需要が小さいと思われるLinuxのためにCPUにハードウェアタスクスイッチング実装するべきかどうか?

ただ、386ASMでFPU命令の使い方がわかったので、FPU命令のテスト書き始めました。(.387をはじめの方に書くか、-80387オプションだった)

2024-03-21 22:42:10

> IRビットを消しておかないと、ISRをクリアした途端にINTがHになってまた割り込みがかかってしまう

レベル入力ですと、その動作になると予想しています。
赤本を見直したところ、レベル入力固定と書かれていることに気付きまして、私の予想が外れている可能性が高くなってきました。

エッジ入力(ICW1のbit3を0)でしたら、8259は外部からの割り込み信号の立ち上がり瞬間のみを割り込みとして認識するので、INTピンがHのままISRをクリアしても割り込みとして認識せず、一旦INTをLにしてからHにすると次の割り込みとして認識すると考えていました。

2024-03-22 05:05:06

>aochanさん
>山川機長さん

ATも98もPICはエッジトリガなんですが、TOWNS(FM-Rも?)はレベルトリガなんです。
PCIはレベルトリガなので後にATはICWの設定は無効にして別にピンごとにトリガ種別を設定するためのレジスタが新設されたようです。(98もPCIが有ったので同様かと思われます)

上に書いたようにINTELのデータシートではIRRは割込を受け付けた時にクリアされ、それと同時にISRがセットされるのですが少々疑問なのがIRRはその名の通りリクエストレジスタなのでこの時点でクリアされてしまうとレベルトリガの場合はCPUから割込禁止を行っても次の瞬間にはINTがHiの場合は再度IRRにbitがセットされて連続で割込がかかってしまうのでは? と思うところです。
PITのモード3だとOUTがカウント設定値の1/2幅でONするのでOUTが出てPICが割込を受け付けた次の瞬間はまだOUT(=INT)がONでは無いのではと思いますが、如何でしょう?

2024-03-22 09:29:04

> PITのモード3だとOUTがカウント設定値の1/2幅でONするのでOUTが出てPICが割込を受け付けた次の瞬間はまだOUT(=INT)がONでは無いのではと思いますが、如何でしょう?
そうですね。実機の観測から考えるとPITのチャンネルゼロのOUTのRising EdgeでTM0OUTが立って、多分この値がI/O 60Hのbit0に出て、そこから実際割り込みがかかるまでにちょっとのラグがあるのはほぼ確定ですね。ラグがどのぐらいなのか計測する方法が無いか考えてるのですが。しかし、Windows 95まで走るようになってからもなお顕在化する実機との差異があるとは。というか、ポーリングでタイミング取るなら普通IFクリアしますよね。多分想像なんですが、このドライバ書いた人がIFクリアするの忘れたけどなぜか動いてしまってそのままになったというところではないでしょうか。

なお、一念発起してFPU命令大半を網羅するテスト書いて実機でサンプル取って比較したら一発で津軽と実機と結果が一致したので、結構FPUも再現性上がってきましたね。386ASMで直接FPU命令を書いたので、今まで遭遇してなくて対応してなかった命令もかなり対応しました。

うーん、Linux動かそうと思ったらハードウェアタスクスイッチングか。。。。モチベーションがあるような無いような。何より需要がない。

2024-03-22 11:30:39

>98 山川機長さん

仰っている"IF"と言うのは、CPUのFLAGSのIFですよね。
ISRの作りにもよるとは思いますが、割込管理BIOSではIFのクリアはユーザーが行う必要が無いようです。(赤本P553)

Linuxについては今現在もメンテが行われているようですので"意義"は有りそうです。(http://www.nurs.or.jp/~kurati/)
が・・・・ ハードウェアタスクスイッチングの実装難易度次第でしょうけど"Win95が落ち着いた時にモチベーションが下がってなければ"みたいな感じでしょうか?
ソフトウェアに関しては何もお手伝いできない技量な物がこんなことを言うのもなんですが。

386ASMでFPU命令をゴリゴリと書いたと言うことは・・・・ Blue Impulse SDKのバージョンアップかな? って(冗談)

2024-03-22 12:21:57

UPD8259Aの資料を見ていて解釈に迷う所もありましたので、そのまま転載しますね。
－－－－－－－－－－－－－
レベル・トリガ・モード
　このモードはICW1のビット3を用いてプログラムできます。LTM=1ならば、割込み要求はIR入力への
ハイ・レベルによって認められ、エッジは必要ありません。この割込み要求はEOIコマンドが発せられる前ま
たはCPUが2番目の割込みが起こるのを防ぐため割込みをイネーブルにする前に取除かねばなりません。
－－－－－－－－－－－－－

0x60Hは8253～8259の間にあって、IRET前にTM0OUTを0にする事でタイマ0のH出力をブロックする役割があるのかな。

そうなると、8253のカウントが完了してOUTピンがH出力にり、その後TM0OUTに1がセットされ、
次に8259のIR0ピンがHになり、最後に8259がCPUに対して割込み要求をしそうですから、
TM0OUTが1になる～CPUへ割込み要求が来る間にもラグが発生する余地があるかもしれませんね。

2024-03-23 05:17:48

JMPFによるタスクスイッチングだけサポートしたらLinux起動しちゃった。。。。

2024-03-23 10:26:09

おー、起動しましたか。お疲れ様です。
大変良い勉強になりました。

2024-03-23 14:09:53

Linux、動いちゃいましたか。 喜ばしいですね。

PITとPICなんですが、I/Oの0060H(割込制御レジスタ/割込要因レジスタ)にマスクビットやTM0CLRビットが存在しており各割込の許可やTM0要因のクリア,現在の状況を読み取れる等の機能やbitの割り振りやそもそも割込とは関係の無いSOUND出力制御bitが有るので外部回路が挟まっていると思います。

外部回路が入っているとするとPIC自体はレベルエッジなんですが、PIT出力の立ち上がりエッジを捉えて決まった幅のON信号として出力してPICに渡すことも可能ですのでTOWNSのタイマー回りの回路がそのようになっている可能性も有ると思います。
初代だと単独で8259相当が載ってるのかなぁ 載ってたら追えば判るような気がします。

2024-03-27 14:26:10

PICの件ですが、↓このサイトの情報ではIRRはEOI後にクリアされて新しい割込が許可されると有ります。
http://www.brokenthorn.com/Resources/OSDevPic.html

データシートが間違えていることはよく有ることですが、本当の所は実機の動作とコードから見る限り上記のサイトの内容が正しいのかも知れません。
もう少し調べてみます。

2024-03-28 09:53:34

と、思ったらIn-Sevice Register(IRR)とか書いてあった。タイプミスですね。(括弧付きの方しか見てなかった)
どちらにしてもレベルトリガでPITのOUTが直接PICに繋がっていると割込ルーチン内でEOIすると同じ割込が入ってしまう事には違いがないか・・・・
やっぱり外部回路が存在するような気がします。

PICをレベルトリガにする理由は、拡張ボード等でINTラインを共有する事が目的でしょうからタイマーなどの一部のデバイスはその目的のために外部回路を入れている可能性は有ると思います。
(PICのトリガをピン毎に設定できれば全て解決するのですが、8259は全ピン共通設定ですのでどちらが重要かを考えた結果なのかも知れません)

2024-03-28 10:07:44

津軽の話というよりは実機の話なので、こっちに持ってきました。

RATOC 3586をうちのネットワークにつなげるべく、いろいろやってみました。どうやら、NET.CFGのフレームをEthernet_IIにしないと、TOWNS TCPのユーティリティは認識しないようです。ソースがあったのでエラーメッセージからたどったら、クラスが802.2とか802.3だと新し過ぎて(w)認識しないようでした。

また、REX3586ではLSL.COM + REX3586.COM + ODIPKTだと、TCP/IPユーティリティは認識するのですが、PINGが飛ばないようでした。人柱になるつもりでDSLINKカードを一枚落としたので、LSL.COM, FMRLAN.COM, ODIPKT.COMの組み合わせでTCP/IPが使えないと、7800円棒にふることになりそうでやや不安なんですが。

REX3586には、パケットドライバが単体で入っているようで、

PD3586.COM 0x60

これを実行した後PINGしたところ、帰ってきたようです。また、DNSのアドレスを指定したらアドレスを正しくResolveしたので、接続に成功していることが確認できました。気になるのが、Routerの接続一覧に出てこないんですよね。DHCPからアドレスを取る方法がわからないのでstatic IPとしてアドレスをリザーブしてしまったからかもしれないですが。

PD3586.COMはNET.CFGを見てない気もするので、関係ないかもしれないですね。

これで、Windows上のファイルを共有できたらすごいんですが、誰かMSLANMANのインストールに成功した人います? まあ、今までファイル一本ずつXMODEMで送受信してたので、SOCKETライブラリ使ってファイル送受信するユーティリティを書いてもいいんですが。

TGDRVみたいにINT 2FHを使ってファイル共有するためだけのドライバとか書けないもんだろうか。というか、FTPあるんだから、2点間限定のFTPサーバー書けばいいのか。やってみるかな。

2024-06-02 11:16:34

手前味噌な紹介で恥ずかしいのですが、etherdfsというファイル共有ソフトの
FM TOWNS移植版でREX3586のパケットドライバによる動作を確認しております。
一度お試しいただればと思います。
https://mcdom.blog.fc2.com/blog-entry-7.html

2024-06-04 14:45:36

こんにちは、どむやまさん。 一応,管理人をしていますWINDYです。

未だ試せていないのですが、有用なソフトウェアの移植の方を有り難うございます。
これがあればHCに飾りとして刺さっているLANボードが使えるような気がします。

手前味噌でも宣伝でも一向に構いませんのでTOWNSを使っている方や過去に使われていた方,また新しく興味を持たれた方が情報を入手する一つの手段として使っていただければ何よりです。

非純正品のボードやユニットは特に情報やソフトウェアが今となっては枯渇していますので助かります。

2024-06-05 10:03:35

WINDY様、ありがとうございます。
貴重なTOWNSの情報交換の場所として本掲示板、とても有難く思っております。
また何かネタありましたら書き込みしますね。

2024-06-06 13:56:45

LAN ManegerでしたらOh!誌のスタッフだったTaroPYON氏が設定方法を書かれています。
http://www.runser.jp/doc/lmodi.html

NetWare ClientもNT Serverも手元にあるので週末にテストしてみようと思います。

2024-06-07 23:34:18

どむやまさん、

おおなんと！そんな便利なソフトがあったとは！使わせていただきます。ありがとうございます。

KtJ Dragonさん、

そのサイト、TaroPYONさんのサイトだったんですね。僕も最近見つけて、試していようかと思っていたのですが、結構ステップ数が多そうだったので、まだ試してませんでした。

情報ありがとうございます！

2024-06-08 12:56:25

LAN Manager入れてみました。機種はFresh Eで、NICは186Aです。
DOS3ベースのTOWNS OSだとODINSUPを実行するところでハングしてしまいました。

で、クリーンインストールしたDOS6にLAN Managerを入れたところ、DHCPでIPアドレスを取れてPINGが通ることろまではテストできました。

これでSAMBAにアクセスできればいいのですが、デフォルトでは脆弱なLANMANプロトコルには対応していないでしょうから設定変更が必要そうです。

あとはコンベンショナルメモリが379kまで減ってしまい、tmenuで使おうとするならばチューニングが必要そうです。プロトコルをNETBEUIにすれば多少はマシになるでしょうが、WindowsXP以前のOSにしか接続できなくなるのでこれはこれで厳しい。

2024-06-08 23:09:01

https://www.samba.org/samba/history/samba-4.11.0.html

Samba 4.11からLan Managerの認証は使えなくなったようです。

2024-06-11 21:14:20

実際にRaspberry Pi のSamba 4.13でLAN Manger認証を有効にしてテストしてみましたが認証エラーで接続できませんでした。古いFreeBSDサーバに入れているSamba 3.6.13であれば接続・ドライブレター割当・ファイルの読み書きに成功しました。ただし、日本語ファイル名は文字化けします(TOWNSでファイル名を日本語にリネームしてDIRで確認すると文字化けしますが、Windows11から見るとちゃんと日本語でした)。

設定にあたり、以下のサイトを参考にしました。

SAMBAの設定: https://askubuntu.com/questions/1213759/allow-smb-1-with-lanman-authentication-with-samba
LAN Managerのコマンド: http://hp.vector.co.jp/authors/VA007890/dos/sd/winnet.html

あと、DOS側でLANMAN.INIのdomain=の内容を、SAMBA側のsmb.confで設定するワークグループ名にしておく必要があるようです。

2024-06-13 21:46:28

FM TOWNS/FMV TOWNSのLAN関連ツール等を作成・移植しましたのでお知らせします。

・FMV-181/182/183/184設定ツール
https://github.com/mcDomDom/fmv18xct
入手困難なFMV-18Xの設定ソフト FJN0ISET.exeの代用品です。

・FMV-18X/NE2000/FM50L186用パケットドライバ
https://github.com/mcDomDom/PDFM
EtherDFSやTowns TCP/IPで使用可能なTOWNS OS上で動作するパケットドライバです。
FMV TOWNSのTOWNSモードではFMV-181/182/183/184しか使えない、と思っていましたが、
ISAのNE2000互換カードも使えました。

・TownsOS(MS-DOS3.1)対応版EtherDFS-3
https://github.com/mcDomDom/etherdfs-3-client
以前移植したEtherDFSはMS-DOS 5.0以降でしか動作しませんでしたが、
TOWNS OS(MS-DOS3.1相当？)上で動作するEtherDFSクライアントです。

是非使ってみてくださいね。

2024-07-31 21:17:54

公開ありがとうございます。
起動フロッピーを作ってしまえばシンクライアントみたいな環境でゲームができるかもしれませんね。

小型低価格なEtherDFSサーバー（Linux版のみ？）を用意するとなると
今はRaspberry Pi Zero2 W　が丁度良さそうでしょうか。

私の方は、どむやまさんが公開されている”モニターのスーパーリアル麻雀対応化”をしたいなぁと思っている段階です。
ラズパイ3Bの購入まではしまして、初めてのラズパイなのでスローペースですが完了を楽しみにしています。

2024-08-09 22:21:26

aochan様
ありがとうございます。
etherdfsのlinuxサーバーですと、retronasというレトロPC向けの各種サーバーの導入パッケージが便利そうです。私も盆休みにでもraspberry piに導入して見る予定です。
モニター改造、もし不明な点ありましたらご連絡くださいね。

2024-08-10 21:49:44

どむやまさん
9.7インチモニターでスーパーリアル麻雀が映るようになりました。
ありがとうございます。
メニュー画面などの背景が若干チラついていますが、左右はみ出していませんし色も正常です。
もしクロック50の時に左右の幅が合い縦縞が無い場合、クロック60付近にチラつきの止まる箇所が一つります。
その代わり縦縞が少し出てくるのと、右側が一部はみ出します。

LCD-8000Vでも発生しますが、自己紹介でキャラクターを選んだあと、名前が拡大→縮小している際に、
拡大縮小中の文字周辺（水平方向）の色が若干変わります。
（それほど問題ではありませんし、もしかするとCRTでも発生している可能性があります）


20Fで他２本とPC-98で少しテストしました。
雷電伝説
　上下切れずに表示出来ています。

スーパーストリートファイター２
　HIGHWIDE　→　CRTの時と同じく左右引き伸ばされて表示されます。
　HIGH　→　お馴染みの正方形に近い表示です。
　LOWWIDE　→　HIGHとあまり変わらない感じです。HIGHに比べると少しぼやけているかも。
　LOWVIDEO　→　LOWと変わらない感じです。
（モニターの設定画面に入り、手動で左右引き伸ばしも可能です）

電源ON時の画面(640x400)
　書き換え前と同じく4:3に引き伸ばされますが、モニターの解像度が高いのでシマシマなどの違和感は目立たず。

PC-98(640x400または200)
　TOWNSの電源ON時と同じく4:3に引き伸ばされます。

変わった解像度(576x448ドットらしい)のドラゴンバスター
　表示可能ですが、マップ画面の縦のシマシマが目立つ状態からは抜け出せず。（モニターの限界かも？）
　液晶画面の情報には24.8KHZ　53HZ NN 640x448と表示されます。


動作テストには変わった動作のソフトばかりを使用していますが、
素晴らしい表示能力のモニターに生まれ変わって大変嬉しいです。


今後さらなる最強を求めるとなると、
16:10のモニターのうち、アス比4:3に設定可能な物を探すことになるのかな。


retronasにはetherdfsも含まれているのですね。
Win95からアクセスできるのも良さそうです。

2024-08-15 22:28:04

aochan様
モニター書き換えできたみたいで良かったです。
各種ソフトでの動作報告感謝いたします。
9.7液晶でも解像度を使用したアスペクト比表示ができるように改造できそうなのですが、自室が暑すぎてあんまり作業進んでおりません(^^;
ドラゴンバスターはX68000版しか持っていないので、PC-98版が入手できたら改善できるか試してみます。
16:10で4:3表示できる改造可能モニターはPHILIPS の252B9があるのですが、ちょっとサイズが大きいのと正方形ピクセルで無い点が惜しいと思っています。
Acerも16:10を出してくれたらいいんですが…

2024-08-26 18:08:41

>どむやまさん
貴重なソフトの移植有難うございます。TownsでEtherDFSのDOS3版を使ってみました。
ethersrv-linux-866を入れたRaspberry PI3と、FM50L187搭載のTownsで相互にファイルのコピーができました。
smbも入れてWindowsとも送受信しています。

ファイルを削除したりTowns menuで開くとハングするので、そのうちWindows版のサーバも試したいと思いますが、
Towns OSのままファイル交換ができるのは楽でいいですね。

自分は黒ジャックのiPad9.7インチモニタ(JG2555TC)を持っていてファームを使わせて頂いています。
簡単にファームの書き換えができて驚きました。公開して頂き有難うございます。

2024-09-01 16:48:43

どむやまさん、
アスペクト比表示が実装されればさらに嬉しいですね。
なんでも映るようになった現状でもありがたい状況ですが。

Amazonで調べたところ、今は16:10のモニターが少ないのですね。
1ドットが正方形で無いモニターがある事も知りませんでした。

ドラゴンバスターにつきましては電卓を使って何倍表示になっているかなど調べたところ、現状で最良の表示が得られている気がしてきました。
あと少しクロックを下げて横幅を狭くできれば、丁度横３倍になりそうだけどギリギリ届かない感じでしたが、横３倍にしてしまうと縦長になりますよね・・・。


98版ドラゴンバスターをプレーする機会が得られた時の注意点を書かせてもらいますね。
動作しない機種が多いのと、正常起動してもFDDのアクセスランプが点灯し続ける変わった動作をします。
動作しない原因は、ラップトップやノート、新しい目の機種などに搭載されたFDDの自動回転停止によるもののようで、
初代MATEあたりから自動回転停止（モーター制御）を"しない"に出来るようになったので"しない"にすれば動作すると思います。
MON信号だけを配線変更などして回転させても読めません。

2024-09-03 00:29:00