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

User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

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

Post by tokumaru »

If you want to do the "role-playing" thing with your own projects that's fine, but don't enforce this on everything else like it was some sort of rule for working with retro consoles. Not everyone chooses to code for the NES because they want to pretend it's still the most advanced technology there is, maybe they just have fond memories of the console, or find the limitations fun to work with, or want to prove that the hardware can do something that's generally considered impossible/unpractical, or whatever.

Different programmers pick different platforms for different reasons, but even if you look at this from a purely commercial angle, it may still be more profitable to code a game for the NES, that has an established fan base that consistently purchases quality games, than to target a modern platforms (PC, mobile, etc.) that's flooded with games, good and bad, making it harder for yours to stand out and make any money.

You always have to make decisions about the scope of your projects. You may be pretending you're a Nintendo employee in 1987, or you might be participating in a competition that'll culminate in a multicart with all entries, and both are acceptable reasons to stick to modest mappers and memory sizes, but you can't generalize and put everyone under the same constraints.
User avatar
za909
Posts: 249
Joined: Fri Jan 24, 2014 9:05 am
Location: Mijn hart woont al in Nederland

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

Post by za909 »

I agree that sticking to certain limits does not necessary mean someone wants to "role-play".
On the one hand, I'm also developing with a small cart in mind, but that's because I want it to be easy and cheap to build a real cart, and I also don't have a budget to hire someone to create graphics for me so I'd have no excuse for limited tilesets otherwise. On the other hand I also want to have a small game pushing certain aspects of the NES with little to no help coming from "the outside". But I think I've done enough topic de-railing for a while now.
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 »

Well, you're the one who jumped up to defend the MMC5 as a target platform after my criticism
Sorry I don't think I ever did that.
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?
I'm not trying to make any point specifically, just answering to what had been said with some insight.
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?
I don't really have an answer for that, but using tools to make work quicker than what a developer could have done in more time back then is definitely fine, as as you said yourself, our time is limited.
Drakim
Posts: 97
Joined: Mon Apr 04, 2016 3:19 am

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

Post by Drakim »

Personally I code because I think it's fun, and developing for the NES has been the most fun programming I've ever tackled. I don't necessarily need to produce some sellable product like Battle Kid, nesdev isn't my day job, and having to prioritize stuff like that rather than the fun would just... suck the fun out of it. I just really love to do nesdev, like a painter who loves to paint but doesn't care about selling his paintings or putting them up in a museum. It's fine if that painting ends up in the trash can once it's done, it was the act of painting that was interesting and meaningful.

The MMC5 is fun to experiment with because it's not widely used, so it has lots of uncharted seas to explore. Not that other mappers wouldn't be fun, but there is just something magical about reaching to new unknown potential heights on my poor little childhood hardware. To figure out some new trick that nobody else has come up with before.

Lately I've been experimenting with the the WRAM bankswitching by using 64K memory divided into 8K pages, which can be used as a crude hardware accelerated array of sorts. Got an update routine pointer for each of your gameobjects? No need to do the reverse RTS trick with all the expensive "LDA Obj_Update_Address,X" stuff, instead you just switch the RAM page and call JSR Obj_Update_Address! :D
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 i think i know what you mean (maybe) about the JSR'ing in RAM thing.

I actually do that a whole bunch of times on megaman odyssey. At the very start when you boot the ROM, i load several areas of "un-rolled" code, and put them in 6000-7FFF RAM page 01 ...so that the game can JSR to those places faster than any regular bankswap stuff.

I also load the whole weapon menu graphics/screens into RAM page 02 ..so that during the game, it doesnt have to read level data or many other things normally, making it load twice as fast.

And again, it's thanks to the MMC5 mappr only. :) because of how you can have more than just 1 "6000-7FFF" area.
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 »

MMC1 (wired as SXROM) and FME-7 (wired as loopy speculated and l_oliveira confirmed) can also bankswitch $6000-$7FFF.
kuja killer
Posts: 130
Joined: Mon May 25, 2009 2:20 pm

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

Post by kuja killer »

wow. and i always thought mmc5 was the only one to have more than 1.
did not know. that's interesting. :)
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:Oh i think i know what you mean (maybe) about the JSR'ing in RAM thing.

I actually do that a whole bunch of times on megaman odyssey. At the very start when you boot the ROM, i load several areas of "un-rolled" code, and put them in 6000-7FFF RAM page 01 ...so that the game can JSR to those places faster than any regular bankswap stuff.

I also load the whole weapon menu graphics/screens into RAM page 02 ..so that during the game, it doesnt have to read level data or many other things normally, making it load twice as fast.

And again, it's thanks to the MMC5 mappr only. :) because of how you can have more than just 1 "6000-7FFF" area.
It's based on the same idea, but you can take it even further. I was about to write up a long explanation but I figured I might as well make a new topic instead of polluting this one.
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: Lately I've been experimenting with the the WRAM bankswitching by using 64K memory divided into 8K pages, which can be used as a crude hardware accelerated array of sorts. Got an update routine pointer for each of your gameobjects? No need to do the reverse RTS trick with all the expensive "LDA Obj_Update_Address,X" stuff, instead you just switch the RAM page and call JSR Obj_Update_Address! :D
There's no need for bankswitched WRAM, or even WRAM at all, for doing such tricks. Having a JMP instruction in ordinary RAM can do similar achievement.
Drakim
Posts: 97
Joined: Mon Apr 04, 2016 3:19 am

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

Post by Drakim »

Bregalad wrote:
Drakim wrote: Lately I've been experimenting with the the WRAM bankswitching by using 64K memory divided into 8K pages, which can be used as a crude hardware accelerated array of sorts. Got an update routine pointer for each of your gameobjects? No need to do the reverse RTS trick with all the expensive "LDA Obj_Update_Address,X" stuff, instead you just switch the RAM page and call JSR Obj_Update_Address! :D
There's no need for bankswitched WRAM, or even WRAM at all, for doing such tricks. Having a JMP instruction in ordinary RAM can do similar achievement.
Only if you all you need is that one JMP. With bankswitched WRAM you can have several of them in "parallel" across the WRAM banks, and invoke one of them based on an index.

I've made a topic about this technique here:

viewtopic.php?f=2&t=17064
Post Reply