Gigamix Online

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

MSX Disk BASIC環境のソフトウェアをROM化してリリースしたい(妄想編)

 twitterのタイムラインを眺めながらブレインストーミング。思いつき次第、適当に追加してゆきます。

https://p.gigamix.jp/devmsx/cg/disk-to-rom_title.png

きっかけ

dsk2romというMSXのディスクイメージファイルをROMイメージ化できるアプリがあったので自作のソフトを変換してみたのだがROMから起動できなかった。BASICのAUTOEXEC.BASから起動するような同人ソフトには非対応かもね。変換の仕方が悪いのかもしれんけど…DISK BIOS相当の機能が入ってるとは思えない。 pic.twitter.com/0lZ6mpqdcP — Takashi Kobayashi (@nf_ban) 2021年8月6日
ん!?ROMイメージのタイプを「コナミSCC」に変更したら動いたぞ!?どういうこと!? pic.twitter.com/GCPq0Bx1ru — Takashi Kobayashi (@nf_ban) 2021年8月6日

 「dsk2rom」というアプリでMSXフロッピーディスクイメージファイルをメガROMイメージに変換できることを知り、拙作の「クイズ!あたっちゃって25%」というBASIC環境のゲームソフトをROMイメージ化してみたら、あっさり動きました

github.com

 ファーストトライで動かなかったのは、出力するROMイメージのメガROMタイプがデフォルトで「コナミSCC」であることを忘れていたためでした。

あれ!?エミュレータでFDDの機能を切ってる(WebMSXでフロッピーアイコンが無い)のにDisk BASICが動いているではないか。ってことはDISK ROM BIOSを内蔵してるってこと!?んー、Microsoft or アスキー製の互換品なの?ライセンス大丈夫なのか、これ。 pic.twitter.com/i0MqEv3F78 — Takashi Kobayashi (@nf_ban) 2021年8月6日

 どういう仕掛けなのかと思って少し調べてみたら、なんと「ROMイメージ内にMSXのDISK ROM BIOS(とディスクイメージ相当のストレージデータ)を同梱していて、ROM起動なのにDisk BASIC ver.1が利用可能になっていた」のです。BIOSを積んでいるので、FDDを搭載しない(=Disk BASICが起動しない)機種でも、BIOS経由のどんなディスクアクセスでも、基本的にROM内で再現できるはずです。

 ところが、2021年現在ではMSXの各種公式BIOSは元アスキー創業者の西和彦さん率いるMSXライセンシングコーポレーションの著作物となっています。

www.n-and-partners.jp

んー、ですよねー。そりゃそうだ、世の中そんなに甘くないのです。 pic.twitter.com/8yd3U3qkLA — Takashi Kobayashi (@nf_ban) 2021年8月6日

 dsk2romは既存のDISK ROM BIOS(DOS1カーネル)をZ80向けに逆アセンブルしたと思われるソースコードGitHubで公開されていました(dsk2rom向けの改造も施されている可能性もあります)が、MSXライセンシングコーポレーションの承認なしに公開されているのではないか?学術目的とは言えソースコードを公開するのはライセンス違反ではないか?…つまり、現状はこの技術を利用して新作ソフトをリリースすることは著作権的に実現できない、と思うわけです。

 とは言え、この技術は今MSXの界隈で喫緊の課題になっている「製造が停止してしまったフロッピーディスクでなくROMカートリッジで新作ソフトをリリースする手段」を一気に解決できるほどのポテンシャルがあります。FDD搭載機と同じ環境で開発が継続でき、ソフトのリリース時にROMイメージ化してROMへ焼くだけです。新作ソフトはもちろん、過去にリリースされたソフト、リリースが叶わず埋もれてしまったソフトの復刻も容易になります。

今求められている技術

  • ファイルストレージとストレージコントローラのような仕掛けがROMにパッケージングされていること
  • ライセンスに違反が発生しないこと
  • 2DDフロッピーディスクの代替という側面から、4Mbit(512KBytes)のメガROMカートリッジと同等規模(やそれ以上)の実装が予想される
  • フロッピーディスクからROMカートリッジへのメディアコンバートが容易であればあるほど良い
  • 変換時の互換性は高いほど良い

イデア①:公式のBIOSをライセンスしてもらいたい

ディスクROMだけ公式ライセンス降ろして貰えれば一発解決なんだけどなー。50円/個とかでできないだろうか。さすがにDisk-Basicの互換品をいまさら作るというのは不毛だ…。 https://t.co/LCX2d38EUe — MSX研究所長 (@yoshimatsuTUQ) 2021年8月6日

 新作ソフトの販売者がdsk2romに同梱するDISK ROM BIOS(DOS1カーネル)に対してMSXライセンシングコーポレーションへBIOSのライセンス料を支払い、正式にライセンスの承認を得ることが可能になれば、dsk2romの技術だけで今すぐ新作ROMソフトが製造・販売できるようになります。

 この手法のメリットは、圧倒的な互換性の高さ。BASIC・マシン語双方のソースコード修正は殆ど不要と思われます。

 メガROMタイプは「コナミSCC」または「ASCII 8K」でイメージ化できます。最近はメガROMコントローラに互換性がある頒布用の新基板がいくつかリリースされていて、組み込み用途にも応じてもらえるようです。

 ハードウェア的には実現可能でも個人製作のソフトに対して公式BIOSのライセンスなんて認証されるのか?これは事例があります。

これ、BIOSのライセンス料がいくら載っているのか…ソフト1本あたりなのか、包括契約的なものなのか…?https://t.co/XW5NukTwdz — Takashi Kobayashi (@nf_ban) 2021年8月7日

 MSX・FAN誌の投稿プログラムコーナー「ファンダム」で一躍有名になったTPM.CO SOFT WORKSさんは、自身のMSX1用ゲームソフト「タロティカ・ブードゥー」を2017年にSteamで配信しました。どう実現しているかと言うと、公式のエミュレータであるMSXPLAYer上に公式BIOSとコンテンツ(ディスクイメージ)を同梱したWindowsアプリに変換(メディアコンバート)しています。

https://p.gigamix.jp/devmsx/cg/disk-to-rom_tarotica_opening.png

 アプリ内にMSXライセンシングコーポレーションのライセンス表記がありますので、これは正式にライセンスが認証されたコンテンツであることが分かります。

