More Famicom notes - NESdev BBS

More Famicom notes
by BootGod on 2007-07-27 (#26022)

Finally I get around to finishing these up from my last set of games

Nintendo:
---------
HVC-STROM (Pinball): I found this bizarre thing in a Pinball cart, check the DB and see for yourself! It boils down to work the same as a NROM cart though.

HVC-FJROM (Famicom Wars): WRAM is not enabled by default (open bus). How the hell do you enable it?! I can't figure it out! Press start 2x to get to a select screen. WRAM is not enabled until you choose one of these options. Once enabled, it stays that way even after reset. Both /CE lines and /WE are connected to the MMC4.

HVC-FKROM on the other hand, WRAM is enabled and writable on power up. On these boards, one of the /CE lines and /WE is connected to the MMC4 the same way FJROM is, the other /CE line is connected to an MM1026, which is some kind of switching device that prevent WRAM corruption when switching between normal power and battery.

Jaleco:
-------
JF-09 (Jajamaru no Daibouken): Existing dump was hacked to work with mapper 66. Also had inner CHR banks swapped like JF-10 (Urusei Yatsura: Lum no Wedding Bell). Should be mapper 87. Doesn't work in Nestopia currently until m87 is fixed (see previous notes for more about this).

JF-19 (Moero!! Pro Yakyuu '88: Kettei Ban): From what I read in docs, bankswitching is done by writing to $8000-FFFF with the register format being like PCxxNNNN where NNNN is the bank num, P means your switching a PRG bank and C for switching CHR and xx being unused. Then your supposed to write the bank num again with P & C cleared. Also has bus conflicts. This particular game will do the following: (the accumulator has the desired value in it at this point)

tax
sta (8000h),x
and #3fh
tax
sta (8000h),x

So there is a lookup table for bank selection at the first 256 bytes at $8000

Only reason I am really noting this is because Moero!! Pro Soccer (which I dont have) is also m92 and seems to do it completely different.

Bandai:
-------
BA-JUMP2 (Famicom Jump II): Doesn't work in any emu. Seen references to mapper 153. Uses Bandai's LZ93D50 and has 8K WRAM (battery-backed) at $6000 and 8K VRAM. Seems to have same register setup as other LZ93D50 games (uses $800x). $8000-8007 normally select 1K CHR bank, but instead here the lowest bit selects the lower/upper 256K of PRG. Once the upper 256K has been selected, it seems you have to write 0 to all 8 CHR bank regs to go back? Not sure if CHR regs serve any other function in this case. On powerup, is set to lower 256K.

BANDAI-CNROM: Works just like HVC-CNROM, even has the evil CHR enable diodes. On a side note, I had 2 copies of GeGeGe 1, one used a 74xx163 instead of a 161.

Mapper70/152: These are indeed the same board with the exception that m70 has pads to select H/V mirroring. Also Kamen Rider Club has the worst controls of any game I've ever played.

BANDAI-GNROM: Just like HVC-GNROM.

Mapper159: Exactly the same as m16 (BANDAI-LZ93D50) except has a 1kb EEPROM instead of 2kb.

A number of Bandai boards use japanese characters in their names, and also Taito's Fudou Myouou Den does as well. Can anyone translate these for me so I can give them better names?

Taito:
------
Mapper80/207 (X1-005): Not so sure they need to be be split, maybe the mirroring has to do with $7EF6? Need to look into more.

TFC-BJ2-5900-35 (Bakushou!! Jinsei Gekijoh 2): WTF! The first cart of this I dumped used the TC0190FMC (m33) and another used the X1-005 (m80) and I dumped them using their respective plugins and they dumped the same! Need to look into this.

What's up with the batteries in these X-017 and X-005 games? Read that X-017 has 8K WRAM at $6000, it does not as far as I can tell.

Konami:
-------
Nothing really new to mention here, one question though, has anyone ever seen an actual "VRC-1"? The m75 games I've seen so far (Konami and Jaleco) have used a chip labeled D65005C075 in conjunction with a 74xx32

Namco:
------
I still haven't seen anything marked as an actual '106' (m19) though I did find a number of carts with a chip labeled '163' that are also m19.

I did notice that Namco 3xxx boards have sort of a pattern to them where the digits represent different attributes of the board. I think maybe we should be using these as the UNIF / board class instead.

Code:

33xx (NROM-series)
------------------
These 4 have "pseudo-pads" for selecting H/V and 128/256 PRG
3301 = H Mirr / 16K PRG
3302 = V Mirr / 16K PRG
3303 = H Mirr / 32K PRG
3305 = V Mirr / 32K PRG

This last one doesn't have the PRG select option:
3311 = H Mirr / 32K PRG

Code:

34xx (108/109/118 series)
-------------------------
In this set, the 3rd digit seems to represent mirroring:

340x = H
341x = V
342x = Mapper ctrl

the 4th digit represents the PRG/CHR sizes:

34x1 = 32K PRG / 32K CHR
34x2 = 32K PRG / 64K CHR
34x3 = 64K PRG / 32K CHR
34x4 = 64K PRG / 64K CHR
34x5 = 128K PRG / 32K CHR
34x6 = 128K PRG / 64K PRG
34x7 = 32K PRG / 32K CHR (PRG NOT SWAPPABLE*)

* The normal 32K PRG carts can bankswitch around its 8K chunks of PRG, I don't know why this would be desirable or practical but they can do it! On the 34x7 boards, the traces that connect the mapper to PRG A13 and A14 are not present, so the 32K is fixed and can't be swapped.

Here is the full list of 34xx boards I have come across and their attributes. There are some oddballs that don't really fit into that scheme above.

Code:

PCB / Mirroring / PRG / CHR / 32K PRG Swapable
----------------------------------------------
= H 32  32 Y
= H 128 32 -
= H 128 64 -
= H 32  32 N
= V 64  32 -
= V 64  64 -
= V 128 32 -
= V 128 64 -
= V 32  32 N
= M 128 32 - (This board controls mirroring by using CHR A15. It thus has a max of 32K CHR. Currently m95)

Now a couple odd ones:
= V 128 128 - (This has a 74xx32 used in conjunction with mapper to allow it to use 128K CHR. Currently m88)
= V 32  32  N (I found this in the game Metro-cross. It looks exactly the same as 3417 to me!)

The rest of them:
-----------------
The rest of the Namco boards are mostly the m19 type and almost exclusively epoxy boards. They use a variety of naming schemes:

60-xx: Always epoxy boards, all m19 except these 2. The name doesn't seem to mean anything useful, the numbers just go up incrementally from oldest to newest.
60-10: This is a standard 108/109/118 cart like those in the 34xx series.
60-24: An m88 board, apparently like the 3443. The 74xx32 and 108/109/118 must be housed under the same glob.

LROG0xx: Always epoxy boards, these are used all over the place. I see these in other companies games like Nintendo. The name doesn't seem to mean anything useful, the numbers just go up incrementally from oldest to newest. Most of the them will have a "real" board name in addition to this, but not always.

And then finally, there are some boards specific to the 106/163. There seems to be meaning to the names but I haven't seen enough of them to be conclusive on aything. The ones I've seen so far:

Code:

PCB / PRG / CHR / WRAM / Type / Battery
--------------------------------
111S0  = 128 128 0 Epoxy Y
111F0  = 128 128 0 DIP   Y
110S0B = 128 128 0 Epoxy N
111F0S = 128 128 0 DIP   N
225S0  = 256 256 8 Epoxy Y

The first 2 digits appear to represent PRG and CHR size (1 = 128, 2 = 256).
The third digit I have no clue.
The 4th digit seems to indicate the type of board (S = Epoxy, F = DIP).
The 5th digit has always been 0.
The last letter may have to do with the presence of a battery (no letter = battery, letter = no battery). Pretty hard to say though.

Now for some game / board specific notes, mostly relating to WRAM:

60-10: Supports WRAM, but not always present
60-12 (Dokuganryuu Masamune): Has WRAM + battery (assuming for WRAM, but not neccessarily), but WRAM is not enabled at powerup and I don't know how to enable it.

Youkai Douchuuki: PRG must be wired funny, had to start with bank # 16. Data below this was mirror of data starting here (IIRC in 32K increments).
60-16 (Kaijuu Monogatari): Supports WRAM, but not present in this case. Has battery backup for internal RAM.
60-21: Supports WRAM, but not always present. When present, it is enabled and writable on powerup. Can be battery backed.
60-25: Has WRAM + battery. WRAM is enabled on powerup but not writable. Again, don't know how to write enable.

Panesian (AVE?):
----------------
I checked out a Bubble Bath Babes cart, it seems to be made by the same place that did AVE's boards. In fact it has the same form-factor and fits pefectly into an AVE cart and it uses the NINA lockout chip as well!? Anyways, this is currently assigned as m3, which maybe it shouldn't be. It has a 64K CHR ROM, which a CNROM board would not work with.

The 74xx161 uses 3 of it's gates, the first 2 are like CNROM:
PRG D0 controls CHR A13
PRG D1 controls CHR A14

But then rather than using D4 and D5 for the security stuff, it simply uses D2 to control CHR A15

by Bregalad on 2007-07-28 (#26031)

Mapper 3 is generalised to support up to 256 8kB CHR ROM banks, so in theory you could have a game using 32 KB PRGROM and 2048 KB CHRROM and still uses mapper 3 (it wouldn't be CNROM tough).
Also, there is no much surprise that a 74HC163 was used instead of a 74HC161 on a particular Bandai board, they behave the same exept on the master reset circuitery, wich is synchronous on 163 and asynchonous on 161, and since the reset is never used (tied to VCC) on CNROM boards, they behave exactly the same. Also a 160 or 162 will work as well, as they are respectively the decimal counterpart of 161 and 163, that means that if they are set to 9 and are clocked, they will automatically reset to 0 and not count to 10. However, since counting is always disabled on all Nintendo boards, they will latch the data written just the same.

It's fun to see this number thing in Namco's boards, unfortunately they seems to be the only boards where there is any meaning in the name. I mean come on, "CNROM" means absolutely nothing, the number parts of Konami's boards means even less, and the other manufacturers seems to just have the name of the game printed on the board. A fun thing is that Overlord's board is marked "SN1-ROM" according to you, and how could Virgin know that SNROM name ?

About the MMC4, I think the main difference between FJROM and FKROM is the size of the CHRROM, just like SJROM and SKROM. My Famicom Wars ROM is set to have 128KB CHRROM, but I guess this is an overdump ? At least it would make sense if it was 64KB.

Finally, it's strange noting the odd diodes were used on all Bandai and Konami CNROM boards as well. Did they got shematic from Nintendo or something ? A fun fact is that it seems all japanese CNROM boards use them, and not a signle NES game uses them (some boards still have slot for them).

by BootGod on 2007-07-28 (#26038)

Quote:
Mapper 3 is generalised to support up to 256 8kB CHR ROM banks

That can't be right, I don't see how it could support anything beyond 16 banks / 128KB CHR. For one, the 161 only has 4 latches so only 4 bits can be used. I know INES doesn't care much for such technicalities, but the Japan CNROM games often use D4 and D5 for the CHR enable functions. If an emu were to interpret those as part of a bank select, they wouldn't work too well.

Quote:
About the MMC4, I think the main difference between FJROM and FKROM is the size of the CHRROM, just like SJROM and SKROM. My Famicom Wars ROM is set to have 128KB CHRROM, but I guess this is an overdump ? At least it would make sense if it was 64KB.

I don't know that I would call that the main difference, but that is probably where the names came from. I would think the additional WRAM circuitry on FKROM would be the primary difference, functionally at least. And yeah, the existing Famicom Wars had a overdumped CHR, and it was bad as well.

by dvdmth on 2007-07-28 (#26039)

BootGod wrote:
That can't be right, I don't see how it could support anything beyond 16 banks / 128KB CHR. For one, the 161 only has 4 latches so only 4 bits can be used. I know INES doesn't care much for such technicalities, but the Japan CNROM games often use D4 and D5 for the CHR enable functions. If an emu were to interpret those as part of a bank select, they wouldn't work too well.

All (good) emulators use the actual PRG/CHR sizes to determine how many bits to acknowledge in PRG/CHR bank registers. For a normal CNROM game, only the lower 2 bits of the CHR register will be acknowledged since there's only four banks available. However, a CNROM clone with eight banks will also work on mapper 3, because emulators will see the larger CHR size and allow for more bank selection bits. A theoretical board with 2MB of CHR could still use mapper 3 (although more complex hardware would be necessary) and emulators will still handle it (though NES 2.0 will be needed to encode the larger CHR size).

by BootGod on 2007-07-28 (#26040)

Ah I see know, thanks for clearing that up.

by Bregalad on 2007-07-28 (#26041)

Quote:
That can't be right, I don't see how it could support anything beyond 16 banks / 128KB CHR. For one, the 161 only has 4 latches so only 4 bits can be used. I know INES doesn't care much for such technicalities, but the Japan CNROM games often use D4 and D5 for the CHR enable functions. If an emu were to interpret those as part of a bank select, they wouldn't work too well.

That is not taken in account for mapper 3. CNROM is mapper 3, but mapper 3 isn't restricted to CNROM if you see what this means. Japanese CNROM games that actually relies on D4 and D5 usage are not mapper 3 any longer. A mapper 3 game with more than 128 KB CHR would require 2 '161 or one '377.
A mapper 3 game could also have SRAM, battery, 4-screen mirroring, or whathever that would come up and that isn't included on a true CNROM board.

by BootGod on 2007-07-28 (#26042)

That's not entirely the case (right now anyways). Mapper 185 is for 8K CHR games only, the other CNROM games that use D4 & D5 still work fine under m3. Those 2 bits need to be set properly when dumping the carts, but in emulation, they work just fine without having to deal with them because the CHR is always enabled to begin with. This really isn't the accurate way to go about this and should probably change in the future. There could very well be carts out there that do similar checks like the 8K ones, but checking for open bus instead, and if it didn't see what it was expecting, go into a endless loop.

by tepples on 2007-07-28 (#26043)

Then define mapper 3 to emulate a board with diodes for CHR enable iff CHR size <= 16 * 8 KiB. But then how does the ROM file specify the direction of each diode?

by Bregalad on 2007-07-28 (#26045)

BootGod wrote:
This really isn't the accurate way to go about this and should probably change in the future. There could very well be carts out there that do similar checks like the 8K ones, but checking for open bus instead, and if it didn't see what it was expecting, go into a endless loop.

I don't agree at all. Setting the wrong diode config will create bus conflicts and that's all that it will do - it won't affect the CHR ROM bank switched in. The 8 KB CNROM carts seems to have the ability to disable the CHROM with D0 and D1, D4 and D5 does not disable the CHRROM at all. The carts could check if the conflict happens, but the result is unpredictable, because the PPU can win and have no particular restults, or the mapper (and diodes) can win and mirror the CHR ROM in a weird way, possibly damaging the PPU itself. I have really no idea why these diodes were used at all, exept to make bus conflicts and possibly damage copying devices that sets the wrong diodes config before reading.

by BootGod on 2007-07-28 (#26046)

Heh, I think I'm going to have to go back and look overs these again! I don't think I'm wording things correctly, I never meant to imply D4 & D5 control actual CE lines, by "enabled" I just meant not in a bus conflicted state. IIRC, when these aren't set correctly, you will get varied results with either device winning the bus like you said. What I need to double check is what happens with these 8K games, when D4 and D5 are set properly, but D0 / D1 are not. I'll take a look in a little bit.

by kyuusaku on 2007-07-28 (#26047)

It would all make sense if someone would finally draw a schematic of a cart! :) I would but I still can't open any FC carts...

by Bregalad on 2007-07-28 (#26048)

I bet that the result is open bus (the CHRROM itself being disabled) but no bus conflicts will appear.

By the way, I noted that the board used for Gradius (J) has slot for 4 diodes, only 2 of them being used, also NES-MHROM-03 has slot for 3 diodes and some NROM boards also have slot for 2 diodes, it would be a good idea to check up this too. (I have none of those boards)

by BootGod on 2007-07-28 (#26049)

You are correct, pin 26 & 27 must be CE's on these carts, plain and simple. If they are not enabled correctly, you get open bus, regardless of how D4/D5 are setup. Not only that, but whether they are active high or low must be dependent on the ROM itself. So basically the only way to know this is to either look at the code and see what the game does, or trial and error. Perhaps the last 2 digits of the ROM serial number might mean something, but those are almost always different from cart to cart.

So as far as emulation is concerned, D4 and D5 are not important (but they shouldn't be ignored either). They just have to be set properly when dumped otherwise you get corruption from the bus conflicts.

INES, without working something into the 2.0 spec can't handle this properly, and UNIF would have to have an additional tag created.

by dvdmth on 2007-07-28 (#26050)

NES 2.0's sub-mapper field should come in handy here. I don't know what kev's plans are for the sub-mappers, but my proposition would be something like this:

For m185: submapper = "dcba"
a = proper state of D0
b = proper state of D1
c = proper state of D4
d = proper state of D5

For m3: submapper = "dc11"
c, d = same as m185
11 = bits must be 1 for emulating this CNROM feature. If either bit is clear, assume a simple 8K CHR switch with no fancy business.

by BootGod on 2007-07-29 (#26058)

I don't know why this didn't click with me before, but I just realized that most 16K CHR CNROM behave the exact same way. Regarding pin 26 & 27, 26 is a valid address line (A13) and the other is a CE line. And again it will varies whether it is enabled high or low. So some games will read open bus for the first 16K and others will read open bus for the last 16K.

None of them currently fail emulation because they do not perform checks like the FC 8K ones do, but they certainly could.

DK Classics is one exception I've run into, you just get mirrored data instead. In this case pin 26 would be A13 and pin 27 rather than being a CE line is simply NC.

So a couple changes I think that need to be made to correctly emulate CNROM would be:

1. File format needs some way to explain the function of pin 26 & 27.
2. In the cases where 1 or both pins are CE lines, need to emulate open bus condition when ROM is not enabled.

A funny thing I noticed, the US version of Mighty Bomb Jack still performs the exact same check that the FC version. It even still writes the correct value to D4/D5 as if the diodes were installed. The reason it passes the test? They used a 32K ROM instead of 8K, and the ROM regions that were open bus on the FC cart are FFh-filled.

On that same note, this game is currently in the DB listed as 16K CHR, due to the way the plugin does it's size detection. Even though the last 16K is useless, I feel it should be kept as 32K. Any arguments on that?

EDIT: clarified a bit on pin 26 & 27

by dvdmth on 2007-07-29 (#26059)

If the actual ROM is 32K, then an accurate ROM dump should also be 32K (I don't care if Cowering calls it an overdump or not).

My personal opinion is that CHR bits 4 and 5 probably don't need emulation, because no game using those diodes will ever intentionally cause a bus conflict (unless the developers were really dumb). An emulator that was in the business of bus conflict simulation would also need to emulate bus conflicts with most discrete logic boards when writing to PRG space. And I'm not about to suggest adding a bit to the INES header spec that says "Emulate bus conflicts." Unless a bus conflict is predictable in nature (as is the case with that one odd Color Dreams mapper variant), there isn't really anything to gain by adding bus conflicts.

Proper emulation of the CHR disable feature, on the other hand, is a necessity. Nestopia currently uses an alternate-state approach, where the CHR is enabled after every other write to $8000-FFFF. This obviously isn't hardware accurate.

Have you ever seen a 16K CNROM game that uses D1 instead of D0 for CHR bankswitching? If such a game exists, it cannot be mapper 3 (nor 185) because the bankswitching algorithm will be different from a standard 8K CHR switch. A 16K CNROM game with D1 as a disable line should be assigned mapper 185, once that mapper has proper emulation (which will require the NES 2.0 sub-mapper field).

by BootGod on 2007-07-29 (#26060)

I have not (and hopefully will not) seen that scenario. In both the cases I mentioned before D0 has controlled the switching and D1 controls the CE line, but whether CE is active high or low varies.

by Bregalad on 2007-07-30 (#26061)

Maybe 16 KB CNROM games just used additional CE because the ROM manufacturer did offer such CHRROMs, and they were compatible with 32 KB ones ?
I'd ask why no game has ever intentionally disabled the CHRROM while rendering the screen in order to get black portions on the screen, this would allow it to disable the screen while it's still enabled trough $2001, for example to have a black bar without affecting the scrolling counters inside the PPU (battletoads does a similar thing, however it switches to a blank nametable, I wonder what would be the result if the CHRROM would be disabled that way).