MMC5's Extended Attributes, some potential issues...

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Drakim
Posts: 97
Joined: Mon Apr 04, 2016 3:19 am

MMC5's Extended Attributes, some potential issues...

Post by Drakim »

Hi, I'm considuring using MMC5's extended attributes, but I've realized that there might be some downsides to the enhancement, so I figured I'd bounce it off you veterans before wasting my time running into this brick wall. :D

Now, from what I understand, normally each tile is painted by using one nametable byte and one attribute table byte (but the entire attribute table is a lot smaller so several tiles have to share the same attribute byte).

With Extended Attributes, the nametable byte works just like before, but the attribute table byte is no longer used. Instead, bytes from the expansion RAM is used as a substitute, but it behaves differently. First of all, there is no sharing between the tiles so you can now freely assign palettes per individual tile. Furthermore, the bottom 6 bits (plus the top two bits from $5130) are used to select between 4KB CHR banks, ignoring the normal CHR banking bits.

Sounds great! But here are my issues:

1. For some crazy reason you can only write to the Extended Attribute RAM during rendering. :shock: But the question becomes, can I just turn off Extended Attributes and put the Extended RAM in "ordinary RAM" mode to quickly edit it during vblank, and then change it back?

2. The Extended Attributes works as if it is 1-Screen mirrored. By also setting the nametables to 1-Screen mirrored mode in MMC5 you solve most potential problems related to scrolling. However, I'm thinking that if you do any sort of IRQ trickery, like split-screen, or the famous Super Mario Bros 3 "falling ceiling" or "rising water" IRQ tricks, you might run into trouble.

Even if you switch over from the first to the second nametable at a certain scanline, the Extended Attributes will be unchanged. This means the tile palettes at the split will end up being wrong unless the split happens exactly at the tile 8px tile boundary.

Could this be solved by not only switching to the second nametable but also turning off Extended Attributes during the split? Is that even allowed, having a partially extended viewport? :)

3. A lot of NES games uses the normal CHR banking bits for tile animations and other tricks, without needing to do expensive VRAM tile updates.
Image
Image

But it's not just animation, but also gameplay tricks. For instance, in Super Mario Bros 3 when you jump on top of one of those blue (P) switches, all bricks tiles turns into coins tiles and vice versa for a limited time

This trick doesn't work with Extended Attributes, as you can't globally change the CHR bank in the same way. I'm thinking you could still do something similar by changing the top two bits in $5130, but it would change ALL tiles and not just the ones you want to animate. You could duplicate the non-animated tiles, but you'd be limited to 4 animation frames, and it would be impossible to selectively animate tiles (SMB3 bricks would morph into coins and vice versa in order to keep other tiles animated).

Is there any other clever way you could animate tiles with Extended Attributes?
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: MMC5's Extended Attributes, some potential issues...

Post by tepples »

If you want to mix ExGrafix and animated tiles, I'd recommend a 32 KiB or 128 KiB CHR RAM. You won't be able to change them all during a single vblank; count on 8 tiles per frame after subtracting time related to OAM and scrolling. The Curse of Possum Hollow (which uses MMC3 and CHR RAM) can update up to 16 tiles spread over 2 frames; the steamy hot boiler room scenes in chapter 3 have a 16-frame animation for 16 tiles.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: MMC5's Extended Attributes, some potential issues...

Post by Bregalad »

