Hatena::ブログ(Diary)

naruko の開発メモ

2018年08月01日

じゅうべえくえすとの敵が出る数の解析

メガトンコインRTAという動画でキノコングという敵が1匹でるべきである場面でそれが2匹でる, その原因は5つもバージョン違いだろう. という考察が書かれていました. 5つは多すぎでおかしいと思ったのでそれを調べました.

バージョン違いはあるが...

5個の根拠として[b]とか[h]とかついているファイル名があると書かれておりましたが、これは dump の手順を間違えているファイルが過去の混乱の遺物として残っているだけなので無視します.

かなり信憑性のある nescartdb は1つ登録があります. そこそこ信憑性のある MAME の hash/nes.xml には2つ登録があります.

この2つを見比べてみましたが、本当にバージョン違いなのか判断には困りました. 命令が増えたり減ったりしているのでそこの差分の部分をアセンブルするから命令とaddressが差分点からずれるていくものが普通のバージョン違いです. これは lda abs (3byte) 命令を jsr abs (3byte) 命令 にしていて ROM の末尾に命令を増やしています.

この手法は第3者がパッチを当てる場合は自分もよくやるんですが、その jsr 命令の中身が何かの計算の補正だったのでプログラマ当人かはわかりませんがたぶん当時の関係者が手をいれたものと思われます. *1

どちらとも敵の数は基本2匹、たまに1匹

両方のバージョンでキノコングが1匹でるはずであろうというところを確認しましたが、基本2匹、たまに1匹出るのでバージョン違いの可能性は低いと思います. (その2つ以外のバージョンがあるならべつの可能性はありそうだけど、1度生産して終わりの販売規模のこのソフトにはちょっと考えられない)

1匹でる条件を調べてみた

エンカウントで trace log を取りました. CPU address $6050 が敵の数なのはわかりました.

F969: lda ($fc), y <- 敵のテーブルのポインタらしい
F96B: lsr a
F96C: lsr a
F96D: lsr a
F96E: lsr a
F96F: lsr a
F970: sta $6050 <- bit7:6 を敵の数にしている

(中略)

8987: lda $6050
898A: clc
898B: adc $6051
898E: adc $6052
8991: rts
8940: cmp #$02
8942: bcc $8986 ;敵の数が2以上か
8944: jsr $f195
F195: lda $038e ;乱数生成
F198: clc
F199: adc #$17
F19B: sta $038e
F19E: lda $21 ;frame カウンタらしい
F1A0: clc
F1A1: adc #$b1
F1A3: adc $5000 ;φ2カウンタ bit7:0
F1A6: sta $21
F1A8: lda $5800 ;φ2カウンタ bit15:8
F1AB: eor $22
F1AD: adc $21
F1AF: eor $1f
F1B1: adc $038e
F1B4: sta $21
F1B6: rts
8947: lsr a
8948: bcs $8986 ;乱数 bit0 == 0 なら減らさないので分岐
894A: lsr a
894B: bcs $8986 ;乱数 bit1 == 0 なら減らさないので分岐
894D: lsr a
894E: and #$03
8950: cmp #$03
8952: beq $8986 ;乱数 bit3:2 == 3 なら分岐
8954: tay
8955: lda $6050, y ;敵を減らすなら $6050 で乱数 bit3:2 == 0 でいてほしい
8958: beq $8986 ;それが 0 なら減らさないので分岐
895A: sec
895B: sbc #$01
895D: sta $6050, y ;敵の数を1つ減らす
8960: bne $8986
8986: rts

乱数生成のサブルーチンはミサイルポッドの確率を出してた動画(じゅうべえくえすとの鉄パイプ乱数を観察)でもでてきたものと同じです. PC (program counter) $8955 の y の値がちょっと気になるのですが変数 $6050 は敵の数で, 変数 $6051, $6052 は未調査ですが敵に関するパラメータだと思います. (別種類の敵の数かも)

このログからの考察ですと、下記のポイントとなります.

  • 敵がでてくるときに乱数を引く
  • 乱数の bit3:0 == 0 の場合は敵の数を1減らす
  • 敵の数が1匹減る条件は 1/16 (6.2%)
  • この命令は通常敵が出るときでも実行する(ボスはやらない)
  • どちらのバージョンもここに違いはない

おまけ:ランダムエンカウントをなくす方法

FA1B: cmp $d2 
FA1D: bcs $fa22 
FA1F: inc $04c9 <= これを nop にするとランダムエンカウントがきえる 
FA22: jmp $fe05

cmp $d2 をユーザー入力にしてスタートボタンを押したときだけ敵が出るようにアレンジするとすごく遊びやすくなると思います.

*1:第3者がやるならエミュレータで動くように無理矢理書き換えるとか、ゲームを有利に進める目的なのでたぶん白

2018年07月10日

Super System Card の仕様

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

0x000000-0x03ffff R-  ROM (A)
0x040000-0x07ffff R-  ROM (A, mirror)
0x080000-0x08ffff --  未定義 (B)
0x090000-0x0bffff RW  RAM (C, mirror)
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)

address decode に関する考察

  • ROM と RAM の領域は A18 はみていない.
  • 未定義領域(B)は Arcade Card で 0x8000 byte のパラレルの RAM が追加される. Super System Card からの出力はしない.
  • mirror 領域は BIOS や CD ソフトでは参照しないように作られているので全く同じでなくても動作するらしい.

register に関する考察

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

  • これがないと画面で SUPER の文字が出ない.
    • 逆説的に, IFU-20 などではこの 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 で十分でこの確認をしないソフトが結構多い.

2018年04月08日

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

2018年04月03日

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 の解読コードの作り替えと結構面倒くさいことになります.

2018年04月01日

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 は調査しないことが多いし、違っていても大した問題ではない.