store.steampowered.com

 個人やインディーが許諾を得る方法を私は知りませんが、存在すると思いたいです。まぁ、西さんにメールやtwitterへ聞けばいいだけの話かもしれませんが。

 なお、Disk BASICの動作条件として、32KBytes以上のRAMが必要です(MSX-DOS1は64KBytes必須)。これにより、RAMが16KBytes以下のMSX1では動作しません。事実上、MSX2以降の対応品となるでしょうね。

イデア②:Nextorを同梱する

にがさんの似非ROM基板に、NEXTORのカーネルROM書き込んでNEXTORが起動してMSXーDOSアプリが動作するするROMは作成できたので、NEXTOR使ってdsk2romと同じような事はできそうな気がします。 — 超兄貴 〜シン・MSX〜 (@SuperAniki_MSX) 2021年8月6日
Nextorならライセンスの問題はクリアですかね。あれっ、RAMは必要ではなかったでしたっけ。例えばMSX1の16KBのマシンでNextor BASICは動くのだろうか…?🤔 — Takashi Kobayashi (@nf_ban) 2021年8月6日
64KBは必要でしょうね・・・しかしBASICプログラムなら大概そのままROM化できますし、カセットテープやテープ形式の非圧縮音声で配布とか。 — 超兄貴 〜シン・MSX〜 (@SuperAniki_MSX) 2021年8月6日
自分の経験ですと、BASICプログラムが1本のみという製作方法がピンと来なくて、プログラム以外のデータを都度読んでゆくようなファイルシステムというかストレージのような仕掛けが欲しくなるんですよね。なのでdsk2romの可能性には期待していたんです。まぁ作り方でどうにでもなる話かもしれません。 — Takashi Kobayashi (@nf_ban) 2021年8月6日

 「Nextor」はMSX-DOS2の上位互換となる、MSXライセンシングコーポレーション(=西和彦さん)に承認されたかもしれないオープンソースの新しいDOS(Nextor DOS)です。

www.msx.org

 dsk2romはDisk BASIC ver.1(DOS1カーネル)を同梱していましたが、Disk BASIC ver.2の上位互換である「Nextor BASIC」を内包するオープンソースのNextorカーネルへ変更すればライセンスの問題が解決する、かもしれない

 「かもしれない」とあえて強調しているのは、Nextorが本当にMSXライセンスコーポレーションの認証がされていて、本当に無償で利用可能かのエビデンスが存在しないからです。

https://t.co/Au3fpKOtsD MSXVRMSXロゴ許諾についてNEXTOR作者のKonamiman氏が西さんと直接話をしたとあります。NEXTORをオープンソース化するのに問題はないか確認した際にMSXVRについても触れたとのこと。※ただしこれは西さんやMSXライセンシングコーポレーションからの発表ではありません — うにスキー (@uniskie) 2020年11月25日
この時点ではMSXBASIC自体のライセンスはマイクロソフトにあり、1台につき1$のライセンス料が必要とありますね。BASIC以外のシステムロムに関しては西さんのMSXライセンシングコーポレーションが権利を保有するとの事で、MSXDOS2関連を含むNextorのオープンソース化について許諾を得たという話。 — うにスキー (@uniskie) 2020年11月25日
原文では西さんによる「祝福」とあり、「公認」は意訳なので、西さんが「いいね!」しただけなのでは。ともとれるんですよね。NextorなどはMSXDOSコードの再利用について具体的な著作権説明が記載されていますが、MSXVRはそれに該当する物が今の所見つけられてないので、気になっています。#MSXVR — うにスキー (@uniskie) 2020年11月26日
Konamimanさん経由で話が通ったのであれば、その辺のシステムROMの使用については確認取ってそうなものですが、確定できる情報をまだ見つけられてないんですよね~。NextorとMSXVRは別の話ですし、どうなってるんでしょうね。どなたかそのあたりご存じでしょうか?https://t.co/eU7xB7ijyK — うにスキー (@uniskie) 2020年11月26日

 メリットは、ライセンスの問題が解決するかもしれないこと、Disk BASIC ver.1との互換性が一定量は担保されていることです。DOS1からDOS2・Nextorへの乗り換えは若干の修正が必要かもしれません。

 なお、Nextor BASICの動作条件として、64KBytes以上のRAMが必要のようです(未確認。Nextor DOSは256KBytes以上のRAMが必須)。Nextor自体はMSX1で大容量ストレージが制御できる性能があるのにメモリ不足による理由で動作できないのは勿体ない話です。事実上、MSX2以降の対応品となるでしょうね。

イデア③:Disk BASICの代替手段を拡張BASICで提供する

拙作のミドルウェア・DMシステム2 https://t.co/8tfHL2O5JG には CALL LOAD というとにかくRAMやVRAMへガンガン転送するという拡張BASIC命令があったんですけど、コンテンツをROM化するときに自身でBASICを拡張してLOAD命令もRUN命令も代替手段で実現すれば、Disk BASICが不要なんじゃないか?って。 — Takashi Kobayashi (@nf_ban) 2021年8月6日
ROMは4000hから7FFhまで拡張BASICのストレージ制御システムが入ってて、8000hからBFFFhまでメガROMで切り替えてストレージが見えたりして、C000hからRAMが見えてBASICプログラムを転送できたりしたら、16KB RAMのMSX1でファイルシステム持ちながらソフトが動かせるんじゃないの?って。 — Takashi Kobayashi (@nf_ban) 2021年8月6日
2DDで動作するMSX-BASICゲームをRom化する話がTLに流れてましたが、過去作品をROM化する場合と、これから作る場合とで技術的な課題は大きく違いそう。これから作る場合、最初からROM化を前提とした仕組みを用意しておけば敷居が下がると思います。#MSX — HRA! (@thara1129) 2021年8月8日
例えば、_LOADなどの命令を搭載したROMを2種類用意します。両者には命令に互換性がありますが、1つはアクセス対象がディスク上のFAT-FS。もう一つはROM上に形成した簡易的なROMディスク。開発時は前者を使い、ROM化するときは後者を使う。誰かがこのROM開発すれば解決、誰が?🤣 — HRA! (@thara1129) 2021年8月8日
最初に挙げた「敷居」とは、DiskBasicまでまるごとROMに書き込んじゃうと権利問題にぶつかる、という敷居ですね。明確な解決方法が不明なモノなので、かなり高い敷居です。なら、そのアプローチをやめちゃえば一気に解決するのでは?というアイディアを書いたのでした。 — HRA! (@thara1129) 2021年8月8日

 拙作ミドルウェア「DMシステム2」では CALL LOAD というBSAVEヘッダの有無問わずディスク上のファイルをメモリへ転送する命令が搭載されていました。ROMの中にそういうストレージアクセス系の命令を代替する拡張BASICのシステムと仮想ストレージを含んだROMイメージを作成することができれば、Disk BASIC(DOS1カーネル)を使用する必要がなくなり、ライセンスの問題が解消されます。

 ほかのメリットは、Disk BASICではないのでRAM 32KBytes以上必須の条件が撤廃され、RAM 16KBytesのMSX1を動作対象に含めることが可能かもしれません(とは言えさすがに8KBytes機はキツいと思うのですが…)。MSX2等64KBytes以上のRAM搭載機を動作対象とする場合にFDDの接続を切るように起動すればBASICのフリーエリアが約23KBytes(Disk BASIC ver.1)が約28KBytes(Disk BASIC非搭載時のMSX BASIC)へ広がる可能性もあります。

 新規で開発するぶんには良いのですが、完成済みのソフトはBASIC・マシン語ともにソースコードの修正は必須です。過去に作成したソフトだと仕様書や技術資料が残っていないと改修できないかもしれません。

