mapper19 と Namcot 129, 163, 175, 340

Japanese-language board. ファミコン向けの日本語のフォーラム

Moderator: Moderators

Post Reply
User avatar
naruko
Posts: 66
Joined: Mon Feb 09, 2009 9:10 am
Location: リムルダール Rimuldar
Contact:

mapper19 と Namcot 129, 163, 175, 340

Post by naruko »

163 に flash memory をつないだり、実機で動かしてみました。いままでの資料に記載されていないレジスタの情報などをまとめてテキストファイルにしておきました。

http://unagi.sourceforge.jp/cgi-bin/hik ... ot_163.txt
http://unagi.sourceforge.jp/cgi-bin/hik ... 75_340.txt

本当は英語で記載したかったのですが、気力が足りなかったので日本語のところに書いてみました。また、NesCartDb さんの情報には大変お世話になりました。ありがとうございます。
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Post by Banshaku »

新しいの情報をありがとうございました。時間あれば翻訳したいけど、私の日本語がまだ良くないです。

新しいの情報が分けたがどうか知りたいです。 

よろしくお願い致します。
User avatar
naruko
Posts: 66
Joined: Mon Feb 09, 2009 9:10 am
Location: リムルダール Rimuldar
Contact:

Post by naruko »

文書を更新しました�RAM CS# 端子の接続と $e000 の挙動から、スプラッターハウスやワギャンランドを 340 としました。 ただしこれは採番の観点から考えると矛盾しています。

スターウォーズの 129 の基板の写真を掲載しておきます。(thanks Yoshida)
音源機能はありますが、 163 とはすこし違いました。
Image
Image

Banshakuさん
新しいの情報が分けたがどうか知りたいです。 
日本語が伝わらないので英語で書いてもらえますか。(ただし返答は日本語にします)
etabeta
Posts: 109
Joined: Wed Nov 29, 2006 10:11 am
Location: Trieste, Italy

Re: mapper19 と Namcot 129, 163, 175, 340

Post by etabeta »

sorry to bump this old thread, but I'd like to update MESS to properly emulate these Namco boards too and I'd like to have a few confirmations

Namcot 175:
- can map only CHR-ROM to PPU RAM by writing at $8000-$bfff
- no mirroring control
- WRAM protect bit at $c000-$c7ff
- no additional sound

Namcot 340:
- can map only CHR-ROM to PPU RAM by writing at $8000-$bfff
- mirroring control to map CIRAM to PPU nametable at $e000-$e7ff
- no WRAM in any known cart (so unclear if there is any enable bit)
- no additional sound

Namcot 129/163
- can map either CHR-ROM or CIRAM to PPU RAM by writing at $8000-$bfff
- mirroring control to map either CIRAM or CHR-ROM to PPU nametable at $c000-$dfff
- WRAM protect bits at $f800-$ffff
- additional sound

is the above correct?

If so, I'd have a couple of questions about Namcot-163.

1. is there any game which actually uses CIRAM as PPU RAM?
I'd like to have a test case to see if I'm emulating it correctly

2. docs are not 100% clear about $f800 reg. it seems to work both as External RAM protect *and* for sound address... but when is it used for one and when for the other? does the effect depend on bit4 or on something else? or is it always used for both?

at the moment, I won't emulate the sound capabilities (I'm not really a sound guy, so I'll ask help to some other MAMEdev for that), but I'd like to have CIRAM and WRAM correct before that :)

thanks

EDIT: replaced spurious occurrence of CHR-RAM with CHR-ROM...
Last edited by etabeta on Wed Apr 17, 2013 7:20 am, edited 1 time in total.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: mapper19 と Namcot 129, 163, 175, 340

Post by lidnariq »

I helped BootGod modify his CopyNES so that he could verify everything I'd transcribed from naruko's notes; he said he agrees with the behavior I've transcribed on the wiki.

With one bonus: Masamune is weird. The four epoxy blob version of Masamune is bizarre in a completely inscrutable way that we couldn't figure out. If the smallest epoxy blob is destroyed or disabled, the cartridge seems to act like a perfectly normal N163 cartridge. If the smallest epoxy blob is functional, writes to internal RAM must first be written to $6000, and then the write to $4800 uses the value that had been written to $6000. Reads act as normal regardless. However: the game seems to work perfectly fine regardless of whether the behavior is proper N163 or this bizarro-land variant.
etabeta wrote:is the above correct?
I'd say that your summary is, with the specificity that "CHR-ROM to PPU RAM" means specifically "as pattern tables"
etabeta wrote:1. is there any game which actually uses CIRAM as PPU RAM?
I'd like to have a test case to see if I'm emulating it correctly
Naruko and BootGod both verified the behavior, but couldn't find a specific game that relied on it. Disch claims that specific games exist that rely on this behavior, but doesn't provide a name.
etabeta wrote:2. docs are not 100% clear about $f800 reg. it seems to work both as External RAM protect *and* for sound address... but when is it used for one and when for the other? does the effect depend on bit4 or on something else? or is it always used for both?
It is always both. So there's some hilarious dances in (i think?) e.g. King of Kings to update music registers at the same time as it keeps PRG-RAM writeable.

