Miliox/gist:7171d74917d6c7e9ea992051a031d3de

## gistfile1.txt
There are many small errors or discrepancies in the docs listed above, unfortunately I don't know if/how those docs are maintained so I'm going to list the errors I've found here for now:

    RLCA instruction: various sources disagree on whether the Z flag should be modified by the operation. After some research I'm pretty sure it shouldn't be modified (the Z80 processor for instance does not modify Z).

    HALT instruction: when this instruction is executed while interrupts are disabled in the CPU (for instance by a DI instruction) the CPU will still be awoken by any interrupt enabled in the IE register, however the interrupt handler will not be run and the control will be given back to the code that called the HALT. Be careful that the instruction following an HALT is glitchy but that's well documented.

    ADD SP,N (opcode 0xe8) and LDHL SP,N (opcode 0xf8): the values of the carry and halfcarry are computed on the low 8bits.

    RLCA, RLA, RRCA, RRA instructions: the flags are described wrong in the CPU manual: after the execution C contains the rotated bit while N, H and Z are always 0. The equivalent instructions in the extended CB opcode space however set Z if the result is 0 and that's correctly documented.

    Instruction timings: The GameBoy CPU manual gets all the timings of conditional branches wrong: it doesn't say that the number of cycles taken by the instruction to execute depends on whether or not the branch is taken. More generally, both this manual and the opcode map linked above have some discrepencies when it comes to instruction timings. In the end it's probably safer to use the timings directly from the assembly source for the accuracy tests.

    The actual state machine for the configurable GPU LCD interrupt seems not well described anywhere. I tried to put a lot of comments in my code to describe my approach, however I'm not sure whether it's 100% accurate.

    When there are more than 10 sprites on a line only the 10 first in OAM order are displayed. The sprite's X coordinates and priority don't matter, only the position in OAM.
	There are many small errors or discrepancies in the docs listed above, unfortunately I don't know if/how those docs are maintained so I'm going to list the errors I've found here for now:

	RLCA instruction: various sources disagree on whether the Z flag should be modified by the operation. After some research I'm pretty sure it shouldn't be modified (the Z80 processor for instance does not modify Z).

	HALT instruction: when this instruction is executed while interrupts are disabled in the CPU (for instance by a DI instruction) the CPU will still be awoken by any interrupt enabled in the IE register, however the interrupt handler will not be run and the control will be given back to the code that called the HALT. Be careful that the instruction following an HALT is glitchy but that's well documented.

	ADD SP,N (opcode 0xe8) and LDHL SP,N (opcode 0xf8): the values of the carry and halfcarry are computed on the low 8bits.

	RLCA, RLA, RRCA, RRA instructions: the flags are described wrong in the CPU manual: after the execution C contains the rotated bit while N, H and Z are always 0. The equivalent instructions in the extended CB opcode space however set Z if the result is 0 and that's correctly documented.

	Instruction timings: The GameBoy CPU manual gets all the timings of conditional branches wrong: it doesn't say that the number of cycles taken by the instruction to execute depends on whether or not the branch is taken. More generally, both this manual and the opcode map linked above have some discrepencies when it comes to instruction timings. In the end it's probably safer to use the timings directly from the assembly source for the accuracy tests.

	The actual state machine for the configurable GPU LCD interrupt seems not well described anywhere. I tried to put a lot of comments in my code to describe my approach, however I'm not sure whether it's 100% accurate.

	When there are more than 10 sprites on a line only the 10 first in OAM order are displayed. The sprite's X coordinates and priority don't matter, only the position in OAM.