昔の記憶ですと…run,load,bloadは間違いなく使いますね🧐 open,copyは使ったり使わなかったりです。場合によってはsaveとかbsaveも使うかもしれません。(セーブをパスワード式かPACにすれば使わないけど) — hide_san(ヒデ) (@_msx_) 2021年8月6日
情報ありがとうございます。ROM化されたゲームのデータ保存方法は別個で考える必要はありますけど、使う命令としてはそんな感じですよね。拙作DMシステム2だとBLOADはCALL LOADで代替、COPYはBPE圧縮で代替できるので、他のBASICプログラムをRUNする手段を代替できれば、なんかいけそうな気が!? — Takashi Kobayashi (@nf_ban) 2021年8月6日
「自作ゲームをROMにする」というのは、ゲームで育ってきた自分からすると「夢」の一つでもありますので…いけるといいなぁ(*'ω'*) — hide_san(ヒデ) (@_msx_) 2021年8月6日

 うーん、DMシステム2のROM化対応・機能限定版のようなものを作ったほうがいいのかな…。ストレージコントローラ、メモリ操作系の命令、MGSDRV(+タイマー割り込み管理)を実装の最優先にして、余ったメモリに何かをちびちび移植してゆく感じですかなーと思うのですが、16KBytesは狭いなぁ。

www.gigamix.jp

 いずれのアイデアにせよ、RAMは64KBytes欲しくなります。

オマケ①:令和の今、MSXのソフトを販売することに対しての販売者側の権利について

MSXAの中の人として回答しますが、MSX用ソフトの販売に限って言えば、MSXライセシングコーポレーションに許諾を得る必要はありません。VHS規格を参考に1983年の時点で「ソフトは権利者の許諾なく出せる」と決定され、以降変更されていません。この話題はMマガ永久保存版の記事でも掲載していたはず。 — ごりぽん (@goripon_tw) 2021年8月8日
MSXライセシングコーポレーションに許諾が必要なのは分かりやすく言えば「公式のシステムROMを含むMSX本体の販売」です。Mマガ永久保存版の時に「エミュも本体1台と見做す」というルールが明確化されたので当然エミュでもライセンスが適用され、EGGなどはこれに従っている訳です。 — ごりぽん (@goripon_tw) 2021年8月8日

 MSXライセンシングコーポレーションの著作物(公式BIOS、公式エミュレータであるMSXPLAYer等)がコンテンツに含まれない場合は、許諾の必要なしに販売が可能です。

オマケ②:MSXの商標、MSXのロゴの使用について

MSXライセシングコーポレーションというのがあるので、今はMSXの商標やらもろもろを使ったゲームは、そこのOKが出ないと出せなかったりするのか?みたいな疑問です。いや、アレスタ再販できたらどうなの?とかあるじゃん。 — ほりい なおき (@hor11) 2021年8月7日
もし、MSX用のアプリケーションを出す時に、ロゴの使用が自由だと仮定したら、ライセシングコーポレーションとして社にする意味がまるでないんですよねー。これはちょっと怯んでしまう。 — ほりい なおき (@hor11) 2021年8月7日
通りすがりの知的財産権各種研究科ですが、ぶっちゃけ9類1区分のみなので、コンピュータソフトウェア/ハードウェア以外の物品、例えばキーホルダー、アクセサリ、Tシャツ、かばん等であれば不正競争防止法等に留意して使う分には合法かと思われます。 pic.twitter.com/4UhYToKqtN — マツド教授 (@Prof_Matsudo) 2021年8月7日
そこは抜かりが無かった、、、アパレルも鳥坂先輩の着ているプリントTシャツはダメぽいな pic.twitter.com/xi239iZX8m — きんのじ (@v9938) 2021年8月7日
RIPPLE LASER様のMSXキーホルダー入荷しました。勿論許諾品です。ハーフミラーを含めた5種類で展開中ですよ pic.twitter.com/8kPDrd3UJ2 — アキハバラ@BEEP (@BEEP_akihabara) 2016年9月11日
更新:MSX2+用のキーボードカバーが販売中、正式ライセンス品 アクリル製で税込4,300円、MSX turbo R用も (取材中に見つけた○○なもの) https://t.co/uXvAJNhKJG pic.twitter.com/wc7oMjodRc — AKIBA PC Hotline! (@watch_akiba) 2016年2月6日

 2021年現在、MSXの商標はMSXライセンシングコーポレーションが保有しています。MSXのロゴも商標登録されています。

 WiiWiiUバーチャルコンソールプロジェクトEGGなど、近年のMSXレトロゲームソフトのダウンロード配信では各種公式BIOSを同梱しているからなのか、MSXという商標を用いているからなのか…いずれにせよほぼ全ての復刻コンテンツにMSXライセンシングコーポレーションのコピーライト表記が付与されています。

 商標の明記やロゴの使用許諾については商習慣でケースバイケースなので一概には言えません。パートナー契約をすると無料で記述できる権利が得られたり、契約して有償で記述したり、契約しなくても記述すれば黙認されることもあり…。