Drakim wrote: 1. For some crazy reason you can only write to the Extended Attribute RAM during rendering. :shock: But the question becomes, can I just turn off Extended Attributes and put the Extended RAM in "ordinary RAM" mode to quickly edit it during vblank, and then change it back?
I'm almost certain you can do this (test on hardware before assuming anything !). However since you'll have to buffer updates for regular VRAM, you can as well buffer updates to ExRAM and execute them at the end of the VBlank routine where you wait for rendering to start. I'm fairly certain Just Breed does this. You could even use an IRQ on scanline 0 if polling at the end of NMI is seen as an annoyance or waste of time.
2. The Extended Attributes works as if it is 1-Screen mirrored. By also setting the nametables to 1-Screen mirrored mode in MMC5 you solve most potential problems related to scrolling. However, I'm thinking that if you do any sort of IRQ trickery, like split-screen, or the famous Super Mario Bros 3 "falling ceiling" or "rising water" IRQ tricks, you might run into trouble.
Not really, as you can use the extended attributes for part of the screen, and switch to the nametable you're not using with extended attributes for the other parts, where attributes will work like normal. Only if you restrict yourself to using only extended attributes all the time (such as what Just Breed does) is it a problem. Even then, fill mode will come to the rescue as you can easily blank areas out or have a 8x8 tiles reperesenting water repating itself for free.
Even if you switch over from the first to the second nametable at a certain scanline, the Extended Attributes will be unchanged. This means the tile palettes at the split will end up being wrong unless the split happens exactly at the tile 8px tile boundary.
Yes, if you use both nametables with the same extended attribute, something which makes few sense in my opinion. Not only the colours will be wrong but more importantly also the upper bits of the tile number, which means the wrong tile might be displayed.
Could this be solved by not only switching to the second nametable but also turning off Extended Attributes during the split? Is that even allowed, having a partially extended viewport? :)
Of course.
3. A lot of NES games uses the normal CHR banking bits for tile animations and other tricks, without needing to do expensive VRAM tile updates.
[...]
Is there any other clever way you could animate tiles with Extended Attributes?
Well, since writing to extended attributes is possible during the frame, you could simply rewrite the highest bits of tile # and pick up the same tile form another bank. Sure it's more annoying to code (especially if scrolling is used), and might result in graphical glitches on the frame where it's updated, but overall it's still the same trick as doing a normal CHR bankswitching. The main advantage is that you have no problem with CHR-ROM bank granularity.
You could also turn extended attributes off for parts of the game where CHR-ROM tricks are required, and turn it back on in other places where more than 256 background tiles and/or finer palette resolution are needed.
Drakim
Posts: 97
Joined: Mon Apr 04, 2016 3:19 am

Re: MMC5's Extended Attributes, some potential issues...

Post by Drakim »

Hmmm, thanks for the advice tepples and Bregalad, using some of these tricks I think I can overcome the issues.
kuja killer
Posts: 130
Joined: Mon May 25, 2009 2:20 pm

Re: MMC5's Extended Attributes, some potential issues...

Post by kuja killer »

i personally use the EX attributes like 99% of the time constantly, for Megaman Odyssey (megaman 3 romhack)

I rarely ever use the normal NES nametable attributes. I have first hand experience and, i've tried a few times to have tile animations before, but it's just flat out purely impossible "with" ex attribute mode..

