TAB:4,WIDTH:80
===========================================
    PC6001VW  -PC6001V for Win32-
      ＆  AllegroDLL for PC6001VW
            SR対応版更新履歴
===========================================


==============================================================================
■2009.04.08 ver 205d4
	・SAVEテープを新規に作成するとファイル名の頭の一文字が欠けた状態で作成
	  されてしまっていた不具合を修正。

	・サウンドOFFの状態でエミュレータを起動してテープロードを行ったとき、
	  テープリードが進行しなかった不具合を修正。
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	相当前に修正を行ったのだが、後日、その修正内容(サウンドがOFFなのに
	テープ音のストリームバッファを作っていた)をバグと判断して、
	再修正してしまった模様…(^^;;;;;;ﾅﾆﾔｯﾃﾝﾀﾞ
	再度、サウンドOFFでもテープ音のストリームバッファを作るようにした。
	内容を忘れないよう、ソースに詳細コメントをつけておくぞ〜。

==============================================================================
■2009.03.19 ver 205d3
	・SR機種以外からYM2203のI/Oポートを除外。
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	mkII,6601にI/O(A3H)が実装されていて、SRとの機種判別に使用できなく
	なっていたのでI/Oテーブルから削除した。
==============================================================================
■2009.03.15 ver 205d2
	・1DD/2Dの判別ロジック追加。
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	連続トラックテーブルが検知されたとき、トラック2-セクタ1のヘッダポジションを
	チェックし、ポジションが1だったら(裏面のトラックだったら)2Dディスクと
	判別して、トラックテーブルを1スキップずつアクセスするようにする。
==============================================================================
■2009.03.15 ver 205d1
	・例外番号セクタのアクセスに対応。
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	市販ソフトのプロテクトの仕組みとして、16以上のセクタ番号が設定されて
	ディスクアクセスが行われることがある。
	通常、物理ディスクからディスクイメージに置き換えられた時点で異常番号
	セクタへのアクセスは不可能になるのだが、ツールによってはD88イメージを
	作る時点で物理ディスクの異常セクタ情報もイメージに忠実に取り込んで
	くれるとの事。
	エミュレータでは今まで異常セクタ番号でアクセスが行われた場合、16以下の
	数値になるように調整を行っていたのだが、この調整を行わないように修正。

	・その他、バグフィクス。
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	メニューから[かな]の入力切り替えを行ったとき、システムがリセットされてしまう
	不具合を修正。
	EXT-ROMが実装されていない状態のとき、メニューからMEGA-ROMタイプが変更出来て
	しまう不具合を修正。(EXT-ROMが無いときは必ずOFFに初期化する)
==============================================================================
■2009.03.13 ver 205d
	・2Dメディアの取扱いを中止。
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	一部メディア変換ツールにて1DディスクイメージからD88イメージを作成した時、
	トラックデータは裏面が存在しない状態で書き込まれているにもかかわらず、
	トラックの登録テーブルだけ表裏連続で書かれているメディアが作られる。
	エミュレータ内部では、そういう奇妙なメディアは似非2Dと称して、
	トラックテーブルが表裏連続出存在するメディアはトラックテーブルを
	2Dディスクとしてアクセス出来るようにしていた。
	しかし、これだと本物の2Dメディアを使っているにも関わらず1Dメディアとして
	アクセスさせたいソフト(例：プラズマライン)では普通に2Dメディアとして
	アクセスが行われてしまい、意図したトラックのデータが取得できない。
	そこで本改修ではトラックテーブルの2D対応を取りやめて、テーブルが表裏連続で
	書かれていても表面のテーブル(奇数番号トラック)にしかアクセスさせない
	ように修正した。(文章で説明するの難しいなあ。)

	奇妙な仕様の2Dイメージは非対応になったので悪しからずご了承下さい(笑。


	・D88ヘッダのディスクサイズ情報が 0 になっているとき、実ファイルサイズを
	ディスクサイズとして扱うように修正。
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	エミュレータにマウントされたディスクの形式チェックを行うとき、ディスク
	サイズ情報がトラック数に満たないとき、D88ディスクでは無いと判断して
	ベタディスク扱いされていた。ところが、変換ツールによってはD88ヘッダの
	ディスクサイズ情報を書き込まないものもあるので、このD88サイズチェック
	だけは無効化しておく。

■2009.03.12 ver 205d
	・拡張ROMが実装されていない状態でも、MEGA-ROMマッピングタイプが有効状態に
	なっていた不具合を修正。
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	例えば戦士のMEGA-ROMタイプが有効になっていると、EXT-ROMが無いにも
	関わらずメモリマッピングが戦士タイプで変化してしまい、BASIC-ROMが
	出てこなくなっていた。エミュ起動時、拡張ROMが設定されていなかったら
	MEGA-ROMタイプをノーマル状態にリセットするように修正。
==============================================================================
■2008.07.02 ver 205c
	・初代機以外の機種で使用しているとき、「メガロム使用中に"どこでもセーブ"で
	保存したデータ」をロードするとメガロムのバンク切替が0ページに初期化されて
	しまう不具合を修正。
==============================================================================
■2008.04.04 ver 205b
	・SR機種を選択して、解像度:640x480・スキャンラインありの設定でシステムが
	  起動しているとき、リセットを行うとスキャンラインが解除されてしまう
	  不具合を修正。
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	SRは画面モードが多彩なので、リセット時に解像度の再変更が行われるのだが
	そのとき 320x240 が一瞬選択され、スキャンラインが自動解除される状態に
	なっていた。
==============================================================================
■2008.02.13 ver 205a
	・初代機を使用したときのモニタ画面のメモリバンク表示がmkII以降の
	  表記になっていた不具合を修正。

==============================================================================
■2008.02.01 ver 205
	・西田ラヂオさん謹製メガロム(2タイプ)に対応。
	・メガロムタイプ切り替えのメニュー項目追加。
	・モニタ画面に(BC)(DE)(HL)(IX)(IY)(SP)の内容表示追加。

==============================================================================
■2005.12.25 ver 204b
	・Allegro ver 4.2 がリリースされているので、乗り換えようと思って試しに
	移行してみたところ、仕様が随分変わっていてマトモに動作しない。
	Allegroに見切りをつける時期かも…。
==============================================================================
■2005.11.25 ver 204a  bugfix
	・デスクトップ解像度チェックで幅と高さを逆に判定していた不具合を修正。

==============================================================================
■2005.11.23 ver 204
	・Desktopの解像度よりもエミュレータのWindowサイズが大きくなる場合(例えば
	640x480のデスクトップ解像度でモニタモードを使おうとした等…)の障害系処理を
	実装。

	・どこでもロードでPSG2SCCのパラメタが復帰できない不具合を修正。

■2005.11.18 ver 204
	・PSG2SCC デチューンをチャンネル毎に強度設定できるよう修正。


■2005.11.16 ver 204
	・PSG2SCC のデチューン幅を調整出来るように修正。
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	標準 0.5%幅 固定では少し融通が利かなかったので…。
	でも、後々の仕様変更の事を考えるとチャンネル毎に強度設定できた方が
	良いのかもしれないなぁ。仕様を試行錯誤できるのもテスト中の今だけだし…。
	リリースしてから仕様変更ってのは望ましくない。


■2005.11.06 ver 204
	・PSG2SCCでノイズチャンネルをPSGに切り替える仕様は取りやめ。
	PSG2SCCチャンネルはSCC波形にノイズを反映させるようにする。
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	スペハリの様にSTICK読み込みで常時 PSG_ENABLE (SOUND 6,xx) を変更しまくる
	ソフト(オマケにBIOSのバグでNOISEとENABLEが断続的にON/OFFする)の場合、
	ノイズ時にPSGに切り替えると波形が寸断されまくって滅茶苦茶な音に
	なってしまうので、ノイズをPSGに任せるのは止め止め (;´Д｀)。
	直接、SCC波形にPSGのノイズ出力を乗っけてしまう。
	まぁ、形の変化するサンプリング波形にノイズが重なるわけだからPSGみたいな
	綺麗な音にならないんだけど…こればかりは仕方ない。


■2005.11.05 ver 204
	・SCC出力を擬似ステレオモードのPANに対応。
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	因みにデチューン効果は親チャンネルと同じPAN位置について来る。


	・PSG2SCCの状態でチャンネルにノイズが設定されたとき、SCCを解除して
	PSGに切り替えるように仕様変更。
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	ここでPSGとSCCの出力交換で色々障害を起した事象についてメモ。

	1.音量
	PSGは周波数が設定されていなくても音量があると耳に聞こえないフラットな
	波が出力されているので、PSGからSCCに音を変更する際、PSGの波形を無効に
	設定するだけではSCC波形に無用な音量のゲタを履かせて音割れや破断ノイズの
	原因になるので、使わないチャンネルは必ずボリュームを落とすようにする。
	(SCCは符号付波形でPSGは符号無しなので、ゼロクロスで波形を中央に持って行く
	よう処理しているとはいえ、特に正の値でオーバーレンジが発生しやすい。)

	2.周波数
	上で述べたように、周波数が無効状態になっていても音量は出力され、他の音源と
	合わさるとノイズの原因となる。かといって、周波数無効時に音量を出力しない
	ようにしてしまうと、フラットノイズ効果や瞬間的にボリュームの上げ下げを
	行うクリック音が出力されなくなる。他にハードエンベロープを使った特殊波形
	出力も使えなくなる。特殊波形出力とは、周波数を設定せずにハードエンベロープの
	音量上げ下げを音階周波数と見なして三角波やノコギリ波を出すという
	エンジンやモーターの効果音に良く使われる例のアレ。

※特殊波形の例…
10 CLS:CLEAR:DIM T(4)
20 FOR I=0 TO 3:READ T(I):NEXT
30 DATA 8,10,12,14
40 SOUND 7,&H3E
50 SOUND 8,&H10
70 SOUND 12,0:SOUND 11,0
60 SOUND 0,0:SOUND 1,0
80 FOR K=0 TO 3
90 SOUND 13,T(K)
100 LOCATE0,0:PRINT "ENV"T(K);":";
110 FOR I=255 TO 1 STEP -1
120 SOUND 11,I
130 LOCATE7,0:PRINT I;"  ";
140 NEXT I,K:SOUND 8,0

	3.ノイズ
	PSG_ENABLEでチャンネル出力が切ってあっても、チャンネルノイズフラグが
	立っていると、音階に乗らない音量幅のホワイトノイズが出続ける。
	NOISE設定が全チャンネル切られるとノイズ生成がストップし、再度、NOISEが
	有効になった時にはノイズ生成の周期がリセットされて再スタート。



■2005.11.03 ver 204
	・SCCポートを io_78H 以降 に移動。
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	今まではPSG2SCCのスイッチが入っているときのみMSX互換のやり方でポートを
	操作出来るようにしていたのだけど(メモリバンクで0x9800〜にSCCレジスタを展開)、
	まぁ、無理がある(笑。
	一々フラグを切替ながらアクセスする必要が生じてしまいどうにもこうにも…。
	そこでSCC専用ポートを独立させ、P6にSCCカートリッジを取り付けたような形に変更。
	実際、物理的にP6実機にSCCカートリッジを接続できるのかどうかは判らないけど、
	元はMSXだしやって出来ない事は無いんだろうなぁ…(*´∀｀)


	・コンテキストメニュー上で仮名と片仮名が同時に選択できる様になっていた
	不具合を修正。


■2005.10.31 ver 204
	・PSG2FM と PSG2SCC で使えるチャンネルオクターブ調整機能を追加。
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	PSGの曲をFM/SCCで鳴らすときに問題になるのが聴こえる音の高さの違い。
	PSG/FM/SCC、三者三様音質が異なるから、PSGを基準にオクターブ設定すると、
	他の音源に移行したとき単純に周波数を移行させるだけでは耳で聞いた時の
	メロディーラインの高さが違う。
	そこでチャンネル毎にオクターブを上げ下げ調整出来るポートの誕生ですヨ。

	さぁ、SCCマニアのMSXer諸君。AY8910+YM2203+SCC という未知の領域(謎)に
	足を踏み入れてみないか？( ･∀･)ﾅﾝﾀﾞｿﾘｬ
	オークションで安値のP6をゲットして、君もP6ユーザーになろう。

	( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ /  ＼  /    ＼ 


■2005.10.30 ver 204
■2005.10.29 ver 204
	・唐突に PSG to SCC 変換出力機能実装。(PSG2SCC ポート)
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	グランゼル(弟)帰省中、FM音源音色エディットは専用のツールを使っても難しい
	云々との話題の最中、『SCCならWSG(昔のnamco音源)と同じ音になるけど。』
	の一言でスイッチオ━━━━━━(ﾟ∀ﾟ)━━━━━━ン!!!!!
	試しにI/Oポートこさえてチョロっと矩形波を鳴る様にしてみたところ、
	コレが (･∀･)イイ!!!!! 実に (･∀･)イイ!!!!!!!!!!
	SCCサイコー!!!! グラ2サイコー!!!!!! (昔の)573サイコーーー!!!!!!!
	(;´Д｀)ハァハァハァハァハァハァハァハァハァハァハァハァハァハァハァハァ
	ハァハァハァハァハァハァハァハァハァハァハァハァハァハァハァハァハァハァ
	ハァハァハァハァハァハァハァハァハァハァハァハァハァハァハァハァハァハァ
	ハァハァハァハァハァハァハァハァハァハァハァハァハァハァハァハァハァハァ

	………思わず取り乱してしまいましたが………(アホか)

	グランゼルにWSGっぽい音色を作ってもらい、某どるるるrrrとMAPPYで
	試してみたところ、余りのガガガ音の素晴らしさに思わず失禁 Σ(ﾟДﾟ;)…(嘘)
	そこで、本腰入れて様々な調整ポートまで整備してしまいましたとさ。
	メデタシメデタシ。

	因みに、SCC音源はFM音源と比べてかなり動作が軽いので、FMカートリッジ
	オプションをOFFにした状態でPSG2SCCエフェクトを使えば、Pen2-300の様な
	非力なマシンでも BUSREQ_OFF でフレームスキップ無しの動作が可能。
	しかも、SR-BASICではPLAY文から OPN+SCC+PSG の組み合わせが扱えて鼻血モノ。
	ただし、BASICのMML上では [OPN]=3ch、[SCC+PSG]=3ch となる。拡張I/Oポートを
	直接叩けば [OPN]=3ch、[PSG]=3ch、[SCC]=5ch でも行けますか？(*´∀｀)
	デチューンOPTIONで自動的に重ねられる音も数えると [SCC]:10ch (笑。

	やっと実機SRユーザーも得するエミュレータ特典が見えてきましたよ、奥さん！



	しっかし、いったいどこまで暴走するのか、P6VW？…(;´∀｀)
	余りにも雑然としたサウンドのソースを見て、そんな事思ったりして…。
	まぁ、深くは考えまい。エミュレータなんて、弄って遊べてナンボなのです。


■2005.10.26 ver 204
	・エミュレータ上でDISK書込を行った際、タイミングを見て仮想ディスクから
	実ディスクイメージに内容を反映させるように修正。
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	今までは、エミュレータ起動時に実ディスクイメージファイルをメモリに
	読み込んで仮想イメージ化しておいて、実行中はその仮想イメージに対して
	データの読み書きを行い、エミュ終了時にWRITEが行われていた場合のみ
	ディスクイメージファイルに内容を反映させるといった動作だった。

	これはエミュレータがメディアイメージをオープンしたまま占有してしまうと、
	エミュで動作確認しながらディスク起動IPLを修正したり、テスト用イメージを
	コピーして作成するといった、外からのメディアイメージ操作が出来なく
	なってしまうので、これを避ける為にこういった仕組みになっている。

	ところが現方式では、折角エミュレータ上からディスクに情報を書き込んでも
	何らかの弾みでOSがフリーズしたとか、エミュが固まったなどの状況に陥ると
	同時にDISKに書いた情報も消失してしまい、不安定な実行環境では危険を伴う。

	そこで今回、一応の安全策としてディスクアクセスでデータの書込作業が
	行われた後、暫くしてFDDのモーターがSLEEPに切り替わる時にディスクの
	内容変更フラグが立っていたら実イメージファイルを開いて仮想イメージの
	内容を反映させ、その場ですぐに解放するという作業を行っている。
	これならエミュにディスクが占有される事も無いし、多少は安心できるし
	ある意味一石二鳥だ。

	※ここで言うFDDのSLEEPってのは、カッコンカッコンとディスクアクセスの
	効果音を鳴らす際にモーター始動音を鳴らすかどうか判別させるために
	常にディスクアクセスの待機時間をカウントしているので、それを
	ついでに利用したということですね (bﾟ∀ﾟ) Good.



■2005.10.29 ver 204
	・SR機種でDISKの自動起動が行われたときに、特定の環境下で例外エラーが
	発生する不具合を修正。
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	WinXpSP2の環境でDISK起動で落ちるという報告有り。
	調査を行ってみたけど、自分のPCにインストされているOS環境下(98,Me,2000)では
	全く問題なし。同じ XpSP2 のOSを使っていても、他の人のPCでは落ちないとの事。

	さすれば特定環境下の問題ということになるので、様々なタイプのデバッグログ
	出力版実行ファイルを作ってログの提供を受けて解析。
	最初はDISKイメージを扱う関数で障害が起こっているのかと思いきや、ログの
	出力情報を細かく絞り込むに、DISK関係では無いことが判明。

	今度はI/OポートからVRAM描画まで範囲を広げてログ出力で追いかけてみたところ、
	どうもある時点で画面描画を行おうとしたときに、機種モードと画面モードの
	噛み合せがズレた瞬間に1/60[sec]画面更新でVRAM描画が入り込んでくると
	例外エラーが発生するみたいだ。
	具体的に言うと、画面モードがN60モードのまま、システムの実行モードがSRモード
	に切替わった時、320x204 のSR専用画面に 256x192 N60モードのセミグラ画面を
	描こうとしてメモリのオーバーフローが発生している。

	実はこのタイミング、画面モードがN60に切り替えられてその直後に動作モードが
	非SRモードに移行する、OUT(0xC1) と OUT(0xC8) 命令の間、ここに偶然画面描画
	が入って来て規定外描画が行われるという、まさに神業的ピンポイント攻撃！
	イタタタ、深いなぁ…(汗。

	と、ここで、何故、他のPCでは同条件で動かしても問題が起こらないのか疑問を
	検証。PCで使用しているビデオカードによっては確保したメモリから多少はみ出て
	アクセスしてもエラーを出さないモノがある。それに加え、このピンポイントの
	タイミングで描画が挟まって来たのは、オプションのCPU_SPEED の設定値が
	昔のバージョンのエミュのデフォルト設定値 69% のまま継続されていたことで、
	他の人とタイミングの違いが生じていたという理由もある。
	因みに、現在は CPU_SPEED、TIMER_SPEED、共に100%で実機と同程度の体感速度に
	なるよう調整されているので、昔の設定値のままになっている場合は 100% に
	直して貰うことが望ましいです（ ´∀｀）。


==============================================================================
■2005.10.16 ver 203a
	・P6Tのテープ自動起動がSR機種でも行われるように修正。
	SR-BASICの自動起動もP6Tの起動設定を MODE:6 にすれば可能。
	今のところP6Tツールが対応していないので、バイナリエディタでチョロっと加工。

	P6toP6T2 でも対応させないといけないなぁ…。

■2005.10.11 ver 203a
	・知っている人は知っている、知らない人は知らないと思うので
	SR のFDについての個人的メモ書きを転載。

[[ SRマシンでの FLOPPY-DISK 自動実行のマメ知識 ]]

	ディスクの先頭(TRACK:0,SECTOR:0)に任意のIDバイナリを書き込んでおくと、
	システムはこのセクタ(256byte)を特定アドレスに読み込んで IDのすぐ後ろの
	番地から実行してくれます。

===============================================================================
0000 525852    DB "RXR"     ;N66モードで1DD(SR用)-FDを扱いたい時のID。
;-----------------------------
0003 3E21      LD A,21H     ;自動入力したい文字数
0005 3232FA    LD (FA32H),A
0008 21DAFE    LD HL,FEDAH
000B 228DFB    LD (FB8DH),HL
000E 3E04      LD A,04H
0010 324EFF    LD (FF4EH),A
0013 EB        EX DE,HL
0014 2120F9    LD HL,F920H
0017 012800    LD BC,0028H  ;コマンドライン転送量(自動入力文字数より多めに)
001A EDB0      LDIR
001C C9        RET
001D 000000    DB 0,0,0     ;ALIGN
;--------------------------- 以下、自動入力文字列
0020 20300D
               DB " 0",CRLF ;How Many Files? の入力値
0023 20320D
               DB " 2",CRLF ;How Many Pages? の入力値
0026 52554E22746573743031220D
               DB "RUN",22H,"test01",22H,0DH  ;実行コマンド

===============================================================================
0000 535953    DB "SYS"     ;N66モードで1D(mkII/66互換)-FDを扱いたい時のID。
;-----------------------------
0003 3E21      LD A,21H     ;自動入力したい文字数
0005 3232FA    LD (FA32H),A
0008 21DAFE    LD HL,FEDAH
000B 228DFB    LD (FB8DH),HL
000E 3E04      LD A,04H
0010 324EFF    LD (FF4EH),A
0013 EB        EX DE,HL
0014 2120F9    LD HL,F920H
0017 012800    LD BC,0028H  ;コマンドライン転送量(自動入力文字数より多めに)
001A EDB0      LDIR
001C C9        RET
001D 000000    DB 0,0,0     ;ALIGN
;--------------------------- 以下、自動入力文字列
0020 20300D    
               DB " 0",CRLF ;How Many Files? の入力値
0023 20320D    
               DB " 2",CRLF ;How Many Pages? の入力値
                            ;どうして頭に空白が入っているかというと
                            ;画面表示の時間稼ぎの為なんだな、これが。
0026 52554E22746573743032220D
               DB "RUN",22H,"test02",22H,0DH  ;実行コマンド

===============================================================================
0000 49504C    DB "IPL"       ;N66SRモードで1DD-FDを扱う時のID。
;-----------------------------
0003 3E0D      LD A,0DH       ;自動入力したい文字数
0005 32D3E6    LD (E6D3H),A
0008 218FE9    LD HL,E98FH
000B 22CEE8    LD (E8CEH),HL
000E EB        EX DE,HL
000F 2120C0    LD HL,C020H
0012 011000    LD BC,0010H    ;コマンドライン転送量(自動入力文字数より多めに)
0015 EDB0      LDIR
0017 3E00      LD A,00H       ;How Many Files? の設定値
0019 C9        RET
001A 000000000000
               DB 0,0,0,0,0,0 ;ALIGN
;----------------------------- 以下、自動入力文字列
0020 52554E22746573743033220D
               DB "RUN",22H,"test03",22H,0DH  ;実行コマンド

===============================================================================

	因みにこの戦闘セクタ、 N66モードの時は 0F900H に読み込まれ、
	N66SRモードの時は 0C000H に読み込まれて実行されます。

	[補足]
	  N66SR-BASIC で1D-FDの自動実行は出来ない。
	  ただし、マシン語による特定操作により1D-FDのセクタを読み込む事は可能。
	  といってもハード的な部分に寄るので、BASIC上で FILES や LOAD が出来る
	  ようになったりするわけではない。
	  エミュ上では、1D/1DD(片面/両面)の区別は単なるセクタ並びの違いとして
	  認識しているので、FDDのハード的な操作は余り関係が無い。


■2005.10.10 ver 203a
	・ベタテープイメージのロード時、TAPE_CLOSE せずに立て続けに TAPE_OPEN が
	実行されるとCMT割込が発生しなくなる不具合を修正。
	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
	I/Oバイナリ形式のテープ読込が上手く行かないという報告アリ。
	そういえば以前のバージョンで実機のスピードに近づけるためにCPUの駆動率を
	かなり下げる事になったので、もしかしてCMT割込のデータを取りこぼすケースが
	増えてきたのかと思い、CMT割込発生とRAMへのデータ書込両方にデバグ出力を
	仕掛けて、どの辺りで取りこぼしが起こるのか確認したところ、どうもマシン語
	のファイル名を読み取った後にCMT割込自体出なくなっているようだ。 
	ナンデダロ？

	割込発生箇所を見ると、２回目の同期頭出しスタート後も割込抑制フラグが
	立ったまま。要するにテープ読出が始まっていないと判断されている。
	PIOのアセンブラローダーを読んでみると、どうやらマシン語ヘッダを
	読み込んだあと、TAPE_CLOSE を行わずに再度 TAPE_OPEN を行っている。
	では割込解禁のトリガーは何かというと…モーター停止とピー音。ピー音？
	そういえば、以前 テープ読込を高速化した際、データブロックの区切りで
	CPUが何か処理をやっている内に勝手にテープが進まないよう割込フラグ以外の
	二重抑制の仕組みを作ったんだっけ…(;ﾟДﾟ)。
	P6T形式では確実にピー音制御を行うから割込抑制管理が二重に行われても
	上手く行っていたけど、ベタ形式だと明確なデータ区切りが存在しないから
	プログラム側から働きかけない限りモータ停止が行われない…。
	テープイメージは殆どP6Tに変換してしまったから今まで気付かなかった(汗。
	というわけで、TAPE_CLOSE が来なくても TAPE_OPEN が来た時点で、
	割込抑制を解除するように修正して一応の解決。


	・モニタモード実行時の画面更新タイミングを変更。

	・モニタモード実行時、システムリセットかけてもブレイクポイントが
	リセットされないようにする。(機種変更が行われてもクリアされない)



■2005.10.09 ver 203a
	・SR機種にて旧互換モード(N60,N60m)実行中にVDPフォントを使おうとしても、
	VDPフォントが正常に表示されない不具合を修正。
	SR用のシステムROM領域にVDP_CGROMをコピーするのを忘れてました。
	データが無い状態だとお豆腐が表示。


	・非SR機種でもSR機種と同様、BUSREQ の ON/OFF が切り替えられるように
	ポートio_C8H を実装 。[エミュレータ独自機能]
	それに伴い、初代,mkII,66の どこでもセーブにBUSREQ情報を追加。

	因みにSR機種での BUSREQ_OFF 時のCPU稼働率は 89.395985663 [%] だが、
	非SR機種の時は 79.936164063 [%] と設定。
	何故なら、SRと非SRではCPUのクロック数がそれぞれ 3.571[MHz]、3.9936[MHz]
	と異なるから。 非SRとSRの BUSREQ_OFF 時に同クロックで動作させる場合
	CPU稼働率は以下の計算によって導かれる。
	
	3.571 [MHz] * 89.395985663 [%] =  3.9936 [MHz] * n [%]
	n = (3571000*0.89395985663)/3993600
	n = 0.79936164063

	(※上記、クロック数やCPU稼動値は Moriyaさんが実機から計測した
	  実測値を元に算出されています。マニュアル上の理論値と異なるので注意。)


==============================================================================
■2005.10.07 ver 203
	・Z80_CPU のインダクションポインタ(IX,IY)を使ったビット演算命令(DD-CB-XX,
	FD-CB-XX) の不具合を修正。


■2005.10.06 ver 203
	・NO_SOUND 時、固定速度実行出来なかった不具合を修正。


■2005.10.03 ver 203
	・まだマイルストーンまで間があるので特定関数の高速化に着手してみる。

	以下、Pen2_300MHz にてmkII、FMカートリッジ有効のフルスロットル時…

	・テキスト文字の描画部分を SWITCH( ) からテーブルジャンプに修正。
		Before: 140% → After: 141%
			まぁ、なんという事でしょう。(CV:加藤みどり)

		ヽ( ﾟ∀ﾟ)ﾉ ♪ワーイ、1% も速度アップしたぞ…
		って、殆ど効果無し…＿|￣|○、


	・Z80処理関数を SWITCH( ) からテーブルジャンプに修正。
		Before: 141% → After: 145%
			まぁ、なんという事でしょう。(CV:加藤みどり)
			(…しつこい)

		ヽ( ﾟ∀ﾟ)ﾉ ♪ワーイ、4% も速度アップしたぞ…
		って、殆ど効果無し…＿|￣|○、


	SWITCH の CASE を一つ一つ関数に置き換える置換作業で物凄く時間を
	食うかと思っていたのだが、正規化置換で上手く一括変化出来たので、
	全体的に2時間程度の作業で完了。 (ﾟ∀ﾟ)ノ ﾔｯﾀ

	個別の結果は上の通りだけど、FMカートリッジを外すと 170% に…。
	やはりFMルーチンは処理を食うなぁ。
	因みに NO_SOUND にすると 206%。
	って事は、音系だけでエミュ全体の処理の 30% を締めてるわけか。
	ふむふむ。



■2005.10.02 ver 203
	・テンキーのプラスが効かなくなっていた不具合を修正。
	デバッグ時のログ出力スイッチに設定したまま、リリース時にソースからコメント
	アウトするの忘れてましたな。


■2005.09.30 ver 203
	・画面スナップショット撮影時、マウスカーソルを消去するように修正。
	確かに、コンテキストメニューからスナップショットを撮ろうとすると、
	マウスが残ってしまいますな。キーボードからスナップする分には大丈夫
	なのだけど…。

	・自作VDGフォントが出来上がったのでテキストファイルをバイナリ変換して
	CGROMに書き込むルーチンを実装。
	でも、コレ、何に使うの？ 使ってるソフトなんてあるの？


■2005.09.26 ver 203
	・某氏がP6初代機 VideoDisplayGenerator内臓フォントをワザワザTVからドット
	拾って描いてくれたので渋し…(ゲフンゲフン)…嬉々として対応してみる(オィ。

	でも、正直言ってユーザーが実機から吸いだせる状況にならないとフォント
	表示部だけ実装してもあまり意味が無いのですよ、コレが。
	VDG内臓フォントは一応チップROM内データなので簡単にエミュの中に実装する
	というわけにも行かなさそうだし………さて、どうしましょうかね？
	今現在は真っ白な四角が出て来るだけになっているのだけど。

	先ずは自分が何も見ずに適当にサンプルフォントを用意して、ユーザー各人に
	それを直してもらうのが良いかな？
	テキストで↓こんな感じにフォントを用意しておけば誰でも弄れるっしょ。

	00000000	00000000
	00000000	00000000
	00000000	00000000
	00011100	00111100
	00100010	00100010
	00100010	00100010
	00111110	00111100
	00100010	00100010
	00100010	00100010
	00100010	00111100
	00000000	00000000
	00000000	00000000


	ということで、自作フォント用意しますか…。
	まぁ、所詮 5x7 サイズだから内臓フォントと同じになるのも多そうだけど、
	気持程度自作ですよ〜ということで…(笑。


■2005.09.24 ver 202a
	・640x480 の画面サイズでファイル指定どこでもロードを使うと、画面サイズ
	そのままにスクリーンだけが 320x240 で表示されてしまう不具合を修正。
	単純に条件分岐ミスだった…。

	・6001AのROM対応をやってみたりなんかしちゃったりして。
	といっても、6001 と 6001A で読み込むROMファイル名が変るだけ。
	6001Aは見た事が無いので、所有している人(居るのか？)に試して欲しい。
	ROM吸出しは6001と全く同様に行って、ROMの拡張子を ".61" にする。
	"BASICROM.61" & "CGROM60.61"

	内部動作は6001と全く同じ。変化としては日本語仮名フォントが何らかの記号に
	変るのかな？ カナ入力でもすれば何か得体の知れない記号が出て来るでしょう。
	ウムラウトとか発音記号とか入ってるのかな？  少し興味ある。

	10 FOR I=32 TO 255:PRINT CHR$(I);:NEXT


■2005.09.23 ver 202a
	・昨日のどこでもセーブの例外エラーの件。
	テスト依頼して確認したところ、やはりFM-Cartridge スイッチを有効にすれば
	どこでもセーブを使っても落ちなくなるそうだ。
	FM音源を実装しないでFM音源パラメタを保存しに行く為に、どこかでアクセス
	エラーが発生する模様。未初期化の変数があるのだろう。
	初期化抜けのFM音源用ワークエリアが無いか調査したところ、FM音源の
	音声ストリームが流れないと初期化されない変数があることが判明。
	FM音源が実装されていなくても変数が初期化されるように修正。


■2005.09.22 ver 202a
	・爆弾男で例にもよってハングアップするケースがあると報告があったので調査。
	どうせ、またSTICK割込(INT16H)の取り逃しが起こってるんだろう…(;´Д｀)
	潰しても潰してもキリが無いなぁ。長い間の試行錯誤で修正に修正を重ねられた
	8049の関数群も汚過ぎるし…でも、綺麗に再構築しようにも動かなくなるのが
	怖くて手が出せなかったりして…'`,､'`,､'`,､(ﾉ∀`)'`,､'`,､'`,､ 

	さて、デバッグ用LOGを全開にして調査開始。
	なかなかハングアップの状況が起こらずに時間を食ったけど、10分ぐらいゲームを
	プレイしたところで無限ループ発生。ログ取得。3MB もある(笑。
	ハングアップ発生その一歩手前の部分の8049アクセスログはこちら。

------------------------------------------------------------------
35cc:IN A,(090H):1e DI #2
35b9:IN A,(090H):1e DI #2
35cc:IN A,(090H):1e DI #2
35b9:IN A,(090H):1e DI #2
35cc:IN A,(090H):1e DI #2
3644:OUT (090H),A:06
3644:INT:RESERVE DI(set_vect) V[16H]
RSV[16H]-DI-set   R16:Vff:Pff
V[16H]-DI-in   Rff:V16:Pff
35b9:IN A,(090H):V[16H] #1 DI 
P[16H]-DI-in   Rff:Vff:P16
35cc:IN A,(090H):04 DI #2
35b9:IN A,(090H):00 DI #2
35cc:IN A,(090H):00 DI #2
35b9:IN A,(090H):00 DI #2
35cc:IN A,(090H):00 DI #2
35b9:IN A,(090H):00 DI #2
35cc:IN A,(090H):00 DI #2
35b9:IN A,(090H):00 DI #2
35ca:INT:++ DI V[02H]
35cc:IN A,(090H):V[02H] #1 DI 
3644:OUT (090H),A:06
3644:INT:RESERVE DI(set_vect) V[16H]
RSV[16H]-DI-set   R16:Vff:P02
35b9:IN A,(090H):1e DI #2
V[16H]-DI-in   Rff:V16:Pff
35cc:IN A,(090H):V[16H] #1 DI 
P[16H]-DI-in   Rff:Vff:P16
35b9:IN A,(090H):24 DI #2
35cc:IN A,(090H):00 DI #2
35b9:IN A,(090H):00 DI #2
35cc:IN A,(090H):00 DI #2
35b9:IN A,(090H):00 DI #2
35cc:IN A,(090H):00 DI #2
35b9:IN A,(090H):00 DI #2
35cc:IN A,(090H):00 DI #2
35b9:IN A,(090H):00 DI #2
35cc:IN A,(090H):00 DI #2
  :
  :
(以下、ず〜っと 35b9H、35ccH の "IN A,(090H)" の繰り返し)
  :
  :
------------------------------------------------------------------

	"INT:RESERVE DI(set_vect) V[16H]" がSTICK割込みの要請。
	その後、"IN A,(090H)" で INT16H が発生する待機ループに入る。 
	正常なプロセスは↓こんな感じ。

------------------------------------------------------------------
35cc:IN A,(090H):1e DI #2
35b9:IN A,(090H):1e DI #2
35cc:IN A,(090H):1e DI #2

3644:OUT (090H),A:06           ;STICK割込み要請
3644:INT:RESERVE DI(set_vect) V[16H]
RSV[16H]-DI-set   R16:Vff:Pff

V[16H]-DI-in   Rff:V16:Pff
35b9:IN A,(090H):V[16H] #1 DI  ;INT16H ベクタ発行

P[16H]-DI-in   Rff:Vff:P16
35cc:IN A,(090H):04 DI #2      ;INT16H パラメタ発行

35b9:IN A,(090H):00 DI #2
35cc:IN A,(090H):00 DI #2
------------------------------------------------------------------

	アドレス 35b9H がベクタを取り出し、35ccH がパラメタを取り出しで、
	STICK処理が終了する。
	一方、無限ループに突入するプロセスは…

------------------------------------------------------------------
35cc:IN A,(090H):00 DI #2
35b9:IN A,(090H):00 DI #2
35ca:INT:++ DI V[02H]          ;キーボード割込み発生
35cc:IN A,(090H):V[02H] #1 DI  ;INT02H キーボードベクタ発行

3644:OUT (090H),A:06           ;STICK割込み要請
3644:INT:RESERVE DI(set_vect) V[16H]
RSV[16H]-DI-set   R16:Vff:P02

35b9:IN A,(090H):1e DI #2      ;ベクタ取得のハズが先に発生した
                               ;INT02H のパラメタが発行されてしまう

V[16H]-DI-in   Rff:V16:Pff
35cc:IN A,(090H):V[16H] #1 DI  ;パラメタ取得の位置に INT16H ベクタが発行

P[16H]-DI-in   Rff:Vff:P16
35b9:IN A,(090H):24 DI #2      ;以降…INT16Hベクタを検知できずに無限ループ
35cc:IN A,(090H):00 DI #2
35b9:IN A,(090H):00 DI #2
35cc:IN A,(090H):00 DI #2
35b9:IN A,(090H):00 DI #2
------------------------------------------------------------------

	キーボードベクタが発生して、ベクタ発行とパラメタ発行の間にSTICK割込要請が
	発生してしまうとタイミング的にベクタとパラメタの発行がズレてしまって
	期待される INT16H ベクタ発行を取りこぼしてしまう…。
	となると、STICK割込要請が出た時点でその時処理中のベクタがあったら
	パラメタを無効にする処置が必要になる。STICK割込は間を置いて発生する
	インターバルになっているので、処理中ベクタはパラメタが残っている場合
	のみスタックを破棄して、ベクタ自体が残っていたらそのまま残したままで
	STICKを予約しておけば良いだろう。


■2005.09.21 ver 202a
	・ver202 でどこでもセーブを使うと例外エラーが発生するとの報告あり。
	OS は Xp、98。ver199 では起こらずに ver200 以降に発生との事。
	う〜む、何故か開発用PCでは平気だ…。
	ver199 から ver200 の大きな変更はSR対応。任意のファイル名でセーブ
	出来るように下のも ver200 からだったかな？
	システムメモリ関係は旧機種と殆ど違いは無いわけだし、大幅に追加した
	ものとしてはFM音源関係箇所だろうか…？ 
	とりあえず、SAVE用ファイル名が変な状態にならない様、エミュの設定が完全に
	新規の状態でも各種作業用パス (ROMパスやSAVEパスなど…) が正確なフルパスの
	状態でオプションに反映されるように修正。
	これが原因かどうかは不明だが(多分違うだろうな…)、FMの環境設定について
	例外エラーが発生する環境で確認してもらう事にしよう。


■2005.09.12 ver 202a
	・PSGをFMに変換出力する機能を実装。(PSG2FM ポート)
	エミュ独自ポート io_ADH でFMに変換するチャンネルをビットフラグで指定。
	bit0:CH-1、bit1:CH-2、bit2:CH-3
	OUT(0xAD),0 で全チャンネルOFF。
	OUT(0xAD),7 で全チャンネルON。

============================================================================
■2005.08.21 ver 202 
	・S98ファイルの出力フォルダをLOG出力フォルダに変更。
	ついでに、録音 ON/OFFで１ファイルに継続記録していた仕様を、ファイル番号を
	加算して別々のファイルに出力するように変更。


	・モニタモードのコマンドに "outs" を追加。
	"outs REG,DAT" で任意のサウンドレジスタへ直接データを出力できる。
	今まで、通常の OUT命令 でサウンドレジスタを変更する場合、
	"out 0xa0,REG"、"out 0xa1,DAT"
	と二つの窓口を叩く必要があって、手間がかかっていたのデス…。


■2005.08.08 ver 202
	・S98が正常に出ている事は確認出来たので、PSG に引き続き FMレジスタも出力
	出来るようにする。
	同時にS98録音開始時に音源チップのレジスタ状態を全て書き出すように修正。


■2005.08.04 ver 202
	・懲りずに S98。
	SYNCを出すタイミングがCPUのクロックによるカウントじゃまずいのかも
	知れないと思い、DirectSound の Stream に合わせて 60[Hz] で区切るように
	してみたり、CPUタイマーを使ってエミュレーターとは別スレッドのタイマーを
	立ててみたり、色々と小細工を施してみたが、結果は変らず…。
	あぁ…もうダメポ…＿|￣|○、


	って、ちょっと、まてぇい！(#ﾟДﾟ)
	試しに KbmPlayer で聴いたら正常に鳴ってるぞ！？
	今まで Winamp でヨレヨレテンポで再生されていた S98 を Kbmplayer に
	持って行ってみたら…全部正常  Σ(ﾟДﾟ;)ガーン
	てーことは、
	要は Winamp のプラグイン(in_S98.dll ver1.3.1+)が変だったのね…＿|￣|○、
	ここ数日の試行錯誤の苦労は…つД`)うっうっうっ


	でも、正直、再生に関しては様々な出力機能が備わっている Winamp の方が
	利用頻度が高いんだよな。in_S98 ってここ数年バージョンアップしてないの？
	検索してみると S98 の Ver3 というのが動いているらしいけど…。
	このプラグインは 6001 の S98 をマトモに再生してくれるのだろうか？



■2005.08.02 ver 202
	・引き続きS98記録部分の見直し。
	レジスタ出力中のSYNC命令は遅延させるように変更したのだがまだおかしい。
	JOYSTICKポートの読み出しで音と無関係に頻繁にデータ更新が行われる
	からかな？
	という事で、JOYSTICK読み出しが発生しないスペハリ以外のソフトを試してみる。

	先ずは、トリトーンロードBGM。
	ふむん。ちゃんと鳴ってるじゃないッスか (=´∀｀)

	では、次はビクトリアス９のロードBGM。
	……(ﾟ∀ﾟ*)……(ﾟ∀ﾟ;)え？……Σ(ﾟДﾟ;)！？……
	＿|￣|○、ダメダコリャ…

	どうもタイミングの取り方を根本的に間違えているような気がする。


■2005.08.01 ver 202
	・S98記録部分の見直し。
	とりあえずその前にS98のバイナリをコマンドに展開する簡易アプリを作成。
	資料として、NekoProjectII と M88 でS98のサンプルを取って展開してみる。

	う〜む、さすがに 98 は 1-SYNC 間に大量にレジスタを出力している。
	88もFM音源が扱えるようになったのはSR以降だから処理速度は段違いだし、
	それに比べてP6は…(;´Д｀)  お  そ  い

	S98は同期時間を [ms]単位で任意に選べるのだけど、タイミング精度を考えると
	1[ms] 同期で記録するのがベター。1[ms] にしても 10[ms]にしても
	データー量的にウェイトの数値が少し変るだけでサイズは変らないので…。
	ところが、98や 88と違って6001の場合、この 1[ms] の時間内に音源に
	送り込めるデータの量が限られてしまって、例えば和音の出力を行おうとすると
	1[ms] の 1-SYNC内に収まりきれずに、パートの出力タイミングに時間的ズレが
	生じてくるみたいだ。

	本来、実機やエミュの場合、チップに出力されたレジスタはその場で音として
	有効になるので、和音出力にCPU何クロック分の時間のズレが生じたところで
	音としては何の問題も無いわけだけど、S98形式の場合事情は異なって来る。
	レジスタの反映はそれこそ時間的に一瞬で済まされるのだけど、時間の同期が
	SYNC命令でウェイトを入れる方式になっているので、レジスタ出力の途中に
	SYNC が挟まってしまうとSYNCの前後にあるレジスタ出力に 1[ms] のズレが
	生じることになり、これが一箇所だけでなくそれこそ記録ログ中にまんべんなく
	存在するものだから、曲自体がユラユラと揺らぐ自体になってしまっている？？

	例えば例を挙げると下の様な部分…。(サンプルにはP6スペハリを使用)

SYNC 184
OUT_REG(M) 08H,0FH
OUT_REG(M) 00H,00H
OUT_REG(M) 01H,00H
OUT_REG(M) 09H,0FH
OUT_REG(M) 02H,00H
OUT_REG(M) 03H,00H
OUT_REG(M) 0AH,10H
OUT_REG(M) 0DH,00H
OUT_REG(M) 04H,BAH
OUT_REG(M) 05H,03H
SYNC 185
OUT_REG(M) 08H,0FH
OUT_REG(M) 00H,3EH
OUT_REG(M) 01H,01H
OUT_REG(M) 09H,0FH
OUT_REG(M) 02H,7AH
OUT_REG(M) 03H,01H
OUT_REG(M) 0AH,10H
OUT_REG(M) 0DH,00H
OUT_REG(M) 04H,DDH
OUT_REG(M) 05H,01H
SYNC 184
OUT_REG(M) 0AH,10H
OUT_REG(M) 0DH,00H
OUT_REG(M) 04H,BAH
SYNC 1
OUT_REG(M) 05H,03H
SYNC 184
OUT_REG(M) 08H,10H
OUT_REG(M) 0DH,00H
OUT_REG(M) 00H,2CH
OUT_REG(M) 01H,01H
OUT_REG(M) 09H,10H
SYNC 1
OUT_REG(M) 0DH,00H
OUT_REG(M) 02H,65H
OUT_REG(M) 03H,01H
OUT_REG(M) 0AH,10H
OUT_REG(M) 0DH,00H
OUT_REG(M) 04H,DDH
OUT_REG(M) 05H,01H
SYNC 185

	SYNC 184 というのがBGMの譜面を更新する定期的なタイマー割込みの間隔で、
	これが曲のテンポにあたる。その間にある OUT_REG(M) が音源チップへの
	レジストリ出力となり音階やボリューム変更が変更される。
	で、1-SYNC以内にきっちりレジスタ変更が収まりきっているなら問題ないが、
	後半部分を見ると OUT_REG(M) のパラメタ更新の間にタイミング的に SYNC が
	割り込んできてしまっているから、前のパラメタ変更と後ろのパラメタ変更の
	間に 1[ms] のウェイトが挟まって、これが彼方此方に存在するお陰で
	曲のテンポに変な揺らぎが発生してしまうという事かな？  推測だけど。
	それにしては、98 や 88 エミュで作ったS98にも同じように SYNC が挟まって
	いるのに変なテンポの揺らぎは聞き取れないんだよな…。
	良くわからん。

	まぁ、とりあえず…
	1-SYNC の間隔挟んでパラメタ出力が継続している場合はパラメタ出力が
	終わるまでウェイト出力を遅延させれば問題ナッスィング？
	1,2[ms] 程度の時間で音階が変るような曲なんて存在するわけないし…。
	あ…例外があったな。ボスコニアンやグロブダなどのサンプリング出力。
	コレはCPU全力疾走でリアルタイムにパートのボリュームを上げ下げして波形を
	再現しているので、Z80-CPUの実時間と直に繋がっているんだよな…。
	でも、どの道S98のSYNC方式だとこういうCPU速度全力疾走は正常に記録できない
	から特に気にするこたぁ無いか。


■2005.07.25 ver 202
	・S98形式のサウンドログ機能を実装してみる。(個人的趣味全開)
	音楽録音はWAVで行うと膨大なサイズになってしまうが、S98ならコンパクトな
	サイズで済むもんね〜 (*´∀｀)

	しかし、S98は AY-3-8910 と YM-2203 などの音源チップのレジスタ書き込み
	記録だけだから uPD7752 の音声出力には対応していない。
	いや、まぁ、S98仕様を勝手に拡張して対応しても良いのだけど、結局、音声出力
	に対応したプレイヤーは自前で作らなければならないので、独自仕様を作る意味は
	無いのデス…(;´∀｀) それなら完全オリジナル形式にした方が楽だし

	さて、S98形式は音源チップのレジストリ書き込みを時間的な同期コマンドを
	挟みながらファイルにバイナリ出力するだけだから、実装するのは楽勝だと
	思ったのだけど、実際に記録したS98ファイルを再生してみると速くなったり
	遅くなったりどうにもテンポが安定しない。
	タイミングの取り方がおかしいのかな？

============================================================================
■2005.07.22 ver 201
	・エミュレータ独自ポートに画面回転設定を追加。

	OUT(0x2F)
	IN(0x2F)
		0:OFF,1:90[deg],2:180[deg],3:270[deg],4:????

■2005.07.21 ver 201
	・画面回転をさせたとき、カーソルもローテートさせるようにする。
	グルグル回転の時は変らず。
	修正箇所は、通常のキーボード割込みによるカーソル入力、STICK関数による
	カーソル状態取得、ジョイスティックの方向。
	う〜む、考えてみたらモニタモード突入で画面が戻ったときには元に戻さないと
	ならないんだよな。結構ややこしいぞ。


	………って、
	なんか脱線してるなぁ。画面描画関数内の合理化・条件分岐潰しをやっていた
	ハズなのだけど、逆に増えてるし…(笑。 
	N60、N60m、N66SR のVRAM描画もバラしておこうかな。それとVRAM描画と
	Window描画の関数も分離して別々に管理しよう。
	メンテナンスは面倒になるけど画面の描画毎に通過する条件分岐は減らせる。 

	因みに画面回転モードの解像度は 640x480 固定。 フルスクリーンに移行出来る
	解像度が前提なので…。 



■2005.07.19 ver 201
	・スクリーンモードの解像度選択部分の見直し。同時に画面表示の回転を仮実装。

	折角、TV4:3モード実装時にオフスクリーンサーフェスのサイズを任意に選択
	出来るようにしたので、Allegroのスプライト機能を使って回転転送してみたら
	意外と綺麗に転送できることが判明。
	以前、プライマリサーフェスの表示だけ Direct3D を使ってポリゴン表示させる
	ようにしたら、拡縮や角度指定で思い切りアンチエリアが発生してしまい、
	コリャ自前でドット転送しないと回転表示は難しいかな？と思っていたのだけど、
	スプライトルーチンを使ったら関数一発で楽チンだった…（*´∀｀）
	といっても、Allegro ライブラリを撤去する段階になったら、結局自前のルーチン
	に置き換える必要性が出てきてしまうので、とりあえず現時点では仮実装。


	それにしても、Allegro スプライトルーチンは座標の指定の仕方が特殊で、
	表示位置あわせするのに多少手間取ったので、仕様メモっておく。

	回転スプライト関数は、

	void rotate_sprite(BITMAP *bmp, BITMAP *sprite, int x, int y, fixed angle);

	…の様な定義になっているのだけど、(x,y) の座標の意味で引っ掛かった。
	回転の軸はスプライトの中心になると説明にあるので、(x,y) で指示した
	座標にスプライト中央が来るよう画像が貼り付けられるのかと思って、
	その様に計算して実行すると、全然想像していたのと違う場所に表示される。
	試しに (x,y)=(0,0) で実行したところ、回転角が 0 [deg] 、180 [deg] の
	時はピッタリとスプライトデータの左上が基点となって表示されるが、
	90[deg]、180[deg]、その他の角度だと奇妙なズレが生じる。
	幾つかの角度をサンプリングし、結果を見て分析するに、どうやらこの関数、
	回転はスプライトデータの中央を軸に行われるが、表示の基点は『回転前』の
	スプライト象の左上座標に固定されているようだ。
	要するに、本来回転させたいキャラクターは正方形の内接円内に収まるよう
	描いておく必要があるって事なのね。
	ここでスプライトに用いたP6の画面は長方形だから、それを回転させれば
	当然長方形の短辺と長辺で構成される直角三角形の斜辺の長さがスプライト
	回転の直径になり、実際の回転された絵の基点は元の位置から大幅にズレて
	指定範囲からハミ出る事になる。

	幅w、高さh のスプライトを回転させ、その回転の中心位置が固定される状態で
	転送したいときは、矩形のサイズが変る度に (x,y) の基点座標を計算しなおす
	必要がある。

	l = sqrt(w*w+h*h);  //矩形の斜辺長
	adj_x = (l-w)/2;   //x の調整値
	adj_y = (l-h)/2;   //y の調整値

	一方、90度回転させた象を、きっちり矩形に納めて表示しようと思ったら、
	スプライトの基点と『回転後』の象の表示位置の差分を指定する必要がある。

	adj_x = (w-h)/2;  //x の調整値
	adj_y = -adj_x;   //y の調整値



■2005.07.12 ver 201
	・のりさんから初代機のN60-SCREEN4コンポジット出力サンプル画像をいただいた
	ので滲み色を調整。

■2005.07.07 ver 201
	・N60-SCREEN4 の COLOR,,1(CSS:0)(緑色) の時にも色化けが発生するように修正。

■2005.07.04 ver 201
	・ベタディスクイメージ(*.DSK)をマウント出来なくなっていた不具合を修正。
	どうやら、SR対応でD88イメージの1D/1DD フォーマット取り扱いを別にしたとき、
	DSKイメージはエラーとして蹴られる様になってしまったらしい…。

============================================================================
■2005.07.01 ver 200c
	・umonistさんのご指摘により、PC-6001初代機で拡張ROMが無い状態で
	メモリマップをCGROMに切替たとき、&H6000-&H6FFF と &H7000-&H7FFF の領域に
	キャラクタジェネレーターをダブルマッピングするように修正。

	初代機でメモリにCGROMをマッピングしたとき、
	拡張ROMがある場合は…

	4000H - 4FFFH : EXT-ROM1
	5000H - 5FFFH : EXT-ROM2
	6000H - 6FFFH : CG-ROM
	7000H - 7FFFH : EXT-ROM3

	となるが、拡張ROMが無い場合は…

	4000H - 4FFFH : Empty
	5000H - 5FFFH : Empty
	6000H - 6FFFH : CG-ROM
	7000H - 7FFFH : CG-ROM

	どうやらこうなるらしい。
	今までは Empty 状態になっていたので…

	4000H - 4FFFH : Empty
	5000H - 5FFFH : Empty
	6000H - 6FFFH : CG-ROM
	7000H - 7FFFH : Empty

	7000H以降でCGROMにアクセスしているソフトではキャラクターデータを
	正常に取得出来なかった。
	因みに mkII以降では拡張ROMがある時はEXT-ROMが入ってくるのは同じだが、
	拡張ROMが無い時は BASIC-ROMが入り込んでくるので 7000H以降でCGROMに
	アクセスすることは出来ない。

============================================================================
■2005.06.10 ver 200b
	・メディアイメージが設定されていない状態でイメージファイル選択を行おうと
	すると、メディアパスがデフォルトパスにリセットされてしまう不具合を修正。


	・モニタモードでのバイナリデータの使い方として試行錯誤していたときに
	用意した、BIN2P6,BIN2P62 コマンドを有効にしてみる。コマンドヘルプも追加。
	これも用途が特殊すぎるのでオマケ機能扱いで良いかな？
	現役P6プログラマーの役には立つと思うけど…。

	説明)

	BIN2P6 <filename> <start-addr> <end-addr>
	BIN2P6 <filename> <start-addr> #<size>
	BIN2P62 <filename> <start-addr> <end-addr>
	BIN2P62 <filename> <start-addr> #<size>

	指定したRAMの範囲を "filename.p6" に出力。
	"filename.p6" はバイナリローダーとデータ部に分かれていて、
	"cload","run" でデータを元の位置に読み込めるようになっている。

	バイナリローダー部は BASIC。データ部のフォーマットは…

	------------------------------------------------------------
	インデックス：6byte "9C,9C,9C,9C,9C,9C"
	格納アドレス：2byte
	データサイズ：2byte
	データ      ：以降、データサイズ分だけバイナリが並ぶ
	------------------------------------------------------------

	BIN2P6 と BIN2P62 の違いは、バイナリローダー部のマシン語をBASICのDATA分で
	読み込ませるか、BASICリストの後半に直接バイナリで組み込んであるかの違い。
	ローダーのマシン語はリロケータブルで、どのアドレスに置いても動作可能。
	デフォルトは &HF880 (DISKの読み込みバッファ) に格納される様になっている。
	バイナリローダー部のBASICを改造したいときなどは BIN2P6 を使い、マシン語で
	メモリを使いたくないときなどはローダーがBASIC領域に組み込まれている
	BIN2P62 を使う。

	バイナリローダーのBASICは以下の通り。

	10 J=&HF880:FORI=0TO47:READA$:POKEJ,VAL("&H"+A$):J=J+1:NEXTI
	11 EXEC&HF880:END
	12 DATA CD,9A,25,CD,70,1A,6F,CD,70,1A,67,CD,70,1A,4F,CD
	13 DATA 70,1A,47,CD,70,1A,57,F3,3E,DD,D3,F0,72,3E,11,D3
	14 DATA F0,FB,23,0B,78,B1,20,EB,CD,06,1B,C3,AA,1A,C9,C9

	BASICを改造したいときは、BIN2P6 で出力されたイメージからバイナリエディター
	などでデータ部だけ切り出して、上のマシン語部分を元にBASICを組み、
	TXT2BAS でP6イメージに変換してデータ部と結合させる。

■2005.06.08 ver 200b
	・モニタモードのFMレジスタ出力コマンドで、未設定レジスタ値を -1(FFFF) で
	出力していた不具合を修正。

	・ついでにFMDRV用音色テーブルを出す隠しコマンドも追加。
	といってもHELPに表示されるので、隠しコマンドというより用途が特殊な
	オマケ機能という扱いかな？
============================================================================

■2005.06.04 ver 200a
	・コロニーオデッセーのエンディングにて、SCREEN3 と SCREEN4 の高速切替で
	画面エフェクトを発生させるシーンで、エミュレータが異常にモタつく状態に
	陥るとの報告。
	P6VW ではスクリーンモード切替の時、確保していたVRAMを一旦解放して変更後の
	スクリーンサイズでVRAM再確保を行っているのだが、一部のビデオカードでは
	この処理が連続で行われると動作に支障が出るモノもあるみたいだ。
	なので、スクリーンサイズが変化しない限りVRAMの再確保を行わないよう修正。

	自分の開発マシンは PentiumII-300MHz で、コレ以下のCPUを使っている人は
	滅多に居ないと思うので、エミュレータ動作の最低環境ラインは保守している
	つもりなのだけど、ビデオカードだけはCPUに比べてかなり強力なのを積んで
	いるので DirectDraw の最低パフォーマンスだけは確認できていなかったみたい。

	以下がCRTコントロール高速切替のテストプログラム。
	ver200 でこのプログラムを使用して、エミュが固まったような状態になるのは
	ビデオカードのVRAM容量が少ないか2D機能が著しく弱い可能性がある。

5 REM MODE 5 - PAGE 2
10 SCREEN3,2,2:CLS
20 CIRCLE(128,80),64,6
30 CIRCLE(188,142),48,11
40 GOSUB 100
50 EXEC&HD000
99 END
100 RESTORE 150:AD=&HD000
110 READ A$:IF A$="*" THEN RETURN
120 POKE AD,VAL("&H"+A$):AD=AD+1:GOTO 110
150 DATA 3E,00,E6,F7,D3,C1,47,CD
160 DATA 61,10,78,F6,08,D3,C1,47
170 DATA CD,61,10,78,C3,02,D0,*


	・どこでもロードを使うと、プリンターファイル出力先がLOG出力用フォルダから
	エミュのカレントフォルダに移動してしまう不具合を修正。

============================================================================
■2005.05.30 ver 200 
	・106キーボード用のキーコードマップにて、[DEL]キーに 0x08 (=[BS]) が
	割り当てられていた不具合を修正。本来は [DEL] = 0x7F。


	・ 320x240の解像度でTV4:3モードを使用し、SRモードの640x200のスクリーンを
	選択してデバッグモードに入ると例外エラーが発生する不具合を修正。
	倍率を等倍に切り捨てる時、縮小表示の場合倍率が 0% になってゼロ除算が
	行われてたりして…(^^;;


■2005.05.28 ver 200 
	・6001/mkII/6601にて、FMカートリッジを有効にした状態で どこでもセーブを
	したのち、今度はFMカートリッジを切った状態で起ち上げてロード復帰したとき
	PSGストリームしか存在しない状態になってしまう不具合を修正。
	FMカートリッジフラグの状態が変化したら、音声ストリームを全て解放して
	フラグの状態に合わせて再構築するように変更。

	・FMカートリッジの実装に併せ、6001/mkII/6601機種でも どこでもセーブ の
	保存データにYM2203のステータスを含めるように修正。


	あ〜、もう、いつまでも何やってんだか…(;´Д｀) 焦焦焦焦



■2005.05.24 ver 200 
	・音声ストリーム周波数が事なった状態の どこでもセーブデータを復帰させると、
	FM音源に周波数が反映されない不具合を修正。

	当然の事ながらPSGもFMも出力周波数の値を内部に持っていて、それを時間の
	基準にして波形を作るので、外部のストリーム周波数が変るときはチップ内の
	周波数情報も書き換える必要があると…。
	でも現在出力中の音だけは時間のカウントが変更前の値を継続する事になるので、
	音を出しっぱなしの状態でどこでもセーブし、音声周波数を変えた状態で
	それを復元すると以前の周波数の音の長さを継続使用とするので、どうしても
	冗長した音になってしまう。でも、こればかりはどうにもならんなぁ。



	・PC-60m55、FM音源カートリッジのフラグとI/Oポート実装。
	ついでに、このフラグを立てたときSR用のFMポートも有効になるよう修正。
	これにて、mkIIでもビクトリアスナインのBGMがFM音源になるし、よっしゅさんの
	FM音源ドライバーもmkIIで実行出来るようになって、実にお得 ( ﾟ∀ﾟ)


■2005.05.23 ver 200 
	・各種ドキュメントの更新。最終アルファ版リリース。
	何かバグでも出てこない限りこのまま公開。


■2005.05.18 ver 200 
	・FM音源のパラメタ復帰部分の見直し。
	レジスタの再設定、モード再設定、ステータスとモジュレータ接続の復元、
	異常なところは見当たらず、波形生成部分を延々トレースしていたところ、
	不可解な部分が…。
	何故かYM2203で使われない位相変調と振幅変調のルートを通過して、値未設定の
	カウンタを使って変調テーブルにアクセスしようとして例外アクセスが発生する。
	モジュレータのパラメタ復元を調べてみたが正常。
	ではデータ保存側の書き込みを見ると……あ、チャンネルパラメタの変数は実体で
	なくポインタを持っているのに、保存先指定の所に "＆" が付いてたりして…。
	パラメタ実体でなくてポインタテーブルの方を保管してた…＿|￣|○、
	うぅぅ、実に安っぽいミスだ…。
	そういうわけで、パラメタ実体の方を正常にファイル保存するよう修正。
	位相変調の所に変な値が入る事も無くなり例外エラーは消滅。
	これでどこでもロードの時にサウンドの初期化を挟む必要が無くなった。
	レジスタ変更だけでそのまま波形生成に反映させられる。

	ううむ、それにしても6月を目標に去年からカナリ余裕を持たせて開発を
	進めて来たハズなのに、随分ギリギリになったなぁ…（´･ω･`）
	本当は動作速度を上げる為にZ80処理のSWITCHを全てテーブルジャンプに変え
	たいのだけど、これは後のバージョンアップの課題ですか？



■2005.05.14 ver 200 
	・擬似ステレオのPAN指定範囲を 0〜64〜128 に変更。
	エミュレータ動作中位置が固定されたままなら10段階でも問題ないけど、
	プログラム中で左右に動かす時は細かく指定できる方が融通が利くし、
	滑らかに移動させる事が出来るので…。
	尤も、Allegro設定ダイアログではスライダーの移動が1文字単位でしか出来ない為
	現在も10段階の粗い指定しか出来ないようになっている。


	・どこでもロードを行ったときFM/PSGの音色が正常に復帰しない原因を調査。
	FMは音色が正常に戻らず、PSGはノイズが立ち上がってしまう。
	どこでもロードの音源レジスタ復帰部分を確認したのだが、この時点では
	パラメタが正常に反映されている。
	6001システムの再起動まで追いかけてみるとシステムの初期化でサウンドの
	初期化も行われている。エミュレータ内からサウンドの周波数を変更できる
	わけでもないのに、何故、ここに初期化を入れたんだっけな？
	そういうわけでサウンド初期化を外す。
	すると…復帰後のFM音源生成で例外エラー発生。工エｴェｪ（；´Д｀）ｪェｴエ工
	そういう事か…。
	コリャ、FM音源の復帰部分を見直さないとダメだな。



■2005.05.13 ver 200 
	・継続して波形ミキサー部分の調査を続けているのだけど…
	単音チャンネルの出力波形をログに取り込んでみると、合成波形に見られるような
	極端な階段は見られない。しかし、合成すると階段が出来る。
	なんだコリャ？

	最終手段として合成前のPSG/FM左右全12チャンネルをテキストログに吐いてみた。
	5秒程度のサンプルを取るのに10分近くかかったけど…（;ﾟ∀ﾟ）
	ここで不可解な事が判明。
	左・右専用チャンネルのストリームを DirectSound バッファに出力するとき
	何故か反対側のチャンネルにも微小波形が出力されてしまっている。

	P6VWではサウンドストリームが走る本数を減らすためPSG-3チャンネル分、
	FM-3チャンネル分 をそれぞれ合成して PSG-CH、FM-CH にしている。
	ステレオ化の時はそれと併せてそれぞれもう1チャンネルずつ確保し、
	それらを左右チャンネルとして生成された波形をPANで割り振って合成している。
	要するに左用チャンネルのPANは完全に左に振り切れているし、右用チャンネルの
	PANは右に振り切れている。
	ところが、ミキサーの方ではチャンネル毎にPANがあるものとしてボリューム調整
	を行っているのだが、完全に片側からしか音を出ないはずのチャンネルまで
	反対側から僅かに波形を出力しているようだ。

	という事は…そうか、片側チャンネルだけに存在するはずの振幅が何故か
	逆チャンネルにも少量出力され、それが加算されるせいで逆側の波形の高さが
	不自然な階段状になってしまったのか。
	チャンネルがそれぞれ別々の音色波形で出ていたらこれも目立たなかった
	だろうけど、全く同じ音色波形を出していたから振幅が倍倍で加算されて
	妙な歪みになっていたと…。

	このミキサーはSEALの仕様を引き継ぐ為にSEALとMAMEミキサーの混合状態
	なのだけど、純粋な片側チャンネルを出せる仕様になっていないみたいだ。
	PANで左右チャンネルに振り分けるときのボリューム値を調整テーブルから
	読んでくる現在の仕様を変更し、各チャンネルから送り込まれて来た生データを
	単純計算で減衰させて DirectSound バッファに送り込むように修正。

	ただし、これだとチャンネル毎の最高ボリューム固定で波形合成が行われるので、
	新規音声ストリームを追加する時は、その都度、全ストリームが重なった時に
	音割れが発生しないよう手動でチャンネルボリューム補正を再計算する必要性が
	出てきてしまう。
	この点、注意が必要と…。



■2005.05.07 ver 200 
	・擬似ステレオモードのFMにノイズが乗ってリリースで唸る原因を調べてみる。
	音色を記録してWAVを波形エディターに放り込んで観察。

	特に変なところは見当たらない…と振幅をどんどん拡大して行くと…！？
	…波が見事に階段状になっとる…（;ﾟДﾟ）
	そうか、PANを振り分けるのに元のFM生成波形に対して割り算・掛け算を
	行っているからその端数部分が丸められちゃってるのね…。

	これはどうしたもんだろう。
	FMで波形が生成されるときは SIN計算で DWORD の桁で数値が出てくるけど、
	これをストリームバッファに格納する段階では WORD整数に変換されるから、
	この整数でPAN計算を行うとどうしてもアラインが出てしまうのかな？

	いや、しかし波形の合成の段階でチャンネル数に合わせて除算されるはずなので、
	この時点で値が飛んでいても問題ないはず。もしかすると、全チャンネルを
	合成した後の波形レベルをミキサーが引き上げようとしているのかも。

	というわけで、チャンネル別のボリュームをアップし、マスターボリュームを
	下げればアラインは減らせるかと思ったら、波形に全く変化無し。
	という事は、ミキサーの波形合成で粗が出ているのか。
	厄介ですな…。



■2005.05.06 ver 200 
	・SRのCPU稼働率を調整。
	大雑把に計算で数値を求めてから、テスト＆修正の繰り返しで微調整。

	BUSREQ_ON の状態だと、
		N60モード稼働率  = 0.5020836; →50.20836 [%]
		N60mモード稼働率 = 0.3960610; →39.60610 [%]
	BUSREQ_OFF では…
		N66SRモード稼働率= 0.8939599; →89.39599 [%]

	ちなみにクロック周波数と垂直同期、タイマー周波数は実際の測定値から
	CLOCK =3571000 [Hz]
	VSYNC =16.640001 [msec]
	TIMER =499 [Hz]
	で動かしている。


	現時点で不明なのは…
		BUSREQ_OFF での N60モード稼働率
		BUSREQ_OFF での N60mモード稼働率
		BUSREQ_ON  での N66SRモード稼働率
		CRT_KILL での N60モード稼働率
		CRT_KILL での N60mモード稼働率
		CRT_KILL での N66SRモード稼働率

	測定手段も無いし判断の目安も無いので、推測で当てはめてみる。
		BUSREQ_OFF:N60,N60m は、BUSREQ_OFF:N66SR と同じ。
		BUSREQ_ON :N66SR    は、BUSREQ_ON:N60m と同じ。
		  (内部で扱うディスプレイの垂直幅は4ドットしか違わないので…)
		CRT_KILL:N60,N60m は、BUSREQ_OFF:N66SR と同じ。
		CRT_KILL:N66SR    は、BUSREQ_OFF:N66SR と同じ。
		  (BUSREQは通常CRT表示のタイミング待ちで発行されるので、
		  CRT_KILL = BUSREQ_OFF と同じ事でしょう。多分。)

	以上の様に、適当に数値を割り当てておく事にする…
	ちょっと大雑把過ぎるかな？(;ﾟ∀ﾟ)> ﾃﾍ


■2005.05.05 ver 200 
	・どこでもセーブを任意ファイルに指定出来るようにする。
	これで３つ以上セーブデータの保存が可能。
	どこでもセーブはゲームとかの場合それほどセーブ箇所は必要ないけど、
	開発のデバッグ作業で使うとなると沢山あったほうが良さそう。
	拡張子は機種別に3種類で判別。

	PC-6001 :"*.s60"
	mkII/66 :"*.s62"
	SR      :"*.s64"

	機種の異なるセーブデータを読み込ませてシステムの再起動をかけるのは、
	やりようによっては可能だけど、そういう使い方は普通有り得ないので、
	現在使用中の機種のセーブデータだけ読み込めるようにしておけば良い。



	・SR機種のN66モードでどこでもセーブしたデータを復帰すると画面が
	表示されなくなる不具合を調査。
	カーソルを動かしたりPLAY文を実行すると音がするのでZ80は走っている。
	画面の表示モードが非SRモードとSRモードで誤動作を起こしている可能性が
	あるので画面描画にデバッガで網を張ったが正常の旧互換で動作している。
	スナップショットを確認すると完全に真っ黒。試しにスクリーンモードを
	切り替えてLINE文でBOX描いたら普通に描画されるのだが白が出てない…。
	白？…って事はパレットが正常に復帰されていないのか？
	
	ああ、やはりそうだった。SR特有のパレット情報の保存方法に不備があった。
	パレットチェンジのI/Oはパレット設定するのに数値をひっくり返して指定する。
	具体的にはこんな感じ。

	OUT(0x40),0 -> 15番のパレットを (15-0)=15 番のカラーに設定。
	OUT(0x41),1 -> 14番のパレットを (15-1)=14 番のカラーに設定。
	OUT(0x42),2 -> 13番のパレットを (15-2)=13 番のカラーに設定。
	OUT(0x43),3 -> 12番のパレットを (15-3)=12 番のカラーに設定。

	そういう意味で、エミュ内部では設定値をひっくり返した値を保管していで、
	それをどこでもセーブで保管していたのだけど、ロードした時その値が
	ひっくり返ったままI/Oポートに送り込んでいたりして。
	だから15番の白が0番の黒に変化してカーソルすら表示されなかったと…。
	調査に随分時間を喰ってしまったけど、結果は単純ミス。



■2005.05.04 ver 200 
	・開発用のコマンド数も随分と増えて来たので、そろそろHP説明の方でも
	モニタモードとオプションの解説を別ページに分けないと、見たい項目を
	見付けるのにも苦労しそうだ。



■2005.05.02 ver 200 
	・以前から作りかけのまま忘れていたデータ圧縮アプリ(Windows)を仕上げよう
	と思ってZ80の展開用コードを組んでいて、デバッグ時にふと思った。
	モニタモードからメモリ内の範囲を指定して、ファイルの形式に出力して外部アプリ
	に引数として引き渡すパイプ処理が出来ないかと。
	しかし、色々仕様を検討してみたのだけど、結局 それをやろうと思っても、
	”メモリのファイル出力＋コマンド実行”の２段階のコマンド引数が並ぶだけで、
	ややこしい上に汎用的なりえないと判断。
	メモリの切り出しはそれ用の "getbin" でやってもらうようにする。
	そこで問題になるのは外部コマンドの実行部分。
	例えば、メモリ内からグラフィックの部分だけ引っ張り出して、外部アプリを
	使用して圧縮したいとき、どの様な操作が必要になるか。
	外部コマンドの実効命令を "!"、外部ツールに "p6tool.exe" というファイルを
	利用すると仮定して…

	getbin vram.bin 0x0000 0x3fff
	! p6tool vram.bin

	この様に入力実行出来るのが理想的。
	それでは、ツールの存在するディレクトリや結果ファイルが出力されるのは
	どこのディレクトリにするのか？
	現状の "getbin" の仕様はロード用のTAPEパスがターゲットパスになっている。
	では、「TAPEが設定されていない場合は？」「 出力先を変えたい場合は？」
	「ツールは必ずTAPEパスに置かねばならないのか？」「テープイメージの存在
	しないフォルダは作業に利用できない？」、等々、融通の利かない部分が
	出て来てしまうので、この際だからモニタモードで利用するテンポラリパスは
	TAPEパスと無関係に独立して設定出来るように改変することにする。

	"getbin" も "bat" も "!" も、全てそのフォルダをカレントとして、
	ファイルを入出力出来るようにしておいて、モニタモード中からでも
	そのパスを変えられるようにしておけば、作業効率は随分良くなるかな？

	あ、でもそれだとAllegroメニューにもパス選択出来るダイアログを用意しないと。
	Windows標準ダイアログでは直ぐにフォルダ選択ダイアログを出せるんだけど、
	フルスクリーン動作中Windows標準ダイアログが出てくると、Allegroのスレッド
	管理の問題で解像度がデスクトップに戻って妙な事態に陥ってしまう…(´･ω･`)


	・モニタモードに更に幾つかコマンド追加。
	開発用フォルダの独立に併せてファイル出力系のコマンドも一括修正。
	って、URLの変更コマンドを入れたは良いけど、Allegroは標準状態だと文字入力が
	化けてしまって、コロンとかバックスラッシュとか入力できない…orz
	必要記号が入力できるよう、変換テーブルも作る必要もあるなぁ。
	他、"getbin" のメモリ取得がメモリマップからの取得になっている不具合。
	本来は RAMからの取得なので、その様に修正。
	外部コマンド実行は CreateProcess でプロセス立ち上げているのだけど、
	拡張子不要で ".exe",".com" も ".bat" も実行できるのかと思っていたら、
	".bat" だけは拡張子まで入力する必要が有る事が判明。
	考えてみれば、".bat" の実行にはコマンドプロンプトを立ち上げる必要があるから、
	拡張子関連付けで判別させないといけないのか。


	・開発支援ファイルは開発フォルダに出力するとして、ログの類はどうしよう？
	開発フォルダに出すようにしてしまうと開発フォルダの移動と共に出力場所が
	変ることになって継続性が保てない。かといってエミュレータの実行ファイルが
	存在するカレントフォルダは普段開いていないだろうし…やはり、デスクトップに
	出した方が扱い易い様な気がするが…これもオプションにフォルダ設定を用意して
	任意の場所に出力できるようにした方が良いかな？




■2005.04.29 ver 200 
	・エミュを擬似ステレオモードで起動してテープロードを行うと、音が左からしか
	出てこない不具合を調査。
	サウンドストリームの設定状態をログに吐いてみたところ、チャンネルとPANの
	対応は正常に行われている。

	[STREAM-CH]    [PAN]
	--------------:-------
	0:PSG(L)      :LEFT
	1:FM(L)       :LEFT
	2:PIGAGA      :CENTER
	3:VOICE       :CENTER
	4:PSG(R)      :RIGHT
	5:FM(R)       :RIGHT
	6:----        :CENTER
	7:----        :CENTER
	8:SYSTEM-SE1  :CENTER
	9:SYSTEM-SE2  :CENTER

	ところが、ピーガーをサウンドバッファに書き込む直前にPANを設定し直しても、
	必ず左に振り切れてしまう…というより、右チャンネルが出てない？？？
	不可解な現象なのでサウンドミキサーの内部に網を張って、DirectSound に
	データを吐き出す前に左右の音を捕まえてみたら…ぐはぁっ！(;~Д~)
	中央の音を左右バッファに振る為にデータの桁落としするとき、ピーガーの
	ボリュームが余りに小さく設定され過ぎているもので、ビットシフトで
	右チャンネル分のデータが綺麗サッパリ消え去ってしまう。
	そりゃなぁ、ピーガーの波形は単純なノイズ波形と言っても良いから、
	どれだけボリュームを小さくしても大きな音に聴こえてしまう為に
	5/100 まで下げているのだけど、これで左右分割の計算を行うと切捨て扱いの
	レベルにしかなっていないという事か。
	そういう事で、ピーガーの波形を作る時点で波形のレベルを 1/2 にしておいて、
	ボリュームを切り捨てされない 10/100 程度になるよう設定しなおし。

	まぁ、以上の理由で、擬似ステレオを選択してある時、ボリュームを 6 以下に
	設定したりすると、右チャンネルの音が先に消滅して左からしか音が聞こえなく
	なりまっす(;ﾟ∀ﾟ)ｱﾘｬ。
	この現象はPSG/FMもVOICEも同様に発生(モノラルでは問題なし)。



	・そろそろドキュメントを整備しないとならない時期。
	これがまた大仕事で、色々と改造を加えた箇所を思い出しながら噛み砕いて
	書かければならない。内包ドキュメントもかなり手を入れる必要があるなぁ。
	「 勘で使いこなして頂戴  (*ﾟ∀ﾟ)ﾃﾍ 」の一言で済めば楽なのだけど(笑。

	そこで、ドキュメントを改定するにあたって、インターネットユーザーの
	解像度統計を引用してみる。

┏━┳━━━━━━┳━━━┓
┃  ┃ 解  像  度 ┃  率  ┃
┣━╋━━━━━━╋━━━┫
┃ 1┃ 1024×768  ┃41.2% ┃
┃ 2┃ 1280×1024 ┃23.8% ┃
┃ 3┃ 1152×864  ┃ 3.8% ┃
┃ 4┃ 1600×1200 ┃ 2.7% ┃
┃ 5┃ 1400×1050 ┃ 2.6% ┃
┃ 6┃  800×600  ┃ 2.3% ┃
┃ 7┃ 1280×768  ┃ 1.5% ┃
┃ 8┃ 1280×960  ┃ 1.5% ┃
┃ 9┃ 1600×1024 ┃ 0.6% ┃
┃10┃ 1280×800  ┃ 0.3% ┃
┗━┻━━━━━━┻━━━┛

	6年前に確認した時は 1280x1024 の解像度が圧倒的だったのだけど、
	今は1024x768 が大幅に増えている。
	これは液晶ディスプレーとノートPCの普及の表れなのかな？
	それと欧米の解像度は 1024x768 程度で、日本・中国・台湾など漢字を使う
	国だと、小フォントサイズでは文字が潰れてしまうので必然的に解像度が
	高くなる傾向があるみたい。
	以上の参考値を踏まえて、以前は WIDTH:1240 の解像度を基準にしていた
	レイアウトを作っていたのだけど、今度は WIDTH:1024 以下の事も考えて
	こじんまりと配置してみようと思ったりして…。

	備考：少数派解像度
┏━┳━━━━━━┳━━━┓
┃  ┃ 解  像  度 ┃  率  ┃
┣━╋━━━━━━╋━━━┫
┃11┃ 1440×900  ┃ 0.2% ┃
┃12┃ 1760×1320 ┃ 0.2% ┃
┃13┃ 1280×854  ┃ 0.2% ┃
┃14┃  640×480  ┃ 0.1% ┃
┃15┃ 1680×1050 ┃ 0.1% ┃
┃16┃ 1920×1200 ┃ 0.1% ┃
┃17┃ 2560×1024 ┃ 0.1% ┃
┃18┃ 1920×1440 ┃ 0.1% ┃
┃19┃ 1280×600  ┃ 0.1% ┃
┃20┃ 1024×600  ┃ 0.1% ┃
┃21┃ 1024×480  ┃ 0.1% ┃
┃22┃ 1280×720  ┃ 0.0% ┃
┃23┃ 2048×768  ┃ 0.0% ┃
┃24┃ 1152×768  ┃ 0.0% ┃
┃25┃ 1152×870  ┃ 0.0% ┃
┃26┃  640×240  ┃ 0.0% ┃
┃27┃ 1408×1056 ┃ 0.0% ┃
┃28┃ 2048×1536 ┃ 0.0% ┃
┃29┃ 1152×783  ┃ 0.0% ┃
┃30┃ 1200×900  ┃ 0.0% ┃
┃31┃ 1168×696  ┃ 0.0% ┃
┃32┃ 1440×1920 ┃ 0.0% ┃
┃33┃ 1856×1392 ┃ 0.0% ┃
┃34┃ 1024×512  ┃ 0.0% ┃
┃35┃ 1152×900  ┃ 0.0% ┃
┃36┃ 1360×1024 ┃ 0.0% ┃
┃37┃ 1024×1280 ┃ 0.0% ┃
┃38┃ 768×1024  ┃ 0.0% ┃
┃39┃ 1408×1024 ┃ 0.0% ┃
┃40┃  960×720  ┃ 0.0% ┃
┃41┃ 2560×1600 ┃ 0.0% ┃
┗━┻━━━━━━┻━━━┛

	640×240 の解像度だとネット閲覧が大変そうだなぁ。
	でも、PocketPC などで定量制接続を使って出先でメールやサイトのチェックが
	できるのは便利で良い。ノートPCのPCカードスロットにPHS挿してダイヤルアップ
	やるのは色々な意味でしんどかった。特に新幹線車中。



■2005.04.28 ver 200 
	・何気に手にとったMSX-FANにソーサリアンのOP譜面が載っていたのでFM音源を
	使ったサンプルを作ろうと思ったのだが…。
	SR-BASICのMMLってタイが無いのか…う、相対音階も無いか…Σ(ﾟДﾟ;)
	HARDエンベロープとソフトエンベロープを組み合わせようと思っても、
	HARDの方はボリュームの融通が利かずにATTACKがかかっちゃうしなぁ。
	これじゃFMとPSGの音量バランスも取れない…。
	まぁ、いいや。とりあえずのサンプルだし。

	で、ソーサリアンに近い音色を作ろうと思ったのだけど、FM音源パラメタ、
	コレが何ともワケワカラン。MSXでFM-PACを使っていた時は殆ど既存音色しか使って
	なかったし、PC98の86ボード(YM2608)も専らアセンブラでJOYSTICKポート叩いたり
	パソ通でダウンロードした曲を演奏するだけで音色自体は余り弄った経験が無い。
	コレは困った…。
	という事で、よっしゅさん作のFM音源トーンエディタを使って、試行錯誤で
	どうにかしてみる。弄りながら調整できるので、これが一番手っ取り早い。
	ところで、作成した音色をどうやって取り出そうかと考えた末、エミュの
	モニタモードからYM2203のレジスタを読んで、チップに登録されたOPの内容を
	BASICのトーンテーブル仕様に並べたDATA分を直接出力するコマンドをに追加。

	ううむ…趣味に走りすぎかな？
	一応、開発支援機能にはなるか。


■2005.04.21 ver 200 
	・タイマー割込のフラグ処理を追いかけてみると、タイマーの間隔が短い時は
	割り込みのオーバーライトが結構頻繁に発生している事がわかる。
	どういう事かというと、通常、タイマー割込は定期的にトリガーが発生して
	いるのだけど…

	 Timer       Timer       Timer       Timer       Timer        [トリガー]
	━╋━━━━━╋━━━━━╋━━━━━╋━━━━━╋━━━＞ [時間経過]
	  ┃          ┃          ┃          ┃          ┃        
	  ┗INT_06    ┗INT_06    ┗INT_06    ┗INT_06    ┗INT_06    [TIMER割込]

	タイマー割込が発生するタイミングに割込禁止[DI]状態で何かやっ
	ていると、
	現状のエミュの仕様だと割込解禁[EI]になった状態で前のタイマーが遅延して
	発生して、その次の割込みは何事も無かったかのように規定のタイミングで
	発生する。

	 Timer       Timer       Timer       Timer       Timer        [トリガー]
	━╋━━━━━╋━━━━━╋━━━━━╋━━━━━╋━━━＞ [時間経過]
	  ┃    [DI]----[EI]      ┃          ┃          ┃          [CPU]
	  ┗INT_06        ┗INT_06┗INT_06    ┗INT_06    ┗INT_06    [TIMER割込]
	                    ↑遅延

	この[DI]期間が2回目の割込みに掛かかると…

	 Timer       Timer       Timer       Timer       Timer        [トリガー]
	━╋━━━━━╋━━━━━╋━━━━━╋━━━━━╋━━━＞ [時間経過]
	  ┃    [DI]----------------[EI]      ┃          ┃          [CPU]
	  ┗INT_06                ↑  ┗INT_06┗INT_06    ┗INT_06    [TIMER割込]
	              トリガ上書き↑    ↑遅延

	こうなって一回分の割込みがスキップされた形になる。
	単純に疑問に思ったのは、タイマー割込を遅延発生させて良いのかどうか。
	これだけ、エミュと実機のタイミングのズレが顕著に現れてくると、何かの
	仕様が間違っている可能性も無きにしも非ず。
	タイマーを発生させるトリガーはクリスタルから直接Z80に繋がっていて、
	CMTやキーボード割込の様にSUB-CPUに入ってから順番で発生するわけでは
	ないので、遅延が効いて良いものかどうか…？
	もし、遅延が効かないとするとCPUが [DI] の最中に発生したトリガーは
	完全に無視されるのだろうか？

	 Timer       Timer       Timer       Timer       Timer        [トリガー]
	━╋━━━━━╋━━━━━╋━━━━━╋━━━━━╋━━━＞ [時間経過]
	  ┃        [DI]--------------[EI]    ┃          ┃          [CPU]
	  ┗INT_06                            ┗INT_06    ┗INT_06    [TIMER割込]


	でも、CPUはバンク切り替えだのその他の割込処理で常時[DI][EI]を繰り返して
	いるから、[DI]時のトリガー無視ってのも考え難いんだよなぁ。

	…と、なんとも単純な疑問点をメモっておく。



■2005.04.20 ver 200 
	・先のスペハリBGMの演奏時間が実時間とエミュレータ時間の一致を得たことから、
	タイマー値を 487[Hz] に固定し、CPU:100[%],TIMER:100[%] 無調整の状態で
	今度はBASICのCPU/TIMERテストプログラムが実機の測定結果に近づくよう
	CPU稼働率の方を調整してみる。

	10 A=TIME:C=0:CLS
	20 B=INT((TIME-A)/975):C=C+1
	30 LOCATE0,0:PRINT C;B
	40 IF B<60 THEN 20

	約一分間でどれだけBASICカウンターが回るか測定するアバウトなものだけど、
	目安としてはこれで十分。因みに実機で測定した結果は下の通り。

	┏━━┳━━━┳━━┓
	┃機種┃モード┃結果┃
	┣━━╋━━━╋━━┫
	┃mkII┃ N60  ┃517 ┃
	┃    ┣━━━╋━━┫
	┃    ┃ N60m ┃375 ┃
	┣━━╋━━━╋━━┫
	┃6601┃ N60  ┃516 ┃
	┃    ┣━━━╋━━┫
	┃    ┃ N66  ┃376 ┃
	┣━━╋━━━╋━━┫
	┃ SR ┃ N60  ┃500 ┃
	┃    ┣━━━╋━━┫
	┃    ┃ N66  ┃380 ┃
	┃    ┣━━━╋━━┫
	┃    ┃ N66SR┃974 ┃
	┗━━┻━━━┻━━┛

	このプログラムをCPU稼働率をチマチマと変えながらビルド＆テストの繰り返し。
	最終的にはこうやって手動で調整しなきゃダメなのねん。
	試行錯誤を繰り返した結果、N60/N60mモードに関しては下の稼働率でほぼ固まった。

	N60モードの稼働率  = 0.461291304; →46.1291304 [%]
	N60mモードの稼働率 = 0.352048964; →35.2048964 [%]

	この小数の異常な細かさは何かというと、テストでZ80の実行命令数
	の累積カウンターを取ったりしてテストプログラムが規定の結果に近づく
	ように大まかに逆算した名残で、実際のCPUクロックは 10^6 の桁だから、
	そこから算出される1/1000単位のタイマークロックの有効桁数から考えると、
	小数4桁辺りまでしか必要ないのだけど…。

	CRT_KILL時の稼働率はボスコニアンの "BLAST_OFF" 発声時間を測定して、
	算出したところ、 70.27188 [%] という数値が出てきたのでその様にしてみた。
	これは N60 でも N60m でも同じ数値にしてしまって良いのかな？
	N60モードでの時間的目安が無いのでアバウトな感じはするけど…。

	さて、このCPU稼働率を組み込んで、今度は目安となるゲームを動かしてみる。
	  →BASICテストプログラムは勿論バッチリ。                …○
	  →スペハリBGMの演奏時間の実機/エミュ比はほぼ完璧に一致  …○
	  →スタフリのOPデモの画面と曲のタイミング一致            …○
	  →マッピーボーナスステージのゲームと曲のタイミング      …×
	アカン。マッピーは相変わらずBGM演奏が早く終わってしまう…＿|￣|○、

	マッピーとそれ以外のソフトの動作条件の違いは、他のソフトはSTICK割込が
	入らないこと。スペハリはBGMを録音するために開始と同時にポーズを
	かけるのでSTICK割込は起こっていない。
	タイマーの基本周波数は実時間と整合の取れたこの値で決定したいので、
	ゲームの動作を速くしてBGM演奏時間内に全ての風船を取れるように
	持って行けるかどうかという所…。
	という事で、ゲームの動作で足を引っ張ると思われるのがSTICK割込の
	発生ディレイ。これは、コロニーオデッセイにも入っているNECのテニスが
	ディレイを想定したプログラムの作りになっているので、その状況証拠を
	取り込んで SUB-CPU に STICK割込を要求してから実際に割込が発生するまでに、
	意図的にある程度の間を空けるようにしている。
	時間的にはMSXの割込仕様を模して、VSYNC間隔だけ間を空けてSTICK割込を
	出すようにしているのだが、これをテニスのスイングが正常に出来なくなる
	ギリギリまで短く縮めてみた。
	そこで VSYNCの1/32 までは間隔を短くする事は出来たのだけど、それでも
	依然ゲームの進行速度よりBGMの方が速く終わってしまう。
	他にどういう条件が関係しているのか分からないけど、現状判明している
	仕様だけでは改良の加えようが無い。
	(今判明している不確定要素は謎の割込みだけ？)

	しゃーない。前と同様、io_F6Hの値を割増して、タイマー値が大きくなるほど
	間隔が大きくなるように弄るしかないね。
	理屈はともかく、現物のソフトはマトモに動くようにしたいし…。
	少なくとも io_F6H=14 時のスペハリのBGM演奏時間の一致から考えると、
	io_F6H=14 の時点で割増されるのは不味い…。マッピーのタイマー値 61 の
	時に ナンボか数値が加算される様に割増だ。

	実際、タイマー間隔に反映される値は…
	io_F6H_adjust = (int)(1.067*(double)io_F6H);
	この程度で良いだろ。
	この式だったらスペハリのBGMは遅くならないで、
	io_F6H_adjust = (int)1.067*14 = 14;
	マッピーのBGMは遅くなる。
	io_F6H_adjust = (int)1.067*61 = 65;
	こういう寸法でさぁ、旦那 (*ﾟ∀ﾟ)ｱﾋｬﾋｬﾋｬﾋｬ


	結局、現状はこうするしかないか…。 
	SRの稼働率は後日調整。




■2005.04.18 ver 200 
	・CPU/タイマー割込比に再び問題発覚。
	現状はスタフリ(タイマー値：io_F6H=3 )とマッピーボーナスステージ(io_F6H=30)
	だけ目安に比を調整してあるのだが、それだと スペハリ(io_F6=14) でBGM演奏が
	実機より遅くなっている事に気付いた。

	実機から録音したBGMとエミュ演奏のWAVを波形エディタに放り込み、特定の曲の
	区切りの時間を基準に比較してみたところ、タイマー値(io_F6H)の補正無しで、
	io_F6H=14 (15/2048[sec]) タイマー基本周波数 487[Hz]( CPUクロックの13分周
	=(3993600/(2^13)) )CPU:100[%],TIMER:100[%] でほぼ同等の長さになっている。

	基本周波数を512[Hz] にしていた時の参考値ではあるけど、

	スターフリートでは…
	io_F6H=3 (→1/512[sec]), cpu_adjust =80 [%],timer_adjust =69 [%]

	マッピーボーナスステージでは…
	io_F6H=30 (→31/2048[sec]), cpu_adjust =80 [%] ,timer_adjust =79 [%]

	…の補正が必要だった事を考えると、単純な比で調整できるモノではないのかな。


■2005.04.09 ver 200 
	・滲み色変更、BASICテストプログラム。

10 CONSOLE,,0,0:SCREEN4,2,2
20 COLOR,,2:CLS
30 FOR I=0 TO 29 STEP 2
31 LINE(I,0)-(I,192),1
32 NEXT
40 FOR I=31TO 63 STEP 2
41 LINE(I,0)-(I,192),1
42 NEXT
50 FOR I=64TO 96 STEP 1
51 LINE(I,0)-(I,192),1
52 NEXT
55 A=0:OUT&H20,0
60 EXEC&H1058:IFSTRIG(0)=0THEN60
65 A=A+1:IF A>2 THEN A=0
70 B=A:IFA>0THEN B=(B-1)*2+1
71 REM GREEN/PINK ｦ ﾂｶｲﾀｲﾉﾃﾞ
72 REM ﾂﾈﾆ bit2 ﾊ ﾀﾃﾃｵｸ｡
73 OUT&H20,B+4
80 PLAY"o6a64":GOTO60


	・PAN設定、BASICテストプログラム。

5 CONSOLE,,0,0:CLS:DIM X(3)
10 SOUND 6,0
30 SOUND 0,&H1B:SOUND 1,&H01
31 SOUND 2,&HE2:SOUND 3,&H00
32 SOUND 4,&HBD:SOUND 5,&H00
50 SOUND8,12:SOUND9,12:SOUND10,12
51 GOSUB 170
54 PRINT:PRINT"[UP][DOWN]:SELECT-CH"
55 PRINT"[LEFT][RIGHT]:MOVE-PAN"
56 PRINT"[SPACE]:RANDOM-PAN"
60 X(0)=5:X(1)=5:X(2)=5:Y=0:GOTO 100
70 S=STICK(0):IF STRIG(0)=1 THEN 140
72 IFS=0THEN70
75 A$="-":IFX(Y)=5THEN A$="+"
77 LOCATEX(Y)+7,Y:PRINT A$;
80 X(Y)=X(Y)+(S=7)-(S=3)
81 X(Y)=X(Y)+(X(Y)>10)-(X(Y)<0)
90 Y=Y+(S=1)-(S=5)
91 Y=Y+(Y>2)-(Y<0)
100 FOR I=0 TO 2
101 OUT&HAE,I   :REM SELECT CH
102 OUT&HAF,X(I):REM SET PAN
103 COLOR 1:IF I=Y THEN COLOR 2
104 LOCATEX(I)+7,I:PRINT "O";:COLOR 1
105 NEXT
130 GOTO 70
140 FORI=0TO2:X(I)=INT(RND(1)*10):NEXT
150 GOSUB170:GOTO 100
140 FORI=0TO2:X(I)=INT(RND(1)*10):NEXT
170 FOR I=0 TO 2:LOCATE0,I
171 PRINT"CH";I;" L:-----+-----:R"
172 NEXT:RETURN



■2005.04.08 ver 200 
	・機能リクエストに出てきた、色化けの色調変更等のエミュレータ独自I/Oの
	実装を検討してみる。
	以前から計画しているフリーの独自BIOS(妄想)と、将来のPC-6001mkIIIの設計
	(大妄想)まで考慮しなきゃいけませんねぇ (*ﾟ∀ﾟ)ｴﾍﾍ
	妄想はともかくとして、この辺の特殊機能はP6VW単独でやっても旨味が無いので、
	他のエミュとコンセンサスを図る必要がある。
	それとP6VWの奇特な機能は後ろの方をコソコソと使うと…。

	6001/mkII/SR で開いているポートは 0xH〜3xH,5xH,7xH。
	大雑把に用途で区分けするとして、

	00H:システム・デバイス関係
	10H:メモリ関係
	20H:グラフィック関係

	とりあえずこの程度で良いや。
	サウンドは AxH の後方に空きがあるのでここを利用する。
	YM2603を拡張実装(妄想)したとしても十分対応できるくらいの空きもあるし。
	先ずは…

// PORT(20H) N60-SCREEN4カラーセット設定
//  bit 0=  0:モノクロ、1:滲み有効
//  bit 1=  0:[01:赤系-10:緑系]、1:[01:緑系-10:赤系]
//  bit 2=  0:赤&青、1:ピンク&緑 
//       (P6V系は固定パレット選択があるので bit2 を色選択に利用。)

static void out_20(byte data){
    int  col;

    if(data&1)  col=1+((data&6)>>1);   //カラーセット
    else        col=0;                //モノクロ

    // モード４カラーモード設定
    //  0:モノ 1:赤/青 2:青/赤 3:ピンク/緑 4:緑/ピンク
    set_mode4color(col);
}

static byte in_20(void){
    int  col;
    byte data;

    //モード4カラー取得
    //  0:モノ 1:赤/青 2:青/赤 3:ピンク/緑 4:緑/ピンク
    col=get_mode4color();

    if(col==0)  data=0;
    else        data=((col-1)<<1)+1;

    return data;
}

	こんなポートを用意してみる。
	ip6系は「色化フラグ＋パレット設定」、p6v系は「固定パレットセット選択」
	なので、共通のIFを設けるならこんな感じになるかな。

	10 PRINT "[ SELECT SCREEN4_COLOR_SET ]"
	11 PRINT "0:MONO,1:RED/GREEN,2:GREEN/RED"
	12 PRINT "Input No.";:INPUT A
	13 IF A>0 THEN A=A+1
	14 OUT&H20,A

	もう一つ、オマケ機能の SOUND-PAN 設定ポートも用意してみる。

// OUT(AEH) PAN設定チャンネル番号指定
//  0-2:PSG, 3-5:FM
static void out_ae(byte data){
    if(data>5)data=5;
    io_AEH = data;
}
// OUT(AFH) PAN設定
// LEFT<-------CENTER------>RIGHT
//  [0],1,2,3,4,[5],6,7,8,9,[10]
static void out_af(byte data){
    if(data>10)data=5;
    InIn.sound_pan[io_AEH] =data
}
// IN(AEH) PAN設定チャンネル番号
//  0-2:PSG, 3-5:FM
static byte void in_ae(void){
    return io_AEH;
}
// IN(AFH) PAN
// LEFT<-------CENTER------>RIGHT
//  [0],1,2,3,4,[5],6,7,8,9,[10]
static byte in_af(void){
    return InIn.sound_pan[io_AEH];
}

	BASIC で設定を行う例。 

	10 REM --- SET PSG_PAN ---
	11 OUT&HAE,0:OUT&HAF,3
	12 OUT&HAE,1:OUT&HAF,7
	13 OUT&HAE,2:OUT&HAF,5
	14 REM --- SET FM_PAN ---
	15 OUT&HAE,3:OUT&HAF,0
	16 OUT&HAE,4:OUT&HAF,10
	17 OUT&HAE,5:OUT&HAF,5

	しかし、PSG +FM = 6ch でPAN振っても寂しい限りだ (;´Д｀)。
	その内、ディレイワイドでも作ってみようかな。
	何か物凄く趣味に走っているような気もするけど…。



■2005.04.05 ver 200 
	・Moriyaさんのio_F6Hポート値タイマー割込相関関係の実機測定結果を元に、
	基本タイマー周波数を計算してみる
	6001のプログラム本に書いてある理論値では io_F6H =3 の時に
	512 [Hz] でタイマー割り込みが発生する事になっている。
	なので io_F6H と割込間隔の関係式はこうなる。

	割込間隔 [sec]： t= (io_F6H+1)/(512*4)

	周波数を導く形だとこうだ。

	タイマー基本周波数 [Hz]： 512= (io_F6H+1)/(t*4)

	そこで、測定結果の t と io_F6H の値からタイマー基本周波数を
	逆算してみるとこうなる。

(PC-6001SR,MODE:5)
┏━━━┳━━━┳━━━━━━┓
┃io_F6H┃ μs  ┃Timer基本Hz ┃
┣━━━╋━━━╋━━━━━━┫
┃  20  ┃10521 ┃ 499.002    ┃
┃  10  ┃ 5529 ┃ 497.37746  ┃
┃   5  ┃ 3008 ┃ 498.67021  ┃
┃   4  ┃ 2508 ┃ 498.4051   ┃
┃   3  ┃ 1996 ┃ 501.002    ┃
┃   2  ┃ 1484 ┃ 505.39084  ┃
┃   1  ┃ 1014 ┃ 493.09665  ┃
┃   0  ┃  512 ┃ 488.28125  ┃
┣━━━┻━━━╋━━━━━━┫
┃    平  均    ┃ 497.65319  ┃
┗━━━━━━━┻━━━━━━┛

	基本周波数は平均して 498 [Hz]。
	512[Hz] に全然届いていない Σ(ﾟДﾟ;)ガーン。
	まぁ、本来 io_F6H が 3 未満なんて使わないから、
	それ以上の平均を取っても、498.8914。

	ううむ…(;ﾟДﾟ) そういう事か…。これはSRの互換モードでのデータだけど、
	これじゃぁ、理論周波数を元にタイマーを出していたらマッピーのボーナス
	ステージは間に合わなくなりますなぁ。
	( 512 / 498.8914 ) = 1.02628
	実機のタイマー割込間隔は理論値よりも 2.6% も遅いという事になる。
	たかが 2.6%、されど 2.6%。1分間で1.56秒、2分間だと 3.12秒の誤差ですよ。

	もういっちょ、MODE:6 の統計。
	MODE:6 は MODE:5 よりタイマー精度が高く、io_F6H =127 で 512[Hz] となるので、
	割込間隔の関係式はこうなる。

	割込間隔 [sec]： t= (io_F6H+1)/(512*128)

(PC-6001SR,MODE:6)
┏━━━┳━━━┳━━━━━━┓
┃io_F6H┃ μs  ┃Timer基本Hz ┃
┣━━━╋━━━╋━━━━━━┫
┃ 240  ┃ 3763 ┃ 500.34879  ┃
┃ 160  ┃ 2508 ┃ 501.52014  ┃
┃ 127  ┃ 2000 ┃ 500        ┃
┃ 120  ┃ 1894 ┃ 499.10903  ┃
┃ 112  ┃ 1766 ┃ 499.89383  ┃
┃ 104  ┃ 1638 ┃ 500.80128  ┃
┃  96  ┃ 1510 ┃ 501.86258  ┃
┃  88  ┃ 1408 ┃ 493.8299   ┃
┃  80  ┃ 1267 ┃ 499.45738  ┃
┃  72  ┃ 1139 ┃ 500.71335  ┃
┃  64  ┃ 1011 ┃ 502.28734  ┃
┃  56  ┃  896 ┃ 497.00056  ┃
┃  16  ┃  265 ┃ 501.17925  ┃
┣━━━┻━━━╋━━━━━━┫
┃    平  均    ┃ 499.84642  ┃
┗━━━━━━━┻━━━━━━┛

	こりゃあ、500 [Hz] で決定だな。
	6001シリーズのタイマー基本周波数は実は  500 [Hz]  というオチでした。
	(SRの場合)


■2005.04.03 ver 200 
	・つД`)ｳｯｳｯｳｯ、重いよ…重すぎるよ。
	そりゃ、mkIIモードでしか動かさなかったり、ステレオ切ったり、フレーム
	スキップ上げたりすればそれなりの速度で動くけど、それだと開発に都合が悪い。
	ということで、サウンドのサンプリングレート設定を再導入。
	以前、不必要になって削った機能がまた戻りつつあるってのも皮肉な話。
	あ、そうか…サウンドレコードのWAVヘッダも可変周波数になるように
	直さないといけないな。
	それにしても、システムメニューはギチギチでスペースが無い。

	正直、オプションメニューにタブページは増やしたくないしなぁ…。
	パッ見、一画面で大体のオプション設定が出来るようにはしておきたい。
	目的の操作に至るまでのプロセスは出来るだけ省いておいた方が
	慣れた後の使い勝手が良いだろうしね。


	・擬似ステレオのPAN設定を再考してみるのだけど…。
	ステージの演奏を聞くように平面的な発生源を想定するか、空間的な発生源を
	想定するか…左右に振ったチャンネルの総音量を固定にするとヘッドフォンを
	付けた頭をグルリと音が回り込むような左右両方の音をピンポイントで録音する
	ダミーヘッド型になり、中央から離れるにつれてボリュームを減らすようにすると
	左右チャンネルが遠くに離れて行く平行移動の音源になる。
	いや、ダミーヘッド云々といっても別に人の声や自然音のライブ録音を
	流すわけじゃないし、空間的な意味合いは無いはずなのだが…
	でも一般のポピュラー音楽と違ってこのケースの場合、音のチャンネルが
	少ないからどうしても個別の音の発生位置を意識する事になっちゃうんだよね。
	ビートルズの時代なんか２マイク録音だから、楽器ごとのPANが固定していて
	非常にハッキリしているという…あんな感じかな？
	音源との距離はチャンネルのボリュームで調整できるから、システムで意図的に
	ボリュームにチョッカイ出す必要は無さそうですな。


■2005.04.02 ver 200 
	・ここしばらくの間、MSXの方でYM2413とSCCを弄くって色々音の研究
	やってたりして…(;´∀｀)ﾃﾍ
	そして、長らく計画していた(秘)プランを実行。
	サウンドのチャンネル毎にPANを設定。
	あっひゃっはｙっはｙはhｙあｙｓぐあｂｄｈじゃかｓｃ…！！！！
	益々、動作が重くなりましたよ、奥さん！
	オプションでモノラルとステレオを選択できるようにしておかないと
	いけないなぁ…。もはや、Pen2-300じゃPSGオンリーステレオも100%で
	動かないのデス(;ﾟ∀ﾟ)


■2005.03.27 ver 200 
	・BGMが鳴っている最中のどこでもセーブ・ロードをどうにかしたいので、
	レジスタ復帰部分の見直し。とは言ってもPSGと違って生成途中の波形を
	復帰させるにも限界があるのだが…。
	モードとレジスタを復帰させて、チャンネル接続とワークエリアを書き戻して、
	後必要なものは……FMタイマーのカウンターはレジスタ復帰でリセットされるし
	特に無いかな？
	それにしてもレジスタを全て書き戻しているのに音色が変ってしまうのは何なんだ？


■2005.03.26 ver 200 
	・昨日に引き続き、FM音源の復帰部分をデバッグトレース。
	延々パラメタ設定のプロセスを追い掛け回していたら、どうもそこかしこで
	パラメタ構造体の直接アドレスでなくスタティク変数を参照している箇所が
	ある事に気付く。このスタティック変数は音源チップを複数持っている時の、
	現在処理中のチップの構造体アドレスを便宜上保持しておく変数のようだ。
	どこでこの変数が初期化されるのか探してみると、チップの波形更新の所で
	代入されている事が判る…。って事は、そうか音源チップのモード・レジスタ
	の更新は、マルチチップの仕様としては駆動させるチップが決まってから
	でないと、どのチップのパラメタを書き換えて良いのか不確定なのか。
	なので動作チップを確定させてからパラメタ反映プロセスを通す必要があると。
	判明してみれば至極当然の事だ (;ﾟ∀ﾟ)。
	SRではYM2203チップ1つしか使用しないので、どこでもロード時に0番チップの
	構造体アドレスをスタティックのワーク変数に放り込んでからパラメタ復帰
	ルーチンを通すことでこの問題は解決。


	・そして、1つ問題解決されると次の問題が発生すると…＿|￣|○、
	どこでもロードで状態復帰後、VRTCやTIMERなど時間経過による割込みが
	常に発生したままの状態に陥る不具合を調査。
	何の事はない。VRTCやTIMER割込みを発生させるカウンタ値が全て0に
	なってしまっている。というか、CPU駆動率が零になっているのか。
	CRT_KILL時の計算式が (double) にキャストされずに、小数点の駆動率が
	(int) 変換で 0 になってしまっただけだ。
	根深い問題じゃなくて良かった…(;ﾟ∀ﾟ)


■2005.03.25 ver 200 
	・SR用のどこでもセーブ・ロードで復帰時に例外エラーが出る不具合を調査。
	原因箇所はFM音源の復帰部分。YM2203用の各種構造体をセーブデータから
	読み込んで、モード・レジスタに書き出して状態を復帰させようとするのだが、
	そこで本来設定されているハズの波形生成の関数やエフェクターのアドレスに
	出鱈目な値が入っていて、アクセスエラーが出ている。
	手続き的にはCPUがI/Oポート経由で音源のパラメタを設定するのと同じ手順を
	辿っている筈なのに何故こうなるのだ？


■2005.03.18 ver 200 
	・YM2203のCSMモードの見直し。
	とにかく出力される波形とパラメータの遷移を全てログに記録して、
	精査してみたのだけど、明らかにアタックが掛かった瞬間出力レベルが 0 に
	落ちてしまっている…

	というか、デバッグで追いかけてみると一度アタックが発生した後、
	次のアタックが設定できない。if else で全て弾かれてしまう。
	そもそも指定ボリュームが64以下だとアタックが設定できないようだけど…
	何でしょ、コレ？ 非常に奇妙な仕様だ。
	アーケードの場合、こんなんで大丈夫なのかな？
	少なくともPCだと都合が悪いので、この条件分岐を撤去。

	うわぁお。難航すると思いきやアッサリ直ってしまった…(;ﾟ∀ﾟ)ｲｲﾉｶﾅ?


■2005.03.06 ver 200 
	・Hashiさんからトラブルシューティングとして、TRACERのロード中画面の話が
	出たので思い出したのだけど、以前、これには対処した事があるんだよな。
	ブロック転送命令中はCMT割込を発生させないという単純なやり方なのだけど、
	ブロック転送中でもタイマー割込は発生する事から、こんな事あり得ないだろう
	思って該当ルーチンはコメントアウトしてしまった。
	でも、まぁ、ロードしながら画面スクロールするソフトなんて TRACER か EGGY
	ぐらいしか知らないし、理屈はともかくとして有効にしておいても良いかな？



■2005.03.03 ver 200 
	・もうすぐ例の書籍発売で今世紀最大のP6祭なのだが…(´･ω･`)
	いますぐ準備できるような宣伝のネタってのも特に無いし…。
	SRの実装にはもう少し時間がかかりそうだが、現仕様を旧機種だけに反映させる
	モノならすぐに用意できそうだ。SUB-CPUやUIの方も弄りまくったから、
	既存機能のテストも兼ねてリリースしてみようかな…。
	色々注文された機能も盛り込んであるし。

	SRの懸案はどこでもセーブとか機種の切り替えなど、メモリ関係の部分。
	これがまた色々複雑で…(^^;;



■2005.02.29 ver 200 
	・ゆみたろさん情報によると、6001のメモリアクセスはRAMアクセスが
	ノーウェイト、ROMアクセスが1クロックウェイトという事らしい。
	ううむ…今のところREAD/WRITEのメモリアクセス全てにウェイトを仕掛けて
	いるのだけど、RAMアクセスがノーウェイトと言う事は、メモリアクセスの
	負荷は実質的に半分以下になるって事か。
	何か、益々エミュのスピードが速くなってしまうなぁ。
	CPU関係の理論値で基準になるのはCPUのクロック数だけなので、
	1[sec]に処理されるCPUの処理量と、タイマー割込のカウントは別々に
	調整できるようにしておこう。

	CPU_CLOCK    1秒間のCPUクロック数
	rate         CPUクロックから画面表示期間を差っ引いた稼働率
	CPU_STATE    = (rate * CPU_CLOCK)       CPUが一秒間に処理できるクロック数
	VSYNC_STATE  = CPU_STATE / 60           VSYNCカウンター
	VRTC_STATE   = (CPU_STATE*16.688)/1000  垂直同期カウンター
	UTIMER_STATE = (CPU_STATE/128)          タイマー割込基本刻み値
	TIMER_STATE  = UTIMER_STATE*(io_F6H+1)  タイマー割込カウンター

	ここで、CPU_STATE と TIMER_STATE にはオプションによる調整を別々に入れておく。

	CPU_STATE   =(rate*CPU_CLOCK*cpu_adjust)/100  CPUが一秒間に処理できるクロック数
	   :
	UTIMER_STATE=(rate*CPU_CLOCK*timer_adjust)/(128*100)  タイマー割込基本刻み値
	TIMER_STATE  = UTIMER_STATE*(io_F6H+1)                タイマー割込カウンター

	それにしても、どこまで調整を組み込んでしまって良いのだろうか…。
	スタフリをサンプルに用いると…

	cpu_adjust = 80 [%]
	timer_adjust = 69 [%]

	この数値が適切な値になる。
	ところが、マッピーのボーナスステージをサンプルに用いると…

	cpu_adjust = 80 [%]
	timer_adjust = 79 [%]

	こうなる…。タイマー割込の調整値が10%も異なる。
	両者の状態で異なるのは io_F6H の値で、スタフリが 3 でマッピーは 60。
	って事は何だ？ 次なる小細工としては、io_F6H が 3→60 に増加する間に
	TIMER_STATE を約10%割増するようにさせれば調整すれば良いのか？

	10/(60-3) = 0.175…

	TIMER_STATE  = UTIMER_STATE*((io_F6H*1.175)+1)   タイマー割込カウンター

	タイマー割込のカウンターはこうなる…。
	う〜む、凄まじいな。理屈もヘッタクレもあったもんじゃない。
	でも、今の所こうでもしておかないと実機と噛み合わないんだよな〜。



	・昨日、6001はCPUと他デバイスのタイミングが連動していないと書いたけど、
	考えてみたらSTICK割込のルーチンを通すプログラムを組むとメインループ実行を
	VSYNC単位のタイミングに調整できるのか…。
	別の言い方をすればSTICK割込を待っていると無駄な時間を食う事になる。
	高速なプログラムにしたかったら、STICKの情報を割込で取得するのでなく
	ハドソンモノと同様、割込禁止の状態でポートから吸い出した方が良いのね。



■2005.02.28 ver 200 
	・他のチェック依頼ソフトの結果とスナップショットが帰って来た。
	おしゃべりシリーズの ポリスドッグ と スカイダイバー と きなさい！。
	特に問題無しということで、(*ﾟ∀ﾟ)q ガッ！


	・SR機種にて、旧互換BASICから1Dディスクを使おうとしても1DDチェックで
	ディスクがイジェクトされてしまう不具合を修正。
	1Dと1DDではファイル名やセクタ管理などのシステム情報が書き込まれる
	トラックが異なるので、誤って書き込まれたらマズイと思ってディスク種類を
	チェックして自動イジェクトするようにしていたのだけど、考えてみたら
	SRの旧互換BASICがPC-6601のBIOSと異なるわけ無いので、mkIIや6601で使える
	1Dディスクが読み込めないなんて事はあるわけないですな。


	・他、MAPPYのボーナスステージが絶対にクリアできないという話を聞いて確認。
	確かに…タイムリミットの音楽の再生が早すぎてゴールまで到着出来ない(;ﾟДﾟ)
	マッピーはBGMをタイマー割込みで演奏し、その演奏状況を時間の目安にして
	ゲームが動いているので、タイマー割込みのタイミングが狂ってくると
	ゲーム中の時間進行そのものがおかしくなってしまう。

	MSXの様に画像処理専用のチップを持っていたりPC98の様にCPUの処理速度が
	十分に速くなりシリーズに速度の異なるCPUを複数持つ様な機種では、
	VSYNCの合図を見たりサウンドボードのタイマーを監視したりしてCPUと
	他のデバイスを連動して動かすような作りのプログラムになる事が
	多いのだけど、6001の様にCPUが非力なマシンではプログラマーが
	手作業でウェイトを増減してタイミング合わせする事が殆どだった。

	実は現状のエミュでは、CPUの速度とタイマー割込のタイミングをマシン
	スペックに書いてあるような理論値で実装しても実機より遥かに早い
	動作になってしまうために、目安として特定のソフトの動作を見て
	それに近づくように調整している。
	P6VWの場合、CPUの動作とタイマー割込のタイミングは、スターフリートの
	OPデモを参照している。スターフリートのオープニングデモはCPUによる画像描画
	とタイマー割込によるBGM演奏の並行動作で、他の割込みが(STICK割込みなど)
	邪魔しに来ないので、タイマー割込だけの動作比を測るには丁度良い。
	理論値でのタイマー割込は 1/(512*4)[sec] 単位なので(SR以外の場合)、
	CPUが1秒間に処理できるクロック数 (CPU_CLOCK) を 2048 で割り、
	そのクロック掛ける io_F6H 指定数、

	TIMER_CLOCK = (CPU_CLOCK *(io_F6H+1))/2048;

	と、これだけのクロック数処理をCPUが行ったらタイマー割込が発生する
	ようになる…が、エミュにこのまま実装しても実機とはタイミングが異なる。
	(現在リリースしているバージョンのP6VWだと、オプションのCPU速度と
	 SYSTEM速度がそれぞれ 94%、94% の時、OPデモのタイミングが合う。)

	原因として考えられる事は幾つかある。

	(1).先ずCPUで処理した命令にかかるクロック数が実機とエミュで事なる。
	(2).SUB-CPUがフラグ変化で値を返してくるタイミングが異なる。
	(3).タイマー以外の割込発生タイミングが異なる。

	先ず、(1) は命令の実行以外にメモリアクセスでもクロックを消費する
	ようなので、他にもI/Oポートがアクセスするデバイスの種類によっては
	クロックを消費する事があるかも知れない。
	(2) は100%確実(笑。コレばかりはどうしようもない。
	(3) はSUB-CPUが絡んでくるのもあるけど、ここ最近書いたSTICK割込が発生
	するまでの"間"なんかは、ゲームプログラムを動かす場合など影響大。
	STICK値を取得するルーチンはこのようになっているので…。

	STICK割込要請ルーチン
	    ↓
	  SUB-CPU のREADY待ちループ (第1誤差発生)
	    ↓
	  SUB-CPUにSTICK割込要請
	    ↓
	  STICK割込が発生するまでの間 (第2誤差発生)
	    ↓
	STICK割込発生
	    ↓
	  SUB-CPU のREADY待ちループ (第3誤差発生)
	    ↓
	  STICK入力値取得
	    ↓

	例えCPU命令処理のクロックが完全に正しい場合でもこれだけの誤差が出てくる。
	特に第2誤差は大きい…。

	スターフリートのOPデモは「VRAM描画＋タイマーによるBGM演奏」だけで
	I/OポートアクセスやSTICK割込が全く発生しないので、純粋にCPUのクロックと
	タイマー割込のタイミングを見計らうには最適のサンプルと言える。
	タイマー速度は io_F6H=3 で、(4/2048)=(1/512)[sec] 単位と間隔が小さい。

	逆にマッピーは 「ゲーム進行＋タイマーによるBGM＋STICK情報取得」の上に
	タイマー速度が io_F6H=60、(61/2048)=(1/33.5738)…  う〜む、STICK割込
	の頻度から考えると、相当誤差が大きくなりそう…(;~〜~)

	先ずはスターフリートOPでCPUとタイマーのタイミングが合うように調整して、
	それからマッピーのボーナスステージでSTICK割込タイミングやSUB-CPUの
	ウェイト調整しか無いのかな…。何か雲を掴むような話だ。
	マッピーではBGM演奏側のタイミング速すぎるという事は、相対的にゲーム進行の
	側がモタついている事になる。
	SUB-CPUのREADYウェイトが実機よりも大いのだろうか？


■2005.02.26 ver 200 
	・うぅぅ、まだSTICK割り込みの発行漏れで無限ループに陥るときがある…orz

	本当に稀にしか起きない現象なので、Releaseモードでもデバグログが出っぱなし
	になるように改造し、別のチェックをやりながらエミュレータを動かし続け、
	無限ループに陥ったときのログを取得。
	さて、リザーブが最後に発行されてそれっきりになる問題の箇所は、

   :
   :
-=-=-=-=-=-=-=-=-=-=INTR (16H) !!! JOY
0e8c:IN A,(090H):84 DI (8049[0x00]) #2
T;T;
1060:KeyboardINT: ++ -- EI V[02]             <<< キーボード割込発行(SUB-CPU)
0ea5:OUT (090H),A:06
0ea5:KeyboardINT:RESERVE DI(set_vect) V[16]  <<< STICK割込予約

-=-=-=-=-=-=-=-=-=-=INTR (02H) !!! KEY3      <<< キーボード割込発生(Z80)
0e8c:IN A,(090H):V[16] #1 DI                 <<< STCIK割込ベクタ吸出し
T;T;T;T;T;T;T;T;T;
1070:KeyboardINT: ++ -- EI V[02]
   :
   :
   :

( "T;" はタイマー割込発生 )

	おや？キーボード割込発行の直後、実際に割込処理に飛ぶ以前にSTICK割込の
	予約が発行されてるぞ！？？？キーボードベクタが発行された時のZ80の
	処理アドレスは 1060H。このデバッグアドレスは何バイトの命令セットを
	処理する時も無関係に2バイト差っ引いて表示しているので、1060H〜1061H の
	どちらかのコード処理前に割込が発生したという事。
	該当箇所を見てみると…

Z0402: DI              ;1061 F3
       LD   A,0FFH     ;1062 3E FF
       LD   (0FECAH),A ;1064 32 CA FE
       LD   A,06H      ;1067 3E 06
       CALL 0E8FH      ;1069 CD 8F 0E

	Σ(ﾟДﾟ;)ガーン
	うわっ、見事にSTICKルーチンのDI直前に割込が発行しとる。
	現在のエミュレータの処理プロセスは以下の順番になっているので…

各種デバイス処理(VSYNC・TIMER・SUB-CPU・CMT・KEYBOARD など…)
  ↓
Z80 一命令実行
  ↓
Z80 割込発行チェック
  ↓
(上に戻る)

	そうか…デバイス処理のプロセスで割込フラグが立ってから実際にZ80で割込が
	発生するまでの間にCPUで一命令実行される様になっているので、キーボード割込
	発行待機状態のままDIに流れ込んでしまっていたのか。
	そして、DIの最中にSTICK割込要請でリザーブが発行され、SUB-CPU内の待機割込は
	クリアされるけど、既にSUB-CPUからZ80の方にキーボード割込が受け渡された
	状態になっているので、EIになった瞬間にキーボード割込ルーチンに飛んで、
	SUB-CPUに保持されていたSTICK割込のベクタ値がキーボード割込の入力キー情報
	として吸い出されてしまうと…。

	となると、これは割込発生をフラグで抑制するというより、この流れ自体を
	入れ替えないとダメですな。
	デバイス処理のところで割込が即時発生しても、CPUでそれを処理するまでに
	一命令処理する隙を与えてしまうと…その一命令がDIだと既に発生した割込に
	待ったをかけた状態のままコード実行が進んでしまう。
	内部のフラグ受け渡しの順番を考えると、割込チェックの後にコード実行を
	持ってくるのが筋ってもんか…。

各種デバイス処理(VSYNC・TIMER・SUB-CPU・CMT・KEYBOARD など…)
  ↓
Z80 割込発行チェック
  ↓
Z80 一命令実行
  ↓
(上に戻る)

	SUB-CPU絡みでCPUのルーチンにまで踏み込む必要が出てくるとは…(´･ω･`)
	実にデンジャラスな改造だ。



	・上の改造確認の為に何かを延々プレイし続けるのも時間の無駄なので、
	モニタモードに任意の割込発行コマンドを追加。

	" SETINTR <intr_no> "

	BASIC上で  "10 PRINT STICK(0):RUN"  を実行してモニタモードに入り、
	1061H にブレイクポイントを仕掛けて、停止したら "SETINTR 0x02" で
	キーボード割込を発生させる。次にSTEP実行で "DI" が実行されずに、
	キーボード割込アドレスにジャンプしたら、割込発生がコード実行より先に
	行われたという証拠になる。

	結果は問題なし。



■2005.02.24 ver 200 
	・キー割り込み1,2 がSUB-CPUを通さずに即時発行になっていたのでそれを修正。
	STICK割り込みのリザーブ状態でSTOPキーが押されるとSTICKベクタが吸い出されて
	無限ループに陥ってました。

	・TV4:3比表示モードを付けてみる…。
	エミュレータの画面だと、ボスコニアンが横に潰れていて遊び難いとか、
	「黄金の墓」のヒロインが横長になってジパングのモモちゃん化していて
	イマイチ感情移入できない(オィ)とか、そういう様々な理由で家庭用TV
	の4:3比率の表示にしたいときに使用してもらえれば良いかと…( ﾟ∀ﾟ)
	今の所、選択できる解像度の問題からフルスクリーンには対応していない。


■2005.02.20 ver 200 
	・色々結果が帰ってきた。他、追加チェックしたものも全てオッケ。

	パワーフェイル   …○
	BEAN'S JACK      …○
	ヒヨコファイター  …○
	バブルグンド1999  …○
	マシンガンジョーvsマフィア…○
	ベジタリアンクラッシュ  …○
	ROM版テニス      …○

	調子良いぞ (*ﾟ∀ﾟ)


	・CLOAD中にリザーブベクタが発行されるとテープの返値として吸い出されて
	しまう事があるので、CMT稼動中はリザーブベクタの発行を抑制。


■2005.02.19 ver 200 
	・SUB-CPUは鬼門。おしゃべりシリーズはイゼルローン要塞だな。
	(;ﾟ∀ﾟ) あひゃ、あひゃひゃひゃひゃひゃ。
	手持ちのハドソン物が全てオーケーになったので別のチェックに回したら
	やっぱりNGが返ってキター…＿|￣|○、
	色々試行錯誤してみたのだけど、最終的にキャノンボールを動くようにすると
	パワーフェイルが動かなくなり、パワーフェイルが動くようになるとキャノン
	ボールが動かないという絶妙なバランス状態(笑)に陥ってしまった。
	まぁ、如何ともしがたいのでデバッグログを貰ってI/Oポートアクセスと
	割込みの流れを確認。


キャノンボール
 [I/O,Interrupt]                              [8049_VECTOR_STATUS]
110b:KeyboardINT: ++ -- EI(vect) V[16]      Vector : Value : -----
-=-=-=-=-=-=-=-=-=-=INTR (16H) !!! STICK     ----- : Value : -----
106a:IN A,(090H):10 DI (8049[0x00]) #2       ----- : ----- : -----
107f:OUT (090H),A:06
107f:KeyboardINT:RESERVE DI(set_vect)V[16]   ----- : ----- : Reserve  STICK割込予約
110e:KeyboardINT: ++ -- EI V[02]            Vector : Value : Reserve  KEY割込
-=-=-=-=-=-=-=-=-=-=INTR (02H) !!! KEY3      ----- : Value : Reserve  KEY割込発生!
106a:IN A,(090H):V[16] #1 DI                 ----- : Value : -----    STICK割込ベクタ
110e:KeyboardINT: ++ -- EI V[02]            Vector : Value : -----    KEY割込
-=-=-=-=-=-=-=-=-=-=INTR (02H) !!! KEY3      ----- : Value : -----    KEY割込発生!
106a:IN A,(090H):1c DI (8049[0x00]) #2       ----- : ----- : -----    KEY割込パラメタ
110e:KeyboardINT: ++ -- EI V[02]            Vector : Value : -----       :
-=-=-=-=-=-=-=-=-=-=INTR (02H) !!! KEY3      ----- : Value : -----       :
106a:IN A,(090H):1c DI (8049[0x00]) #2       ----- : ----- : -----       :
110b:KeyboardINT: ++ -- EI V[02]            Vector : Value : -----       :
-=-=-=-=-=-=-=-=-=-=INTR (02H) !!! KEY3      ----- : Value : -----       :
106a:IN A,(090H):1c DI (8049[0x00]) #2       ----- : ----- : -----       :
110f:KeyboardINT: ++ -- EI V[02]
    :
(ENDLESS LOOP)



パワーフェイル
 [I/O,Interrupt]                              [8049_VECTOR_STATUS]
42dc:IN A,(090H):32 DI (8049[0x00]) #2       ----- : ----- : -----
42ef:IN A,(090H):32 DI (8049[0x00]) #2       ----- : ----- : -----
42dc:IN A,(090H):32 DI (8049[0x00]) #2       ----- : ----- : -----
42dc:KeyboardINT:++ DI V[02]                Vector : Value : -----    KEY割込
42ef:IN A,(090H):V[02] #1 DI                 ----- : Value : -----    KEY割込ベクタ
4367:OUT (090H),A:06
4367:KeyboardINT:RESERVE DI(set_vect) V[16]  ----- : Value : Reserve  STICK割込予約
42dc:IN A,(090H):1e DI (8049[0x00]) #2       ----- : ----- : Reserve  KEY割込パラメタ
42ef:IN A,(090H):V[16] #1 DI                 ----- : ----- : -----    STICK割込ベクタ
42dc:IN A,(090H):04 DI (8049[0x00]) #2       ----- : ----- : -----       :
42ef:IN A,(090H):32 DI (8049[0x00]) #2       ----- : ----- : -----       :
42dc:IN A,(090H):32 DI (8049[0x00]) #2       ----- : ----- : -----       :
42ef:IN A,(090H):32 DI (8049[0x00]) #2       ----- : ----- : -----       :
42dc:IN A,(090H):32 DI (8049[0x00]) #2       ----- : ----- : -----       :
42ef:IN A,(090H):32 DI (8049[0x00]) #2       ----- : ----- : -----       :
42dc:IN A,(090H):32 DI (8049[0x00]) #2       ----- : ----- : -----       :
    :
(ENDLESS LOOP)


	上２つを見比べてみると、DI時の予約ベクタ発行条件が相反している事が判る。

	キャノンボールはSTICK割込みを予約してEI状態に移行し、STICK割込が発行される
	前にキーボード割込が間に割って入って、キーボード割込のパラメタが返らな
	ければならない所にSTICK割込のベクタが吸い出されてしまい、以後、STICK割込が
	発生しなくなりSTICK割込待ちで無限ループに陥っている。
	ということは、ここで想定されている予約ベクタの発行条件は、事前に発生した
	割込のパラメタが返却される前に予約ベクタは発生しないという事。
	条件式で表わすとこういう感じ。
	if( Reserve && !Value ) return Reserve;

	ところがパワーフェイルの方では、STICK割込予約を発注した後、DI状態のまま
	STICKベクタを吸い出すところでSTICK割込予約の直前に発行されたキーボード
	割込のパラメタが入り込んで来てしまい、STICK割込のベクタ値を検知できずに
	エンドレスループに陥っている。
	ということは、ここで要求される予約ベクタの発行条件は、STICK割込予約直前に
	発行された別の割込パラメタが残っていても予約ベクタを返して欲しいという
	ことである。
	条件式だとこうなる。
	if( Reserve ) return Reserve;

	SUB-CPU内にパラメタが残っていても予約ベクタを出して欲しいのか、
	パラメタが残っている内は予約ベクタを発行して欲しくないのか…。
	違いは割込予約を発注した後にEI状態になったかDI状態のままかという事。
	て事は、予約ベクタの発行条件としてはパラメタが残っているうちは
	ベクタを発行させない if( Reserve && !Value ) を選択して、割込予約
	発注した後 DI状態で間に邪魔が入る事無くポートを読みに来る時は
	予約ベクタを素直に発生させれば両方で問題なくなるのか。
	DI時の割込予約発注の時点でSUB-CPUに残る他のベクタとパラメタを
	キャンセルしてしまえば良いという事だな。

	この条件で上の２つの流れを見直してみると…


キャノンボール
 [I/O,Interrupt]                              [8049_VECTOR_STATUS]
107f:OUT (090H),A:06
107f:KeyboardINT:RESERVE DI(set_vect)V[16]   ----- : ----- : Reserve  STICK割込予約
110e:KeyboardINT: ++ -- EI V[02]            Vector : Value : Reserve  KEY割込
-=-=-=-=-=-=-=-=-=-=INTR (02H) !!! KEY3      ----- : Value : Reserve  KEY割込発生!
106a:IN A,(090H):1c DI (8049[0x00]) #2       ----- : ----- : Reserve  KEY割込パラメタ
110e:KeyboardINT: ++ -- EI V[02]            Vector : Value : Reserve  KEY割込
-=-=-=-=-=-=-=-=-=-=INTR (02H) !!! KEY3      ----- : Value : Reserve  KEY割込発生!
106a:IN A,(090H):1c DI (8049[0x00]) #2       ----- : ----- : Reserve  KEY割込パラメタ
      :
      : (しばらく間をおいて…)
      :
110e:KeyboardINT: ++ -- EI V[16]            Vector : Value : -----    RESERVE発行
-=-=-=-=-=-=-=-=-=-=INTR (16H) !!! STICK     ----- : Value : -----    STICK割込発生!
106a:IN A,(090H):00 DI (8049[0x00]) #2       ----- : ----- : -----    STICK割込パラメタ



パワーフェイル
 [I/O,Interrupt]                              [8049_VECTOR_STATUS]
42dc:IN A,(090H):32 DI (8049[0x00]) #2       ----- : ----- : -----
42dc:KeyboardINT:++ DI V[02]                Vector : Value : -----    KEY割込
42ef:IN A,(090H):V[02] #1 DI                 ----- : Value : -----    KEY割込ベクタ
4367:OUT (090H),A:06
4367:KeyboardINT:RESERVE DI(set_vect) V[16]  ----- : ----- : Reserve  STICK割込予約
42dc:IN A,(090H):V[16] #1 DI                 ----- : Value : -----    STICK割込ベクタ
42ef:IN A,(090H):04 DI (8049[0x00]) #2       ----- : ----- : -----    STICK割込パラメタ
42dc:IN A,(090H):31 DI (8049[0x00]) #2       ----- : ----- : -----       :

	ううむ、特に矛盾は見当たらず。
	よしコレで行こう ( ﾟ∀ﾟ)



	・修正後のチェック。

	爆弾男          …○
	3D爆弾男        …○
	キャノンボール  …○
	ゼロファイター  …○
	イタサンドリアス…○

	よっしゃ！全部オッケー ( ﾟ∀ﾟ)d
	というわけで、他の分の調査依頼を投げてみる。
	さてさてどうなりますか…。
	懸案のパワーフェイルは大丈夫かな？ちと心配だ。




■2005.02.18 ver 200 
	・まだSUB-CPU でトラブル。ハドソンモノが動かなくなった。
	どうもDI状態のままでベクタ取得するソフトの場合、割込リザーブを発行した
	直後にベクタの取得が行われたら、その場でリザーブを解除してベクタと返値を
	発行しないといけないようだ。

	まとめ。

	▼DI(割込禁止)状態でリザーブ発行後 EI(割込解禁)された時は、実際に予約
	  割込が発行されるまでINTRはフリーの状態となり、他の割込も割り込んでくる。

	  理由：リザーブが発行されるまで他の割込を排他的に扱うと、キーが効かない
	        とかタイマー割込が動かないとか即時発行割込で不具合が発生する為。


	▼DI(割込禁止)状態でリザーブ発行後、DIのままSUB-CPUのステータスを読まれたら
	  その場で予約を解除してベクタと返値を返却しなければならない。
	
	  理由：ソフトによっては予約した割込内容を受け取れず、DI状態のまま待機の
	        無限ループに陥ってしまう。
	        (EIになれば垂直同期のタイミングでCPUが割込を発生させるのだが…)

	と、こういう仕組みかな？
	ハドソン物の場合、多分、EI状態で予約した割込が発生するのを待っていると
	無駄な時間待機する事になってスピードが遅くなるので、DI状態で直接 SUB-CPU
	から値を取って来ちゃうって事なんだろうな。


   (DI)
    ┃
OUT (90H),06H → INTR 16H [予約]
    ┃
    ┃
    ┣━━━━━━━━━━━━━━━━━┓
   (EI)                              (DIのまま)
    ┃                                  ┃
    ┃←INTR 02H とか                 IN 90H →割込は発行されて
    ┃    INTR 06H とか                 ┃    いなくても、ベクタ(16H)と
    ┃      いろいろ発行可能            ：    返値を返却しないといけない。
    ┃                                  ：    もちろんリザーブは解除。
    ┃
(垂直同期分の
   時間が経った)
    ┃
INTR 16H [発行！]
    ┃
    ┃
    ：
    ：

	もしかしてSUB-CPUの割込処理って順番待ちのパイプじゃなくて、スタック形式
	なのかな？ 後から要求された割込の方が先に発行されるとか…？
	STICK割込とキーボード＆タイマー割込の関係を見る限りはそうなんだけど、
	他はどうだかわからないな。CMT割込なんかは順番待ちしてるっぽいけど…。


	・ううぅ、SUB-CPU弄ってるときが一番緊張するなぁ…(;ﾟДﾟ)ドキドキ
	なんたって、少し動作を変えただけで今まで動いていたソフトが済し崩し的に
	動かなくなったりする…。
	さてと…手持ちのハドソンソフトの動作確認開始だ。
	一通り動かしてみて固まらなければ成功。
	
	爆弾男          …○
	キャノンボール  …○
	ゼロファイター  …×

	Σ(ﾟДﾟ;)



■2005.02.18 ver 200 
	・先日の改造で少々マズイ事が起きた。
	現在の SUB-CPU は1つしか割込みをリザーブしていないのだが、
	STICK割込を垂直同期に合わせて発行するようにしてしまった為、
	STICKが発行されるまでの間キーが押されてもキーボード割込が発行されず、
	もの凄くキーレスポンスが悪くなってしまった…(;ﾟДﾟ)ガーン
	前も書いたが、STICK割込は要求があった場合に必ず発行しないといけない
	割込なので、キーボードやタイマーなどとは扱いが異なり最優先でリザーブを
	受け付けるようになっている。
	ってことは、垂直同期に合わせる割込と即時発行割込のリザーブは別々の
	フラグに分離しておかないとダメですな。
	SUB-CPU と ベクタ発行のタイミングの流れはこの様になっている。

[8049]  [垂直同期]    [Z80]

 RESET    --+--
   :        |
 READY      |    --> CPUは 8049のREADY を検知してSTICK割込発行要請
            |        <<< INTR 16H [予約]
 RESET      |
   :        |
 READY      |        >>> INTR 02H [キーボード割込]
   :        :           (即時発行の割込は自由に発行)
    (…略…)
   :        :
 RESET      |        >>> INTR 06H [タイマー割込発行]
   :        |
 READY      |
            |
 RESET    --+--  --> 垂直同期と共に リザーブベクタ発行
   :        |        >>> INTR 16H [STICK割込発行]
 READY      |

	通常、SUB-CPUと何か情報を遣り取りしたいと思ったらフラグのONだけを監視して
	いれば良いのだけど、ハドソン物の場合フラグ落ちまでチェックされているので
	短期サイクルで擬似的な RESET と READY を繰り返している。
	本物の8049は接続された各種デバイスの信号を受け取って変化するハズだから
	垂直同期とも連動が取れてフラグ変化するのだろうが、エミュでは擬似的な
	動作なので垂直同期とは非同期。上の様にINTR 16H(予約)が発行されてから、
	次の垂直同期が発行されるまでに十分な時間があれば実機で想定された分の
	処理時間が稼げるのだけど…

[8049]  [垂直同期]    [Z80]

 RESET      |
   :        |
 READY      |    --> CPUは 8049のREADY を検知してSTICK割込発行要請
            |        <<< INTR 16H [予約]
 RESET      |
   :        |
 READY    --+--  --> 垂直同期と共に リザーブベクタ発行
   :        |        >>> INTR 16H [STICK割込発行]
 RESET      |
   :        |
 READY      |

	この様に垂直同期の直前のREADYを捕まえてリザーブが出された場合、想定された
	処理時間が足りずに都合の悪い事になる。だったら垂直同期と関係無しで、
	リザーブが出された時点から、自前でカウント取って発火するようにすれば
	全て解決？

[8049]  [垂直同期]    [Z80]

 RESET      |
   :        |
 READY      |    --> CPUは 8049のREADY を検知してSTICK割込発行要請
   :        :        <<< INTR 16H [予約]
    (…略…)             |
   :        :            |
 RESET      |            |
   :        |            |
 READY      |            |(割込専用カウンタ)
            |            |
 RESET    --+--          |
   :        |            |
 READY      |            |
            |            |
 RESET      |            |
   :        |            |
 READY      |        発火、リザーブベクタ発行
            |        >>> INTR 16H [STICK割込発行]
 RESET      |
   :        |
 READY      |

	……こんなんで大丈夫なのか( ﾟДﾟ)？



■2005.02.17 ver 200 
	・特定のアプリによってはSTICK割込み発生のタイミングがSUB-CPUの
	READYフラグの発生と上手く噛合わない事が判明。
	今現在のエミュ内での割り込みの扱い2通りある。タイマーやカセットなど
	即時発行が求められるものと、一度SUB-CPUにリクエストを渡しておいて
	特定タイミングで発行するもの。
	STICK割込の場合、割込リクエストを取り逃がすと無限ループに陥るケースが
	多いのでタイミングを遅らせる事無くEI(割込解禁)と同時に即時発行して
	いるのだけど、アプリの中には割込リクエストを発行した後 EIになってから
	暫く間をおいて割込が発行される事を前提としてコーディングされている
	ソフトもある。
	ハドソンおしゃべりシリーズでは割込リクエストもベクタ取得もDI(割込禁止)
	状態で行われるのでSUB-CPUのフラグ変化だけを考えていれば良かったのだけど、
	EI状態になった後に発行タイミング待ちが必要になる事は考慮していなかった。
	SUB-CPUのフラグ監視をして割込予約の意味合いでリクエストを出している
	ソフトの場合、リクエストと同時にベクタ発行されてしまうとその後の
	処理で辻褄が合わなくなる。
	コレはどうしたもんだろうなぁ…SUB-CPU内部のカウントアップだけでなく
	外のINTRチェックとタイミングを合わせないとダメかな？
	DI状態の時は割込発行も何も無いからタイミングは関係無いけど、
	EI時のベクタ発行タイミングはMSX2などと同様、垂直同期に合わせて
	発行させるように変更。


■2005.02.13 ver 200 
	・SRの旧互換モードでビクトリアス9が動か無いという事なので原因を調査。
	ビクトリアス9はSRだとFM音源を使って曲を奏でるので音関連のI/Oポートが
	原因だろうと予想を立てつつ、とりあえず固まるまで動かしてみる。
	…って、ロードが終わった途端に固まってますな…(^^;;;
	モニタモードでプログラムを追いかけてみると以下のルーチンで無限ループ。

Z0149:PUSH  AF        ;A732 F5
      OUT   (0A1H),A  ;A733 D3 A1
Z0159:IN    A,(0A0H)  ;A735 DB A0
      CP    080H      ;A737 FE 80
      JR    NC,Z0158  ;A739 30 02
      POP   AF        ;A73B F1
      RET             ;A73C C9
Z0158:JR    Z0159     ;A73D 18 F6

	io_A0H はINで値を返すようになっておらず エラー値(0FFH)しか返らないので、
	確かにこのチェックルーチンだと無限ループに陥るはずだ。
	音源ポートというと IN(0A2H) がYM-2203のステータスリードで、このポートに
	BUSYフラグとか返却される様になっているわけだが、もしかするとここは
	チップ全体ではなくFM音源だけのステータスで、SSGのステータスは IN(0A0H) で
	返されるようになっているのかも知れないなぁ。
	というわけで、SSG がBUSY状態にならないように常に 00H の値を返却させると、
	無事に動くようになった。



	・スターフリートをプレイしていて思った事。

	「レーダー座標を鉛筆でメモするのも面倒だなぁ…」
	「スナップショット撮ってビューアーで開くという手もあるが、
	  一々ファイルをビューアーに放り込むのも手間だ。」
	「臨時スナップショット機能作るか (*ﾟ∀ﾟ)ﾍﾗﾍﾗ」

	そういうわけで、またもや "衝動的" に一時的な写真メモ機能をコンテキスト
	メニューに追加。フルスクリーンの時は使えないけど…。
	画像表示モジュールはCaViのプログラムをゴッソリ削って最小限の機能だけ
	残したもの。スナップショットデータの受け渡しはクリップボード経由。
	それにしてもこの機能、スターフリート意外に役に立つのだろうか…(^^;;



■2005.02.10 ver 200 
	・keiさんから、市販ソフトの動作テスト結果とスナップショットが色々と
	帰って来たので個別対処。
	先ずはROMソフト PUCK MEN を初代機で起動すると、タイトル画面のセミグラで
	表現されるはずのキャラクターの絵が文字に化けてしまうとの事。
	mkII だと正常。

	SCREEN別文字キャラクター描画ルーチンなんてmkIIも6001も同じ関数を使って
	いるので使用機種によって何が変るわけでも無く、全く原因に見当付かずで
	文字キャラクターの表示アトリビューに未知の数値でも設定されているのかと
	思って確認してもらったところ、この様な調査結果が。

> ちょっと調べてみました所、該当個所のVRAMアトリビューには
> 単純に 60H が入っているだけでした。なので更に調べていくと
> 原因は『ROM/RAMカードリッジを使用している状態になっている為
> ページ１のVRAMアドレスが 8000H〜8400H になっている』事である
> と判明しました。
>
> 本来、カードリッジゲーをする際にはROM/RAMカードリッジは
> 使用しない訳ですが、P6VWでは「Extend RAM 有り」にしないと
> Extend ROM が有効にならないのです。
> なのでプログラムでは 0C000H〜0C1FFH にページ１のアトリビューが
> あるものとして動作しているのに、P6VWでは 8000H〜81FFH がページ１の
> アトリビューになっている為に正しく表示されていなかったのです。

	確かに、今現在はどの機種で立ち上げても強制的に64kの拡張RAMを
	マップに割り当てているので、常に空きバンクにはRAMが実装された状態に
	なっている。なので、初代機で拡張ROMを使用していて、そのROMが16KB以下の
	容量の場合、空いたアドレスには全てRAMが入り込んでくる。
	イマイチ理屈がわからないけど、拡張ROMを装着した時は拡張RAMを切り離すよう
	修正を施したところ直ったとのこと。どうもその仕組みに合点が行かず
	疑問をもっていたら、以下の様な解説が…。

> あれ？  ご存じありませんか？
> 初代機の場合、拡張RAM無しだと 0C000H〜0FFFFH の16kbがRAMですが
> この内ページ１のVRAMが 0C000H〜0C400H
> そしてページ２のVRAMが 0E00H〜
> となりますが、拡張RAM有りだと8000H〜0FFFFH の32kbがRAMで
> この内ページ１のVRAMが 8000H〜8400H
> そしてページ２のVRAMが 0E000H〜
> ページ３のVRAMが 0C000H〜
> ページ４のVRAMが 0A000H〜
> となります。
> 
> 対してmk2以降の機種では初めから64kbあるので
> 拡張RAMが有ろうが無かろうが関係ないのです。

	Σ(ﾟДﾟ；)ガーン！
	不覚にも今の今まで知らなかったデスよ…＿|￣|○、←mkIIメインユーザー

	I/Oポート自体の動作でmkIIと初代機に何か異なる部分があるのかと
	いぶかしんでいたのだけど、どうやら初代機のBIOSが自動的にRAMの存在を
	チェックしてVRAMのページ割当を変えていたのか…。
	(自分は、空のRAMというものは書き換えても内容が変らないベタROM扱い
	されているものだと思っていた…。)
	確かに、拡張RAMが無いとVRAMを3ページも確保出来ないので、BIOS側で
	メモリ管理を行わないとBASICでの画面表示すら動作保証されない。
	ううむ、勉強になりましたね (^^;

	そういうわけで強制的に拡張RAMを実装するのはとりやめて、きちんと
	オプションのスイッチを見て実装・未実装を変えるように修正。



	・次、SR用プラズマラインの表示色がおかしい。
	画面スナップショットを見る限り、どうも N60m-SCREEN4 を使っていると思われる。
	というのも、"あの" I/Oポートで座標を指定して１ドットずつアクセスするような
	SRのビットマップモードで高速なポリゴン描画など出来るわけ無いだろうし、
	常識的に考えてSR用の新しい描画ルーチンなんか組まずに mkII と同じ
	描画エンジンをそのまま使っていると想像できるから。まぁ、決定的な根拠は
	タイトルロゴと宇宙船がプレーンの重ねあわせになってるからなんだけど…。

	起動は SR-BASIC(MODE:6) からとの事なので内部でコントローラを切り替えて
	画面表示を旧互換モードにしているのだろう。
	N60SR-N60m 間のスクリーンモード移行について、直接I/Oポートを叩くだけで
	起動したBASICモードと異なる描画モードに問題なく切り替わるという事は、
	以前 画面スクロールのサンプルプログラムを作った際に既に確認済。
	OUT(040H) のプレイクポイントも引っ掛かるらしいので、パレットチェンジ
	を使っている事も間違いない。
	という事は、SRの場合、旧互換BASICで起動しても I/Oポートを直接叩けば
	N60m のスクリーンモードにもパレットチェンジが適応されるので、それを
	踏まえたカラー選択でスクリーン描画を行わないといけない。

	SRのカラーコードは↓以下の並びで、パレット命令で変更できるのは 13〜16番。

┏━━━━━━┓
┃カラーコード┃
┃    css3=0  ┃
┣━━━━━━┫
┃ 1: 透明    ┃
┃ 2: 青紫    ┃
┃ 3: 橙      ┃
┃ 4: 赤紫    ┃
┃ 5: 青緑    ┃
┃ 6: 空色    ┃
┃ 7: 黄緑    ┃
┃ 8: 灰色    ┃
┃ 9: 黒      ┃
┃10: 青      ┃
┃11: 赤      ┃
┃12: マゼンタ┃
┃13: 緑      ┃←PALET 13,n
┃14: シアン  ┃←PALET 14,n
┃15: 黄      ┃←PALET 15,n
┃16: 白      ┃←PALET 16,n
┗━━━━━━┛

	因みにパレットチェンジは15色使えるスクリーンだと COLOR 13〜16 にそのまま
	割り当てられているけど、SCREEN4 で4色しか使えないモードの場合、
	COLOR,,n のカラーセットによって16色中4色に分離されたカラー割り当てになる。
	パレットチェンジで変更されるのは カラーコード13〜16 が割り当てられている
	COLOR,,2 カラーセットの COLOR 1〜4 ということになるわけだ…。

┏━━━━━━━━━━━━━━━━━━┓
┃N60m  SCREEN 4                      ┃
┣━━━━┳━━━━┳━━━┳━━━━┫
┃COLOR,,n┃パレット┃カラー┃色      ┃
┃        ┃  番号  ┃コード┃        ┃
┣━━━━┻━━━━┻━━━┻━━━━┫
┃css3=0                              ┃
┣━━━━┳━━━━┳━━━┳━━━━┫
┃COLOR,,1┃COLOR 1 ┃   9  ┃黒      ┃
┃        ┃COLOR 2 ┃  10  ┃青      ┃
┃        ┃COLOR 3 ┃  11  ┃赤      ┃
┃        ┃COLOR 4 ┃  12  ┃マゼンタ┃
┣━━━━╋━━━━╋━━━╋━━━━┫
┃COLOR,,2┃COLOR 1 ┃  13  ┃緑      ┃←PALET 13,n
┃        ┃COLOR 2 ┃  14  ┃シアン  ┃←PALET 14,n
┃        ┃COLOR 3 ┃  15  ┃黄      ┃←PALET 15,n
┃        ┃COLOR 4 ┃  16  ┃白      ┃←PALET 16,n
┣━━━━╋━━━━╋━━━╋━━━━┫
┃COLOR,,3┃COLOR 1 ┃   1  ┃透明    ┃
┃        ┃COLOR 2 ┃   2  ┃青紫    ┃
┃        ┃COLOR 3 ┃   3  ┃橙      ┃
┃        ┃COLOR 4 ┃   4  ┃赤紫    ┃
┣━━━━╋━━━━╋━━━╋━━━━┫
┃COLOR,,4┃COLOR 1 ┃   5  ┃青緑    ┃
┃        ┃COLOR 2 ┃   6  ┃空色    ┃
┃        ┃COLOR 3 ┃   7  ┃黄緑    ┃
┃        ┃COLOR 4 ┃   8  ┃灰色    ┃
┣━━━━┻━━━━┻━━━┻━━━━┫
┃css3=1                              ┃
┣━━━━┳━━━━┳━━━┳━━━━┫
┃COLOR,,5┃COLOR 1 ┃   9  ┃緑      ┃
┃        ┃COLOR 2 ┃  10  ┃黄      ┃
┃        ┃COLOR 3 ┃  11  ┃青      ┃
┃        ┃COLOR 4 ┃  12  ┃赤      ┃
┣━━━━╋━━━━╋━━━╋━━━━┫
┃COLOR,,6┃COLOR 1 ┃  13  ┃白      ┃
┃        ┃COLOR 2 ┃  14  ┃シアン  ┃
┃        ┃COLOR 3 ┃  15  ┃マゼンタ┃
┃        ┃COLOR 4 ┃  16  ┃橙      ┃
┗━━━━┻━━━━┻━━━┻━━━━┛

	それと、COLOR,,5/COLOR,,6 には CSS3=1 のカラーコードが割り当てられて
	いるのだけど、こっちのパレットも13〜16番にパレットチェンジを当て
	はめちゃって良いのかな？？

┏━━━━━━┓
┃カラーコード┃
┃    css3=1  ┃
┣━━━━━━┫
┃ 1: 緑      ┃
┃ 2: 黄      ┃
┃ 3: 青      ┃
┃ 4: 赤      ┃
┃ 5: 白      ┃
┃ 6: シアン  ┃
┃ 7: マゼンタ┃
┃ 8: 橙      ┃
┃ 9: 緑      ┃
┃10: 黄      ┃
┃11: 青      ┃
┃12: 赤      ┃
┃13: 白      ┃←PALET 13,n
┃14: シアン  ┃←PALET 14,n
┃15: マゼンタ┃←PALET 15,n
┃16: 橙      ┃←PALET 16,n
┗━━━━━━┛

	そうなると COLOR,,6 のカラーセットもチェンジカラーで変化する事になるけど、

┏━━━━━━━━━━━━━━━━━━┓
┃N60m  SCREEN 4                      ┃
┣━━━━┳━━━━┳━━━┳━━━━┫
┃COLOR,,n┃パレット┃カラー┃色      ┃
┃        ┃  番号  ┃コード┃        ┃
┣━━━━┻━━━━┻━━━┻━━━━┫
┃css3=1                              ┃
┣━━━━┳━━━━┳━━━┳━━━━┫
┃COLOR,,5┃COLOR 1 ┃   9  ┃緑      ┃
┃        ┃COLOR 2 ┃  10  ┃黄      ┃
┃        ┃COLOR 3 ┃  11  ┃青      ┃
┃        ┃COLOR 4 ┃  12  ┃赤      ┃
┣━━━━╋━━━━╋━━━╋━━━━┫
┃COLOR,,6┃COLOR 1 ┃  13  ┃白      ┃←PALET 13,n
┃        ┃COLOR 2 ┃  14  ┃シアン  ┃←PALET 14,n
┃        ┃COLOR 3 ┃  15  ┃マゼンタ┃←PALET 15,n
┃        ┃COLOR 4 ┃  16  ┃橙      ┃←PALET 16,n
┗━━━━┻━━━━┻━━━┻━━━━┛

	もしこのカラーチェンジが、カラー番号でなく色そのものに対して行われる
	としたら、css3=1 のパレットチェンジは下のように適応される事になる。

┏━━━━━━┓
┃カラーコード┃
┃    css3=1  ┃
┣━━━━━━┫
┃ 1: 緑      ┃←PALET 13,n
┃ 2: 黄      ┃←PALET 15,n
┃ 3: 青      ┃
┃ 4: 赤      ┃
┃ 5: 白      ┃←PALET 16,n
┃ 6: シアン  ┃←PALET 14,n
┃ 7: マゼンタ┃
┃ 8: 橙      ┃
┃ 9: 緑      ┃←PALET 13,n
┃10: 黄      ┃←PALET 15,n
┃11: 青      ┃
┃12: 赤      ┃
┃13: 白      ┃←PALET 16,n
┃14: シアン  ┃←PALET 14,n
┃15: マゼンタ┃
┃16: 橙      ┃
┗━━━━━━┛
┏━━━━━━━━━━━━━━━━━━┓
┃N60m  SCREEN 4                      ┃
┣━━━━┳━━━━┳━━━┳━━━━┫
┃COLOR,,n┃パレット┃カラー┃  色    ┃
┃        ┃  番号  ┃コード┃        ┃
┣━━━━┻━━━━┻━━━┻━━━━┫
┃css3=1                              ┃
┣━━━━┳━━━━┳━━━┳━━━━┫
┃COLOR,,5┃COLOR 1 ┃   9  ┃緑      ┃←PALET 13,n
┃        ┃COLOR 2 ┃  10  ┃黄      ┃←PALET 15,n
┃        ┃COLOR 3 ┃  11  ┃青      ┃
┃        ┃COLOR 4 ┃  12  ┃赤      ┃
┣━━━━╋━━━━╋━━━╋━━━━┫
┃COLOR,,6┃COLOR 1 ┃  13  ┃白      ┃←PALET 16,n
┃        ┃COLOR 2 ┃  14  ┃シアン  ┃←PALET 14,n
┃        ┃COLOR 3 ┃  15  ┃マゼンタ┃
┃        ┃COLOR 4 ┃  16  ┃橙      ┃
┗━━━━┻━━━━┻━━━┻━━━━┛

	と、含みを持たせたところで、とりあえず番号変化の方を割り当てておこう。


	・どこでもセーブで拡張ROMの内容保存せんのか〜！(#ﾟДﾟ)
	…てな事を前から言われていたような気がするので、EXT-ROMの内容もセーブ
	データに書き込むように変更。
	今まではEXT-ROMが設定されていないと拡張ROM用のメモリ自体が確保されて
	いなかったので、どこでもLOADで後から読み込ませるには修正箇所が多すぎて
	手をつけなかったのだけど、現バージョンではEXT-ROMが存在しなくても一応メモリ
	だけは確保してあるので(SYSTEM-ROM変更対応)、EXT-ROMの内容をそこに読み
	込ませるだけの簡単対応でオッケ〜。
	しっかし、I/Oポートの復帰は順番を綿密に練らないとダメだなぁ。
	アッチのポートでこのフラグを立てておかないとこっちのポートで違う動作を
	するとか異なるメモリを割り当てるとか、なんやかんや色々と条件分岐が
	絡んできて、CPUを動かした途端に暴走という事例が後を絶たない。

	とりあえず真っ先にやっておく必要があるのは、下のポートを順番に復帰する事。

	1.OUT(0C8H)  // I/O[C8] SR_CRTコントロールモード
	  ↓
	2.OUT(0C1H)  // I/O[C1] CRTコントロールモード
	  ↓
	3.OUT(0B0H)  // I/O[B0] システムラッチポート

	これで画面やCPUなどの動作モードが設定されるので、この後にメモリの
	設定や画面表示関係のポートを復帰させて行く。




■2005.02.07 ver 200 
	・衝動的にメモリダンプ窓に簡易バイナリエディタを仕込んでみる…(´･ω･`)
	カーソル表示と16進数の入力が出来るようになっただけで、コピーペーストや
	検索などの大掛かりな仕組みは無い。まぁ、2時間チョイならこの程度か。
	コンソールからメモリ書き換えを指示するよりは扱いが楽になったかな？
	範囲指定のコピーペーストを組み込もうと思ったら、大規模改造になって
	膨大な時間を要しそうだ… (;ﾟ∀ﾟ)


■2005.02.06 ver 200 
	・FM音源のCSMが良くわからないので、SRの音声合成の方を追いかけてみる。
	SRのTALKの基本的な動作プロセスの流れはこんな感じ。

	  TALK命令実行
	    →フォルマントパラメタセット(7バイト)のテンポラリ準備
	      →VOICE割込要請
	            ↓
	  VOICE割込発生
	    →フォルマントパラメタ送信(1)
	      →次の割込要請
	            ↓
	  VOICE割込発生
	    →フォルマントパラメタ送信(2)
	      →次の割込要請
	            ↓
	  VOICE割込発生
	    →フォルマントパラメタ送信(3)
	      →次の割込要請
	            ↓
	  VOICE割込発生
	    →フォルマントパラメタ送信(4)
	      →次の割込要請
	            ↓
	  VOICE割込発生
	    →フォルマントパラメタ送信(5)
	      →次の割込要請
	            ↓
	  VOICE割込発生
	    →フォルマントパラメタ送信(6)
	      →次の割込要請
	            ↓
	  VOICE割込発生
	    →フォルマントパラメタ送信(7)
	      →次のフォルマントパラメタセットのテンポラリ設定
	            ：
	            ：
	            ：
	        (割り込み停止中)
	            ：
	            ：
	            ：
	◎先ほど送り込んだフォルマントセットの波形出力が終わりそう。
	    →VOICE割込要請
	            ↓
	  VOICE割込発生
	    →フォルマントパラメタ送信(1)
	      →次の割込要請
	            ↓
	  VOICE割込発生
	    →フォルマントパラメタ送信(2)
	      →次の割込要請
	            ↓

	という具合に、発声が終わるまで上の流れが繰り返される。
	ところが現状のP6VWの仕組みだと、割込停止されてから再びVOICE割り込みが
	発生するまでの無音の間が空いてしまっている。
	これは、音声ストリームが再生波形の残量をチェックして割込再発生の
	指示を出して、7回のVOICE割込発生処理で次のフォルマントセットを送信し
	終わる前にストリームバッファのデータを吐き終わってしまうために
	空白状態が出来てしまう事が原因。

	7回分のVOICE割込は結構処理時間が掛かる。それに加え、VOICEよりもタイマー
	割込の方が優先順位が高いので、これが間に割り込んでくる。
	波形を準備するまでにはそれ相応の準備時間が必要となると、音声ストリームが
	割込発生の指示を出すタイミングを早めれば良いという事になるハズなのだが、
	音声ストリームの残量チェックを無視して割込指示を出しても全然間に合わなかった。

	そこで、音声波形を用意するための7回分の割込を処理するCPU時間と音声
	ストリームの残量チェックの間隔の時間を比較してみたら、残量チェックの
	間隔の方が大きくなってしまい、実際に波形が足りなくなってから音声ストリームが
	残量チェックに来るまでにタイムラグが出来て、その結果音声バッファがスグに
	欠乏してしまう状態になっていた。

	考えてみりゃ、そりゃそうだわな。
	音声ストリームはPSGやFMと同じくVSYNCと同期して動いている。
	VSYNCは 1/60[sec] だから、1/60[sec]単位でしか残量チェックが出来ていない
	事になる。音声合成波形は 1/100 [sec] 単位の波を生成するのだが、
	音の出力が1/60[sec]単位なので、1/60[sec] のチェック間隔を跨いでも、
	7回分のVOICE割込が十分こなせるくらい前にVOICE割込を発注しなければならない。
	チェック処理を前に持って行きたかったら、その分のデータを遅延バッファに
	溜め込んでおく必要が出てくるのだが、音声だけ遅延バッファを増やすと
	今度はPSGやFMやタイマー割り込みなど他の処理と噛み合わなくなってくる。

	となると、残る手段はただ一つ。ストリーム処理の間隔をVSYNCと切り離して、
	1/60[sec]よりも速く動かして、バッファ不足発生と残量チェックの間が空かない
	ようにする事だ。
	そういうわけで、音声ストリームを 1/120[sec] で呼び出すようにしてみた。
	普通の音声に於いてはバッチグー。(ﾟ∀ﾟ)d

	で、試しに歌を歌わせてみたら………………(((( ；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

	アカン…まだ変なところがある…＿|￣|○、ｶﾞｸｯ



■2005.02.05 ver 200 
	・モニタモードにバイナリ表示窓を追加。
	メモリの特定範囲を監視して、前回のコマンド実行からコンソールに戻ってくる
	までの間に内容が変化した箇所を色違いで表示。
	それと、今までだと連続ステップや連続トレース実行中はCPUが一命令実行する
	度に全パラメタを更新していて激烈に重たかったので、連続実行中はレジストリ
	内容だけ書き換えるように修正。I/Oポートやバイナリ部分は、コンソールに
	処理が戻ってきたときに更新される。
	ステップ実行を繰り返す時も、一々ヒストリバックしながらENTER叩くのは
	手間だと思ったので、テンキーのENTER を Auto Re-Command に設定。
	NumPad_Enter を押すだけで直前のコマンド再実行。


■2005.02.01 ver 200 
	・ご要望にお答えして、フルスクリーンでもモニタモードが使えるように変更。
	でも、いいのかな？ 確かに字が大きくなってトレース実行とか見やすくなるけど、
	setbin,getbin などのダイアログが出るコマンドで面倒な事になるような…。
	とりあえずフルスクリーン状態で解像度変更が行われるのは宜しくないので
	最低限の切り替えだけ実装。
	プログラムをトレースしたい時などは、フルスクリーンでやると字が大きくて
	処理速度も速くなって楽チンですな。


■2005.01.31 ver 200 
	・機種の切り替えを組み込んでみる。
	これがまた…初期値を変数定義時に設定してあるグローバル変数を
	どこかの初期化関数でまとめてキッチリ代入しなおさないと、再起動時に
	存在しないビットマップサーフェスにアクセスしに行って例外エラーとか、
	色々困った事に…。グラフィックと機種別のメモリ構成だけをやり直せるように
	初期化と解放の順番をアチコチ入れ替えるなどして、出来るだけ少ない変更で
	ハードの再構成が出来るよう試行錯誤してみたのだけど、纏まっていた初期化関数を
	機能別に分解する必要が出てきたりして、やはり複雑な変更になってしまった。



	・試しにグラフィック描画のピクセル転送をアセンブラで書いてみたのだけど、
	全然スピードが変らなかったどころか、むしろ重くなってないかい！？Σ(ﾟДﾟ;)
	嗚呼、C言語の最適化に負けた…＿|￣|○、
	といっても、BYTEとDOUBLEのキャストが面倒で数値演算PRCも使ってないし、
	ニーモニックの組み合わせ忘れて不器用なコードを書いてるからしょうがないか。
	せいぜいレジスタ変数でお茶を濁すくらいかな？まぁ、無駄な事はやめておこう。
	元々、mkII あたりまでは Pen2-300 でも処理落ちしていなかったワケだし、
	そもそもSRで起動されると音の出力一つ取ってもYM2203チップとして FMとSSG、
	4MHz の音声処理が2つ動くことになるので、PC-6601までの PSG 2MHz 処理
	と比べると…
	(SR機種)/(旧機種) =(FM+SSG)/PSG =(4+4)/2 =4
	…で音の処理の負荷は大雑把に4倍なワケですよ。この辺がヘビーなところ。

	しかし、インラインはラベル指定のたびに一旦括りを外さなきゃいけないのが、
	かなり面倒で不便ですなぁ。

(例
	LB_TR_POS_Y_3:
_asm{
		MOV		EDX,SCWIDTH
		SHL		EDX,4
		TEST	ECX,EDX
		PUSH	ECX
		JZ		LB_TR_POS_Y_4a
		MOV		EAX,[EDI][EBX]
		MOV		EDX,EBX
		MOV		EBX,EAX
		MOV		EAX,COL_MODE3[EBX]
		MOV		EBX,EAX
	}
	LB_TR_POS_Y_3a:
_asm{
		MOV		EBX,EDX
		MOV		AL,[ESI][EBX]
	}
	LB_TR_POS_Y_3b:
_asm{

	他にも単なるスキップなのに一々ラベルを書くのが面倒で、"JMP @f"、"JMP @b"
	が無性に使いたくてたまらなくなったりして…。
	条件反射的に JR を使いたくなってしまうのは Z80 の呪いですか？




	・動作チェックの為の Pen3-700 マシンの Win2k で動かしてみたのだけど、
	何故かFM演奏でモタつくところがある。エミュの動作は100%だから、
	システム全体の処理落ちとは考え難いい。念のためストリーム録音した
	WAVを確認してみると出力されたFM波形自体に遅延が見て取れる。
	普段、Pen2-300 の処理落ちマシンで開発しているから異変に気付かなかった。
	そこで、Busyウェイトが変になったのかと思って調べてみたが、全く問題なし。
	I/Oポートのアクセスログを見る限り特におかしな所は………何かTimerAの
	チェックがやたら何回も入っているな？

	Σ(ﾟДﾟ;)ハッ！はっちゃけた！

	FMのTimerルーチンはYM2203内部に組み込んであるのだけど、考えてみればエミュ
	の方はオプションでZ80とシステム全体に速度調整が入るようになっている。
	現在のCPU速度とシステム全体の調整値は 94%,94%、に設定されているから
	そりゃあ、同じ時間のタイマーを取ってもYM2203とZ80ではZ80の方が処理が
	遅れるに決まっている。CPUのタイマー割り込みとも同期が取れない。
	FMはZ80の実行ステータスでタイマーカウンターをとらないとダメって事か…。

	というワケでカウンター部分をCPUの方に移動。
	アッサリ、直った (;ﾟ∀ﾟ)



	・ミッドナイトマジックが動かない原因を調べてみる。
	まずは途中で固まるまでのI/Oポートアクセスを記録。
      ：
      ：
7415:IN (d0H) ->00H
7415:IN (d0H) ->81H
7415:IN (d0H) ->1fH
7417:IN (d0H) ->00H
70ff:OUT (b1H),f7
e643:OUT (63H),fe
800a:OUT (faH),fa
800e:OUT (c1H),fb
800e:OUT (b0H),f2
8012:OUT (c8H),e2
8015:OUT (caH),00
8017:OUT (cbH),00
8019:OUT (ccH),00
8022:OUT (a0H),08
8026:OUT (a1H),00
8022:OUT (a0H),07
8026:OUT (a1H),3e
8022:OUT (a0H),00
8026:OUT (a1H),00
8022:OUT (a0H),01
8026:OUT (a1H),00
    (停止)

	こうなる。
	IN (D0H) はFDCからデータの受け取り。
	その直後には OUT (0B1H) だの (0C1H),(0C8H) とシステムラッチを突っついて
	いるので、その辺なんだろうなと…停止した後のコードを追いかけてみると、

      LD   HL,Z0002   ;802A 21 8A 80
Z0514:LD   DE,0FF00H  ;802D 11 00 FF
      LD   BC,018H    ;8030 01 18 00
      LDIR            ;8033 ED B0
      EI              ;8035 FB
      LD   A,06H      ;8036 3E 06
      CALL Z0003      ;8038 CD 82 ED
      JP   Z0004      ;803B C3 07 81

	割込みテーブル部分にアドレスを再設定して、どこかにジャンプ。
	ジャンプの前に EI があるという事は割り込み受付OKって事ッスね。
	モニタモードのブレークポイントで止めると、TIMER と VRTC 割り込みが
	発生待機状態になっている。
	ところが、VRTC割り込みが発生すると復帰せずに暴走。
	何じゃコリャ？ 直前の OUT(0FAH) を見ると、VRTC は io_BCH の設定ベクタ
	が有効になっていないので標準の 22H って事で、割り込みテーブルを眺めてみると。

FF00:88 80 ----
FF02:B2 ED KEY3
FF04:88 80 RS232C
FF06:4A DA TIMER
FF08:88 80 CMT-R
FF0A:88 80 ----
FF0C:88 80 ----
FF0E:88 80 KEY1
FF10:88 80 ----
FF12:88 80 CMT-E
FF14:BD ED KEY2
FF16:C8 ED JOY
FF18:FF 18 TVR
FF1A:B7 F1 DATE
FF1C:C9 AF ----
FF1E:CD 47 ----
FF20:00 AF VOICE
FF22:CD 44 VRTC  <<<<<<<<<
FF24:00 CD ----
FF26:9C 00 ----

	う〜ん、設定されているなぁ。
	それでは、割り込みジャンプ先のアドレスを見てみると…

      LD   H,00H    ;44CA 26 00
      INC  L        ;44CC 2C
      CALL 03FB9H   ;44CD CD B9 3F  <<<<<<<<
      POP  BC       ;44D0 C1
      POP  HL       ;44D1 E1
      RET           ;44D2 C9
Z1340:CALL 04514H   ;44D3 CD 14 45
      AND  0FH      ;44D6 E6 0F
      RET  Z        ;44D8 C8

	( ﾟДﾟ)？
	どう見てもサブルーチンの開始位置じゃないよ、ここ。
	モニタモードでVRTCの割り込みジャンプ位置を EI,RET だけのダミーアドレスに
	書き換えたら、見事に動くようになった。

	って事は何だ？ VRTCは発生したらいけないという事なのかな！？
	何を以って発生させない条件としているのか？ もしかして io_FAH ？
	しかし、io_FAH は先の 2005.12.11 で、io_FAHのタイマー割り込み部分を
	マスクしてしまうとタイマー割り込みが発生しなくなる不具合が発生した事から、
	EI/DI と直接関係無いと予想を立てたはずなのだけど…。
	2005.01.10 にはテクニカルマニュアルの表記がおかしいとまで思ってたのに(^^;;
	こりゃ、予測をひっくり返す必要性が出てきたなぁ。

	現状予測を導き出したタイマー割り込みの発生条件の部分を再度見直してみる。
	ベクタ発行の条件は↓こうなっている。

	if((!(rf3&0x04))&&(!(io_B0H&0x01))&&(TIMER_flag)){ // タイマ割り込み発生

	タイマー割り込みは io_F3H と io_B0H、2つのポートフラグがスイッチになる。
	現在はこれらの条件が論理積(AND) となっているが、これが io_FAHのマスクも含めた
	論理和(OR)だったとしたら…ちょっと実機で試してみた。
	BASIC上にて…
	OUT &HF3,INP(&HF3) OR 4  →カーソル点滅停止(タイマー割り込みが止まった)
	OUT &HB0,INP(&HB0) OR 1  →カーソル点滅停止
	という事は、io_F3H と io_B0H のフラグは論理積で正しい。
	OUT &HFA,INP(&HFA) OR &h10  →カーソル点滅継続

	Σ(ﾟДﾟ;)ヅガーン！
	つまりio_FAHは他の関連フラグとは論理和の条件になると？？？

	if(TIMER_flag){
	   TIMER_flag = FALSE;
	   if((!rf3&0x04)&&(!io_B0H&0x01)) intr_no=rf7/2;//port(F7H)の設定が割込値になる
	   if(DEF_TIMER_INTR)              intr_no=rba/2;//port(BAH)の設定が割込値になる
	}

	って事は、他の割り込みも io_FAH のマスクでEI/DI決めちゃって良いのかな…
	VRTCの場合はこうなると…。

	if( VRTC_flag ){  // VRTC割り込み
	   VRTC_flag=FALSE;
	   if((!io_B0H&0x01)||(!io_FAH&0x10)) intr_no=rbc/2;//port(BCH)の設定が割込値になる
	}

	と、少なくともミッドナイトマジックを分析する限りこういう推測が成り立つと。
	他のソフトの動作如何によっては、また変るかも知れないけど…。
	あぁあ、何か不安だなぁ…((((;ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ



	・上記の推測に基づいてio_FAH のマスクによるEI/DIを反映したら、
	早速起動すらしなくなったよ…＿|￣|○、ガクッ
	今度の原因はタイマー割り込みでなく JOYSTICK 割込み。
	io_FAH でJOYSTICKのマスクが外れ、io_B9H のベクタが有効になるわけだけど、
	ここの設定が io_B9H =010H(ダミー) になってるし…
	もう、どないせーっちゅーねん…
	もしかして特殊なのってタイマーじゃなくてVRTC の方なのか！？
	コイツがio_FAHのマスク有効だと割り込みが発生しないのか？？？？？

	しかし、良く良く考えてみれば io_FAHのフラグが有効でないと割り込みが発生
	しないってのはおかしいんだよな。io_FAHのマスクでEI/DI決まってしまったら
	旧機種モードが全く動かなくなる。
	ってことは、全体的には 2005.12.11 の推理が正しい。
	ただ、割り込みによって動作が異なるという事なのだろう。
	そういう規則性が無いのが一番厄介なんだよなぁ…(;´Д｀)
	もしかして、SR独特の割り込みだけ EI/DI の扱いになるのか？
	サッパリわからん。SRの割り込み解釈に関しては完全に迷走している。

	さて、VRTC以外の割込ルーチン元に戻すか。
	何か無駄な時間ばかり食ってるな (ﾟДﾟ)ブツブツブツ…
	お陰でここに書くネタには困らないけど…。



■2005.01.29 ver 200 
	・数日前の続き、エミュとメニューと情報やり取り部分を仕上げてしまう。
	受け渡し情報はシステムメニューとエミュレータのスレッド間で使用している
	ファイルマップをそのまま利用する。システムメニューを飛ばして直接エミュレータ
	スレッドが立ち上げられたら、INIファイルを読み込んだ後、エミュ側スレッドで
	新たにマップを作成。
	ん、もしかしてエミュとメニューを分離してしまったら、システムメニューの
	存在意味が無くなってしまう？…ってな事でも無いか。エミュレータ起動中に
	変更したい項目なんてたかが知れてるもんね。使用頻度の低いオプション項目は
	システムメニューにだけあれば良い。
	うう、しかし2つのアプリを交互に修正して整合性をとるのはシンドイなぁ。
	丸一日かかってしまった…。


	・そういえば、エミュレータとサブメニューモジュールのアイコンどうしよう…。
	6001っぽく赤黄緑青の原色バリバリで攻めてみますか (;ﾟ∀ﾟ)



■2005.01.25 ver 200 
	・前々から問題になっていた、ファイルの選択に Windows標準ダイアログを使うと
	RPCRT4.DLL が例外エラーを返してきて、エミュレータ終了時に例外エラーを
	引き起こす不具合を調査。
	といっても、Windowsカーネル内部の問題だから調べようが無いのだけど、
	Allegro が何かチョッカイだしているのは間違いない。
	ダイアログ表示時に例外が数回も連発される所を見るとエクスプローラーと
	Allegroでフォーカスの取り合いでもやって、メモリの不具合を誘発してる？
	デバッグ窓に怒涛の如く”例外エラー例外エラー例外エラー”とか表示されるのは
	精神衛生上良くないかも…(;ﾟДﾟ)ﾊｧﾊｧ
	基本的に P6VW は320x240フルスクリーンのガチンコゲームプレイが目的なので
	窓モード実行中のメニューを作りこむ事には消極的なんだけど (Allegro が
	暴れん坊という事もある)、デバグモードで動かしながらの開発作業がやりにくい
	と言われるとP6アプリ開発支援に力を注ぐ身としてはちょっと問題がありますな。
	確かに、Allegroメニューは窓モードだと小さ過ぎて見づらいし、マウスでは
	操作しづらい…。でもキーボードオペレーションで考えるとAllegroメニュー
	の方が全然操作しやすいんだよな、これが。
	もしかして、エミュレータってーとフルスクリーンのキーボードオンリーで
	バリバリやってる自分が異端？


	・Allegroさんが余りにも強力にスレッド管理をやろうとするので、標準メニューは
	Allegro の監視が及ばないように外部プログラムに持たせることにする。
	ということで、メニュー画面を出すだけのサブモジュールをシステムメニューの
	切り張りでチョイチョイっと作成。オプションのカテゴリは Allegro のエミュ内
	メニューと同じ形になるようにダイアログの整形しなおし。
	まぁ、昔作ったけどAllegroに干渉されてマトモに表示できなかった文字メニューを
	そのままコンテキストメニューに置き換えただけですな

	それにしても Allegro は神経質なスレッド管理やってるよなぁ。
	そりゃ、汎用ライブラリともなるとデバイスとのI/Fは全て専用の独自関数を
	使って管理する事が大前提になっているのはわかるけど、やり過ぎは良くない。
	WaitForSingleObject で外部スレッドの監視ループを回したら、Allegro 側の
	監視ループが肝心の自分のメッセージ受け取れなくなってフォーカスアウトも
	検知できなかったりして…いや〜、しつこい (;´∀｀)
	なんやかんやで、メニュー表示は完成。

	オプションに機種の変更ボタンを付けるべきか付けざるべきか考え中。
	やって出来ない事は無いけど、エミュレータ動作中に機種変えないよなぁ、普通。
	


■2005.01.25 ver 200 
	・何をするにしても現状の速度だと時間のロスが多すぎるような気がするので、
	高速化に着手してみる。

	○画像の表示が等倍で行われるときは拡縮転送でなくベタ転送で行う。

	○TAPEやDISKやTAPEカウンタが変化した時だけ画面上部ステータスを描画する。

	○ストリーム波形更新の関数を RC-Filter 有り無しに分け、PSGのみRC-Filter処理
	  を通すようにする。( VOICE/TAPE/FM はフィルタ無し )

	○メニューとエミュを別アプリに分離。(これはメモリ節約)

	○I/Oポートの switch-case は冗長すぎるのでI/Oポート処理を関数にバラして、
	  機種ごとの関数テーブルジャンプ方式に変換。(うっひょ〜デンジャラス！)

	結果はそこそこかな？


■2005.01.22 ver 200 
	・640x480 の解像度で、N60(256x192)の画面を表示しようとすると、
	250% の倍率が収まりきってしまい、回りのステータス表示を無視して
	エミュレータ窓一杯一杯に画面を表示しようとするので、倍率を
	制限して200%以上の拡大率にならないようにする。


	・実行速度がスッカリ重たくなってしまったなぁ。
	様々な箇所での機種別条件分岐が爆発的に増えたせいなんだけど…。
	ここまで来たら、画面の表示とか、I/Oポート処理とか、メモリ管理とか、
	機種毎にDLLに分解して、条件分岐を使わないでゴッソリ別のルーチンを
	呼び出すようにすれば、少なくとも旧機種の実行はSRの処理に足を引っ張られる
	事も無くなるんだけど…メンテナンス性の事を考えると同じソースが幾つも
	重複するのは好ましくないや。とはいえ、余りに末端での条件分岐が多すぎるので
	もう少し根っこのほうに機種別の分岐を持って来るよう調整しよう。
	まぁ、SRはどうやっても全機種分の処理が必要だから重くなるのは仕方なし。

	現状を挙げると、Pen2-300 だと フレームスキップを 9 にしても
	実行速度は 80% 程度。Pen3-700 だと辛うじて FSKIP=0,100% かな？
	因みに、デバッグ版の実行は  Pen2-300  で FSKIP=9,15% 。
	ログを吐いてる最中は 0% (笑。
	ログを出し切るまで5分ぐらい固まったりして…(；ﾟ∀ﾟ)ｱﾋｰ


	・ミュージライターで音が出ない原因を追いかけてみた…。
	どうやら、IN(0A3H) YM2203ステータスチェック でエラー(0FFH)しか帰って
	こなくて、YM2203 がBUSY(80H)状態と違いして無限ループしているようだ。
	ソースを確認したら、SRモード(MODE:6)以外、ポートの読み取りを拒否してた。

	// ---------- YM-2203 ----------
	case 0xa3:
	  if(get_p6sr()){
	      rval=io_A3H=YM2203_status_port_r(0);
	  }
	  break;

	ミュージライターは N60m(MODE:5) で動くから、読み取りできなかったわけね。
	ううむ…(´･ω･`)、機種タイプを跨いで使用されるSRポートもあるのか…
	これは気をつけないといけないなぁ。

	// ---------- YM-2203 ----------
	case 0xa3:
	  rval=io_A3H=YM2203_status_port_r(0);
	  break;

	上の様に修正して、一件落着。


	・何故か付属のサウンドテストプログラムでは音が出ない。
	そこで、サウンドポート(io_A0H,io_A1H)への出力だけログに記録してみるが…

	163d:IN (a3H) -&gt;03H
	164c:OUT (a0H),24
	1652:OUT (a1H),d1
	163d:IN (a3H) -&gt;83H
	163d:IN (a3H) -&gt;03H
	164c:OUT (a0H),42
	1652:OUT (a1H),1b
	163d:IN (a3H) -&gt;83H
	163d:IN (a3H) -&gt;83H
	163d:IN (a3H) -&gt;03H
	164c:OUT (a0H),4a
	1652:OUT (a1H),1d
	163d:IN (a3H) -&gt;83H
	163d:IN (a3H) -&gt;03H
	164c:OUT (a0H),46
	1652:OUT (a1H),28
			:
			:
			:

	ポートアクセスの羅列だと見難くてしょうがない。
	で、SOUND命令に置き換えてみる。

5 sound &h27,&hbc:rem &lt;&lt; TIMER SET (音色設定前)
6 sound &h32,&h01:rem 音色設定
7 sound &h3a,&h01:rem   ↓
8 sound &h36,&h01
9 sound &h3e,&h01
10 sound &h42,&h7f
11 sound &h4a,&h7f
12 sound &h46,&h7f
13 sound &h4e,&h7f
14 sound &h52,&h1f
15 sound &h5a,&h1f
16 sound &h56,&h1f
17 sound &h5e,&h1f
18 sound &h62,&h1f
19 sound &h6a,&h1f
20 sound &h66,&h1f
21 sound &h6e,&h1f
22 sound &h72,&h1f
23 sound &h7a,&h1f
24 sound &h76,&h1f
25 sound &h7e,&h1f
26 sound &h82,&h0a
27 sound &h8a,&h0a
28 sound &h86,&h0a
29 sound &h8e,&h0a
30 sound &hb2,&h07
31 sound &h40,&h7f
32 sound &h41,&h7f
33 sound &h42,&h7f
34 sound &h43,&h7f
35 sound &h44,&h7f
36 sound &h45,&h7f
37 sound &h46,&h7f
38 sound &h47,&h7f
39 sound &h48,&h7f
40 sound &h49,&h7f
41 sound &h4a,&h7f
42 sound &h4b,&h7f
43 sound &h4c,&h7f
44 sound &h4d,&h7f
45 sound &h4e,&h7f
46 sound &h28,&h00:rem &lt;&lt;&lt;&lt;&lt; KEY_OFF
47 sound &h28,&h01:rem &lt;&lt;&lt;&lt;&lt; KEY_OFF
48 sound &h26,&hba
49 sound &h25,&h01
50 sound &h24,&hdd
51 sound &h42,&h27
52 sound &h4a,&h31
53 sound &h46,&h3c
54 sound &h4e,&h45
55 sound &had,&h13
56 sound &ha9,&h0a
57 sound &hae,&h32
58 sound &haa,&hde
59 sound &hac,&h34
60 sound &ha8,&h4c
61 sound &ha6,&h3b
62 sound &ha2,&h0a
63 sound &h27,&hbf:rem &lt;&lt; TIMER SET (音色設定後)

	これがタイマーセットでウェイトが入る前までのポート出力なんだけど…
	音色と波形の設定をしているのだけど、何故 KEY_OFF命令しか無いのだろう？
	これでは音が出るわけ無い。何かキーをONにするタイミングがあるのかと
	ソース内を眺めていたら、内部タイマー有効時に使用される タイマーA の
	ルーチン内に全チャンネルをONにする所がある。
	27Hレジスタ のタイマーモードセットの内訳は下の通りだから…
	あ…CSMが再現されていないという事なのか！？ Σ(ﾟДﾟ;)ガーン

┏━━━━━━━━━━┳━━━━━┳━━━━━┓
┃YM2203_27Hレジスタ  ┃波形設定前┃波形設定後┃
┣━━┳━━━━━━━┫ の27Hの値┃ の27Hの値┃
┃bit ┃  フラグ内容  ┃  = 0BCH  ┃  = 0BFH  ┃
┣━━╋━━━━━━━╋━━━━━╋━━━━━┫
┃ 0  ┃  LOAD-A      ┃    0     ┃    1     ┃
┃ 1  ┃  LOAD-B      ┃    0     ┃    1     ┃
┃ 2  ┃TIMER-A Enable┃    1     ┃    1     ┃
┃ 3  ┃TIMER-B Enable┃    1     ┃    1     ┃
┃ 4  ┃  RESET-A     ┃    1     ┃    1     ┃
┃ 5  ┃  RESET-B     ┃    1     ┃    1     ┃
┃ 6  ┃  3SLOT MODE  ┃    0     ┃    0     ┃
┃ 7  ┃  CSM MODE    ┃    1     ┃    1     ┃
┗━━┻━━━━━━━┻━━━━━┻━━━━━┛

	CSM MODE というのは複合正弦波モデルで、88SRのシルフィードや
	ゼリアードなどでゴショゴショとおしゃべりする、あの機能。
	波形が生成されてないのかな？


■2005.01.20 ver 200 
	・動作テストの結果レポートをもらったのだけど、う〜む、やはり市販ソフトが
	動くには、実装のおかしな箇所が沢山残っているみたいで…(;´Д｀)
	ユーザーインターフェース部分の不具合は作業優先順位が低いので放置して
	おくとして……まず最優先に何が必要か？
	テスト用ソフトを読み込ませる手間暇を無くす為に、どこでもセーブと
	ロードが必要かな？
	ということで、突貫でSR用どこでもLOAD/SAVE を作成。
	FM音源はレジスタにリセットを掛けてしまうので完全に元の状態に戻るわけじゃ
	ないけど、メインメモリの状態が保存できるから今のところはこれで良いや。

	現状は大量のログに埋もれて原因の特定作業でアップアップ。



	・聞いたところによると、mkIISR と 66SR のROMって全く同じらしい。
	確かに mkIISR と 66SR 判別のI/Oポートビットフラグが有るけど、
	何かFDDデバイスの判別にでも使うのかと思っていた。
	って事は、必然的に mkIISR も 1DDドライブを扱う事になるわけですな。
	6601/mkIISR/6601SR 全てFDCドライブで、異端なのは mkII だけか…。
	miniFD と FDC の処理受付順番を入れ替えておこう。


	・IN (0A3H) でFM音源ステータスにREDAY(00H)しか帰って来ないので、
	デバッガでチェック。
	って、BUSYフラグを立てる所が "#ifdef" で飛ばされてるだけだった…orz
	FM.H の FM_BUSY_FLAG_SUPPORT 定義を有効に修正。
	FM のBUSYタイマーにはZ80の内部タイマー(秒単位)を使用するので、
	そのルーチンも追加。
	でも RAINE のBUSYタイマーは…

	/* Really it does not seem to make any hearable difference,
	  it seems to be among these things that mame thinks are necessary to
	  be accurate, but it does not make any difference for any normal
	  human being, while eating cpu power at the same time.
	  So disabled, until we find a place where it's usefull. */

	…こんなん書いてあって、機能が無効になってるんだよな。
	有効に使える場所が見つかるまで…って事はアーケードはBUSYは見てないのか。
	この未使用機能をそのまま実装してしまうと 1sec の BUSY が有効になるので、
	キークリック音のたびに 1sec 止まる事になってしまう。
	まぁ、音源チップのクロックはCPUより遥かに高速なわけだから、
	適当に調整しておけば良いかな？
	少なくともタイマー割り込みよりは遥かに小さく設定しておく必要性が
	あるだろう。BASICでのFM音楽演奏に支障を来たさない様に調整。
	どこかで聞いた話によると、26音源ボードの場合、レジスタにデータを送ると
	6.0x10^-7 [sec] 程度のウェイトが入るらしい。
	これをCPUステートに置き換えると…

	wait = 6 *10^-7 *CPU_STATE;

	で良いのかな？  ザックリと単純化すると

	wait = 3138893/1666666 = 2 ？

	( ﾟДﾟ)は？ これ、実質ノーウェイトじゃないか。何か違うような気がする。
	もう少し色つけておくか(イイカゲンだなあ)。


	・FM.C のYM2203システムは内部タイマー処理と外部タイマー処理、好きな方を
	選んで使えるようになっている。(デフォルトで内部タイマーOFF…)
	しかし、内部タイマーは音源チップクロックをベースに時間をカウントするので、
	オプションでスピード調整したエミュのシステムと整合が取れなくなって
	しまうという事かな？そういうわけで、通常は自前の外部タイマーを
	使用すべきなのかもしれない。
	このFM音源タイマー、JUD氏の説明によると
	------------------------------------------------------------
	かいつまみますと、いわゆる分周タイマですかこれ、
	Ａが １２×（１０２４−ＮＡ）ｆ    ＮＡ：１０ビット（２４・２５Ｈ）
	Ｂが １９２×（２５６−ＮＢ）ｆ    ＮＢ：８ビット（２６Ｈ）
	ｆ：３．９９３６ＭＨｚ／分周数

	デフォだと分周数は６のはずです。
	２ＥＨと２ＦＨが分周コントローラですね。
	------------------------------------------------------------
	という事で、OPNの処理ルーチンを見る限り、分周コントローラが
	呼び出されると、タイマー設定値と周波数から自動的に計算が
	行われ、タイマールーチンには 0.005 [sec] みたいな感じで、
	[秒] に変換された数値が送り込まれてくると…
	ここで、1秒間に処理されるZ80のステート数(CPU_STATE)と掛け合わせ、
	Z80サイクルのタイマー発生時間を導き出すわけですな。

	cycles = duration * CPU_STATE;

	そして、この周期でタイマーハンドラを呼び出して、タイムオーバー
	フラグを立てる。



■2005.01.16 ver 200 
	・まだ不備な所はあるけど、とりあえず市販ソフトの動作を確認したいところ。
	SR用ソフトを持っている人に投げて確認してもらおう。自分は持ってない。
	となると、デバグ出力の掃除をしないと不味いな。
	今は一回のテストで900KB位のログが出てくるし…(^^;;


	・ディスクに正常に書き込み出来ない原因を追いかけてみる。
	まずブランクディスクを何枚か作って、様々なタイプのプログラムをテープから
	CLOAD しては SAVE や BSAVE を繰り返し、後ほどそれを LOAD してみるのだが、
	全てのプログラムが256バイトブロック単位で飛び飛びでしかデータが
	書き込まれていない。書き込まれるセクタがスキップされているのかと
	思ったら、飛ばされたブロックのデータが 00H で塗りつぶされてしまっている。
	空ディスクのセクタは 0FFH で埋め尽くされているはずだから、何らかの
	バイナリを書き込もうとしたけど、FDCバッファの内容が00Hに変わって
	しまったと言うことになるのかな？
	何これ？6601 だと正常に動いているのに…( ﾟДﾟ)？ナンデ


	・鬼の様にDEBUG_LOGを出力して確認してみたら(原始的)、io_D3H のFDCバッファ
	が上書きされている事が判明。地道にソースを追いかけると、FDCバッファの
	インデックスポインタの初期化を思いきり間違えていた Σ(ﾟДﾟ；)ガーン

	×：fdc_idx[i]=0;
	○：fdc_idx[j]=0;

	なんという初歩的ミス…。
	こんにちはマイコン でも扱えるようなレベルだ。


	・あれ？FDCの書き込みテストで、間違えてmkII用のBASICディスクに何か
	書き込んでしまったよ。というか、ディレクトリとFATの部分に書き込まれている
	データ内容によっては、普通にディレクトリ/FAT情報と勘違いしてデータを
	書き込んでしまう。これは不味いな…(´･ω･`)
	SR と mkII ではマウントできるディスク種別を分けるようにするか。
	mkII/6601 の時は 1D/片面2D (ID:00H) のみ、
	SR の時は 1DD/両面2D (ID:40H,10H) のみ、
	という分け方で、適応外ディスクは警告を出してEJECTさせるようにする。
	変な形式のベタディスク(DSK)だけはどうやっても判別出来ないけど…。



■2005.01.14 ver 200 
	・先のディスクアクセス高速化のお陰でFDCアクセス音が非常にけたたましく
	なってしまった。現在はセクタアクセス単位に効果音を呼び出しているので、
	これをトラック単位のアクセスで音を鳴らすように修正。
	別に厳密なディスクモーターの動きをなぞっているわけじゃなくて、
	ディスクアクセスしている事が使用者に判かりさえすれば良いので、
	この辺はアバウトに調〜整〜っと。

	SEEK音を出すところのコメントに
	”// シーク・ジ音！ ヽ(ﾟДﾟ)  シーク・ジ音！ ヽ(ﾟДﾟ)”
	とか書いてあってズッコケた。



■2005.01.10 ver 200 
	・SR実装不備の最後の部分、音声合成が発声されない原因を調べてみる。
	io_E0H、io_E2H、io_E3H に片っ端からブレークポイントを仕掛けて、先ずは
	SR-BIOSルーチンの動きを把握。

	IN(0E0H) でuPD7752 の状態チェックの後、初っ端 OUT(0E3H) に謎の値(020H)が
	放り込まれてそれっきり。
	mkIIの場合だと OUT(0E3H) に 00H〜04H が入ってきたら固定語再生、
	0FEH が来たらフォルマント開始なので、それ以外の値はエラーとして
	未処理になっているんだよな。

	ではフォルマント送信を開始する箇所(OUT(0E3H))はどこかと検索をかけると
	2箇所見つかる。

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
Z0102:  IN  A,(0E0H)    ;1BAB DB E0
        BIT 7,A         ;1BAD CB 7F
        RET             ;1BAF C9
Z0103:  LD  A,0FFH      ;1BB0 3E FF
        OUT (0E3H),A    ;1BB2 D3 E3
        RET             ;1BB4 C9
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
        DI              ;1E12 F3
        LD  A,(IY+115D) ;1E13 FD 7E 73
        OUT (0E2H),A    ;1E16 D3 E2
        LD  A,(IY+114D) ;1E18 FD 7E 72
        OUT (0E3H),A    ;1E1B D3 E3
        POP IY          ;1E1D FD E1
        POP HL          ;1E1F E1
        POP AF          ;1E20 F1
        EI              ;1E21 FB
        RET             ;1E22 C9
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

	1BB2H の箇所は、音声ステータス監視の後に 0FFH が送りこまれるので
	音声終了箇所と思われる
	1E1BH の箇所は、発生速度設定 OUT(0E2H) の後にあるので、ここが
	音声発生開始位置となる。この場所で謎の値 020H が放り込まれてくるわけだ。
	しかし、このコマンドが実行された後をデバッガで追いかけてみても、
	フォルマント送信 OUT(0E0H) が行われずに、ステータスチェックを行って
	音声合成BIOSは終了してしまう。

	今度はフォルマント送信箇所 OUT(0E0H) を探してみる。
	1箇所だけ見つかる。

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
Z0591:  IN  A,(0E0H)     ;1F1E DB E0
        BIT 6,A          ;1F20 CB 77
        JR  Z,01F29H     ;1F22 28 05
        LD  A,(HL)       ;1F24 7E
        OUT (0E0H),A     ;1F25 D3 E0
        DEC HL           ;1F27 2B
        RET              ;1F28 C9
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

	このアドレスを遡上して行くと、1E23H まで行き着くのだが、
	どのBIOSルーチンからこのアドレスが呼ばれていない。
	そこで予想される事は、音声発生を指示した後の "EI、RET" という終わり方と、
	io_FAH のポート実装を試みたときにあったVOICE割込みの存在と、
	音声合成の仕様から推測するに、音声データが必要なときにVOICE割り込みを
	発生させてフォルマントパラメタセット(7バイト) の送信を促しているのでは
	ないかという事。
	そこでSR-BASICの I レジスタの割込みテーブルアドレスを見ると、テーブルは
	0E600H に設定されているので、そのメモリを並べて見てみると…
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
E600  BE 03
E602  E4 02
E604  C0 03
E606  EF 03
E608  D8 03
E60A  BE 03
E60C  BE 03
E60E  D7 02
E610  D7 02
E612  EA 03
E614  DF 02
E616  B6 03
E618  23 1A
E61A  CA 19
E61C  30 1A
E61E  BE 03
E620  23 1E    <<<<<<<<<
E622  30 10
E624  00 00
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
	あった。
	0E620H に先にフォルマント送信 OUT(0E0H)ルーチンに繋がるルーチンの
	アドレスとして出てきた 1E23H が並んでいる。
	これにより、20H 割り込みがVOICE割り込みと断定して良いだろう。

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
        DI                ;1E23 F3
        PUSH HL           ;1E24 E5
        PUSH AF           ;1E25 F5
        LD   HL,(0FFD0H)  ;1E26 2A D0 FF
        CALL 01F1EH       ;1E29 CD 1E 1F
        LD   A,(0FFD8H)   ;1E2C 3A D8 FF
        INC  A            ;1E2F 3C
        CP   07H          ;1E30 FE 07
        JR   NC,01E3EH    ;1E32 30 0A
        LD   (0FFD8H),A   ;1E34 32 D8 FF
        LD   (0FFD0H),HL  ;1E37 22 D0 FF
        POP  AF           ;1E3A F1
        POP  HL           ;1E3B E1
        EI                ;1E3C FB
        RET               ;1E3D C9
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

	後は予測実装になるわけだけど、OUT(0E3H),20H が行われた時点で、第1回目の
	VOICE割込み発生が促される。それから後は、フォルマントデータが1つずつ
	割込みルーチン内で送り込まれ、送り込まれたデータを受け付けたら
	次のVOICE割り込みが発生するに違いない。
	そしてOUT(0E3H),0FFH が来たら割込み停止となるのだろう。


	・上記推論通り割込み発信を実装したところ、波形と波形の間に空白が
	出来てしまった。これは割り込みで次のフォルマントデータを要求しても、
	その送信処理をCPUが行っている間に音声バッファにある残りの波形が再生しつく
	され、音が出力されない空白期間が出来ている事を意味しているわけですが…。
	それにしては、空白が大き過ぎるような気がする。
	SRではmkIIの様に最初にTALK文字列全文を一気に変換してからフォルマント
	データを順次出力するのではなく、一語ごとにフォルマント変換し、段階的に
	音声合成チップに送り込んでいるみたいだ。そういう意味ではmkIIとは比較に
	ならないくらい音声発生中の中間処理に時間を裂かれるという事になるけど…。
	後でTALK文字をフォルマント変換する処理にどれだけ時間が食うのか
	計ってみるか。


	・VOICE割込みの処理でデバッガ追いかけていて思い出したのだけど、
	やっぱりio_FAH  のビットフラグは、io_B8H〜io_BFH の割込みアドレスに
	対応させちゃって良さそうだ。
	io_FAH 各ビットは特定の割り込みに関連付けられているわけだけど、
	このマスクが有効になったら、その割込みベクタはデフォルトのベクタ値から
	io_B8H〜io_BFH に設定されている値に切り替わるという事で…。
	実際、SR-BASIC 動作中は、io_FAH の値は 0EFH になっていて、
	VRTC の割込みベクタ変更だけが有効になっている。

┏━━━━━━━━━━┳━━━━━━━━━━━━━━━━━┓
┃  io_FAH ポート     ┃          発行割り込みベクタ      ┃
┣━━┳━━━━━━━╋━━━━━━━━┳━━━━━━━━┫
┃bit ┃関連割り込み  ┃    ０：有効    ┃    １：無効    ┃
┣━━╋━━━━━━━╋━━━━━━━━╋━━━━━━━━┫
┃ 0  ┃  sub CPU     ┃io_B8Hベクタ有効┃      ？        ┃
┃ 1  ┃  JoyStick    ┃io_B9H    〃    ┃     16H        ┃
┃ 2  ┃  Timer       ┃io_BAH    〃    ┃io_F7Hベクタ有効┃
┃ 3  ┃  Voice       ┃io_BBH    〃    ┃     20H        ┃
┃ 4  ┃  VRTC        ┃io_BCH    〃    ┃     22H        ┃
┃ 5  ┃  RS-232C     ┃io_BDH    〃    ┃     04H        ┃
┃ 6  ┃  Printer     ┃io_BEH    〃    ┃     24H        ┃
┃ 7  ┃  EXT_INT     ┃io_BFH    〃    ┃      ？        ┃
┗━━┻━━━━━━━┻━━━━━━━━┻━━━━━━━━┛

	Mr.PCテクニカルコレクションの解説には『各種割り込みのDI/EIの切り替えを
	行うためのポートです。』と書いてあるから "DI/EI" の単語に引っ掛かって
	しまうけど、これは表現の仕方が違うような…。
	ところで、SUB_CPU と EXT_INT 割込ベクタって何だろ？
	今現在未確定で空いているベクタは、00H,0AH,0CH 。割込テーブルのジャンプ先を
	見ると割込復帰だけのダミールーチンに割り当てられている。
	まぁ、いいや。当面放置。



■2005.01.08 ver 200 
	・何気なくDISK-BIOSの初期化をデバッガで追いかけていたら、途中でステート
	メントエラーを受け取って状態初期化に飛ばされる所がある事が判明。
	エラーの値 (0ffh) が返って来るのは、io_D4H 。
	IOポートの該当箇所を見てみたら、IN命令の io_D4H の値を返すところが
	実装されていなかったりして…（＾＾；
	普通に READY(00H) の値を返すように返すようにしたら、ディスクアクセスの為の
	実行プロセスが半分ぐらいになりましたよ…Σ(ﾟДﾟ；)ガーン
	ついでなので、FDC内部で転送中の擬似ウェイト部分の待ち時間を半分にしたら、
	更に高速に…Σ(ﾟДﾟ；)ガガーン
	結果、FDCのディスクアクセスが３倍ほど速くなりました(当社比)。
	今まではDISK-BIOSの内部で散々無駄な処理が行われていたのね…orz


	・モニタモードの強化。
	▼コマンドラインにヒストリー追加 (16コマンドまで)。
	▼メモリダンプにRAM専用コマンド追加。 "dr **** ****"
	▼ディスアセンブラにRAM専用コマンド追加。 "ur ****"
	    (通常ダンプだと現在のメモリバンクの内容が出てくるので…)
	▼ブレークポイントに割込ブレーク追加。 "break intr **"
	▼割込みフラグの状態監視表示を追加。

	開発環境強化の為ならプログラムの無駄遣いなんて気にしない気にしない。
	(*ﾟ∀ﾟ)アヒャ


■2005.01.05 ver 200 
	・[ホイッスル現象考察〜グランゼルメモ]

	○ホイッスル(MAX発音方)   (※単音では聴こえない)
	1.register 0-5 の内容を全て 0 にする。(全ch最高音程)
	  SOUND 0,0:SOUND 1,0
	  SOUND 2,0:SOUND 3,0
	  SOUND 4,0:SOUND 5,0
	2.register 8-10 を 15 にする。(全ch音量MAX)
	  SOUND 8,15
	  SOUND 9,15
	  SOUND 10,15

	○鳴らない場合
	1.register 7 を 56 にする。(3ch発声、ノイズなしセッティング)
	  SOUND 7,56
	2.register 1 を 1 にする。(ch.A を低音設定。)
	                          (これがキッカケで全ch発音開始する時も。)
	  SOUND 1,1
	3.register 1 を 0 に戻す。
	  SOUND 1,0

	○これでも鳴らない場合
	1.register 3,5 を 1 にする。(ch.B,C も低音設定)
	  SOUND 3,1:SOUND 5,1
	2.register 3,5 を 0 に戻す。
	  SOUND 3,0:SOUND 5,0
	3.register 1 を 1 にする。
	  SOUND 1,1
	4.register 1 を 0 に戻す。
	  SOUND 1,0


	備考）PSGレジスタ内容
	reg  0  MSB ┓ch.A  ┓
	reg  1  LSB ┛      ┃
	reg  2  MSB ┓ch.B  ┃Pitch Setting
	reg  3  LSB ┛      ┃
	reg  4  MSB ┓ch.C  ┃
	reg  5  LSB ┛      ┛
	reg  6              Noise Setting
	reg  7              Mixer Setting
	reg  8        ch.A  ┓
	reg  9        ch.B  ┃Volume Setting
	reg 10        ch.C  ┛  (0-15, 16:envelope)
	reg 11  Fine Tune   ┓
	reg 12  Coarse Tune ┃Envelope Setting
	reg 13  Shape/Cycle ┛
	reg 14  I/O portA (Joystick1)
	reg 15  I/O portB (Joystick2)


	理論的に "SOUND 1,0:SOUND 0,0" の音は鳴らない(聴こえない)。
	"SOUND 0,8" が約16KHzで上限となる。しかし、ch.A,B が
	"SOUND 1,0:SOUND 0,0:SOUND 3,0:SOUND 2,0" となっている状態で、残りの
	チャンネル(ch.C) で可聴音が発声されると (例："SOUND 4,27:SOUND 5,1")
	それがキッカケとなり、今まで鳴っていなかった ch.A,B がホイッスル音として
	発音されて、その後に ch.C の音を消しても ("SOUND 10,0") ch.A,B の
	ホイッスル音は鳴り続ける。この状態で更に ch.C を最高音量に設定して発音を
	再開すると("SOUND 4,0:SOUND5,0:SOUND 10,15") 最強レベルのホイッスルになる。
	因みに格chの音量バランスを変えると(例："SOUND 8,14"とか…) ホイッスルの
	ピッチが変る。
	普段は最高音程は鳴らない(聴こえない)が、それらが十分な出力を持ち
	(2chで発音)、そこに通常音程の音が加わると、AY8910からスピーカに至る
	回路のどこかで共鳴の様な状態になりホイッスル音に変ると予想される。
	因みに、最高音程でなくとも各チャンネルの音量バランスなどの絡みが
	上手い具合になったときもこの現象が起こったりもする。
	各チャンネルの音量バランスが変ると何故、ホイッスルのピッチが変化するのか
	という部分については謎。


	☆ホイッスルテストプログラム

	10 restore 100
	20 read a,b:if a=-1 then 40
	30 sound a,b:for i=0 to 500:next:goto 20
	40 end
	100 data 0,0,1,0,2,0,3,0,4,0,5,0
	110 data 6,31,7,55,7,56,8,15,9,15,10,15
	120 data 0,27,1,1,0,0,1,0,8,0,-1,-1


■2005.01.04 ver 200 
	・SR-BASICを動かしてテストしていたところ、PAINT命令で境界色をはみ出して
	塗りつぶしに行くことが判明。
	メモリリード部分を見直したところ、io_60H〜io_68H の読み出しメモリブロック
	でなく io_69H〜io_6FH の書き込みバンクを参照してメモリを読んでいた…。
	単純ミス。


	・マイコンBASICマガジンDELUXE・ナムコ ビデオゲームミュージック
	プログラム大全集のMr.PC用リブルラブルを入力していたら、画面演出に
	ROLL命令が使われている。ということで、画面表示スケール調整の関係で
	先延ばししていた画面スクロール機能を実装。
	と言っても、バックグラウンドに組み立てられたエミュのスクリーンを、
	スクロール変数で指定された位置で分割してプライマリーに転送するだけで
	特別な事はやっていないのだけど、
	問題は先送りにして来た表示スケールの切り替えの仕様。

	320x240 のWINDOWサイズでエミュレータを動かしているときに、SR で 640x400 の
	解像度を使ったらどう対処するかという部分で、本来ならWINDOWサイズを拡大して
	640x400 の解像度が収まるようにすべきところだけど、フルスクリーン動作時の
	モード切り替えを避けたい事と(SR-MENUの起動時スクリーンモードが連続で
	切り替わるから)、デバグ用のモニターモードでの表示も考慮しなければならない
	ので、結局、任意のWINDOWサイズに合わせてP6の解像度がWINDOWサイズより大きく
	なった場合、縮小表示されるようにする。


	・SR-BASIC で ROLL命令 を使ってグラフィック画面のスクロールテストを
	させていたら、高さが 200ラインモード なのに io_CCH (スクロール基点Y) に
	203 が入ってくる事が判明。画面表示のバッファには指定分 200ラインの高さしか
	確保していなかったので例外エラー発生ですよ。
	何？SRのライン指定って単なる画面表示のマスクか何かなのか？
	まさかとは思うが…1ドット縦シューでブロック書き換えを見せない為の
	マスク領域を意図してたりして…。
	そういうわけで、SRモードの時はライン設定を見ずに問答無用で204ラインの
	高さを確保するように変更。 画面表示のマスクも特に必要無さそう。

	ああ、でも SCREEN3 の時は 200-203 ラインの範囲もcssの0番の色で
	塗りつぶさないといけないかも。
	SCREEN3 で黒帯が出るのは変なので…。



■2005.01.02 ver 200 
	・ここ数日、ご老体を酷使しすぎたせいか実機mkIIが危篤状態に…(;ﾟДﾟ)
	PSGの波形が妙にピヨっていて昨日からヤバイヤバイと思っていら…＿|￣|○、

パトラッシュ、僕はとっても眠いんだ…
                ξ    
    ヽ    ∧_∧      
    ⊂⌒~つ-ω-)⊃    
~~~~~~~~~~~~~~~~~~~~~~~~

       ⊂⊃
       ∧_∧
      ( -ω-)  さよ〜なら〜
   i⌒| U U
   川 |  |
      U U
      ∫
      :
    ∧_∧
⌒~つ=ω=)⊃
~~~~~~~~~~~~~~~~~

ヴワァアアアアアアアアアアアアアアアアアアアアアアアアアアアアアアアアア！
               .｡::+｡ﾟ:゜ﾟ｡・::｡.               .｡::・｡ﾟ:゜ﾟ｡*::｡. 
         .｡:*:ﾟ:｡:+ﾟ*:ﾟ｡:+｡・::｡ﾟ+:。     ｡:*ﾟ｡::・｡*:｡ﾟ:+ﾟ*:｡:ﾟ:+:｡. 
      .:・ﾟ:｡:*ﾟ:+ﾟ・｡*:ﾟ         ﾟ(ﾉД`)ﾟ           ﾟ:*｡・ﾟ+:ﾟ*:｡:ﾟ・: 
 ｡+゜:*゜:・゜｡:+゜                                      ゜+:｡゜・:゜+:゜*｡ 


■2005.01.01 ver 200 
	・morさんリクエストの初代機モード時のスクリーン外部枠のカラー変化を実装。
	mkII以降の機種は黒背景。初代機でも専用モニタを使うと黒背景で、RF出力の時
	だけ色が付く。実際、どういう色指定でどういう背景色になるかマニュアルに
	書いてあるわけでもないので、昔の雑誌のゲーム広告のスナップショットとか、
	AXシリーズゲームパッケージの裏写真とかを参考に予想実装してみる。

	SCREEN1,2は黒、SCREEN3,4はcssカラーセットの0番パレットで塗りつぶし。

	・上記改変で外枠の色を変えたら、速度やテープなどのステータス表示が黒背景で
	浮いてしまったので、背景カラーによってステータスカラーも変るように修正。 


	・スペースハリアーはJOYSTICKを読みに行くときBGMの音声波形を一瞬切断する事に
	なって、パリパリと破断ノイズが発生する。これは厳密にデジタルな波形を
	出力するエミュだけに現れる現象かと思って、JOYSTICK読み出しでOUT命令が
	来たときはPSG波形更新をしないようにしていたのだけど、実機の波形を録ったら
	思う存分ブッブッ途切れまくってるよ…(^^;;
	実機がそうならエミュでノイズが乗っても問題ないだろうとは思ったのだけど、
	わざわざ耳障りな現象を再現する必要もないので、このままにしておく。

	因みに[STOP]でゲームをポーズしている時はJOYSTICK読み出しが行われないので
	破断ノイズは入らない。


	・[ホイッスル現象再現作業プロセス]
	グランゼルの実機サウンド解析の予測に基づき、先ずはストリーム出力に
	LOW-PASS_RCフィルター実装。フィルターの内容はMAMEのSTREAMと同様、
	2PASS。

	・[ホイッスル現象再現作業プロセス]
	6001のアンプ回路はどうも波形のゼロクロスポイントを自動的に補正する機能が
	付いているようなので(高機能)、それを実装するためにPSGを複数チャンネルから
	単独チャンネルにまとめ、ゼロクロスフィルターを実装。


■2004.12.28 ver 200 
	・OUT(93H) ポートCコントロールが呼び出されたとき、CPUの水平稼働率変更
	呼び出しが行われていなかったので、それを追加。
	ボスコニアンを動かした時、CRTをOFFにしてるのにおしゃべりが遅かった
	ので気が付きました (；ﾟ∀ﾟ)

	・ところが水平稼働率をフルにしたら妙に甲高い声になってしまったので再度調整。
	今度は水平稼働率が半分になるようにしてみると…まだ早いような気がするけど
	何となく実機に近づいてますか？
	(イイカゲンだなぁ)
	今度、実機で録音して調整しよう。


■2004.12.26 ver 200 
	・どうやらPSGとSSGはチップのクロック数が異なることにより音質も異なるようだ。
	mkIIと6601SRではスペハリBGMも違って聞こえるって事なのか。
	そういうわけで、PSGはクロック1.99675 MHz、SSGはFMと同様4.0MHzと設定。
	まぁ、同一チップ内でクロックが異なるなんて事は有り得ないか…。


■2004.12.24 ver 200 
	・FMの音楽をエミュと実機で聴き比べる為にHashiさんから雑誌投稿作品を…
	…ゲフンゲフン…いや、別のお茶を濁すような事でもありませんが…(;ﾟ∀ﾟ)
	貰ったテープイメージをBASICテキストに戻し、MMLを弄ってテストしようと
	思ったのだけど、そういや P6DatRec の復元機能は SR-BASIC に対応していない。
	面倒だけど、先ずはSR-BASICのテープイメージをテキストに展開するアプリを
	作ろうとダイアログを作り始めた時点で、ふと、思い出した。
	そういえば、エミュ上で "LLIST" を実行すれば "printer.txt" にリストが
	出力されるじゃないか…。危うく無駄な時間を費やす所だった。
	(カナやグラフィック記号は化けてしまうけどね。)

	…と、思い出しついでに、プリンタ出力が行われた時は即座に仮想ファイルから
	実ファイルに内容を反映させるように修正。
	いちいちエミュを終了してからじゃないとプリンタ出力結果が取り出せない
	のは余りにも不便だし、DISKやTAPEイメージと違ってプリンタ出力ファイルは
	エミュ動作中にコピーしたり消したり出来るようフリーにしておく
	必要性もないので…。

 
	・エミュ内メニューにFMチャンネルの KEY ON/OFF スイッチを追加。
	PSGは1音1チャンネルだったのだけど、FMの場合3音で1チャンネルに
	なっているので、波形を合成するところでキーが無効になっている
	チャンネルのボリュームを 0 に落とすようにしている。


	・1DDittでイメージ化した6601SRユーティリティーディスクがD88と
	認識されない不具合を調べてみる。
	ヘッダの認識ディスクタイプの所にD88フォーマット規定外の数値が入っている。
	D88 は 2D,2DD,2HD のイメージタイプしか想定しておらず、6601SR の1DDには
	ディスク属性のIDが割り振られていないため、1DDittではそこに1DDのIDを拡張して
	割り振っていたという訳ですな。因みに、mkII外付けドライブの1D形式は
	現状では単密度の2D形式として扱われているので ディスクIDは 00H。

	[D88フォーマットのディスクID]
		2D:00H ,2DD:10H ,2HD:20H ,1DD:40H

	・D88ディスク読込部を1DDフォーマットにも対応。

	・オプションメニューでの新規ディスク作成の際に、1D/1DDの選択ダイアログを追加。


■2004.12.22 ver 200 
	・FM音源が出力されない不具合を調べてみる。
	YM2203ジェネレーターの波形生成の部分を追いかけてみると、FMのチャンネル
	ボリュームが尽く 0 になっている。
	音源の初期化部分をみると音源チップのインターフェースボリュームは
	上位16bitがFM音源用、下位16bitがSSG用になってるのか…。
	となると、オプションにPSGボリュームと別にFM用も用意した方が良いのかな？
	しかしなぁ、任意に音のバランスを変える事もないだろうし、何よりメニューの
	密度が今以上になるのはちょっとマズイ。
	PSGのボリュームを総合的なサウンドボリューム扱いにした方が良いですね。

	と、ボリューム部分は修正したのだが、まだ音が出ない？？
	SSGパートは正常に出力されているのだけど…。


	・念のためストリームレコーディングで出力したWAVを調べてみると、
	一応音は出ていたみたい……耳に聞こえないくらいの微小波形で…(;ﾟ∀ﾟ)
	これってボリューム比がおかしいんだろうなぁ。
	でも、RAINE の DARIUSなんかのYM2203の音源設定項目見ると、
	"YM2203_VOL(120,50)" で FM:SSG =2:1 の比になってるんだよね。
	こっちは "YM2203_VOL(120,50)" にしてあるんだけど何故にアンバランス？
	そこで、試しに  play "v15" してみたら突然大音量に…。
	う〜む、FMのボリュームは極端ですな。
	しかし、待てよ。PSGは3チャンネルが各々別々のストリームバッファを持って
	いるから、最大音量で和音を出して波形が重なったときに音割れしないよう
	分割調整してあるわけだけど、YM2203ジェネレーターは3チャンネルを1つの
	波形に重ねて１つのストリームバッファに出力している。
	という事は、FM:SSG =3:1 のボリュームにするとSSGと同等の音量になるって
	事か…多分。そういうわけでボリューム比を "YM2203_VOL(150,50)" に調整。
	(*´∀｀) お〜、一応音が出てる、出てる。
	FM実装は結構時間を食うかと思っていたけど、意外にアッサリ出来たなぁ。


	・FMの音がちゃんと曲を奏でてくれるのか確認するため、ベーマガ1987年7月号掲載
	Nezukun氏作 の mkIISR/6601SR用 「DARIUS〜宇宙洞窟のテーマ〜」を入力。
	打ち込みと見直しに2時間半…(；´Д｀) ﾊｧﾊｧ
	YM2203の関数実装作業よりも時間を食ってるところがまた…。

	で、早速鳴らしてみたわけだが………何か変だぞ?
	ip6p でも鳴らしてみたけど、やっぱり音が違う Σ(ﾟДﾟ;) ガーン

	さすがにFM音源はそう易々と実装出来やしないか。


	・と言った側から、出力WAVの波形を見て原因がスグに判明。
	FM波形を出すには波形生成のクロックが全然足りてないようで…。
	チップのクロックはAY8910の数値に設定してあるので、YM2203の数値に
	設定しなおさないとダメッスね。

	因みに今現在のAY8910のクロックはPC-6001mkIIマシン語入門(ASCII刊)に
	書いてある数字を参考にして 1996750 にしてあるのだけど、
	実際、RAINEでエミュレートするアーケードマシンのAY8910の設定を見ると、
	フロッガー：  (1789750)  /* 1.78975 MHz */
	アルカノイド：(1500000)   /* 1.5 MHz ???? */
    マットマニア：(1500000)   /* 1.5 MHz?????? */
	となっていて、各々異なる上に疑問符付き。
	現在の 1996750 という値も実は多少の疑問があって…何故なら実機では
	play"o8b" とやると、音の周波数がクロック数を超えてしまうせいか、
	波が飛び飛びの状態で繋がってホイッスルの様な音になるんだよね。
	でも、エミュでそうならないということは、この数値は実機よりも
	クロックが高いという事になる………多分(イイカゲンだなぁ)。
	その内、PSGのホイッスルも再現したいなぁ。
	スペハリのBGMもホイッスルが無いと寂しくて寂しくて…つД`)

	とにかくYM2203のチップクロックは4MHzという事は判っているので、
	ベースクロックを 4000000 に設定。
	これで正常な波形が出るようになった。

	ところが、今度はSSGの音がFMのクロック数になって変質してしまっている。
	これではSR以外のモードで動かした時にも変な音になってしまうな。
	音源ジェネレーターは通常１チップ１クロックなのだけど、こういう場合
	SSGとFMのクロックを別々に動かすほうが良いのかも知れない。
	そういうわけで、SSGとFMのクロックを分離はしてみたのだけど…。

	もしかして、実機でもmkIIで鳴らしたPSGと、SRで鳴らしたSSGは音色が
	異なっているのかな？ もしそうなら 更に PSG,SSG でもクロックを
	分離する必要が出てくる。



■2004.12.21 ver 200 
	・現在のサウンド関数はシングルチップ用のインターフェースになっているので、
	現在のMAME音源ドライバ仕様に合わせてマルチチップ仕様に変更。
	AY8910 と STREAM、全関数の引数を弄る必要があるので、かなりの大規模改造。
	本当はYM2203 １チップは使わないわけだからシングルチップ仕様でも問題ない
	のだけど、MAMEのYM2203関数がマルチチップ仕様なのでこの関数を導入する
	ためには関数のIFを合わせる必要がある。


	・RAINE の YM2203ジェネレーター関数取り込み。
	変数名や関数名で細かいところ修正する必要はあったが、他は殆ど弄らずに
	ソースのリンク完了。
	タイマー割込のIRQハンドラーは、VSYNC や TIMER割り込みと同様 CPU_STATE の
	カウントアップで発生させる方法に置き換え。

	# 気になってRAINEとMAMEのTIMERルーチンを調べてみたのだけど、こちらと同様、
	# Z80のクロックカウントで割り込みを発生させているようだ。
	# てっきり CPUタイマー使って実時間を測っているのかと思ったけど…
	# 考えてみればエミュの仮想システム内時間は全て同期してなきゃ意味がない。

	I/FをAY8910からYM2203のモノに差し替えてポートアクセスをAY8910のままで
	動かしてみると、一応 SSGの音は出ているようなので関数の取り込みは
	上手く行ったようだが…はて？FM音源が出ませんよ？



■2004.12.19 ver 200 
	・TVR割込を呼ばれたとき、GetLocalTime() でPCローカル日付を返すようにする。
	と、その前に返値を予測するためにTVRの返り値を 11H,22H,33H,44H,55H を
	してみたところ、日付は  "01/22/火 33:44:55"  となった。
	22H,33H,44H,55H はBCDで格納された日時分秒という事はこれで判明。

	第一パラメタの 11H だけが異なる扱いになるわけだ。
	見た感じ、上下 4bit のどちらかが月でどちらかが曜日になる事はわかるので、
	今度は第一パラメタに 12H を放り込んでみる。
	結果は、"01/23/水 33:44:55"。
	上位が月のHEX値、下位が曜日を番号に置き換えたものって事ですな。

	普通、"0-1-2-3-4-5-6" で "日-月-火-水-木-金-土" が割り振られる
	ものかと思いきや、SRの場合、"月-火-水-木-金-土-日" の順になるみたい。
	因みに "GetLocalTime(SYSTEMTIME *st)" で取得される曜日情報
	"st.wDayOfWeek" は、"日-月-火…" の並びなので、番号を加工する必要あり。

	しかし、何度かカーソルを動かしていると不意に固まる時がある。
	特にボチボチっと連続でキークリック音が出ると、確実に固まる。
	もしかして、DATE割り込みでデータを取ってる最中に、キーボード割り込みが
	発生したりしてるのか？


	・キーボードを操作しているとTVヨヤク処理が固まる原因を調査。
	通常にキーボードを受け付けているときのI/Oアクセスログ。

0e9a:IN (92H) ->eeH
0ea2:OUT (93H),09
0ea5:OUT (90H),32
@@@@@@ KEY3 RESERVED @@@@@              <<<<< キーが押されて 8049にベクタ発生依頼。
-=-=-=-=-=-=-=-=-=-=INTR (02H) !!! KEY3 <<<<キーボードベクタ発生
0e7a:OUT (93H),0c
0e7c:IN (92H) ->9eH
0e82:IN (92H) ->9eH
0e7c:IN (92H) ->9eH
0e82:IN (92H) ->beH
0e8a:OUT (93H),0d
0e8c:IN (90H) ->c6H     <<<<< キーコード・カマ〜ン( ･∀･)
1bbe:OUT (a0H),07
1bc1:IN (a2H) ->38H
1bc5:OUT (a0H),07
1bc9:OUT (a1H),37
1bbe:OUT (a0H),08
1bc1:IN (a2H) ->00H
1bc5:OUT (a0H),08
1bc9:OUT (a1H),0f
1bc5:OUT (a0H),07
1bc9:OUT (a1H),38
1bc5:OUT (a0H),08
1bc9:OUT (a1H),00
-=-=-=-=-=-=-=-=-=-=INTR (06H) !!! TIMER <<<< タイマー割込発生
-=-=-=-=-=-=-=-=-=-=INTR (1aH) !!! DATE  <<<< DATE割込発生
0e7a:OUT (93H),0c
fea1:OUT (f0H),dd

	↓キーを受け付けない状態のログ。

0e9a:IN (92H) ->eeH
0ea2:OUT (93H),09
0ea5:OUT (90H),32
-=-=-=-=-=-=-=-=-=-=INTR (1aH) !!! DATE  <<<<< DATE割込発生
0e7a:OUT (93H),0c
0e7c:IN (92H)@@@@@@ KEY3 RESERVED @@@@@  <<<<< 8049 キー割込予約
0e7a:OUT (93H),0c
0e7c:IN (92H) ->8eH
0e82:IN (92H) ->8eH
0e7c:IN (92H) ->8eH
0e82:IN (92H) ->8eH
0e7c:IN (92H) ->8eH
0e82:IN (92H) ->aeH
0e8a:OUT (93H),0d
0e8c:IN (90H) ->02H  <<<< キーボードベクタ読出
b7c5:OUT (f0H),dd

(…略…)

0e9a:IN (92H) ->eeH
0ea2:OUT (93H),09
0ea5:OUT (90H),32
-=-=-=-=-=-=-=-=-=-=INTR (1aH) !!! DATE  <<<<< 再び DATE割込発生
0e7a:OUT (93H),0c
0e7c:IN (92H) ->9eH

	という事で、予想通り、DATE割込のデータ出力の最中にキーボードベクタが
	割り込んできてDATEコードを押しのけて、自分のデータを吐いてしまってる。

	コリャ、SUB-CPUの処理の問題ですな。という事はどうしよう？
	一連のDATER割込処理のルーチンを読むと、DI の状態で日時5バイトデータが
	出力されているけど、もし途中で EI になったらどうなるんだろうとか…。
	データ出力を中断してリセットしちゃって良いのかな？
	それとも、EI 状態でも IO(090H) をやると平然と続きのデータを返し続ける？
	EIになった時の他の予約ベクタ発行を考えるとリセットするのが妥当のような
	気もするけど、EIになっても他の割り込みが発生しない場合そのままデータを
	返し続けても全然問題は起こらないハズだし…。
	よし、TVRとDATE割込は、他の割込と処理を分けて優先的に処理しておこう。
	他の割り込みはTVR,DATEのデータを返し終わるまで全て待機。
	問題が起きたら修正しよう。




■2004.12.18 ver 200 
	・忘れないうちに、引き続きTV予約システムがマトモに動かない原因を追跡。
	以下、I/OポートアクセスのLOG。

0ea2:OUT (93H),09
0ea5:OUT (90H),32 <<<<< DATE割込を促す
-=-=-=-=-=-=-=-=-=-=INTR (1aH) !!! DATE
0e7a:OUT (93H),0c
0e7c:IN (92H) ->beH
0e82:IN (92H) ->beH
0e8a:OUT (93H),0d
0e8c:IN (90H) ->00H <<<<
0e7a:OUT (93H),0c
0e7c:IN (92H) ->aeH
0e82:IN (92H) ->aeH
0e8a:OUT (93H),0d
0e8c:IN (90H) ->00H <<<<
0e7a:OUT (93H),0c
0e7c:IN (92H) ->aeH
0e82:IN (92H) ->aeH
0e8a:OUT (93H),0d
0e8c:IN (90H) ->00H <<<<
0e7a:OUT (93H),0c
0e7c:IN (92H) ->aeH
0e82:IN (92H) ->aeH
0e8a:OUT (93H),0d
0e8c:IN (90H) ->00H <<<<
0e7a:OUT (93H),0c
0e7c:IN (92H) ->aeH
0e82:IN (92H) ->aeH
0e8a:OUT (93H),0d
0e8c:IN (90H) ->00H <<<<
-=-=-=-=-=-=-=-=-=-=INTR (06H) !!! TIMER
-=-=-=-=-=-=-=-=-=-=INTR (1aH) !!! DATE
0e7a:OUT (93H),0c

	DATE割り込みが発生して…5回 IN(90H) を行って…その後、またDATE割り込みが
	出てしまっている。割込みフラグが落ちてないないようなので修正。
	Try Again !

0e94:IN (92H) ->eeH
0e9A:IN (92H) ->eeH
0ea2:OUT (93H) ->09
0ea5:OUT (90H) ->31 <<<<< TVR割込を促す
-=-=-=-=-=-=-=-=-=-=INTR (06H) !!! TIMER
-=-=-=-=-=-=-=-=-=-=INTR (06H) !!! TIMER
-=-=-=-=-=-=-=-=-=-=INTR (06H) !!! TIMER
(以下、延々…INTR (06H) のみ発生)

	今度はTVR割込が発生しない………って、セットする割込みフラグ間違えてた。
	さて、今度はどうだ…。

0ea2:OUT (93H),09
0ea5:OUT (90H),31
-=-=-=-=-=-=-=-=-=-=INTR (18H) !!! TVR
0e7a:OUT (93H),0c
0e7c:IN (92H) ->beH
0e82:IN (92H) ->beH
0e8a:OUT (93H),0d
0e8c:IN (90H) ->00H <<<<
0e7a:OUT (93H),0c
0e7c:IN (92H) ->aeH
0e82:IN (92H) ->aeH
0e8a:OUT (93H),0d
0e8c:IN (90H) ->00H <<<<
0e7a:OUT (93H),0c
0e7c:IN (92H) ->aeH
0e82:IN (92H) ->aeH
0e8a:OUT (93H),0d
0e8c:IN (90H) ->00H <<<<
0e7a:OUT (93H),0c
0e7c:IN (92H) ->aeH
0e82:IN (92H) ->aeH
(以下、延々同じアドレス範囲をループ)

	今度は何！？
	ループに突入したところを捕まえて該当箇所を見ると…。

      LD   (0D0E4H),A ;B629 32 E4 D0
      LD   A,031H     ;B62C 3E 31
      DI              ;B62E F3
      CALL Z0079      ;B62F CD 8F 0E <<<< TVR割込を促す
      EI              ;B632 FB
                              ---===<<<< ここでTVR割込発生
Z0083:LD   A,(0D0E4H) ;B633 3A E4 D0  <<<< (0D0E4H) はTVR割込内の IN(090H) 返値
      INC  A          ;B636 3C
      JR   NZ,Z0083   ;B637 20 FA     <<<< 0FFH 判定
      LD   A,(0D0E5H) ;B639 3A E5 D0
      LD   HL,0D0E6H  ;B63C 21 E6 D0

	IN(090H) で 0FFH が帰ってくるまで無限ループとなっている。
	現在は仮値として常に 00H を返しているけど、本来のTVR割込はデータを
	返し終わった後、終端の合図として 0FFH を返さないとダメらしい。 

	結果として表は出るようになったけど、年月日も時間も全て 00H で返している
	せいか、途中で操作できなくなるし…＿|￣|○ 
	日付返却部分も作らないとダメそう。 
	意外とてこずりますな。

■2004.12.17 ver 200 
	・TV予約システムが起動しない原因を追いかけてみる。
	とりあえず、暴走するまでデバッガで追跡。
	下の該当箇所、ROMのバンク切り替えの後、0000H にジャンプした後
	滅茶苦茶な動作…。

DI              ;7821   F3
LD  A,012H      ;7822   3E 12
OUT (0F0H),A    ;7824   D3 F0
LD  A,0FCH      ;7826   3E FC
OUT (0C2H),A    ;7828   D3 C2
JP  00H         ;782A   C3 00 00

	アドレス 7824H で OUT (0F0H),12H  が行われた場合、

	0000H-1FFFH:VOICE_ROM_1
	2000H-3FFFH:VOICE_ROM_2
	4000H-5FFFH:BASIC_ROM_3
	6000H-7FFFH:BASIC_ROM_4

	になるのだけど…あれ？VOICE_ROM って メモリマップのページ3,4(4000H-7FFF)
	用のプログラムだよな？…考えてみたら VOICE じゃなくて TV予約のROMが
	入らないとオカシイ。
	そうか、SRの場合 メモリマップの PAGE-1(0000H-1FFFH), PAGE-2(2000H-3FFFH)
	に VOICE_ROM のスイッチが設定されたら、TV予約システムのROMがマッピング
	されるのか(*ﾟ∀ﾟ)！ 気付かなかった…というか、資料が無かった。

	TV予約は何処かいなとROMファイルを探すと…あった。
	SYSROM2 の 2A70H 辺りから、"TVヨヤク" という文字列発見。
	SYSROM2 を頭からマッピングして解決。
	でも、キーが効かない。続きは後日。
	モニタモードの方のROMバンク表示のところも修正しておかないと…。


■2004.12.14 ver 200 
	・ディスクドライブが認識されない原因を追いかけてみる。
	I/Oポート全てにアクセス履歴のデバッグ出力とFDC処理関数にブレークポイントを
	仕掛けて実行してみるのだが、一箇所だけポートアクセスのデバッグ文字列が出力
	されるのに、ブレークポイントに引っ掛からない箇所がある。
	該当アドレス箇所の逆アセンブラリストは↓コレ。

LD  A,0F3H       ;702B    3E F3
OUT (0B1H),A     ;702D    D3 B1
LD  B,00H        ;702F    06 00
LD  C,0D0H       ;7031    0E D0
LD  DE,055AAH    ;7033    11 AA 55
OUT (C),D        ;7036    ED 51
INC B            ;7038    04
OUT (C),E        ;7039    ED 59
IN  A,(C)        ;703B    ED 78
CP  E            ;703D    BB
JR  NZ,07048H    ;703E    20 08

	OUT (0D0H) で、0AAH,055H を続けて出力し、IN (0D0H) で先ほど出力した値が
	取り出せたらディスクが存在すると解釈してるらしいが…
	あれ？ IN (0D0H) でデバッガに引っ掛かりませんよ。

	しまった…Mr.PC は FDC処理に飛ばさなきゃならないのに、
	外付けFDD処理受付の所で 66モデル しか弾いてなくて、
	68モデルはその場で処理されていた…。

case 0xd0:
    // FDD制御用
    if( get_p6model()==66) break;  //66の処理は↓で
    io_D0H = fd_in();
    return io_D0H;

×：if( get_p6model()==66) break;  //66の処理は↓で
○：if(get_p6model()==66||get_p6model()==68) break;  //66,68の処理は↓で

	フロッピーコントロール io_B1H,io_B2H の実装不具合かと思っていたのだけど、
	単なるケアレスミスだった…。


■2004.12.11 ver 200 
	・B0H システムコントロールのインターバルスイッチをVRCT割り込みにも適応。
	mkII の場合、インターバルスイッチはタイマー割り込みの有無だけだった。
	・SR時、B0H システムコントロールの初期値を 0xff に修正。
	因みに mkII の時は 0xf3 。
	・SR動作時の水平同期CPU稼動率はio_C8HポートのBUS_REQフラグによって
	変るようなので(Moriyaさん情報)、CPU駆動率設定をそのように修正。
	今まではio_C8HポートのSR_BASIC_MODEフラグを見て変化させていたので…。
	・mkIIモードとSRモード時の割り込み発生ルーチンを分離。
	SRモード時、割り込み優先順位をつけて、io_FAH の割り込み
	コントロールフラグを適応させる。
┏━━━━━━┓┏━━━━━━━━━━┓
┃  優先順位  ┃┃  io_FAH ポート     ┃
┣━━━━━━┫┣━━┳━━━━━━━┫
┃ 1.Timer    ┃┃bit ┃割り込みマスク┃
┃ 2.sub_CPU  ┃┣━━╋━━━━━━━┫
┃ 3.Voice    ┃┃ 0  ┃  sub CPU     ┃
┃ 4.VRTC     ┃┃ 1  ┃  JoyStick    ┃
┃ 5.RS-232C  ┃┃ 2  ┃  Timer       ┃
┃ 6.JoyStick ┃┃ 3  ┃  Voice       ┃
┃ 7.EXT_INT  ┃┃ 4  ┃  VRTC        ┃
┃ 8.Printer  ┃┃ 5  ┃  RS-232C     ┃
┗━━━━━━┛┃ 6  ┃  Printer     ┃
                ┃ 7  ┃  EXT_INT     ┃
                ┗━━┻━━━━━━━┛
	mkII では io_F3H の下位ビットが割り込みマスクになっていたけど、
	SR では 上位ビット(bit5-7) が Waitコントロールに割り当てられ、
	下位ビット(bit0-4)は全て 0 になっている。
	という事は、SRモードで動いているときは io_F3H の割り込みマスク
	は無視しちゃって良いということなのだろうか？
	さすがにSR機種の判別でキックしてしまうと、旧BASICモードで動かした
	時にmkII以前のソフトが動かなくなってしまうだろうし…。

	とりあえず現状では、旧モードの時は↓の判定で
	if(!(io_F3H&0x04) && !(io_B0H&0x01)&& TIMER_flag ){
		//タイマー割り込み発生
	}

	SRモード動作時は↓こうしてみる。
	if(!(io_F3H&0x04) && !(io_B0H&0x01)&& !(io_FAH&0x04)&& TIMER_flag ){
		//タイマー割り込み発生
	}

	ってか、sub_CPU 割り込みって何？
	多分、CMT や Keyboard など、まとめて SUB_CPU という扱いになっていると
	予想は出来るけど、でも Joystick 割り込みが別扱いになっているのが不思議だ。
	6001やmkIIだとJoyStick割り込みは SUB_CPU から発生していたのだけど ？
	(Door2 は IN (90H) でJoyStick割り込み(016H) を取り込んでいるし…)
	もしかして SR だと YM-2203 から出てるのか？？
	だから、Door2 はmkII用とSR用、別々に出ていたと…？？？？
	という事で、SR機種の時は JoyStick割り込みを要求されたときSUB_CPU に
	ベクタ予約するのを止めて、その場で割り込みを発生させてしまうように修正。

	Voice割り込みも良くわからない。
	シンギングでFM音源と同期を取るためのモノかな？
	声の再生が終わったら割り込みが出てくるとか…。

	DATE割り込みやテレビ割り込みは EXT_INT に含めてしまって良いのだろうか？

	う〜む、疑問符だらけだ…。


	・(；´Д｀)あううあああう。
	上の通り、subCPU と JoyStick のマスクをストレートに実装したら、
	SRメニューが起動しなくなってしまった…orz

	何でもかんでも SUB_CPU割り込みマスクに含めてしまったのが不味かった？
	CMR_READ,CMT_ERROR,KEY1,KEY2,KEY3 全部まとめちゃったんですけど…。
	キーボード割り込みはSUB_CPUに含まれないのかな？

	つーか、SRメニュー、io_FAH のマスクでJoyStick割り込みをOFFにしてる
	クセに、それから発生を促してくるのは何でやねん！？

	  OUT (0FAH),F2H で JOYSTICK を不許可にする。
	→OUT (90H),06H  でJOYSTICK割り込み発生を促す。
	→待機の無限ループ。Σ(ﾟДﾟ；)

	io_FAH のマスクを否定する流れだな。
	io_FAH のJoyStickマスクって通常の(16H)ベクタと意味が違うのか？
	JoyStick のボタンが押されたら時に Keyboard割り込みみたいに突発的に
	発生するベクタが有るとか…。

	タイマー割り込みも発生しなくなったぞ。
	SR-BASIC起動中は io_FAH が 0EFH になっているし…(VRTCしか有効でない)
	…って事は根本的にこのio_FAHポートの役割を勘違いしている事になる。
	とりあえず、io_FAH のマスクは全部外しておくか。
	io_FAH と io_FBH って一体何を意味しているのだろう。懸案事項だ。


■2004.12.03 ver 200 
	・SR用に組み込むFM音源ジェネレータを選択。
	P6VのPSGにはMAME系列のAY8910が使われているから、
	プログラムの親和性を考えるとYM2203にもMAME系のSOUNDエンジンを持ってくるのが
	一番なのでMAME最新版のソースを見たいのだが、ネット接続障害のせいでソース
	アーカイブのダウンロードもままならず。
	MAMEのZIPソースは10MBくらいあるからなぁ…。
	同系で言えばRAINEの方はどうだろうと見に行くとコッチは tar.bz2 で 1.4MB。
	数回の失敗の後、無事ダウンロード完了。

	2203INTF.C と FM.C を取り込めばいいのか。
	AY8910のソースも新しいのと入れ替えないといけないか。
	調整に時間が掛かりそう。


■2004.11.30 ver 200 
	・しまった…昨日のパレットとカラーの対応ってマニュアルのVRAM資料の
	アトリビュー数値そのままかと思い込んでいたら、全然ちゃうやんけ(汗。
┏━━━━┳━━━━━━━━━┓
┃パレット┃SCREEN 1カラー番号┃
┃  番号  ┃                  ┃
┣━━━━╋━━━━━━━━━┫
┃  01    ┃01：透明    [49]  ┃
┃  02    ┃02：青紫    [53]  ┃
┃  03    ┃03：橙      [50]  ┃
┃  04    ┃04：赤紫    [54]  ┃
┃  05    ┃05：青緑    [51]  ┃
┃  06    ┃06：空色    [55]  ┃
┃  07    ┃07：黄緑    [52]  ┃
┃  08    ┃08：灰色    [56]  ┃
┃  09    ┃09：黒      [57]  ┃
┃  10    ┃10：青      [61]  ┃
┃  11    ┃11：赤      [58]  ┃
┃  12    ┃12：マゼンタ[62]  ┃
┃  13    ┃13：緑      [59]  ┃
┃  14    ┃14：シアン  [63]  ┃
┃  15    ┃15：黄      [60]  ┃
┃  16    ┃16：白      [64]  ┃
┗━━━━┻━━━━━━━━━┛
	BASICマニュアルからSCREEN1のテキストカラーはこの順番になっていて、
	どこかのビットを入れ替えたらアトリビューの色並びになるのかと
	思ってざっと並べてみると…
┏━━━┳━━━━━━━━━━━━━━━┓
┃カラー┃    アトリビュー値            ┃
┃  番号┃              HBGR   → HGRB  ┃
┣━━━╋━━━━━━━━━━━━━━━┫
┃ 00H  ┃透明    ：00H (0000B)→(0000B)┃
┃ 01H  ┃青紫    ：04H (0100B)→(0001B)┃
┃ 02H  ┃橙      ：01H (0001B)→(0010B)┃
┃ 03H  ┃赤紫    ：05H (0101B)→(0011B)┃
┃ 04H  ┃青緑    ：02H (0010B)→(0100B)┃
┃ 05H  ┃空色    ：06H (0110B)→(0101B)┃
┃ 06H  ┃黄緑    ：03H (0011B)→(0110B)┃
┃ 07H  ┃灰色    ：07H (0111B)→(0111B)┃
┃ 08H  ┃黒      ：08H (1000B)→(1000B)┃
┃ 09H  ┃青      ：0CH (1100B)→(1001B)┃
┃ 0AH  ┃赤      ：09H (1001B)→(1010B)┃
┃ 0BH  ┃マゼンタ：0DH (1101B)→(1011B)┃
┃ 0CH  ┃緑      ：0AH (1010B)→(1100B)┃
┃ 0DH  ┃シアン  ：0EH (1110B)→(1101B)┃
┃ 0EH  ┃黄      ：0BH (1011B)→(1110B)┃
┃ 0FH  ┃白      ：0FH (1111B)→(1111B)┃
┗━━━┻━━━━━━━━━━━━━━━┛
	H-B-G-R の上位H だけそのままで下の B-G-R のビット並びを G-B-R にすると
	規則的な並びになる。謎は全て解けた。
	HGRB→HBGR に変換してからアトリビュー並びのテーブル参照すれば良い。
	カラー番号からアトリビュー番号への変換はこれでオッケ。

	color_no = (col&0x08)+((col&1)<<2)+((col&0xc)>>1);
	palet_no = (pal&0x08)+((pal&1)<<2)+((pal&0xc)>>1);
	COLOR[palet_no] = color_no;


■2004.11.29 ver 200 
	・IO_40H〜IO_44H のパレット指定を修正。
	IO_40H〜IO_44H は PAL16〜PAL13 対応、入力パレット番号は 0〜15 で
	COL16〜COL0、ビットが反転した状態で指定するとの事。(Windyさん情報)

	例えば、SR-SCREEN1のカラー番号とP6VW内のパレット番号の対応は
	↓こうなっているわけだから…
┏━━━━┳━━━━━━━━━┓
┃パレット┃SCREEN 1カラー番号┃
┃  番号  ┃   H-B-G-R(文字)  ┃
┃        ┃  css2-B-G-R(背景)┃
┣━━━━╋━━━━━━━━━┫
┃  01    ┃01：透明    [49]  ┃
┃  02    ┃02：橙      [50]  ┃
┃  03    ┃03：青緑    [51]  ┃
┃  04    ┃04：黄緑    [52]  ┃
┃  05    ┃05：青紫    [53]  ┃
┃  06    ┃06：赤紫    [54]  ┃
┃  07    ┃07：空色    [55]  ┃
┃  08    ┃08：灰色    [56]  ┃
┃  09    ┃09：黒      [57]  ┃
┃  10    ┃10：赤      [58]  ┃
┃  11    ┃11：緑      [59]  ┃
┃  12    ┃12：黄      [60]  ┃
┃  13    ┃13：青      [61]  ┃
┃  14    ┃14：マゼンタ[62]  ┃
┃  15    ┃15：シアン  [63]  ┃
┃  16    ┃16：白      [64]  ┃
┗━━━━┻━━━━━━━━━┛
	OUT  &H40,&H03  のコマンドが来た場合、
	カラー番号((15-(0x40 & 0x0F))+1) のパレット番号を ((15-0x03)+1) と
	入れ替える。
	この場合は  COLOR[16] =14  が実行されて、"COLOR 16" が白からマゼンタに
	変ると解釈していたのだが、実機はというと…シアン！？Σ(ﾟДﾟ；)
	あれ？何かおかしい。

■2004.11.28 ver 200 
	・機会があったので他のP6エミュ作者の方々にSRの描画とタイマーに
	ついて質問。そこで判明した事。

	■ SRはタイマーのカウント方法が違う。
	  mkII までは IO_F6H の値が 3 で 1/512 の割り込みが出ていたが、
	  SRではタイマー速度を調整できるようにする為か、IO_F6H が 127 の時に
	  1/512 の割り込みが出るようになっている。
	■ SRはDMAで画面表示が行われるので水平表示期間もCPUが稼動可能らしい。

	以上、２点を踏まえてタイマーカウンタの値を調整。
	なるほど、クロック周波数が SR で3.58MHz、mkII 3.9936MHz と、
	mkII の方が速いにも関わらず、実行速度はSRの方が速かったのは
	そのせいだったのね ( ﾟ∀ﾟ)ノ
	でも水平周期を丸々CPUに割り当てたら相当スピードが速くなってしまった。
	普通にmkIIモードで動かすと、プログラムとタイマー割り込みの同期が
	外れてしまう…（スターフリート等）。
	ゲームでもmkII用があるのにわざわざSR用が出ていたのもこのせい？

■2004.11.27 ver 200 
	・テープが読み込めない原因は、SRは垂直同期のたびにB0ラッチを叩きに
	来るのでテープモータ開始スイッチが連射された状態になっていたから。
	テープリードの状態フラグが変化しない時は、テープモータスイッチが
	動かないように修正。

	・先の修正で不具合発生。テープ読み込み中にSTOPでとめると、次にCLOADを
	行っても二度とテープリードが始まらなくなる。理由はSTOP割り込みで強制的に
	テープが止められてもB0Hのフラグがそのままだから。というわけでSTOP割り込み
	でテープが止まったときもB0Hのテープモータフラグを落すように修正。

	・640x480用にScanLineルーチンを改正。

	・タイマー割り込みが変過ぎる？ので ip6plus のソースを参照してみる。
	リセット時、ポート値を初期化せずに内部のフラグだけON/OFFしている。
	VRTC割り込みのフラグも初期化してないみたい。
	という事はエミュレータシステム起動時、SR機種以外の時も問答無用で
	VRTCが発生しているのかな？

■2004.11.26 ver 200 
	・機種選択をチェックボタンをプッシュ形式にする。
	選択肢の数が多い時はこっちの方がパッと見、分かりやすいと思うので。

	・MONITORモードのパラメタ表示をSR用に大改造。
	拡張RAMファイルからの読み書き命令はいずれ拡張RAM用のモノを
	実装する必要あり。

	・(；´Д｀)あううあああう。
	CRTを切り替えながらVRAMの読み書きテストをやっていたら、
	特定のオフセットでZ80実行コードの読み込みがVRAMに切り替えられて
	途中暴走することが判明。何か他にIOポートスイッチでも見る必要が
	あるのかと思って、ip6plus のソースを参照。
	プログラムバンクのセグメント指定0の時しかVRAMアクセスさせない
	ようになっているのだが…。ん？そうか、なるほど。
	BASICROM.68,VOICEROM.68といったバラROMのセグメント
	を 0x8000 以降にズラしてしまって、セグメント0x0000 でプログラムが
	走る事が無いようにSYSTEMROM に固めたということなのか。 
	The SR ショック。
	仮に MAIN_RAM の 0x0000 と、VRAMに割り当てられる位置にプログラムを
	置いたとしても、それがVRAMアクセスで読み出される時は、どうせ
	0x0000〜0x7fff まで PAGE2のグラフィック画面に割り当てられるわけ
	だから、プログラムアクセスとVRAMアクセスのバッティングは
	起こらなくなるわけですな。
	でも、グラフィック画面の右側パート(0x0000-19ff)がクチャクチャでも
	良いから、グラフィック画面の左側だけを使って、MAIN_RAM の0x0000
	からプログラムを配置して動かしたいなどというヒネクレタ事を考えると、
	この暗黙の了解も破綻してしまうけど…(；´∀｀)アリエナイ？
	雑誌のSR仕様説明記事は説明が足りないなぁ。ま部分的コピーしか
	もらって無いから何とも言えないんだけど…。

	・VRAMの書き込みは正常に出来るようになったけど、読み出しはまだ変。

■2004.11.25 ver 200 
	・旧態のROMイメージでは ip6plus と互換性が取れないので、
	BASICROM.68,CGROM60.68,CGROM66.68,KANJIROM.68,VOICEROM.68,SYSROM2.68
	を結合して、"SYSTEMROM1.68"."SYSTEMROM2.68","CGROM68.68" にまとめて、
	メモリ管理ポインタもSR用に別に用意。既存の 6601メモリブロックには
	ここからデータをコピーしておいて、6601モードのポインタ指定のまま
	動作するようにしておく。確保メモリは２倍食うけど、微々たるモノ。

	・(；´Д｀)あううあああう。
	ROMのマッピングを変えたから、Z80実行コードとVRAMアクセス部分が
	正常に動かなくなってしまった…。
	結局、Z80実行用と通常メモリアクセスの関数の分離を取りやめて、
	同じ mem_read内部のIO_6XHバンク参照でどうにかコジつけてみるが…。
	こんなんで大丈夫かい？

	・SR-BASICに入ってすぐにスクリーンをグラフィックモードに切り替えると、
	SR-MENUの画面表示で使われたデータの残骸が表示されるのだけど、
	これはコレで良いのだろうか？

■2004.08.11 ver 200 
	・SR用のCPU_STATE計算を入れる。そうしたらカーソルの点滅が激烈に
	遅くなってしまいました＿|￣|○。タイマー割込み値が変って事か…。
	計算式が不明なので放っておく(またか)。

■2004.08.04 ver 200 
	・画面解像度を640x480に固定してしまったのだが、Pen2-300 だと
	処理落ちして "100%" ですら動作しない ＿|￣|○ ｶﾞｸｯ
	SRの仕様に無理に合わせて、6001やmkIIモードでも遅くなってしまうのは
	問題なのだけど、かといってノーマルモードやSRモード切り替えのたびに
	バチバチ解像度を切り替えるのはフルスクリーンで動かす事を前提に
	考えると無理があるので、SR以外の機種の解像度だけ  x1,x2  から
	選べるようにしておけば良いかな？
	という事で、そのように改造。
	……暫く改造に間があいたから、またVRAMの仕組みを忘れていた…orz

	・パレットは未だ意味不明。
	PORT 40H〜44Hって、パレット13〜16 に対応してるわけではない？？
	どうも6601の初期メニューの配色が違うのです。
	とりあえず実害は無いので放っておく。

	・割り込みで詰まる。垂直同期の発生間隔って１水平処理ステートの
	262ラインで良いのかな？ 
	SR-BASICの場合、画面解像度がBASIC内で切り替えられても実際に
	表示解像度が切り替わるのはVRTC割込みが出た時になってしまうので、
	VSYNC と VRTC のタイミングが異なっていると、↓の様になってしまう。
	-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
	  SR-BASICからSCREEN3,2実行
	→ページが切り替わる
	→VSYNC発生：[320x200の解像度のままPAGE2が表示される]
	→VRTC発生：[解像度が604x400に切り替わる]
	→VSYNC発生：[640x200の解像度でPAGE2が表示される]
	-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
	要するに一瞬だけチラッと異なる解像度が表示されるわけで…
	これがVSYNCとVRTCの発生タイミングがズレればズレるほど、
	この「チラッ」の間が長くなってしまう。
	よくわからないので、現状では VSYNCと発生タイミングを同じにして、
	VSYNCの発生直前にVRTCを出すように調整してみる。

	・DATE  読み書きの仕様が良く分からないのだが、どうも一度発生を
	促すと５連発で割り込みが発生するので、その分カウントアップして
	５回目に割込みフラグを落すようにしておく。

	・テレビコントロールも同様。
	TVを自動点灯させるために予約日時を取り込んでいると考えられるので
	日付と同じ仕組みにしておく。
	でも、こんな適当な対応で良いのかな？

■2004.07.21 ver 200 
	・SRモードで動いているときのmkII CRTモード(IO_C1H)が良く解らないので、
	BASICROM.68 を逆アセンブラしてみるのだが…mkII用のCGROM切り替えは
	bit0で 6001用とmkII用を指定していたわけだけど…SRの時は純粋にCGROM66の
	頭を指定しておけば良いみたい。ただし各種フラグはSR用の画面解像度選択で
	使用されるのでそのまま変化させておく。mkIIでは常に１だったIO_C1Hの
	bit0も今回はSR用グラフィック表示高さのパラメタになるのでコレも変数に。
	関連して再設定が掛かるB0ラッチのVRAMアドレス切り替えは無効にすると…。

	○mkII用CRTモード IO_C1H:
		c1bit0   = (data)&1;
		n60_win  = (data>>1)&1;
		mk2_char = (data>>2)&1;
		mk2_grap = (data>>3)&1;
	○SR用CRTモード IO_C8H:
		not_SR_MODE = (data)&1;
		not_BUS_REQ = (data>>1)&1;
		CONSOLE     = (data>>2)&1;
		not_BITMAP  = (data>>3)&1;
		SR_VRAM     = (data>>4)&1;

	これらを組み合わせると

[not_SR-MODE==0] SRモードが前提。
if(c1bit0==0) SRHEIGHT=204; else SRHEIGHT=200;
if(CONSOLE==0) CONSOLE_HEIGHT=25; else CONSOLE_HEIGHT=20;
if(VRAM_ADDR==0) vram_addr=0x0000; else vram_addr=0x8000;

グラフィックモード
+==========+=======+========+========+======================
|not_BITMAP|SR_VRAM|mk2_char|mk2_grap|
+==========+=======+========+========+======================
|    0     |   0   |    0   |   0    | WIDTH:640,VRAM:0x0000
+----------+-------+--------+--------+----------------------
|    0     |   0   |    0   |   1    | WIDTH:320,VRAM:0x0000
+----------+-------+--------+--------+----------------------
|    0     |   1   |    0   |   0    | WIDTH:640,VRAM:0x8000
+----------+-------+--------+--------+----------------------
|    0     |   1   |    0   |   1    | WIDTH:320,VRAM:0x8000
+----------+-------+--------+--------+----------------------

テキストモード
+==========+=======+========+======================
|not_BITMAP|n60_win|mk2_char|
+==========+=======+========+======================
|    1     |   0   |    0   | CONSOLE_WIDTH:40
+----------+-------+--------+----------------------
|    1     |   0   |    1   | CONSOLE_WIDTH:80
+----------+-------+--------+----------------------
|    1     |   1   |    0   | CONSOLE_WIDTH:40
+----------+-------+--------+----------------------
|    1     |   1   |    1   | CONSOLE_WIDTH:40
+----------+-------+--------+----------------------

	画面描画のところで IO_C1H と IO_C8H のビットフラグを一々チェックするのも
	面倒だから、graphic_width ,graphic_height ,console_width ,console_height
	などの変数に直接数値を納めておいた方が合理的。

	・VRAMの表示仕様がマニュアルだと良く分からない。
	以前作ったP6CGコンバーターのソースを見てそのまま反映させようと思ったら、
	MOがぶっ壊れていてソースが入ったディスクを読み出せない…＿|￣|○
	そこで ip6plus のソースを参照してドット配置の仕方だけ見てみる。
	…徐々に思い出してきた。そうだ ”WORD単位”で偶数ライン・奇数ラインが
	互い違いに並んでいるんだった。ホント、面倒な仕様だよなぁ。

メモ）SR-VRAMのドット並び SCREEN2(320x200)
	(0,0)-(255,203)のブロックが   MAIN_RAM:0x1a00-0x7fff にマッピング
	(256,0)-(319,204)のブロックが MAIN_RAM:0x0000-0x19ff にマッピング
	・メモリとドットの対応
      ０        １        ２        ４            ５        ６    …２５５
  ┏━━━━┳━━━━┳━━━━┳━━━━┓┏━━━━┳━━━
０┃1A00: H ： L      ┃1A01: H ： L      ┃┃1A04: H ： L      
  ┣━━━━╋━━━━╋━━━━╋━━━━┫┣━━━━╋━━━
１┃1A02: H ： L      ┃1A03: H ： L      ┃┃1A06: H ： L     
  ┗━━━━┻━━━━┻━━━━┻━━━━┛┗━━━━┻━━━
  ┏━━━━┳━━━━┳━━━━┳━━━━┓┏━━━━┳━━━
２┃1B00: H ： L      ┃1B01: H ： L      ┃┃1B04: H ： L      
  ┣━━━━╋━━━━╋━━━━╋━━━━┫┣━━━━╋━━━
３┃1B02: H ： L      ┃1B03: H ： L      ┃┃1B06: H ： L     
  ┗━━━━┻━━━━┻━━━━┻━━━━┛┗━━━━┻━━━

  上の様に 4バイト(4x2=8dot)ブロック単位に扱うようにする。
  (Ｙ２５６〜３１９の範囲はアドレスが 0x0000 になる）


■2004.07.21 ver 200 
	・mkIIメモリマップを切り離したらアッサリSRメニュー画面が出てきた( ﾟ∀ﾟ)
	SRモードで動いているときにmkIIのメモリ配置にならないように入り口で
	蹴ってしまえば良いだけのこと…気付いてみれば単純な話しでした。

まとめ：SRモードを手っ取り早く動かすには…
======================================================
SR-ROMの読み込み。
    BASICROM.68,CGROM60.68,CGROM66.68
    KANJIROM.68,VOICEROM.68,SYSROM2.68
各種SR用IOポートの実装
  IO_60H〜6FH：SRメモリバンク切り替え
  IO_C8H：CRTモード切り替え
  IO_C9H：TEXTアドレス切り替え
  IO_CAH,CBH：BITMAPスクロールX
  IO_CCH,CDH：BITMAPスクロールY
  IO_CEH,CFH：BITMAPアクセス座標 Y
  IO_FAH：SR割り込みコントロール
既存のIOポートの改変
  IO_A3H：IN が行われたとき YM-2203のダミーステータを返す。
          0x80,0x80,0x80,0x80,0x00 をループで返せば良い。
          (FM音源を実装するまでの仮対処。)
  IO_B0H：VRAMアドレス切り替え無効化
  IO_C1H：CGROMバンク切り替えを切り離し、SRモードのSCREEN変更実装
  IO_C2H：漢字ROMの切り替え無効化
  IO_F0H〜F2H：mkIIメモリバンクの無効化
8x8フォントの表示に対応
VRAMメモリアクセスの実装
SRモードのSCREEN表示対応
======================================================
これだけやっとけば、とりあえずSRメニュー画面は出てくると…。
他にも色々とSRだけの機能があるだろうけど、画面見ながらノンビリやれば良いのデス。
で、問題はVRAMのメモリアクセス。
IO_C8H で BITMAPモードフラグが立っている時は、
Z80を実行する為のコード読み込みは現状のままのメモリバンク参照で行い
LD などの命令での読み込みは IO_CEH,CFH とオフセットアドレスを組み合わせた
MAIN_RAMから読み出しを行うように分離しておかないと、BITMAPフラグが
立てられた途端にZ80実行の為の読み込みもVRAMアクセスで読み込まれてしまい、
即暴走に繋がる也。

■2004.07.16 ver 200 
	・システムメニューから画面解像度選廃止。
	SRの最大解像度は 620x200 なので、それに合わせて 640x480 を
	ウィンドウ解像度として固定する。
	ただし、デバッグモードの表示に 640x400 のサブウィンドウを
	出すわけには行かないので、ここは 320x200 に縮小表示することにする。

■2004.07.11 ver 200 
	・音声合成の実装が完了したということで、SR実装分離バージョン開発開始。
	先ずはI/Oポートの実装から、メモリバンク切り替え0x6n実装。
	この雑誌コピー資料だけでは外部デバイスが存在しなかった時の動作が
	不明確なので、現時点では問答無用で拡張RAM(64KB)は実装させておく。
---------------------------------------------------

表作成用コピペ
┏━┳━┓
┃  ┃  ┃
┣━╋━┫
┗━┻━┛



