幻の画像フォーマットPRCGSを復活させる

Win32版(JE4SMQ作)

M5Stack版(JE4SMQ作)

エミュレータ上のMZ-2500 Personal CP/M版(JE4SMQ作)

エミュレータ上のX68000版(JF0MVA作)

エミュレータ上のMSX2 SCREEN12専用版(JS1CSS作)

エミュレータ上のPC88VA版(JJ4CAG作)

エミュレータ上のPC-8801CDOSII(JETターミナル)全機種版(当時のJA1YBE構成員作)

エミュレータ上のFM TOWNS版(JK2RLT作)

エミュレータ上のPC-98x1 Windows98でWin16版とMS-DOS 16/4096色版(いずれもJK6PZZ)作

※元は1991-93年頃の開発のため、21世紀現在は別人にコールサインが再割り当てになっている可能性があります

平成初期に一部で流行したPRCGS画像フォーマット保存委員会です。

知名度は殆どありませんが、後述の通り非常に多くの国産パソコンに移植されています。

全てアマチュア無線家の手による開発です。

当時X68000とMZ-2500用を作成しましたが、令和改元記念に今時のプラットフォームへ移植を行ってみました(2019/5/2)。

PRCGS閲覧アプリのWin32版アプリは今まで存在しなかったので、今となっては普及のしようがありません。

今回ありそうで無かったWin32版と、今流行のM5Stack用 に移植を行いましたので、レトロPC実機やエミュレータを持っていない方でも容易に当時の画像を見れるようになりました。

Win16版は存在しましたが、Windows3.0時代の物で、現在の64bit Windowsでは起動すら拒否されます。

今回それが解消され、リビルドすればネイティブx64版も作成可能です。

また、Win32版はデータ作成アプリも移植したので新しい画像データを作成することが出来るようになりました。

上のサンプル画像をご覧下さい。

手前で確認した限りまあまあの互換度ではと思います。

Win32版は表示もデータ作成もほぼ一瞬です。

M5Stack版は途中に中間ファイルを作るため当時の処理速度に近いですが、やはり速いですね。

当時はどの機種も表示に数十秒、データ作成は何分も掛かりました。

写真は2017年に父島へ行って小港海岸すぐのカフェUSK Coffeeで撮影したものです。

320x240pixelのカラー液晶内蔵で5cm四方のM5StackとPRCGSの相性は非常に良く、Dot by Dotできれいに表示できます。

Win32版は無償のVisual Studio 2009 Communityで、M5Stack版はArduinoで開発しました。

不具合修正や機能追加はご自身で行って下さい。

実行ファイルとサンプルデータはこちらです。

サイズが大きいですがソースファイルはこちらです。

また、当時ハムフェアやSASEで頒布されたPRCGS DATA Collectionはこちらです。

※サーバの都合のよりダウンロードできなくなる可能性があります

当時のおたく文化、レトロPCの雰囲気が満載です。

なお、ファイル展開にはLHaやPMext等の現在では主流ではないアーカイバーが必要です。

このページへのリンクはかまいませんが、再配布は中のドキュメントに従って下さい。

以下に誕生の背景にある技術や文化の説明があります。

技術的解説は次を見てください。

PRCGS誕生の背景(パソコン史な視点で)

平成初期(ここではWindows95発売前の1988-1994年頃の話とします)のバブル期には画像処理を売りにしたホビーパソコンがたくさん発売されました。

令和元年現在ではパソコンの規格はほぼWindows10が走るものと相場が決まっていますが、当時は各社が独自仕様の8/16ビットパソコンを発売していました。

日本ではかな漢字文化が根強いので、独自仕様でも光るものがあれば一定のシェアが取れていたのです。

当時のパソコンはグラフィックの解像度が320x200-640x400pixel程度で、16色も出れば良い方でした。

後に1990年代の市場を席巻するガリバーNEC PC-9801もこの範囲に入っています。

しかしながら1980年末期ごろから256色、4096色、65536色同時表示が可能なパソコンが発売され、写実的な表現が出来るようになってきました。

とはいえ当時は満足なペイントツールは無く、当然スキャナやデジタルカメラはあっても高価で、下絵をラップフィルムに書いてCRT(液晶ではありません)に貼り付けてなぞると言った苦労をしながら絵を描いていました。