こちらですかね。もうアーカイブにしか残ってないので、口約束みたいな状況ですが^^;https://t.co/RHm0S4C3h4 — MA-X @ B-Cat Software (@max_2608) 2021年8月7日
営利でソフト出すのはダメって事みたいだし、グッズもお金払ってくれって書いてあるしで、これが前提だといろいろ終了だな。 — ほりい なおき (@hor11) 2021年8月7日

 00年代当時はユーザーの有志(MSXアソシエーションという任意団体)と西さんとの間でこのように決まっていた(で、ソフトウェア以外のグッズとかも出てた)のですが、2021年現在は西さんの会社が取り仕切っているのでこの条件が今もスライドで継続している、とは断言できないと私は思うんですよね…。

 また、過去のMSXアソシエーションの記述を見るに、M2さんの「アレスタ」復刻のような商業活動と個人・同人活動とではライセンスの条件が違う(案件により違う)可能性もあります。

 MSXのコンテンツ復刻でプロジェクトEGGを長らく運営しているD4エンタープライズさんは西さんと長年の付き合い(殆ど師弟関係な)ので包括契約的なものがあるのかもしれません。

 そういえば近年D4エンタープライズさん以外の会社からMSXのコンテンツが復刻されたのは、コナミさんしか存在しないような…

オマケ③:西さんの見解

 西和彦さんから直接コメントが出ました。「皆んな勝手にやっているみたいです」はいろんな含みがありますね…

雑感

 今回のまとめ記事を書くにあたり、MSXライセンシングコーポレーションの守備範囲を私が圧倒的に知らなすぎる。皆さんはご存知なのかもしれませんが。詳細な情報がWebでは殆ど辿れなかったので憶測や過去のエビデンスで「○○らしい」とふわふわした根拠しか残らないんです。NDAのようにあえてWebで情報が載らないようになっているのかもしれませんが。

 M2さんはレトロゲームの技術集団ですから公式BIOSなんて不要で何から何まで内製できてしまう(法務も余裕で解決できる)から商業案件はそれはそれで進捗を進めていただくとして、内製できる技術力を持たないので公式BIOSを利用したい個人やインディーの人々にもコンテンツの再販や新規リリースしやすいような環境づくりができればいいな、と思っています。

MSX共通・漢字ROMの「非漢字部分」のフリーフォント

 MSXの漢字ROMに含まれている「JISの規格外だがMSXの各機種で共通っぽい非漢字部分の文字群」について、旧JISレベルな実機側との互換性をいまさら取るために手描きをしたライセンスフリーフォントです。

 なんという後ろ向きなソリューション!

MSX共通・漢字ROMの「非漢字部分」とは

 MSXの漢字ROMは旧JIS(JIS C 6226、いわゆる78JIS)ベースですが、主に非漢字部分であるシフトJISコード 81ADh~859Eh には、旧JISでは未定義なのに独自に実装された文字および新JIS(いわゆる83JIS)とは違う独自に実装された文字が含まれています。

https://p.gigamix.jp/devmsx/cg/kanjirom_non-kanji_large.png

 この漢字部分は東芝ワープロRupoシリーズと互換性があるものの、MSXにおいては共通の字形で揃えられており、MSX以外のPCでは採用実績が見当たらないため、MSXにおける事実上の規格化された文字群である可能性が高いことが分かっています。

 漢字ROMの調査結果については、以下のブログ記事をご参照ください。 gigamix.hatenablog.com

 この「MSX共通の非漢字部分」はUnicodeで代用できない文字も含まれていることから、いま新規でMSX用漢字フォントデータを作成する際に他のライセンスフリーフォントから移植して再現することができません。そこで、この文字群のライセンスフリーフォントを整備することとしました。

16px角のライセンスフリーフォント

 A to Cさん作のライセンスフリーフォントデータ「漢字ROM image file for msx emulaters」に、MSX共通の非漢字部分データが含まれています。

 このデータで採用されたフリーフォント「jiskan16」の全角文字部分はパブリックドメインです。半角文字と全角非漢字部分のフォントはA to Cさんの手描きで、2021年5月26日、Apache License 2.0の適用となりました。

「漢字ROM image file for msx emulaters」は、A to CさんのWebページでダウンロード可能です。→ http://www.yo.rim.or.jp/~anaka/AtoC/labo/labo32.htm

あの頃は無料のものにライセンスを明示するなんて発想がなかった…。 > jiskan16はパブリックドメインですが手描きの追加部分はライセンスが明示されていません 今更ですが、Apache License 2.0ということにします。@nf_ban — LD A,'akayaman';RRCA (@akayaman) 2021年5月26日

12px角のライセンスフリーフォント

 12pxの全角非漢字部分のフォントは、けっきょく自分で描きました。なんという本末転倒!!

https://p.gigamix.jp/devmsx/cg/kanjirom_non-kanji_freefont_20210622.png

 一旦この内容でFIXとさせていただきます。私のデータもライセンスは Apache Licence 2.0 を適用します。どうぞご利用ください。

MSXの漢字ROM 非漢字領域の各社共通部分フリーフォント(12px, ver.4) ○○グラムと○○メートルの表記を現在の国際ルール(筆記体を用いない)に変更、グラムを「めがねg」へ変更&メートルの筆記体っぽさを少し残したのは、全角文字の「g」「m」と区別するため。 pic.twitter.com/iLdkrhPpYf — Takashi Kobayashi (@nf_ban) 2021年6月20日

フォント解説

 非漢字部分はの文字は番号0(G000)から93(G093)まで、全94文字あります。

https://p.gigamix.jp/devmsx/cg/kanjirom_non-kanji_freefont_20210622_2.png

 この絵の左上を起点(G000)として、右へ走査してゆきます。1文字ごとにカウントを増やしてゆきます。1行20文字で、右端まで走査した場合は1行下がってまた左端から右へ走査してゆきます。

 非漢字部分のシフトJISコードとデザイン割付の対比表は以下の通りです。

