Questions about NES programming and architecture

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

lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Questions about NES programming and architecture

Post by lidnariq »

Color 0 of each sprite palette, and also color 0 of each background palette, is actually transparent.

It's just stored as eight 4-color palettes, but it functions as eight 3-color palettes and a global backdrop color.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Questions about NES programming and architecture

Post by tokumaru »

lidnariq wrote: Tue Aug 18, 2020 5:56 pmIt's just stored as eight 4-color palettes, but it functions as eight 3-color palettes and a global backdrop color.
But the physical memory actually holds four 4-color palettes (background) and four 3-color palettes (sprites), but the only background color 0 that's ever displayed is that of the first background palette, the other 3 are ignored during normal rendering.
User avatar
Secamline
Posts: 44
Joined: Sat Aug 15, 2020 4:25 pm

Re: Questions about NES programming and architecture

Post by Secamline »

tokumaru wrote: Tue Aug 18, 2020 5:50 pm
Secamline wrote: Tue Aug 18, 2020 5:44 pmdoes color 0 of each sprite have to be the same as the background color at $3F00 for the global background color to be displayed properly?
There's no physical memory for color 0 of each sprite, they're mirrors of color 0 of each background palette. When you write data there you're simply overwriting the first entry in each background palette, which is why most people write repeated values.

In my own palette update routines I prefer to skip the mirrored entries (using BIT $2007) and save a bit of RAM.
I didn't expect such an easy explanation!
I also have another unrelated question, I know you can use DMA to transfer one page of data from RAM to VRAM or OAM, but is there another DMA register to copy chunks of data from ROM to RAM like on other consoles? I haven't been able to find an answer on the internet yet.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Questions about NES programming and architecture

Post by lidnariq »

Secamline wrote: Tue Aug 18, 2020 6:07 pm is there another DMA register to copy chunks of data from ROM to RAM like on other consoles?
Nope. It's a conspicuous missing feature with the NES.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Questions about NES programming and architecture

Post by tokumaru »

The only DMA operation that can be done is from PRG memory (RAM or ROM) to OAM, and it's always 256 bytes. It would've been great if they included a way to DMA to VRAM!
User avatar
Controllerhead
Posts: 314
Joined: Tue Nov 13, 2018 4:58 am
Location: $4016
Contact:

Re: Questions about NES programming and architecture

Post by Controllerhead »

Here, uh, something like this would be cool. Maybe just, you know, less terribly drawn.

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

Re: Questions about NES programming and architecture

Post by tokumaru »

Controllerhead wrote: Tue Aug 18, 2020 7:39 pmImage
Time to nitpick: palette entries aren't actually bytes, since NES colors really only need 6 bits. The upper two bits are not retained. This is also true of the attribute byte in each OAM entry: the 3 unimplemented bits do not physically exist in the PPU.
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Questions about NES programming and architecture

Post by Bregalad »

Controllerhead wrote: Tue Aug 18, 2020 7:39 pm Here, uh, something like this would be cool. Maybe just, you know, less terribly drawn.
It's actually not that terrible but I'd ignore entries $3f20 and above - they're totally unused and the only reason they exist was to save hardware in the PPU by decoding less adress lines.

For CPU RAM you only mentionned $0000-$07FF and didn't mention the existing mirror at $0800-$1FFF ; it's exactly the same concept.
Useless, lumbering half-wits don't scare us.
User avatar
Jarhmander
Formerly ~J-@D!~
Posts: 568
Joined: Sun Mar 12, 2006 12:36 am
Location: Rive nord de Montréal

Re: Questions about NES programming and architecture

Post by Jarhmander »

Controllerhead wrote: Tue Aug 18, 2020 7:39 pm Image
Image
((λ (x) (x x)) (λ (x) (x x)))
User avatar
Quietust
Posts: 1918
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Questions about NES programming and architecture

Post by Quietust »

Secamline wrote: Mon Aug 17, 2020 3:19 pm Okay so let's try to keep it simple yet as complete as possible.
Is this better?
Image

An additional nitpick (which apparently wasn't obvious enough in my previous reply): it's spelled "expansion", not "expension".
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
Pokun
Posts: 2675
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Questions about NES programming and architecture

Post by Pokun »

Controllerhead wrote: Tue Aug 18, 2020 7:39 pm Here, uh, something like this would be cool. Maybe just, you know, less terribly drawn.
I think it's pretty good. Only complaint I have is that you use the same term for the backdrop and the background. The red palette entry is the normally used backdrop colour, the two purple ones are the normally unused backdrop colours (they are only used in special circumstances). The grey area contains the palette entries for what is normally called the "background" in the community (it's also called the "pattern plane", the "tile map", the "screen map" and many other things).
User avatar
Secamline
Posts: 44
Joined: Sat Aug 15, 2020 4:25 pm

Re: Questions about NES programming and architecture

Post by Secamline »

Here's a quick update :
Image
Pokun
Posts: 2675
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Questions about NES programming and architecture

Post by Pokun »

Looks good. The PRG MEM would normally be ROM which is booted from since the NES has no internal system ROM, but I guess there are people that makes working ROM-less cartridges just for fun.

The DMA controller is also in the CPU chip I think.
User avatar
Secamline
Posts: 44
Joined: Sat Aug 15, 2020 4:25 pm

Re: Questions about NES programming and architecture

Post by Secamline »

Should I add DMA controller to the CPU then?
I thought I could add a footnote about the FDS at this point. I'm not very well informed about this device even though I own one, but I assume it just loads the data from the disk to an internal RAM, which is connected to the cartridge port just as if it were an actual cartridge. I'm not sure but I guess the system simply sends one part of the code to the CPU and another to the PPU, thus simulating the presence of two chips. Also if I'm not mistaken, the external audio chip that could be found in some Famicom cartridges was built into the FDS itself.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Questions about NES programming and architecture

Post by lidnariq »

Secamline wrote: Thu Aug 20, 2020 5:19 pm Should I add DMA controller to the CPU then?
Does it make things clearer to you?
I assume [the FDS] just loads the data from the disk to an internal RAM, which is connected to the cartridge port just as if it were an actual cartridge. I'm not sure but I guess the system simply sends one part of the code to the CPU and another to the PPU, thus simulating the presence of two chips.
No, there's two physical RAMs inside the FDS base. (Depending, possibly 5. Either way, it's still 32KB of DRAM for the CPU and 8KB of SRAM for the PPU)
Also if I'm not mistaken, the external audio chip that could be found in some Famicom cartridges was built into the FDS itself.
No, there were multiple different expansion audio chips. The FDS had one, as did a bunch of others.

See: nesdevwiki:List of games with expansion audio
Post Reply