CD-ROM2 の ADPCM 用(にもつかえる) RAM の転送その3

別件の修正です.主に CD-ROM コントローラから ADPCM 用 RAM を書いてしまえる DMA と呼ばれているやつです. 等幅に書いてある部分の左端の数値は 6280 からの絶対address 0x1ff80x の略記,その次がそこに書かれる data で並ぶ場合は連続で書かれます.

bios, DMA, write pointer 初期化あり

先日の記載と同じです.

8 xx
9 xx
d 3,2,0
1 81 08 xx xx xx xx 00
b 2
(loading)
b 0

d = 3 の時点で write pointer を更新します, その後の 2, 0 は意味があるのかよくわかりません. b = 1 を書いた時点で転送を開始し、 write pointer がずれることはありません.

b = 2 の代わりに b = 1 をする自前コードがたまにあります. がろすぺがそう.

bios, DMA, write pointer 初期化なし

download2 がやってました. bios を使ってるのであまり文句は言えませんが、write pointer の初期化を忘れていそうです.

d 0
1 81 08 xx xx xx xx 00
b 2
(loading)
b 0

この場合は write pointer はその前に使った値のまま使われます. 以前のソースはここで write pointer を更新していておかしかったようです. 普通の RAM が足りなくてキャラデータを ADPCM 用 RAM にいれておいてボスになったらそれを読み込ませる処理をやっているみたいです.

自前コード,DMA, b を書く順番が違う

先日の記載です.

1 81
8 xx
9 xx
d 3,2,0
b 2
1 xx xx xx xx xx 00
(loading)
b 0

address 0x1ff801 に書く順番がちょっと変ですがここは問題になってないので無視します. b = 2 を書いた後に残りの read(6) のパラメータを書きます. この場合も write pointer はずれません. (ずれてたので直しました)

bios, 6280 write

8 xx
9 xx
d 3,2,0
c xx,xx,...

d = 3 のあと d = 2, d = 0 と続くので, write pointer がずれないようです.

自前コード,6280 write

8 xx
9 xx
d 2
a ??
a xx.xx,...
d 0

d = 2 のままなので write pointer が1個ずれて a = ?? によって補正されるようです.
エミュレータ上の解釈は d の bit2 が 0->1 になるときに bit0 が 1 の場合はwrite pointer はずれない, bit0 が 0 の場合は write pointer はずれる. ということになっています.

5つの例を見ての解釈

  • read(6) の発行の前後にかかわらず address 0x1ff80b の w1 か w0 を 1 にすると CDROM FIFO の buffer が ADPCM 用 RAM に書く
  • address 0x1ff80d w1 を 0->1 にすると write pointer を設定し,状態を write standby にする
    • 先日コードまでこの入力は 0x1ff80d.w1 | 0x1ff80b.w1 | 0x1ff80b.w0 としていましたが解釈を変えました
    • write stand by は address 0x1ff80d w1 を 1->0 にするか, address 0x1ff80a を write すると write ready に変わる
  • address 0x1ff80d.w1 を 1->0 にすると 状態を write ready にする

いまのところ address 0x1ff80d.w0 は意味がないという実装にしていますが、これでうまくいかないソフトがでるならエミュレータと同じにすべきだと思います.
この調査は everdrive 持ってる人がプログラム書いて DUO で動かしてくれるとわかるんでだれかやってほしいです.

続 CD-ROM2 の ADPCM 用(にもつかえる) RAM の転送

コブラIIとロードス島(1作目)の停止理由をみたところ原因は下記でした.

  • READ(6) コマンドの転送先を題名の RAM に設定
  • その初期化の一部を BIOS を使わずに直接制御

ADPCM 用(にもつかえる) RAMというまどろこっしい表現はこの RAM へ ADPCM 用の data をいれればボイスが出るのですが、非SUPERソフト*1で普通に使える RAM 容量不足の対策に使っていてボイスに関係ないことが多々あります.

問題のコードは2作品で流用されていて BIOS と違う初期化手順でも正常動作すればなおりそうです. いまは 1 byte ずれててそこで暴走したり停まってました.

bios

8 0
9 0
d 3,2,0
1 81 08 00 1b f5 1b 00
b 2
(loading)
b 0
(6280 read ADPCM RAM)
8 0
9 0
d 8,0

