Mapper 163 in a Cpld. Question about the Nes signals.
Moderator: Moderators
Mapper 163 in a Cpld. Question about the Nes signals.
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.
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.
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: Mapper 163 in a Cpld. Question about the Nes signals.
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".
Re: Mapper 163 in a Cpld. Question about the Nes signals.
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.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".
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.
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: Mapper 163 in a Cpld. Question about the Nes signals.
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.
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.
Re: Mapper 163 in a Cpld. Question about the Nes signals.
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:
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:
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.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.
Re: Mapper 163 in a Cpld. Question about the Nes signals.
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:
The security part is wrong and I need to do a mask with 0x7300 in some cases. But for the intro it works.
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;
Last edited by bitmask on Thu Dec 23, 2021 3:20 pm, edited 2 times in total.
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: Mapper 163 in a Cpld. Question about the Nes signals.
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.
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.
Re: Mapper 163 in a Cpld. Question about the Nes signals.
It worked!!! Thanks. (code below).
Now the bottom half is being displayed correctly. I was ready to implement a scanline counter
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.
Now the bottom half is being displayed correctly. I was ready to implement a scanline counter
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;
Re: Mapper 163 in a Cpld. Question about the Nes signals.
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
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
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: Mapper 163 in a Cpld. Question about the Nes signals.
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.
Re: Mapper 163 in a Cpld. Question about the Nes signals.
By directly latching PPU_A[9], I released about 25 MC/LE/LUT(s)
Re: Mapper 163 in a Cpld. Question about the Nes signals.
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
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
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: Mapper 163 in a Cpld. Question about the Nes signals.
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.
Re: Mapper 163 in a Cpld. Question about the Nes signals.
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.