I'm developing a game with the MMC5 chip, and have encountered an issue with the high nametable bytes.

As it normally goes, one is to write the high 960 bytes of the nametable to $5C00 in PRG space. However, as documented, the NES' two VRAM nametables are nametable #0, #1, and the MMC5 EXRAM nametable is #2. So, I decided I'd do a shortcut to write it. On vblank, I would select nametable #2 with MMC5's $5105, write to with with $2006/2007, then swap back in the normal nametable #0, write the low bytes, and I'm done... with a good amount of spare CPU cycles to make sure I don't go over vblank.

It worked on the emus, but doesn't on hardware! Is there a way to use $2006/2007 to write the high nametable bytes, or must I do the manual $5C00 writing? It'll take twice the CPU cycles if I have to do the manual indirected writes and increment each byte.

I heard that when using the extra WRAM on the cart, you _must_ write using $2006/2007 and can't use $5C00. However, I went trough disassembly of commercial MMC5 games with the extra WRAM, and they indeed use $5C00 as well. Either way, the $2006/2007 writing does work for me. So many conflicting docs on MMC5!

Anyone know if this shorcut can be done, and how?
Thanks in advance!

Try to change $5200.
The screen must be turned on via $2001 when you write to $5c00-$5fff, and don't write to it during VBlank (I'm not very sure of this, ask other people for more information).

Bregalad, Ent from the woods of Fangorn

> Try to change $5200

Why? That affects vertical split mode, NOT the extended attribute rendering mode ($5104)

> The screen must be turned on via $2001 when you write to $5c00-$5fff, and don't write to it during VBlank

This seems completely contrary to common sense, which dictates that you would NOT want to write to it when something's trying to read from it. But oddly enough, one of the games I checked DID write to $5C00-$5FFF during rendering. It may be safe to write here while rendering, but I don't see why there would be ANY sorts of problems related to writing to it when it is *NOT* rendering...

--
Quietust
P.S. If you don't get this note, let me know and I'll write you another.

I agree. It wouldn't makse sense that you could only write to it when the screen is redrawing. However, I'm trying to figure out a way to write to it without using the PRG address writes, and use $2006/2007.

As a matter of fact, in my first build which I tested on hardware, I did write to it during vblank with the screen turned off (yes both, turned it back on before vblank was up), writing through $5C00, and it worked.

I may just have to wait until I finish my RAM cart system to probe the MMC5 regs through trial and error.

From Goroh's Doc:
"Consideration
5c00-5fff has 3 uses.
Split Mode and ExGrafix Mode's VBlank is written so as to become
crowded, it writes a 0 and becomes crowded.
Every mode tries to go around ExRAM mode including reading but it
writes it, is effective in bulk and #5c-#5f is the output at times
where it is effective."

I can't really understand that in that broken english, but doesn't it mean that when the MMC5 is using those 2 modes that whenever something is written to 5C00-5FFF in VBLANK, it writes a 0 to it?

As for it works in emulators and not hardware. Hardly any emulators emulate the MMC5 well. The best one I found is Nestopia, which seems to play all the MMC5 game without glitches.......but I'm not sure and thats just my opinion.

Did you make an MMC5 devcart? I've been wanting to do that.

Quietust: "But oddly enough, one of the games I checked DID write to $5C00-$5FFF during rendering"

How many MMC5 games did you check?

Hi. I checked about three of the games' disassembly in the debugger.

You bring up a good point with that snippet from Goroh's doc, but it's too broken to understand.

I've built both an ELROM and EWROM devcart, those poinouts I posted work for both.

"Hi. I checked about three of the games' disassembly in the debugger."

Well I was asking Quietust about the games he checked that wrote to 5c00-5fff during rendering. But what were the results/discoveries of your checking?

"You bring up a good point with that snippet from Goroh's doc, but it's too broken to understand."

Yeah, it is very broken english. I wonder if the Japanese version is just as confusing. It was probably a "literal" translation word for word or something. Someone who knows the NES quite well and knows japanese should translate it or something. Well, it was translated from Japanese, now it needs to be translated from broken english. But all-in-all it's the best info I can find on the MMC5 even if it's hard to understand. Kevin's Doc is so much understandible, but it only talks about chr/prg banks and WRAM/SRAM and nothing about EXRAM.

Do you know of any other MMC5 info as I've been wanting to code a game in it?

"I've built both an ELROM and EWROM devcart, those poinouts I posted work for both."

Really? What games have those boards? And what pinouts are you referring to?



Would it be possible to get the TMNT demo from http://www.zophar.net/roms/nes.html
working on a real NES with your devcart as it is an MMC5? I've always wanted to know how it looked/sounded on a real NES.

Hope you figure out the problem though. Good luck. :)