シフトJIS 非漢字コード 文字の意味
81AD G000
81AE G001
81AF G002
81B0 G003
81B1 G004
81B2 G005
81B3 G006
81B4 G007
81B5 G008
81B6 G009
81B7 G010
81B8 G011
81B9 G012 g(グラム)
81BA G013 m(メートル)
81BB G014
81BC G015
81BD G016
81BE G017
81BF G018
81C0 G019
81C1 G020
81C2 G021
81C3 G022
81C4 G023
81C5 G024
81C6 G025
81C7 G026
81C8 G027
81C9 G028 空白
81CA G029
81CB G030
81CC G031
81CD G032
81CE G033
81CF G034
81D0 G035
81D1 G036
81D2 G037
81D3 G038
81D4 G039
81D5 G040
81D6 G041
81D7 G042
81D8 G043
81D9 G044
81DA G045
81DB G046
81DC G047
81DD G048
81DE G049
81DF G050
81E0 G051
81E1 G052
81E2 G053
81E3 G054
81E4 G055
81E5 G056
81E6 G057
81E7 G058
81E8 G059
81E9 G060 🗀
81EA G061
81EB G062
81EC G063
81ED G064 縦展開の箱の上半分
81EE G065 縦展開の箱の中間部分
81EF G066 縦展開の箱の下半分
81F0 G067 円の上半分
81F1 G068 円の下半分
81F2 G069 横展開の箱の左半分
81F3 G070 横展開の箱の中間部分
81F4 G071 横展開の箱の右半分
81F5 G072 円の左半分
81F6 G073 円の右半分
81F7 G074 ○にCR1
81F8 G075 ○にCR2
81F9 G076 ○に禁
81FA G077 ○に均
81FB G078 ○に↑
81FC G079 ○に↓
8240 G080 三角付き縦線素片
8241 G081
8242 G082
8243 G083
8244 G084 中黒
8245 G085
8246 G086
82F2 G087 斜線1
82F3 G088 斜線2
82F4 G089 点線縦
82F5 G090 点線横
82F6 G091 点線水玉
83B7 G092
83DD G093 網目

BASIC:phpのexplode関数をMSX-BASICでそれっぽく実現する

 忘備録

 phpでいうexplode関数(旧split関数。区切り文字で文字列を分割して配列変数に代入するやつ)に相当する処理をMSX-BASICで実現するのってけっこう面倒臭いですね…。

BASICプログラムコード

100 'text split sub.
110 '[in] A$:separator, B$:string
120 '[out] SP$():array, TA:array count
130 '[use] TA, TI, TA$
140 TA=0:TI=0:TA$=""
150 FOR TI=1 TO LEN(B$)
160  IF MID$(B$,TI,1)=A$ THEN TA=TA+1
170 NEXT
180 IF 9<TA THEN TA=9:'max array No.
190 ERASE SP$:DIM SP$(TA)
200 TA=0
210 FOR TI=1 TO LEN(B$)
220  TA$=MID$(B$,TI,1)
230  IF A$<>TA$ THEN SP$(TA)=SP$(TA)+TA$ ELSE TA=TA+1:IF 9<TA THEN TI=LEN(B$)
240 NEXT
250 RETURN

使い方

A$=":":B$="a:bb:ccc:dddd"
GOSUB <サブルーチンの行番号>

入力

  • A$:区切る文字(1文字)
  • B$:区切られる文字列

出力

  • 配列変数 SP$:分割された文字列が順次格納されます(最大要素数:9)
  • TA:要素数が格納されます(最大:9)

MSXの漢字ROMの互換性を調査する

 MSXは各社から発売されていましたが、漢字ROMにはどのくらい互換性があったのか調査します。また、MSX以外の他機種とテキストを交換する際の互換性についても検討しています。

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

分かっていること

 当方で確認できる環境で全ての文字を調査したところ、以下のような結果でした。

  1. MSXの漢字ROMは旧JIS(JIS C 6226、いわゆる78JIS)ベースだが、漢字部分は新JIS(83JIS)による字形の変更が実装されている
  2. シフトJISコード 81ADh~859Eh のうち旧JISでは定義されていなかった部分(主に非漢字部分)に、新JISとは違う独自に実装された文字が含まれる
  3. 独自に実装された非漢字部分は東芝ワープロRupoシリーズと互換性があるものの、MSXにおいては共通の字形で揃えられており、MSX以外のPCでは採用実績が見当たらないため、MSXにおける事実上の規格化された文字群である可能性が高い。
  4. 独自実装と思われる拡張文字には「(CR1)」「(禁)」「(均)」や多種な網点等の文字が含まれており、一部の文字はUnicodeでも代用できない。
  5. なお、MSXの規格において、漢字ROMのどのコードがどの文字を表すかといったJIS規格のような仕様は明確に存在しない。

MSXと他機種とで互換性が失われる、独自実装の拡張文字群

 非漢字の赤と緑の文字について解説。この2色に含まれる文字は、MSX以外の他機種と互換性が失われます。

  • ■ 赤字:旧JIS(78JIS)では定義が無かった空きエリアだが、新JIS(83JIS)では定義されたために他機種との互換性が無い文字
  • ■ 緑字:旧JIS・新JISともに定義が無かった空きエリアだが、後の90JISで第3水準に定義されたものが含まれるために他機種との互換性が無い文字

https://p.gigamix.jp/devmsx/cg/kanjirom_non-kanji_large.png

 ここで気になるのが、独自実装された文字群が当方で確認できる環境(FS-4600F・FS-A1ST・MSXPLAYer・HALNOTE・MSXView)すべてで(デザインの誤差はあるものの)字形は同じでした。松下・ソニー東芝・三洋・アスキーHAL研究所各社ともども敢えて独自実装部分を揃えているのかもしれません。

 非漢字部分で独自実装されている文字群は大まかに「上部(81ADh~824Eh)」と「下部(8492h~859Fh)」に分かれます(表中の「モヤモヤポイント」を参照のこと)。上部の実装は共通化されている傾向が強い一方、下部の実装は各社で違いが見受けられます。

MSXとそれ以外との互換性を保つには

 以上のことから、表中の緑字と赤字の文字を避ければ他のレトロPCや2021年現在のPCとの互換性をほぼ保てます(エンコードシフトJISが適切です)。

 逆にMSXの実機との完全な互換性を確保するには、ROM側に緑字と赤字の実装(特にモヤモヤポイントの上部文字群の実装)が必須、ということのようです。

そしてパイオニアの漢字ROMにはMSX規格外のフォントが入ってる旨がマニュアルに書かれているなど無法っぷりがすごい。 — MSX研究所長 (@yoshimatsuTUQ) 2021年5月26日

 えっ!?

漢字ROM全文字ビュアー(閲覧プログラム)

 今回の調査で私が使用しました「漢字ROM全文字ビュアー」です。もしこれ以外の字形である機種をお持ちの方がいらっしゃいましたらぜひご確認&ご連絡ください。→ twitter@nf_ban

