Just google "GB CPU Manual" and download the first PDF you find. It's a big read, but has some very thorough info. There are also the infamous Pan docs. The GB uses a modified Zilog Z80, but a handful of opcodes were changed and/or removed; it only uses the Z80's CBxx extended opcodes in addition to the regular ones, so all in all there're less than 512 instructions to emulate.
To save you the trouble, look here: http://marc.rawer.de/Gameboy/Docs/GBCPUman.pdf
Not much on the GB needs HLE. The starting values of the registers and a number of MMIO registers in I/O RAM (0xFF00 to 0xFFFF) need to be set if you don't run the BIOS. I have no idea how the NES' PPU works, but I've heard an NES is around the same level of difficulty as a GB (along with the Game Gear?) though some people found the NES easier, disregarding mappers if you care about accuracy :p
EDIT: Wow, I'm such an idiot. Completely missed that you mentioned the PPU, not CPU. Now that I'm fully awake, I guess I should talk a little bit more regarding what you actually asked about
The LCD itself is easy once you have the timings setup correctly. After the 144th HBlank (GB's screen is 160x144) you merely have to draw the data. You'll need to read the LCDC, Scroll X/Y, and BGP (background palette) registers to start. LCDC reg will tell you where to find the Tile Maps, which hold references to specific tiles. The tiles themselves take 16 bytes of space; each pixel is represented by 2 bits worth of data so you get four possible values (for four different colors, 0b00, 0b01, 0b10, 0b11). The background map is made up of 32x32 tiles, so the total size of really 256x256 pixels, but of course the GB's LCD only displays 160x144 of that. The Scroll X/Y registers tell you how far over you need to move the map. Essentially, you see which Tile Map you're supposed to use, then use the value in the Tile Map to look up a specific tile in a Tile Set, then you draw it to the screen. The only tricky part is that there are two Tile Sets, one that uses unsigned numbers and another that uses signed numbers.
Sprites can obviously be drawn above or below the background. The GB has enough memory for 40 sprites, and only 10 sprites can be drawn on any given scanline. You have to read OAM (Object Attribute Memory) from 0xFE00 to 0xFE9F. Each sprite in OAM has 4 bytes worth of data describing how and where to draw it, as well as where to find the sprite data itself (1: Y coordinate minus 16, 2: X coordinate minus 8, 3: Sprite Tile Number, 4: Various sprite options like above/below background, horizontally/vertically flipped, sprite palette). Sprite image data itself is actually held in Tile Set #1, so you just look up the Sprite Tile Number, then look up the data from that Tile Set. Just like tiles, they have the same format. Sprites, however, can have two palettes, whereas the background only has one. As I mentioned earlier, if you ever write any value to 0xFF46, this triggers a DMA transfer from RAM to OAM. Basically, you copy a large chunk of data somewhere else. I guess this is handier than actually working on OAM directly, but I've never actually made homebrew GB stuff. Additionally, sprites can be 8x8 or 8x16, but I haven't messed around with the latter yet.
I'd suggest reading the manual and taking a look at http://imrannazar.com/ for tutorials to get your head around the concepts, specifically the GPU Timings, Graphics, Integration, and Sprites sections. Imran's code isn't perfect, but at least he explains what's going on (or at least what should be going on with real hardware).
To save you the trouble, look here: http://marc.rawer.de/Gameboy/Docs/GBCPUman.pdf
Not much on the GB needs HLE. The starting values of the registers and a number of MMIO registers in I/O RAM (0xFF00 to 0xFFFF) need to be set if you don't run the BIOS. I have no idea how the NES' PPU works, but I've heard an NES is around the same level of difficulty as a GB (along with the Game Gear?) though some people found the NES easier, disregarding mappers if you care about accuracy :p
EDIT: Wow, I'm such an idiot. Completely missed that you mentioned the PPU, not CPU. Now that I'm fully awake, I guess I should talk a little bit more regarding what you actually asked about
The LCD itself is easy once you have the timings setup correctly. After the 144th HBlank (GB's screen is 160x144) you merely have to draw the data. You'll need to read the LCDC, Scroll X/Y, and BGP (background palette) registers to start. LCDC reg will tell you where to find the Tile Maps, which hold references to specific tiles. The tiles themselves take 16 bytes of space; each pixel is represented by 2 bits worth of data so you get four possible values (for four different colors, 0b00, 0b01, 0b10, 0b11). The background map is made up of 32x32 tiles, so the total size of really 256x256 pixels, but of course the GB's LCD only displays 160x144 of that. The Scroll X/Y registers tell you how far over you need to move the map. Essentially, you see which Tile Map you're supposed to use, then use the value in the Tile Map to look up a specific tile in a Tile Set, then you draw it to the screen. The only tricky part is that there are two Tile Sets, one that uses unsigned numbers and another that uses signed numbers.
Sprites can obviously be drawn above or below the background. The GB has enough memory for 40 sprites, and only 10 sprites can be drawn on any given scanline. You have to read OAM (Object Attribute Memory) from 0xFE00 to 0xFE9F. Each sprite in OAM has 4 bytes worth of data describing how and where to draw it, as well as where to find the sprite data itself (1: Y coordinate minus 16, 2: X coordinate minus 8, 3: Sprite Tile Number, 4: Various sprite options like above/below background, horizontally/vertically flipped, sprite palette). Sprite image data itself is actually held in Tile Set #1, so you just look up the Sprite Tile Number, then look up the data from that Tile Set. Just like tiles, they have the same format. Sprites, however, can have two palettes, whereas the background only has one. As I mentioned earlier, if you ever write any value to 0xFF46, this triggers a DMA transfer from RAM to OAM. Basically, you copy a large chunk of data somewhere else. I guess this is handier than actually working on OAM directly, but I've never actually made homebrew GB stuff. Additionally, sprites can be 8x8 or 8x16, but I haven't messed around with the latter yet.
I'd suggest reading the manual and taking a look at http://imrannazar.com/ for tutorials to get your head around the concepts, specifically the GPU Timings, Graphics, Integration, and Sprites sections. Imran's code isn't perfect, but at least he explains what's going on (or at least what should be going on with real hardware).