問題の手順

1 81
8 0
9 0
d 3,2,0
b 2
1 08 00 61 35 0f 00
(loading)
b 0
(6280 read ADPCM RAM, used bios)
8
9
d 8,0

別の手順

address 0x1ff80b に data 0x01 を write するもの. 流用コードとちょっと似ている...

1 81
8 0
9 0
d 3,2,0
1 08 00 0f 1b 05 00
b 1

*1:SUPERソフトでも容量不足になったらやっぱり使う

CD image を可逆圧縮して保存する

この手の開発をしていると CD image を HDD に大量に保存する必要がありまして、結構容量を食います. 圧縮するにも可逆圧縮でないとデバッグが不完全になってしまいます.

これらは全てコマンドラインシェルスクリプト経由で運用する流れです.

chdman で固める

chdman は MAME に付属するディスクイメージを固めるソフトだと思います. CD image の場合、DATA は deflate (たぶんzlib), Audio は flac で固めますので可逆圧縮です.
MAME なら固めた chd ファイルからも起動できます. (しかし,家庭用ゲームを遊びたい人が MAME を選択するのはないでしょうね... PCE のエミュレーション精度も理由があってあんまよくないですし)

前回の cdmanipulator で作ったファイルも固められます. .cue と .img が必要です.

 chdman createcd -i hoehoe.cue -o hoehoe.chd

7za で固める

.img はこの段階で削除可能なので、.chd .sub .cdm を 7za.exe で固めます.

 7za a hoehoe.7z hoehoe.cue hoehoe.cdm hoehoe.sub -mx=7
 7za a hoehoe.7z hoehoe.chd -mx=0

.sub と .cdm は圧縮率が高いデータになりますので -mx=7 で固めます. .chd はすでに圧縮したファイルですので圧縮しない -mx=0 で 7z ファイルに入れ込みます.

この行程で元のファイルからの中身にもよりますがファイルサイズが 50% 程度になります.
ys1&2 の img ファイル(766,702,608 byte)を zip,7z,chdへ圧縮した場合の処理時間と圧縮率比較です.値は共に少ない方が優秀です.

 zip 37sec 91%
 7z  53sec 86%
 chd 93sec 62%

圧縮ファイルから戻す

 7za x hoehoe.7z
 chdman extractcd -i hoehoge.chd -o hoehoe.chd.cue -ob hoehoe.img

chdman の -o オプションで .cue の文字列を含める必要があります. これをしないと audio の byteorder が圧縮前と逆になります. これはドキュメントには書いてなくてソースコードから確認しました.
-ob は付けないと拡張子が .bin になりますので全く同じにしたいなら .img にしたほうがいいでしょう.
cue 自体は別途ありますので .chd.cue にしてます. おそらく一緒の中身がでてくると思いますが詳しくは知りません.

補足:Audio の byteorder

.img のフォーマットは CDRWIN 発祥でそこで Audio の byteorder は little endian と決められたようです. イメージを作るソフトも多分それにならって little endian に統一されています.
実際の CDDA では bigendian で書き込まれているようです. CD の多バイトデータは bigendian で構成されているのがほとんどで CDDA だけ little endian にするのはちょっと考えられないです.
そこらへんがあって少し混乱があったようです.

Super System Card 内蔵本体レジスタの予測

DUO シリーズと PI-CD1 の仕様の考察です. Games Express CD Card の対応をしていて気になった記述がありました.

games express cd card (blue)
00F8C6: 
	cli
	lda	$18C1 <- レジスタの読み込み
	cmp	#$AA
	bne	$F8EB
	lda	$18C2 <- レジスタの読み込み
	cmp	#$55
	bne	$F8EB
;レジスタがあったので初期化
	lda	#$AA
	sta	$18C0 <- レジスタへの書込み
	lda	#$55
	sta	$18C0 <- レジスタへの書込み
	lda	#$68
	sta	$2204
	lda	#$20
	sta	$2205
	bra	$F8F5
00F8EB: ;レジスタがないので旧システムと判断
	lda	#$80
	sta	$2204
	lda	#$08
	sta	$2205
00F8F5: 
	lda	#$01
	tam	#$40

