ということでメモリ周りのパタンはこのようになりました
ROM用にDIP28ピン-600mil幅。SRAM用にはスキニーDIP28ピン300mil幅、TSOP32ピン、SOP32ピンの3種のフットプリントをパラでつなげました。SRAMに関しては排他的でどれか1個のパタンしか使えません。電源電圧、必要容量、パッケージタイプに合わせたバリエーションに対応できますが、ふと我に返ると自分の手持ちの部品でやる限りどれか1～2パタンしか作らないだろうなと。
ところでこういう規則的なバス接続とかはオートルータでやるより手動引き回しの方が絶対にきれいにできると思ってます。ここの部分だけ作り上げておき残った未配線はオートルータで片づける作戦です
ROMとSRAMはピン配置が似ているのでバス配線が容易です。さらに簡潔にするには上下に親子ガメ方式で重ねてしまう手があって、DIP形状のROMソケットの中にSOPのSRAMを仕込むと省スペースにもなりうまいやり方です。秋月のZ80ボード、AKI-80がそんな設計でした。
でこのボードでも28ピン600mil幅のDIP-ICソケットの下に32ピンSOPのフットプリントを置いてみたら・・
こりゃダメじゃん・・
寸法図で見れば明らかなんですがSOP28ピンは余裕で入りますが32ピンでは2mm以上幅が広いのでこのやり方は使えませんでした。
SRAMにパッケージ違いのもの（TSOP32-P-0820）を持ってくればこれは幅が約8mmなのでこれならうまくいきます。下の図だとパッケージを90度回転させて引き回しがえらいことになってそうに見えますが、実はTSOPはピンアサインをDIPと変えていて（1/4回転させている）この位置関係でも、もっと短かく接続できます。
ただそのためだけにTSOPを調達するのも何だし、0.5mmピッチのハンダ付けもいまいち自信がないので思案中です。
今回のシステムはメモリ周りから設計を進めています。RAMはNSC810内蔵の128バイトとしてもROMはどうしても外付けになります。
ただ柔軟な構成ができるようにRAMもあとから外付けできるように、また容量、タイプも様々なものが使えるように配線は用意しておくようにしました。
RAMは64kbit（28ピン）～1Mbit（32ピン）が実装できるようにパタンを作成します。以下のように片寄せすればほとんどのピンは共通なのでこれは容易です
ROMも手持ちの64kbit～256kbitが載せられます。ただしEEPROMを使う場合はBUSY等の一部の制御線をジャンパポストで切り替える必要があります
という感じでざっくり回路図入力しました
３Ｖで確実に動作するＲＯＭがあるかというと、探せば当然あるわけで最近の大容量フラッシュＲＯＭは逆に３．３Ｖ品しかなかったりします。
ただ今回のようにシングルボードのブートに使おうとすると最初にボードの外でROMライタでモニタプログラムを書き込んでおく必要があります。ところが3.3Vフラッシュの29LVシリーズとかでは電源電圧が2.7～3.6Vとなっていて5Vを想定した手持ちのROMライタが使えません。また同じ理由でパッケージも表面実装品だと困ります。
ということで他に当たっていたらちょうどいいのが見つかりました。日立の電気消去型EEPROM、HN58Vシリーズです。これにはDIP形状もあるし、動作電圧が2.7～5.5Vと広範囲で使えそうです。
ではSRAMはどうするか、ということになりますがこれは３．３Ｖ品の例えば東芝TC55Vシリーズ(動作電圧2.7～3.6V)を直付けしてしまえばいいということになります。
と、ここまで仕様が固まりかけてちゃぶ台返しですが、このボードは周辺をどう拡張するかによりまだ３Ｖ動作固定に決めきれません。SRAMの動作電圧範囲は狭いので搭載は断念、３Ｖ－５Ｖ両電圧対応にしておきます。デバッグ中も都度ユーザプログラムをオンボードでEEPROMに書いてしまえば良いわけでSRAMと変わりありません。繰返し耐久性も10^5サイクルとされているので大丈夫でしょう
今年最初のプロジェクトは原点に帰って8ビットCPU、NSC800を動かしてみようかと考えています。CPUや周辺を気づいたときに集めていましたがだいたい揃ってきたところです。NSC800はZ80とバイナリコンパチなので開発環境も問題ありません。
上からCPU：NSC800 、RAM+TIMER+I/OのNSC810A、I/OのNSC831
これらはマルチプレクスバスで直結でき、ROMはありませんがちょうど8085/8155/8755のチップセットに似ています。またこれらのチップはCMOSプロセスで動作電圧が2.4～6.0V、消費電流も少ないのでうまくいけば乾電池2本で動作するボードができるかもしれません。
ただやはり問題はROMをどうするかです。アドレスラッチに3V動作の74HC/74LVが使えるとしても汎用ROMにつないで動くでしょうか。ROMもCMOSの27Cxxであれば実力値でいけるか、・・で今年の裏テーマは省エネ・エコ化、5V系からの脱却というのもいいかもしれません。
とは云いつつ、主要３チップ構成ではなんとなく見た目に物足りないような気もして、つながりそうなチップも手持ちから掘り出してきました。
上からシリアルコントローラ：INS8520、16ch8ビットA/Dコンバータ：AD0817、LEDドライバ：MM5450、リアルタイムクロック：MM58167
ただしこれらをつなぐにはアドレスをラッチしてセパレートバスにしなければならず電源電圧も5V、消費電流も増えるので乾電池で、というのは厳しいでしょう
ともかく今回はナショセミ縛りで、パッケージ共通の白い縦バーのデザインがなかなか良い感じです。メーカロゴマークをよく見てみると波型から鈎爪型に変わったのは1993～1994年ころのようですが、波型の前世代のマーク、ICマスクパタンのようなデザインが結構好きでした
これが使われたのはbitsavers.orgのデータブックアーカイブで見ると1974～1975年ごろまでだったようです。小学生のころはじめて手にしたIC、低周波アンプのLM380にこのマークがついてたなぁ、、というと齢がバレますが。
アマチュアが趣味で部品入手しようとするき入手性、高級感のヒエラルキーがあって
東芝・日立＜テキサス・モトローラ＜ナショセミ＜＜アナデバ・リニアテクノロジ
のような感じでした。
ナショセミはアマチュアにも親しみがある会社というイメージでしたが今や消滅です
演奏用のデータファイルの入手ですが”VGM”、”Archive”とかで検索するとゲーム音楽のまとめサイトが見つかります。ただ許諾関係が明らかでないので、ここではやってみた・・だけにしておきます。音源としてYM2151のみを使用している曲を選びダウンロードしますがアップされているファイルは”.vgz”という拡張子になっていて圧縮されているようです。これはunzipで解凍できます。
VGMファイルは単発の効果音のような1秒程度のものからオープニングテーマのような1分以上演奏される100kbyteを超えるものまでいろいろあります。
まず電源ONでモニタが起動したらVGMプレーヤのプログラム本体を0x2000番地からロードし実行。VGMプレーヤのコマンド待ち状態”］”になったらVGMロードコマンド「L」を実行してターミナルからVGMデータをバイナリモードで0x8000番地へファイル転送します。
ここでは77296byteのファイル転送していますが、64kbyteを超えるサイズもちゃんとロードできていることがわかります。メモリ上に転送が終わったら、まず先頭4バイトの識別子が”Vgm ”(0x56,0x67,0x6D,0x20)になっていることを確認してからヘッダに含まれるいくつかの情報を表示させています。プロンプトに戻ったらplayコマンド「P」で演奏開始します。
VGMファイルには音源ICにセットされる音色パラメータ（MIDIでいうところのエクスクルーシブデータ）も含まれているため作成者が意図した音色で鳴っていると思われます。8音ポリという限られた資源の中でドラム・ベース・バッキング・リードと良くアレンジされていて感心します。もっとも自分はゲームには全く関心が無く、所謂ゲーセンに行ったことも、家庭用ゲーム機で遊んだこともないので原曲聞いたこともないし、どの程度再現されてるかもわかりません。
実行中の状態
クロックのレゾリューションの問題ですが、いっぺんに大量の音が鳴ったり、曲の途中で音色の入れ替えが行われてそうなところでテンポがもたつく感が多少あります。処理間のインターバルをタイマ計測しているので遅れながらも処理は順次行われ、誤差は累積していく方向です
VGMフォーマットを解析する部分は簡単ですが、問題なのはVGMデータをどのように持つか 、ということになります。デバッグ時のテストでは
const unsigned char vgmdata[]= {0x56, 0x67, 0x6d, 0x20,・・・・・・};
という具合に配列としてコードに埋め込んでしまいましたが、曲の差し替えができるようにBSS領域にバッファを確保して、シリアルからダウンロードするようにしました。
メモリ配分は以下のように仮置きし、バッファ領域はできるだけ大きく0x08000～0x1FFFFの96kbyteとしています。
VGMプレーヤのメインルーチンはこのような感じになります。核になるパーサ処理vgmplay()を終了コードを検出するまで常時コールし続けるだけです。vgmplay()はイベントごとにgetByte()でバッファから1バイトコマンドを取り出すと同時にポインタを進めます。
今回はVGMの解析もFM音源の制御も既存のものを参考にしているので難しいところはないのですが、悩み、つまづいたのがまたしてもx86CPUにおけるセグメントの壁でした。
このプログラムはMSCのスモールモデルでコンパイルしていますが大きいVGMデータをアクセスするためにメモリ上の特定位置に流し込んでポインタでキャストした実アドレスで参照しています。このポインタを最初、
unsigned char far *vgmaddr;
というようにfarポインタで宣言していましたが、どうも動作がおかしいのです。64kバイトを超えるようなファイルを転送すると1周してバッファ先頭部分を壊してしまいます。farポインタはセグメントとオフセットの両方の情報を保持しているので1Mbyeまで連続アクセスできると思い込んでいたのですが、インクリメントする場合はオフセット部分しか評価せず、セグメント境界を超えるアクセス（セグメント部分への桁上げ）はできないようです。まあ考えてみれば当たり前なのですが。ROMに焼き付けているモニタプログラムのloadコマンドもfarポインタを使っていますがスモールモデルでコンパイルする限りコード・データ合わせて64kbyteの制約があるので問題にならなかったわけです。
MSC/C++6.00Aでは幸いヒュージポインタをサポートしているのでこれを使えばリニアなアクセスができます。ポインタは
unsigned char huge *vgmaddr;
と書き換えるだけです。
