Might be worth linking to the other thread which addresses related questions:
viewtopic.php?p=37133#p37133

By coincidence, here's a recent blog post describing the PPU and linking to an emulator: reading the source code of an emulator might help a bit.

Might be best to start by understanding - if not in fact building - a simpler system before moving up to something as complex as the NES' PPU. A monochrome bitmap is simpler than a monochrome system with character ROM, is simpler than a colour bitmap, is simpler than character-based colour attributes, is simpler than a tile-based system. Sprites are an extra complexity - Apple and Acorn managed without them, and supported impressive games.

Working backwards, you need to choose a video standard (because your monitor will only sync to some standard timings) and that tells you how many pixels per second need to be output during the active part of the scanline. The earliest systems didn't have frame buffers or line buffers: so they need to fetch video data from main memory (or shared memory) at the appropriate rate, and the video system has to have priority.

(In the other thread, there's some difficulty trying to get both the video and the CPU to have enough memory access without impeding one another - simpler is to give the video priority and stall the CPU. A tradeoff of performance for complexity.)

For a monochrome system, your video logic needs to fetch one bit per pixel. In fact, it will actually fetch in bytes, or perhaps in pairs of bytes.
For a colour system, you need to fetch some number of bits per pixel.

A monochrome system with a character ROM has an extra level of indirection: the foreground/background bits must be fetched from the ROM, with the ROM addresses coming from the main memory (or shared memory.)

A colour system with a character ROM has to fetch per-character colour attributes and use those with the foreground/background information to get the actual pixel values.

A system with tile graphics has to fetch a per-tile index and then fetch data from the tile definitions, and then perhaps fetch colour data from an attribute area.

Summary: sprites and tile graphics are convenient for a low-memory system, but not essential even for video game purposes.

Another complexity to consider is that the NES PPU supports scrolling the image field on a per-pixel basis. A slightly earlier generation of video game consoles (ColecoVision, Sega Game 1000) and similar-era computers (MSX, TI 99/4A) used a video system that could only display a fixed-position tiled image without scrolling.

Scrolling isn't that tough to add, even with a linear framebuffer IMHO. Just add a register which loads a counter each scanline (horizontal scrolling) and frame (vertical scrolling) that determines the starting offset into VRAM when the scanline/frame begins.

I see now that the PPU is not quite as I thought: It has a private VRAM, which the CPU can only access during vertical blank. It helps, then, that the data is mostly tile numbers, not graphic data. The PPU accesses VRAM very intensively during an active scanline, including fetching some data for the following line which it can store internally.
http://nesdev.com/2C02%20technical%20reference.TXT

Definitely not a beginner's video system!

It's a shame that no one (apparently) has seen fit to make a modernized CRTC device a la the venerable Motorola 6845E or perhaps the CSG 8568, which wasn't bad as Commodore I/O devices went. Of course, neither is directly adaptable to modern VGA displays...

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Hi,

I'm currently using something like this

this only shows the video side. The CPU just connects to the "left" side of the dual-port RAM. Any CPU can be used as long as the 55ns access time of the RAM is sufficient. The dual-port RAM provides the Frame Buffer, currently the program in the AVR converts the frame-buffer content to a 24x80 B/W text display. Also the AVR can write to the frame buffer so I can use the dual-port RAM as ROM emulator to bring up a system. The VGA signal is a standard 640*480@60Hz signal. Instead of a 74HC166 you could also use a 3:3:2 R-2R Ladder to create 256 colours.

cheers

Peter

I think you could get a VGA display to accept 6845 input by just doing pixel doubling from 640x480 to 320x240. I.e. halve the clock speed input to the 6845 so the sync times are doubled.

6845 is a wonderful little device, but doesn't make a good pixel-level CRT controller. It is inherently a character/text-oriented CRT controller, and the registers and the addresses it places on the bus are meant to interface to a character ROM as well as VRAM. However, you COULD use it for graphics; the original CGA card uses the 6845, even in graphics mode. The 6845 is not able to address more than 128 rows of characters, where a character is some integer of pixels high (including 1 pixel). Therefore, characters have to be two pixels high to get the required 240 scanline resolution. Because of the way the 6845 counts (it's basically two different address counters, counting at different rates, concatenated together to make a big address counter, along with cursor and sync signals), the CGA framebuffer's even and odd scanlines are split between two address regions. So you really can't do a bulk transfer easily without losing time between scanlines. Not fun :/.

There are two other issues I have with using the 6845 personally:

1. Not made anymore?
2. Was willing to ignore #1, but Garth correctly pointed out in a DM during one of my rants that although the 6845 easily interfaces to a 65xx bus, clock rate is limited to about 2MHz.

Hence my comment about "modernized."

As for graphics, not every display requirement has to include bit graphics. A text mode display is more than adequate for many of the projects we build.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!