今では信じられないと思いますが、当時はそのように描いた絵を線や円、あるいは16進ダンプに分解してプログラムにして頒布するといったこともありました。

これは画像だけを表現するフォーマットがまだ未分化だったからです。

NAPLPSというフォーマットがありましたが、これはそのような考え方で画像を記述していました。

今は存在すら覚えていないビデオテックス、日本だとキャプテンシステム等ではこの考え方で表現力を売りにサービスしていましたが、結果は文字しか出ないパソコン通信のコミュニティ機能(絵が出ない以外は今のSNSと大した差はありません)の勝ちでした。

ちなみに現在主流のJPEGが発表されたのが1992年9月18日だそうですからそれより前ですね。

JPEGは当時のコンピュータではソフト的に処理するのは非常に苦労するフォーマットだったため、21世紀までは実質使えなかったのです。

GIFやTIFFやBMPは既にありましたが、256色以上ではフロッピーディスク1枚に数枚（1枚もだめなことも)の絵しか入らない巨大な代物でした。

GIFは特許問題があり、使用がはばかれた時期があります。

パソコン通信の時代の通信速度は、初期は300bps、アナログモデム末期でも56kbpsでしたから、携帯電話でギガビットの5Gとは隔世の感があります。

PRCGS誕生の背景(アマチュア無線の一時代)

昭和末期から平成初期までが日本のアマチュア無線が一番勢いのある時代でした。

一般に1987年11月21日公開の「私をスキーに連れてって」が主な理由と認知されていて、携帯電話の無い時代にゲレンデでハンディトランシーバを使うシーンが大変受けたのは実際そうだと思いますが、私は別の理由もあると思っています。

1985年に電電公社がNTTに民営化されたときに端末開放がされました。

今では考えにくいと思いますが、固定電話機は電電公社からのレンタルが原則で、建前では電話回線から外して勝手に取り換えることが出来なかったのです。

それが公式に許されることになって、各社からいろんな電話機やFAXが売り出されました。

電話だけでなくモデムの接続も可能になりました。

そこでパソコン通信なるものが出現し、PC-VAN,Nifty-Serve,アスキーネット等大手が出現して全国レベルでのコミュニティが出来るようになりました。

ヘビーユーザーは電話代が月何万円もかかることもあったようです。

大手に対して草の根ネットというものもあり、コアな話題はそちらの方が主流な場合もありました。

時をほぼ同じくして、アマチュア無線の世界でもFMトランシーバに接続してRTTYよりも高速でエラーフリーの出来るパケット通信が現れました。

こちらは電話代の概念はありません!

モデムに相当するTNCは当時のモデム代と大して変わらなかったのです(大体3-4万円、時代が進むと2万円程度)。

4アマの試験は当時も今も簡単ですからパソコンが得意で一日中通信したい層が大挙して参入してきました。

当時発売されたパケット通信に関する書籍です。

一番左がアメリカで1986年に発行されたおそらく世界で最初の参考書です。

ちなみに全部英語で、写真は皆無です。

表紙に当時市場を席巻したMFJのTAPR TNC-2クローンやカントロニクスのKPC-2が踊っています。

右は国内で最初に発売された解説本、CQ出版のパケット通信ハンドブック(1987/5)と電波実験社(現電波社)のパケット通信(1987/5)です。

私の現在の所持品です。

Teleleaderブランドのタスコは当時TNCの販売ではトップメーカーでした。

膨大な利益をあげて莫大な収入があったそうですが、別事業（パチンコの制御基板)の失敗で現在は潰れています。

下はオーディオメーカーのアイワ(今はソニー関係の十和田オーディオのブランドですが)のAPX-M25です。

当時パソコン通信用モデムを発売していて一定のシェアを取っていましたが、TNCもAPX-25/APX-M25というのを発売していました。

当時の広告です。

WARDは日本で初めてTNCを発売(AEA社製の輸入やノックダウン生産)した会社です。

T-ZONEはまだハムショップのトヨムラの時代です。

その後亜土電子＞ツクモ＞ヤマダ電機...悲しいですね。

