What would you change about the NES?

[turboxray]

How can the sprite dropout be disabled? I thought it's limited because of timing? There is no way to make it fetch sprites in 0 time.

An updated new PPU.

[lidnariq]

Turns out that any change to how the PPU fetches sprites will cause a compatibility problem with at least one mapper, and possibly several.

You can't take advantage of the extra unused 34th background fetch time, nor the first dummy nametable fetch during sprite fetches, because MMC3 requires that the first fetch be at dot 264. Otherwise its IRQ timing within a scanline will be 4 to 12 pixels too early.

You can't take advantage of the other 7 dummy nametable fetches and stuff more sprite pattern fetches, because MC-ACC and several unlicensed mappers rely on PPU A12 toggling 8 times per scanline.

You can't take advantage of the dummy nametable fetch at the end of each scanline, because MMC5 relies on seeing the same nametable address fetched three times in a row to clock its IRQ.

So the only question can be: what games are you okay with losing compatibility with?

[olddb]

Was the NES designed with mappers in mind or was it an after thought?

[psycopathicteen]

Was the NES designed with mappers in mind or was it an after thought?

I think it was designed with mappers considering the PPU had its own cartridge bus.

[Oziphantom]

bah that was a feature of it being "cheap". Why put extra chips/ shared access/ RAM on board the machine. Just put more pins on the edge connector and then put ROMs on the cart. Makes the machine much cheaper.

[psycopathicteen]

I wish the SNES did that.

[za909]

Here's a few things I would change, mostly I would just correct some of the errata and finish what was left unfinished...

• Fix PPU errata like Sprite overflow flag being unreliable, OAM DRAM should be auto-refreshed, 6-bit RGB color space (like on SMS) but we can keep the 2bpp as is
• Make PPU Slave Mode usable, so that an external PPU could be used... from what I understand the backdrop pixels would be replaced with the picture from the external PPU
• Finish the CPU cycle counter that was found on the die, with CPU cycle or scanline mode, making mapper IRQs irrelevant
• Remove hardware APU envelopes and sweep completely and introduce an 8-step 1-bit "wavetable", basically a configurable version of where the pulse sequences are looked up from anyway. This could give 4 duty cycles + some POKEY-like distortion waves eg. "10110100" and the ability to use the pulse channels as a DAC with "11111111"
• 8-bit DMC frequency divider instead of a lookup table

[sdm]

Add some 'additional' hardware video mode, e.g. 256x192, then the screen size would be 768 bytes, and the free 256 bytes (32x24 = 768 tiles /4 = 2bits per tile = 192 bytes attr table) would be reserved as attribute table so that you could set a separate palette for each 8x8 tile. It would be cool.

[tokumaru]

I think I'd rather they had made the name tables 32x28 (256x224 pixels), leaving 128 bytes for attributes, which would allow for 4 bits of attributes per 16x16-pixel area, instead of just 2. Each of the extra bits could then be used for one of the following:

- Horizontal or vertical pattern flipping;
- Doubling the number of addressable palettes;
- Pattern table selection (giving the background access to all 512 tiles);

Personally, I'd definitely like to increase the number of addressable palettes to 8, giving the background access to all of the palettes (or, if Nintendo was feeling particularly generous, it could add 8 more palettes just for sprites for a total 16). The other bit I'm not so sure... I'm torn between horizontal flipping and pattern table selection.

Other advantages of slightly shortening the screen and name tables to 224 scanlines (which is about what's normally visible anyway) include:

- 16 more scanlines of vblank time (that's 80% more!);
- Slightly less awkward height of 14 metatiles;
- no half-visible attribute blocks when scrolling vertically.

Man, I'm feeling kinda sad now because they didn't go with 256x224... specially considering that some of these improvents wouldn't even have made the PPU any more expensive to produce.

[Dwedit]

That's a neat thought, but it would complicate the fetching sequence a bit, as you'd need attribute information to determine which pixel strip you are fetching from video memory, then conditionally reverse the bits in the fetched byte.

But with one extra bit for palette selection on each of sprites and backgrounds, they could have shared the complete palette.

[Yave Yu]

Use truly four square duty cycles: 12.5%, 25%, 37.5%, 50%.
Use linear channel mixer on APU1.
Add two more color hues, also two more gray, no darker than black but just black.
No PPU mask.

[Pokun]

I guess you would get 8 duty cycles that way (though 4 would just be negated variants). You would need another register with more bits for setting it though.

Colors indeed includes a bit too many useless black duplicates. If they could expand the hues maybe we could get a better yellow.

Why no PPU mask? You mean register $2001 right? It got some of the most essential PPU controls: general sprite/BG blanking and leftmost column sprite/BG blanking.