CPU address $18cx は絶対 address 0x1ff8cx のことです.
read のレジスタは HuCard の Super System Card にも存在し、 BIOS でも参照してます. ここに無効な値をデータバスに出すと起動画面で SUPER の文字がでなくなって旧システムと判断するようです.

HuCard の Super System Card 内部には下記の IO があります. 全て mirror を含んだ絶対アドレスでの記述です.
絶対アドレス

0x000000-0x07ffff ROM
0x080000-0x0fffff RAM 
0x1ff8c0-0x1ff8cf register

内蔵機種の場合 HuCard (相当品も含む)挿入でこれら全てが無効になると思いこんでたのですが, ROM と RAM を無効にして register は無条件で有効のようです. *1
この BIOS の書込みをから想像するに 0x1ff8c0 に上記の値を書き込むと HuCard が挿入されていても内蔵 RAM が使えるようになるみたいです. なぜなら Super System Card の BIOS ではこのレジスタ領域は読むだけで書くことはありませんでした. さらに HuCard の Super System Card では RAM は必ず有効になるべきなので, 本体内蔵機種でのみ意味があるレジスタになります. *2

UperGrafx では標準状態で address 0x1ff8cx の read レジスタは HuCard のほうを使うようにしています. Games Express 専用モードでは read レジスタも UperGrafx から出力することと 0x0d0000-0x0fffff の RAMを使えるようにして CD 麻雀美少女中心派が起動できることを確認しました.

*1:これを非公式メーカーが何故知っていたのかが疑問です

*2:HuCard の Super System Card でも Card 挿入端子をみて有効無効を決められますが... 合理化すると中身全く一緒のほうがいいのかも?

cdimage 作成の手順と注意

UperGrafx 内蔵の CD-ROM2 互換機能ではメモリーカードに cdimage を転送した状態で運用します.

手順

  • cdimage の作成は PC から CD-ROM が読める drive を接続して行ないます.
  • cdimage の作成ソフトは CDManipulator を利用します.
  • 作成したイメージファイル (拡張子 .cdm, .img, .sub) を専用ソフト(後日提供予定)から専用パーティションへ無圧縮で転送します.
    • エクスプローラからファイルをコピーする手順ではありません.
    • CDManipulator 作成のデータ限定での対応です. 他ソフトが作成した cdimage を転送するプログラムを書いてくれる人がいらっしゃるなら転送ソフトのソースコード提供をしようと思います.

CDManipulator の設定

画像のようなオプションにしてください.

  • マルチセッションモード (これはシングルでもいいと思う)
  • 高度な設定を選択
  • プリギャップ解析を「しない」
  • 正しいTOCとギャップ情報の取得を「しない」
  • エラーの無視を「する」
  • 残り2つはわたしにはよくわかりませんので好きにしてください.

正しいTOCとギャップ情報の取得をしない理由

このオプションは Compact Disc の規格違反だった場合は厳格な情報に補正する機能です. おそらくこの目的は CD-R ドライブ一般普及時の CD コピー対策で意図的にエラーを混ぜた disc への対処だと思われます.

HE システムの CD-ROM の場合は規格策定がされたであろう1988年頃の設計で運用されており意図的なコピー対策ではありません (CD-R どころかファイルシステムさえ存在していない時代です).

この問題の原因は audio track の次に data track がある場合のギャップ領域の管理データとTOCの相違です.
例としてうる星やつらでは TRACK 2 にはギャップ領域である index 00 とデータ領域である index 01 の2つが存在します. TOC には index 01 の開始時刻は 00:47:71 と書かれていますが、実セクタの管理データでは index 01 は 00:47:70 から始まっています.
subchannel の該当データ. index01 は 00:47:70 から始まっている(管理データの時刻はBCD表記で実データから2秒加算した値で運用する). 色をつけたデータ順番に 02->track, 01->index, 00->時刻(M), 49->時刻(S), 70->時刻(frame)


mainchannel 00:47:70 のデータ. 管理データに補正するとここを参照し意味がないデータが出てくる.


mainchannel 00:47:71 のデータ. ヘッダがありこちらを読み込めば起動する.

この相違があった場合には HE システムの CD-ROM としては TOC を優先しますが、image作成のオプションでは管理データを優先して補正します. この相違はおそらく 1988年頃の Compact Disc の規格としては許容されるエラーと私は考えています.

