nesdev.com

調査がある程度進みましたので公開します。
現在広く知られている mapper #16 の明確な間違いは register address は $6000-$ffff の部分です。正しくは FCG-1 と FCG-2 は $6000-$7fff, LZ93D50 は $8000-$ffff です。
http://w.livedoor.jp/famicomcartridge/d ... G%20series

Datach の調査文書は結構雑です。ちょうど1年まえに調査したのですが、機材を返却してしまい当時のメモから作りました。

おかしいところや疑問点があったらいってください。

To Lidnariq:
nesdev wiki への執筆を楽しくみています。
I have a question on Bandai LZ93D50 pinout. I have not know detail information about 29 pin. Have you examine by yourself?

I have not examined for myself.
I assumed the only unexplained difference of pinout was pertinent. (Sorry)
It is possible that bus conflicts would happen with RAM on BA-JUMP2 if $800D.7 were ever set.
(google:
私は自分自身のために調べていない。
私はピン配置の唯一の原因不明の違いは適切だったと仮定した。 （申し訳ありませんが）
それは$800D.7がこれまで設定されている場合、バス競合がBA-JUMP2上のRAMとどうなる可能性があります。)

ぼくの調査を追試してくれたら、情報の真実さが増していいことだと思っていました。

ピンの並びからあなたの推測はもっともらしいです。推測は楽しいことですが、本物のICから確認していないなら"推測"または"?"を書いた方がいいです。

I have started fixing the (luckily minor) inaccuracies I had in MESS for these PCBs
Could you just confirm a couple of small details about the BA-JUMP2 board?

1. are the writes to $8004-$8007 ignored? (unfortunately google translate makes a mess of you original comment on this, so I have to ask for a confirmation, even if you probably already wrote about it on your page)
2. are the writes to $800d ignored, since there is only SRAM and not EEPROM on the board? your webpage seems to suggest that the lines on the board are present, even if no actual EEPROM is physically available...

1. CPU の $8004,$8005,$8006,$8007 への書き込みは LZ93D50 のレジスタ
にはラッチされる。LZ93D50 の PPU A12 への入力端子が L 固定なので、
ラッチしたレジスタの値が Charcter ROM A17:10 へ出力されることがない。
(そして charcter ROM 自体が存在しないのは自明だ)

2. BA-JUMP2 の基板には EEPROM は配置/配線されていない。
本来は I2C EEPROM を接続することを想定した端子に SRAM を例外的に
配線したという意味で、 I2C control と書いてある。


1. LZ93D50 internal registers latches CPU's writing operation to
$8004,$8005,$8006,$8007. LZ93D50's PPU A12 (pin22) fixed/wired L
level, it never output latched value to charcter ROM A17:10.
And this PCB is not placed charcter ROM device.

2. BA-JUMP2 PCB is not placed/wired EEPROM.
LZ93D50 pin 27 is supposed to be wired I2C device.
I have a description such as this because it was arranged SRAM
exceptionally this board.

LZ93D50 に関係のない話です。
MESS はいつも解析に使っているのでこの機会に etabeta さんに伝えたいこ
とがあります。hash/nes.xml で修正して欲しいことがあります。

Silva Saga (Jpn)
これは baddump がついていますが、 redump しても hash は同じでした。
原因を調べたら、 battery backup がないときに $6000-$7fff を 0x00 で
埋めると、 silva saga のプログラムのチェックサム検出を通過してしまう
ものの、ゲームの進行上は不正なデータとなります。
http://d.hatena.ne.jp/na6ko/20130909/p1
この領域の初期値を 0x00 で埋めなければ、正常な動作となります。
ですので、 baddump を外してください。


Dezaemon (Jpn)
PCB は NES-SLROM ではなく NES-SXROM とすべきです(本当は HVC-SXROM)。
hash は同じなので baddump は不要です。


----
This is a story not related to LZ93D50.
I offset uses analyzing Famicom games with MESS. I want you fix
hash/nes.xml


Silva Saga (Jpn)
This game is marked 'baddump', redumped image's has same by my
friend. I analyzed this game. When .sav file is not found, many
emulators fill data 0x00 as 'initialize' at address $6000-$7fff.
The program passed checksum at $6000-$7fff, but game is buggy.
http://d.hatena.ne.jp/na6ko/20130909/p1
If emulator is not fill 0x00 'initalized data', game works fine.
I want remove baddump flag.

Dezaemon (Jpn)
PCB is defined 'NES-SLROM'. This is wrong, database must be defined
as 'NES-SXROM'. (In fact, this is HVC-SXROM).
Its hash is same, I want remove baddump flag.

naruko's pinout of BA-JUMP2 shows the pin that was I2C SCL is now 6264 +CE. So writing to $800D should be necessary to drive I2C SCL high to talk to RAM.

thanks for the replies! I will look into them tonight (got some short deadlines at work)

@naruko: would you consider sending bootgod some snaps and info about those cart you verified? it would be good to share the confirmation with the NESdb

実は nescartdb への登録方法をしらないわたし。
市販品のファミコンカセット全てを持っている協力者はいても、わたしはソフトをそんなに持っていない...

I think you can ask directly to bootgod by email.
I doubt he has much time to work on his site (I haven't seen him around for a while), but I think he can setup up something for you

a last pair of question, this time related to Bandai Datach (that I'm currently implementing in MESS)
- I'm a bit confused about the subcarts with an EEPROM. when you write that SDA line is shared between the internal and the external EEPROM, do you mean that a write to $800d writes to both EEPROMs? or is it something else?
- Also, for the record, SD Gundam - Gundam Wars writes to the external I2C address at start... do you have a cart to see if there is anything connected or if it's just some remnant of the development with no effect in the released game?
- From heuristic observation of Battle Rush – Build Up Robot Tournament writes, I think the External I2C SCL goes in bit 3 of the written data at $8000-$8003 (actually the game seems to write to address $8004-$8007 as well...)


on the other subject (fix to nes.xml), when you have time could you share with me (even by PM) pics of the datach pcbs and, if you have them, of Silva Saga and Dezaemon pcbs? I love to document the precise label and markings inside the carts, if possible


finally, thanks a lot for the great docs (and I hope you get one day a Bandai Karaoke Studio too, because I was always curious about that subslot system!)

I²C is funny in that it requires specific behavior on both lines to start communication, so splitting either SCL or SDA would be sufficient to use talk to multiple EEPROMs without worrying about address conflicts. Since the X24C01 uses all the addresses, it can't coexist with anything... So a write to $800D will control the physical line that is SDA for both internal and external EEPROMs, but to persuade either the X24C01 or X24C02 the game is talking to it requires specifically a high-to-low transition of SDA no less than 4µs before the same transition of SCL.
As far as I can tell, because the PCB still connect PPU A12 to the LZ93D50P, it should require writing to all eight addresses, not just the first four.

Is that EEPROM (X24C01) actually I²C compliant? The address field of an I²C message is supposed to select a slave in a network, not an address in an EEPROM...I see some gain to proceed that way but that makes it pretty much a non-standard I²C device (contrast to a 24AA64, for instance)

_________________
((λ (x) (x x)) (λ (x) (x x)))

The X24C01 is technically not I²C because it's using the device address as the EEPROM address (and therefore responds to all 128 I²C addresses, precluding anything else from being on the same bus). But otherwise it's the same wire protocol.