Gigamix Online

懐かしの8bitおもちゃPC「MSX」を骨までしゃぶり尽くそう。MSXの最新ニュース、ブログ、自作ソフトの配布など。

SCC音源が使えるMSX用サウンドドライバとSCC-I対応状況のまとめ

2021年1月23日現在。随時更新中。情報が分かり次第、追加してゆきます。

更新情報

スナッチャー付属カートリッジ

SCC-Iとは

 コナミスナッチャー」「SDスナッチャー」の付属カートリッジに搭載されたSCC音源チップの名称です。これはコナミのその他のMSX用ゲームカートリッジに内蔵されていたSCCとは少し違います。

www.msx.org

 SCC-IはSCCと互換性がある「互換モード」に加え、全5音それぞれ異なる波形を指定できる独自のモード(ここでは「拡張モード」と呼びます)が存在します。通常のSCC(互換モード)はch4とch5が同じ波形で発声されるので、拡張モードでは互換モードよりも音の表現力が拡大します

 SCC-Iは「SCCI」「SCC+」「K052539」「2312P001」と呼ばれることもあります。なんと呼ぶのか正しいのか、私には分かりかねます。ICの表面に「SCC-I」と刻印されていますので、ここでは「SCC-I」と呼びます。

 ちなみに通常のSCCは「K051649」と呼ばれることもあります。

この記事の趣旨

 これまで「SCCに対応する」と言うと「SCCとSCC-Iのどちらでも再生できる=互換モードのデータを作成する」「互換モードで発声する」ことを意味していました。

 しかし昨今、SCC-Iの拡張モードを用いて楽曲を作りたいというニーズが現れ始めました。SCC-Iを搭載した製品である「スナッチャー」「SDスナッチャー」の入手は2021年現在極めて困難であることに対し、互換品・相当品の入手は比較的容易になっています。今ではパソコンのソフトウェアで完全再現することも可能なため、むしろ1990年代の頃より2021年のほうがSCC-Iに対する敷居が低くなっている感すらあります。

 ところが各種サウンドドライバでのSCC-I拡張モードの対応状況をMSXのコミュニティにて探すも、拡張モードに限った情報は極めて少なく全貌が把握できないため、それらを2021年の基準で確認することにしました。

SCCの仕様(解析資料)

 裕之さんのドキュメントが詳しいです。→ http://d4.princess.ne.jp/msx/scc/

SCC音源に対応するMSXサウンドドライバ一覧

【おことわり】SCC音源に対応しないドライバは今回調査の対象外なため取り上げません。予めご了承ください。

サウンド

MuSICA

今確認してみたらch5の音色変更は不可でした。MuSICAはサウンドカードリッジ専用ですがそれをSCC+としては使ってないようです。今まで知りませんでした — ハルマッキン (@Harumakkin) 2020年12月20日
勤労5号ではチャンネルミュートをしても同じ音色だったため、コンパイルの時点で同じになってるようです。 — 大槻真嗣(@s_ohtsuki) 2021年1月13日

 ちなみにMuSICAエディタは公式見解ではないものの環境を構築すればMSX1でも動作します(RAMが32KiB以上必要)。

こちらをどうぞー MUSICAをMSX1で動かそう https://t.co/GaZVoFDPOl — うにスキー (@uniskie) 2021年1月20日
おお、MuSICAがMSX1で動きました!DOS1とNextorのどちらでもいける。ESC→DELキーでMSX2以降の80文字モードに切り替えようとすると画面が崩れるもののフリーズはしない安心設計(!?)。VDPの特性に特化しなければ他の過去資産もMSX1で使えそうですね。コンパイル後のBGMデータの再生環境が課題かも。 pic.twitter.com/d5frqP98XN — Takashi Kobayashi (@nf_ban) 2021年1月23日

 環境の構築方法は、TINY野郎さんのページに記載されています。→ http://www.tiny-yarou.com/msxmusica.html

MGSDRV

MGSDRVは5チャンネルの音色を別に指定できなくなっています。4/5どちらのチャンネルで音色を設定しても4チャンネル側にしか設定されません。SCCIの初期化の際にはSCC互換に設定しているので当然無問題ですが、せっかくのSCCIがSCC互換でしか動いてないのがもったいないという話です。 — ごりぽん (@goripon_tw) 2020年9月24日

 ちなみにMGSDRVは環境を構築すればMSX1でも動作します

gigamix.hatenablog.com

MPK(Music Player K-kaz system)

MPK v.1.06 ・SCCチャネル4, 5音色指定モードの話は説明書には見かけず ・演奏情報の仕様にはSCC45V SCC音源チャンネル4, 5の音色番号 というワークがある ・動作上は、SCCチャネル4, 5に対する音色指定は共通(後着優先でどちらのチャネルにも適用される)に見える ・なのでたぶん音色指定は共通 — gomhi/ごーみ (@gomhi) 2021年1月23日

 ちなみにMPKは公式見解ではないもののMSX1でも動作するそうです(RAMが32KiB以上必要)。

おまけでもう1つ。MPKの動作環境はMSX2以上・VRAM 128kB以上となっているけど、ドライバ本体はページ1にRAMがあればMSX1でも動く模様。自分はRAM 32kBのPIONEER PX-7でSNATCHERサウンドカートリッジのRAMをページ1に出してMPK曲データを鳴らしています。再生できる機種が多いのはありがたいです。 — gomhi/ごーみ (@gomhi) 2021年1月23日

APiDRV

SCMD

MSXplug/MSXplay

MSXplugは内部的にはSCC+が接続されています。オプションの「Standard/Enhanced」はSCCカートリッジの種別選択ではなく、SCC+を「互換モード/拡張モード」に強制固定する機能です。「拡張モード」にした場合、MGSDRVは互換モード用なので音が鳴りません。 https://t.co/jBdpBaPFdB pic.twitter.com/qqD9SZWoId — DSA (@ym2413) 2021年1月11日

SCC Blaffer (NT)

SCC-Musixx

Super Music Editor

TriloTracker

If you or other Japanese music friends have any questions, I will be happy to help you out. — John Hassink (@John_Hassink) 2021年1月13日

令和の時代、MSX用ゲームソフトのセーブデータをどこに作るべきか問題

 2020年?2021年?にMSXパソコン用の新作ゲームソフトをリリースするにあたり、ゲームのセーブデータをどこに保存するかのアンケートがtwitter上で行われていました。その反応が興味深かったので、まとめてみました。

https://p.gigamix.jp/devmsx/cg/savedata.png

 なんでそんなことで悩むんだよ(普通クラウドでオートセーブだろう)と最近の若者は思うでしょう。が、1983年に発売されたMSXを今でも利用する人だからこその悩みがそこにありました。

開発者の思い

アンケート

#MSX のゲームソフト(FD版)で「ゲームのデータを製品FDに書き込むのはやめてほしい」という人の割合が知りたいです。セーブデータの記録方法について、ぜひ皆さんの意見を聞かせてください。 — B-Cat Software (@BCatSoftware) 2020年12月15日

