Just to be nitpicker: I assume you meant attribute reads. Palette reads cannot be redirected. No way, no how.
Yes, I meant attributes. Nitpick all you want... =)
And the reason an extended tile index a la MMC5 would be harder is because the extra bits for the tile index need to come from somewhere.
I assumed this wouldn't be a problem because for extra attributes you also need extre bits.
If you just want to redirect attribute reads, there is a one-to-one correspondence between the read instructions coming from the PPU and the read instructions going to the mapped memory.
Now, since I am not really sure of how all the fetching during rendering works, I can only guess that the reason why these reads have a one-to-one correspondence is that in spite of just one pair of attribute bits being used for a 2x2 tile area, that same pair is read once for each tile?
Whereas if you want more bits for the tile index, you have to throw in an extra memory read to latch the uppermost bits of this extended tile index from this memory. So if you want to use your on-cart memory for this, you would need to perform two reads for every nametable index being fetched.
You know, I'm a noob at this. But in my head, if you had the extra bits (defining from which bank to fetch each tile from) inside on-cart memory it would be just a matter of putting those bits in the higher address lines of the CHR chip at the correct times (assuming that the mapper has a way to tell the correct times - which it must have, since it would be able to redirect the attribute reads at the correct times). The NES wouldn't even know that'd be going on. Then again, noob's point of view.
And personally, I'd rather spend the extra cost and effort needed on a shared memory system instead. (eliminating the vblank limit altogether)
But even if there is no vblank limit, you'd still have to time your writes in order to not get any "tearing" and things like that. Unless you are updating a part of a nametable that's hidden, in which case no limit would be great!
Depends on what you mean by "standard NES stuff". The NES sort of deviates from itself already, as it was only meant to run NROM games when it was released.
Yeah, "standard" is a tricky word here. But I meant things that are taken as "NES-like", because of the large number of games using UNROM, MMC1, MMC3 and such. Making a "super mapper" now will make the games less "NES-like", and few people will be able to run those games unless the mapper was properly implemented on most emulators and the carts were easily obtainable. You know, if you release a MMC3 game, anyone can get a MMC3 cart and put your game on it.
In my opinion, the mapper jungle is both the coolest and the ugliest aspect of NES development, and NES development is as much about hardware as software engineering. There is no standard to follow, so you're free to invent anything you like that will run on the hardware, as long as you have good reasons for doing so. (i.e., if your supercool game idea needs it)
Yours is a valid point though. Most of the MMC5 games sucked badly, while the best NES games there ever were used the most primitive discrete-logic mappers. (Battletoads come to mind) So the hardware is always secondary to well-made software.
It would be cool as hell to have 2 scrolling planes, extended attributes, extend sprites, extended everything. But the fact is that the NES scene is a bit slow, and we haven't made extensive good use of even the standard features yet. So, even if a devcart had all these cool features, I don't see them being used all that much. There is plenty to explore with the "standard" hardware as it is. I don't think this is just the time yet.
But if you're satisfied with the existing cart types, then I don't really see the benefit of cloning them rather than sacrificing existing games. There are a lot of crappy games to put on the altar for almost every common cart type. And re-cycling circuit boards is a lot nicer to the environment than manufacturing new ones. And last but not least, all game collectors out there will be even happier than before, since it raises the value of their cart collection.
I know... I bought a lot of crappy games the other day (like, some 12 carts) and I picked the cheapest ones which had the mappers I wanted.
But you know, even if a devcart does not have these super cool runtime features, it can still stand out for it's development features. Like being able to program chips in place, eliminating the need of an EPROM programmer. That's something I really miss. I have made NROM, UNROM and am about to make a couple MMC3 devcarts, but I find it very annoying having to take the chips in and out, from the cart to the programmer and vice-versa. A self contained, all-in-one devcart would be the coolest thing to have, even if it does not include any revolutionary mapper features.