Mapper 163 in a Cpld. Question about the Nes signals.

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
bitmask
Posts: 9
Joined: Thu Dec 23, 2021 8:48 am

Mapper 163 in a Cpld. Question about the Nes signals.

Post by bitmask »

Hi, I'm trying to implement the mapper 163 using a Cpld, but I'm struggling to make it work. The page below has the mapper description.

https://wiki.nesdev.org/w/index.php/INES_Mapper_163

I have some questions about the Nes signals and when we can detect a read or a write to ranges $0000-7fff and $8000-ffff. The page below has some details about the pins:

https://wiki.nesdev.org/w/index.php/Cartridge_connector

In this mapper I have to latch some registers when there are writes to the range $5xxx.

My first try was the latch in the rising edge of M2, and when R/W (PRG_RW) is 0 (a write) and ROMSEL (PRG_CE) is 1 (not in $8000-ffff).
But it doesn't work. By the documentation, when M2 is 1 it means the signals are stable, so it seemed the right place to do the detection.

After that I tried the falling edge of R/W and checking if ROMSEL=1. Also doesn't work and actually seems wrong because by my understanding the R/W changes when M2 is low, so the signals are unstable and probably is not the right place to latch the data bus.

ROMSEL=0 can be use to drive the PRG's CE, but I think ROMSEL=1 has not direct relation with a read or write to $0000-7fff because it's a NAND of M2 with A15, so ROMSEL can be 1 but M2 can be 0 at the same time, meaning it's not a read or write.

In the Snes we have individual pins for CE, OE and WR, but with Nes we have only one pin for OE and WR (R/W) and ROMSEL is not like a CE in the Snes, because it's Nand of M2 with A15, so the problem is how to interpret the signals in the range $0000-7fff.

For now I'm trying to finish the PRG side. The CHR side I'll implement later, and for now I only did some simple connections. I'm testing with the Final Fantasy 7 game, and when the game starts we can hear the main theme and see the intro graphics. So right now I want to finish the PRG side to hear the main theme and see some garbage on the screen, but right now I'm facing only a black screen.
I'm using an emulator (Mesen) the change the code and see what happens, to help the debugging. The mapper 163 has some registers that seems to be related with security, but after removing these registers from the logic the game keeps running (at least the intro), so I think the problem I'm facing is related to the PRG signals I described above.

Someone can help me?

Thanks.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: Mapper 163 in a Cpld. Question about the Nes signals.

Post by NewRisingSun »

Mapper 163 has recently been better understood. Only NintendulatorNRS and libretro-fceumm emulate the mapper correctly at this time; Mesen does not. Be also sure to use a ROM image not listed in the NES 2.0 Header XML Database as a "bad dump".
bitmask
Posts: 9
Joined: Thu Dec 23, 2021 8:48 am

Re: Mapper 163 in a Cpld. Question about the Nes signals.

Post by bitmask »

NewRisingSun wrote: Thu Dec 23, 2021 12:04 pm Mapper 163 has recently been better understood. Only NintendulatorNRS and libretro-fceumm emulate the mapper correctly at this time; Mesen does not. Be also sure to use a ROM image not listed in the NES 2.0 Header XML Database as a "bad dump".
Hi, yes, I'm using the code of some emulators to understand this mapper. I'm using Mesen because I was able to compile it to do the changes and it runs Final Fantasy 7, so it's implementation is similar to other emulators and enough to run this game.

And the question about the signals is not particular to this mapper. Seems that other mappers like MMC1 and MMC3 have registers in the $8000-ffff range, so in this case the ROMSEL is enough, but in the range $0000-7fff the ROMSEL is not enough.
Last edited by bitmask on Thu Dec 23, 2021 1:14 pm, edited 1 time in total.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: Mapper 163 in a Cpld. Question about the Nes signals.

Post by NewRisingSun »

My point about the choice of emulators was that you should study correct rather than incorrect implementations of the mapper.

As for signal timing, please have a look at this circuit that adds PRG-RAM at $6000-$7FFF to a circuit board that previously did not have it. Once you have solved the /ROMSEL delay issues described therein, decoding $5000-$5FFF rather than $6000-$7FFF then becomes a simple matter of applying a different address mask.
bitmask
Posts: 9
Joined: Thu Dec 23, 2021 8:48 am

Re: Mapper 163 in a Cpld. Question about the Nes signals.

Post by bitmask »

Thanks for the link. I'll check this 33ns delay, but I think it's not the cause for this specific issue. And driving the CE for the PRG-RAM is simpler because we only need to check for addresses in the range $6000-7fff and M2=1.
But when we need to latch a register we need to chose the correct rising or falling edge of one of the pins.

But this page has the following line:
If you latch data/address on the falling edge of M2 of writes to $4020-$7FFF, you don't need to worry about this delay because /ROMSEL still has the correct logic level at this point.
This seems to be a good try. It eliminates this delays issues, but logically I think it's still the same thing compared to the rising edge. Let me try.
bitmask
Posts: 9
Joined: Thu Dec 23, 2021 8:48 am

Re: Mapper 163 in a Cpld. Question about the Nes signals.

Post by bitmask »

It worked. I did the latch on the falling edge of M2 and checked for WR=0 and ROMSEL=1 (check the code below).

It showed only the Final Fantasy 7 intro. But there is no sound! I don't know why, because the graphics are being displayed and I can choose the two options in the main screen with the controller. It means that the Rom is fully accessible. Wait, maybe there is some bank issue, where it can fetch the intro data but not the sound data? But at least there is something being displayed, so I can advance in the project.
For now only the top half of the intro is being displayed correctly. The bottom half has garbage because the mapper needs the change the CHR bank at scanline 127, and I still need to implement that. But what I did on the CHR side was enough to display the top half correctly.