ブラウザで動きを確認する

webmsx.org

ダウンロード

BASICプログラム解説

  • 16PXVIEW.BAS…MSX標準漢字ROM(16pxフォント)のビュアー
  • 12PXVIEW.BAS…MSXView互換ROM(12pxフォント)のビュアー(参考出品) ※対象フォントROMが必要です
  • AUTOEXEC.DS2…READMEを表示します

 次々と漢字を表示します。BEEP音のあとに何かキーを押すと改ページ、Sキーを押すと画面をBSAVE形式で保存します。JIS第1水準で計13枚の画像、第2水準まで保存すると計16枚の画像となります。

【おことわり】画面上の文字はROMをダンプした結果ではなく、文字出力エンジンであるDMシステム2による結果ですので、ROMの実際の内容と違って表示される可能性がありますので予めご了承ください。

www.gigamix.jp

12pxフォントの調査

 MSXの標準漢字ROMは16pxフォントですが、MSXの低解像度に適したスモールフォントも存在します。

HALNOTE・MSXView

 HALNOTE及びMSXViewに付属されているスモールフォントです。12pxフォントと12×8pxフォントの2種類を利用できます。FS-A1GTに内蔵されています。12pxはJIS第1水準・第2水準を搭載、12×8pxはJIS第1水準のみ搭載。

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

 12px・12×8pxの双方において、赤字・緑字のどちらも、非漢字部分にMSX共通の字形が実装されていますので、実機で作成したテキストに関しては互換性がほぼ保たれています(モヤモヤポイントの下部は互換性がありません)。

 このフォントは各種対応アプリで日本語表示が可能です。詳しくはブログ記事にて

gigamix.hatenablog.com

松下仕様12ドット漢字

 FS-4600F、FS-A1FM、通信モデムFS-CM1、プリンタカートリッジFS-PW1に内蔵されているスモールフォントです。MSX日本語BASICのCALL KANJI1・CALL KANJI3で対応しています。JIS第1水準のみ搭載。

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

 緑字は全く実装がなく、赤字はMSX共通の字形ではなく83JIS相当の字形となっています。

【細かすぎて伝わらない】松下仕様12ドット漢字ROMとは、パナソニックの一部環境(FS-4600F、FS-A1FM、FS-CM1)に搭載されたROM。画面解像度が低いMSXでは16px角の標準漢字ROMより12px角が重宝する場面あり。また、漢字BASICの_kanji1と_kanji3でこのROMが利用される。文字の見え方が全然違うでしょ? pic.twitter.com/8fSJPVDd6U — Takashi Kobayashi (@nf_ban) 2020年7月20日

 つまり、MSX以外の他機種との互換性は高いものの、標準漢字ROMのフォントが用いられる CALL KANJI0・CALL KANJI2 と、松下仕様の12ドット漢字が用いられる CALL KANJI1・CALL KANJI3 とでは同一機種でも字形が変わって表示されるということです。

かんたん手帳リフィルくん

 アスキーのシステム手帳リフィル用印刷アプリに付属されているスモールフォントです。JIS第1水準のみ搭載。

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

 緑字は全く実装がなく、赤字はMSX共通の字形ではなく83JIS相当の字形となっています。全角文字は松下仕様12ドット漢字と全く同じデザインですが、83JISで定義されている849Fh以降の各種罫線文字が含まれていません(注:確認プログラムのバグで表示できていないだけかもしれません)。

要町 as MSX-View(MSXView漢字カートリッジ互換ROM)

 MSXViewの付属漢字ROMカートリッジと互換性のある、フリーフォント「要町フォント」のROMイメージです。JIS第1水準・第2水準の漢字を搭載。

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

 非漢字部分に90JISの文字が含まれており、漢字部分も90JISの改定が含まれますので、字形としては90JIS相当品と考えられます。他機種との互換性は非常に高くなる一方、赤字・緑字のどちらもMSX実機とは互換性がありません。

 「要町 as MSX-View」は、A to CさんのWebページでダウンロード可能です。→ http://www.yo.rim.or.jp/~anaka/AtoC/labo/labo32.htm

k12x8shn(MSXView漢字カートリッジ互換ROM)

 MSXViewの付属漢字ROMカートリッジと互換性のある、フリーフォント「東雲フォント(12px)」「k12x8(12×8px)」が組み合わせられているROMイメージです。JIS第1水準・第2水準の漢字を搭載。

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

 ここでは「東雲フォント(12px)」を取り上げますが、緑字は全く実装がなく、赤字はMSX共通の字形ではなく83JIS相当の字形となっています。なお「k12x8」も83JIS相当の字形となっています。

 「k12x8shn」は、門真なむさんのWebページでダウンロード可能です。→ https://littlelimit.net/viewfont.htm

こぼれ話

漢字ROMの源流はどこなのか

テクハンやデータパックのI/Oマップにもその名残が…。 pic.twitter.com/BGxE2hvNV1 — ごりぽん (@goripon_tw) 2021年5月26日

 MSXの漢字ROMは東芝の意向が強く働いた、という見解があります。松下製品に搭載された漢字ROMのICは東芝製、とのこと。東芝仕様の漢字ROMがそのまま規格化されたようです。

 私が分からないのは、東芝仕様をMSXの規格として取り込む際、JIS規格(JIS X 9051-1984「表示装置用16ドット字形」)のような「コードと文字の意味付け」を含んでいたのか?ということです。例えば旧JISの空きエリアの一つ「81F9hはマル禁マークにしよう」というような。非漢字部分の共通化されているかもしれない独自実装の文字が実は或るメーカーによっては字形が異なるかもしれない、という可能性を未だ捨て切れません。

