You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The PPU IO fetch timing is roundabout correct but definitely off by a couple of cycles here and there. This issue exists to keep track of progress towards achieving full accuracy here and to take notes off my findings so far.
Mode 0 rendering really seems to begin four cycles earlier (at cycle 28 - BGHOFS % 8 * 4 instead of 32 - BGHOFS % 8 * 4). VRAM access likely is done in a pipelined way where the VRAM access happens four cycles after the address calculation.
TODO: does the same also apply for Modes 2 - 5?
WIN[x]H reads seem to happen one cycle earlier or WIN[x]H writes take a cycle to apply.
The former would be weird because we already do the first WIN[x]H read on the first cycle of the scanline.
The latter would make sense if there is a general one cycle IO write delay. This has not been proven to exist yet, however at least a couple of IO registers (IE, IF, IME and TM[x]CNT) seem to have such a delay.
The text was updated successfully, but these errors were encountered:
The PPU IO fetch timing is roundabout correct but definitely off by a couple of cycles here and there. This issue exists to keep track of progress towards achieving full accuracy here and to take notes off my findings so far.
28 - BGHOFS % 8 * 4
instead of32 - BGHOFS % 8 * 4
). VRAM access likely is done in a pipelined way where the VRAM access happens four cycles after the address calculation.The text was updated successfully, but these errors were encountered: