There are 3 (very broad) possibilities.
1) Your emulator implements some hardware behavior incorrectly (bad CPU instruction, bad timer, bad memory writes/reads, bad interrupts, etc) which causes the data in VRAM to become corrupted.
2) VRAM is not corrupted, however, the way your emulator renders VRAM data as an image is incorrect.
3) Your emulator implements some hardware behavior incorrectly
and the way your emulator renders VRAM data as an image is incorrect (double whammy!)
#2 is the easiest to check. Just grab another emulator with a debugger and compare the bytes in VRAM (you can print yours out as a log file, might even be a good idea to bind that to a hotkey to do it on command). If your bytes match something like BGB, then you know the issue is with rendering. Otherwise, you know your emulator is writing incorrect bytes into VRAM, and the source of that problem could be anywhere.
Fortunately, #1 is easy to trace. Simply choose a corrupted tile, and observe all writes to VRAM for that tile. Your emulator will diverge from something like BGB, but with BGB's debugger, you should be able to figure out why. E.g. this is how I go about debugging stuff, question and answer style. The below example is hypothetical; use it as a reference for yourself on bug-hunting.
Code:
* Is my emulator's VRAM the same as BGB's?
- No, 1 byte at 0x8800 is 0xFF in my emulator when it should be 0x00
* When does my emulator write 0xFF to 0x8800?
- Using log files, it wrote 0xFF to 0x8800 at PC = 0x1000 :: LD (HL), A. HL at that time = 0x8800, A = 0xFF
* When does A equal 0xFF before this instruction in my emulator?
- A is set to 0xFF at PC = 0x9F0 :: LD A, (DE). DE = 0xC000 at that time.
* When does the byte at 0xC000 equal 0xFF before this instruction in my emulator?
- ...
So on and so forth. Eventually you'll run into a point where your emulator and BGB were giving the same results, then they split. Once you find that split, you'll also find the source of your problems. My advice is to see if you can at least pass blargg's CPU tests first. The output may be somewhat obscure, but as long as it lists "OK" for each test, that should be good enough to correctly boot up Tetris.