"Well I was asking Quietust about the games he checked that wrote to 5c00-5fff during rendering. But what were the results/discoveries of your checking?"
I didn't specifically check when the $5C00 writes were made, just what regs were read/written and with which values, so I don't have any results in that myself.

As for more info on MMC5, I haven't done anything with it that's not in the docs yet, as I haven't finished my RAM cart system, and have been using EPROMs to test my game on hardware. When I finish the RAM system, I'll be able to do all kinds of tests.

The ELROM is the simple MMC5 board used for Castlevania 3 among others. The EWROM board has 32K of SRAM on it and is used in Romance of the Three Kingdoms 2. I posted the pinouts at: http://nesdev.parodius.com/cgi-bin/wwwthreads/showpost.pl?Board=hardware&Number=607&page=0&view=collapsed&mode=threaded&sb=5#Post607

As for the TMNT demo, I can test it on hardware when my RAM cart system is done, but I can't say for sure if it'll work, since NESes don't have the extra audio capabilites of the Famicom. So, if it's using the MMC5 enhanced sound, it likely won't work on an NES.

The TMNT demo doesn't use the extra sound channels. I already checked that on emulators to make sure it'd run on an NES. It uses only the PCM channel. The only thing though is that it runs "good" on all the emulators except for the TMNT logo which appears in some emulators and others it doesn't (or doesn't fully appear). So I've been wondering what would actually show up on the screen as well as the sound quality of the TMNT theme song. Well, If you could test it on real hardware and then tell me the results I'd be grateful.

I've also been thinking of making an MMC5 devcart (once I get one of the boards) so now once someone else has done it and you gave the pinouts it seems like I'll be able to do it. thx a lot :)

-> Why? That affects vertical split mode, NOT the extended attribute rendering mode ($5104)

Sorry, I wrote it quickly. To write #$c0 to $5200 set the extended screen on the whole screen. $5201 change a thing with the scrooling, and you can try something with this.
I've fully experience when you write #$01 to $5104 and when you write only #$00 to $5200 (then you use only ExGraphix mode), but, as you see, I'm in trouble with the Split Mode.

->This seems completely contrary to common sense, which dictates that you would NOT want to write to it when something's trying to read from it. But oddly enough, one of the games I checked DID write to $5C00-$5FFF during rendering. It may be safe to write here while rendering, but I don't see why there would be ANY sorts of problems related to writing to it when it is *NOT* rendering...

Yes you're right.
If you write any value when the rendering is off, the value written is 0.
Put all the palettes on black (with screen ON) or write to it during the first or the last 8 scanline, hidden in NTSC.

Bregalad, Ent from the woods of Fangorn

From Sgt Bowhack's translation of Goroh's doc:
"Consideration
5c00-5fff has 3 uses.
Split Mode and ExGrafix Mode's VBlank is written so as to become
crowded, it writes a 0 and becomes crowded.
Every mode tries to go around ExRAM mode including reading but it
writes it, is effective in bulk and #5c-#5f is the output at times
where it is effective."

From Goroh's doc:
?lŽ@
5c00-5fff‚Í‚RŽí—Þ‚ÌŽg‚í‚ê•û‚ª‚ ‚é?B
Split Mode‚âExGrafix Mode‚Ì‚Æ‚«‚ÉVBlank’†‚Å?‘‚«?ž‚Ý‚ð?s‚¤‚Æ
?‘‚«?ž‚Ý‚½‚¢’l‚Å‚Í‚È‚­?A0‚ª?‘‚«?ž‚Ü‚ê‚é?B
‚ǂ̃‚?[ƒh‚Å‚à?‘‚«?ž‚Ý‚Í—LŒø‚¾‚ª“Ç‚Ý?ž‚Ý‚ÍExRAM Mode‚Ì
‚Æ‚«‚Ì‚Ý—LŒø‚Å‚ ‚é‚»‚Ì‘¼‚Ì‚Æ‚«‚Í#5C-#5F‚ª?o—Í‚³‚ê‚é?B

A better translation:
* Consideration
5C00-5FFF has 3 uses [split mode nametable, exgrafix attribute/bank data, and scratch RAM].
When in Split Mode and ExGrafix Mode, writes performed during VBLANK are ignored and 0 is written instead. Writes are allowed in all modes, but reading is only allowed when used as simple expansion RAM; otherwise, open bus (5C-5F) is returned.

--
Quietust
P.S. If you don't get this note, let me know and I'll write you another.

Does that mean that you can't write to 5c00-5fff while in VBLANK when either Split mode and/or ExGrafix mode is active just as Bregelad said? Although I don't understand why it'd need to be while rendering to actually write to it.

So you can translate Goroh's doc from japanese? Your translation does make a lot more sense and I thank you as that has been confusing. I've been scrounging up all the info I can on the MMC5 and although goroh's doc seems to be the most accurate and complete, it's quite hard to understand with the broken english. It does make perfect sense with the whole memory map of it, it just doesn't make thatmuch sense when trying to explain the structure/perticulars of it. Thus it would be hard for emulator authors and such that don't read japanese huh?

--
P.S. I got the note thus you don't have to write me another........unless you feel like it

Although, this could just mean you need to turn off the exgraphics mode to write turning vblank then turn it back on after. When I debugged some MMC5 games, they would toggle between modes 2 and 1, writing inbetween. I do this in my game, and it did work on hardware when I wrote to $5C00--that's not a problem. Writing to $5C00 on vblank works fine. It's just that I'm trying to figure out if there's a way to write to it with $2006/2007.

Hum... Well.
The way to just turn off the mode 0/1 is not stupid... I trided to see the Just Breed's code to see that, but it's too much unstructured. I saw a part of the programm that's turn off the ExGraphix mode, and I also saw the ExGraphix mode always used, but I did't undestand that.
But you can of course also do that like me, both works.

Bregalad, Ent from the woods of Fangorn

Sorry for Double-Posting.
Quietust, can I ask you how works registers $5106 and $5107 ?
There are also something with palettes and ChrBank, but I don't understand this doc.
To everyone, that the Goroh's document isn't allright, for exemple it don't show the difference between the "8k/16k" bankswitching mode and the "only 8k" one, mode 2 and 3 in $5100 (see Kevin Horton's doc to see the difference). If you want to use mode 3 and put $02 in $5100, your programm will bug shortly and not run.
Mabye there are others big errors like this in this doccument, so be carefull.

