I found a very well done Pokemon adaption from the GB to NES named:
Lei Dian Huang: Bi Ka Qiu Chuan Shuo
It's a chinese game with the mapper 163 and I would like to play it on real hardware. I couldn't find a matching donor cart for it, so I think it would make more sense to patch the rom to be compatible with MMC3.
I saw that some guys already had success in patching mapper from one to another (Loopy's SMB2j MMC3 patch or the VRC4 to MMC3 patch for Gradius2 for example
), so it shouldn't be impossible^^.
It would be very great to see if someone is interested.
Generally, asking people to do work for you won't get any results. You'd be better off learning how and doing it yourself. If you ask for help learning, you're sure to get better results.
First things first, learn a little bit of rom hacking basics. The Getting Started section on the romhacking.net forums has pointers to a lot of useful documentation. Then get some mapper documentation (I prefer Disch's) and learn about the mapper the cart currently uses and the mapper you want to port it too. Make sure the feature set is reasonably similar.
Next you'll have to do the conversion. Using a debugging emulator (or a disassembler, your choice), locate everywhere the game writes to the mapper registers. From there, reverse engineer the bank switching routine and replace it with a new one written for your target mapper.
First question: Is this one of those huge 2MB roms that won't possibly fit in the 512k max size of MMC3?
Dwedit wrote:
First question: Is this one of those huge 2MB roms that won't possibly fit in the 512k max size of MMC3?
I think you're right. In Soviet Russia, a little bird tells YOU that the .7z compressed file itself is bigger than 512 KiB. This means the game probably won't fit on a PowerPak or on an authentic MMC3 cart board.
@Dwedit:
yes it has 2mb prg and no chr, so i think it has vram (i think)
naaah... darn -.-
i hoped to be able to have a pokemon version for nes
but i have to face the reality:
if i want to have such a game, i have to make on my own, but noone will chop my head for askink xD
Is iNES mapper #163 some sort of expanded MMC3 ?
I see that the Chinese FF7 pirate also use that one, right ?
I was looking around the Internet for mapper information but I could not find anything yet ...
i read that mapper 163 is used to get bigger roms working (i think the mmc3 only supports up to 512kb per chip)
Here you go it may not be Yellow Pokemon buts it's Pokemon, hopefully its not globtop and you could possibly replace the chips with the version you want.
http://www.ebay.com/itm/Pokemon-Collect ... 222wt_1139
thx for the advice but i think the cart uses for sure some glop tops and i think it hasn't the right mapper. it's multicart so it has to be a mapper something around 150 or somewhere for multicarts
Oh, I have that cartridge
Here are some pictures of it:
http://www.elotrolado.net/hilo_hilo-ofi ... 1727723864
It uses both PRG-RAM and CHR-RAM
You aren't going to fit it on a MMC3 without a big recode for three reasons:
-Mapper 163 swaps the entire 8000-FFFF PRG-ROM block. The MMC3 is unable to do this.
-Mapper 163 can handle up to 2MB, whereas the MMC3 can only handle 512KB
-Mapper 163 can automatically swap the CHR-RAM on the middle of the screen (have a look at the VRAM on the intro screen where Pikachu appears, with FCEUX at scanline 0 and then at scanline 128) without intervention from the CPU.
But would a hack to a 6-bit version of mapper 34 (oversize BxROM) be feasible, apart from having to recode these games' title screens? One of my own projects uses that exact board. Mapper 163 appears not to be documented on our wiki; I get a whole bunch of irrelevant results related to a Namco audio chip.
Also probably needs protection schemes cracked. Some of those pirate games are a bitch to mess with.
Mapper 163 has an AP protection, but I have been partially disassembling the game and I haven't found any access to the AP register ($5300)
Here is the code from VirtuaNESex:
Code:
//////////////////////////////////////////////////////////////////////////
// Mapper163 NanJing Games (NES Chinese RPR game) //
//////////////////////////////////////////////////////////////////////////
void Mapper163::Reset()
{
reg[1] = 0xFF;
strobe = 1;
security = trigger = reg[0] = 0x00;
SetPROM_32K_Bank(15);
SetCRAM_8K_Bank(0);
}
BYTE Mapper163::ReadLow( WORD addr )
{
if((addr>=0x5000 && addr<0x6000))
{
switch (addr & 0x7700)
{
case 0x5100:
return security;
break;
case 0x5500:
if(trigger)
return security;
else
return 0;
break;
}
return 4;
}
else if( addr>=0x6000 ) {
return CPU_MEM_BANK[addr>>13][addr&0x1FFF];
}
return 0;
}
void Mapper163::WriteLow(WORD addr, BYTE data)
{
if((addr>=0x4020 && addr<0x6000))
{
if(addr==0x5101){
if(strobe && !data){
trigger ^= 1;
}
strobe = data;
}else if(addr==0x5100 && data==6){
SetPROM_32K_Bank(3);
}
else{
switch (addr & 0x7300)
{
case 0x5000:
reg[1]=data;
SetPROM_32K_Bank( (reg[1] & 0xF) | (reg[0] << 4) );
if(!(reg[1]&0x80)&&(nes->ppu->GetScanlineNo()<128))
SetCRAM_8K_Bank(0);
break;
case 0x5200:
reg[0]=data;
SetPROM_32K_Bank( (reg[1] & 0xF) | (reg[0] << 4) );
break;
case 0x5300:
security=data;
break;
}
}
}
else if( addr>=0x6000 ) {
CPU_MEM_BANK[addr>>13][addr&0x1FFF] = data;
}
}
void Mapper163::HSync(int scanline)
{
if( (reg[1]&0x80) && nes->ppu->IsDispON() ) {
if(scanline==127){
SetCRAM_4K_Bank(0, 1);
SetCRAM_4K_Bank(4, 1);
}
if(scanline==239){
SetCRAM_4K_Bank(0, 0);
SetCRAM_4K_Bank(4, 0);
}
}
}
void Mapper163::SaveState( LPBYTE p )
{
p[0] = reg[0];
p[1] = reg[1];
}
void Mapper163::LoadState( LPBYTE p )
{
reg[0] = p[0];
reg[1] = p[1];
}
I have the original cartridge and a NROM cartridge with EEPROMs, so if you want to do any test that runs from RAM swapping the cartridge to check the behaviour of the mapper, just ask.
Just someone pointed me to this thread, so bump. No need patch, when possible to make mapper. It's not that complicated.
Thanks 80sFREAK, for yet another empty message that implies that you know how to do things but doesn't provide any actual information. Why bump the thread if you're not going to provide any new information? Your message basically means "Hi, I'm awesome and I know how to replicate this mapper, but I'm not gonna tell you guys because you suck. Bye."... it doesn't help anyone!
80sFREAK wrote:
Just someone pointed me to this thread, so bump. No need patch, when possible to make mapper. It's not that complicated.
Both are viable. A patch would allow others to also more easily play this on better-available hardware. It would be more appropriate for someone who lacks experience making custom mappers. Building the mapper would allow playing the game unchanged, which might be more reliable and wouldn't need someone to do to the patching.
@tokumaru a bit weird way to ask for info, but i can accept it. Look, it's possible to make things, but motivation.
If you're going to implement the mapper using discrete logic, you're going to have a rough time designing the scanline counter. AFAIK it does not use the classic PPU A12.
Didn't see this before...
80sFREAK wrote:
@tokumaru a bit weird way to ask for info, but i can accept it.
Asking for info? I couldn't care less about a mapper used in a shitty pirate game. I simply despise the way you act, like you know more than everyone else without even providing some info to back you up or help other people.
Quote:
Look, it's possible to make things, but motivation.
I don't doubt you, I just think you brag too much and help too little.
socram8888 wrote:
If you're going to implement the mapper using discrete logic, you're going to have a rough time designing the scanline counter. AFAIK it does not use the classic PPU A12.
80'sFREAK can do anything with discrete logic.
INL might be right. I can think of at least six ways to wait for a split point in the background, and two of them are known to be used in NES or Famicom games using a discrete logic mapper.
These methods assume a fixed ratio of CPU cycles to scanlines.
- CPU cycle counting (used in VRC, FDS, and FME-7): If M2 rises 341 times, 3 scanlines have been drawn. This works on NTSC, RGB, and Dendy, but needs adjusted for PAL NES versions.
- DMC sample counting (used in Codemasters and the discrete mapper AOROM): Coarse approximation of CPU cycle counting, requires no mapper support, but automatic sample playback is not possible.
These methods count events that happen once per scanline.
- PA12 (used in MMC3 and RAMBO-1): If PA12 stays low for at least four M2 cycles and then goes high, sprite fetch has started. Imposes minor limits on 8x16 pixel sprite use.
- PA13 (used in MMC5): If PA13 stays low for at least three M2 cycles, the third nametable entry on the row is being fetched.
These methods watch which part of the background plane is being rendered.
- Tile FD/FE (used in MMC2 and MMC4): Watch PA13-4. Whenever the address changes to $0FD0-$0FEF or $1FD0-$1FEF, trigger a bank switch.
- Nametable page (used in the discrete mapper of Oeka Kids): If the high nibble of the PPU address (PA13-12) changes from anything else to 2, background fetch has begun. Read the CHR bank number from PA11-10.
Anyone willing to code a test ROM that runs from RAM with cassette swapping? Disabling rendering will instantly distinguish once-per-scanline and background following methods, and playing with 8x16 sprite patterns, scrolling, and CHR readback should distinguish the rest.
tepples wrote:
Tile FD/FE (used in MMC2 and MMC4): Watch PA13-4. Whenever the address changes to $0FD0-$0FEF or $1FD0-$1FEF, trigger a bank switch.
Briefly being pedantic, and without being able to verify against a copy of PunchOut!: I think they're paying attention to PPU A3 also (requiring it to be 1) and changing the latch on rising PPU /RD, rather than delaying after both pattern table fetches.
I'm pretty certain the easiest discrete logic scanline interrupt source would be to use the MMC3-style A12 counting with a large binary counter (e.g. 74'4040). Downsides are that it would only be configurable to produce an interrupt after one fixed 2ⁿ scanlines without a lot more logic, and you need a separate latch bit to serve as acknowledge+disable interrupts.
lidnariq wrote:
tepples wrote:
Tile FD/FE (used in MMC2 and MMC4): Watch PA13-4. Whenever the address changes to $0FD0-$0FEF or $1FD0-$1FEF, trigger a bank switch.
Briefly being pedantic, and without being able to verify against a copy of PunchOut!: I think they're paying attention to PPU A3 also (requiring it to be 1) and changing the latch on rising PPU /RD, rather than delaying after both pattern table fetches.
I believe you're correct about the watching PPU A3 = 1 for second PT byte fetch. Although MMC2 has the entire PPU address bus as inputs, not sure if it's actually using A2-A0 though... (I recall some discussion that the patent docs may have gave reason why it was included in the design but then dropped.) MMC4 only has A13-A3, which is what you need.
For what it's worth I've have issues using the Rising edge of CHR /RD because PPU A12 didn't always happen to be valid at that point depending upon how fast your logic is. I had some glitching using CHR /RD rising edge alone. I ended up latching the address bits on the falling edge which is when they're actually supposed to be valid, and then bankswitching at the rising edge. I haven't taken the time to verify that's how the actual MMC2/4 works, but that's what I had to do to get it to work
I have this cart, and I have a NROM cart with EEPROMs. I don't mind running a test program on my console.
I think it can't be a CPU-based counter, because this is designed to run on NTSC consoles, yet it works well on every PAL console I have. I know it's technically possible to make a code able to detect and run on both frequencies, but being a card made by some chinese guys (with very good programmers, tough, because it is quite neat for a bootleg) to play on crappy famiclones with PAL, NTSC, PAL60... speeds, I think it's unlikely.
AFAIK the CHR-swap is only used on the title screen to display that big Pikachu, and not in-game. It should be possible to modify a bit the title screen to make it simple enough not to need to swap banks.
socram8888 wrote:
It should be possible to modify a bit the title screen to make it simple enough not to need to swap banks.
That or just do the swap manually with sprite 0.