The next step is to fix this sound issue, the security registers and add this scanline counter. This scanline counter seems to be the hard part. I found some information and seems that three consecutive reads to the same address marks the beginning of a new scanline, or something like that.

The code that worked is:

Code: Select all

	
cpuwrite: process( CHR_ADDRESS, CHR_DATA, PRG_ADDRESS, PRG_DATA, internal_prg_address, PRG_RW, PRG_CE, M2, internal)
	begin
		if (falling_edge(M2)) then
			if PRG_RW = '0' and PRG_CE = '1' then
				
				if internal_prg_address = x"5100" and CHR_DATA = x"06" then
					m163_prg_bank <= x"03";
					
				elsif internal_prg_address = x"5101" then
					if m163_reg /= x"00" then
						m163_trigger <= not m163_trigger;
					end if;
					
					m163_reg <= PRG_DATA;
				
				elsif internal_prg_address = x"5000" then
					m163_prg_bank(3 downto 0) <= PRG_DATA(3 downto 0);
				
				elsif internal_prg_address = x"5200" then
					m163_prg_bank(5 downto 4) <= PRG_DATA(1 downto 0);
					
				elsif internal_prg_address = x"5300" then
					m163_security <= PRG_DATA;
					
				end if;
			end if;
		end if;
	end process;
The security part is wrong and I need to do a mask with 0x7300 in some cases. But for the intro it works.
Last edited by bitmask on Thu Dec 23, 2021 3:20 pm, edited 2 times in total.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: Mapper 163 in a Cpld. Question about the Nes signals.

Post by NewRisingSun »

The mapper has no scanline counter, and you should not implement one. FCEUX seems to implement it as a scanline counter because its mapper interface does not directly allow trapping address changes reliably, but real hardware does no such thing. This is why I insist so heavily on applying a proper description of a mapper, not some outdated emulator implementation of it.

The wiki very simply says how to implement the CHR switch: latch PPU A9 on a rising edge of PPU A13, and replace CHR A12 with the latched value.
bitmask
Posts: 9
Joined: Thu Dec 23, 2021 8:48 am

Re: Mapper 163 in a Cpld. Question about the Nes signals.

Post by bitmask »

It worked!!! Thanks. (code below).
Now the bottom half is being displayed correctly. I was ready to implement a scanline counter :P
I read some posts about the MMC5 where seems that a scanline counter is needed so I thought I'd need to detect scanline 127 by counting.

Now I'll look for this audio problem. Something is still missing.

Code: Select all

	CHR_MAPPER_ADDRESS(3) <= CHR_ADDRESS(13);
	CHR_MAPPER_ADDRESS(2) <= chr_a9_latched when (chr_switch = '1') else CHR_ADDRESS(12);
	CHR_MAPPER_ADDRESS(1 downto 0) <= CHR_ADDRESS(11 downto 10);

	chrbank: process( CHR_DATA, CHR_ADDRESS, chr_switch )
	begin
		if (rising_edge(CHR_ADDRESS(13))) then
			chr_a9_latched <= CHR_ADDRESS(9);
		end if;		
	end process;
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: Mapper 163 in a Cpld. Question about the Nes signals.

Post by aquasnake »

Some mapper163 games need to monitor the scanline counter to automatically switch the Chr bank, and the mmc5 level scanline counter mechanism is required. In addition, some games will have copy protection, which can be verified by reading $5100 and $5500, and I think this part of the logic is relatively obscure



Adding these two parts of logic implementation will improve the emulation degree of mapper163 to more than 95%, but the number of macro cells of CPLD can easily exceed 120. If these two parts are not implemented, it can be implemented within 72 macro cells. As to FF7, you will see the broken opening screen
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: Mapper 163 in a Cpld. Question about the Nes signals.

Post by NewRisingSun »

Again, mapper 163 does not and never had a scanline counter, and certainly not one that follows the MMC5 method of scanline detection; it would be insane to implement such a thing. FCEUX just implemented one in lieu of more accurate hardware emulation.
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: Mapper 163 in a Cpld. Question about the Nes signals.

Post by aquasnake »

By directly latching PPU_A[9], I released about 25 MC/LE/LUT(s)
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: Mapper 163 in a Cpld. Question about the Nes signals.

Post by aquasnake »

Several games with strict PPU scanline timing were tested:

Hu Lu Jin Gang(NJ039)
San Guo Zhi - CaoCao Zhuan(NJ018)
San Guo Zhi - Lv Bu Zhuan(NJ040)
San Guo Zhi - Liu Bei Zhuan(NJ083)


The method based on PPU address line latch has more graphic glitches, while the other which based on scanline detection is more stable.

The latter is recommended

Although the emulation of fceux is not as same as the actual cart, it has stronger compatibility than other emulators, especially for mapper163 family
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: Mapper 163 in a Cpld. Question about the Nes signals.

Post by NewRisingSun »

Then you are not implementing the address line latch properly. I don't see any glitches in those games with it. As far as FCEUX' mapper 163 emulation is concerned, it does not even implement the bit swap properly. As far as I know, only libretro-fceumm and NintendulatorNRS have proper mapper 163 compatibility.
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: Mapper 163 in a Cpld. Question about the Nes signals.

Post by aquasnake »

I just apply these two different implementation to my hardware CPLD flashcart, which is not convincing. I need someone else's test data on the physical development cart.
Post Reply