It is currently Thu Oct 19, 2017 9:33 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 12 posts ] 
Author Message
 Post subject: recommended mapper
PostPosted: Fri Feb 18, 2005 11:59 am 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Feb 18, 2005 12:17 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Feb 18, 2005 3:09 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1389
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Feb 18, 2005 3:35 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Feb 18, 2005 4:10 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
The only MMC3 doc:

http://www.tripoint.org/kevtris/mappers/mmc3/index.html


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 19, 2005 12:52 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10058
Location: Rio de Janeiro - Brazil
Disch wrote:


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).


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 19, 2005 1:43 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 19, 2005 2:05 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 19, 2005 10:19 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 19, 2005 11:07 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Feb 19, 2005 11:22 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Sun Feb 20, 2005 1:56 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1389
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group