But this is still not particularly friendly for scrolling, since the wrap around from 288 to 0 and vice-versa has to be handled manually, like we currently have to do between 240 and 0 when scrolling vertically. Keeping all dimensions as powers of 2 greatly simplifies this!
What would you change about the NES?
Moderator: Moderators
Re: What would you change about the NES?
Re: What would you change about the NES?
I'd rework the expandability by bringing expansion audio to the cart connector, switching to a friendlier Famicom-styled expansion port, and in general being less of a stick-in-the-mud about what third parties were allowed to do with the NES's hardware, considering we never got any expansions, not even expansion audio, even though it was "technically" available.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: What would you change about the NES?
You would have enough memory to have attributes for every 8x8 tile instead of every 16x16 tile.Pokun wrote: ↑Sun Mar 06, 2022 5:10 pm Probably, he only has 6 fingers.
Kind of similar to my suggestion, though I'd want it wider as well. But to make sure that the nametable size is that of an integer number of attribute elements is also a good point. If the nametable is 36x32 characters it would be exactly 9x8 attribute elements large. 4 character columns and 2 character rows would be outside of screen, which is enough for the commonly used 16x16 dot metatile size. VRAM would only need to be 1152 byte nametable + 72 byte attribute-table for a total of 1224 byte VRAM. I'm not sure how much cost saving this is though since it might need a custom ASIC for this kind of non-standard RAM size, unless part of the VRAM chip can be shared with other things, like the palette.DRW wrote: ↑Sun Mar 06, 2022 3:07 am My improvement suggestion: Have the name tables be 256 pixels high instead of 240, so that you don’t have unused color attributes and there is no invalid vertical scrolling position range.
Also it would make calculations easier, like when you try to map absolute y pixel positions to the corresponding tile position. Dividing by 256 or 16 just works better than 240 and 15.
Re: What would you change about the NES?
I think that should be configurable because it has the tradeoff of keeping track of 4x as many attributes. That may be too much overhead in some cases.psycopathicteen wrote: ↑Mon Mar 07, 2022 1:03 pm You would have enough memory to have attributes for every 8x8 tile instead of every 16x16 tile.
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: What would you change about the NES?
Since Nintendo only introduced the NES in fall of 1985, and had a product recall in Japan slightly before that time, they could have added marginal improvements in 1985, such as 4 KiB instead of 2 KiB CIRAM. They did add periodic noise after all.
Re: What would you change about the NES?
Yeah, but it might had compromised the compatibility with the earlier games already released at this time.
Ah right, this fixes Y-scroll (and does away with the Y-scroll's 9th bit) but now X-scroll needs manual wrapping. It works well on the Game Boy because the nametable is 256x256 dot while the visible screen is only 160x144 dot.tokumaru wrote: ↑Sun Mar 06, 2022 6:41 pmBut this is still not particularly friendly for scrolling, since the wrap around from 288 to 0 and vice-versa has to be handled manually, like we currently have to do between 240 and 0 when scrolling vertically. Keeping all dimensions as powers of 2 greatly simplifies this!
Yeah that would be a good feature as the BG attributes are one of the more limiting things on the NES. Overhead might be a concern though as Ben Boldt said.psycopathicteen wrote: ↑Mon Mar 07, 2022 1:03 pm You would have enough memory to have attributes for every 8x8 tile instead of every 16x16 tile.
Re: What would you change about the NES?
I already started the same thread in 2006. My answer wouldn't change since then, that is, 16x8 sprites instead of 8x16 sounds like a better idea, especially if it can still put 8 sprites that are twice as wide.
Another great change would have to have the PAL NES more compatible with the original NTSC machine, much like the Dendy is.
Finally, a real IRQ counter would be amazing, and would make a lot of things much easier than they are without requiring any mapper. It would also oppen oportunities to play with sound mixing and $4011 much more easily.
Another great change would have to have the PAL NES more compatible with the original NTSC machine, much like the Dendy is.
Finally, a real IRQ counter would be amazing, and would make a lot of things much easier than they are without requiring any mapper. It would also oppen oportunities to play with sound mixing and $4011 much more easily.
Interesting concept, although scrolling would be improved, some games relies on the scroll being without NT updates. Also, some games relies on the mid-frame NT changes, such as Rad Racer games. Having a fixed status bar while scrolling in any direction would be incredibly though. And the hardware would be much more complex to adress tiles in a 40x40 tilemap than a 32x32 one.If we are to follow the same specs to keep cost the same or lower I think I would keep the 2 kB VRAM but make a single nametable that is a bit larger than the visible screen like on the Game Boy. That way seamless scrolling could be done in all directions very easily and with better use of the VRAM. I suppose 2 kB is not even needed in this case, so it could be trimmed down to lower the cost, two birds with one stone. I would keep the ability for ROM cartridges to come with extra VRAM so that it can be used to swap in a second nametable for raster effects like the 1-screen scroll that the MMC1 can do, and the Game Boy also can do without mappers.
Useless, lumbering half-wits don't scare us.
Re: What would you change about the NES?
That is a neat idea but I don't think it can help the sprites-per-scanline limitation. There are a fixed number of 8-bit sprite fetches for each scanline. No matter how you organize your sprites, the limitation is actually the number of fetches, which equates to "number of sprite pixels per scanline". We often refer to this as a quantity of sprites, since they're always 8 pixels wide. If you do wide 16x8 sprites, the limitation per scanline still stays the same number of pixels/fetches, so now you could only have HALF of those kind of sprites per scanline... In light of this, it makes sense that they put 8x16 the tall way. The mode does not ever chew into any extra of the horizontal limitation.
When fetching sprites in the H-blank, half of them are garbage nametable and attribute table fetches. If they used all the fetches for sprite data, there could be twice as much sprite pixels per scanline. There are probably some technical reasons that the PPU had to follow that pattern of Nametable/Attribute/sprite/sprite.
Re: What would you change about the NES?
The AVS takes 7 of the 8 unused nametable fetches during sprite fetches in order to fetch 15 sprite slivers on each scanline.
Tepples figured out how to adjust the timing for both PPU-internal and PPU-external evaluation to match this.
Even though there are 170 fetches on each scanline, and only 33×4=132 are needed for background fetches, we can't use the whole remaining (170-132)÷2=19 fetches for just sprites because it'll break the timing expected by existing games that use MMC3. The modified fetch timing already breaks MC-ACC (a ÷8 prescaler) because we didn't know how it worked... but at least it's a much smaller set of games.
Tepples figured out how to adjust the timing for both PPU-internal and PPU-external evaluation to match this.
Even though there are 170 fetches on each scanline, and only 33×4=132 are needed for background fetches, we can't use the whole remaining (170-132)÷2=19 fetches for just sprites because it'll break the timing expected by existing games that use MMC3. The modified fetch timing already breaks MC-ACC (a ÷8 prescaler) because we didn't know how it worked... but at least it's a much smaller set of games.
Re: What would you change about the NES?
That is pretty cool. I did not know there was any hardware that did this.
How about doubling each existing sprite fetch? Normally the PPU has to multiplex the address and data lines, which results in each fetch taking 2 cycles. If you were to make a PPU that had more pins and didn’t have to multiplex, would it be ok to double-fetch like this or would it break mappers to do that? I mean, PPU /RD could stay low for the duration of both fetches, and it swaps the address mid-way through.
How about doubling each existing sprite fetch? Normally the PPU has to multiplex the address and data lines, which results in each fetch taking 2 cycles. If you were to make a PPU that had more pins and didn’t have to multiplex, would it be ok to double-fetch like this or would it break mappers to do that? I mean, PPU /RD could stay low for the duration of both fetches, and it swaps the address mid-way through.
Re: What would you change about the NES?
I imagine it could cause malfunction in a memory that samples the address on the falling edge of /RD. I don't know of any particular brands of mask ROM, NOR flash, or SRAM that work this way, but I do remember from a "mod your Pokémon Game Boy cartridge to have immortal saves" discussion that some FeRAMs need to be clocked in this manner. (The tutorial on Imgur doesn't appear to explicitly mention this though.)
Re: What would you change about the NES?
Most stuff can be handled via hardware on the cart.
Things I would add:
A 240 pixel wide mode. I.e. clipped 8 pixels on the left and right. Maybe make it a reg that controls how many 8pixel blocks are blanked on the right and left.
An available mode where color #0 for each subpalette on BG tiles shows the color for that tile. Just like the GB. Yes, sprites can't show behind tiles in this mode but not all games require that anyway.
And while not original base hardware, but Nintendo should have released an NES/Famicom consoles that removed the sprite-line dropout limit.. sometime in like '89 or '90. An NES+.
Things I would add:
A 240 pixel wide mode. I.e. clipped 8 pixels on the left and right. Maybe make it a reg that controls how many 8pixel blocks are blanked on the right and left.
An available mode where color #0 for each subpalette on BG tiles shows the color for that tile. Just like the GB. Yes, sprites can't show behind tiles in this mode but not all games require that anyway.
And while not original base hardware, but Nintendo should have released an NES/Famicom consoles that removed the sprite-line dropout limit.. sometime in like '89 or '90. An NES+.
Re: What would you change about the NES?
The /OBJLBLK flag already takes care of clipping sprites on the left though, what's missing is clipping sprites at the top of the screen.
Yeah I've always thought color 0 is a bit of a waste. For sprite subpalette 0, color 0 would be the same as the backdrop color unless the palette is expanded to get rid of the color 0 mirrors.
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.
Yeah I've always thought color 0 is a bit of a waste. For sprite subpalette 0, color 0 would be the same as the backdrop color unless the palette is expanded to get rid of the color 0 mirrors.
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.