短波帯で海外と交信したい伝統的な層、FMハンディ機でラグチュー(おしゃべり)したいカジュアル層、コンピュータネットワークで実験したいマニア層が全部そろっていた時代でした。

令和元年の実情は、伝統的な層がFT8等の低S/Nでも通信出来る手段へ変質したとはいえ唯一残ったということでしょうか。

写真の右上がTNCです。

それらが合体する平成初期

パケット通信がヒットしたのは以下の理由があります。

・1200bpsの高速通信

　今から見れば非常に低速ですが、パソコン通信用が300bpsの時代に1200bpsのモデムを積んだTNC-2が出たのですから技術的に上ですね。

　また、TAPRは回路図をオープンにしてファーウエアを他社にライセンスしたため多数のメーカからクローンが発売されました。

　自社開発できたのはカントロニクスとエクスエラ位だと思います。

　しかしながら速度アップが最後までされず、1990年半ばにはこのメリットは皆無でした。

　現在の位置情報をデジタル情報で送信するAPRSはTNCの技術がそのまま使われています。

・エラー発生時の再送信

　RTTYは送りっぱなしで送信内容が壊れていてもどうしようもないのですが(但し逆に言えばいかに不利な状況でも確実に復調するかの技術力の発露、コンテストでの競技性がある)TNCはある程度は再送信して時間が少々かかっても送る内容の保証があります。

　当然ですが100%ではありませんが、耳で聞こえる程度なら何とかなるのは革命でした。

　これは無手順のパソコン通信では最後まで無かったので、文字化けのリスクはありました。

　インターネットプロトコルでは当然実装されています。

・デジピータ機能

　無線機とTNCを繋いで電源を入れっぱなしにしておくと、第三者が送信したデータを一度受信後オウム返しで再送信する機能です。

　時間がかかりますが山の上に置くと通信できる範囲が広がります。

　レピータと違って1波しか使わず、また同じ周波数に距離を置いて複数設置すると多段デジピートが可能です。

　私の住む倉敷から剣山＞和歌山＞名古屋の局と接続出来ました。

HFの到達距離とFMのローカルラグチュー的な部分が両方あるわけです。

接続する端末はパソコンは当然として当時はワープロ専用機が存在しましたが、エプソンのワードバンクノートというA4サイズの当時としては小型のワープロにTNC-μ21を外付けしたりNOTE-TNCを内蔵して移動運用、今のモバイル通信が出来ました。

さて、当時はQSO（普通の交信)相当のチャット以外に何に使ったのでしょうか。

丁度フロッピーディスクの普及によりある程度の大きさのファイルを保存できるようになったので、パソコン通信のホスト局に相当するものが現れました。

一般にRBBSと呼ばれます。

電子メールと掲示板、今のコミュニティ機能(パソコン通信的に言うSIGやフォーラム)です。

タスコ電機はここに目を付けてTNCにRBBS機能を内蔵してヒットさせました。

遠くまで電波の届くロケーションにあるRBBSは人気となり、アイボール大会(オフ)が開催されたりもしました。

山がちな地形の事情でデジピータ網が発達した3エリア(近畿地方)は後述する転送機能のあるRBBSとは距離を置いて、スタンドアロンの個性があるRBBSが末期まで主流でした。

やがて今のMastdonよろしくRBBS同士でメッセージの交換(同期)が出来るようになり、世界的な分散RBBSが存在するようになりました。

日本ではM.O RBBSが結構な勢力(作者が香川県にいるせいだと思われるが少なくとも岡山香川県では)でしたが、世界で一番大きなネットワークはFWD-NETです。

最初に開発したW0RLIが有名ですが、よりコンカレントになったMBL、圧縮転送や同時に複数人接続を実装したFBBが出てきたあたりがピークです。

これらを動かすためにわざわざPC/AT互換機を輸入した人もいたそうです。

国内にはまだ東芝J-3100位しか無い時代です。

JE4SMQ@JA4xxx(RBBSのコールサイン).JNET4.JPN.ASといった独特の電子メールアドレスで世界中とコンタクトが取れました。

メール到着時間は国内で数時間、アメリカだと1日程度です。

先の移動運用と組み合わせると今とやっていることは変わらないのが衝撃ですね!