https://t.co/KyKVHQhcPz このサイトによると、FS-A1Fの漢字ROMはTC531000AP(マスク番号6616)でMSX-Writeと同一らしいです。HX-33/MSX-WriteIIの漢字ROMであるTC531000P/CP/AP(マスク番号0071)からの拡張からなのかがわかれば、MSX独自拡張文字(?)の由来の手がかりにはなるかと思います。 — たけがみりう@Nice boat. (@RyuTakegami) 2021年5月1日
TC531000CP-0071は手元に吸出し済みの状態であるから画像化すれば良いのね?ちょっと気になったことがあるのでちょっと作業してみるけど… — SASANO Takayoshi (@uaa) 2021年5月4日
レイアウトが全然違うので比較が難しくなっていますけど、こっちがJW-R50FIIの16×16部分(こちらも意図的に縮小しています)。/\の部分はMSX仕様になっていないと記憶してるんだけど、実際どうだったっけか…? pic.twitter.com/wDZx4ZYHnx — SASANO Takayoshi (@uaa) 2021年5月4日

 東芝製の漢字ROMはワープロ「Rupo」シリーズで採用されたものと同等のようです。ワープロが先にあり、MSXへ転用された可能性が高い。

今後作成するフリーフォントの互換ROMは、どこに合わせるべきなのか

個人的にはJIS2004/2012字形とかJIS第三水準の非漢字部分とか…イマドキの仕様を含んだMSX向け漢字ROMを作る方が良いんじゃないのって気がする。 — SASANO Takayoshi (@uaa) 2021年5月4日

 私も、今から漢字ROMイメージを作るのであればJIS2004/2012字形とかイマドキの規格でいいんじゃないかと思います。もちろん後述の「実機と互換性のある漢字フォント」も組み込めば完璧とは思うのですが。

 で、問題なのは、MSXView互換の漢字フォントのほうでして。

MSX-View用漢字ROMって第二水準のグリフの並びがバグってたりするんですが、あれを直すべきかどうかって問題ありますよね。ソフト側で漢字ROMのバグを意識しているならバグを残した並びにしないといけないし、そうでなければ正しい並びに直さないといけないし…どうするのかな? — SASANO Takayoshi (@uaa) 2021年5月4日

となると対処としては… ・純正相当でバグ無しROMの仕様(ヘッダ文字列)を定めてそれにプログラム側で対応する ・(さっき書いたように)ROMの側で対処コード有無に関係なく使えるようフォントデータを配置する …のどちらかだけど、すでにメンテされてない対応アプリを考慮すると後者が無難かも? — ごりぽん (@goripon_tw) 2021年4月26日

うーんダメか。結構派手にズレてたorz。両用は無理ですね。 pic.twitter.com/VwLvyhwlU8 — ごりぽん (@goripon_tw) 2021年4月27日

 MSXViewの純正ROMには、一部文字のデータ位置が間違って格納されているバグがあります。FS-A1GT内蔵のROMも該当します。対して「要町 as MSX-View」「k8x12shn」のように新しく開発された互換フォントROMでは第2水準の漢字データが追加されることに加え、このバグが修正されています。

 純正ROMを「旧仕様」、互換ROMを「新仕様」と呼ぶことにすると、ROMが旧仕様の場合は一部文字の表示処理をソフトウェア側で補正する必要があり、Viewフォント対応の各種アプリは既にそのように実装されています。

MSXViewのバグについてはモノは既に出回っているので結局ソフト側の対応が必要で、ソフト側の対応フローも既にあって各アプリが実装済(そして作者はフェードアウト気味でソフト改修が見込めない)なので、ROMの実装でバグ解消するなら要町の字形に準拠した新仕様のROMでリリースするのが得策かと。 — Takashi Kobayashi (@nf_ban) 2021年5月4日

なるほど……。となると、やはり12×8の第二水準を機械的な変換で埋めて、

 新仕様向けの互換ROMについてはイマドキの規格(90JIS以降)で作成して良いと思っています。逆に、実機との互換性を重視する旧仕様向けの互換ROMを新規作成する場合は以下の要件を満たすべきと考えます。

  1. 文字体系は旧JIS(漢字部分は新JIS)に準拠し、上記の表のようにMSX特有の独自文字群を実装する
  2. 一部文字のバグを逆算して実装する

独自実装された文字をUnicodeへ代用する

 Unicodeでは何のコードが適切なのか…未来情報産業さんのブログにオピニオンがあります。

miraicorp.blog.fc2.com

miraicorp.blog.fc2.com

 ただし、Unicodeでは代用できない文字も含まれています。

MSXの実機と互換性のある漢字フォント作り

