mapper19 と Namcot 129, 163, 175, 340

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...

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.

I'd say that your summary is, with the specificity that "CHR-ROM to PPU RAM" means specifically "as pattern tables"

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.

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.

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.

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)...



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...

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

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

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

解析していた当時の彼の twitter の発言の URL を貼っておきます。
http://twilog.org/makimura_mfg/month-1104

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?

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

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

漢字

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 機能は実在する可能性はあるんですよね....