Only by turning it off, and going back to the regular megaman 3 drawing routines (which i've kept just in case, like this), "then" i can have tile animations on the fly with CHR-ROM ...because "chr-rom" is ignored completely in EX att mode.
ex: boltman cave section, and first hallway in NecroMan

And yes, i've noticed that the EX att's are only allowed to be updated "during" rending because...
If it ever happens during the vblank time, then there will be graphic glitches ...an easy way to test that is when there is no music playing.

So whenever i have muted screens like the Game Setup screen, or after you beat a robot master ...im forced to play a song id...but mute the sound completely...which guarentee's the EX attribute update routine will come "after" scanline 0 ...because the music engine comes first and will push it out of vblank time.

if that makes sense
Last edited by kuja killer on Fri Feb 09, 2018 6:47 pm, edited 2 times in total.
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Re: MMC5's Extended Attributes, some potential issues...

Post by Bananmos »

Wow, this post summarizes very well why I'm not too fond of the MMC5. The ExRAM such an all-or-nothing solution. Just want the 8x8 attributes? Tough luck, be prepared to lose out on CHR-ROM bank-switching features as well. And also enjoy having to write 16 times as much data to do animations using attribute changes, when only 4 times as much would have been needed.

And with all the functionality and advanced features that went into the MMC5, it baffles me that they didn't allow selectively enabling either extended attributes or extended tiles. Or at the very least allowed some form of bank-switching. I've always felt the MMC5 was a collection of great ideas poorly packaged. I guess it does work well for some games and makes 'em sine a bit extra. But it is telling that mostly slow-paced strategy games (Koei simulation games, Just Breed and the cancelled Sim City NES version) used the ExRAM functionality.

Anyway, to stop ranting and get back to the topic: One way I suppose you could use fast'n'easy CHR-ROM animation with MMC5 would be to use the top 2 bits from $5130 that control which 256kB page to use for ExRAM tiles. This would require 1MB of CHR though, and would also limit your animation to always animate 4 frames.

And you would also need to duplicate any visible tile that shouldn't animate across all pages which is quite a waste. Although it's worth noting that if you don't use your full range of tile numbers you could also use the tiles that are never visible in gameplay in your game for other things... such as cutscenes, menus or any other code where you could either use ExRAM without the fast'n'easy CHR-ROM animation, or not use ExRAM at all.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: MMC5's Extended Attributes, some potential issues...

Post by Bregalad »

Bananmos wrote:Wow, this post summarizes very well why I'm not too fond of the MMC5. The ExRAM such an all-or-nothing solution. Just want the 8x8 attributes? Tough luck, be prepared to lose out on CHR-ROM bank-switching features as well. And also enjoy having to write 16 times as much data to do animations using attribute changes, when only 4 times as much would have been needed.
Sure, but you can write the changes during the frame so having more data to write is not such a huge deal.
And with all the functionality and advanced features that went into the MMC5, it baffles me that they didn't allow selectively enabling either extended attributes or extended tiles. Or at the very least allowed some form of bank-switching.
Extended tiles is bankswitching, except in a different form where each tile on the screen has it's own bankswitching.
Anyway, to stop ranting and get back to the topic: One way I suppose you could use fast'n'easy CHR-ROM animation with MMC5 would be to use the top 2 bits from $5130 that control which 256kB page to use for ExRAM tiles. This would require 1MB of CHR though, and would also limit your animation to always animate 4 frames.
No offense, but this is a pretty terrible strategy, extremely wasteful in CHR-ROM. You'd better either turn ExRAM off for portions of the game that requires tiles animation, or do the bankswitching by hand even if it means updating quite a significant amount of data to ExRAM, during the frame, like I suggested. Sure it is wasteful in CPU time, but at least not on CHR-ROM.
Last edited by Bregalad on Mon Feb 12, 2018 1:52 am, edited 1 time in total.
kuja killer
Posts: 130
Joined: Mon May 25, 2009 2:20 pm

Re: MMC5's Extended Attributes, some potential issues...

Post by kuja killer »

yea that's truly the only way. is to "not" use the EX att mode, in order to have the instant tile animations of CHR-ROM.

It'd probably be "okay" to do with EX att's only on "non-gameplay" screens like menu's, stage select, anything "outside" of regular gameplay. Otherwise...cant have those animations unless it's explicitally off for a select number of screens during a level

https://i.imgur.com/OiCl8kY.png
I have ex attributes turned "off" for only the first 3 screens of Pyro Man here... because the waterwall is a tile animation and can only be done in CHR-ROM --

after passing that area, i immediately turn EX att's back on for the rest of the level, cause this level uses around 700 "unique" graphic tiles, thanks to MMC5's EX att allowing any 8x8 tile to come from "anywhere", and color pal thing.

i really like this discussion topic.. :)
Drakim
Posts: 97
Joined: Mon Apr 04, 2016 3:19 am

Re: MMC5's Extended Attributes, some potential issues...

Post by Drakim »

kuja killer wrote:yea that's truly the only way. is to "not" use the EX att mode, in order to have the instant tile animations of CHR-ROM.

