int32 cltable[FM_CLENTS*2] =
{
8192, -8192, 8168, -8168,
8152, -8152, 8120, -8120,
8104, -8104, 8088, -8072,
8056, -8056, 8040, -8040,
8024, -8008, 7992, -7992,
7976, -7976, 7960, -7944,
7928, -7928, 7912, -7912,
7896, -7880, 7864, -7864,
|
| 敗北感。 |
対数変換テーブルを何とか一致できるように作れないかといろいろ計算してみたが、結局うまい計算式は思いつかなかった…。これ以上考えてもしょうがないので、実チップから吸い出したテーブルをそのまま載せることにした。力技は芸が無いが仕方が無い。正の領域では100％正しい計算式がわかったんだけどねぇ。
何かスクリーンショットも取れなくなってるし。
ちなみに、テーブルの吸出しの方法だが、rad=π/2近辺のサイン波がなだらかな変化をすることを利用し、TLを1ずつ変化させることで取ることが出来る。
|
| サイン波と誤差 |
対数変換テーブルとサインテーブルの生成周りを書き直す。図のように0〜πまでは完全に波形が一致したが、出力が負になると誤差が…
なぜに〜?
 |
| 誤差 |
PC側の取り込みプログラムをマルチスレッド化して、ついでに fmgen の波形も一緒にとれるようにする。 結果を csv に落とせば excel で読めるので色々解析できるのではないだろうか。
実際に比べてみると良くわかる… ってなことで、FB=5 の時の出力波形の誤差をグラフにしてみた。
FB = 5 の波形はオーバーフローのためか非常にノイズ成分の多い波形で、振幅もかなり大きく震えるのだが、誤差を取ってみるとピークは周期的に現れるようだ。FB < 5 の波形は暴れないので誤差は少なかったが、皆無というわけでもないんだよね…
話は変わるが、取り込み結果の最初の数十サンプルにごみが入るのはなぜなんだろうか。
PC 側からリセット命令を送るとストリーム転送が止まってしまうのはなぜなんだろうか。←リセット後のウェイトが必要だった
FM 音源の波形合成には log とか sin とか複雑な式がたくさん出てくる。fmgen でも変換テーブルを C ライブラリの数学関数を使って作ったりしている。ただ実際のところ YM2203 という石は20年近く前のテクノロジーで作られたわけだから、sin や log を求めるにしろあまり高精度のものは使えなかったのではないだろうか？ 精度が高ければいいというわけではなく、より本物に近いものが正しいのだ。
 |
 |
| 生波形 | FB=7 |
私は標準のアセンブラではなく、秋月の PA を使っている。PA はよく使いそうな命令をマクロ化しているのでプログラムはかなり書きやすくなっている。それでも PIC のクセが取りきれてるわけではないので結構気を使う。Cとまでは言わないがもうちょっと気の聞いた処理系は無いものか…
しかしそこでいきなり yacc や lex の本を読み出してしまうと何が目的だかわからなくなるので自制しておく。当面の目的とは全然関係ないんだし。
というわけで日曜日を一日つぶした結果、シリアル経由で OPN を叩いたりデジタル信号を吸い取ったり出来るようになりました。ちなみに右の波形は、OP1つ分を波形を FB だけを変えて重ねたもの。FB=4 を越えるとほとんどカオスに近い状況になる。ここまで似せるのは大変かもね〜
後はPC側の環境を整えたら fmgen との比べっこに移ろうと思う。
 |
 |
| OPM->OPN アダプタを作ってみた | 裏側 |
OPM は OPN で出来ることはほとんどできるわけだけど、音程の制御方法が違っていたり、SSG-EG モードが無かったりと、いくつか足りないところもある。
そもそも1つしか持ち合わせの無い OPM を壊してしまわないか不安もあるわけで、最初は OPN 辺りで試行錯誤を繰り返してみることにした。
制御基板は OPM 用に作ってあるので、OPM のピンを OPN に変換するためのアダプタを作ってみた。
トータルな消費電流は 100mA 弱。OPM とほぼ変わらない程度かな。
ROMEO の生音に触発された cisc は、自前の fmgen の再現性を高めることを決意。とりあえず解析を容易にするために、直接 FM 音源を叩き、データを吸い上げるハードウェアを作ろうと思ったのだが？
手持ちの石は 2203 と 2151 ひとつずつ。まずは何も考えずに秋月の 16F877 テストボードに 24 ピンのソケットを置いてみる。