Shonumi Wrote:It's great to see aspiring and curious types interested in emulation. Just like ShizZy (Gekko founder) I started with the GB, now I'm working on GC emulation Tongue

Anyway, yeah, you'll want the tutorials from Imran Nazar. Obviously start with the emulated CPU then work your way up. As for tips, here's a few things that you can do to avoid pitfalls and generally have an easier time of it.
Wrap your head around how the CPU works. Learn what registers, opcodes, cycles, stack pointers, and program counters are, and learn them well. It'll serve you well if you move onto other emulation projects
Get used to low-level byte operations. You'll have to use AND, OR, and XOR bitwise manipulators, as well as bit shifting. It's very beneficial to know how to read hexadecimal as well
Focus on getting your CPU off the ground first. While the fun stuff doesn't start until you get to graphics, if your emulated GB CPU isn't up to snuff, you'll be banging your head on something sooner or later. Google for Blarrg's GB CPU tests; they're ROMs meant to test the accuracy of certain instructions. I have a local copy I can upload if you can't find them (he just made a new website early this year, might not turn up in searches).
Imran Nazar's JavaScript GB emu is not cycle-accurate, so don't go off of what it says. Use this CPU manual for accurate timings. It doesn't account for conditionals such as JR NZ (you'll learn what that is), but look at VBAM, ZBoy, or this GB emu if you want readable source code. Personally, the last one has the clearest code.
Get used to the idea of pointers. Many games will read use a 16-bit value to represent and address that should be read from to get the value that will be stored in a register. It may be confusing if you have never used memory management in something like C++, but you'll need to know what you're doing when programming the CPU.
GET A DEBUGGER. This will save your life. Even though it's not totally cycle-accurate, I use JSGB by Pedro Ladaria. You can setup your own offline local version by copying all of the necessary file (jsgb.lcd.js, jsgb.timer.js, etc) This is useful if you want to test your own ROMS instead of the ones provided by the website and thus keep yourself legal.

Now for some pro-tips, i.e. how to avoid major PITA moments:
When doing input, you should never return zero when reading from P1 (0xFF00). This can cause a variety of graphical glitches. You should instead return 0xFF, which means no input is being entered on the P1 register.
The LCD renders per-scanline, so on each HBlank, you'll need to determine which line needs to be draw using which pixels
Opcodes 0x07, 0x0F, 0x17, and 0x1F require you to set Bit 7 of the Flag Register, unlike the extended opcodes (0xCB07, 0xCB0F, etc) with the same mnemonic name.
The GB compares two registers (LY and LYC) to determine if a STAT interrupt should occur. You should compare LY and LYC after you update LY. LY represents the current scanline, so when you enter into an HBlank, update LY by one first, then compare LY and LYC to see if you should raise a STAT interrupt.

I'm always available to personally help you too, so don't be afraid to ask. Additionally, this might be a good read too: http://www.multigesture.net/articles/how-to-write-an-emulator-chip-8-interpreter/ Of course a CHIP-8 emu is not as difficult as a GB emu, but if you want to try something first, or try to get your head around emu-programming, it's a good article to look at.

Shonumi Wrote:but look at VBAM, ZBoy, or this GB emu if you want readable source code.