nesdev.org

That or Bootgod's database, or even the board table that Tennessee CV used to maintain.

tokumaru wrote: If the game used a simpler discrete logic mapper (such as CNROM or UNROM), it would be possible to build it from standard logic chips you can buy anywhere, but the connector would still be an issue.

How about changing the game Mapper? If I can convert MMC3 to UNROM, is there any change to use a UNROM board?

I want change Mapper 4 (MMC3/TLROM) to Mapper 2 (UNROM)

I choose Mapper 2 (UNROM) because I have its board. Also there is a good tutorial for UNROM reproduction here :
http://www.nintendoage.com/forum/messag ... adid=28034

What I need to know for Mapper conversion, specially Mapper 4 to 2

What is the relation between PCB Class and Mappers?

FARID wrote:I want change Mapper 4 (MMC3/TLROM) to Mapper 2 (UNROM)

That would require reprogramming most of the game.

FARID wrote:I want change Mapper 4 (MMC3/TLROM) to Mapper 2 (UNROM)

Well, it doesn't really work like that. Mapper conversion is something you consider when the mappers involved are similar and share common features, or when the mapper you are converting to is a superset (it has all the features and more) of the mapper you are converting from.

UNROM however lacks most of the features an MMC3 has, and if the game uses the MMC3 it most likely does make use of such features. There's just no way you can make this conversion, unless you completely reprogram the game, like tepples said. And even then there might be some things that couldn't be done without the MMC3.

tokumaru wrote:

FARID wrote:I want change Mapper 4 (MMC3/TLROM) to Mapper 2 (UNROM)

Well, it doesn't really work like that. Mapper conversion is something you consider when the mappers involved are similar and share common features, or when the mapper you are converting to is a superset (it has all the features and more) of the mapper you are converting from.

UNROM however lacks most of the features an MMC3 has, and if the game uses the MMC3 it most likely does make use of such features. There's just no way you can make this conversion, unless you completely reprogram the game, like tepples said. And even then there might be some things that couldn't be done without the MMC3.

I am ready to reprogram this game offset by offset. just tell me where I have to start.

What game is it, and why does it need to become UNROM? MMC3 donor cartridges aren't that rare.

Hacking Arabic-translated Kunio-kun games to be UNROM or MMC1 is out of the question. They are dependent on features of MMC3 such as CHR-ROM being quickly switchable, the scanline counter, the 8k bankswitching size, etc. You might be able to change it to a more capable mapper, like FME7, VRC6, MMC5, etc, but not to anything less capable.

FARID wrote:I am ready to reprogram this game offset by offset. just tell me where I have to start.

I don't know what you mean by "offset by offset", but maybe you didn't understand what I meant by "reprogram the whole game" either.

Like Dwedit said, the game program was written to take advantage of the MMC3 features: 8KB bank size, fast CHR-ROM bankswitching, scanline counter, etc. There is no possible that this same program will run on a cart that doesn't have any of those features (UNROM), no matter how much you hack it.

To make this game run on an UNROM cart you'd have to make a new game similar to the original one as much as possible. And you're of course not going to do that.

It's pretty much the same as converting a Gameboy game to the NES, it can't be done, you have to make a new game.

tokumaru wrote:To make this game run on an UNROM cart you'd have to make a new game similar to the original one as much as possible. And you're of course not going to do that.

On the other hand, compare the conversion of Contra (魂斗羅) to UNROM for North American release. But then Konami had it easy, with full source code and all.

It's pretty much the same as converting a Gameboy game to the NES, it can't be done, you have to make a new game.

Game Boy to NES (or vice versa in the case of Super Mario Bros. Deluxe) is a bit harder, as you actually would have to rewrite the whole thing, not just disassemble, document, make some architectural refactoring, and reassemble. For example, Game Boy has an 8080-family CPU while NES has a 6502. Game Boy prefers updates in hblank, while NES prefers them in vblank.

US and Japanese Contra came out at about the same time.

tepples wrote:On the other hand, compare the conversion of Contra (魂斗羅) to UNROM for North American release. But then Konami had it easy, with full source code and all.