AtoCさんの漢字ROMイメージがOCMやMSXPLAYerへ実装されたもので間違いないと思います。jiskan16にはMSX固有の非漢字が含まれていないから足りない部分を手描きする必要があった、と。他のFPGAプロダクツの事情はちょっと分かりません。 — Takashi Kobayashi (@nf_ban) 2021年5月5日

 公式のMSXエミュレータであったMSXPLAYerに実装された漢字ROMは、A to Cさん製作の「漢字ROM image file for msx emulaters」であることは間違いないようです。この漢字ROMイメージはJISで規格化されたパプリックドメインのフォント「jiskan16(JIS X 9051-1984」をベースに、規格外の半角文字やMSX独自実装の文字を手描きで実装したようです。

 「漢字ROM image file for msx emulaters」は、A to CさんのWebページでダウンロード可能です。→ http://www.yo.rim.or.jp/~anaka/AtoC/labo/labo32.htm

あと、このROMイメージのライセンスについて、jiskan16は半角部分がソニー製で、無償で使えますがソニーのコピーライト表記が必要だったはずなので、手描きで置き換えることでライセンス表記を回避したんだと思います。が、これ自身(手描きを含んだjiskan16)に対するライセンス明示が無いんですね。 — Takashi Kobayashi (@nf_ban) 2021年5月5日

ライセンス表記さえちゃんとしていればSONYのフォントでも問題ないってことですか…(8x16.bdfの表記 https://t.co/OS3nCmCScg みたいに)。おそらく自由に使っても問題ないのでしょうが、なんとなくですがAtoCさんの追加部分に関してもライセンスをきちんと設定した方が良い気がします。 — SASANO Takayoshi (@uaa) 2021年5月5日

 MSX共通非漢字部分のライセンスフリーフォントについては、以下のブログ記事をご参照ください。

gigamix.hatenablog.com

参考文献:漢字ROMに関する情報サイト

MegaSCSI:MSX用SCSI I/Fの使い方備忘録

 MSXSCSI I/F「MegaSCSI」のノウハウ備忘録。私のSCSI活用方針は、MSXWindowsとのデータ交換を手軽にするために、MSXに接続するSCSIストレージをWindowsにも持ってゆける環境の構築を目指すものです。

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

 ちなみにMegaSCSIを初期化(カーネルインストール・SRAMフォーマット)する方法はこちら。

gigamix.hatenablog.com

SCSIストレージを実機でフォーマットしてパーティーションを切る(SFORM)

  1. SFORM-1ではなく「SFORM-2」を利用する
  2. 似非ASPIは「オン」にしてフォーマットする。

 SFORM-1.COMで初期化するとWindowsでは容量0バイトのパーティーションがマウントされますので、Windowsと併用する場合は SFORM-2.COM を用います。

SFORM-2で似非ASPIオンで初期化し直したら全パーティーションがマウントされるけど、MSXで作ったファイルが見えるようになった。気になるのは、エクスプローラーでは.batファイルが見えない+Amazon DriveをインストールしているとSDカードへ勝手に何かファイルを作ってしまう。 pic.twitter.com/AngNwJKsMn — Takashi Kobayashi (@nf_ban) 2018年3月24日

 2018年当時のこのツイートでは System Volume Information フォルダが勝手に作られるWindowsの仕様に気付いておらず、Amazon Driveの挙動を疑っていました。実際はマウントしたドライブ全てに等しく勝手に作られており、Googleドライブも同様でした。

MSXのSFORM-2でフォーマットしたSDカードをWindowsに差してみたら全てのパーティーションがマウントされたようで割と大惨事。そのうえパーティーション0に書き込んだファイルは、パーティーションまるごと見えない様子。なんだろうこれは…似非ASPIをオフにしたから? pic.twitter.com/HsgXjyeZeU — Takashi Kobayashi (@nf_ban) 2018年3月24日

 MSX-DOS2が認識できるストレージ容量は1ドライブ32MB(ファイルシステム FAT12の最大値)のため、32MB以上のストレージをMegaSCSIのフォーマットツールで初期化すると、32MB毎にパーティーションが分割されます。

 注意点は、分割されたパーティーションはWindowsでは全て別々のドライブにマウントされます。容量230MBのMOドライブの場合、7ドライブ分がマウントされます。パーティーションが沢山ある場合、Windowsのドライブレターの最後(Z:)を使い切る場合もあります。2GBのストレージを32MB単位で区切ると60分割されます。そういうストレージもWindowsではマウントできるのですが、大量のドライブがマウントされる状況はハードウェア側の負担を増やす原因にもなりますし、実用的ではありません。

 2021年現在、私はMSXの実機ではなくWindows PC+クラウドサーバでコンテンツの管理をしているため、本音を言えばMSXの実機側はWindowsとのデータ交換が便利なだけで十分です。私が希望することは、SFORM-2 で32MBのパーティーションを1個や2個だけにして初期化したい(分割数を指定したい)ということなのですが、現状は実現していません。Windowsの管理ツールで複数のパーティーションをつなげて無効化すればドライブ数は減りますが自動化する方法が分からず、手動ではとても面倒な作業です。

 私がSFORMで試行錯誤した顛末はこちら。

https://twitter.com/search?q=SFORM-2%20from%3Anf_ban&src=typd&f=live

仮想ディスクの使い方(EP.COM)

忘備録。MegaSCSIでディスクイメージをドライブにマウントする設定例。マウント先のドライブレターは予め空けて実行。設定後のドライブレターはSCSIデバイスに置き換わるのでマウント解除はESETで空にする。WebMSXでダウンロードしたイメージはMSX実機では形式違い?でマウントできないので注意。 pic.twitter.com/WvX7aLP2SF — Takashi Kobayashi (@nf_ban) 2018年9月28日

 ディスクイメージファイルを仮想的にドライブへマウントできる機能です。「MegaFlashROM」や「Carnivore2」など昨今発売中の多機能カートリッジにおいても「SofaRun」アプリを使うと仮想ディスクの機能が利用できますよね。MegaSCSIではEP.COMを利用します。

 MegaSCSIのEP.COMは、保存したイメージファイルの書き込みセクタが連続している必要があります。よって、ファイルの書き換え(作ったり消したり)が頻繁に起きているドライブではセクタを連続して書き込めないままファイル保存される場合が多いためEP.COMの利用に失敗する場合があります。

 ドライブをフォーマットしたうえでディスクイメージファイルをコピーすれば連続したセクタで書き込めるので、EP.COMの利用が捗るはずです。

ストレージをWindowsでマウントすると以後MSXではボリューム名が勝手に付いたように見える問題

 ストレージドライブにボリューム名を付けておかない状態でWIndowsへもってゆくと、勝手にボリューム名「B」が付けられている問題。

 MSX上で予めボリューム名をつけてからWindowsへ持ってゆく。

ストレージをWindowsでマウントすると「System Volume Information」フォルダが勝手に作られる問題

 Windowsでマウントするたび、Windowsコマンドプロンプトで以下のコマンドを実行する。

d: ←マウントしたドライブ名
rmdir "system volume information" /s /q

 何度も入力するには面倒くさい文字量なので、私は日本語入力の辞書へコマンド1行分を単語登録して、都度実行しています。

将来的にはSCSI経由でクラウドストレージへ繋ぎたい

BOOTHでRaSCSI基板購入して、MSXからMOドライブとして使うことできた。結構嬉しい。はじめ勘違いしてRasPiB+を使っててうまくく動かず。3Bに交換して動いた #RaSCSI #MSX pic.twitter.com/MaXln2yPIw — ハルマッキン (@Harumakkin) 2020年10月28日

MSXでEtherは無理にせよRaSCSI経由でクラウドストレージを直接マウントできれば最高ですね(できるのか調べてませんが)。MegaSCSIなので基本的にFAT12運用なんですよね…(FAT16化に失敗したままウン年経過して未だ実現せず)。Nextor動けばなぁ。 — Takashi Kobayashi (@nf_ban) 2020年10月29日

いちおう、 linuxのクラウドマウントで任意のドライブにマウントできるので あとは rascsi版のドライバがあればナチュラルにアクセスできるはず。(ソースはあるよ) — applesorce (@applesorce) 2020年10月29日

 MegaSCSIとRaSCSIを接続し、RaSCSIと各種クラウドストレージを接続することでMSXのドライブをクラウド化することは可能なようなんですけど、まだ実践したことがありませんが、夢がありますね!

 フロッピーディスクの生産中止によってSDカードへの移行が求められ(ワンチップMSXがまさにそれ)、今度はSDカードも低容量の製品が不足になりつつあるので、直接ネットへ繋がるソリューションが今後求められてゆくのでしょうね。