M5Stackでゆみみみっくす! その2

M5Stackで音を鳴らしたい!

せっかくM5Stackで動くゆみみみっくすデモを作ったのだから、やっぱりサウンドを鳴らしてみたいと思うわけよ!(^-^)

 

でも私はM5Stackで音を鳴らしたことがない。

そういえばM5Stack Core2を手に入れて、初めて起動した時に音が鳴ってたような…。

それ以来、聞いたことがないのでどんな音だったのかも忘れてしまった!(^_^;

 

今回はやった事ないことに挑戦するので、ちょっとだけ手間取りそうだよ!

ちなみにこのブログで書かれている事は、全てM5Stack Core2 で試してる!

M5Stack BASICやFireなどではやり方が違う可能性もあるのでご注意ください!

 

音のデータを用意する

何はともあれ音のデータが必要だ!

サウンドのフォーマットはたくさんあるけれども、M5Stackで鳴らせるのはWAVフォーマットくらいかも? 詳しい説明は省くけれど、WAVは生音のデータで、このまま鳴らす事が出来る。MP3とかAACは複雑な計算をしないと音が再生できない。

 

動画(mp4)ファイルからWAVデータを作り出すのは、ffmpegコマンドを利用すれば良い。

 

それぞれのオプションはちゃんと理解していないけれど、適当にサンプルとして出せればいいから…と思って変換してみた!(^^;

でも……44.1KHzのステレオWAVなんて再生できるんだろうか…滝汗

ダメだったら出力し直してみるとして、まずはこれでテストだ!(^^;;

 

SDカードにあるデータを鳴らす!

まずはサンプルがどこかにあるはずなので、それを探してみる!

多くのサンプルはArduino IDEのファイル→スケッチ例にあるのだけど、サウンドに関するものは見当たらないなぁ…。

 

だいぶいろんなところを探してみて、ようやくそれっぽいプログラムを見つけた!

M5StackでWAVファイルを再生するプログラムのようだ!

これをそのまま利用させてもらおう!(すみません…)

 

ファイル名が /wav/samba.wav になっている部分を /wav/yumimi.wav に変更。

これで試してみたが……淡い期待をしていたけれども、残念ながら鳴らない(^^;;

動作を見てみると、どうも演奏しようとした瞬間に終了してるように見える。

 

やっぱり用意したサウンドファイル(.wav)がダメなんのだろうな…と思い作り直し。

まずは一番チープな音にしてテストしてみることに!

このオプションでモノラル 8KHzのWAVファイルが作られたようだ!

 

このファイルをSDカードにコピーしM5Stackを再起動したところ、無事に鳴った!(^^)

サンプリングレートが高くないので電話でしゃべってるくらいの音になってるけれど、原曲を知っていれば聞き取ることは出来る…くらいだろうか(^^;;;

 

鳴らし方を調べている時に気がついたのだが、どうやらライブラリ的にはmp3やAACなどのフォーマットも鳴らせるようだ。ぜひどこかで試してみたいぞ!(^^)

 

メモリにあるデータを鳴らす!

出来上がったプログラム(SDカードから読み込みながら鳴らす)をそのままゆみみみっくすのデモプログラムに入れると、上手く鳴らない可能性が高い。

 

ゆみみみっくす動画では、絵を表示するために頻繁かつ長い時間SDカードをアクセスする。SDカードへのアクセスは排他的に行われる(だろう)から、おそらく絵のデータを読み込み始めるとサウンドが止まる。

 

絵と違い、サウンドは1フレームでも途切れるとはっきり分かる。人間の目は途中のコマが抜けていても、目(脳みそ?)が勝手に補間してくれるのだが、耳はそうではない。

この手のプログラムで最優先されるのはサウンドなのだ!

 

そしてサンプリングレートを8KHzにしたのもワケがある。

ゆみみみっくすの動画は3分34秒あり、秒数換算で214秒。214x8000バイトx16bitPCMで3424KBとなり、このサイズならばM5Stack Core2のPSRAMに丸々入る計算だ。

PSRAMのアクセスは遅いという印象が(私には)あるけれど、SDカードからの読み込みに比べたら爆速だ!(^-^)/

 

ということは、SDカードから読み込みつつではなく、メモリにあるデータを再生する関数があれば、目的は達成出来ることになる!

いろいろと探したりこねくり回したりしてみて目的を達成出来るプログラムになった!

 

最終的にゆみみみっくすを動かしているプログラムの一部を公開します。

↑これが宣言部分。

↑これがサウンド初期化と、駆動部分。

初期化の関数内で、確保されたヒープにwavファイルを一気に読み込んでいる。

3.4MBのファイルを3秒台の時間で読み切るM5Stack素敵!(^^)

 

Core0AudioはxTaskCreatePinnedToCore関数で登録されてコア0で実行される。

コア1は映像を描画するためにフル稼働!

逆にコア0が余ってたのでちょうど良かった!(^^)

 

なお、実験している最中はAudioFileSourcePROGMEMを利用していたが、あとになってAudioFileSourceSPIRAMBufferという関数があるのを見つけた。

もしかしてコッチの方が良かったりする???(@_@;;

 

映像の時間に合わせる

せっかく音が鳴っても、映像とシンクロしてなかったら残念すぎる!(T-T)

 

画像データは圧縮効率によりファイルサイズが変わり、SDカードから読み込む時間やデータ展開の時間がバラバラになっている。

具体的な数字をあげると、最短で30ms、最長で120msくらい掛かってた。

これだけの違いがあると、工夫無しで音楽と合わせるのは不可能だ。

 

なんとかして音楽と合わせなければならないが、実はそんなに難しくない(^^;

先ほど書いた通り、サウンドは途切れなく鳴らさないとバレるけど、映像は1コマ抜けても気づかれない事が多いのだ!

 

そこで、描画する時間が処理落ちしていた時には、意図的にコマ落ちをさせる処理を入れた。

1990年代のゲームでは良くやっていた手法だ!

 

ゆみみみっくすの映像は1/30秒を基準にデータが用意されていた(Youtubeの制限かも?)。

1秒=1000ミリ秒を30で割ると、1枚の絵に掛けられる時間は33.33ミリ秒だ。

この時間に処理が間に合えば33.33ミリ秒まで待つ、間に合わなければ66.66ミリ秒まで待つ…という処理をいれつつ、1枚の映像をスキップする。

 

これで映像と音楽がずれる事がなくなる!

 

コマ落ちがどどーんと発生した時(多くは複雑な絵の場合)は、少し見た目が目立つけれど、それでも音楽と映像があってる方が良いのは分かるだろう。

 

実際のところ、映像の描画には多くの時間がかかっており、33ミリ秒で描画が終わる事はほぼ無い。せっかく用意された6411枚の画像の、実に半分以上は描画されていない(^^;;

 

これで本当に終わり…?

思いつきで作ってしまったゆみみみっくすデモだったが、ワリと満足度の高いものが出来上がった気がする!やっぱり音楽入ると違うね!(^-^)

 

またしてもツイートしてから気がついたのだが、プログラム的にゆみみみっくすに依存しているところがないんですよね…。

制限があるとすれば、サウンドデータが4MBを超えられない(260秒くらいが限度)くらいかも。CPUコアを1つ専有する事を考えたら、MP3とかACCでの演奏が出来るかも知れないので、もっと長い音楽を再生する事も出来るかも!?

 

ということは、Youtubeの映像とか、mp4ファイルになっている映像であれば M5Stack Core2で再生出来るって事かー……ほほぅ……(-_-;;

 

ではまた次回!(^-^)ノ

 

M5Stackでゆみみみっくす!

みんな大好きM5Stackで、みんな大好き?ゆみみみっくすのオープニングムービーを動かしたお話!

 

このところ、レトロPC上でゆみみみっくすのオープニングムービーを動かしているツイートを連続して何件か見た!懐かしいなぁすごいなぁ…と思ってしまったら……自分でもやってみたくなるw

 

そういえば、過去にBad Apple!!を動かした際、グレースケール版も作ってみようと思って頓挫してた事を思い出した。ビット深度が深いという意味ではグレースケールもカラーも同じようなもんよ…という理不尽すぎる解釈から、いっちょやってみるか!となった(^^)

 

日曜(サンデー)プログラムの感覚でいるから、1日または長くても2日で作りたい!

 

そういえばゆみみみっくすは、メガドラCD版をゲームの最後まで終わらせているはずだけど、ストーリーを全く覚えてない…うむむ??

ゲームそっちのけでCinepakの解析をしてたからかな……

 

とりあえず机上で検討

そもそもムービーをどこから持ってきたら良いのか…というところで、まずはつまづく。

メガCD版のソフトは持っているけれど、動かせる実機がない。

実機があったとしても撮影する機材もない。

 

今回はYoutubeにあった動画を利用させてもらうことにした(ごめん)。

[MD]ゆみみみっくすオープニング - YouTube

 

動画自体が3分34秒あるので、214秒=6420フレームくらいのデータ量になる事が見込まれる。これをどう管理するか…。

データはどう圧縮するのか…。

 

メガドライブの色は512色中64色が表示可能らしい。…ということは64色で表現しても遜色ないという事か。

 

SDカードからの読み込み速度も気になるところ。過去の実験で1024KB/秒ほどの読み込み能力があるのは分かっているけれど、あの時の高性能SDカードはいずこへ…orz

 

うん、検討してみた結果、作ってみないとわからないとなった!(^^;;

↑無計画すぎる

 

まずは動かしてみる!

仕組み的には、1つの動画ファイルをそのまま再生するのではなく、1枚1枚の絵を高速に表示させる事でアニメーションっぽく見せる。

 

動画ファイルをjpegに分割するのは、ffmpegコマンドを使えば簡単に出来る。

  ffmpeg -i yumimi.mp4 -vf scale=320:-1 data/%04d.jpg

 

そして出来上がった、おびただしい数のjpegファイル…その数6411枚!

このファイルをどうにか加工してM5Stackへ入れなくてはならない…。

 

まずはjpegファイルを320x240x24bitのRAWデータに変換して加工しやすいようにする。

jpegファイルは、libjpegというライブラリを利用すればワリと簡単に扱う事が出来る(^-^)

 

このRAWデータのままだとサイズが225KBもあり、そのままM5Stackに置いとく事も難しい。減色および圧縮の方法を考える。

 

方法としてはこうだろう。

まずは64色まで減色してみる。

その上で出来上がったデータを圧縮する流れだ。

元絵が64色で描かれているのならば、遜色のない絵ができあがるはずだ。

 

減色

私の時代(?)にはカラーリダクションとか言ったけど、今はなんて言うんだろ??

そういえば減色ツールなんてエラい昔に仕事で開発したっきりやってなかったっけ…。アルゴリズム含めてすっかり忘れてる(^^;;;

 

当時のプログラムを見てみるとmediancutなる名前が関数名につけられていた。うーん、苦労した覚えはあるけれども、ソースみてもアルゴリズムが思い出せんw

まぁ動けばいいっしょ!←をぃ

 

↓こちらが元絵

↓こっちが減色後の絵

ちょっと気になるところはあるけれども、M5Stackの小さな画面で見たらきっと気にならなくなる……はずだ!(^^;;

 

ちなみに減色後のデータを見るツールも即席で作った!

タイトルがFont Viewerのままになってる辺りで急ぎ加減が分かるw

ツールも含めて土日で作り終わらなければ日曜プログラムとは言えないのだ!!

 

データ圧縮

データ圧縮については少し困ってしまった(T-T)

Bad Apple!!の時は基本的に白黒しかなかったので、圧縮アルゴリズムはランレングス一択だったのだが、今回は色情報を持っている事からデータが複雑だ!

↑こんな感じの絵は、横方向へのランレングス圧縮が効きにくい。

 

仕方ないのでいくつかのアルゴリズムを組み合わせた圧縮ツールを作る事にした!要は一番効率の良いアルゴリズムをその場その場で採用するような感じの手法。かつ展開速度を担保するために、ビット単位ではなくバイト単位での圧縮とした。

 

圧縮後のデータサイズを小さくするため、データのMAXを64KBという制限にした。そのため、320x240のデータを上下分割して、320x120のデータ2つとして扱う。

M5Stackで画面描画を行う際、320x240を一気に描けない制限ともマッチするので、これで良いか、となった。

 

元絵のデータが320x240(75KB)+パレットデータ64色(128バイト)で76,928バイト。

圧縮後のデータは最低で746バイト、最大で35,772バイトとなった。

 

そしてすべてのデータを1つのファイルにまとめた事により、127,007,871バイト(121MB)という巨大なアニメデータが完成した!元のmp4が10MB無いのに!(T-T)

1つ前の絵との差分を取れば小さくなるのは分かってたけど、今回はスルー(^^;;

 

そして出来上がったのがコレ。

コア0で圧縮データの展開、コア1でSDカードからの読み込みと描画を担当。

コア0の方がちょっとだけヒマな感じ。

描画にはLovyanGFXを活用させて頂いてます!

 

圧縮データと圧縮を展開したデータは、大きさ的な関係で内部RAMに置けなかったので、(速度の遅い)PSRAMに置いた。

画面の端にノイズが乗る事が多くてチカチカしてしまうので、画面の上下をデータ上で黒に塗りつぶした。

 

SDカードは高性能なタイプが手元になく、ノーブランドのモノを使用。おそらくブランドのものよりも2割くらい読み込み速度が遅いと思われる…。

 

ツイートして完了!と思ったけど、なんだかモヤモヤしたものが…。

もっとキレイに作れるのではないか……と思ってしまったのだよ…。

 

作り直してみる!

プログラマたるもの、気になる事が残っていたら直さないわけにはいかないだろう!

たとえ日曜プログラムであっても避けられない習慣なのである!!

 

 表示領域を280x224にしてるけど、実はこれだと64KBに収まる

 コアを2つ使うためにダブルバッファリング化してけど必要?

 減色プログラムを改良したい

 表示までに掛かる手間を減らしたい

 

↑で「画面端にノイズが出たので消した」と書いたが、実はデータ上では単に黒い領域として残ったままになっていた。

 

表示サイズを計算してみたところ、280x224 = 62,720バイトとなり、パレットのデータを含んでも64KB(=65,536バイト)に収まるじゃん!となった。

これをやると……データ生成ツールまですべて作り直しになるんだけど…orz

 

……うーん…でもやるか!

フォルダも新しく作り直してyumimi2とした!(改造ではなくて新作成!)

 

この際なので……ノイズが微妙に乗って気になってた減色ツールも改良した!

25年以上前に書いてたツールという事もあり、当時のコンピュータで現実的な速度で動かすために精度を犠牲にしていたところが多々あったのだ。

精度を上げるようにコーディングし直したところ、ノイズが出にくくなった!

 

そしてツール類を一新した。

前のバージョンでは、減色、圧縮を別のツールにしてて手順も面倒だったが、新しくしたツールでは減色と圧縮を同時に行うようにした。このおかげで6411ファイルの更新に30分くらい掛かっていた作業時間が、19分まで短縮された!

土日しか時間がないから、何度もテストが出来ないのだ(T-T)

 

コアを1つで実行するようにした。

このおかげでバッファを複数持たなくて済むようになったため、すべてのバッファを内部RAMに入れる事ができるようになった!

複雑なシーケンス制御が無くなった事もあり、68msくらい掛かっていた表示が、35msくらいまで速くなった!(^-^)

 

そして出来上がったのがこちら↑

ツイートしてみたが、見る側にとってはほとんど何も変わってないという…orz

いいのだ、これぞ日曜プログラムの醍醐味だ!←多分違

 

おわりに

データの用意から減色、圧縮、実機へ持ってきての表示という作業を、はからずしも2度やってしまったワケだけど、意外に出来ちゃうもんだなーと思った!(^^)

しかも土日の用事もしっかり済ませた上で作業してるので、実質はもっと短い。

このくらいの作業量が老体にはしっくりくるかも!(^^;

 

あと気になってるのは音楽ですねー……。

M5Stackでどうやったら鳴るんだろ??意識した事すら無かったよ。

 

ではまた次回!(^-^)ノ

 

16進ダンプ入力ツールを作った!

16進ダンプリスト、入力してますか?(^-^)

 

私は気圧の変化による頭痛がひどい時や、仕事で必要となった時に入力してる(^^;

何も考えない状態(無心)で打ち込みたい時や、逆に集中したい時とかにも入力したくなるw

今回、気圧の低い日が頻繁にあって集中出来ない期間があったため、ちょこちょこダンプリストを入力しては気を紛らわせていた。

 

そんな時、もっと効率の良い入力環境を作りたいなぁ……なんて思ってしまった!(^-^)

思ってしまったならば作るしかないだろう!w

 

今までのダンプ入力事情

今までも手入力でダンプリストを打ち込む環境を手元に用意してあった。

↑こんな感じのテキストを用意しておいて、コンバートするだけの簡単な環境。

 

バイナリに変換するツールはPythonで書いてあり、バイナリ化とチェックサムを計算するだけのごくごく簡単なもの。

 

このPythonツール自体は2017年11月頃作ったもので、当時開発をしていたFM-7エミュレータでテスト用のプログラムを準備するために用意した。

この当時、手元にバイナリデータを打ち込む環境が無くて、当時のプログラムを入力するのはどうしたらいいんだ??となったのがきっかけだ。

FM-8活用研究に掲載されていたギャラクシアンを打ち込んだのが最初だった!(^^)

 

テキストデータで打ち込むようにしたのは、単純に整形する際の利便性のよさと、OCRした後のテキストを簡単に扱えるようにしたかったためだ。

 

そしてギャラクシアンOCRを利用してデータを作成していた。

タブレットで写真を撮る

OCRでテキスト化

・テキストをダンプ形式に整形

・誤字を修正

チェックサム確認→修正を繰り返す

・256バイト終了

 

……入力する手間は無かったけれど、全体的な時間はかえって掛かったイメージ。

16進数ダンプ専用のOCRとかあったら認識率上がりそうだけど、(当時の感じでは)使いにくいかもなーって印象だった。

 

試しにダンプリストを手入力してみる事にした!(^-^)

テンキーをA〜Fに変換するプログラムもないけれど(そもそもうちのMacにはテンキーがない…)、フルキーで打ち込んだらどのくらいの速度になるんだろうか??

当時、256バイトを打ち込むのに約10分掛かった記憶がある。1ブロック10分、1時間で6ブロック打ち込める!みたいな感じで気合を入れていた記憶が蘇る(^^;;

 

そしたら…今フルキーでタッチタイピングすれば、256バイトを2〜3分で入力出来た!

考えてみればテンキーをA〜Fに割り当てて打ち込んだとしても、効率の良い片手打ちだ。

タッチタイピングすれば両手で高速に打ち込むことが出来る。

そりゃそうか!(^-^)

コレ以降、OCRに頼らずに手入力をするようになった!

 

↑昔は書籍を広げてカセットテープのレーベルをあてがう感じで入力をしていたが、今の時代にこれをやると広げ続ける本が傷んでしまう(T-T)

 

↑そこでダンプリストを写真に撮るようにした。

これで本の痛みは最小限に済む!

さらにガイドとなるものはダンボールを切り貼りして手作りした!

しっかりと固定して置けるので両手が空き、タッチタイプが可能となった!(^-^)

 

便利な入力ツールが欲しい

「自分が使う」を大前提として、使いやすいツールが欲しい!

ダンプリストを入力するたびに、そんな事を思うようになった。

 

不満のひとつに、アドレスを自動発生させる機能がない事があった。

ダンプを入力するたびにアドレスを手で書いてたのだ。

これは効率が悪い上に間違いが起こる。

さらにADRSSumなどの雛形を自分でコピーしたテキストを作らねばならず、ダンプを打ち込む際の面倒事項となっていた。

 

今の感じだとOCRを試すこともしばらくは無いだろう。

そうなると手入力を大前提に使いやすいツールが欲しい!(^-^)

 

昔、Oh!FMだったと思うけど、FM-7で動くとても使いやすい入力ツールがあった。

フルスクリーンでダンプ入力が可能であり、しかも入力していくとチェックサムがリアルタイムに表示される!

そんな感じのツールが手元にあると良い!(^-^)

 

なんとなく想像で以下のような仕様を考えてみた!

 256バイトのブロックを表示

 チェックサムはリアルタイムに更新される

 カーソル移動はEmacs準拠

 入力部分が拡大表示される

 セーブされるファイルは常に64KBのRawファイル

 

テキストベースで画面構成も考えてみる。

 

ふむ、こんな感じで入力できるのならば画面は80x25固定でも良さそう。

1980年代風の入力ツールでいいじゃん!(^-^)

拡大表示するためにはフォントを変えるかドットで打つか…。

せっかくなのでSDL対応してグラフィックで描いちゃう!

よし、そうなったらフォントはPC-9801だよなー!

……って感じでだんだんとワル乗りしてきたww

 

最初に作ったのがコレ。画面構成はほぼそのまま作っている。

拡大表示はカーソルを中心として前後を見えるようにしてみた。

この状態で16進数を打ち込むと、チェックサムがリアルタイムに更新される!

 

その後、アスキー文字領域にもカーソルを表示してみたり……

入力対象となっているラインにアンダーラインを引いてみたり…

 

背景を淡い青にしてみたり…と改良を重ねてみた!

 

SDL対応なのでMacだけでなくWindowsLinuxでも動くはずだ。

ポメラDM250に入れておけば、旅先でダンプリストを入力しちゃう事だって可能!

電子辞書Brainに入れておけば、授業中のヒマな時間にダンプ入力出来る!

おお、意外に使えそう!(使う人は限られるが…)

 

使い方のクセが強すぎるため(だってカーソル移動がEmacs準拠よ?)配布する予定はないけれども、使ってみたーい!という話が多数上がるようであれば公開も考えていきたい。

何度も書くけど、高機能ではない(^^;;

セーブ(CTRL-X + CTRL-S)されたファイルは64KBのRawデータなので、独自でデータ加工のプログラムが書けない人にはお手上げツールなのだ(^-^;;

 

おわりに

昔から自分の環境は自分で作りたい派の人だったけれど、まさかこの時代にダンプ入力ツールを作るとは思ってなかったw

でもいいね、自分環境!

もっともっと整えていきたいと感じた!(^-^)

 

ではまた次回!(^-^)ノ

JR-300エミュレータの続編その1

ほそぼそとJR-300エミュレータの開発を続けている!

ここんところ実務でバタバタしてるので、1日で取り組める時間が1時間も無い(T-T)

でもちょっとずつでも続けていられればいいかな!

飽きっぽい性格なので、どこでやめちゃうかドキドキしてる(T-T)

せめてエミュレータのバイナリ公開まで行けるといいなぁ…。

 

でもJR会が予定された事からエミュレータを作る気になり、それをツイートした流れからJR-300をお持ちの方まで現れた!

JR-300本体の写真も載せてくださったのは本当に感謝でしかない!

写真や資料はどれも果てしなく参考になる!!

想像していたJR-200とJR-300の切り替えはディップスイッチで行うみたいだ。

 

RS-232Cがついているのは分かったけれど、BASICインタプリタの中にはシリアルっぽいファイルディスクリプトが存在しない(存在するのはCAS0:のみ)。

ということはプログラムのロードとかが出来ない???

うーん、謎ましい感じだ!(^-^)

 

JR-300の情報については本当に欲しい!

動く実機があれば開発してるエミュレータの答え合わせも出来るのだけど…うぬぬ。

 

デモンストレーション

JR-300のデモンストレーションの気になるところを修正した。

もちろん修正したのはデモプログラムではなく、エミュレータ側だ(^^;

 

円グラフの色がおかしい。

多分、グラフの中に色が塗られるのが正しいんだと思うけれど、なぜか塗られない。

 

その前に……実は円の描画が正しく実装されていないのだ(^^;

Xデー(JR会)に間に合わせるため、エミュレータの実装をズルしてる部分があった!

まぁこの手のズルっこはどこかでダメになるものだ(^^;;;

 

計算式を見直したところ、最後の1ドットが描画されていなかった!(T^T)

急いでると些細な事でバグが出る…orz

おっしゃ!ちゃんと直った!(^-^)

 

ちなみに棒グラフの一番下、赤い帯しか見えてないんだけど、ここは赤の背景、赤の文字で「ソノタ」とかかれているらしい。アトリビュートと文字の色解釈が間違っているのかと思ったが、どうもそうではなさそう…。

この謎はもう少し引きずりそうだ!

 

画面に飛行機が横切ると、テキストで青が残ってしまう問題。

 

これはスペース(' ')[$20]が背景色青で設定されている。

この場所以外でもスペースを別アトリビュートで置いてたりする。

わざわざ色を設定して置いてることから、なにか意味がありそうなんだけど…。

でもスペースが置かれてるし…。

デモの開発途中で仕様変更になった名残なのかも…??

 

仕方ないのでスペースは何色の背景で描画されようとも透過するようにしてみた。

してみた…というのがアレですが、正解がわからないので仕方がない(T-T)

 

飛行機の後方にカーソルが表示されちゃってるけど、これは気にしないで(^^;;

デバッグで動かしてるとカーソルが消えないのだw

 

一通り動いてるデモをツイートしてみたので、ぜひ見てみてほしい(^-^)

 

速度について

上のツイートに速度について書いているが、ここで詳しく説明をしたい。

Z80CPUのエミュレーションは大雑把ではあるが4MHzくらいに調整した。

 

サブCPU(おそらく6802)はフルスピード、つまりZ80側から見るとノーウェイトで動いてる。

Z80の1命令でどんな処理も終わってしまっているのだ(^^;;

デモの中にあったスプレッドシートの画面が瞬時に表示されてるのは、このせいだ。

この先、きちんとサブCPU側の処理遅延を入れていけば、上から下にだららーっと表示されていくのが見えるほど遅い…と思う!

 

さらにGDCもすべてノーウェイト動作だ。

LINEはコマンド発行後はGDC側で全処理が行われるので、Z80側から見たらノーウェイトで線が引かれている。

PAINTが遅く見えるのは、処理の途中でZ80側の処理が挟み込まれるから。Z80がちゃんと遅いのでPAINT自体も遅くなる…という事だw

 

この先、エミュレータをちゃんと作り込んでいくと、全体的にどんどん遅くなる(^^;;

デバッグ中はもちろんフルスピードだよ!(^o^)/

 

この先はBASICでのPCG定義(おそらくDEF CHR?)など、まだ解析できてない部分がたくさんあるので、その辺りを確認していこうと考えている!

のんびり行くよー!(^^)

 

ではまた次回!(^-^)ノ

JR-300エミュレータの開発その7

このシリーズ完結編!(^-^)

この先にも開発は続くので、その時は続編みたいな感じに続けるよ!

 

JR-300 ナショナル」のキーワードで検索をするといくつかの写真が見つかる。

本体とキーボードが分離したセパレートタイプの筐体で、初代PC-8801やX1っぽい感じを受ける。

BASICがカセットテープで供給されるのに、本体にカセットデッキがついてないように見えるんだが…しかもデータレコーダーは別売りだった??

年代によってカタログに記載されたスペックも違うようで、だいぶ紆余曲折感が漂う。

 

時代の狭間にあったマシンなのかもな…と思ってみたり(^^)

でも愛すべきマシンですよ、JR-300!

 

2022/11/29(火)

昨日までの解析で、今まで謎に包まれていたグラフィックコントローラは、PC-9801などで使われていたμPD7220らしい事が判明した。

 

GDCは直線補完、円、拡大したグラフィック文字、傾斜文字、VRAMからの読み出し/書き出しなどの機能がある。

対応の仕方が分からなかったSYMBOL命令とか、もしかしたらGDCの機能を利用しているのかも??

 

コントローラの素性が分かると、今まで謎だった仕様が明らかになる。

そうなると……ソースコードをキレイに直したくなるよね??(^^;;

 

今までは100%が想像であったし、MSB-LSB反転の解釈だったので間違いも多い。

全体を反転させた状態、つまり素のGDCとして定義し直したい気持ちが強い。

 

というわけで!

グラフィック表示系を全部作り直すよ!!!(^o^)

 

気合が入ったところではあるけれど、

これから実務が忙しくなるので毎日作業ができなくなる。

なんとか2023年のお披露目会(1/14[土])には間に合わせたいのだが…。

 

2022/11/30(水)
この先はグラフィックコントローラ改めGDCと書くことにする。

まずは今あるグラフィックコントローラ系のプログラムを一旦外す。
この状態でもBASICは起動するはずだ。

 

その上で、GDC μPD7220 としてコードを再編するようにした。


機能はほぼすべてわかっているので、今度は作るための資料がたくさんある!
むしろ機能がわかりすぎて、これ、全部対応するの?ってなってる汗

リファクタリング…というか作り直しはちょっと大変だぞこれは。

 

でも困ったことに実務の締切がキツくて、JR-300の作業が当面出来ない…

ぐぬぬ

 

2022/12/06(火)
GDCのコマンドを見直す作業を継続する。

手元にあるGDCテクニカルブックを読み直しているけど、これを参考にしてGDC制御のプログラムを作ったことが一度も無かった!

GDCのコマンドってパラメータの数が微妙に可変長だったりして判定が難しい。

 

さらに、JR-300のBASICでCLS(画面クリア)で発行されるコマンドが、資料に書かれているコマンド発行と違ってるのが理解できぬ…。


うーむ…

勝手に解析してたときは気軽に解釈してたけど、資料が揃うととたんに難しくなるのはコレ如何に(T-T)

 

2023/01/13(金)

だー!1ヶ月以上も手がつけられなかった!

しかも締め切り明日だし!!(T-T)

せめて以前まで動いてたデモくらいは動かした状態でお披露目したい!

 

BASICインタプリタで発行されるGDC初期化部分は対応が終わったけど、それ以外の描画については手つかず状態だった。

……1日で対応できる量なのかな…(^^;;;

 

でも実装するべきものが決まっていると作業効率も良い!

一度書いたことがある処理なので中身で悩むところはなく、PSET、LINE(ラインスタイル含む)、VRAMからの読み出しを一気に実装した!

円(CIRCLE)だけは未実装案件だったけど、書籍に数学書いてあったから思ったよりも簡単に実装できた。良かった(^^;

 

今のところはBASICとデモンストレーションの対応が出来れば良いだけ。

いわゆるお行儀のよいプログラムの対応をしただけの状態。

 

この手の実装で難しいのは「ユーザーが限界ギリギリの速度を出そうとして、マニュアルに書かれていない方法(でも動いちゃう)を使う」のに対応する事であって、規定に基づいた使い方を実装するのは、そこまで難しくないのだ(^^)

 

書かれている通りに実装をしたらちゃんと思ったように絵が描かれた!

当たり前の事なんだろうけれども、それがなんだか嬉しかったよ!(^^;;

 

GDCの実装が終わった後の映像。

おそらくJR-300の文字はこれでよいのだと思う。

無限マークは左半分がテキスト(表示はPCG、つまりGDCとは無関係)なので、そっちの解釈が間違ってるんだろうと思われる。

どう表示されるのが正しいのかが分からないなコレは…orz

 

GDCの実装をちゃんとしたら、それまで見えてなかった漢字が表示されるようになった!表示されてなかった原因が、色の解釈の問題だったのか、それとも別の機能だったのかは調べてない(^^;

まだ文字の拡大表示をサポートしていないので、その機能でないことは確か。

本体に漢字ROMは入ってなくて、デモプログラムに内包されてる。

 

全体的に色があってるのか少し不安w

木になってるリンゴが円で描かれてた!

LINE機能のラインスタイルを対応したら、中間色PAINTのような表示になった。

なるほど、いろんな機能をちゃんと使ってるね!(^^)

右から飛んでくる飛行機はPCGで描かれていて、雲?みたいな跡が残ると思うけれど表示が化ける。これも正しい解釈が分かってない…。

 

これが謎だったデモンストレーション!
GDCのCIRCLE機能に対応したら描画されるようになった。

BASICのCIRCLE命令はZ80側でドットを計算してPSETしてるのに対し、デモンストレーションの中ではGDCの機能を使ってた。

多分、BASICの描画よりもだいぶ速かったと思う。

同時にカラーパレット機能も使われてました!

 

この画面はテキスト表示だけだったのでサブCPUのお仕事(^^)

ここだけで横80キャラクタ(WIDTH 80)が使われてます。

 

最後の画面。

多分、円の中がちゃんとPAINTされていないのと、棒グラフの一番下の赤が「その他」とか書かれていそうな予感。これも表示系がちゃんと出来てない。

 

……という感じで、まだまだ完成には程遠い感じ!

デモンストレーションの表示を完璧にした状態で、あとは用途不明のBASICを解析していく流れかなーと考えてる。

 

 

BASICとデモテープだけを頼りにエミュレータを書く

こんな体験ができるとは思ってなかったなかったけど、これも巡り合わせなのかな…!

良い経験をさせてもらえました!(^-^)

一度手を付けてしまったマシンなので、最後まで頑張りたい(^-^)

 

JR-300エミュレータの開発編、これにて終了!(^o^)

ありがとうございました!!

 

ではまた次回!(^-^)ノ

JR-300エミュレータの開発その6

JR-300エミュレータの開発話、第6弾!(^-^)

 

かなり動いてきた感はあるけれども、今の動きがどのくらい正しいのか私には分かってない。分からないどころか、誰もJR-300を知らないので答えがない(^^;;

 

実は妄想のマシンを作り上げてるだけなのかもしれないな……

そんな不安を感じつつも、JR-300と書かれたカセットテープを信じて作っていくよ!(^^;

 

2022/11/26(土)

テキストに描画するフォントを、ノーマルフォントを使うのかPCGフォントを使うのかの切り替えは、どうやらアトリビュートのbit6(0x40)らしい事が判明。

bit6が1の場合はノーマルフォントを、0の場合はPCGフォントを使うらしい。


8ビット情報のうち、これで7ビットの役割が判明。(xP_BBB_FFF)

残りのMSB(x)は何に使われているのか…汗

 

PCGを表示出来るようにプログラムを変更してみたところ、画面上から変なゴミみたいな表示は消えた。でも…画面には文字しか表示されていない。

まさかこういうデモ??(@_@;
いや違うだろうな…うーん…

 

動作時のログを追ってみると、大量のLINE描画が発行されている。
LINE命令のPSETするかPRESETするか判定がBASICの時と違っているようで、なぜかLINEが描画しない。
あれれおかしいな…BASICでさんざんテストしていたのに(T-T)

VRAMにはデータがでてるんだろうか?

うん、VRAMを無理やり描画(というよりもアスキーアート的な感じで出力)してみると、確かにデータは出力されてるっぽい。

 

仕方ないので、オールセット(理論上は真っ白な線が表示される)でテストしてみたところ…

うお!絵が出た!!

出たけど…出たけど……なんか変?!

 

画面の解像度が640x200ドットになっていそう…

あとグラフィックよりもテキストが奥に表示されてる。

 

これはBASICインタプリタの初期化に合わせたつもりだったけど、解釈が逆だったか。

デモンストレーションの結果を見て修正する必要がありそう。

あと…なぜか色が出てる。

ドットが真っ白になる事を覚悟して変更をしたつもりだったのに…。

うーん、1つ1つの動作が謎いぞ。

 

横のドットを修正して表示されたJR-300ロゴ!
気になるところが多いなー。
まず…背景が青一色であってるんだろうか??
それに画面下の無限マークのテキスト。これも意図と違う気がする。
カーソルが表示されちゃってるのは、これはまだ未解析のサブCPU側のコマンドがあるからだろう。

 

デモを1周回す
おかしな画面は置いとくとして、まずは先にデモを1周回しちゃおうと思い、未定義なグラフィックコントローラな部分などをすっとばしていったところ、なんとか回ることに。

 

デモは全部で5種類入っていた。

・タイトル(JR-300表示)
ワープロ(漢字表示は??)
・絵(ペイントで塗りつぶされちゃう:最後に飛行機?が飛ぶ)
スプレッドシート
・棒グラフ?(白で塗りつぶされちゃう)

 

絵が表示されるデモを見たとき、PAINTがハデにあふれて画面が1色になってしまう現象が出ていた。LINEの終端が届いてないのかと思ったけれど、デバッグログに不穏なものが…。

…なにかの……補間機能っぽいものを使おうとしているデータがでていた。

しかもタイプ違いの8種類。

コレは嫌な予感がする…(-_-;

 

これ…もしかしたら円を描こうとしてるんじゃんないだろうか??

BASICではドットを計算してPSETしていたCIRCLEだけど、デモでは違う?

私自身、グラフィックコントローラで円を描かせた経験がないので、パラメータが想像できぬ。

うぬぬ…これは困ったぞ(T-T)

気になる問題はあるけれど、後回しにできるものは後で解決する!

 

まずはこれらのデモを個別に1つずつ見られるようにする手法を確立しとかないと、この先のデバッグがとても大変になりそうだ!

プログラムで個別ジャンプ、またはジャンプテーブルが見つからないかな…。

…と思っていたら、あっさり見つかった!

 

0x010Dから並んでいるCALL nnnnがデモ呼び出しだった!

これを修正すれば、選んだデモだけをテストする事ができそうだ!(^-^)

そして目視で確認した時には5つのデモだと思っていたが、どうやら見えてないデモがあるらしく全部で6種類存在するっぽい。

 

・タイトル(JR-300表示)
ワープロ(漢字表示は??)
・絵(ペイントで塗りつぶされちゃう:最後に飛行機?が飛ぶ)

・未知のなにか

スプレッドシート
・棒グラフ(白で塗りつぶされちゃう)

 

2022/11/27(日)

謎の8回出ていた補間機能っぽいものが気になる。

もしも円の描画だとすると、なんとなくPC-9801で使用されていたGDCに似た機能を持ってるコントローラなんだな…。当時、そんな何種類もグラフィックコントローラって出てたんだっけ??
そう思いつつGDCの資料を見直したところ、同じものではないけれども、構造的には良く似てるとわかった。


コマンドそのものに共通点はないものの、コマンド系体的に良く似てるというか。
参考になるところがたくさんあることがわかった。

 

あああ……GDCの資料を見て思い出したことが!

  LINE(0,0)-(319,199),7,,&HABCD ← 最後がラインスタイル

GDCと同じような機能があるのなら、ラインスタイル指定ができそうなんだけどなぁ…と思って調べていたら、しっかりデータが出てました…。


N88-BASICやF-BASIC4.0以降にあるラインスタイルと同じ指定方法だった。
うーん、一度試してみてErrorになった気がしてたんだけどな…。

 

対応するべき事がどんどん増えていく…。

・LINEのラインスタイル対応
・謎の8回補完機能解析
・グラフィックコントローラの実行サイクル試案

 

2022/11/28(月)
LINE命令のラインスタイルに対応させるため、一度初心に戻って詳しく調べる事にした。

 

そういえば、今までアドレスデータがビット反転されていたのをいちいち手で元に戻してチェックしていたが、デバッグログに出力するときにひっくり返したら簡単じゃん…と今更ながら思った。

 

それで一度、アドレスデータだけじゃなくて、すべてのデータをひっくり返して出力した。

出力されたデータを見たとき……ある衝撃が…。

つい先日、GDCの本を見た時のコードが思い出される…。

μPD7220でLINEを描画するのは

  [78] TEXTW
  [33] WRITE
  [49] CSRW
  [4C] VECTW
  [6C] VECTE

の順番でコマンドを発行するらしい。

 

そんな目線でBASICのLINE命令で発行されているコマンドを追いかけてみると……

01 1E [78] - [TEXTW] 
00 AB [D5]
00 CD [B3]

01 CC [33] - [WRITE] 

01 92 [49] - [CSRW] 
00 84 [21] 
00 C0 [03]
00 04 [20]

01 52 [4A] - [MASK]
00 20 [04]
00 20 [04]

01 32 [4C] - [VECTW]
00 90 [09]
00 28 [14]
00 00 [00]
00 28 [14]
00 00 [00]
00 00 [00]
00 00 [00]
00 14 [28]
00 00 [00]
01 36 [6C] - [VECTE]

……え?

……ええ?

………えええ!!??

マジで?(@_@;

 

ちょっと待って!!

GDCと同じデータが出力されている!

 

今まで、アドレスデータはプログラムでビット反転されていたので「このデータは反転している」と認識できたけれど、コマンドデータはそのまま出力されていたので意識していなかった。

けど、よくよく考えれば同じデータポートに出力されているんだから、同じようにビットが反転したデータが送られていると考えるべきだったのか!

 

μPD7220は3画面同時書き込みが出来ないので、3回同じデータが出るのもうなづける。

あとPC-9801のようにメインメモリにはVRAMがマッピングされていないと思えば、沢山のコマンドが発行されるのも理解出来る。

 

なんてこった……ずっと不明だったグラフィックコントローラは、μPD7220だったのか!

これはもう確定事項にしてしまって良いと思う!(^-^)

ずーっと手元にGDCの資料を置きながら作業してたのに気づかなかったなんて…orz

 

うーん…ソースを書き直したくなるよ…どうしよ…(^^;;

 

ではまた次回!(^-^)ノ

JR-300エミュレータの開発その5

JR-300エミュレータの開発話、第5弾!(^-^)

いくつまで続くんだろ…多分7くらいで終わる気がする(^^;;

 

JR-300エミュレータを公開してからというもの、すごい量のDMが届く!

日本語英語のみならず「これは何語??」って思うメッセージまで(^^;;

JR-300ってそんな有名なマシンなんだっけ?(@_@;

 

「解析のコツみたいなものはあるのか?」という質問が多いのでお答えします!

コツというよりは「過去に自分でBASICインタプリタを作ったことがある」というのが大きい気がする。

BASICインタプリタが内部でどのように動いてるのかを理解しているので「これは何をしてるんだろう?」というよりも「多分こういうことをする処理があるはず」という狙った解析ができているんだと思う。

LINEやPAINTのアルゴリズムも、実際に作ったことがあるから迷うところが少ない。

コツというよりも、過去の経験と知識が役立ってるんじゃないかなー(^^)

 

 

2022/11/21(月)
BASICの命令や関数を実行しまくって、不具合が出るもの片っ端から直していく。
各命令を見ていくとJRシリーズっぽいもの(FIND命令とか)もあるけれど、SYMBOLなどのF-BASICっぽいものも存在する。
各メーカーの良いとこ取りをしたマシンっぽかったのかな…。

MON命令(マシン語モニタ)で ? を入力すると停止する。
何かヘルプを表示させようとしているとか??
調べてみると制御文字の0x07を出力していた……BEEPか!
音は最後の最後にしたいので、今は何もしないのが一番の対処!(^^;;

 

CONSOLE命令はスクロール開始行、スクロール行数の指定となっていた。
これもWIDTH命令で初期値に設定されたまま放置していたが、ちゃんと設定することで簡単に対応終了。
CONSOLE命令の省略形としてC. が使えるようだ。

 CONSOLE 0,25 → C.0,25

各命令の省略形を調べるのは、全コマンドを打ち込みまくるしかないか…。

これは別の機会に頑張ろう、おう!

 

PEEK、POKE、CALLのテストもサクッと終了。
この辺りの…サブCPUもグラフィックコントローラも触らないものは、今の状態でもほとんどが動くんだろうな…と思いつつも念のためテスト。

テストしてると楽しくて1日の作業時間があっという間に終わっていくw

    
2022/11/22(火)

今日はカラーパレット関連を見ていく。

 

PALET命令は2つの引数を持つ。

それぞれが数値で0〜7の範囲という、いかにもカラー番号を表している。

しかし…PALET命令を実行しても、グラフィックコントローラ側に情報が出ない。

ありゃ…と思っていると、意外にもサブCPUコマンドが(今まで出現した事のない)別のカタチで呼ばれている事に気がついた!

 

今までテキスト関連を制御する時には、[0xFC01]←0x06が入るタイプで、コマンドコード自体は[0xFC47]に入っていた。

 

そういえばこのサブCPUアクセスのサブルーチン群は、さらに上のレベルで分離していたんだった…。別のレベルでもサブCPUアクセスがあるとは!

 

コマンド 引数   パラメータアドレス
00      02    [FC27]
01      01    [FC34]
02      01    [FC2A]
03      01    [FC2F]
04      02    [FC34]
05      06    [FC3F]
06      23    [FC47] ← これがサブCPUアクセスの関数群
07      0B    [FC88]
08      0A    [FC90]
09      0C    [FC99]
0A      07    [FCAF]
0B      01    [FCB6]
0C      05    [FCBB] ← これも出てきてる
0D      03    [FCC6]
0E      01    [FCC9]
0F      03    [FCCE]
10      01    [FCED]

 

今までは0x06の呼び出ししか対応出来てなかったけれど、この機会に全て受け取れるように修正する。

かなり大きなコード修正になるので、2~3日はかかりそうな予感。

 

2022/11/23(水)
サブCPU処理のリファクタリング
元の構造を残さずキレイに書き直す判断をしたため大幅な変更。
今まで書き散らかしたコードの多いことよ…orz

 

2022/11/24(木)
サブCPU処理のリファクタリング作業が落ち着いてきた。

キレイに整理してみて分かったが、サブCPUのコマンド番号はまだまだ空きがあって、正体不明な部分だらけだった!

こんな少しの実装だけでもBASICって動くんだな…(^^;;

 

ようやくPALET命令の作業に戻ってこられた!

PALET 1,7
この指定で、カラー番号1の色(青)をカラー番号7の色(白)にチェンジする。

数値をカッコでくくるとSyntax Errorなので注意。

 

サブCPUコマンドの0x0C系列0x02がパレット変更機能と判明。

 

パレットの変更は、なぜかサブCPU側に情報が出ている。

パレットってグラフィック画面への命令だと思いこんでいるが、もしかしてテキスト画面にも影響するって事??

それとも最終的な表示は合成も含めてサブCPUが処理してるから?


…常識的に考えたらグラフィックのパレット変更だと思うので、今のところはそのように実装してみる。

実機で見てるわけではないので、これが正しいかどうかは分からない。

デモンストレーションのプログラムでパレットチェンジが出てくるかなぁ…。

 

BASICのシステムコール

BASIC内部で呼び出されるシステムコール、コマンド番号の後ろに2バイト空けるのがルールらしい。
この構造はF-BASICを解析してた時に見た覚えがある。

コマンド番号、戻り値、Reserve…みたいな感じなんだろうな、きっと。

 

表示プライオリティ
PRTY命令、おそらく画面のプライオリティなんだろうと想像。
どこかの資料に表示プライオリティを変えられると書いてあったので、この命令がそれなのかも?

 

PRTY命令の書き方は「PRTY 式」となっている。
数字は0〜255の範囲を取るみたいだけど、さすがにこれだけあると想像が付かない…。
スーパーインポーズ、テキスト、グラフィックの3つだと思うけれども、他にもあるのかな…。

 

BASIC起動時に1で初期化されているので、これがデフォルトっぽい。
この設定で、テキスト画面を手前、グラフィック画面を奥に設定しておく。
「PRTY 0」とすれば、テキストとグラフィックの表示優先順位を変えるようにしてみた。

この辺りも実機がないと確認は出来ない。

実機で見てみないと案件が増えてきた(^^;

 

 

2022/11/25(金)
謎のマシンJR-300、今までの解析でおぼろげに見えてきたのは…

 

Z80
メインのプログラムシーケンス

サブCPU
おそらく6802なんじゃないかと想像してるけどクロック数含めて詳細不明。
テキスト画面、サウンド、画面制御(パレットや表示優先順位など)を担当

グラフィックコントローラ
グラフィック全般を担当。
直線補間はあるっぽいけれど、それ以外は特筆する機能を見つけられていない。

 

メインCPUからビデオメモリを分離してる事で、表示に必要なDMAがZ80側に割り込まずに済むはず。その分、Z80はノーウェイトで動いていた可能性が高い。

ただ、サブCPUやグラフィックコントローラとのやりとりは複雑怪奇で、全体的なバランスは悪く感じる。

カタログスペック上は最高性能に見えたかも知れない!(^^;

 

さあ!

BASICインタプリタの各種命令もだいぶ動いてきたし…

そろそろデモンストレーションを動かしてみたいと思うようになってきた!(^^)

出来る限りBASICの命令でハードウェアの詳細を調査し、万全の体制でデモンストレーションへ移行したい気持ちが強かったけれど、まだまだ完全ではない。
PCG機能とか音楽演奏とかは放置したままになっている。

音楽はどうしようかな…とかなり悩み中。

 

不安は残るものの前に進むしか無いのでデモンストレーションの動作確認に入る!

デモンストレーションプログラムはBASIC言語で書かれているわけではない。オールマシン語プログラムとして独立している。

そのため、今まで解析してきたBASICのワークエリアなどは役に立たず、あくまでもサブCPUとグラフィックコントローラの仕様のみが生きる感じだ。

今までプログラムを書いてきたJR-300エミュレータの素性が試される!(T-T)

 

PCG

デモンストレーションプログラム先頭で、PCG定義みたいなエントリを見つけた。
サブCPUコマンドの0x06系統0x0Dでキャラクタを定義しているみたいだ。

データフォーマットはキャラクタ番号、実際のデータという感じの単純なものだったため、特に悩むこともなくサクッと対応。

フォントの0x00~0x3Eまでが書き換わってるのがわかるだろう。

ちなみにこのフォントビュワーも即席で作った!(^^;

こういうしょーもないツールが増えていくのも仕方ないだろう…w

 

フォントデータはBASICプログラムに埋まってるわけではない。私自身がJR-200を所有しているので、そこからデータを拝借してきた。このJR-300のフォントセットはコレで正しい…というわけではないのでご注意!

 

定義するキャラクタのデータは8バイト固定となっている。この事から察するにPCGはX1のような8色ではなく単色であることが分かる。

これは…ちょっぴり惜しさを感じちゃうな…(^^;

 

サウンド

次にサウンド関連の処理らしきものが出てきた。
どうやらサウンドはサブCPU側で動かしているらしい。

 

サブCPUとの共有メモリである0xFC0Eに0x00、0xFC02に0x80を書き込んだのち、0xFD00からサウンドデータ(微妙にバイナリ化されたMML)を書き込んでいく。

このMMLをテキスト化したデータは以下の通り。

 

T90V15O5L20C+L4DD+EL8AEDC+O4L24BO5L8DL24F+L8DO4L20BL4A+BO5L4CL7C+R1L8EDC+O4BAG+AL16O5C+L8O4BEO5L20C+L4DD+EL8AEDC+O4L24BO5L8DL24F+L8ED+DC+O4BAG+O5C+O4L7BR1L32BL16A
T90V15O5L8R8AR16O5R8ER16O4R8F+R16O5R8DR16O4R8G+R16O5R8ER16O4R8AR16R8AR16R8AR16O5R8ER16O4R8F+R16O5R8C+R16R8DR16O4R8G+R16R16L16G+R16
T90V15L8O3AR8O4ER8O3C+R8O4AR8O3DR8O4DR8O3BR8O4BR8O3G+R8O3G+R8O3AR8O4AR8O3G+R8O4DR8O3ER8O4G+R8O3AR8O4ER8O3C+R8O4AR8O3DR8O4DR8O3A+R8O4F+R8O3BR8O4F+R8O3ER8O4ER8O3L16AR16O4E

 

友人がMSXで演奏させてくれたけれども、微妙に…ちょっと…とても変!(^^;

私がテキストに変換する際にMMLの解釈を間違えているのか、それとも何かクセのあるサウンドドライバだったのか…(^^;;

これはエミュレータではないところで悩みそうw

 

プログラムを見る限り、サブCPUへ渡すMMLの長さは256バイトを超えても大丈夫のようだけど、限界値は不明。サブCPU側のバッファに依存しそう。

実機がないとわからんなぁ…。

とりあえずエミュレータ側がPSG対応するまでは仮対応で先に進む。

 

デモンストレーション画面
デモンストレーションの最初の画面を描画する辺りで、今まで制御文字だけだと思っていたエントリが、実は通常文字も扱える事を知った今!

こういう使い方の幅については、実例が出てこないと気が付けないよね…汗

 

でも表示された画面を見ると……

うん、見事に化けてるね(T-T)

 

多分だけど…標準フォントとPCGフォントを切り替える必要がありそう。
あるとしたらアトリビュートかな…。
JR-200ではアトリビュート情報の中にノーマルフォントとPCGフォントの切り替えビットがあったので、JR-300でも同じ機能があるのかも?

 

今回はここまで!

あと数回続きます~!

 

ではまた次回!(^-^)ノ