Toフィールドという概念があって、本来は電子メールの宛先(P属性)に使うのですが、誰でも見えるB属性(フィールド)というのがあって、例えばCPUFMで富士通FMシリーズのパソコンについて話し合うなどある程度の決まりが出来てきました。

当然タスコのTNC内蔵RBBS機能も、よく使うRBBSのSYSOPへお願いすることで自動着信してLED点灯まで実現できていました。

FPMB等のオートパイロットを使うと送受両方出来ましたが、パソコンの電源を入れっぱなしにしないとだめでした。

なお、アマチュア無線は暗語の使用が禁止なので、個人用電子メールであっても送信されるパケットをワッチしたらまる見えだったので、そのあたりは良心に任されていました。

今で言うまとめサイト的なものは、CQ ham Radioの記事で毎号掲載されていました。

他、まだ商用インターネットが無い時代にIPパケットを飛ばすグループもいて、私もやっていましたがそちらは別のページを見て下さい。

画像フォーマットPRCGSについて

Packet Radio Computer Graphics System Version 3

FWD-NET PRCGSフィールドで開発されました。

インターネットに無いことはグーグルさんでも出てこないので、PRCGSについても正しい内容は見つからないはずです。

ましてやパソコン通信時代のログがほとんど残っていない事態同様、アマチュア無線のパケット通信もそれ自体で世界が完結していたため、意図的に残さない限り今後は消えゆくのみです。

PRCGS DATA Collection掲載内容

1993年当時の対応機種

コールサインは再割り当てされているため、現在同じ局がいても、同じ人とは限りません。

漏れや間違いがありましたらご容赦下さい。

閲覧対応

PC-8801用は社団局の構成員です。

データ作成対応

機種によって必要なファイルや機材があるので、機種名のみ記します。

FM-TOWS,X68000,PC-8801,PC-9801

作成データがあるのでPC88VAもあると思われますが未確認です。

歴史

最初のFM-TOWNS版作者のJF8WAV局による
※亡くなられていると聞いています R.I.P.

ハムフェアで頒布の小冊子(1993年)　前日に製本を手伝ったのはひみつ

1990-1994年までということになるでしょうか。

1995年はWindows95発売、インターネット元年になるので、FWD-NET自体が急激に衰退していき、21世紀までは持ちませんでした。

2000年問題もあったようですし。

CQ ham radio 1992年12月号JA3CF画像通信の連載記事に掲載されました。

技術的解説

仕様

当時はパソコンの画面サイズが最大でも640x400pixelと小さく、容量1MB程度のフロッピーディスク全盛でファイルサイズの制限が厳しかったことを前提に設計されています。

1.1×1から65536×65536pixel RGB各5ビット(32768色)カラーをサポート

　実験的な画像を除いて、多くの絵師が使ったのは320×200pixel 15ビットカラーでした。

　大部分の画像表示アプリはこの大きさのみサポートしています。

　解像度が高く発色数が少ない機種はディザリング等の技術で疑似多色表示を行っていました。

2.カラー、モノクロをサポート(モノクロは画像サイズ低減のため)

　モノクロも15ビットですが3/1程度のサイズになるのと独特の味があるので若干数あります。

　モノクロは作成できないアプリが多いです。

3.独自のPRCGS-Press可逆圧縮

　320x200pixel 24ビットカラ―のBMPが188kB程度のサイズになりますが、PRCGS化後は60-100kB程度です。

　色数が減っているとはいえ自然画でも1/2程度にはなります。

　JPEGにはかないませんが、そちらは非可逆圧縮ですから厳密には元の絵が破壊されています。

フォーマット

　128バイトのヘッダとそれ以後のデータ部分に分けられます。

ヘッダ

　0x00-0x07Fまでの128バイト

　今で言うメタデータ相当の実装があります。

　ファイル自体のタイムスタンプが変更されてもいつ作成か分かります。

　機種により実装のぶれがあるので、正確性の担保はしかねます。

本体部分

　0x80バイト目からの可変長です。

　原点は画面左上から右へX軸、下へY軸です。

　データはRプレーンで1画面、Gプレーンで1画面分、Bプレーンで1画面分で保存されています。

　現在のフレームバッファはRGBパックで並んでいるものが殆どなので、アプリ側で任意のドットの現在の表示色を取得できない場合は仮想VRAM用ワークメモリの確保が必要です。

