recommended mapper

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
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

recommended mapper

Post by tokumaru »

What mapper would you recommend?
I was just reading the docs and the BANDAI mapper (mapper 16) looks great! It is really simple, lets you swap small chunks of VROM, has IRQ's... I just fell in love with the thing! But I guess it isn't one of the most populars, right? I think FCEUltra doesn't even support it, does it?

What should I have in mind when choosing a mapper? Unfortunately I have no way of testing my programs/demos/games on the real hardware, so I shouldn't worry about having a cartrige with the same mapper. Or should I, on the remote possibility of getting my program/game/demo ever placed on the real thing?

I'd like to choose a simple mapper, but the simpler ones only swap BIG chunks of VROM, and my programs really need small swaps. And I'm not in the mood of replicating data and making lots of 8k chunks to simulate small swaps, and end up with a huge rom. Or using VRAM, what would be very sloooow...

Well, what have you guys been using lately?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

Also loved Mapper 68 (Sunsoft Mapper #4). Very simple, precise information, mirroring selection... VROM chunks are a little bigger, but I could live with that.
Firebug's document on NES mappers has a lot of holes in it. Most of the mappers don't have precise information on the mirroring selection registers... that makes it difficult to pick an appropriate mapper.
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Post by Quietust »

If you want a mapper you can easily obtain, the most obvious choice would be the MMC3.
In my opinion, you SHOULD get your program/game/demo to work on the real thing. There are plenty of people here with devcarts that can test it for you; if someone isn't available for whatever reason, most of the current 'good' NES emulators behave closely enough to the real thing (especially Nintendulator, which was designed for this sole purpose) to give you a general idea of whether it will work or not.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

Yeah, MMC3 seems great... but Firebug's document fails to explain a simple feature of it: it says $A000 controls mirroring, but he "has no confidence in the accuracy of this information". Could you please explain how it works?
User avatar
Disch
Posts: 1848
Joined: Wed Nov 10, 2004 6:47 pm

Post by Disch »

User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

It is indeed a very good doc. I wouldn't call it "only", though... I think the avaliable docs complete each other. This one explains the scanline IRQ quite well.

I got so excited (since I was actually understanding what was written!) that I decided to play a little with some games that use the mapper. I looked at the code of a couple of games (kirby, megaman 5) and changed it a little to get the game do what I wanted, and now I think I understand how everything works quite well, I guess I'm ready to use it.

Thank you for the tip, Disch!

PS: This mapper really is easy to obtain... so many games use it! I even got a couple of carts at home that use it (not that it will help me with my dev'ing or anything).
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

Ok, i did a couple of tests today and got the page swaping working beautifully. But totally screwed myself with the IRQ scanline counter. Could anyone explain to me how it works?
This is what I did:

At the end of NMI:
1. write the line number to $C000;
2. write to $C001;
3. write to $E001;
4. enable IRQs (CLI) (wasn't disabled, but... could that be the problem? I changed it in all ways I could possibly think of)
5. clear the color emphasis bit I'm going to set later;

At IRQ adress:
1. write to $E000;
2. set a color emphasis bit;

But the whole screen gets the fu**ing bit set! Then I tried to not only set the bit in the IRQ, but also clear it right after. Then I could see That it gets set and cleared many times in 1 single frame. Why are these routines being called more then 1 time per frame?

What I'm doing should work! It's simple: during vblank (NMI) I set the timer. In the IRQ code I disable IRQ's and do whatever has to be done to the screen. Why doesn't it work? Can anyone point me the problem here?

Thanks in advance
User avatar
Disch
Posts: 1848
Joined: Wed Nov 10, 2004 6:47 pm

Post by Disch »

You must not be disabling APU Frame IRQs.

Write to $4017 with bit 6 set ($40) somewhere... like in your reset routine. If you don't do this, an APU frame IRQ will eventually trip and will send a constant IRQ signal until acknowledged/disabled.

Your MMC3-related register writes look fine.

EDIT:

Also... there are weird rules that must be followed if you plan on using MMC3's scanline counter:

- BG must be set to use ppu $0000 for patterns ($2000.4 = 0)
- Sprites must be set to use ppu $1000 for patterns ($2000.3 = 1)
- if you're using 8x16 sprites, all your sprites must use the right side of the pattern table ($1000)

Break those rules and MMC3 IRQs will not operate as expected.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

Thank you, Disch! Really!

I have not yet tested, but there is no reason for it not to work after I disable the APU IRQs. I thought something else was firing IRQs, but would spend all eternity trying to figure out what, and would never guess it was sound related... I'm really new to the sound stuff.

Thank you very much!

Oh, and about the rules: it is a bitch to always have this kind of rules, but this ones don't seem very limitating for now... maybe I'll change my mind when I'm coding (wich is when we discover the worst things), but I don't think so...
User avatar
Disch
Posts: 1848
Joined: Wed Nov 10, 2004 6:47 pm

Post by Disch »

No prob no prob.

Writing $00 to $4010 might not be a bad idea either (this will ensure that DMC IRQs are disabled... although I doubt they'd go off unless you actually play a DMC sample. Still you might want to do it anyway.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

Just changed the code and everything seems to work ok now! There is just one thing that bugs me: when games like kirby (the one I was studying) set the reload value to, say, $7F, we will see the screen changing after line $80. But in my tests, setting it to $7F will result in scanline $7F already having the changes applied to it. Wich way is correct? The doc you pointed out says that "the number of scanlines before the interrupt fires is (N + 1), where N = IRQ reload value", and from this, I guess Kirby is right... Did I miss something here?

Disch wrote:No prob no prob.

Writing $00 to $4010 might not be a bad idea either (this will ensure that DMC IRQs are disabled... although I doubt they'd go off unless you actually play a DMC sample. Still you might want to do it anyway.
I'll do it, you can never be too safe! =D I really have to learn to work with sound... I've never bothered learning sound programming, not even on the PC...
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Post by Quietust »

The IRQ will go off at the visible end of the scanline, so you might want to wait a hundred cycles or so and apply your changes at the end of the next scanline.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
Post Reply