It'd probably be "okay" to do with EX att's only on "non-gameplay" screens like menu's, stage select, anything "outside" of regular gameplay. Otherwise...cant have those animations unless it's explicitally off for a select number of screens during a level

https://i.imgur.com/OiCl8kY.png
I have ex attributes turned "off" for only the first 3 screens of Pyro Man here... because the waterwall is a tile animation and can only be done in CHR-ROM --

after passing that area, i immediately turn EX att's back on for the rest of the level, cause this level uses around 700 "unique" graphic tiles, thanks to MMC5's EX att allowing any 8x8 tile to come from "anywhere", and color pal thing.

i really like this discussion topic.. :)
That's pretty impressive, I was thinking of just having a on/off bit at the start of each level for ex attributes, but you are actually switching right in the middle of the level?

How do you deal with the transition, do you simply make sure that the 4th screen can be painted identically with ex attributes on or off?
kuja killer
Posts: 130
Joined: Mon May 25, 2009 2:20 pm

Re: MMC5's Extended Attributes, some potential issues...

Post by kuja killer »

oh yea. Basically i have what i call "level events" where each "level id" jumps to it's own section of code to do whatever you want (and wont interfere with other's) basically one of those "jump tables".

And in a level, i begin by taking the level's current "screen number ID" megaman is on, and again, use that as a "jump table" so any individual screen, can have it's own unique code.

So i can change background palettes, turn off/on MMC5's ex attribute mode, or any other thing on a "screen by screen" format. :)

And sometimes i need to go even more technical by reading the camera's current X position, and only do things once you pass like say, "X position 30, on screen 7" ..but it also mean i have to reverse the effect (which takes more code) ..if you decide to walk back the way you came for any reason
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Re: MMC5's Extended Attributes, some potential issues...

Post by Bananmos »

No offense, but this is a pretty terrible strategy, extremely wasteful in CHR-ROM. You'd better either turn ExRAM off for portions of the game that requires tiles animation, or do the bankswitching by hand even if it means updating quite a significant amount of data to ExRAM, during the frame, like I suggested. Sure it is wasteful in CPU time, but at least not on CHR-ROM.
"Waste" is a relative word. It totally depends on what is your most limited resource. :)

If you are targeting the MMC5, it's likely that you're already not too bothered about mass-producing carts, and targeting people with emulators. And you'll get no brownie points for a file that's 768kB smaller there.

And even if you were aiming to put your creation on real carts, the price increase for switching to of a 1MB Flash ROM is probably way smaller than the cost of the donor board.

And assuming your original target CHR was around 256kB, sacrificing ROM space - even at a multiple of 4x - is more reasonable than using > 25% of your frame time on re-creating the CHR bankswitching use case using manual writes to ExRAM.

Frame time that you could need to avoid lag, or just to avoid wasting your third and possibly even more limited resource: Your own time.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: MMC5's Extended Attributes, some potential issues...

Post by Bregalad »

Bananmos wrote: "Waste" is a relative word. It totally depends on what is your most limited resource. :)

If you are targeting the MMC5, it's likely that you're already not too bothered about mass-producing carts, and targeting people with emulators. And you'll get no brownie points for a file that's 768kB smaller there.

And even if you were aiming to put your creation on real carts, the price increase for switching to of a 1MB Flash ROM is probably way smaller than the cost of the donor board.

And assuming your original target CHR was around 256kB, sacrificing ROM space - even at a multiple of 4x - is more reasonable than using > 25% of your frame time on re-creating the CHR bankswitching use case using manual writes to ExRAM.
In the perspective of an early-1990s NES game coder, which is probably the perspective you want to have when coding a NES game, it makes no sense to quadruple CHR-ROM size as ROM was expensive. It doesn't matter how expensive it is today, if you are in the shoes of a contemporary game developers it makes no sense to target the NES whatsoever. Even if you target for the NES for whathever reason, it makes no sense to use the MMC5 since it's so difficult to replicate, and you could probably get similar features in a simpler way requiring less hardware if you were to do your own PLD development without having to mimic an existing Nintendo mapper.
Frame time that you could need to avoid lag, or just to avoid wasting your third and possibly even more limited resource: Your own time.
If your own time is so precious, then NES game development is definitely not the hobby to have ^^
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: MMC5's Extended Attributes, some potential issues...

