せっかく高速バイナリ通信の仕組みを作ったので、それを活かした大きめサイズの何かを作ってみたい…と思った！
内容よりもデータ量よ！←割とひどい暴言
グラフィックデータを入手せよ！
もう次の事を始めたい気持ちが一杯で、時間が掛かる複雑なプログラムは無理だなぁ…と思い始めてしまったｗ HC-40とかHC-88の時にも「絵がない絵がない」と言い続けていたので、ここいらでまとまったモノクロ画像を用意しとこうと考えた。
工学社から発売されているI/O(今も出てるよ！)に、MZ-80B用の「グラフィック花札こいこい」というゲームが掲載されていた！私は当時のI/Oを別の場所に置いてしまっているため、手元にあった「MZ-80B活用研究」という書籍を参考にした。
ここから花札のグラフィックデータを借りることにした！(すみません)
データを借りる…と言っても、ダンプリストのどこからがグラフィックデータなのかを解析しなくてはならない。これはゲームプログラムの説明記事とBASICプログラムから比較的簡単にアドレスを割り出す事が出来た。そこで震え上がったのが、約10KBというデータ量…。
256バイトのブロック38個分だ！いやはや…しびれるｗｗ
若い頃は本当に沢山のダンプリストを入力した。一番長かったのがI/Oに掲載されていたFM-7用のゲーム「NOBO」じゃないだろうか…。64KBかそれ以上あったような気がする。掲載ページを減らすためかダンプの文字も小さくなっていたが、当時は気にせず打ち込んでいた。
最後にダンプリストを打ち込んだのは何だったのかなぁ…ポケコンかも？
それから長い月日が流れ、２年ほど前に必要に迫られてFM-8のゲームのダンプソフトを打ち込む必要が出てきた。昔、１ブロック(256バイト)を打ち込むのにチェックサムまで合わせて10分くらい掛かった記憶がある。そこから計算しても時間が掛かりすぎるな…と思い、OCRにてバイナリを入手する方法をとった。
OCRで読み取ったデータをテキスト整形してチェックサムを合わせて…とやると、１ブロック10分以上の時間が掛かったが、それでも手間を考えたらいっか…と思っていた。
最近はOCRに頼らず手入力している。OCRしたデータの間違いを修正しチェックサムを合わせるという時間が、実は結構掛かると気が付いたのだ。OCRに比べて入力の手間は掛かるが、時間は圧倒的に短い。当時は１本指でテンキーを16進数に見立てて打ち込んでいたが、今はフルキーを両手で打ち込んだ方が速いのだ！
ウソだと思ったら、試しに今、256バイトを打ち込んでみて欲しい。昔よりも高速に入力出来るはずだ！(^-^)
そしてチェックサムまで入力したテキストをチェックするツールを作った。これで相当なスピードアップとなり、２年前から何度となくダンプリストを打ち込むようになった。
データフォーマットを解析せよ！
私自身、MZ-80Bは所有した事が無い。当然、プログラムも作ったことがない。
しかしこれまた２年ほど前、１日だけお披露目する目的のためだけにMZ-80Bエミュレータを書いた事があった。開発も一晩というお気楽実装ではあったが、ちゃんとゲームが動いたｗ
その際、グラフィックのデータフォーマットは理解したつもりでいたので、だいーぶ楽観視していたのだが……今回、なぜかその形式に基づいて解析しても元の絵に戻らない問題が出た。
あれー……なんでだろ？？？
いろんな資料を漁るが、どうにも理解が及ばない。
オリジナルプログラムを解析してみたところ、BASICのPATTERN命令で表示しているようだ。ここに何か秘密があるのか…と思い調べていくと、なんと想像とだいぶ違うフォーマットになっていた(^^;; これは…分からないｗｗ
というわけで。外部ツールにてさくっと変換！
そのままＣ言語の8bit配列のカタチに変換する事にした。
こうしておけば、将来的に他のマシンでも使えるはずだ！
実機で表示させてみる！
PC-8201系のプログラムで難しいだろうな…と感じるのは、LCDへグラフィックを表示する辺りだと思う。アドレスが連続していないうえにLCDCのアクセスが少しばかり面倒だ。
まともに計算して描画しようとすると、条件判断文だけでそれなりになってしまう。
そこで、前回PC-8201でプログラミングした時だが、仮想VRAM→実際のVRAMへの転送処理を書いた。ユーザープログラムでは連続したアドレスの仮想VRAMに絵を描く、転送処理で複雑なVRAMアクセスをしてくれる…というわけだ。
下のリンクに詳しい概念を書いていたので、興味あったら参考にしてほしい(^-^)
ここまでお膳立てが出来ていたら、Ｃ言語で絵を表示するのは簡単だ。
マジックナンバーばりばりのコードで申し訳ないｗ
お前ホントにプロか？との声が聞こえてきそうな気がするけどキニシナーイｗ
8085アセンブラで書こうとすると少々面倒な気持ちになってしまう処理でも、Ｃ言語で書いたら一瞬だ！レトロマシンでもこういう効率の良さが必要だよね(^0^)
ちなみに上記のコードをそのままコンパイルすると、結構悲惨なコードが出てくる。速度的にはアセンブラで書いたのに比べて1/3以下くらいかも知れないが、まずは動かす事が重要よ(^^)
当たり前なのだが…C言語使うと四則演算が簡単に書けて本当に助かる。アセンブラで書いてると乗算ひとつとっても大変だ！(^^;;
ワンパターンだけど…NEC PC-8300でグラフィックスを表示させてみた！
— PocketGriffon (@GriffonPocket) 2021年2月1日
プログラムは数分で作れたけどデータ入力が大変だったよ！(T-T) pic.twitter.com/jpcrAq0cp7
実際に動かしてみたのがこちら↑
例のバイナリ転送プログラムを使ったよ！
先日開発したバイナリ転送プログラムを最大限に活用した！
今回は花札のグラフィックデータだけで10KB近くもある巨大なものだ。BASICのテキストに変換してみたら、37KBにもなってしまった。実機にロードするためのメモリが足りない！
これもバイナリ転送さまさまだ！
転送速度を測ってみたが、約10KBの転送に掛かる時間は手動計測で10.5秒ほど。きっちり9600bpsで転送出来ているとみて良いだろう！(^-^)
表示プログラムが単純すぎて、２〜３度しか転送しなかったのはナイショだｗ
ではまた次回！(^-^)ノ