ゲームソフトの前提条件

  • 対応するハードはMSX2以上 → RAM64KB以上の環境が保証されていることが前提(MSX1は考慮しない)
  • 提供するメディアはフロッピーディスクFDD搭載機=DISK ROM BIOSMSX-DOSMSX Disk BASIC 含)の保有機種で動作する前提(FDDを搭載しない機種は考慮しない)
  • 2020年現在フロッピーディスクは生産が終了した → もはや貴重品と化したストレージメディアです。全世界的に品不足の状態

アンケートの結果

アンケートの最終結果が出ました。44%の回答者がPAC/FMPACへの保存を望んでいる事になります。なかなか興味深い結果になりました。 https://t.co/wMFbjXx31d pic.twitter.com/dsyv0o778I — B-Cat Software (@BCatSoftware) 2020年12月22日
 なんと、FMPACへのセーブデータ保存を望む人が一番多い結果に!

開発者の決断

MSXの場合、ゲームソフトのFD書き込みに関する落とし所はこんな感じなのかな。・FDのバックアップを強く推奨・PAC/FMPAC対応・FDへの保存は任意(手動)・可能ならパスワード形式を検討 — MA-X @ B-Cat Software (@max_2608) 2020年12月17日

我ながら汎用的に情報を整理できたと思う。 https://t.co/9nzXfetWYu — MA-X @ B-Cat Software (@max_2608) 2020年12月18日

主な手法とアピールポイント

製品のフロッピーディスクで保存

 昔はわだかまりなく製品のフロッピーディスクにゲームデータを保存したものでした。データ管理が一番簡単です。後述の「バックアップしたのち製品ディスクで保存」も含めると、この意見が多数でした。 昔の自分なら「全部」(ユーザディスク保存も含めて)だけど、どれかひとつなら製品ディスク保存かなあ。破損が怖いけど、作り手としてはゲームは遊んでなんぼで、コレクターのためのものじゃないと思ってるので。 https://t.co/ONsdM7RovL — まかべひろし (@sinpen) 2020年12月17日
ゲームディスクに書き込まれることとディスク入れ替えの手間を負うことどちらか選ぶなら、私は入れ替えくらいは許容しますが、現状ドライブ故障だけでなく、ディスクそのものが入手困難ですからゲームディスクに保存も仕方なしですかね😅 https://t.co/SsHtvcTY2r — HRA! (@thara1129) 2020年12月15日

派生:バックアップしたのち製品のフロッピーディスクで保存

 ヴィンテージ品と化したMSXではソフトウェアに「コレクション」「アーカイブ」の意味が込められるようになり、製品データを極力改変しない(製品にセーブデータを書き込まない)ことを望む人が現れ始めました。 MSXでも68でもそうですが、バックアップ取らずにマスターディスクで遊ぶのが怖いです・・・。68のイースもセーブディスクいらないと書いてるのは、ユーザーディスクの1枚がもったいないからだと思うのですが、さすがにマスターにセーブするのは怖いな。 https://t.co/OiG74kX5lo — redmax.ars (@redmax_ars) 2020年12月16日
