トランスレータとしてN-MOS FETを使う技法は簡易的で実装しやすいと思います。 何と言っても秋月がモジュール製品を販売していますから、お手軽です。 FETを使う方法は構造的にオープンドレインであり、 プルアップしているだけという難点があります。 オープンドレイン構造に速度を期待してはいけないというお話があります。
方向を自動切り替えしてくれるタイプのデバイスもあります。 それらは電流をセンスするなどトリッキーな方法で動作しているため、万能ではありません。
Hi-Z制御のできる74LV1T125ファミリを並べる案はわかりやすそうに見えます。 この方法の難点は閾値がL側に偏った変則になることです。 1.8Vから5Vに直接変換できないことも挙げてよいでしょう。 3.3V対5Vの変換が扱えればそれで良いと割り切るなら、良いデバイスだと考えられます。
明示的なHi-Z制御ができなくても良ければ、74LVC1T45も良いと考えられます。 このデバイスはdual supplyを持っていて、 1.8Vロジックからダイレクトに5Vロジックに変換できます。
ケースバイケースで何を選択するのかが変わります。 シリコンで実装されていないメニューは恐らく需要がないのでしょう。 場合によってはソフトウェアの設計も変わりますね。
YM3014はサンプル信号の立ち下がりでシフトレジスタの結果をパラレルにラッチします。 YM3014はラッチした最初の10bitを仮数部(LSb first)、 続く3bitを指数部(LSb first)としてD/A変換を行います。 仮数部は10bitあります。0x000から0x3FFまでの値を取りますので、 符号拡張を施す目的で2の補数表現にするためには、符号ビットを反転する必要があります。 指数部は値0が禁止されており、1が相対的に1/2、2が1/4、3が1/8、4が1/16、5が1/32、6が1/64、7が1/128の係数を表現します。 データシートを読む限りでは下記のような演算をすれば良さそうに見えます。 なお、これは仮説であって裏付けを取っていませんので念のため。 設計と実装をする前にYM2203あたりの生データをシフトレジスタ経由で取り出して分析、試算して検証したほうが良いでしょう。
検証するには何らかの形で生データを読む必要があります。 試算してみると1bitあたり1.25μ秒程度の時間余裕しかありません。 マイコンの外部にレジスタを付けてラッチすれば1ワードあたり18μ秒まで緩和されますが楽ではないですね。 48バイトでパケットを構成すると24ワードで4800命令時間に相当しますので、ワンチャンあるかも? という感じです。 割り込み駆動でワードを拾うと、それだけで50命令ぐらいは使いそうな気がしますので、 見かけほどの余裕はないと思います。
ここまで考えて、YMF288があるならそれを使えばいいのでは、と思ったのでした。
実験対象になるべきデバイスに流通在庫がどの程度あるのかは不明です。 もし在庫が尽きていたのなら、そのときはFPGAにコピーするかエミュレーションするしか前途はありません。
私が知る限り秋月は8bit x 256kの非同期DRAMを販売していません。 かわりに16bit x 256kの非同期DRAMが販売されています。 このメモリチップをYM2608Bに繋ぐ場合、素直に考えれば下位8bitバスとCASL#を配線します。 上位8bitバスに該当するメモリバンクを捨ててしまうのはなんだか勿体ない気がします。 しかし、一般的には、上位バイトを捨ててしまう実装が普通のようです。 これは音源ドライバがADPCMメモリマップを把握していなければならないことが関係しています。 特別なデバイスドライバをスクラッチできないのであれば、 上位バイトに何か配線をしても意味がないのです。 100円のメモリを活かすために300円のロジックを追加することはしないのです。 もともと、FM音源を使う需要の殆どは既存のソフトウェアをあるがままに動かすエミュレータ用途にしかないため、 互換性があればそれで良しでこのような結果になるようですね。
ちょっと思考実験をしてみましょう。
メモリチップを活かすには、上位8bitバスとCASH#を配線すれば大丈夫です。 素人目にはマルチプレクサが必要に見えますね。 DRAMチップには、RAS#の次にCAS#にパルスが与えられない限りにおいて OE#を無視してデータバスをHi-Zを保つ、という面白い性質があります。 さらに、16bit幅のDRAMチップは8bit幅のDRAMチップを2つ並列接続にしたものと等価な取り扱いができるよう設計されている、 という特徴もあります。 これを活用することにします。 するとデータバスの下位8bitと上位8bitは直結することができそうに見えます。 バンク切り替えレジスタを1bit用意してアドレスに使います。 CAS#の動作中にバンク切り替えを起こすような不具合を除却するために、 バンク切り替え入力をRAS#でラッチしましょう。 ラッチはRAS#の立ち下がりエッジが理想的に見えます。 しかしRAS#自体はどうせDRAMリフレッシュでバタバタする信号であること、 さらにRAS#のエッジはどちらであってもCAS#を割り込まないと想定して良さそうであることから、 立ち上がりエッジのデバイスである74ACT74をそのままバンク切り替え信号生成レジスタに用いても実害はなさそうに見えます。 立ち上がりエッジ採用時に関わる制約は16μ秒のDRAMリフレッシュ時間を挟むべきであると言うだけです。 バンク切り替えが必要になるタイミングはYM2608Bに関して言えば通常は演奏される曲と曲の間なので、 16μ秒以上空けることに恐らく問題はありません。
YM2608Bから生えているCAS#はバンク切り替えレジスタをアドレスに用いたデマルチプレクサでCASL#とCASH#に分配します。 デマルチプレクサに何を使うかは若干悩ましいところです。 マルチプレクサ用デバイスである74ACT157であるとか74ACT153あたりが思い浮かびます。 ところでバンク切り替えレジスタに74ACT74を使ったのであれば、QとQ#出力を取り出せるはずだということに気が付きます。 これを活用すればデマルチプレクサは単なるORゲートで良いことになります。 74ACT32があれば大丈夫と考えられます。
NetBSD pkgsrcでcertbotをインストールするとrustcがビルド依存で取り込まれ、これがLLVMを要求します。 そこで引き込まれたLLVMが各種オプション盛り盛りのフルセット扱いになります。 依存関係がとても重たいので、別のACMEクライアントを使うようにしたほうが良いのか悩みどころです。 Linux方面では公式サポートのあるcertbotを使うのが定番なので、 運用ノウハウとしてcertbotを使い続けたほうが楽ちんです。
メモリが足りない環境ではLLVMがビルドできないためrustcの組み込みにも失敗し、 certbotはビルドできません。事前にビルドしてバイナリパッケージを転送して使えば良いのですが、 ビルドに都合の良い空きマシンを確保するのは思っている以上に煩わしいものです。
このような場合は代替策を使います。uacmeを使うのが良さそうです。 インタプリタ系を採用した実装はランタイムエンジンのアップデートが予想以上に煩わしいことになります。 安定性が期待できるという意味でC言語で書かれているツールは貴重です。