I don't know whether there's actually two separate registers inside, but it looks like that should be academic: if the register is shared, when the auto-increment bit is set, PRG-RAM is write-protected.
at the moment, I won't emulate the sound capabilities (I'm not really a sound guy, so I'll ask help to some other MAMEdev for that), but I'd like to have CIRAM and WRAM correct before that :)
The N163 natively generates samples at 119kHz always, and rotates between all the channels. A good resampler should be the only hard part about it.
etabeta
Posts: 109
Joined: Wed Nov 29, 2006 10:11 am
Location: Trieste, Italy

Re: mapper19 と Namcot 129, 163, 175, 340

Post by etabeta »

thanks a lot for the replies, it all makes sense now (for what an epoxy block can make sense ;) ).

a small question, to be sure I'm not starting from wrong assumptions about 163 CHR banks usage (it happens often to me, but usually I find test cases which prove me wrong, while here there seems to be no usage of this feature, so I prefer to ask): the documented behavior is that when these accesses occur the NES CIRAM is used as VRAM (i.e. PPU $0-$1fff) instead of being used as NT (i.e. PPU $2000-$2fff), right? because some (old) docs talk about CHR-RAM but no on-cart VRAM chips is present (based on bootgod descriptions)...
lidnariq wrote:
at the moment, I won't emulate the sound capabilities (I'm not really a sound guy, so I'll ask help to some other MAMEdev for that), but I'd like to have CIRAM and WRAM correct before that :)
The N163 natively generates samples at 119kHz always, and rotates between all the channels. A good resampler should be the only hard part about it.
yup, but I'm not familiar with the internals of sound emulation in MAME/MESS. it took me a few minutes to add sound to Sunsoft5B and VRC6, because the base chips were already emulated and I only needed to take care of their registers. but in this case, I need to understand e.g. how to hook up the resampler to the rest of the code :)
given that I still have many more simpler things to implement, I think this will be postponed to a later stage...
User avatar
naruko
Posts: 66
Joined: Mon Feb 09, 2009 9:10 am
Location: リムルダール Rimuldar
Contact:

Re: mapper19 と Namcot 129, 163, 175, 340

Post by naruko »

質問の回答ではないのですが、紹介したいことがあります。

Namco の IC の調査はハードウェアの解析は私が行いましたが、外部 WorkRAM の write protect の調査は牧村さんが行いました。 彼は 163 のレジスタ全てを総当たりで書き込んで、 write protect がどこか調べるプログラムを自作しました。

現在はテストプログラムは削除されていますが、彼の調査が非常に大きな事でした。

解析していた当時の彼の twitter の発言の URL を貼っておきます。
http://twilog.org/makimura_mfg/month-1104
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: mapper19 と Namcot 129, 163, 175, 340

Post by lidnariq »

etabeta wrote:a small question, to be sure I'm not starting from wrong assumptions about 163 CHR banks usage (it happens often to me, but usually I find test cases which prove me wrong, while here there seems to be no usage of this feature, so I prefer to ask): the documented behavior is that when these accesses occur the NES CIRAM is used as VRAM (i.e. PPU $0-$1fff) instead of being used as NT (i.e. PPU $2000-$2fff), right? because some (old) docs talk about CHR-RAM but no on-cart VRAM chips is present (based on bootgod descriptions)...
Yes, there's no separate CHR-RAM.

The VRAM can be mapped to both nametables and pattern tables at the same time—it just has the ability to map any of the bottom 256KiB of CHRROM or the 2KiB RAM on the mainboard into any of the twelve bottommost 1KiB slices of the PPU's address space. (Modulo the bit about ROM nametables can only only come from the bottom 224KiB of CHRROM) But I agree that it seems likely the games either use 1 screen mirroring and use the other KiB like TQROM, or maybe use ROM nametables.

For what it's worth, I think I found some ROM nametables in Battle Fleet (about half of the last 32KiB of the 128KiB CHRROM), and the last 6KiB of Megami Tensei 2's 256KiB CHR looks like non-tile data—so maybe this is a game to investigate for using RAM-as-pattern table?
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: mapper19 と Namcot 129, 163, 175, 340

Post by tepples »

I see one good reason to use the TQROM configuration in a video game made only for Japan.

(Google)
私はビデオゲームでTQROM構成を使用するには、一つの良い理由は、日本のためにのみ作られたを参照してください。

漢字
User avatar
naruko
Posts: 66
Joined: Mon Feb 09, 2009 9:10 am
Location: リムルダール Rimuldar
Contact:

Re: mapper19 と Namcot 129, 163, 175, 340

Post by naruko »

TQROM はカートリッジに Chracter RAM と Charcter ROM が併存していて PPU address 0x0000-0x1fff に配置できるみたいですね。
163 の場合は Charcter RAM として使う場合は本体の VRAM を 0x0000-0x1fff に配置できる配線ではあることは確認してます。カートリッジの中にキャラクタRAMはありませんし、PPU /WR の線が未使用です。

女神転生II (DDS2) の Program ROM の中に Charcter data が入っていると牧村さんが言及していたので、Charcter RAM 機能は実在する可能性はあるんですよね....
Post Reply