リトルバンパイアforP6(5)

　　リトルバンパイアをP6で動かそうブログ５


　　FM音源がやっと終わりました。
　　音色が違ったのは、FM音源の再生時に１オクターブ高かったためでした。SSG音源の方は合っていたため、分かりづらかったようです。


　　で、また別の問題が。


　　漢字を表示させる時の美咲フォントデータですが、第一水準のデータだけでも30K程度あります。
　　当初、PC-6006を使えばフリーエリアが16Kぐらいになるので、対処できるかなーと思っていたんですが、どうもこれだと足らないようです。


　　今のターゲットは、

　　PC-6001mk2SR＋PC-80S31（２ドライブ） or PC-6601SR（２ドライブ）
　　　　＋
　　PC-6006SR or PC-6007SR

　　という、かなり贅沢なスペックが必要になります。


　　PC-6601SR ＋ SD-6031WIF（64Kバイト増設版）でもいいんですが、64Kバイト増設というのがネックですね。


　　エミュレータなら、全然問題にならないんですけどね(^^;)

Comments

お久しぶりです。ずっとROMってましたが全部読んでいました。

> 　漢字を表示させる時の美咲フォントデータですが、第一水準のデータだけでも30K程度あります。

ROMの漢字は使えませんか？外部フォントを使うよりもROMの字を使って工夫して
表示する方が良さそうな気がします。SRなら一水はありますから充分でしょう。
文字サイズはSRのJIS漢字もmkIIの漢字も同じでしたっけ？

ところでANKは内蔵のを使うとして、漢字も全部オンメモリでないとダメですか？
mkIIのように教育漢字だけオンメモリにすれば半分くらいになると思います。
あまり使わない字はFDから読むのも当時の機種らしいのでは？

> PC-6001mk2SR＋PC-80S31（２ドライブ） or PC-6601SR（２ドライブ）
> 　　PC-6006SR or PC-6007SR

元々が2D2台の88用ですから2FDDは当然としても、せめて6006で間に合うように
したいですね。

Posted by かかっくん at 2014年08月26日 09:46

どうもです。

漢字の件ですが、以下の２点が問題です。

１）SRでも1024文字＋仮名文字しかROMにはありません。ROMカートリッジには第一水準はありますが、入手性の問題や、エミュレータが未対応などのため、現実的ではありません。

２）漢字ROMのデータは16×16ビットのため、8×8に無理やり変換した場合、多分判読できないと思われます（未確認ですが）。


また、
>> ところでANKは内蔵のを使うとして、漢字も全部オンメモリでないとダメですか？
>> mkIIのように教育漢字だけオンメモリにすれば半分くらいになると思います。

使う／使わないの判別をするのがかなり厄介です。
文章の文字コードを加工しない場合、多分１文字２バイトのテーブルが必要になるので、どれだけの文字を搭載できるかなー、という所です。


>>あまり使わない字はFDから読むのも当時の機種らしいのでは？

　これは案としてはアリかも知れませんが、多分非常に遅くなってゲームにならないと思われます。
（今でも十分に遅い...）


　PC-6006（16K）だけの対応に関しては、もうちょっと考えてみます。

Posted by えすび at 2014年08月26日 22:21

> １）SRでも1024文字＋仮名文字しかROMにはありません。ROMカートリッジには第一水準はありますが、入手性の問題や、エミュレータが未対応などのため、現実的ではありません。

そうでしたか。てっきりSRには一水はあるのかと思っていました。
スペックの確認不足です
# よく考えたら最低でも256Kを3ヶ、互換性でP6漢字がもう1ヶ、計4ヶ必要ですから
# 載せないのも無理ないですね

> ２）漢字ROMのデータは16×16ビットのため、8×8に無理やり変換した場合、多分判読できないと思われます（未確認ですが）。

これは指摘されると思っていました。16x8は88の200ラインやDOS/Cで実績がありますが、
さすがに8x8は未知数ですね。
美咲フォント以外にも8x8のフォントはあり(MacOSのOsaka 9ポイントとか)それなりに
読めるので、やはり8x8でデザインされたフォントが
良さそうです。

> 使う／使わないの判別をするのがかなり厄介です。
> 文章の文字コードを加工しない場合、多分１文字２バイトのテーブルが必要になるので、どれだけの文字を搭載できるかなー、という所です。