大半の CD-ROM2 disc では TRACK 2 の TOC が HE システムのCD-ROMとして正しい値を得られれば正常に起動します. disc の末尾に予備として data track がありますがここにもTOCと管理データの相違がある可能性があります. ただしTRACK 2 が正常に読めれば利用されないので問題になりません.


1 つの disc に 3 つ以上の data track が存在する場合はこの相違が data track の数だけ疑いがあるので必ず補正されていない TOC を優先する必要があります.
例えば迷宮のエルフィーネは data track が 22 個もあり, このオプションを有効にすると補正が大量にかかりますが、 TRACK 2 は問題ないので起動はするものの絵がおかしくなります.
(左がTOC準拠、右が補正されたもので違いが大量にある. これは data track のみを抜粋した比較であり, audio track を含めると相違点が大量にある. audio は2/75秒程度ずれていても人が違和感を感じないはずで動作には影響が少ない)


エラーの無視をする理由

ディスクが物理的に損傷していない場合、いままででたエラーを見るとギャップやloadout領域の規格違反ばかりでした. CD-ROM2 システムではギャップやleadout領域のデータを見ることはありませんので無視して構いません.
エラーも含めて精度の高い完全なイメージを作りたいという話だとCD-ROM2互換機能開発の目的からそれていきますので光学ディスクの専門家を探して相談してください.

upergrafx cd 互換機能ソフト個別リスト

https://docs.google.com/spreadsheets/d/1wsMjm5DMLgWVzfab49cX-TYCAgx0fXAiLJ6UL7AwNAM/edit#gid=1608184984
致命度は低い物の(つまりなぜかとまらない)重要な問題をいくつか直しました.

command 0xdd, 0xde

databus を hardware handshake にしてから安定していませんでした.
この2つはゲーム起動後には安定しなくても動いていたのが謎でしたが、 0xde のほうは起動時のみ, 0xdd は CD player ぐらいでしかつかわないのでゲーム起動中はあまり関係がないということでした.

hardware handshake の不安定の原因は6280バスの監視の設計が根本的におかしかったことが判明しましたので直しました.

adpcm status (その1)

通常 ADPCM は再生完了の割り込みを受けてレジスタを再度更新するはずなのですが、割り込みを受けないソフトの対応をしました.

0x1ff80b.w = 1


6280 からみてwrite 側の対応よりかは read 側の対応も必要でした.
これにより HCD5080 (銀河婦警伝説) と HCD4067 (がろすぺ) がまともに遊べるようになりました. HECD6026 (てきぱき)はいままでまともに起動しませんでしたが、オープニングが動いてゲーム本編でいきなり停まるところまでです.
がろすぺとてきぱきは問題のBIOS外でのレジスタ操作の部分のソースがまったく同じでソースを流用した可能性があります. *1

0x1ff80b.r 側の対応をしたためなのか charawrong がいくつか改善しています. NAPR-1018 (download2) は全く直ってないので別の原因かもしれません. これは毎回起きるわけではなかったのでしばらく様子見です.

fadeout

fadeout 完了後に音量が0%の場合にもう1度 fadeout とすると音量が100%に戻ってfadeoutをし直すという問題の対応をしましたがこれが不十分で、銀河婦警伝説はそこがおかしくなりました. ゲーム本編はまったく問題ありません.

adpcm status (その2)

途中で adpcm が再生できなくなっておかしくなっていました.
原因は state machine の state で fifo の empty での条件更新が同じ複数レジスタが一部矛盾していました(まれに発生). empty flag を 1 度 latch してから条件にいれたら安定しました. これは warning で文句いうのか伝搬遅延で高い値がでるはずなんですが、見落としてたのかもしれません.
ただ empty flag の使い方は複雑な条件を混ぜてるわけではなく, dual clock fifo の write 側の empty を見ているので勝手が違うのかもしれません. (通常は empty を見るのは read 側が大半)

*1:意外なことに餓狼2とがろすぺのソース流用はないらしい

upergrafx cd 互換機能ソフト個別リスト

確認数が増えたため csv で管理することにしました. 内容は公開いたします.
https://docs.google.com/spreadsheets/d/1XPKLQS6xKoB1jTkHLnzNVm1AlEISMRddpeVPh7q6Ey4/edit#gid=398211885

  • 型番及び名称は mame に付属している hash/pcecd.xml から抽出し、一部手直しをしています.
  • マイナーバージョンの違いは区別しません.
  • ADPCMの音割れは影響範囲が多いため個別ではなく全体の問題とし、個別リストには記載しません

