Super System Card の仕様

address は全て21bit絶対表記です.

0x000000-0x03ffff R-  ROM (A)
0x040000-0x07ffff R-  ROM (A, mirror)
0x080000-0x08ffff --  未定義 (B)
0x090000-0x0bffff R-  RAM (C, mirror, read only)
0x0c0000-0x0cffff --  未定義 (D)
0x0d0000-0x0fffff RW  RAM (C)
0x1ff8c0          RW? RAM control register?? (E)
0x1ff8c1-0x1ff8c7 R?  version register (F)
0x1ff8c8          RW? RAM control register?? (E, mirror)
0x1ff8c9-0x0ff8cf R?  version register (F, mirror)

2018年12月11日(C)を改訂.
2019年1月5日(B)を改訂.
2019年3月10日register offset 7 について追加.

address decode に関する考察

• ROM と RAM の領域は A18 は address decoder はみていないが、 write strobe 制御でみている.
• 未定義領域(B)は Arcade Card で 0x8000 byte の領域に mirror での IO port が追加される. Super System Card からの出力はしない.
• mirror 領域は BIOS では参照しないように作られているので全く同じでなくても動作するらしい.
  • DS 英雄伝説2の起動直後に address 0x99000 へ書き込み、再度読み込んだ結果が異なるとフラグを立てて、ゲームの途中で意図的に止まるように組まれている.

register に関する考察

bios の address は 16bit の PC 表記で絶対アドレスは 0x000000-0x001fff に割り当てられているという設定です.

• これがないと画面で SUPER の文字が出ない.
  • 逆説的に, IFU-30 などではこの address に data を出すということはない.
• offset 0 は非公式 BIOS で書き込んでいるので RAM の使用を制御できるらしい?
• offset 5,6 は TG-16 での同名カードとデータが異なる.
  • データの比較は BIOS 内部で完結するので, データが異なっても BIOS の返す結果には影響はない.
• offset 1,2,3 は BIOS $e05a で参照する. 目的は version の確認.全ての CD ソフトで確認する.
• offset 5,6,7 BIOS $e0de で参照する. 目的は同じく version の確認だが、Super CD のみ利用可能. version を知るだけなら $e05a で十分でこの確認をしないソフトが結構多い.
• offset 7, read, bit7 は super system card の種類. 0 が HuCard の Super System Card と Arcade Card Pro, 1 が Duo シリーズ.
  • PI-CD1 はおそらく 1 になる気がする
  • あすか120%の裏技扱いのシステムカードチェックで判別していたので調べた. Arcade Card のレジスタでは区別できないようだ.

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

Subchannel の並びの対応は PC ソフト側 HDL 側共に完了しました. いくつか問題があります.

問題1:回路数限界

HDL のコード上、利用回路数はたいしたことがないはずでしたが、 FIFO を追加したところで EP2C5 に収まらないとエラーが出てしまいました. FIFO の RAM 容量ではなく FIFO を構成する回路の利用量が多いことを忘れていました.
開発機の EP2C8 で利用していますが、本当に採用するなら対策をいれる必要があります.

問題2:command 0xdeと RAM 容量限界

開発機では先述の問題を回避できるので、デバッグを続行しました. 次に判明した CDG player の起動時の処理の順番がおかしいみたいです. おかしい原因が私の実装の互換性不足であれば調査して直せばいいのですが....

• Audio CD player で Graphics を押す
• 画面が切り替わるので約3秒以内に再生ボタンを押す
  • 押さないとカーソルが DISC ボタン移動して初期化し直す
• 再生ボタンが押せた場合、 Audio Disc 再生コマンドが走るがその後に comannd 0xde が走る

最後の command 0xde は TOC を参照し MSFC を返します. RAM 容量をけちるためにここは DISC IMAGE を毎回読みにいってデータを返しておりまして、 Audio play 中に command 0xde を発行すると Audio は停まります...
DISC IMAGE を読まずに最初に RAM に load しておけば良いのですが、RAM 容量は先述ではギリギリの状態でしてあまりここにも余裕をおけない状態です. ここを RAM に展開する場合は単純計算で MSFC*1 の各1バイト * 102 で 408 byte もいります. C は 1bit なのと、 S と F は 7bit で済むのでそこに詰めて 306 byte ならまだいいのかもしれませんが...

問題3:仮に動いたとしても実用に値する物なのか

• CDG player に入るまでに操作が多い
• CDG player がなんか変
• 映像描画規格が明らかに貧弱

難しいものです.

*1:Minute 0-99, Second 0-59, Frame 0-74, Control 0-1

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

データの並びは仕様書通りに channel R からW (bit5:0) を利用します.
ここで command と instruction があり、instruction は 6 通り定義されているのに規定外のそれが大量に出てきて解釈に困りました.

これはどういうわけか仕様書に書いてないことで, channel R から W のaddressを並び替えるということがあります. cdgtools v0.3.2 の cdgtools.py に deinterleave の記述がありますのでこれにしたがってやります.

• 並び替えには 1 度に 3 sectors の読み込みが必要です.
• channel P と Q は並び替えてはいけません.

interleave は address/data bit のわりと規則性のある並び替えに対して使う言葉と思っていたので、先日の .sub ファイルの並びを仕様書通りに並び直すことを interleave と誤って解釈していました. この2つの並び替えはまた別の物です.

mednafen での動作も大体わかりましたので upergrafx にも実装しようと思います. しかし今のイメージファイルは sunchannel の並び準拠のため、イメージファイルの仕様変更及びそれに追従した ikaebi のコード修正と HDL 側 subchannel Q の解読コードの作り替えと結構面倒くさいことになります.

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とがろすぺのソース流用はないらしい