今年の２月にPC-1600KでBad Apple!!を表示するプログラムを作った。
「せっかくPC-1600Kに32KBの増設メモリを２つ取り付けているのに、それを有効活用出来ていないなぁ…」と思ったので、メモリを使い切る事を目的とした実験だった。当初の目的は達成出来たのだが、画像データを強めに圧縮したため表示速度が出ないという残念な結果に終わっていた。
その後、表示を高速化をするブログを書いている。データ構造を変える事はせず、ソフトウェア側でどこまで高速化が出来るかという、これまた実験だった。
その結果、やはり不満が残る結果に…。
速度が出ていない事もそうなんだけど、一番気になっていたのはBad Apple!!が最後まで見られないのだ。
Bad Apple!!は約219秒のアニメーションで、秒間30枚の絵で出来ており総数は6566枚ある。
PC-1600Kという限られたメモリ容量しかないマシンで、この枚数すべてをオンメモリに載せるなんて不可能！(T-T)
それでも頑張ってデータを圧縮して、前回の実験では1086枚の絵をメモリに載せていた。
64KBに1086枚入ってるのを多いと思うか、少ないと思うかは人によって差があると思うけど、自分的にはそれなりに入っていたと思ってる(^^)
単純計算をすれば、384KBのメモリがあれば全てのデータを入れられるかも知れない。
データは入るかも知れないけど、速度はあのままだ。
どうしたらPC-1600Kで1/30秒の表示をしつつBad Apple!!を完璧に再生できるんだろうか…。
メモリが……メモリが欲しい！！！
増設メモリを作ってしまえ！！
そんな切実な思いを伝えたかどうかは覚えてないが、何ヶ月か前からハードが得意な知人に「PC-1600Kの増設メモリって作れない？」というお声がけをしていた。お声がけというか、本体と増設メモリと資料をセットにして押し付けたｗｗ
その知人からプロトタイプが出来上がったと連絡があり、先日そのメモリを受け取った。
これがそのメモリだ！！本邦初公開！！
容量は1MB、つまり1024KBもある。
ポケコンに1MBという容量が必要なのか…と、さすがの私も思うｗ
メモリモジュールにはCE-1600M同様にバッテリーでのバックアップ機能がある。一度書き込んだデータは意図的に消さない限りは残っていてくれる。
こんな感じにS2スロットに取り付けて使う。
知人曰く「しまったー！本体に取り付けたまま電池の交換が出来ない！」と言ってたので、もしかしたら改善されるのかも知れない(されないのかも知れないｗ)。
勘違いされるとイケナイので書いておくと、メインメモリとして拡張されるサイズはCE-1600Mと変わらず最大で32KBだ。それ以外のメモリは基本的にRAMファイルとして使う。
PC-1600Kは元々256KBまでのメモリならば標準のROMでフォーマット(INIT)出来る。それを超える場合には独自でフォーマットプログラムを作らねばならない。
知人にハードを作ってくれとお願いした手前、このプログラムは私が書いた。
DSKF "S2:"すると、冗談のような数字が表示される！
Bad Apple!!の再検討！
大容量メモリは手に入った！これでようやくBad Apple!!のリベンジができそうだ。
どうせイチからすべて作り直すことになるんだから、データフォーマットも都合の良い形式に変えてしまおう。目指すべきは「高速表示」だ。この目的のためにメモリを使う！
まず、無圧縮ですべてのデータが入るかを検討してみた。
PC-1600Kでの表示は64x32ドットにしよう…と前回の実験で決めていた。これはPC-1600Kでは程よいサイズという事もあるが、このマシンが高速に描画するのに都合が良いサイズでもあるのだ。今回もこのサイズは崩さないようにする。
１バイトが８ドット構成のマシンなので、データサイズとしては１枚の絵(64x32ドット)で256バイト。絵は6566枚あるので単純計算だと1.6MBの容量が必要になる。1MBでも収まらないなんて……Bad Apple!!恐るべし！！(^^;;
この手の画像データはランレングス圧縮すると圧縮率が良くなる事は分かっている。分かっているがドット単位の展開では処理時間が掛かるのは、前回の実験で証明されている。
今回はデータの最小単位をドットではなく、バイト単位でデータを小さくするアプローチにした。
256バイトのデータの中に、00とFFのどっちが多いかを調べる、それを基準の色としバッファをクリア。さらに基準の色が00だった場合はFFを、FFの場合は00がいくつあるのかを調べて、そのオフセット(バイトの位置)をデータとして並べる、最後に00でもFFでもないデータをオフセット＋データとして並べる。
言ってる事が良くわからん…と思うけど、運が良ければデータは小さくなり、複雑な絵はむしろ大きくなるフォーマットだ。そこで元の256バイトよりも大きくなる場合には「無圧縮」という選択をいれた。最大で256バイト、基本はそれ以下というデータとなる。
このフォーマットの利点はデータの復元が高速な点だ。1/30秒での表示をするためには展開速度の高速化は優先度が高い。
この方式に基づいてデータを加工してみたところ、6566枚の画像データが約884KBに収まる事が分かった。ここでようやく付加データも含めて1024KBに収まりそうな目処がたった。
表示プログラムはアセンブラ化！
前回の実験では描画処理をC言語で書いていた。ドット単位で展開処理を書く必要があったため、プログラムがある程度複雑だったこと、出力されるアセンブラコードを見て「これ以上速くするのは簡単じゃない」というところまで突き詰める事が出来たため、それ以上触らなかった。
今回は前回以上のガチンコ勝負なので、最初からアセンブラで書く事を意識したデータ形式にした。おかげでプログラムをすっきり書くことが出来た。バッファのクリアなどはPUSHを並べるなどZ80っぽい高速化を楽しみながらのご実装をした(^^)
前回は省メモリ化のためデータの途中でバンクを跨ぐ事を許容したコードを書いていたが、今回はそこも廃止し、１つの絵を表示するデータはメモリバンクを跨がない保証をデータ側でした。おかげでメモリアクセスもすっきりし、非常に高速にアクセス出来るようになった。
巨大データをモジュールへ転送！
さて……おそらく今回一番の問題はココ！
さっき全部のデータで884KBと書いたが、この巨大なデータをどのようにしてメモリモジュールへ転送したら良いのか…。
PC-1600KはBLOAD命令でバイナリのデータも読み込むことが出来る。マシン語のデータなどはBLOADで読み込むようにしてて、とっても便利だ。
このBLOADで読み込めるバイナリデータにはバンク情報が含まれるのだが、実は今回のケースではこの情報だけでは足りないのである。
PC-1600Kのメモリバンクは、横方向へ伸びるバンクメモリと、それとは別に縦方向に伸びるバンクメモリが存在する。通常、PC-1600Kで「バンク」と言えば横方向を指していて、BLOADにはこの「横バンク」の情報が入っている。
今回のメモリモジュールは「縦方向」のバンク情報を操作する事でメモリアクセスをする仕組みだ。BLOADで対応出来ないのはそういった事情による。
無いものは作りゃいい！の精神で、縦方向のバンクにも対応したダウンローダーを作った！(^^; 以前、高速バイナリローダーを作ろうとした時に色々と調べてあったので、ワリとあっさり作ることが出来た。
RS-232C経由で専用のバイナリを送り込めば、自動的にバンクメモリに書き込んでくれる。
横方向のバンクにも対応出来ているので、BLOADの代わりに使う事が出来る汎用ツールだ。
大雑把にはこんな↓感じでデータをダウンロードした。
6566枚のデータを圧縮、順番に並べて１バンクのサイズ(16384バイト)に収まるように１つのファイルとする。こうして並べていくと全部で56(1MBは64バンクある)のファイルになった。これらのファイルの先頭にバンク情報などを書き込んでやり、最終的には１つの巨大なファイルとした。
この巨大データを専用ダウンローダーでダウンロードしつつメモリへ書き込む。RS-232C経由ということもあるが、884KBのデータを転送しつつ書き込みつつ…をして約33分掛かった！
でも33分で面倒なデータを書いてくれるんだったら万々歳だ！
------
PC-1600KでBad Apple!!をリベンジしてみた！速度がかなり速くなってるのと、全フレームが入ってます。長くて全部は載せられないけど(^_^;)
— PocketGriffon (@GriffonPocket) 2021年4月15日
詳細はブログで紹介予定！＼(^o^)／#BadApple#PC-1600K#ポケコン pic.twitter.com/RkfRN0Uizf
やっとPC-1600Kで満足が出来るBad Apple!!を作ることが出来た。
オリジナルとは白と黒が反転してるなど気になるところはあるけれども、次のチャンスがあったら修正したいと思う。次があるのかな？あるのかもねー汗
ちなみに今回使った1MBの増設メモリだが、あくまでもテスト版でありプロトタイプだ。
今後どのような展開になっていくのかは知人のみが知る…って感じだ！(^^;;
ではまた次回！(^-^)ノ