A列:型番

B列:upergrafxでの動作状態

  • (空欄): 未確認
  • ok: 5分ぐらい動作して問題なし
  • bad: 不具合があるが、動作は停まらないなど軽微なもの
  • freeze: 停まる
  • toc ng: disc dump 時で toc が自動補正されるのか,起動しない.
    • ->: toc を手動補正したあと起動確認後の状態
    • これはおそらく Compact Disc での規格上、厳格な判断では不正な状態になっているもので disc dump 時に自動で補正がかかり toc がずれてしまうと考えています. 正式な対処をするのであれば本物の disc を本物の CD-ROM2 から取得する toc を得てそれを image に記載すれば直ると思われます. つまりそのための PCE 向けのソフトを作る必要があります.

C列:不具合の概要

  • 未調査: 未調査.
  • charawrong: 映像で一部キャラクタが化ける. 化け方は毎回異なり起きないこともあるし激しく起きる場合もある.
  • videononsync: ロード時間が早すぎるのかロード経過表示がとても粗くなる
  • cddadelay: 映像とCDDA音声がずれる
  • nonbios: BIOS 外でのレジスタ操作, これがある場合対処によって動いたり動かなくなります
  • 0x1ff80b.w=1: 通常 2 を write するものの, bios 外から 1 を write する. 1 の現状動作の対処ができていない.
  • adpcmstatus: adpcm での再生の前後で何かしらの不備で停止

D列:名称

upergrafx CD-ROM2 互換機能ソフト別動作確認状況

データ転送方式の根本的改善と致命的な実装不備を2件直しましたので安定度が上がりました. BIOS 外でのレジスタ操作が原因での不具合は信頼性のある対処に時間がかかりますので、一般提供後に内部更新機能を利用して段階的に対応していくつもりです.

7月8日更新: 確認ソフト数を45本から59本に更新しました.

45/59 問題のないもの

起動後5分程度の操作で不具合がないものです.

cjcd4005_sotsugyoushasin_miki
dwcd1001_rayxanber2
glcd4001_advancedvariablegeo
hacd0003_superdarius
hacd9002_sidearms
hcd0015_ys3
hcd2024_starparodia
hcd2025_gateofthunder
hcd3043_cotton
hcd3046_tengaimakyou_kabukiden
hcd4063_worldheroes2
hcd4064_tengaimakyo_dendennoden
hcd5075_gingayuna2
hcd9009_ys_1_2 (補正後)
hecd3003_moonlightlady
hecd4009_madstalker
hecd4010_3x3eyes
hecd5024_deadofthebrain
iccd1001_rtypecompletecd
kmcd2002_snatcher_cdromantic
kmcd2003_gradiusii
kmcd3005_akumajoudraculax
kmcd4007_tokimekimemorial
mccd4005_fraycd
napr-1036_sotsugyou_graduation
napr-1038_puyopuyocd
napr-1049_asuka120
napr1041_striderhiryu
nscd0004_ranma1_2
nscd0005_ldis
nscd1006_ranma1_2
nscd2009_ranma1_2_datou
nscd2013_choaniki
nxcd1004_sereisenshispriggan
nxcd2008_sprigganmark2
nxcd2010_doubledragon2
nxcd3022_motteketamago
nxcd3027_srmp4custom
pvcd-2005_minesweeper
rscd-3002_fiendhunter
thcd3001_sylphia
ticd-4002_hatsukoimonogatari
tjcd0010_legion
tjcd2024_babel
tjcd9004_redalert

3/59 一部問題のあるもの

一部声が割れます.

hcd2031_gingaojosamadensetsu_yuna

読み込みを早くしているためにデータ読み込み画面の更新がよくないです. ゲーム内容は問題ありません.

hcd4061_ryukonoken

システムカードversion2以下での起動画面が高確率で不正なものになりますが、軽い調査では原因不明でした. 進行に問題はなさそうなので保留にします.

hcd3051_ys4

5/59 停まる, BIOS 外のレジスタ操作

