テキスト画面圧縮手法（gettext3/puttext3 for Ｘ６８）

＊圧縮手法基本

Ｘ６８のようなテキスト画面もグラフィック形式の場合、１つの文字を表示するのに
１６バイトかかる。（８＊１６サイズの半角キャラクターの場合。）従って、これを
そのまま記録すると大量のメモリーが必要となる。そこで画面の圧縮記録が必要となる。

テキスト文字には縦方向に連続性が強い。すなわち縦に同じパターン（コード）が
続くことが多い。しかもこのパターンを画面上での出現数を調べると、非常に
片寄っていることがわかる。多くの場合、上位８もしくは１６種類で全体の９０％
以上となる。実験の結果、上位１６種をとったの方が一般的に圧縮率が高くなる
ようである。

また、文字は横８ドット＝１バイト＊縦１６ラインを基本としているので、
圧縮はまずバイト単位で縦１６ライン（＝バイト）を処理し、次にとなりのバイトへ
移動する。横方向の処理が終わったら次のテキストＹ行（＝１６ライン下）へ
移動する。
	(2)→横
   (1)	********
   ↓	********
  縦16	********
   ﾗｲﾝ	********
	
   (3)次のテキスト行へ

テキスト画面圧縮はこの規則を用いて行う。すなわち、よく出てくるコードはコードを
圧縮すると同時に長さも同時に記録する。出現頻度の低いコードはそのままもしくは
２バイトにして記録する。ただし、出現頻度の低いコードでも局所的に連続することが
あるので、その場合はランレングス圧縮する。

カラー対応は２プレーンのコードをＯＲしたものを記録すると共にその色を記録する。
従って２プレーンをそれぞれコード圧縮することはしない。色に関してはコード以上に
連続性が強いのでこれも圧縮する。圧縮方法は色はビット数が少ないのでコードの上位
コード圧縮と同じ方法をとる。なお、白と黒は両方とも２プレーンに書き込むことに
なるので同じとみなす。（画面上、白と黒の出現確率は高い上に両方を同じとみなす
のでさらに圧縮効率が上がる。）

以上のコードと色の圧縮の結果、通常のテキスト画面では１０％台まで圧縮可能で
ある。圧縮効率をこれ以上あげることも可能であるが、圧縮スピードとの兼ね合いから
ここで止めてある。


＊コード圧縮方法
コードはプレーン０／１をＯＲしたパターンで圧縮する。
現在の圧縮手法では、これは横１バイト内でプレーン０／１のパターンが
同じである（異なることはない）ということを前提にしている。
（これについて詳しくは色圧縮のところで述べる。）

上位コード１６種
	画面上に出現するパターンの上位１６種類多いもの順。
	多くの場合これで画面上の出現コードの９０％以上をカバー出来る。
	
	通常、上位８種よりも１６種の方が圧縮率が数％上がる。
	（１バイトで現されるコードの長さを増やすより圧縮対象にする
	コード数を増やした方がいいということ。）
	ただし、画面上のコードの出現パターンがきわめて片寄っている場合は
	上位８種の方が圧縮率が上がる場合もある。

圧縮コード
	BIT7=1	上位１６種コードの圧縮コード
	　BIT6,5,4,3	圧縮コード番号
			上位１６種の番号<<3
	　BIT2,1,0	コードの連続出現数
			1〜6	長さそのもの
			0	次の８ビットが長さ-7
			7	次の１６ビットが長さそのもの
				high/lowの順（680*0では展開時にこの方が早くなるため）

	BIT7=0	上位１６種以外のコード
	　$03〜$7f	コードそのものを１バイトで記録する。
	
	　$00,$00/$01/$02/$80〜$ff
			コードを識別子$00に続く１バイトに記録する。
			結局２バイトコードになる。
			画面上の出現コードは一般に>=$80より<=$7fの方が多いため
			このようにする。（多いコードが１バイトで表現出来るよう
			にする。）
	
	　$01,len,code			８ビット長ランレングス圧縮
	　$02,len-high,len-low,code	１６ビット長ランレングス圧縮
			コードが一定以上続くときそれをランレングス圧縮する。
			識別子、長さ、コードの順に記録する。
			１６ビットの時はhigh/lowの順。
			
			圧縮開始長さ基準
			　$03〜$7f（１バイト）			４以上
			　$00/$01/$02/$80〜$ff（２バイト）	２以上

	識別子コード選択に付いて
	　もしそのコードがよく出てくるコードなら上位コードに入るので通常コード
	  としては出てこなくなるのでいい。上位コードでないときは余り出てこない
	  コードだから別に２バイトになってもいい。一番いいのはBIT7=0のコードで
	  出現回数が一番少ないものから３つを使うことだが、コード可変にすると
	  高速化の点で不利になるのでやめた。
	　ある程度は圧縮率を重視するが、それ以上は速度を重視するのである。
	　それは連続識別子/BIT7=1コード圧縮や上位８／１６自動切り替えをやめた
	  理由でもある。


＊色圧縮方法

色はすべて圧縮される
	　BIT7,6,5,4	色
			１６色まで対応可能にしてあるが、現在はBIT5,4のみ使い
			４色しか処理していない。
			同時アクセスのアクティブプレーン指定ビットと同じとなる。
			（BIT5,4 : 11=黒、01=水色、10=黄色、11=白）
			色<<4
			ただし、白と黒は同じとされる。
	　BIT3〜0	色の連続出現数
			1〜15	長さそのもの
			0	次の８ビットが長さ-15
			15	次の１６ビットが長さそのもの
				high/lowの順

展開時にはコードは色情報に従ってプレーンに書き込まれる。
	色	黒／白	両プレーンにコードを書き込む
		水	プレーン０にコードを、プレーン１に０を書き込む
		黄	プレーン０に０をプレーン１にコードを書き込む

現在の色圧縮手法では横１バイトの中で色が変わる場合（プレーン０、１のパターン
が違う）には対応していない。これはコードではなく色の圧縮に処理を追加すれば
対処できるが、そのようなパターンはテキスト画面ではほとんどないと思われるので
現在は対応していない。


＊記録データ構造
メモリー内への記録はヘッダー部分とコード圧縮データ部分、色圧縮データ部分の
３つに分かれれる。圧縮データサイズは、圧縮を終了しなければ決定できない。
（これがこの圧縮ルーチンの最大の欠点である。）
ただし、仮想圧縮によりワークエリアサイズを算出する関数は用意している。

ヘッダー（２８バイト）
	名称		先頭	サイズ		補足
	wx		0	2	short	text座標幅
	wy		2	2	short	text座標幅
	size		4	4	int
	csize		8	4	int
	上位code表	12	16	JOUI	buff0