It really depends on what mapper features are used. If an MMC3 game doesn't use the scanline counter and doesn't require lots of CHR-ROM bankswitching, it might convert somewhat easily to UNROM. That's hardly the case though, most MMC3 games I'm aware of make full use of the hardware.

tokumaru wrote: I don't know what you mean by "offset by offset", but maybe you didn't understand what I meant by "reprogram the whole game" either.

As far as I had learned, assembly is a very powerful language. It is possible to do everything with it. But unfortunately it is very complex and changing the source code is very time consuming. For example adding one byte is enough to mess up the whole game. Because of this matter hackers usually use DTE instead of expanding ROM to insert more text in the game.

I guess I have to change everything like adding more bytes in some places, changing the pointers and doing some other things that I don't know.

So my question is what are the steps for this project?
I know fully learning and understanding assembly language is an important step. But I want to know what the other steps are.
Please introduce me some resources.
I want to give it a try even if it seems impossible.

FARID wrote:I want to give it a try even if it seems impossible.

It doesn't seem impossible, it IS impossible and nobody who knows anything about NES programming will tell you differently.

If a very good programmer decided to try this, he could maybe even get a playable game, but there would be several things missing or broken, because they simply can't be translated to UNROM.

If everything was possible with any mapper, like you seem to believe, there would be only one mapper, don't you agree? Why would they invent a new ones? The truth is mappers were invented to do things that weren't possible before, and the MMC3 does things that simply can't be simulated by older mappers, that's the truth.

As frustrating as it may seem, if you want to see this game running on hardware you will have to buy an MMC3 cart. Is that really so hard in your country? The MMC3 was used in so many games that in the US and in Japan you can buy carts with it for less than a dollar.

Honestly, it would be much, much easier to modify a glob top cartridge than convert the game to UNROM.

tokumaru wrote:If everything was possible with any mapper, like you seem to believe, there would be only one mapper, don't you agree? Why would they invent a new ones?

Except for Rare and Codemasters, which routinely pushed discrete mappers to their limits. But I wouldn't recommend trying a complex mapper hack like this until you have a finished game under your belt.

tepples wrote:Except for Rare and Codemasters, which routinely pushed discrete mappers to their limits.

Yeah, but that's part of the point... If you design a game for the discrete mappers from the beginning you can do a lot, which is why a game similar to this soccer game can probably be coded from the ground up for UNROM, but a game engineered for the MMC3 is a completely different story.

FARID wrote: So my question is what are the steps for this project?
I know fully learning and understanding assembly language is an important step. But I want to know what the other steps are.
Please introduce me some resources.
I want to give it a try even if it seems impossible.

A notable difference is that UNROM provides no IRQ, while MMC3 does. So for example with MMC3 the game might tell the IRQ to trigger at line 200 (out of the 240 on screen, 262 in total). The IRQ code would run automatically at that time. Without an IRQ, the CPU will have to wait for precisely that time. This affects the timing a lot for the obvious reason (CPU usage), but also because you'll use the NMI interrupt to base the timing, and the game needs to use that also (for vblank). Using the sprite #0 hit helps out here, but it also involves having the CPU wait and you only get 1 screen location, where MMC3 can be re-used and trigger on any scanline. The DPCM IRQ trick demonstrated recently might be helpful.

But the scanline IRQ (and what Dwedit said, except it was Persian) brings up another problem that does make it impossible with UNROM. UNROM has 8kB of CHR-RAM, and I believe this game uses CHR-ROM. The MMC3 will trigger an IRQ at a certain line, then it will use the mapper to change the graphic bank instantly. With CHR-RAM, you have to load it yourself (at 6 CPU cycles per byte, at the absolute fastest). You can pre-load things to an extent, but if the needs it banked a certain way, or uses more than 8kB of CHR, with UNROM there's nothing that can be done without constantly stopping the game.

MMC3 is very common mapper, even pirate carts have many clones of it. One of them is labeled AX5202P, I've found that even those can be ordered from places in China, but the ones I got have a defect rate to make them useless.