6280 address 0x1ff80b.write への書込み処理を簡略化して動いているものが多い傾向です. 0x1ff80d.write への処理も自前でやっている物もあります.似たような不具合を総合的に見て無難な形にする予定ですが、最終的には実物での動作を分析して互換性を上げたいところです.

hcd4067_garoudensetsuspecial
hcd5080_gingafukeidensetsu_sapphire
hecd6026_tekipakiwarkinglove
jccd9001_kagaminokuninoledgend
napr-1034_calii

5/59 停まる, 詳細未調査

hcd5078_yunahv
nxcd2016_srmspecial
nxcd3028_mahjonglemonangel
tjcd2022_mirashounenkonan
tjcd2023_mugensenshivalis

2/59 イメージの作成に問題

TOC の値が規格と少しずれているらしく、イメージ作成ソフトが誤って補正しているのかなどイメージ作成の過程で調査が必要です.

hcd9009_ys_1_2
tjcd0008_meikyuunoelfeene

upergrafx CD-ROM2 互換機能ソフト別動作確認状況

システムカードは本物を使ってますのでそれが原因で動かないということはないです.

ある程度やってみて問題なし

cjcd4005_sotsugyoushasin_miki
hacd9002_sidearms
hcd2025_gateofthunder
hcd3046_tengaimakyou_kabukiden
hcd4064_tengaimakyo_dendennoden
hecd4010_3x3eyes
hecd5024_deadofthebrain
kmcd2002_snatcher_cdromantic
kmcd2003_gradiusii
kmcd3005_akumajoudraculax
mccd4005_fraycd
nscd0004_ranma1_2
nscd2013_choaniki
nxcd2008_sprigganmark2
nxcd2010_doubledragon2
nxcd3022_motteketamago
nxcd3027_srmp4
rscd-3002_fiendhunter
thcd3001_sylphia
ticd-4002_hatsukoimonogatari
_crazyhospital

停まらないがちょっと変

hcd2024_starparodia
hcd2031_gingaojosamadensetsu_yuna
napr-1049_asuka120

ADPCM の再生が一部ダメ.

  • hcd2024 は雑音がすごい(詳細未調査).
  • hcd2031 は割れる. 追記のつなぎ合わせが悪いだろうか?)
  • napr-1049 はおそらく 6280 から ADPCM 用 RAM への追記をしていてそれの対応ができてない.
hcd9009_ys_1_2
hecd3003_moonlightlady
jccd9001_kagaminokuninoledgend

絵が一部変になる. キャラデータの転送がまれに変. ADPCM RAM から 6280 へデータを読んでるんだろうけど対応ができてないと思われる(詳細未調査).

停まる

hcd4061_ryukonoken
hcd5078_yunahv
hcd5080_gingafukeidensetsu_sapphire
hecd6026_tekipakiwarkinglove
nxcd1004_sereisenshispriggan

全部起動はするけど途中で止まってしまう...

  • hcd4061, hcd5078 は未調査.
  • hcd5080 はちょっと見た感じ無駄なコマンド発行があるのでプログラムが汚そう.
  • hecd6026 は BIOS 外でのレジスタ操作.
  • nxcd1004 と mccd4005 は 6280 address 0x1ff802.r から CD-ROM data を読んでいたのでそれの対応をやって mccd4005 は問題なしに昇格. nxcd1004 のほうは fifo にいれたデータを全部読み切ってないらしい.

例外的な対応

hcd9009 は CD-ROM track index 01 の TOC が 1 frame ずれていて, discimage の作成に問題があるのか本当にこれで動いているのかの判断が必要. とはいえこのご時世に問題があるデータを作ってくるとは思えないので、この状態で起動することも考えている.
一応 subchannel Q も確認したが TOC の通りで mainchannel の sector が後ろにずれている... この時に本物の CD drive が mainchannel の管理データをみて1つ後ろの sector に補正している仕組みがあるなら考え物.

PCE CD-ROM2 内部 ADPCM 用 RAM 制御機能に対する考察

情報の精度

この文書はインターネット上で得られる情報を元に実装したものであり、実機からの分析情報ではありません. 情報の精度はよくありません. 詳しい仕様をご存じの方は是非教えてください.

はじめに

CD-ROM2 システムで一番複雑なのは ADPCM 用 RAM 制御であると思われる. CD-ROM2 に入っている ADPCM decoder は MSM5205 であるが、 MSM5205 には RAM 制御機能は一切なく, CD-ROM2 側で RAM を制御管理する.

