YM2612 + SN76489 メガドライブ音源を ESP32 で鳴らす (SPI接続編)

メガドライブのゲームミュージックをどうしても今再び実チップで鳴らしてみたい…。DNA がそうしろと言っているのだからしょうがない。

あれこれ部品を集めてがんばっておりましたが、なんとか PCM 付きで YM2612(FM音源) と SN76489(PSG音源)を発声させることができましたので、顛末を少しずつブログに書いていきたいと思います。

ハードウェアは次のように構成しています。

  • YM2612 + SN76489(メガドライブ搭載音源)
  • ESP32 DevkitC(制御用マイコン)
  • MCP23S17(SPI I/Oエクスパンダー)
  • LTC6904 * 2(I2C クロックジェネレーター)

作成中のものでソースコードも未整理、まだ回路図も書いていませんが(結線だけ README.md にメモしてあります) github に一式コミットしてあります。一応、現段階のものでフルスピードで PCM 付き .vgm が再生できています。:)

https://github.com/h1romas4/esp32-genesis-player

構成ですが、ESP32 マイコンは GPIO が少ないのと、将来的に音源を増やしたり、PC からも音源制御をしたいと考え、SPI 制御の I/Oエクスパンダー MCP23S17 を使ってシリアルパレラル変換を試みています。

音源制御のマイコン部分は、実際にゲームから送信された音源制御コマンドを44100Hz でサンプリングして保存した VGM Format 形式を事前に準備して、マイコンからデーターを読み取り音源に送信する形式をとっています。

さて、このシリーズの最初の難関は SPI MCP23S17 を使って 44100Hz(22us) に間に合う形で音源にコマンドを送りつけることで、最初はどうやっても間に合わず途方にくれてしまいした。。

esp-idf SPI Master Driver の spi_device_transmit でコマンドを送信すると、50us 程度次のコマンドを送るまでに間隔があいてしまいます。いきなり企画倒れか!がびーん。

これはどうやら SPI Master Driver が FreeRTOS マルチタスクに対応しており、処理に mutex と割り込みを使っていてその時間が乗っかってきているという事情のようです。

このため杓子定規に音源制御シーケンスを、YM2612 データーバスをセットして、CS と WR を落として…というふうに MCP23S17 に送ると、音楽がものすごいゆっくりに…。かつ YM2612 は 6ch 目を PCM に割り当てることができ、PCM の大きいデーターをひっきりなしに送信しますので、PCM を活用した楽曲ではまったく太刀打ちできず。

ということで、まずは音源制御のコマンドをなるべくまとめて送信すべく、MCP23S17 のデーターシートを読んでいたところ、良さそうなモードを発見。

特殊なモード(IOCON.BANK = 0のバイトモード)にすると、関連付けられたA/Bレジスタペア間でアドレスポインタが切り換わります。例えばBANKビットをクリアし、アドレスポインタをアドレス12h (GPIOA)またはアドレス13h (GPIOB)に初期設定した場合、アドレスポインタがGPIOAとGPIOBとの間で切り換わります。アドレスポインタは最初レジスタペアのどちらのアドレスを指していてもかまいません。

MCP23S17 の I/O は GPIOA と GPIOB の 8本ずつに分かれていますが、これらに ひとつのSPI シーケンス中にコマンドを連続で送ると A->B->A->B… とくるくる回ってくれます。

MCP23S17 と YM2612 の接続を、GPIOB に YM2612 データバスに、GPIOA に制御系の足を接続として、次のようにコマンドをおくる用に修正。赤い線の中がひとつのSPI シーケンスのイメージです。

(下の図はプロトでつくった I2C 版 MCP23012 で行ったものなので速度は無視してください… I2C 版でも同じ動きになります)

最初(0xB1)にアドレスバス(GPIOB)をセットし、次に CS/WR を落として同時にA0/A1 を設定(0x04)、次は GPIOB に戻ってしまうので最初と同じデーターをセットし、最後に CS/WR を上げて完了です。ひとつの音源コマンドを、ひとつのSPI シーケンスで送れるようになりました。

また、YM2612 より SN76489 は遅く、このような最短シーケンスだと音源が反応できなかったので(WR を下げてから上げるまで 12us くらいいるみたいです)ダミーの同一データーをコマンドに挿入して時間待ちし、こちらも同じようにひとつの SPI シーケンスで送れるようにしています。

ということで、これにて 4つの SPI シーケンスがいるところをひとつにまとめられシーケンス間隔問題を 1/4 削減できましたが、依然としてまとめられないシーケンス間に 50us 程度間隔があいてしまう問題は残りました。

いくつか考えて、ダミーデーターを送り続けてシーケンスを繋ぎっぱなしにすればいいじゃないかと思いつきましたがちょっと普通にやるとコマンドのタイミングを取るのが難しそうです。 一応鳴るにはなりましたがテンポがずこっとなりがちでした。。

再び途方に暮れましたが、いろいろ調べていたところ ESP32 本家のサンプルで SPI の液晶コントローラーをつかった NES(ファミコン)エミュレーターがあることを思い出す。

既存のエミュレーター移植なので、最終的にメモリーにレンダリングされた 320x240x8bit という大量データーを 60fps で SPI で転送しているとすれば何かあるハズ…とソースを確認。

https://github.com/espressif/esp32-nesemu/blob/master/components/nofrendo-esp32/spi_lcd.c#L402

かくしてそこで見つけたのは ESP32 の SPI ペリフェラルを直接たたくソースでした。

ESP32 Technical Reference Manual とにらめっこで命令を理解しつつ、はたして…。

1コマンド 7us キター! 😀

YM2612 は実際には 2コマンドで1セットなので 14us になりますが 1サンプルには十分間に合っていますのでこれで大丈夫そうです。(ここもまとめようと思えばできるハズです)

そんなこんなでメガドライブ楽曲が実チップで鳴るところまでごきつけました。嬉しい…。ベアナックル2が奏でられてしばし放心…。

タイムリーなことに、ぼくのゲームミュージック好きの原点にして頂点である古代祐三さんが MUCOM88 音源ドライバーをベアナックル2を含むサンプル曲付きで CC 公開されており、mucom MML を VGM に変換するプログラム mucomMD2vgm を kumatan さんが公開されています。

現時点残念ながら mucomMD2vgm で変換した .vgm はぼくの vgm パーサーだと unknown のコマンドがでてしまってまだ完全に発声できないのですが、おそらく vgmpos ずれだと思うのでちょっと直してみたいと思います。

他にも回路図をかいたり、基板をおこしたり、クロックを安定させたりまだ仕事が残っていますので、引き続きこの未来ガジェット製作をやっていきたいと思います。:D

関連

Visual Studio Live Share の活用

Visual Studio Code Advent Calendar 2018 の 16日目です。 🙂

今年もいろいろな分野で活躍してくれた VS Code でしたが、拡張として提供されている Visual Studio Live Share にもずいぶん助けられました。

Visual Studio Live Share は自分の Visual Studio から他の Visual Studio に接続してコード編集することを基本とするコラボレーション用の拡張です。ソースコード以外にも相手ホストのいろいろな機能に接続することができます。

  • ランゲージサーバーへの接続(相手の環境を使ってコード補完ができる)
  • プロジェクトファイル全体の grep 検索
  • 任意のポートにブラウザで接続
  • ターミナルに接続
  • デバッグ実行

自分の環境にソースコードや実行環境を持っていない状態でも、相手の環境を使って簡単にプログラミングを開始することが可能で、相手の環境で発生している不具合を手元で再現させながら修正するといったことが数分の準備で簡単に行えます。

接続はインターネット上に配置された Micsoroft の Live Share サーバーを介して行いますので、残念ながらクローズドな LAN 環境では使うことができませんが、代わりにルーターのポート開放など難しい設定なしに、どんな場所にいても機能を使うことが出来ます。

またクロスプラットフォームにも対応していますので、Windows から macOS に接続して動作させるようなことも可能です。ということで、いくつかの例を紹介してみたいと思います。

ランゲージサーバーとコンソール接続

Rust を編集している Linux をホストに Windows ゲストから接続して、Linux 上にあるソースコードと Rust Language Server に接続してみたところです。

補完も定義表示も相手の環境のものを使っていい感じに動作します。

Windows から Linux への bash の接続も OK で、ショートカットキーや Powerline の制御文字などもそのまま転送してくれます。相手の環境のコマンドがそのまま打てますので、Windows 側からビルドなんかもすることができます。すごい。

デバッガーへのアタッチ

ホスト側で起動したデバッガーにアタッチして、ゲストからステップオーバーやウォッチなどの操作をすることができます。 Linux / Rust / LLDB ホスト環境に Windows ゲストからアタッチした図です。

デバッグコンソールなども転送されてきます。

たとえば、Windows で動く LLDB を準備するのはちょっと大変ですが、このように Linux に接続できると簡単に環境を揃えることができます。(残念ながらゲスト側からデバッグの実行構成を起動することができませんでした。”The host doesn’t allow starting the debugger.” と言われてしまうので何かできそうな気がするのですが、引き続き調査してみます)

任意のポートにブラウザから接続

ウェブ開発をしている時に大きな力を発揮するのが、サーバーへのポート開放です。

今度は Windows で動作している Java ウェブアプリ環境に、macOS から接続してみます。Windows ホストに macOS ゲストから接続した上で、Live Share の Share Server を選択して、開けるポートを “localhost:8080” のように指定します。(この例は SpringBoot アプリケーションなので 8080 で起動します)

あとは macOS ゲスト側のブラウザから http://localhost:8080/ にアクセスするだけです。(localhost なのが不思議な感じですが VS Code がプロキシーして、ホストに接続してくれます)

macOS から Windows のターミナル(Powershell)に接続することもできますので、gradle を動かしてアプリケーションの起動停止をするようなこともでき、ソースコードを編集しながら、ブラウザで動作確認といったことがリモートで簡単にできるようになっています。

今年はお隣におられる方の環境につないでプログラムを修正したり、一番遠くは北海道・福岡間でプログラムの修正を行ったりしました。

特に不具合の修正では、それを手元で再現させる環境をつくるまでに時間がかかるものですが、VS Live Share を使えば不具合が起きている環境に接続してすぐ修正を開始することができます。(これができなかったら修正箇所が分らなかったのではないかということもありました。

VS Code はそれ自体の導入も手軽ですので、そのようなシチュエーションに出会ったら試してみてはいかがでしょうか。

あ、ひとつまえのポストも VS Code ネタですのでよければご一緒にどうぞ。。

AsciidoctorとGradleでつくる文書執筆環境

技術文書を書く環境が欲しくなり、VS Code と Gradle を使って Asciidoc 文書を執筆する環境を整えてみました。 お手軽に構成できて、300ペジくらいの文書でも耐えられそうです。

てなわけでまた来年もよろしくお願いいたします。。 🙂

AsciidoctorとGradleでつくる文書執筆環境

技術文書を書く環境が欲しくなり、VS Code と Gradle を使って Asciidoc 文書を執筆する環境を整えてみました。 お手軽に構成できて、300ページくらいの文書でも耐えられそうです。 🙂

VS Code でリアルタイムプレビューしながら Asciidoc 文書を執筆し、最後に HTML/PDF 文書にすることができように仕込んだ Gradle ビルド、フォントや CJK パッチ、.vscode 設定などをパッケージして github で公開しています。

https://h1romas4.github.io/asciidoctor-gradle-template/index.html

本文書は Asciidoc とその Ruby による実装である Asciidoctor を用いて Asciidoc 文書を執筆する環境を構築する手順を示します。実行環境は Windows、Linux、macOS の各 OS に対応しています。

上記のサイト(Asciidoc 文書のサンプルになっています)で詳しく手順を書いていますが、基本的にリポジトリを取得し、文書を書いて、 ./gradlew docs するだけでいい感じに Asciidoc を HTML/PDF 文書に変換して公開できるようになっています。

PDF 文書は次のようなものが出力されます。

AsciidoctorとGradleでつくる文書執筆環境(PDF版)

https://h1romas4.github.io/asciidoctor-gradle-template/index.pdf

PDF に関しては本文フォントを明朝体にできるとより技術書らしくなると思うのですが、残念ながら prawnpdf ライブラリが OpenType に対応していないため導入を断念しました。(リポジトリの方では .ttf の 源様明朝 を導入しました)

しかし、対応は進んでいるようなので期待します。

https://github.com/prawnpdf/ttfunk/issues/53

Hey there maintainers! I’ve been working for the last several months on supporting OpenType fonts, which really just means supporting the CFF font table.

さて、今回このプロジェクトを作成するにあたり初めて Asciidoc の書式を全て確認しましたが、表現力が高く、思ったことは思った通り書けばよい感じなのでお気に入りました。 😀

(2020/4/17 更新) Qiita に最新の Gradle 定義で記事を書きました。

AsciidoctorとGradleでつくる文書執筆環境 v2

asciidoctor-gradle-pluginを活用して Asciidoc 形式の文書を Gradle を使って簡単に HTML/PDF 文書に変換できるビルドテンプレートをつくってみました。

リポジトリを github に置けば Github Pages ですぐ綺麗な文書を公開できるようになりますので、良ければお試しください!

関連