Stupid hypotetical poll...

[Bregalad]

Hi. I'm asking myself something.
If you could magicaly add or change one single feature of the NES hardware, what will you do ?

Myself, I'd be quite for replacing the 8x16 sprites per 16x8 sprites. That would be much more usefull to animate things, and even allow up to 16 "tiles" on the same scanline such of sprites.

[ccovell]

Make tiles 16-colour rather than 4-colour, thus eliminating the Attribute table and palette mirroring.

[Knurek]

I'd switch 2A03 with C64's SID chip. Just to know what kind of funky stuff the japanese composers would do with it.

[tokumaru]

The 2 things that bother me the most are the limit of sprites per scanline and the height of the screen that is not aligned to the atribute tables (making it a bitch to scroll vertically).

Of course, the sprite problem could be solved as Bregalad said, by adding larger sprite widths, such as 16x8. And the attribute problem could be solved with the 16-color thing.

If I had to pick one... I'd change the height of the screen to 192 pixels (24 tiles) so that there was enough space in the attribute tables to assign a palette to each tile. There would still be 64 bytes left for whatever.

[jackpkmn]

Make tiles 16-colour rather than 4-colour, thus eliminating the Attribute table and palette mirroring.

I agree.

[tepples]

Vcount register (as seen in MMC5, Game Boy, GBA) capable of reliably generating IRQs.

OR:
CPU direct write access to PPU address space, with writes inserted "between" PPU reads.

OR:
Bring the video signal out to cart edge, as is done with the audio signal on the Famicom.

[Bregalad]

Make tiles 16-colour rather than 4-colour, thus eliminating the Attribute table and palette mirroring.

16 colours tiles means 4BPP, so tiles would be 32 bytes instead of 16.
This would limit the pattern tables to only 128 tiles and that would be pretty bad, even if we gain a lot from the fact that tiles are 16-colors. Games would have had very detailed tiles but poor backgrounds overall. Also, even if sprites could be a lot more detatiled (like the SNES), they would have so few tiles that it would be less animation frames for all monsters and players or less monsters in games that already have few animation tiles.
Also, it would be impossible to do effect by color-swap a tile, since all its color would be fixed. This isn't used often on BG tiles due to the attribute tables' complexity, but this is often done with sprites.

[jackpkmn]

Now that I think about it that does make sence. More colors more power. And the NES doent have it right?
-looks over sholder at NES that is stacked with books-

[blargg]

I couldn't think of anything offhand and now I'm tainted with others' ideas. Of those, having a standard timer that can be polled and optionally generate an IRQ would be quite a help and free up previously-wasted CPU time used for delay and polling loops.

[Bregalad]

If I had to pick one... I'd change the height of the screen to 192 pixels (24 tiles) so that there was enough space in the attribute tables to assign a palette to each tile. There would still be 64 bytes left for whatever.

That'd be pretty good to have the same resolution for PAL and NTSC systems. They do have the same resolution, but I mean the pratical resolution. On a NTSC NES, the first and last 8 pixels are reliably hidden, even if they are rendered. The leftmost and rightmost 8 pixels can be randomly hidden or shown from TV to TV (that's what I heard). On a PAL systems all these regions are always shown. It'd be good to simply have a hardware stuff to hide the rightmost 8 pixels along with the leftmost 8 ones, allowing proper horizontal scrolling with horizontal mirroring without attribute glitches. Or also hide the top and bottom 8 pixels on a PAL TV, so you can do proper scrolling with vertical mirroring on both TV standards. For now, "perfect" bidirectionnal scrolling is just impossible on a PAL screen.

One thing I'd very like is to have the priority on background tiles instead of sprites. The Game Boy Color and SNES have that, and you would simply tell if that map tile is above or below sprites.
Of course, maintain the priority bit on sprites would be even better, allowing stuff to be drawn over background anyway (like the MegaMan's life bar, or faces that comes in windows such as in Fire Emblem), and sprites that are either above or below the background (player, enemies, ...). That'd really be great. Together with Tokumaru's idea, there would be some free space in the Name Table range for this.... However, I'm cheating to my own rules, because I said only a single modification to the orginal hardware.

I'm surprised nobody mentionned just a faster CPU. It would allow more frame calculation, so less glitches in most commercial games, since more reliable methods could be used for task that are done each frame, and it would of course allow much more writes in VBlank, such as CHRRAM animating.

[tokumaru]

That'd be pretty good to have the same resolution for PAL and NTSC systems. They do have the same resolution, but I mean the pratical resolution. On a NTSC NES, the first and last 8 pixels are reliably hidden, even if they are rendered. The leftmost and rightmost 8 pixels can be randomly hidden or shown from TV to TV (that's what I heard). On a PAL systems all these regions are always shown. It'd be good to simply have a hardware stuff to hide the rightmost 8 pixels along with the leftmost 8 ones, allowing proper horizontal scrolling with horizontal mirroring without attribute glitches. Or also hide the top and bottom 8 pixels on a PAL TV, so you can do proper scrolling with vertical mirroring on both TV standards. For now, "perfect" bidirectionnal scrolling is just impossible on a PAL screen.