制御内容はおおまかに下記である.

  • 6280 (CPU) からのデータ読み書き
  • CD-ROM コントローラからのデータ書込み
  • MSM5205 へのデータ送信

6280 からのレジスタ

制御レジスタは絶対アドレス 0x1ff800 から 0x1ff80f にあり、当機能に該当するもののみ記載する. レジスタのアドレスは一部 bit を decode していないので mirror がある. decode していない bit はおそらく bit9:4 だと思われる.
レジスタには read / write で別の意味を持つもの, write cycle が発生しただけで意味を持つものもあるので RAM と同じ感覚で考えてはいけない.

レジスタは address.rw.bit と表記し 0x1ff80d.w3:0 とある場合は絶対アドレス 0x1ff80d, write, bit0から3の4bitを意味する.

address 0x1ff800, 省略

address 0x1ff801, 省略

address 0x1ff802, 割り込み発生許可
w6   CD (seek?) ready interrupt mask (0:disable, 1:enable)
w5   CD (transfer?) done interrupt mask (dataの意味は同上)
w3   ADPCM play done interrupt mask (dataの意味は同上)
w2   ADPCM length register msb interrupt mask (dataの意味は同上)
read や他の bit は省略
bit4 は CD-G に使う割り込みらしいが現段階では省略

address 0x1ff803, CD,ADPCM 状態
r6   CD (seek?) ready status
r5   CD (transfer?) done status
r3   ADPCM play done status
r2   ADPCM length register msb == 0
address 0x1ff802 と同じ bit の並びになっている. 割り込み許可時に
この値が 0->1 になると 6280 へ IRQ2 を送信する.
bit4 は address 0x1ff802 と同じ

address 0x1ff804, 省略

address 0x1ff805, 省略

address 0x1ff806, 省略

address 0x1ff807, 省略

address 0x1ff808, ADPCM argument register (1/2)
w7:0  ADPCM argument bit7:0

address 0x1ff809, ADPCM argument register (2/2)
w7:0  ADPCM argument bit15:8

address 0x1ff80a, ADPCM RAM data port
r7:0  ADPCM RAM read data
w7:0  ADPCM RAM write data
アクセスするごとに RAM address は increment される.

address 0x1ff80b, CD-ROM data desitination register
w1    CD-ROM data desitination (0: 6280 data port, 1:ADPCM RAM)
w0    不明
詳細の考察は後述する.

address 0x1ff80c, ADPCM RAM controller status
r7    reading status (0:idle, 1:reading)
r6:4  不明
r3    playing status (0:idle, 1:playing)
r2    writing status (0:idle, 1:writing)
r1    不明
r0    playing status の反転値らしい
詳細の考察は後述する.

address 0x1ff80d, ADPCM RAM controller operation
w7    reset (0:idle, 1:reset)
w6    play (0:stop, 1:play)
w5    play endless?
w4    latch to length register
w3    latch to read or play address register
w2    6280 から read に関する address 制御らしい
w1    latch to write address register
w0    6280 から write に関する address 制御らしい
詳細の考察は後述する.

address 0x1ff80e, 省略

address 0x1ff80f, 省略

6280 から ADPCM 用の RAM へのアクセス

  • argument register を書込み, 目的別の address register へ latch する.
  • 0x1ff80c.r0 は address latching と書かれている文書もある.
  • 0x1ff80c.r7 と r2 はこの RAM が実際には DRAM であるため、DRAM への address の設定や refresh の都合で時間が一定ではないため存在すると思われる.
  • 0x1ff80d.w2 は 6280 から読み込むときに 1 に set する. これを設定した後 0x1ff80a.r を 2 度読み込んだ後(=空読み)、指定した address の data が読み取れるが何故そうなるのかが不明.
  • 0x1ff80d.w0 ではやはり書き込むときに 1 にset する, read と違い 1 度の書込みのあと、指定した address へ data を書き込めるがやはり理由は不明.

6280 からの ADPCM 用 RAM の読み込みはかなり重要. RAM が少ない SUPER ではない CD-ROM2 ソフトで ADPCM の再生の目的ではなく RAM 容量を増やすために使われる. SUPER CD-ROM2 ソフトでもビジュアルシーンで通常の RAM を使い切った場合に CD-DA を停めずにデータをよんでいるなど、テクニックが多い.

