* Tue Nov 19 12:30:00 JST 2002 Naoyuki Sawa

-----------------------------------------------------------------------------
高速RAMに転送するモジュールのアセンブラソース「clipfram.s」を作成するためのフォルダです。
なぜ「clipfram.c」のままでなく「clipfram.s」にしてからプロジェクトに追加したかというと、
高速RAMに転送するためには必ずサイズが4KB以下でなくてはならず、
リリースビルド/デバッグビルドによってサイズが変わっては困るからです。
（実際、デバッグビルドではとてもじゃないけど4KBには収まりません。）

「clipfram.s」を作成するための手順は次のとおりです。

1.	このフォルダの「clipfram.c」を修正します。
2.	「make」とタイプすると、「clipfram.s」ができます。
3.	「clipfram.s」を手修正でさらに最適化します。(必須ではありません)
4.	「make install」とタイプすると、「clipfram.s」が上位フォルダにコピーされます。

以上です。

→2002/11/19 19:00現在、手修正の部分はsedスクリプト(clipfram.sed)で行っています。

-----------------------------------------------------------------------------
注意！

モジュールサイズが4KBを超えないように注意！
いまのところ、プログラム上では誰もサイズチェックを行っていません。
アプリケーションリンク時のmapファイルでチェックしてください。

0010ab54    00001000    00000d8c    clipfram.o                     0   REL
                        ~~~~~~~~
                        これが1000以下であること！

→2002/11/19 21:13 app_init()で高速RAMへ転送する前にサイズチェックを追加しました。

-----------------------------------------------------------------------------
注意！

「make」する前に今ある「clipfram.s」のバックアップを忘れずに！
「clipfram.c」をコンパイルしてできた「clipfram.s」そのままならいつでも作れますが、
手順3.で手修正した「clipfram.s」をうっかり上書きしてしまうと大変です。

一応、makeスクリプトによって、一世代だけのバックアップが作成されます。
「make」したときにあった「clipfram.s」は、「clipfram.s.bak」に保存されます。
二世代以上の保存は行われません！
また、「make clean」を行うと「clipfram.s.bak」も消去されます。

→2002/11/19 19:00現在、手修正の部分はsedスクリプト(clipfram.sed)で行っています。

-----------------------------------------------------------------------------
clipfram.cのnew_LCDDrawObject()は、高速RAMに置くためのメモリ節約(5KB->3KB)のために、
かなり高速化が弱くなっています。
2bitマスクなしビットマップの8ピクセル境界転送の最適化が省略され、
また、コード展開もかなり弱くなっています。
高速RAMに転送せずに使うならば、2002/11/18以前のバージョンの方が高速です。
	clip\keep\高速RAM改造前の安定コード保存\clipdobj.c
に旧いバージョンを残してありますので、参照してください。

P/ECE MOD Driverについては特に変更点はありませんが、
コードがあちこちに分散したため、保守性が悪くなっています。
一つのモジュールにまとまった形態として、
	clip\keep\高速RAM改造前の安定コード保存\clipmod.c
に旧いバージョンを残してありますので、参照してください。
ただし、P/ECE MOD Driverについては今後機能拡張を行う予定ですので、
旧いバージョンとは機能的な違いが出てくる可能性が高いです。

-----------------------------------------------------------------------------
2002/11/19 18:30

render_font()をclippce.cからclipfram.cに移しました。
フレームフォントの描画などで、render_font()の遅さが問題になっていたので、
render_font()が高速RAMに移ったことによる効果はかなりあります。
特にフレームフォントの描画を多用するアプリケーションで顕著です。

clipfram.cにrender_font()を追加したことによって、
clipfram.cモジュールのサイズが、なんと、ぴったり4KB(!)になりました。
もう、MODドライバの未実装エフェクトを実装することもできません(^^;

-----------------------------------------------------------------------------
2002/12/08 05:43

1)
mod_mix()のループ音バグを修正しました。
これまで、ループ音は

       0        repofs      repofs+replen  length
       |==========|===============|==========|
一周目 |------------------------------------>|
二周目 |          --------------->           |
三周目 |          --------------->           |
  ・
  ・
  ・

と再生していましたが、これは間違いでした。正しくはこうです。

       0        repofs      repofs+replen  length
       |==========|===============|==========|
一周目 |------------------------->           |
二周目 |          --------------->           |
三周目 |          --------------->           |
  ・
  ・
  ・

つまりループ音では、(repofs+replen)〜(length)の区間は絶対に再生されません。
無駄なデータです。
自分でMODデータを作る場合は、メモリ・ファイル容量節約のために、
ループ音のループ区間以降の音はトラッカー上で切り取っておくようにしましょう。

2)
また、ループ音かループ音でないかの判定を少し修正しました。
これまでは、replen=0が非ループ音、replen>0がループ音と判断していましたが、
正しくは、replen=0or1が非ループ音、replen>1がループ音でした。
なぜreplen=1が非ループ音なのか不思議ですが、アミガ依存の歴史的な理由(？)みたいです。

3)
以上の修正を行ったことにより、モジュールサイズが(4KB-32バイト)程度に減りました。
この空き容量を使って、テンポエフェクトを(Fxx,xx=0x20〜)を組み込む予定です。

-----------------------------------------------------------------------------
2002/12/08 06:26

テンポ対応を行いました。モジュールサイズは(4KB-8バイト)となりました。

