CD Graphics 対応のための調査その1

CD Graphics (別名 CDG, CD-G, CD+G) を実験として対応してみようかと思います. とりあえず medfenam のソースコードや CD Graphics の仕様書などを見てます.
調べたことを書いていきます.

CD-ROM2 fifo

CDDA 再生中(CD-ROM read 中でも入りそうですが..?) に fifo に subchannel data が入りそれを 6280 の port から読み込む.

address 0x1ff802.w.4
subcchannel FIFO IRQ MASK

address 0x1ff803.r.4
subcchannel FIFO status

address 0x1ff807.r.7:0
subcchannel FIFO data (+auto increment)

IRQ2
status と IRQ MASK が共に1の場合 IRQ2 の線が low になる.
  • FIFO data は 1 sector 読み込むと 98 byte の data が入る.
    • data の並びは 0x00, 0x80, subchannel data. data bit7 が 1 になるのは 2番目の data のみ. subchannel data の並びは規格書通り.
  • FIFO status は subchannel data が入ると 1, address 0x1ff807 を読んで fifo が空になったら 0 を設定.
  • FIFO を意図的に空にする条件は現在不明.

subchannel の仕様

  • 1 sector あたり 98 byte の data を持つ. 先頭 2byte は同期信号.
    • 12 byte ごとに P,Q,R,S,T,U,V,W の 8 つに分ける.
    • P と Q はどの CD でも使われている. CD Graphics は R から W も使う.
  • Compact Disc の仕様では data の並びは 1 byte に P から Wの 1bit ずつを保持する. bit7 が P, bit6 が Q ... bit0 が W となる.
  • 各 1bit は MSB ->LSB

subchannel image の仕様

  • パソコン上で CD image を作ると .sub のファイルができるが同期信号を捨てて順番を並べてかえている.
  • byte offset 0 から 11 を P, byte offset 12 から 23 を Q ... という並びで 1 sector あたり 96 byte となる.
  • 経験上 subchannel の data は PCE の CD に限っては(当時の規格として許容される量の)誤りが多い. そのせいなのかドライブによって補正をかける,補正をかけない,全部 data 0にして出すなど対応はばらける.
    • subchannel data は CD-G などの派生規格やコピープロテクト目的ではない限り、あまり使われず出力しない場合も多かった.
    • subchannel data は通常のCDであればなくても再生成が容易である.
    • 一般ユーザーが疑う PCE の CD image の中身が異なる部分は .img の方のデータの中身であって subchannel は調査しないことが多いし、違っていても大した問題ではない.

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 に補正している仕組みがあるなら考え物.