CD-ROM 読み込みから ADPCM 用 RAM への書込み

通常は下記の手順で行なわれる.

  • READ(6) コマンド発行
  • COMMAND REQ -> COMMAND ACK -> DATA IN REQ
  • DATA IN REQ 受付後 0x1ff80b.w1 = 1 にする
  • ADPCM RAM controller から ADPCM RAM へ書込み
  • DATA IN REQ -> STATUS REQ

0x1ff80b.w1 = 1 のタイミングは BIOS では上記になっているが、BIOS を使わない場合は READ(6) 発行時点で 1 になっている場合もありそれでも ADPCM 用 RAM へ書き込まれる. このタイミングに設定している理由は不明.

ADPCM 再生中にも書込みが可能. ソフトでは再生と書込みの address 範囲が一致しないようにしている. 一致した場合の動作は現時点では不明.

ADPCM 用 RAM の address はおそらく 0x1ff80b.w1 = 1 の時点で argument register から latch すると思われる. このため 0x1ff80d.w1 = 1 は設定しなくても良い. また 0x1ff80b.w1:0, 0x1ff80d.w1:0 はこのために bit の並びを揃えているようなので, 詳細不明の w0 も同じ意味を持つと予想される.

ADPCM の再生 (追記の必要のない短い時間)

  • ADPCM 用 RAM に MSM5205 へ渡すデータを書き込む
  • length register と read or play address register を設定する
  • ADPCM play done interrupt を許可する
  • address 0x1ff80d.w = 0x60 を書き込んで再生開始
  • 再生終了後 IRQ2 が発生するので、発生原因が ADPCM play done の場合は address 0x1ff80d.w = 0 を書き込んで停止

再生開始は w6=1, w5=1, w2=0 となる. w5 は length register == 0 でも再生を停めないのか address register 0xffff -> 0x0000 を許可するという意味を持つと思われるが基本的に 1 に設定するらしい. w2 は空読みがいらない理由の根拠らしい.

ADPCM の再生 (追記が必要な長い時間)

  • ADPCM 用 RAM に MSM5205 へ渡すデータを書き込む
  • length register と read or play address register と write address register を設定する
  • ADPCM play done interrupt と ADPCM length register msb interrupt mask を許可する
  • address 0x1ff80d.w = 0x60 を書き込んで再生開始
  • 再生途中に IRQ2 が発生するので, ADPCM length register msb interrupt の場合は READ(6) を発行する
    • READ(6) 発行後, SCSI status を DATA_IN_ACK にした時点で 0x1ff803.r6 の割り込みを発生させること,この割り込みの後に 0x1ff80b.w1 = 1 となり、追記の初期化が完了する.
    • ADPCM 用 RAM への書込みが終わった時点で 0x1ff803.r5 の割り込みを発生すると,追記の処理の終了となり、次の追記の処理を受け付ける.
  • これ以上の追記を望まない場合は ADPCM play done interrupt のみ許可する
  • 再生終了後 IRQ2 が発生するので、発生原因が ADPCM play done の場合は address 0x1ff80d.w = 0 を書き込んで停止

追記処理は前述の処理をすべて応用するので、実装できていなかった.

ADPCM 用 RAM controller について重要なレジスタ(変数)は下記の動作をすると思われる.

  • length register
    • 16bit のレジスタ
    • read cycle の場合 -= 1
    • write cycle の場合 += 1
    • bit15:0 == 0x0000, bit15 == 0 で各 status, interrupt に反映
  • write address register
    • 16bit のレジスタ
    • 6280 からの write の場合は 0x1ff80d.w1 を利用し latch する
    • CD-ROM から直接 write する場合は 0x1ff80b.w1 を利用し latch する、再生中は latch しないらしい(?)
  • read or play address register
    • 16bit のレジスタ
    • read cycle に使用 (6280 からの read, MSM5205 の再生で更新)

追記処理中は address 0x1ff80d は停止以外の目的で書込みをしないのでこう解釈している. length register は overflow (0xffff->0x0000), underflow (0x0000->0xffff) が起きないらしいが、 address register は overflow が起きるため追記に利用できる.