Bregalad, Ent from the woods of Fangorn

$5106 and $5107 are used for the "4th nametable" that the MMC5 provides, which contains a single tile with a single attribute setting, filling the entire screen (very quick way of getting a "blank screen") - $5106 sets the tile number, and $5107 sets the attribute bits (bottom 2 bits). In my emulator, I simply do a memcpy() on each write, though I should eventually change this to use nametable I/O handlers (and store the MMC5 ExRAM within the mapper savestate instead of within the PPU as "the 3rd nametable").

--
Quietust
P.S. If you don't get this note, let me know and I'll write you another.

Thanks a lot. Does it works with all graphics mode (in $5104) ?
PS : What's the name of your emulator ?

Bregalad, Ent from the woods of Fangorn

> Does it works with all graphics mode (in $5104) ?
Dunno

> What's the name of your emulator ?
Nintendulator.
http://nintendulator.sf.net/ for the latest build

--
Quietust
P.S. If you don't get this note, let me know and I'll write you another.

I understand now why it's the only US emulator to emulate correctly the MMC5 !!
But palette reading doesn't work with your emulator, then my game don't run correctly on it (just for information).

Bregalad, Ent from the woods of Fangorn

> But palette reading doesn't work with your emulator

From what I recall, palette reading doesn't reliably work on a real NES either; some tests have shown that it works, while other tests have shown that it does *not*. Nobody knows for sure.

--
Quietust
P.S. If you don't get this note, let me know and I'll write you another.

I think it works on my (top-loader) NES. When I ran the nestress test program it said "DrPC Jr" on the palette reading test.

I'm not sure why anyone would want to read from the palette memory, though.

->From what I recall, palette reading doesn't reliably work on a real NES either; some tests have shown that it works, while other tests have shown that it does *not*. Nobody knows for sure.

That's funny. Isn't it something with rendering on/off ?
Read palette can be usefull to do transparencey (note that you can also have a pallete-mirror in your RAM, that I'll do).

Bregalad, Ent from the woods of Fangorn

I got the $2006/2007 high nametable bits it working today. I found that rather than setting the graphics mode to '2', then writing, then setting it back to '1', by setting it to '0', then writing, then back to '1', it works on hardware! So you emu authors gotta update your MMC5 driver!

Cool....finally some definate info on the MMC5. Thx. In my game I probably would have made that mistake and been unable to test it on real hardware (yet....). Hopefully I'll be able to make one of the MMC5 dev carts (any suggestions?).

->I got the $2006/2007 high nametable bits it working today. I found that rather than setting the graphics mode to '2', then writing, then setting it back to '1', by setting it to '0', then writing, then back to '1', it works on hardware! So you emu authors gotta update your MMC5 driver!

I'm sorry, but I don't undersand what you would like to say...
You're trying to write to the third nametable (ExRam) via $2006/7 ?

Bregalad, Ent from the woods of Fangorn

I was able to write the third nametable with $2006/2007, yes.

This is also usefull to upload ExRam during rendering as you said, exept you can avoid to calculate a pointer, with "ora #$5c", etc...
Then, I'm sorry but I don't understand how you do (you explained this a bit quickly...).

Bregalad, Ent from the woods of Fangorn