Curious about MMC5 5209/520A registers

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

lidnariq
Posts: 9658
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Curious about MMC5 5209/520A registers

Post by lidnariq » Fri Jan 17, 2020 6:00 pm

kuja killer wrote:
Fri Jan 17, 2020 5:44 pm
Never F0+ though cause it creates a empty black line at the top of the screen, that must be what your referring to. Or maybe that's the actual real 5FC0-5FFF part.
Yeah, values in the $F0-$FF range are the invalid ones, and they'll try to display the attribute table as though it were tiles. If that were the only problem, it'd be fine - even handy - to use it as a special "hidden" two rows off the top of the nametable, because extended attribute mode means that they're not used for both name and attribute.

But that gets to the other bug: if the Y scroll is in that range, and the X scroill is ... some other unknown constraints ..., then it'll double-clock the MMC5's scanline counter, and IRQs will happen up to 8 scanlines higher than you wanted.
I know it'd be probably nice for certain situations/screens though.
Split left-and-right screen. Glitchless 8-way scrolling (using two nametables in horizontal layout) with a status bar (in the 3rd)

calima
Posts: 1186
Joined: Tue Oct 06, 2015 10:16 am

Re: Curious about MMC5 5209/520A registers

Post by calima » Sat Jan 18, 2020 2:02 am

The vertical split is not that useful though, because it's tile granularity, not pixel. Meaning you can't do proper sliding transitions with it (well, you could hack the pixel position with sprites, but PITA). Leaves only vertical shooter HUD pretty much as the use case.

kuja killer
Posts: 103
Joined: Mon May 25, 2009 2:20 pm

Re: Curious about MMC5 5209/520A registers

Post by kuja killer » Sat Jan 18, 2020 3:28 am