Maybe there could be a hardware setting to hide the top and/or bottom pixels, as there is for the leftmost 8 pixels.

One thing I'd very like is to have the priority on background tiles instead of sprites. The Game Boy Color and SNES have that, and you would simply tell if that map tile is above or below sprites.

Yeah, that'd be cool! The Master System also does it like this. The SMS has some advantages over the NES, but also has some dumb stuff, such as h/v flipping of tiles implemented to the background, but not to the sprites. That's just stupid.

I'm surprised nobody mentionned just a faster CPU. It would allow more frame calculation, so less glitches in most commercial games, since more reliable methods could be used for task that are done each frame, and it would of course allow much more writes in VBlank, such as CHRRAM animating.

I don't know... Even if we had a super fast CPU, with low color resolution and bad scrolling there is little more we can do. A better PPU could result in much better graphics, using the same CPU for game logic. With a better CPU, you could use much more time with tricks that would seem to improve the graphics, but not nearly as much as the better PPU. And after wasting so much time with the graphics, you'd pretty much have the same time for game logic as we do know. For some reason, PPU upgrades make more sense to me.

[Bregalad]

Yeah, that'd be cool! The Master System also does it like this. The SMS has some advantages over the NES, but also has some dumb stuff, such as h/v flipping of tiles implemented to the background, but not to the sprites. That's just stupid.

Oh, yeah. I cannot think of one single game that doesn't use the horizontal flipping. Platformers use it to draw the player in only one direction and flip it horizontally to the other. Top-down games can have 3 direction, and the fourth (left or right) mirrored from its counterpart.
Dragon Warrior games and Just Breeds are the only exeptions, where playable characters always holds their weapons in the right hand and shield in the left, so just mirror the sprite would fake that (as it does in anyother game).
BG flipping can be usefull, but definitely less than sprite, since you'll benifit to do advanced shadows effects on tiles that looks similar but reverted.

I don't know... Even if we had a super fast CPU, with low color resolution and bad scrolling there is little more we can do. A better PPU could result in much better graphics, using the same CPU for game logic. With a better CPU, you could use much more time with tricks that would seem to improve the graphics, but not nearly as much as the better PPU. And after wasting so much time with the graphics, you'd pretty much have the same time for game logic as we do know. For some reason, PPU upgrades make more sense to me.

That's what Nintendo have thinked when designing the SNES. The upgraded the CPU by about 2 (can have either M12/8 or M12/6 speed, instead of M12/12 like the NES). The PPU and APU are about 100 times better than NES's, allowing relocatable Name Tables and Pattern Tables in a 32kb VRAM, up to 4 scrolling independant planes with up to 1024 tiles, possible mirroring, and priority bit. It also allow transparency between planes or with a fixed color, and windows clipping. When less than 4 layers are used, 4BP tiles can be enabled for the first 2 layers, allowing much better graphics. (and that not to mention mode 7). The APU is very powerfull and really cannot be compared with the NES' in no way, it is just so different.

If no priority bit is here on NES, an alternate was would be to have clipping windows like the SNES. Set the left side and right side, and clipping is done. That wouldn't be usefull to have priority background in levels, but that would be very usefull for RPG with windows : You have to manually hide sprites that are under the windows. Sometimes, sprites are just on the border and it looks bad because they either "enter" in the window, or are sometimes clipped just outside the window and look even worse. Window clipping would fix it. Unfortunately, it would be needed to do stupid timed code / timed IRQs to change the registers mid-frame, so it would definitely be better to have priority bits.

[jackpkmn]

If there is an emulator with the ability to modify such things then we could accuratly answer these quetsions. Since use of a speedup button in an emularot ups everything that wouldent make a very good prediction. But who knows? I may just be crazy. Also I might be losseing my touch, I dont know as much about this as I used to.

[blargg]

If there is an emulator with the ability to modify such things then we could accuratly answer these quetsions.

We'd also need someone who wanted to try writing code that would take advantage of the new features, and which wouldn't work on the NES architecture (similar to writing iNES-format cartridges that only work on Nesticle and don't work on the NES architecture).

[tepples]

If the new features can be represented in a CPLD or FPGA mapper, then yes, they can be implemented in hardware. Limiting case is a game console that fits in the NES slot and just uses the NES for power and to read the controllers (a la Super Game Boy or Genesis 32X).