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

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