テンポ対応により、MODDRIVER.tick変数の解釈が少し変わりました。
これまで、MODDRIVER.tickは次のように変化していました。

speed=4の場合:
	tick
	0
	1
	2
	3
	4->0 ... 次のローを処理
	   1
	   2
	   3
	   4->0 ... 次のローを処理

今回より、MODDRIVER.tickは次のように変化します。

speed=4、tempo=110の場合:
	tick
	0
	110
	220
	330
	440
	550-> 50 ... 次のローを処理
	     160
	     270
	     380
	     490
	     600 -> 100 ... 次のローを処理

これまでと較べてtickの値は常に125倍で表され、(tick%125)を小数部と見なします。
speedはこれまでと同じくオーバーフロー比較値を表しますが、これも125倍してspeed*125で比較します。
上の例ではspeed=4なので、4*125=500に達したときにオーバーフローと見なして次のローを処理します。
tempoはtickの増分です。
このように、speedとtickを組み合わせて全体の速度を決定するのが、MODの仕様だそうです。

-----------------------------------------------------------------------------
2003/1/31 21:57

new_LCDDrawObject()のPIXEL(p,m)マクロのmask判定部分を改良。
「(mask >> (m) & 1)」→「(mask & (1 << (m)))」に変更しました。
約3%高速化(全画面転送時)、コードサイズは20バイト少なくなりました。

なぜこれで高速化になるかというと、m=7〜0それぞれの場合について
「(mask >> (m) & 1)」：
	m=7	ld.ub %r0,[%r1]; srl %r0,7;            jreq ...		3op/3byte
	m=6	ld.ub %r0,[%r1]; srl %r0,6; and %r0,1; jreq ...		4op/4byte
	m=5	ld.ub %r0,[%r1]; srl %r0,6; and %r0,1; jreq ...		4op/4byte
	m=4	ld.ub %r0,[%r1]; srl %r0,6; and %r0,1; jreq ...		4op/4byte
	m=3	ld.ub %r0,[%r1]; srl %r0,6; and %r0,1; jreq ...		4op/4byte
	m=2	ld.ub %r0,[%r1]; srl %r0,6; and %r0,1; jreq ...		4op/4byte
	m=1	ld.ub %r0,[%r1]; srl %r0,6; and %r0,1; jreq ...		4op/4byte
	m=0	ld.ub %r0,[%r1]; srl %r0,6; and %r0,1; jreq ...		4op/4byte
「(mask & (1 << (m)))」：
	m=7	ld.ub %r0,[%r1]; ext 0x80@m; and %r0,0x80@l; jreq ...	4op/4byte
	m=6	ld.ub %r0,[%r1]; ext 0x40@m; and %r0,0x40@l; jreq ...	4op/4byte
	m=5	ld.ub %r0,[%r1];             and %r0,0x20  ; jreq ...	3op/3byte
	m=4	ld.ub %r0,[%r1];             and %r0,0x10  ; jreq ...	3op/3byte
	m=3	ld.ub %r0,[%r1];             and %r0,0x08  ; jreq ...	3op/3byte
	m=2	ld.ub %r0,[%r1];             and %r0,0x04  ; jreq ...	3op/3byte
	m=1	ld.ub %r0,[%r1];             and %r0,0x02  ; jreq ...	3op/3byte
	m=0	ld.ub %r0,[%r1];             and %r0,0x01  ; jreq ...	3op/3byte
となるからです。
m=7〜0で5バイトの節約になり、これが4回(XY反転有無の組み合わせ)あるので、合計20バイトの節約です。

本当は、m=7の場合のみ「(mask >> (m) & 1)」の方法を使った方が速く・小さくなるのですが、
メンテナンス性との兼ね合いで、ここらで妥協することにしました。

※「ryukの薫製工房」さん(http://www.interq.or.jp/earth/ryuk/)による改良を利用させて頂きました。
　ありがとうございます。

-----------------------------------------------------------------------------
2003/1/31 21:57

new_LCDDrawObject()のクリッピング時画面外判定処理を改良。
これまで、反転なし/ありそれぞれの処理の中で行っていたものを、共通化してまとめました。
コードサイズが4バイト少なくなりました。

以上の変更を行った結果、現時点のコードサイズは0xfe0(4064)バイトです。

-----------------------------------------------------------------------------
2003/2/1 14:55

new_LCDDrawObject()にて、残りライン数の取得「y = obj.dh」を共通化し、容量節約しました。

-----------------------------------------------------------------------------
2003/2/1 14:55

MODドライバを可変チャネル数に対応しました。

一時的なミキシングバッファが32ビットになったので、(MOD仕様外ですが)64以上のボリュームも指定可能です。
ただし、(ファイン)ボリュームスライドを使うと、既定の最大ボリューム値64にクリッピングされてしまうので、
64以上のボリュームを使う場合は、そのチャネルでは(ファイン)ボリュームスライドを使わないで下さい。

容量削減のため、エフェクト処理部分であらかじめエフェクトデータを4ビットづつに分解するようにしました。
（mod_seq()のeff_ff,eff_f0,eff_0f変数です）
多少、速度が犠牲になりますが、これをしないとコードサイズが4KBを超えてしまうため、やむをえません。

以上の変更により、現在のコードサイズは0xfe4(4068)バイトです。

-----------------------------------------------------------------------------