Post by calima »

Bregalad wrote:If your own time is so precious, then NES game development is definitely not the hobby to have ^^
That's more of a language than a platform thing.
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Re: MMC5's Extended Attributes, some potential issues...

Post by Bananmos »

Even if you target for the NES for whathever reason, it makes no sense to use the MMC5 since it's so difficult to replicate, and you could probably get similar features in a simpler way requiring less hardware if you were to do your own CPLD development without having to mimic an existing Nintendo mapper.
Well, you're the one who jumped up to defend the MMC5 as a target platform after my criticism, and now you've saying the MMC5 shouldn't be an option at all? I'm confused about what point you're trying to make?

And yes, I think it goes without saying that targeting the MMC5 means your target audience is primarily emulation (or possibly FPGA flash-carts where the cost of the cart has already been provided for), which I already mentioned.

And indeed a lot of the typical features of MMC5, like 8x8 attributes, can have a much simpler alternative implementation if you do want to think about making cartridges. But that also misses the point. No one who makes a game for the MMC5 will have cart replication as a primary concern, but rather emulator support. And the emulator support for your homebrewn CPLD will be virtually non-existent.

You do seem to be quite concerned about engaging in some form of 1990s coder role-playing game, which I can respect. But I am curious how far it goes? After all, have you *really* developed a NES game if you've taken advantage of all the modern tools of cycle-accurate emulators with visual debuggers, Python scripting tools for your build toolchain, and last but not least the in-depth hardware knowledge that is available with the nesdev wiki?

Or should the only respectable NES coders be using authentic development systems from the time, and only have looked at the official Nintendo docs for their learning curve? (Which I think are actually available now IIRC)

Yeah, I'm playing the Devil's Advocate here, but I am actually of interested in just how far this classification of what is "authentic" nesdev actually goes. And personally I think it makes a lot more sense to just stop pretending and view our hobby for what it is: Post-modern NES-development of today, which seeks to create a piece of quirky nieche art that runs on an ancient console, and which can only really be appreciated by those who have some relationship to that old console.

And that art form has very different targets and constraints than the typical NES game dev studio from the 1990s had - not only in terms of technical limitations.

I also feel that the arguments over how much to emphasise the 'pure' way of doing things re-ocurr in loads of other retro-subcultures (i.e. jazz music, Lindy Hop-dancing, etc). But usually they end up with people acknowledging that we tend to get too wound up about "how it REALLY was back in the day", when more often than not we are mostly speculating and extrapolating from a few anecdotes.

For those taking the role-playing seriously, I don't have an exact figure of what the 1990s cost of ROM size vs/programmer time actually was, and I'd be curious to know just out of curiousity. But in the end it wouldn't really change my position on this. :)
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: MMC5's Extended Attributes, some potential issues...

Post by tepples »

If you're coding for an emulator, you might as well target TurboGrafx-16 instead of NES + MMC5. Mednafen runs both.

To me, the "role-playing" with discrete mappers and size limits is mostly important for getting your game into a community multicart. But then again, it might be a spectrum:
  1. Multicart release eligible (discrete; 128K or smaller depending on submission rules)
  2. Solo cart release eligible (discrete, MMC1, MMC3, FME-7; biggest memory mapper accepts)
  3. Emulation eligible (VRC6, Namco 163, MMC5, and other obscure mappers; biggest memory mapper accepts)
  4. The next more powerful system (TG16)
  5. Screw it, I'm making a PC game (Alwa, Shovel Knight)
Post Reply