　それが出来ない機種では外部ストレージにテンポラリファイルを作らないと実装出来ません。

　当時の機種はほぼ全てがデータ作成時メモリ不足になるため、テンポラリファイルを作るものが殆どです。

PRCGS-press（旧称NTN-ARC)について

　JN3NTNによる可逆インデックスランレングス圧縮です。

　原理

　以下の14バイトのデータを仮定します

　数字は実際は5bit(0-31)までの範囲を取りますが、説明上1桁にします。

　11114433366668

ランレングスは値と長さを列挙して圧縮します。

　上の例では1が4つ、4が2つ、3が3つ、6が4つ、8が1つなので、

　1442336481

　になります。

　これだけでも半分の長さになりますね。

　ここでよく出て来る長さの値を表にします。

　4が2回、3,2,1が各1回出ているのでインデックスとして、　

　これをヘッダ部分に保存します。

　そして、インデックスにある値（ここでは0-3迄の4種類)だけで並べると

　4321

　と、たったの4文字で終わってしまいます。

　実際の格納は、1バイトの上3ビットがインデックスで8種類、下5バイトが階調です

　複雑な処理ですね。

　インデックスが3ビットということは0-6の7種類の長さを記憶できます。

　インデックス7は0(1ドット)と決め打ちです。

　インデックスにある実際の長さの組み合わせで実際の長さを表現するのです。

　当然1ドットだけもありえるので、インデックス7(最後)は必ず0(1ドット)になります。

　ですので、実際の処理ではインデックスは0-7迄の8種類あります。

格納時にインデックスの小さい方が長い値を、インデックスが大きくなると小さい値を入れておくと探しやすそうですね。

　インデックスの中身は0オリジンなので、0-255:1-256までの値を入れることが出来ます。

　実際は255は境界値になるので、0-254(1-255ドット)の並びで実装しています。

　上記の例で長さ11ドット(10)があった場合は、

　a.11ドットをインデックス0番目の4ドットと比較して充分多いのでインデックスの中身が4ドット、つまり0番目の0を出力

　b.11ドットからaで格納した4ドットを引いたら残り7ドットなので、7とインデックス0番目の4を比較して充分大きいので、インデックスの中身が4、つまり0番目の0を出力

　c.7ドットからbで格納した4ドットを引いたら残り3ドットなので、3とインデックス0番目の4を比較すると、ちょっと大きいので次のインデックス1番の中身が3、つまり1番目の1を出力

　d.3ドットからcで格納した3ドットを引いたら残り0ドットなので、この値の処理は終了

　結果 11-4-4-3=0になるのでインデックスの値001の並びになります。

　さらに1文字減りました。

　インデックスの値を何にするかは元の絵を解析しないとだめなので結構難しいです。

　私が当時作ったARC.cは、長さと出現頻度の積が大きな値を採用するようにしています。

　真っ白な画像だと当然長さ最大値の254(255ドット)が連続するので0x1E決定なのですが、当てはまるのはテストパターンしか無いと思います。

　展開は簡単ですね

　a.1バイト読む

　b.上3ビットのインデックスとした5ビットの階調情報を取り出す

　c.インデックス値を元にヘッダにある表引きして実際の長さを取り出す

　d:画面の左上から長さ分だけ並べて表示する

　　もし画像のXサイズを越えたら次の行の先頭から、赤プレーン分埋まったら緑プレーン、青プレーンを埋めて、全部埋まったら終了

　フレームバッファから現在の色を取得できる場合は実装が楽ですが、それが出来ない場合はやっぱりメモリかテンポラリファイルのお世話になる必要があります。

　昔のパソコンは色を簡単に取得出来たので問題にはならなかったのですが、組み込みのSPI接続の液晶は結構面倒です。

　正直アニメ絵の様な線の太さが同じものはかなり小さくなりますが、色の変化が激しい、要は周波数の高い写真はあまり効かないです。

　JPEGはローパスフィルタで周波数の高い部分を削って小さくするので破たんがありえます。

　PRCGSは可逆圧縮で元のデータに戻せるので、解像度が低くてもかなりの密度で見えます。

まあべる本舗に戻る