Oh that Vertical split thing wiith $5200-5202, right ?? I was going to try that out once for the Pause Menu, but i was really disappointed that it wasnt allowed for EX Attributes. :( Apparently only works with regular nametable's stuff.

I would of split the menu screen in half. scroll one side up, other down, like lidnariq said. For Tango and Rush Intros. Like this:
Image


I kept trying all the possible EX modes on 5104 to work with the Vertical split stuff, but it just never would no matter what I did. So i was like screw it, and just scroll the whole entire screen up normally ...no vertical split stuff.
Image

Maybe i'll get to another day on something else. But i learned ...it only will work "without" EX att's. :(

User avatar
Bregalad
Posts: 7951
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: Curious about MMC5 5209/520A registers

Post by Bregalad » Sat Jan 18, 2020 3:07 pm

tepples wrote:
Fri Jan 17, 2020 4:07 pm
MMC5 ExGrafix lets you use tiles from an entire 256 KiB block, but it doesn't let you compose glyphs at non-8x8-pixel boundaries. Thus if you want a proportional font with CHR ROM, you have to prerender all your strings when building the ROM.
I actually thought about this problem at some point in my 15+ years of wondering about NESdev. The conclusion is that you don't need to prerender all strings or anything.
You just need to "waste" a 4kb CHR-ROM bank, where each 256 tiles are such that #00 contains a line with the value #00, tile #01 a line with the value #01 and so on and so forth. You can then, on a single nametable line, represent anything. You then use timed code/IRQ to compress the nametable so that 1 tile = 1 line. It's possible to have variable width font and/or kanjis that way.
Since the MMC5 have more nametables than other mappers, and have large CHR-ROM sizes allowed, it's not a problem to use nametable and CHR-ROM space like that.
But that gets to the other bug: if the Y scroll is in that range, and the X scroill is ... some other unknown constraints ..., then it'll double-clock the MMC5's scanline counter, and IRQs will happen up to 8 scanlines higher than you wanted.
Oh that's a shame. It would have really been useful if ExAttributes could be used for a 32x32 nametable instead of 32x30. I still belive it can be done, but only if you don't use the scanline counter IRQ for other uses than reset the scroll to $F0 after line where it's $EF.
kept trying all the possible EX modes on 5104 to work with the Vertical split stuff, but it just never would no matter what I did. So i was like screw it, and just scroll the whole entire screen up normally ...no vertical split stuff.
I see no reason why this wouldn't be possible. As long as you don't use ExGraphics together with split-screen it should work fine.
Even if you use both at the same time the issue is that the data at $5c00-$5fff is used simultaneously for the split screen area (as nametable) and for the normal screen area (as palette/tile number extended attribute). But you shouldn't be prevented to do it, just like you're not prevented to use PPU $23C0-$23FF as nametable and attribute table simulaneously using scroll values $F0-$FF.

Fiskbit
Posts: 152
Joined: Sat Nov 18, 2017 9:15 pm

Re: Curious about MMC5 5209/520A registers

Post by Fiskbit » Sat Jan 18, 2020 6:44 pm

calima wrote:
Sat Jan 18, 2020 2:02 am
The vertical split is not that useful though, because it's tile granularity, not pixel. Meaning you can't do proper sliding transitions with it (well, you could hack the pixel position with sprites, but PITA). Leaves only vertical shooter HUD pretty much as the use case.
It's only tile granularity in the standard CL configuration, right? My understanding is that SL-configured boards will allow the split to have pixel granularity, but that no commercial boards use this configuration.

Assuming that's right, do we know why CL configuration even exists?

lidnariq
Posts: 9658
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Curious about MMC5 5209/520A registers

Post by lidnariq » Sat Jan 18, 2020 7:23 pm

Fiskbit wrote:
Sat Jan 18, 2020 6:44 pm
It's only tile granularity in the standard CL configuration, right? My understanding is that SL-configured boards will allow the split to have pixel granularity, but that no commercial boards use this configuration.
Vertical scroll, yes. Horizontal scroll is still forced to be the same on both left and right sides.

I figure there should be other genres of games that are OK with this, but I admit I also don't have any immediate ideas. Certainly plenty of games were published for consoles that don't have fine scroll capabilities, and tile-granularity X scrolling is still permissible on the portion of the display that's not in ExRAM (since in ExRAM the coarse X is just the sliver number for the scanline). Coarse Y control is available on both sides in CL mode; fine Y control is available on both sides in SL mode.
Assuming that's right, do we know why CL configuration even exists?
Our only guess is that the MMC5's adder is too slow for the ROMs they wanted to use at the time. Certainly when using modern 70ns flash or RAM it should be just fine.

Sour
Posts: 815
Joined: Sun Feb 07, 2016 6:16 pm

Re: Curious about MMC5 5209/520A registers

Post by Sour » Sun Jan 19, 2020 12:58 pm

lidnariq wrote:
Fri Jan 17, 2020 3:45 pm
(see: Drag's test and loopy's video of hardware. As far as I know, no emulator - not even Mesen - handles this edge case correctly yet.)
Didn't actually know about this specific glitch/test rom, thanks! Reworking the MMC5 internals to be less hacky had been something I've been meaning to do for a long time, and I finally just got done with it. As of the latest commit, that test rom should behave like the youtube video of it, and the glitches on the first scanline in Just Breed should be visible, etc.

Still haven't implemented any of the MMC5A stuff, though.

NewRisingSun
Posts: 1214
Joined: Thu May 19, 2005 11:30 am

Re: Curious about MMC5 5209/520A registers

Post by NewRisingSun » Sun Jan 19, 2020 1:23 pm

I rewrote the MMC5 emulation for NintendulatorNRS some time ago, and in that test ROM, the ruler does move, but in the wrong direction --- instead of revealing the "A", it lost the "9". :oops:

zzo38
Posts: 1075
Joined: Mon Feb 07, 2011 12:46 pm

Re: Curious about MMC5 5209/520A registers

Post by zzo38 » Sun Jan 19, 2020 10:32 pm

Did you use my ideas for the submapper number of MMC5?

The intention of this specification is that all known games (with the possible exception of some very recent homebrew games) can be emulated correctly (note: this does not necessarily mean that the cartridge is actually configured this way; the game might not care about some of these features) with the submapper number set to zero. If changes need to be made, then it can be done. It is unlikely that someone will need to use nonzero submapper numbers, but if someone does need, then it will be possible to specify these features if it is implemented.


EDIT: There may be other variants than what I listed, so these variants might not be so good. As far as I know though, all of them other than PRG-RAM still may be used to specify existing cartridges, even if nobody cares. But I may be wrong. And even if I am not wrong, there may be variants that I have failed to consider.
Last edited by zzo38 on Mon Jan 20, 2020 12:34 am, edited 2 times in total.
[url=gopher://zzo38computer.org/].[/url]

lidnariq
Posts: 9658
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Curious about MMC5 5209/520A registers

Post by lidnariq » Sun Jan 19, 2020 11:11 pm

UGH, stop it.

We don't need submappers for MMC5, because no hardware relies on the variation. In the case that we do discover some future variation that isn't one of the four you've outlined, by allocating all four bits as a bitmap, you've precluded the ability to allocate submappers for that future hardware.

zzo38
Posts: 1075
Joined: Mon Feb 07, 2011 12:46 pm

Re: Curious about MMC5 5209/520A registers

Post by zzo38 » Sun Jan 19, 2020 11:44 pm

lidnariq wrote:
Sun Jan 19, 2020 11:11 pm
We don't need submappers for MMC5, because no hardware relies on the variation. In the case that we do discover some future variation that isn't one of the four you've outlined, by allocating all four bits as a bitmap, you've precluded the ability to allocate submappers for that future hardware.
That is correct, it is a valid point. (I realize too there are other points I may have missed, but what you make nevertheless is a good point.)
[url=gopher://zzo38computer.org/].[/url]

kuja killer
Posts: 103
Joined: Mon May 25, 2009 2:20 pm

Re: Curious about MMC5 5209/520A registers

Post by kuja killer » Sun Feb 02, 2020 1:14 pm

Hey there again ? Rather than start a new thread, i kind of had another question or two, not about mmc5 stuff at the momment, but just NESASM things.

First, is it possible for a macro or a "if/else" statement to loop X number of times ...i know "asm6" has something called "REPT" to repeat doing something over and over, i did not find that in the nesasm documentation though. :( So i do not know.

I unrolled some routines in my game that are literally over 5000 lines long, and i wondered if a macro or if/else ...or something, can repeat a few lines to ya know...do that ?? just nesasm doing the loop, NOT the game's code. If that makes sense. Here's an example:
Or is that too stressful for nesasm to handle?? I would bet that would only just hurt nesasm's own compile time. I wouldn't know.

Image
-----------------------------
Next question:
Is there any way to like put a low and high pointer table type of thing, into 1 line .."without" using the ".dw" thing ?? I cant seem to figure out how to do cause i always get all kinds of "undefined" or "invalid address" or other types of errors. I dont really want to use dw since i'd have to add a couple more lines of code to follow the different format. Because im obssessed with un-rolling things, for more speed. :|

basically, this - and it's OK if not though to both questions, no big deal.

Image

Post Reply