個人的には、どちらかというと「製作者側の都合」で、極力FDにセーブ(書き込み前提の仕様で出荷)はしたく(させたく)ないですね。経験上、想定外な使い方をするユーザーが出てきて、本当は無関係なのに「バグでFATが壊れる?」というような状況に陥ると、サポートで体力を奪われますので・・・ https://t.co/zwo6ONv6zI — EXCEED. (@TransAmGTA92) 2020年12月16日
デュプリケートディスクを作るウィザードリィ方式が最強。(シングルドライブだって言ってんだろ!) https://t.co/KbE3NlG2mP — yasi001 (@yasi001) 2020年12月15日
書き込み許容派だけど可能ならノンプロテクトで自力バックアップが出来ると安心。違法コピー対策もあって難しいかもしれないけど…。セーブロード時にディスク入れ替えてアクセスするユーザーディスク方式という手も。まあユーザーディスク用の空きディスクの用意が厳しいけど…。 https://t.co/VTQbb5k1sT — ごりぽん (@goripon_tw) 2020年12月15日
バックアップが取れるのなら.dskで運用しちゃいますよね。するとゲームディスクに保存がデータの所在がバラけず一番確実かな^^; — ひぽぽ(ファミコンGimmick!👍 (@koichironakaza1) 2020年12月15日
基本的に製品のディスクにセーブは書き込まないで欲しいよね。>RT ゲームの保存やっててほんと悩ましいところ。セーブデータ解析してオリジナルに戻すことは不可能ではないかもだけどオリジナル性は喪失されてるって感じるよ。 — めーちゃん (@rikyou_moe) 2020年12月15日
ディスクのバックアップ(コピー)が取れるのなら、ゲームディスクに書き込むのが手間いらずなんですけどねぇ・・・ — イノウマ (@inouma1) 2020年12月15日
バックアップを取ってバックアップディスクでプレイするので、データを書き込んでも問題なしと考えてます! — み(ゲーム・将棋・MSX) (@marumi) 2020年12月15日

 バックアップが取りやすい=複製しやすい。つまり、製品をリリースしてもコピーされ、インターネットに流出しやすくなります。開発側がそれを望まない・懸念を感じるのは至極当然のことです。 私も、コストや工期を考えるとメディアはFDで購入者にバックアップを促すよう取説に記載しようと思っています。コピーそのものよりもネットにディスクイメージを流される方が痛いですね。既にCELIA for X68000で被害に遭いましたので。 — MA-X @ B-Cat Software (@max_2608) 2020年12月17日

自分で用意したブランクディスク

 新しいブランクディスクにセーブすると、製品自体にデータ改変は起きませんがディスクの交換作業が発生します。 製品FDじゃなくてブランクFDに書き込むやつがよかった(過去形) https://t.co/upcfYJuQXl — やまかわ aka やんま ま (@yamma_ma) 2020年12月15日
製品ディスクは故障が怖いしディスクの差し替えは不便だし、PACは持ってないし、パスワードは間違える。テープは巻き戻さにゃならん。今考えと恐ろしく不便だが、楽しかった。ありがとう。 — げーにん (@geinin) 2020年12月16日
ああ、MSXって1ドライブの機種が殆どだもんなあ。個人的にはゲームディスクはライトプロテクトしときたい。ブート機能の無いゲームディスク作成する方式がいいかな。ただ、これは複数ディスクゲーがダメ。 https://t.co/oWAO4SMzuf — ゆっち(偽) via NNK (@nnk_osn) 2020年12月16日
フロッピーディスクを買ったら「すぐ全部フォーマットしておく」というMSXしぐさがあります。これはアプリ内からフォーマットが(ほぼ)できないというMSXの作りに関係しています。事前フォーマットしてないと、ゲーム等でユーザーディスクがなくなってセーブできなくて詰むのです…。 — MSX研究所長 (@yoshimatsuTUQ) 2020年12月13日

 MSXは基本的に1ドライブでの運用が前提なので、ディスクの交換作業回数は他の機種より多めです。これによって古くなったFDDで経年劣化による部材の故障や破損のリスクが発生します。 そういう作りだったんですけど、それはMSXの部材が市場に出回っていた時代だからこそ実現できた酷使っぷりで、2020年の今はディスク入れ替えを多用すると経年劣化で部材が壊れて使用不能になるリスクが高まっちゃうんですよね…つらい。 — Takashi Kobayashi (@nf_ban) 2020年12月17日

派生:ユーザーディスクを作成、ゲーム起動後はそのディスクで保存

 製品とデータの分離を考慮した折衷案。ゲーム起動は製品ディスクで行い、以後ユーザーディスクでプレイしデータ保存する手法。ディスク交換は1回で済みます。 ユーザーディスクを用意するタイプが安心かも。 — 反動 (@FF14_hando) 2020年12月15日
そのアンケ、初回にユーザーディスク作成でいいのになぁ…と思ってみてました。新規ゲームを選択するとブランクディスクにゲームデータをコピーしてセーブもそれに書く方式。起動時だけ製品ディスク(プロテクトあり)入れて、ユーザーディスクに入れ替えたらもう入れ替えは不要。 — EmiCharLounge (@EmiCharLounge) 2020年12月18日

 初回のディスク作成に時間を要するのがネック。ティル・ナ・ノーグより速いとは思うけど…

PAC(Pana Amusement Cartridge)/FMPAC

 PACは松下電器が発売した汎用のバッテリーバックアップカートリッジで、FM音源付きのFMPACは当時のログイン誌(パソコン業界の雑誌)の売上トップ10にもランクインされるなど販売数が多かった製品です。 次回作はPACのセーブ方式を検討しておこう。 https://t.co/09NLPHmzr6 — むらかたとうじ/村方凍二 (@ipheion78) 2020年12月17日
フロッピーディスクのゲームでPAC必須というのはない(ありえない)。ROMのゲームでセーブ先がPACかテープか、というのはいくつかあるが、だいたいのゲームはセーブ用SRAMを内蔵していて、PAC要求タイトルは非常に少ない。ほぼ唯一がハイドライド3なのだ。(あとキャビンADVのROMもあるにはある) — MSX研究所長 (@yoshimatsuTUQ) 2020年12月17日
必須とまでは言いませんが、テクノソフトのフィードバックは PAC があると進んだステージが随時保存されてゲームオーバーになってもコンティニュー可ですが、無いと最初からやり直しなので2周クリアするのが大変でした — tyr105店員 (@tyr105) 2020年12月17日
MSX版ハイドライドⅡはSRAM内蔵だったがハイドライド3はPAC or テープセーブでSRAM非搭載の理由として考えられるのは・4MbitROMを採用してコスト高・PanasonicとT&ESOFTの付き合いからPACを採用したあたりかな https://t.co/fy93DBb0CO — 610 (@shimako_610) 2020年12月17日

 MSX・FANの投稿プログラム「LAST WAR」もPACに対応できる程度に、実装は難しくない様子。 「拡張カートリッジSRAMへのセーブ」普通のMSXには二次記憶装置がないためプログラムやゲームデータの保存にはカセットテープが使われたが、松下が発売していたPAC/FM-PACには1KB×8の記憶領域があり、投稿プラグラムでこれを使うハックが流行りかけていた。一瞬でセーブ/ロードができるので便利なのだ pic.twitter.com/qKBlRVzhPo — 草薙 昭彦 (@nagix) 2019年2月24日

 ただ、PACのデータ管理は杜撰なイメージがあります。規格なんだけど自由、みたいな。セキュリティのセの字も無い。 MSXのPACって管理領域がなくて、何をセーブしてるんだか全く分からないのが痛い。FM-PACでバックアップは取れるけど、意味のあるデータが入ってるかどうかすら全く分からない。キャビンのゲーム間では判別してくれたりするが…(幻影都市からXakとか) — MSX研究所長 (@yoshimatsuTUQ) 2020年12月17日

 PACをアクセスできるアプリはいくつか存在します。

 拙作DMシステム2でもPACへのアクセス機能があります。

パスワード出力(ふっかつのじゅもんメソッド)

 昔は苦行だった写経作業も、今はスマートフォンという便利なアイテムがあるので書き写しミスが解消されます!入力が面倒なだけ! パスワード記録が簡単な時代になって良かった https://t.co/IDJBL3wnBc — りあるあるぱか (@giw) 2020年12月17日
超絶長い復活のじゅも・・・ — 焦がしエクレア (@SearEclair) 2020年12月16日
保存は今ならケータイのカメラがあるので書き写し間違いは無さそう。 — 超兄貴〜MSX2021〜 (@SuperAniki_MSX) 2020年12月16日
すべてのユーザーがPAC / FM-PACを所有しているわけではありません。 それに加えて、フロッピーディスクドライブは多くの場合壊れています。 パスワードが最も便利な方法だと思います。 — MSX Resource Center (@msxorg_es) 2020年12月15日

カセットテープ(データレコーダー)

 カセットテープ自体はまだメディアとして現存していますが、CMTケーブルの所有者が今は少なめということが課題。また、turbo Rでは廃止された機能です(PCMのマイク入力はありますが…)。 MSXのセーブ媒体はテープ一択やろ(嘘 — きんのじ (@v9938) 2020年12月15日
MSX側にマイクが標準だったら、マイクとスピーカでデータレコーダーも良かった — りあるあるぱか (@giw) 2020年12月17日
やはり今もも手に入る、いにしえのカセットテープ最強説(笑)(turboRは無理ですが)まとまった数を作るならマッパメモリ付きNextorSDカートリッジが1万で何とかなるのかも。 — 超兄貴〜MSX2021〜 (@SuperAniki_MSX) 2020年12月17日
ハイドライド3もテープにセーブできますよね?(補足説明書が無いとやり方がまず分からないけど)。VSハイドライド3はFDソフトでありながらPACが絶対必要ですが(汗)。 — けものびと (@jyu_jin) 2020年12月17日
turboRはMSX1より売れなかったことからも明白!まさかテープのほうが入手性が良いといわれる時代がくるとは思わないよね・・・データレコーダ本体のほうがアレだけど。ラジカセ使うならケーブルもか — しんさん (@shinsan68k) 2020年12月18日

 カセットテープのピーガー音をスマートフォンで録音・再生するソリューションは存在します。MSX2CAS です。 play.google.com

QRコード

 スマホの併用が前提なら、パスワードよりもQRコードのほうが出力できるデータ量は増えます。 いっそQRコードで表示(笑)。 — ごりぽん (@goripon_tw) 2020年12月16日

 MSX実機上でQRコードを生成するプログラムコードは、実在します。 gigamix.hatenablog.com

 でも、QRで出力したゲームデータをどうやってゲーム本体に戻すのか。 いや、セーブデータ。ゲームに戻すときにMSX側にカメラが必要だ!カメラカートリッジ(デジタイザとも言う)の製造を急ぎましょう! — Takashi Kobayashi (@nf_ban) 2020年12月17日

複数対応・全対応

 遊ぶ側からしてみれば、そりゃあできることなら複数に対応していただくのが有り難いのです。 贅沢を言えば、PAC, ディスク, パスワードの選択式なら安心私はPAC/FMPAC持ってるのでPACのが楽ですが、持ってない人も多いでしょうから。スマホでスクリーンショットとるのも容易な時代なのでパスワードも昔ほど不便じゃないですよね。 — HRA! (@thara1129) 2020年12月15日
ベストは選択式かも知れません。PACもどのセーブスロットを使うのかという問題があってちょっと大変な側面はありそうですね。ただ、ディスクセーブの場合でも個人的には困らなかったりします。昔から(可能なソフトは)起動してからバックアップに入れ替えて遊んでいました。CanCanバニーとか。 — うにスキー (@uniskie) 2020年12月15日
どれにするか迷ったら「全部」w — 後藤 浩昭 / GORRY (@gorry5) 2020年12月16日
 開発側のやる気次第なところは、あります。

その他

 コナミの10倍カートリッジで保存しよう案 「コナミの新10倍カートリッジ」のSRAMって、仕様公開されてないんだっけ? — チョンタロー (@Chontaroh) 2020年12月16日

 新しいデバイスをつけちゃおう案 msxのセーブ媒体ならコントローラー端子にsdカード直結でええんではもしくはシリアルケーブル — applesorce (@applesorce) 2020年12月16日

 ダウンロード販売のみに割り切ろう案 TLで見かけたMSXにおけるセーブ問題実ディスへの書き込みが嫌なのって凄くわかりますかといって、私はPACを使ったセーブもあまり好きじゃないMSXはエミュレーターにおける何処でもセーブが一番好きかな — Retokatsu☆usagi(裏垢ですw) (@retrokatsudou) 2020年12月17日

反則技:RTCの未使用領域

RTCのバックアップ領域に保存… — NAONORI (@naonori_msx) 2020年12月17日
RTCのバックアップ領域はファイヤーホークのセーブデータがあるのでダメ♪・・・前にステージセレクトとエネルギーマックスを書き換えるRTCセーブデータエディタ作った♪ — 焦がしエクレア (@SearEclair) 2020年12月17日
ちなみに、MSXのゲームデータのセーブ先で一番謎なのがリアルタイムクロックの空きビット(確か)で、ファイヤーホークだけが採用しています。エミュレータ開発の時に混乱を巻き起こしました。 https://t.co/lWiXMQpBcf — MSX研究所長 (@yoshimatsuTUQ) 2020年12月18日
 ファイヤーホークはクロックICの未使用領域にセーブデータを書き込むようです。ダメ!ゼッタイ!

確かペンギンくんwarsもだよ~ https://t.co/WoTIENjdTK — せいみまさみ (@masa_seimi) 2020年12月23日
 ぺんぎんくんwarsも、らしい。えっ、ぺんぎんくんwars2じゃなくて!?

こういうハードがあれば解決するのに…

 ここから先は未来の話。フロッピーディスクでの供給には限界があることは皆が認識していて、ではこの先どうしよう、という。

ハードウェアを拡張するカートリッジ

ファミコンDOOMに倣って、RaspberryPi載せますか!(笑) — HRA! (@thara1129) 2020年12月17日
マイコン載せるならPIC32MXでも相当なことが出来そう・・・。 — 焦がしエクレア (@SearEclair) 2020年12月17日
マッパタイプ切り替え機能付きNextorカートリッジ・・・自分用に何個か設計した♪ — 焦がしエクレア (@SearEclair) 2020年12月17日

PACの互換カートリッジ

クラウドSofarunみたいな感じの斜め上多機能カートリッジでお願いします!(無謀) PAC互換で考えたときに、そういや似非RAMはあるけど似非PACって無いですね。 — Takashi Kobayashi (@nf_ban) 2020年12月17日
SRAM有効化レジスタの実装が複雑なので汎用ロジックでは作りづらいんですよねPAC…。CPLD使うと単体カートリッジとしては大げさすぎるし。 — ごりぽん (@goripon_tw) 2020年12月17日

実装されるのはROMだけどディスク駆動のように見えるソリューション

 MSXなのでROMでのソフト供給に切り替えるのが今風であり、未来志向。そこで、フロッピーディスクでの動作環境をROM上でエミュレートすれば良いのでは?というアイデア(そこまで作るなら、ゲームの方をSRAM付きメガROMにする方が早い、、なんて口が裂けても言えない)Oo。😊 — HRA! (@thara1129) 2020年12月17日
ROM+SRAM混成の似非ディスク(RAMでもROMでもない(笑))カートリッジが出来たら…。 — ごりぽん (@goripon_tw) 2020年12月17日

 ここは解説が必要です。

カートリッジを開けるとICとmicroSDが付いてる構造はどう?と思うものの。カートリッジ内部でディスク起動するにはDisk ROM BIOSが必要でFDD非搭載機にBIOSが無いからBIOSの代替品も用意する必要があって、Nextorは無料で入手できるけどマッパRAMが搭載されていないと起動しないのか。そりゃ無茶だ! — Takashi Kobayashi (@nf_ban) 2020年12月17日
 1990年代当時は全然気にしていませんでしたが、90年代当時フロッピーディスク供給のMSX用市販ソフトや同人ソフトが数多くリリースされたのは、当時のMSX市場はFDD搭載機種で占められており、それイコールMSXシステムのスロットにDISK ROM BIOSが接続されている状態、ゆえにMSX-DOSやDisk BASICが利用可能でソフト開発が容易だったことが挙げられます。

Sony HBD-F1 from msx.org
 MSXではFDD非搭載機種へFDDを接続する際にはカートリッジで拡張していました。このカートリッジにはDISK ROM BIOSが含まれていました。

 令和の時代に入るとフロッピーディスクの供給が止まりFDDの劣化が目立つ始めたため、ROMカートリッジがMSXのコンテンツ配信メディアとして改めて見直されてきました。海外ではROMカートリッジでの新作ソフトが相次いでいます。そうなると、初代MSX(MSX1)やFDD非搭載機も対応機種の視野に入ってきます。

 似非RAMディスクの手法で「メガROMカートリッジなんだけど実態は外付けストレージ(似非ROMディスク)」というものを作ることは既に実現可能な技術なのですが、FDD非搭載機種(=DISK ROM BIOSを搭載しない機種)ではファイルをロードすることができません。ROMカートリッジ内にDISK ROM BIOSの働きをする機能を追加すればFDD非搭載機種でもファイルをロードできます。が、DISK ROM BIOSはメーカー各社の著作物であり、無断で転用できません。

 そこで、NextorというMSX-DOS2上位互換の新しいOSが選択肢に入ります。

www.msx.org

 NextorはOSの起動ファイルはもとよりDISK ROM BIOSの代替品となるカーネルプログラムも無料で入手できます。しかし、Nextorは多機能ゆえにマッパーRAM 128KB以上のRAM容量を必要とします。(RAMを128KB以上搭載していればMSX1でも起動できるのが強みです)

 Nextor上で起動する「メガROMカートリッジなんだけど実態は外付けストレージ」というものを作ると、128KB以上のマッパーRAM+Nextor+似非ROM(コンテンツストレージ)+ゲームセーブ用の書き換えできるストレージが必要となり、もはや本末転倒なレベルです。そういったカートリッジがもの凄く格安で開発できるようになったら採用を検討できるんでしょうけどね…。

PICマイコンとSRAMとSDカードスロットが載っていて起動時にマイコンがSDを読んでSRAMにROMイメージを書き込んでからシステム起動とか。書き込み終わるまでMSX本体側はWAIT信号で停止(笑)。— ごりぽん (@goripon_tw) 2020年12月17日
4メガ8メガROMの光栄ソフトがそんな動きっぽい(笑)実は内部はほぼFDイメージ説 — 超兄貴〜MSX2021〜 (@SuperAniki_MSX) 2020年12月17日
DISK2ROMのよう♪ — 焦がしエクレア (@SearEclair) 2020年12月17日

 Nextorは現実的ではないので、光栄のメガROMゲームのような「ROMの一部をディスクのファイルストレージっぽく振る舞うシステム」が開発されればROMカートリッジでもいけるかもしれないですね。例えば4000h以降にBASICの拡張命令を定義して、ファイルのロードは拡張BASIC(CALL LOADとかCALL RUNとか)だけで行うような…

 BASICプログラムをROMイメージ化するソリューションは存在します。DISK2ROM です。 www.msx.org  プログラム以外のコンテンツを付属できないっぽいんですよね。

ハンバーガー・ショップ for MSX2 キミは慌てず確実にハンバーガーを作れるか?

 当クラブ(というか俺)は昔にこういうゲームを作っていました。

タイトル画面

https://p.gigamix.jp/humberger/cg/screenshot_humberger_1.png

ゲーム画面

https://p.gigamix.jp/humberger/cg/screenshot_humberger_2.png https://p.gigamix.jp/humberger/cg/screenshot_humberger_3.png https://p.gigamix.jp/humberger/cg/screenshot_humberger_5.png

ゲーム内容

 思わず食べたくなっちゃうゲーム。客の注文どおりに材料をのせて、ハンバーガーを作りまくりましょう。電波新聞社・刊「マイコンBASICマガジン」1990年1月号掲載作品。

ルール

  • 客が注文する5種類の食材(バーガー・チーズ・ハム・野菜・パン)を間違えないようにひたすら積んでゆくアクションゲームです。
  • それぞれの食材はキーが割り当てられています。客の指示どおりに食材のキーを押してください。
  • キーを押すのが遅いと”遅い”と文句がでます。まちがえて押すと“違う”と文句がでます。3回文句が出るとクビ(ゲームオーバー)になります。
  • 閉じるためのパンを乗せたらステージクリア。ハンバーガーを作るごとにスピードが速くなっていきます。とくにパンをのせるのが速くないと速攻でクビになります。
  • 給料(スコア)は、材料の重ねる数とスピードで計算されます。スピードが上がるたびに給料があがりますが、むずかしくなります。

遊びかた

 タイトル画面のときに、スペース・バーかジョイスティックのボタンを押してください。以後、押したデバイスでゲームをします。

 カーソル・キーまたはジョイスティックの4方向にハンバーガーの4種の材料が割り当てられています。画面左上に表示される客の注文どおりにボタンを押してください。

  • バーガー…「↑」(カーソル上 または スティック上)
  • チーズ…「→」(カーソル右 または スティック右)
  • ハム…「↓」(カーソル下 または スティック下)
  • 野菜…「←」(カーソル上 または スティック左)

 最後のパンはスペース・キーまたはトリガ1を使います。

今すぐ遊ぶ

 以下のURLをクリックしてください。PC・スマートフォンWebブラウザ上で遊べます。

https://webmsx.org/?MACHINE=MSX2J&DISK=https://www.gigamix.jp/humberger/HUM110P.DSK&P=KANJI

ダウンロード

ソフト名ハンバーガー・ショップ for MSX2
ハードMSX2(VRAM 128KB)、MSX2+MSX turbo R
要・JIS第一水準・第二水準漢字ROM
対応OSMSX-BASIC ver.2.0 以降
作者nf_ban(Gigamix)
リソース 原版(LZH) HUM110P.LZH 2020.12.15, 7211 Bytes
再配布版(ZIP) HUM110P.ZIP 2020.12.15, 7302 Bytes
ディスクイメージ HUM110P.DSK 2020.12.15, 737280 Bytes

Webアプリ版もあります

 HTML5で制作されたWebアプリ版はこちら www.minagi.jp

こぼれ話

 原作はマイコンBASICマガジン1983年5月号掲載のNEC PC-6001版「ハンバーガー・ショップ」

https://p.gigamix.jp/humberger/cg/photo_humberger_bm198305_1.jpg

 時は1983年、投稿プログラム雑誌「マイコンBASICマガジン」に掲載されたNEC PC-6001用の「ハンバーガーショップ」というゲームソフトがたいへん面白いゲームでしたので、これをMSX2パソコンへアレンジ移植し同誌へ投稿したところ、1990年1月号にてめでたく採用されました(掲載当時は「msxban」というペンネームで活動していました)。

https://p.gigamix.jp/humberger/cg/photo_humberger_bm199001_1.jpg https://p.gigamix.jp/humberger/cg/photo_humberger_bm199001_2.jpg

 しかし2003年4月をもって「ベーマガ」は残念ながら休刊を決定してしまいました。

 今でも十分面白いとゲームと思いますし、ベーマガに掲載された作品については、ネット上での作者による無料公開は自由ということが公式ホームページ上で述べられていましたので、休刊を惜しみつつ、記念に皆さんに遊んでいただきたく今頃になって同誌プログラム投稿規程(その他の項目5)に基づきインターネットにて配布することにしました。

 マイコンBASICマガジン プログラム投稿規程 http://www.basicmagazine.net/bm/entry/ptoukou.htm

【注】その後2015年になって電波新聞社の「電子工作マガジン」内に「マイコンBASICマガジン」が復活することになろうとは思わなんだ… denkomagazine.net

製品情報

  • 初出:1989年(1996年にWeb公開開始)
  • 対応ハードウェア:MSX2(VRAM 128KB)、MSX2+MSX turbo R
  • コピーライト表記:© 1983 PINEAPPLE SOFT/Y.Matsuki, © 1989 1996 Gigamix, All rights reserved.

クイズ!あたっちゃって25% MSXで8人同時に楽しめる、テレビ番組風クイズゲーム

 当クラブは昔にこういうゲームを作っていました。

タイトル画面

https://p.gigamix.jp/ds2/cg/screenshot_atch_1.png

ゲーム画面

https://p.gigamix.jp/ds2/cg/screenshot_atch_3.png https://p.gigamix.jp/ds2/cg/screenshot_atch_3.png https://p.gigamix.jp/ds2/cg/screenshot_atch_3.png

ゲーム内容

  • 最大5人(または8人)まで同時に参加できる、MSXパソコン向け対戦クイズゲームソフトです。
  • コンピュータAIを含めた全200人でTVのクイズ番組に参加する体で、早押し勝ち抜きクイズに挑戦します。難問・珍問の約800問があなたの頭脳を刺激します。
  • 「ピリオド」と呼ばれるクイズのジャンル単位ごとにチャンピオンを一人決めます。ピリオド毎に問題数がランダムに決められ、最終問題で一番速く正答した人 または 一人で勝ち残った人 がチャンピオンです。
  • クイズは1問ごとに全員同時に10秒以内で回答してゆきます。誤答または時間切れしたプレイヤーは失格となり、そのピリオド内では回答権がなくなります(ピリオドが変わると回答権が復活します)。さらに、クイズに正解しても回答時間が一番遅かった人は強制的に失格です。
  • 全員失格するケースも有り得なくはないのですが、全員失格した場合はチャンピオンなしで次のピリオドへ進みます

ここが見どころ

  • MSX2で、PCMによるテレビ番組風実況アナウンスが行われます!司会がひたすら喋り続けます。
  • AIと言っても簡易的な思考ルーチンではありますがCOMプレイヤーは人間っぽさが出る思考と回答を目指しました。AI一人ひとりに得意不得意のパラメータを与えています。優しい問題は正答に集中し、難しい問題ほど4択がバラけて遅く回答するようなセッティングになっています。
  • サークルPCCMの同人マルチタップ「忍者タップ」に対応しています。忍者タップを2個接続することで、最大8人プレイが可能です。
  • 回答時間が一番遅かった人が同タイムで複数人居る場合は、複数人まとめて失格します!滅多に起こらないレアケースですが、頑張って実装しました。

ミドルウェア

 当クラブのBASICプログラム開発支援ツール「DMシステム2」を採用しました。

 MSX2における漢字テキスト表示、PCM再生、BGM再生(MuSICA)、忍者タップのデバイスドライバ対応、パレットアニメーションの演出、画像データ圧縮等の各種処理をBASIC環境上で構築しています。

 DMシステム2はどなたでもご自由にソフトに組み込んでお使いいただけますので、こちらもどうぞよろしくお願いします。https://gigamix.jp/ds2/

こぼれ話

 MSXの市場が冷えていった1990年代後半はパソコン通信やインターネットを通じてMSXの愛好家同士が直接会うコミュニティが全国各地で発生していました。そういったイベント会場で盛り上がれるパーティーゲームはそもそもMSXでは数が少なかったため、「あたちゃ」それなりに好評をいただけました。

 開発の経緯、および90年代後半のMSXシーンについては「マジカルラビリンスRemix」でも振り返っていますので、そちらも合わせてご覧ください。

gigamix.hatenablog.com

製品情報

  • 初出:1997年(1998年・2000年にアップデート実施)
  • 対応ハードウェア:MSX2(VRAM 128KB)、MSX2+MSX turbo R
  • メディア:2DDフロッピーディスク 1枚
  • コピーライト表記:© Gigamix/ATCH Project 1997-1998

MGSDRV:仕様?バグ?未確認情報まとめ

随時更新中

 MGSDRVに関する既知のバグ情報、バグなのか仕様なのか分からないような未確認情報をまとめました。ご迷惑をおかけします。

 バグ情報・不具合情報をお待ちしております。当チーム @nf_ban(主宰) または @goripon_tw(プログラム担当) までお寄せください。

https://p.gigamix.jp/mgsdrv/cg/buglist.png

ちなみにMGSDRVの概要・ダウンロードは、こちらのリンクからどうぞ。 www.gigamix.jp

未解決・未調査の情報

コメント行が256文字を超えると演奏されない現象が発生する?

kf→koの切り替え前後に共通したリズム楽器が指定されている場合、そのリズム楽器が発声されない?

kf→koの切り替え前後に共通したリズム楽器が指定されている場合、そのリズム楽器が発声されない。(y14,32を間に記入することで回避できます。) https://f.msxplay.com/?id=d92848c3 #MGSDRV https://t.co/BrQnU2GnlW?amp=1 — Pt.Macumba (@Pt_Macumba) 2021年2月23日

 詳細不明ですが、回避策はあります。

vbの相対指定を使用すると他のリズム楽器も巻き込まれて音量が変化する?

vbの相対指定を使用すると他のリズム楽器も巻き込まれて音量が変化する。(vの相対指定と同じ動作をする。) https://f.msxplay.com/?id=9180ce68 #MGSDRV https://t.co/0o47EgjZDx?amp=1 — Pt.Macumba (@Pt_Macumba) 2021年2月23日

 詳細不明です。

opll_tuneで指定した値によっては音程が意図しない高さになる?

opll_tuneで指定した値によっては音程が意図しない高さになることがある。トラック1(音階指定,opll_tune使用)→トラック2(opll_tuneで指定した値と同じ値をyコマンドで書き込み)→トラック1&2同時再生 https://f.msxplay.com/?id=02a58331 #MGSDRV https://t.co/1tDPCaykZP?amp=1 — Pt.Macumba (@Pt_Macumba) 2021年2月23日
opll_tuneの指定値が171以下の場合にこの仕様が発動する。F-Numberの値は344-(171-opll_tune指定値)になり、Blockが-1される。(o1の場合はオーバーフローします。) — Pt.Macumba (@Pt_Macumba) 2021年2月23日

 詳細不明ですが、回避策はあります。

machine_id の使い方が不明?違いはあるのか?問題

研究いただいてありがとうございます。m(_ _)mmachine_idについて、既存データにmachine_idを付加するツールを使った事があるのですけど、私も違いが分かりませんでした^^;MSXメーカーや機種毎にカートリッジスロット部の抵抗値に違いがありますが、抵抗値を変更するしか特効薬は無い様ですね。 — ひぽぽ(ファミコンGimmick!👍 (@koichironakaza1) 2020年7月23日
machine_idの違いがわからないのは自分だけではないということで安心しました(おぃ 機種毎の音量違いはMMLのボリューム値を変えただけではなかなか対処できないのでほんとに厄介です。なので今作っているグラディウスの曲は機種による音の違いが出ないようSCCのみで作っているのですが・・・ — ぱるぷ (@parupu_x_nagae) 2020年7月23日
machine_idの挙動について昔ain氏に聞いたことがあるんですが、MGSCでは単純にIDの記録をしているだけで、実際の音量の調整はMGSELで再生時に行っていると聞いた記憶があります。動作は3音源の最大音量を下げて調整だったかと。なのでMGSDRV単体でのプレイでは反映されない…はず(記憶あやふやです — たかを (@takawo_n) 2020年12月31日
MSXplayのチップ毎の音量バランスは実機が基準ではありません。計算が軽いバランスになっています(確かvgmplayと同じにしたはず)。ただ、FS-A1STの実機で作ったデータを再生した際に、極端に違和感がないようなバランスにはなっているはずです。 — DSA (@ym2413) 2021年1月1日
 私(nf_ban)も調査を進めていますが、今のところ machine_id に対応するアプリは MGSEL のみ、machine_id の違いを定義する仕様書の類も存在しない、という状況です。

バグではなく仕様の情報

SCCI(スナッチャー付属サウンドカートリッジ)に対応している?

 コナミの各種ゲームカートリッジに内蔵されていたSCC音源はチャンネル4とチャンネル5を共通の波形でしか利用することができないハードウェア仕様でしたが、「スナッチャー」の付属サウンドカートリッジ(通称:「SCCI」「SCC-I」「SCC+」)はチャンネル4とチャンネル5を独立して利用できるハードウェア仕様となっています。

 ですが、MGSDRVではSCC-Iに現状非対応です(SCCと同じ振る舞いを行います)。SCCIのチャンネル4とチャンネル5は共通の波形で動作します。今後対応できるかもしれませんが、開発機材=実物(カートリッジ)の確保が急務。

あれ?mgsdrvってSCC+の4/5チャンネルの独立音色モードって対応ってしてたっけ。なんか昔対応してない、という話になったような記憶が...。— DSA (@ym2413) January 21, 2020
MGSDRVバージョンアップするとして。MSX1を想定した件の修正と、可能ならSCC+対応(4/5チャンネルの個別音色指定)はやりたいな。あとはバグ修正だけど…ややこしいのばっかりだからなー。むぐぐ。 — ごりぽん (@goripon_tw) 2020年9月15日

 SCC-I対応を行うにはドライバの新設計が必要との見解です。現状はペンディングです。

SCC+対応、そういえば似非SCCはSCC+相当で動作してるんだっけか…。うへぇ。判定できるのかな? — ごりぽん (@goripon_tw) 2020年9月15日
4チャンネルの波形メモリに書き込んで5チャンネルの波形メモリを読んで変化があれば似非とかなら判定できるかなと考えてますが…。 — ごりぽん (@goripon_tw) 2020年9月25日
mgsフォーマット自体にフラグを持たせて、mgscに#scc_type みたいなコマンドを拡張する感じではないでしょうか。既存のデータでも誤って4/5チャンネルに別音色を指定してしまっているものがありそうな気がするので、自動判定は難しそうな気がします。 — DSA (@ym2413) 2020年9月25日

音ずれが発生する

MGSDRVのバグで1つ思い出したのは、(発生条件が判らないのですが)「1音目の発音音階が化ける(別の音になる)」というやつです。 なので、今でもMGSDRVのデータは、全chでv0のダミー発音データを入れてます。 MSXplayの「Arabiyaan」にも入ってるw https://t.co/hbhre3y9G0 https://t.co/jtIlJiiwo1 pic.twitter.com/of5MZ7JkI7 — Wiz.@「ペンゴ!オンライン」2曲「キャラバンブーマー」1曲作編曲担当 (@WizardOfPSG) November 17, 2019
あー…想像以上にずれてますね。 流石にこれはMGSDRVのバグっぽいですね。 他にもいくつかバグがあったような。 https://t.co/zWQFTcM8a1 — Wiz.@「ペンゴ!オンライン」2曲「キャラバンブーマー」1曲作編曲担当 (@WizardOfPSG) November 17, 2019
いやぁ…どうでしょう?w 拙者は音を敷き詰めて曲を作るタイプなので、メロだけ浮かせて静かな音色でモーフィング掛けると目立つ…のかもしれません。 もしかすると、MGSDRVの作者の方が、何等かの対処をしてそうな気もしますが。 https://t.co/pcwrvxh9UC — Wiz.@「ペンゴ!オンライン」2曲「キャラバンブーマー」1曲作編曲担当 (@WizardOfPSG) November 23, 2019
Webの「MML Editor」に読み込ませた.MUSの演奏時間を拡張するコマンドがあったのか!MGSCの取説に載ってなかったような?やり方は、.MUSの冒頭に「;[duration=600s]」を書き込んでコンパイルすると、演奏時間が600秒に拡張される。コマンド内の「600s」の値を変更すれば、任意の演奏時間に変更可。 https://t.co/mznphNGJNh — ぎゃぶねこ (@gyabuneko) December 4, 2019

E+ と E が同じ音階になる

 一般的にMML表記の「E+」は「F」の音階または相当の音階になるようですが、MGSDRV(MGSC)では「E」になります。方言となりますのでご注意ください。

ぎゃー24行目に打込みミス発見・・!CDE [[BAEF+4E+4B] [AG+F+D4F+G+A]] [BAEF+4E+4BAG+F+D4F+G+A] 「E+4」の部分がそれです。幸い、音自体は「E」の音で鳴ってくれてました。てっきり「F」音が鳴るものと・・焦った~ — K.H.(焼飯太郎)@モーメントに作品まとめてます (@Yakimeshi_Taroh) October 15, 2020
厳密に言うとMGSDRVではなく、MGSCの仕様と思います。基本的には E+ = E で扱われることはないと思います。E+ = F で演奏するか、E+ と F を微妙に違う周波数で演奏するかは、調律や楽器によるかなと思います。 — DSA (@ym2413) October 16, 2020

@eエンベロープで音色を切り替えると音がおかしくなる現象

 MGSDRVの @e コマンドは「現在の音色にエンベロープをコピー」という意味です。 @ コマンドで一度も音色を指定していない状態で @ e コマンドを使うと、音が出なかったり変な音が出たりします。

 特に曲の冒頭で音がおかしくなる場合が目立つのは、キーオンから @e が適用されるまで一瞬だけ別の音色が適用されているから。バグとも言えるかもしれませんが、ver.3シリーズにおいては仕様となります。

MGSDRV、@ e エンベロープで音色を切り替えると特に曲の冒頭で音がおかしくなることが多いですが、これはキーオンから @ e が適用されるまで一瞬だけ別の音色が適用されているからです。 — DSA (@ym2413) February 18, 2020
英語では何度かツイートしましたが、MGSDRVの @ e コマンドは「現在の音色にエンベロープをコピー」という意味です。 @ コマンドで一度も音色を指定していない状態で @ e コマンドを使うと、音が出なかったり変な音が出たりします。 — DSA (@ym2413) February 18, 2020

@コマンドで一度も音色を指定せずに音を鳴らすと最初の1音だけ「ビ〜〜ッ」っという謎の音が入り、以降の音は鳴らなくなる現象

 エレキベースの音が一瞬鳴った後、空のユーザー定義音色(すべての音色パラメータが0)に切り替わったことによって出る異音、とのこと。発音前に音色指定を必ず行ってください。

@コマンドを指定せずに @eコマンドを利用すると演奏結果が不定になる

これは @ コマンドを指定せずに @e コマンドを使うと、演奏結果が不定になる(環境によってどんな音が出るか分からない)という現象ですね。MGSDRVの仕様です。この曲のイントロについては353行目から360行目の @e コマンドの前に @ コマンド(例えば11番あたり)を入れてやると直ると思います。 - DSA (@ym2413) 2021年3月2日

「9音リズムモード」でHチャンネルの音量が全く反映されない

試行錯誤して、9音リズムモード (FGHチャンネルにリズム使用) で、Hチャンネルに音量が全く反映されていない事に気づいた。多分、ハードウェア的な仕様だよなぁ。でもなぜかソフトエンベロープ(@e)指定だと、固定の音量に下がる挙動になる不思議。多分、v と@eで内部処理が違うんだろうな。#MGSDRV — たかを (@takawo_n) 2021年2月23日

 本来設定できない「9音リズムモード」。特殊な環境なのでバグなのか仕様なのか分かりにくいのですが、OPLLの仕様のようです。

レジスタ構成の関係でHチャンネルはvがシンバルの音量、音色番号がタムの音量(14,13,12...,0,15の順で音が大きくなります)になります。例えば H y14,32 q8 v8@14 c4 でシンバルが音量8、タムが音量0で鳴ります。G チャンネルだとvがスネアの音量、音色番号がハットの音量になります。 — DSA (@ym2413) 2021年2月23日
作る側の夢としては、9音リズムモードなる opll_mode 2 を用意してもらって、そのモードではFGHチャンネルのリズム音源に指定したMMLが思い通りに音に反映される動作…という感じになるのでしょうか — たかを (@takawo_n) 2021年2月23日

 こちらは新バージョンへの要望。

半角スペースの入れ方に注意

ちょいと所用でMGSDRVをいじってるんですが、「音階と音長の間」の半角スペースは無視されるけど、「マクロ種別と数値の間に半角スペースを入れるとエラーになる」のね…知らなかった。例)〇a8〇a 8〇*b8×*b 8…って、こんな書き方しようとしてるのは拙者だけかもしれませんがw — Wiz.@「ペンゴ!オンライン」2曲「キャラバンブーマー」1曲作編曲担当 (@WizardOfPSG) 2020年12月6日
MGSDRV自体はコンパイルされたバイナリデータを再生するので、どちらかというとMGSCの仕様ですね。MGSCもソースが失われていて復旧もされていないので手を加えられないのですよ。 https://t.co/PnLQ1eFXX1 — ごりぽん (@goripon_tw) 2020年12月7日
 twitter@Wiz.さんの報告。「音階と音長の間」の半角スペースは無視される、マクロ種別と数値の間に半角スペースを入れるとエラーになる。バグとも言えるかもしれませんが、ver.3シリーズにおいては仕様となります。

MGSCNV: ver.2→ver.3への変換の違いについて

ver2をver3にツールで自動変換した.mgsファイルを、MSXplayの逆コンパイル機能で変換したMMLを解析してみたのですが、違いがあったのは・・・・データの冒頭で「machine_id」と「alloc」が追加されている・テンポが1/2になっていて、MMLの音長も1/2にされている続きます — ぱるぷ (@parupu_x_nagae) 2020年7月23日
検証に使用したファイルも自前のレンタル鯖に置いておきますね。ver2のBASICファイルhttps://t.co/TCWPNj2dcrver2をver3に自動変換して、MSXplayで逆コンパイルしたテキストhttps://t.co/l1CJ99vwbY — ぱるぷ (@parupu_x_nagae) 2020年7月23日
 変換後のテンポと音調が1/2になるのはバグとも言えるかもしれませんが、ver.3シリーズにおいては仕様となります。

プライマリのマッパーRAMへしか常駐できない?

MGSDRV ですが、PrimaryMemoryMapper にしかインストールできないみたいですね。プライマリを消費し尽くしてから常駐させて、MGSPから曲を読み込んだら、漢字RAMのときと同じ理由で死ぬかなと、テストを試みたのですが、そもそも MGSDRV がプライマリしかダメでした (^^;#MSX #MGSDRV — HRA! (@thara1129) October 19, 2020
常駐部分の簡略化とスロット切替のコストを嫌ってのことですね。基本的にDOS2でマッパ使って常駐するものには要プライマリマッパってのが多いような? https://t.co/YWxDBHOJIo — ごりぽん (@goripon_tw) October 19, 2020
 各種拡張メモリカートリッジをスロットに差すような「マッパーRAMが複数ある状態」の場合でも、MGSDRVではプライマリのマッパーRAMでしか常駐できません。turboR規格の場合は本体内蔵RAMが自動的にプライマリになります(A1ST 256KB、A1GT 512KB)。

任意のアドレスへ移動(リロケート)ができない?

制作しているメガROMゲームにMGSDRV実装案もありまして、自己書き換えやっているのでRAMのどこに置いたらいいかと、PAGE1ですかねぇ・・・? — むらかたとうじ/村方凍二 (@ipheion78) 2020年12月7日
mgsdrv.com を丸ごとROMにおいて、+0010h~(だったかな?)を RAMのpage1の 6000h~ にコピーして使えばよいと思います。そこにおかれる前提でアドレスが設定されてるので。 — HRA! (@thara1129) 2020年12月7日
元々がPage1(確か6000h~)で動作しているのでリロケートしないと他には置けないですね。ドライバのサイズは8KB上限と定められていたかと思いますが…ワークRAM込みだったかな?やっぱりROM組み込める版が必要か…。 — ごりぽん (@goripon_tw) 2020年12月7日
仕様書を見ると、一時期 MGSDRV.REL というものが公開されていて、それは L80. COM でアドレス再配置できたようですが、いまはCOMしか見あたらないので 残念ながら6000h固定ですね😅4000h~5fffhは自由に使って良いようです。 — HRA! (@thara1129) 2020年12月7日
以前はMGSDRV.RELが公開されてたのか。まさにMGSDRV.REL公開できないかなと考えてたところなので…仕様書読んでみるかー。 — ごりぽん (@goripon_tw) 2020年12月7日
 MGSDRV本体はリロケータブルではありません。ただし過去にMGSDRV.RELというファイルがパソコン通信ネットで流通していて、MSX-L80を用いて再構成することで任意のアドレスへ移動が可能だったようです。

 当クラブではMGSDRV.RELを入手および管理していません。もし今でも関連ファイル・アーカイブをお持ちの方がいらっしゃいましたらぜひご連絡ください。

管理者は見ている

2桁年ぶりにMGSDRVをバージョンアップするかもと言う話になってるんだけども。最新版って3.20で合ってるよね?(汗)(苦笑)何せ2桁年経ってると手元の物が最新かどうかも微妙なうえ、もうちょっとバージョンが上がってたような気もするので…。 — ごりぽん (@goripon_tw) September 14, 2020

MGSDRVのトップページ → https://www.gigamix.jp/mgsdrv/