Questions about NES programming and architecture
Moderator: Moderators
Re: Questions about NES programming and architecture
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.
It's just stored as eight 4-color palettes, but it functions as eight 3-color palettes and a global backdrop color.
Re: Questions about NES programming and architecture
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.
Re: Questions about NES programming and architecture
I didn't expect such an easy explanation!tokumaru wrote: ↑Tue Aug 18, 2020 5:50 pmThere'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 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.
Re: Questions about NES programming and architecture
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!
- Controllerhead
- Posts: 314
- Joined: Tue Nov 13, 2018 4:58 am
- Location: $4016
- Contact:
Re: Questions about NES programming and architecture
Here, uh, something like this would be cool. Maybe just, you know, less terribly drawn.
Re: Questions about NES programming and architecture
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.
Re: Questions about NES programming and architecture
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.Controllerhead wrote: ↑Tue Aug 18, 2020 7:39 pm Here, uh, something like this would be cool. Maybe just, you know, less terribly drawn.
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.
- 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
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.
P.S. If you don't get this note, let me know and I'll write you another.
Re: Questions about NES programming and architecture
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).Controllerhead wrote: ↑Tue Aug 18, 2020 7:39 pm Here, uh, something like this would be cool. Maybe just, you know, less terribly drawn.
Re: Questions about NES programming and architecture
Here's a quick update :
Re: Questions about NES programming and architecture
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.
The DMA controller is also in the CPU chip I think.
Re: Questions about NES programming and architecture
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.
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.
Re: Questions about NES programming and architecture
Does it make things clearer to you?
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)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 were multiple different expansion audio chips. The FDS had one, as did a bunch of others.Also if I'm not mistaken, the external audio chip that could be found in some Famicom cartridges was built into the FDS itself.
See: nesdevwiki:List of games with expansion audio