どこまで文字を減らせるか試してみました。
88版をM88上でKANJI1.ROMの内容を変更してプレイしてみました。
# ご存知のように、P6漢字はJIS漢字を間引いて詰めたものであり、並び順は同じです

フォントにテーブルを持たせるという方法があります。
ex.
DEFW 8140h ;コード(SJIS)
DEFB 0,0,0,0,0,0,0,0 ;フォント
DEFW 8141h ;コード
(以下略)

これなら1文字あたり10バイトになります。1024文字で10Kです。
ディスクには歯抜けにせずすべてのフォントも収録しておけば(ただしRAM転送用10Kが増え
ます)ルーチンの修正は小幅で済みそうです。

ところで、フォント無しなら増設RAM無し(SRの64Kだけ)で動きますか？
それともやはり増設必須になりますか？

Posted by かかっくん at 2014年08月28日 02:01

　とりあえず、BGMなしなら拡張RAM16Kで済むようにしました。

　美咲フォントは、８×８なんですが、実質は７×７なので、余計な空白の１バイトを削りました。（罫線などだけが８×８で、漢字は全て７×７です）


>>ところで、フォント無しなら増設RAM無し(SRの64Kだけ)で動きますか？

　可能ですが、ほとんど意味がないため、プログラムの最初のチェックで起動しないようにしています。

　まあBASICなので、何とでもなりますが。

Posted by えすび at 2014年08月28日 20:00

>> ところで、フォント無しなら増設RAM無し(SRの64Kだけ)で動きますか？
> 　可能ですが、ほとんど意味がないため、プログラムの最初のチェックで起動しないようにしています。

ぃぇこれは増設RAMにフォント以外も載るのかフォントだけか？という確認でした。
フォントだけならフォントのサイズを圧縮できれば(8x8→8x7で1バイト浮く)RAM必要量を
減らせるので...質問が拙かったですね

ちなみに、16x16を256Kx3にした場合、本当に一水しか入りません。記号類はANKのものを
使う事になります。英数記号類込みならいつものように256Kx4(1Mx1)になります。
同様に、ANK併用なら8x8で24K、8x7で21Kになりそうです。テーブル式なら8x7で最大27K
前後ですか。

# mkIIの際に同じ256Kに詰め込むなら16x16 1024字より8x8 一水フルセットが面白かった
# かも知れませんね

Posted by かかっくん at 2014年08月29日 04:39

　今のところ、拡張RAMに載っているのは

・8x8美咲フォントデータ（第一水準）
・BGM再生

　です。

　BGM再生は意外と大きくなってしまい、プログラムが2Kバイト、音色データが2Kバイトです。この他に音符データ（MMLデータ）が必要です（結構大きい）。

　8x8美咲フォントなら、第２水準まで64K拡張RAMに搭載可能です。何も細工せずに60Kぐらいのサイズです。

Posted by えすび at 2014年08月29日 21:27

> 　今のところ、拡張RAMに載っているのは
> ・8x8美咲フォントデータ（第一水準）
> ・BGM再生
> 　です。

あれ？フォント無しなら...

>> ところで、フォント無しなら増設RAM無し(SRの64Kだけ)で動きますか？
> 　可能ですが、ほとんど意味がないため、プログラムの最初のチェックで起動しないようにしています。

だったのでは？
↑は文字表示ルーチンを省いて代わりにBGMのルーチンを入れた場合ですか？
それともBGMも鳴りませんか？

> 　8x8美咲フォントなら、第２水準まで64K拡張RAMに搭載可能です。何も細工せずに60Kぐらいのサイズです。

8x8なら32K、16x16なら128Kで4096字ですから、64K/256KでJIS X0208(JIS83)が全部入り
ますね(256Kは一般的な実装)。組み込みで8x8をROMに焼いたものや余った末尾にANKを
焼いたものがあるようです。
今回は二水は不要と思います。88のF系は一水までだったので、シナリオには使っていないと
思います。

結局、現状ではフォント＋BGMで拡張16Kは無理そうですね。何とかせねば

Posted by かかっくん at 2014年08月30日 01:16

　何だか誤解を招きそうなので、完成版のメモリマップを参照して下さい。

Posted by えすび at 2014年08月30日 08:40