There is one thing that I would like to clarify regarding the increment size when you're changing bank for CHR-DATA.
In the case of MMC1, the banks are usually 4k (except one case where it cover the compete 8k). The change bank register is 5 bit, which mean it can covers 32 possibilities.
When you change bank, will the increment be based on the bank size (4k/8k) or always 4k (which mean 0k, 4k, 8k, etc)?
Same question regarding MMC3. One pattern table allows 2k only bank, the other one is 1k. How the increment will be? Always 1k or based on the size of the bank?
I checked the wiki but it doesn't mention about that fact.
Usually the increment is the smaller possible size.
For the MMC1, even in 8k mode, you write the number of the corresponding 4k bank, and it switch 8k.
For example if you write either 2 or 3 to the CHR ROM bank register and are in 8k mode, 4k bank 2 will be swapped in $0000-$0fff and 4k bank 3 will be swapped in $1000-$1fff.
The exeption to this is the MMC5 : The banks numbers are actual numbers in regard to the size you have selected. I don't know for the MMC3 but I'd be almost sure it acts as for the MMC1, always counting banks for the smallest available size and ignore the low bits if you use a larger size.
Thanks for confirming the information. I can now continue to work on my map editor and be sure that the bank I select in it will be same as the nes.
Maybe I should update the wiki with this information since it is quite useful to know.
Well, I guess it's already mentionned on the Wiki, but if you could get it told in a more newbie-friendly way than the current ulatra-technical way it would be great.
Some old mappers doccuments available on the NESdev main page could give more percise information thant the wiki.
Bregalad wrote:
Some old mappers doccuments available on the NESdev main page could give more percise information thant the wiki.
*cough*cough*
http://www.romhacking.net/docs/362/
</plug>
Wow that sounds more modern and better. I didn't know you wrote so many well done doccuments. Great work.
Altough most are written for the emu author and not the NES game author, it's still more usefull than the old crap.
EDIT : In the SOROM part the 'R' bit is seems mispositionned : It should be bit 3 instead of bit 4, you'd want to fix this for a future update (unless it's me who is stupid).
Kevtris information is outdated. It still states that SJROM uses CHR-RAM for example, which is terribly wrong.
If you look carefully at this :
Quote:
A CHR register.
7 bit 0
---------
xxxW xxxR
W: WRAM bank.
0 - bank 0
1 - bank 1
Note: the "W" bit must be set THE SAME on BOTH CHR select
registers, or else Bad things will happen!
R: VRAM 4K page select bit
For 8K CHR pages:
Note: only the first CHR register is used.
7 bit 0
---------
xxxx Wxxx
W: WRAM bank.
0 - bank 0
1 - bank 1
WRAM banks:
Bank 0 is not battery backed, while Bank 1 is.
It doesn't really make sense : The W bit is bit 4 above, but bit 3 below. Since the MMC1 just ignores the low bit in 8k modes, but does not shift the whole register as the MMC5 does, the W bit has to be at the same place in both cases. I do have no SOROM board to check unfortunately.
According to the Wiki it would be bit 3, but someone (including me) could have written false information in it.
I think it would make sense it is bit 3 so that it is SXROM compatible (I mean Nintendo could have imposed bit 4 for ROM and bit 2-3 for ROM regardless of the board). But this have to be verified.
Or one would just to have to look at the code from a Koei game to check this out.
I always thought that was weird too. I suppose it really doesn't make sense that it uses a different bit. *shrug*
Checking a commercial game wouldn't help, as I'm sure they all stay in 8K CHR mode (and the confusion seems to be with 4K mode).
Thanks for the heads up. I'll make that change in my local copy for the next update (if I ever get around to doing another update).
Checking a game reveals it is bit 3. And it is electronically impossible it's a different bit depending on CHR size when you think about it correctly. It's Kevtris who messed up, it's always bit 3 for SOROM.
Bregalad wrote:
Checking a game reveals it is bit 3.
For 8K mode, sure. But show me a SOROM game that uses 4K mode.
Quote:
And it is electronically impossible it's a different bit depending on CHR size when you think about it correctly.
No it's not. It's just unlikely. It wouldn't be the first time seperate bits were used for the same thing depending on another register's state.
Anyway we're in agreement for the most part. I agree it's most likely bit 3 in both cases. Hence why I made the change. :P
Thanks Dish for the document regarding mappers, I will give it a look.
The thread went a little bit off topic but in the end if fixed some information so I guess it's a good thing and see no problem with it.
The reason I need the information is for a feature in my map editor. When you create a map, it will be associated with a Metatile set. This set will be associated with some CHR-Data set.
Your metatile set needs to know which chr-data bank in your pattern table needs be selected so you can show the map the way it supposed to be. So you have to select which mapper to use for your project. Depending which pattern table you chose, this affect how many banks you can select (ex: MMC3 is sometime 2k banks or 1k banks).
So you can select the banks in real time and see the result. The next time you open the project it will re-open the same banks you selected. Later I want to include some bank switching animation with a timer to have an idea how the animation would look like but I'm still far from doing that since I can only put less than 1h per day on it when I'm lucky.
Disch wrote:
Bregalad wrote:
Some old mappers doccuments available on the NESdev main page could give more percise information thant the wiki.
*cough*cough*
http://www.romhacking.net/docs/362/</plug>
I read your documents and nowhere in mapper 04 (MMC3) does it mention if the CHR bank selected is switched by 1k increment or not. Did I miss something in it? Or maybe it written indirectly and I didn't saw the nuance about it?
I suppose it's not fully spelled out... but the info is sort of there:
example from main readme:
Code:
$0000 $0400 $0800 $0C00 $1000 $1400 $1800 $1C00
+---------------+---------------+-------+-------+-------+-------+
| <$7EF0> | <$7EF1> | $7EF2 | $7EF3 | $7EF4 | $7EF5 |
+---------------+---------------+-------+-------+-------+-------+
Here, the register at $7EF3 selects a 1k CHR page for $1400-17FF, while $7EF0 selects a 2k CHR page for
$0000-07FF.
Numbers surrounded by <> symbols indicate the low bits of the given page number are ignored. This is
typical where a mapper deals with several different page sizes. For example, $7EF0 selects a 2k page, but
its low bit is ignored (effectively, you must right-shift its value by 1 for the actual page number).
Basically the size of the "slot" determines the size of the banks. <> symbols denote that the low bits are ignored (right shift to get actual page number). So for MMC3:
004.txt:
Code:
$0000 $0400 $0800 $0C00 $1000 $1400 $1800 $1C00
+---------------+---------------+-------+-------+-------+-------+
CHR Mode 0: | <R:0> | <R:1> | R:2 | R:3 | R:4 | R:5 |
+---------------+---------------+---------------+---------------+
CHR Mode 1: | R:2 | R:3 | R:4 | R:5 | <R:0> | <R:1> |
+-------+-------+-------+-------+---------------+---------------+
R:2 through R:5 would be 1K page numbers because they cover 1K, whereas R:0 and R:1 would be 2K page numbers. But for R:0 and R:1 you'd need to right shift them by 1 (as the <> symbols indicate)
So if R:0 = $05 .. then that would select:
2K page 2 for $0000-07FF
or.. as Bregalad put it (which might be easier to visualize for you) you can think of it as this instead:
1K page 4 for $0000-03FF
1K page 5 for $0400-07FF
I think I'm getting closer to visualize it, thanks for the information.
When you select R:0 in Chr mode 0, the first bit is ignored. This mean if I asked page 2 or 3, I would receive page 1.
Since the size of the slot determine the size of the bank, this mean that if I select page 1 (2/3), I will receive the value at $0800. In that mode, it would not be possible to receive the value at $0400.
This is what I was trying to clarify. In 2k mode, I will only be able to select the data inside the CHR-DATA by 2k increment, the same as the slot. So page 1 is not at $0400 but $0800. The bank in that mode will never be able to start at $0400.
Is it correct?
Yes it sounds correct. In fact it would be more acurate to say "select 2 1k banks at $0000-$07ff" instead of "select 2k bank at $0000-$07ff", as the number written is the number paging of 1k increments. It should be easier if you only have one numbering system for all modes.
As you say, the low bit is ignored and cannot used to rotate banks so that $000-$3ff have bank N and $400-$7fff bank N+1. Here the number you write applies for both banks that are hardwired to 2kb bounds, so you always end up with an even bank in $000-$3fff and a odd bank in $400-$7ff.