NES Power On Variance

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

NES Power On Variance

Post by Alyosha_TAS »

Some recent work with the read2004.nes test rom was done by True on TASVideos.org to see what real console results were like.

While it generally worked as expected, in terms of the actual test of the $2004 reads, the initial number of 'FF' at the beginning was pretty variable (and in ways that I'm not understanding.)

For those not familiar, this test by Quietust basically just waits for 4 VBlanks, does an NMI, and then runs the test. The initial 'FF's just indicate where the tests start, one per ppu tick per FF. So this test is an excellent way to characterize power on timing.

The results varied from 0-12 FF. But, what I'm not understanding is that there were more then 8 values possible. Initially I thought that there should be 8 (4 clock alignments x Vblank)

So I started looking at what exactly 6502 does when the rest line is low.

Code: Select all

cycle	ab	db	rw	Fetch	pc	a	x	y	s	p	Execute	State	res
0	0000	a2	1	LDX #	0000	aa	00	00	fd	nv‑BdIZc	BRK	T1	1
0	0000	a2	1	LDX #	0000	aa	00	00	fd	nv‑BdIZc	BRK	T1	1
1	0001	55	1		0001	aa	00	00	fd	nv‑BdIZc	LDX #	T0+T2	1
1	0001	55	1		0001	aa	00	00	fd	nv‑BdIZc	LDX #	T0+T2	1
2	0002	9a	1	TXS	0002	aa	55	00	fd	nv‑BdIzc	LDX #	T1	1
2	0002	9a	1	TXS	0002	aa	55	00	fd	nv‑BdIzc	LDX #	T1	1
3	0003	e8	1		0003	aa	55	00	fd	nv‑BdIzc	TXS	T0+T2	1
3	0003	e8	1		0003	aa	55	00	fd	nv‑BdIzc	TXS	T0+T2	1
4	0003	e8	1	INX	0003	aa	55	00	55	nv‑BdIzc	TXS	T1	1
4	0003	e8	1	INX	0003	aa	55	00	55	nv‑BdIzc	TXS	T1	1
5	0004	e8	1		0004	aa	55	00	55	nv‑BdIzc	INX	T0+T2	0
5	0004	e8	1		0004	aa	55	00	55	nv‑BdIzc	INX	T0+T2	0
6	0004	e8	1	INX	0004	aa	55	00	55	nv‑BdIzc	INX	T1	0
6	0004	e8	1	INX	0004	aa	55	00	55	nv‑bdIzc	INX	T1	0
7	0005	e8	1		0005	aa	56	00	55	nv‑bdIzc	BRK	T0	0
7	0005	e8	1		0005	aa	56	00	55	nv‑bdIzc	BRK	T0	0
8	e8ac	00	1		e8ac	aa	56	00	55	nv‑bdIzc	BRK	T0+T1	0
8	e8ac	00	1		e8ac	aa	56	00	55	nv‑bdIzc	BRK	T0+T1	0
9	00e7	00	1		00e7	aa	56	00	55	nv‑bdIzc	BRK	T0+T1	0
9	00e7	00	1		00e7	aa	56	00	55	nv‑bdIzc	BRK	T0+T1	0
10	00ff	00	1		00ff	aa	56	00	55	nv‑bdIzc	BRK	T0+T1	1
10	00ff	00	1		00ff	aa	56	00	55	nv‑bdIzc	BRK	T0+T1	1
11	00ff	00	1		00ff	aa	56	00	55	nv‑bdIzc	BRK	T0+T1	1
11	00ff	00	1		00ff	aa	56	00	55	nv‑bdIzc	BRK	T0+T1	1
12	00ff	00	1	BRK	00ff	aa	56	00	55	nv‑bdIzc	BRK	T1	1
12	00ff	00	1	BRK	00ff	aa	56	00	55	nv‑bdIzc	BRK	T1	1
13	00ff	00	1		00ff	aa	56	00	55	nv‑bdIzc	BRK	T2	1
13	00ff	00	1		00ff	aa	56	00	55	nv‑bdIzc	BRK	T2	1
14	0155	00	1		00ff	aa	56	00	55	nv‑bdIzc	BRK	T3	1
14	0155	00	1		00ff	aa	56	00	55	nv‑bdIzc	BRK	T3	1
15	0154	00	1		00ff	aa	56	00	55	nv‑bdIzc	BRK	T4	1
15	0154	00	1		00ff	aa	56	00	55	nv‑bdIzc	BRK	T4	1
16	0153	00	1		00ff	aa	56	00	55	nv‑bdIzc	BRK	T5	1
16	0153	00	1		00ff	aa	56	00	55	nv‑bdIzc	BRK	T5	1
17	fffc	00	1		00ff	aa	56	00	52	nv‑bdIzc	BRK		1
17	fffc	00	1		00ff	aa	56	00	52	nv‑bdIzc	BRK		1
18	fffd	00	1		00ff	aa	56	00	52	nv‑BdIzc	BRK	T0	1
18	fffd	00	1		00ff	aa	56	00	52	nv‑BdIzc	BRK	T0	1
19	0000	a2	1	LDX #	0000	aa	56	00	52	nv‑BdIzc	BRK	T1	1
19	0000	a2	1	LDX #	0000	aa	56	00	52	nv‑BdIzc	BRK	T1	1
Basically it holds the current operation and waits to see a high RES line during phi2 (similar to other interrupt behaviour.)

So, if reset happens to be released during phi1, there could be up to an entire CPU cycle of mismatch between when the CPU reacts and when the ppu reacts.

I haven't found a way to investigate reset like this on Visual 2C02, is this possible? If it turns out that the ppu resets faster, it could add another variable to start up state. This is important in TAS since games don't tend to self sync to a single ppu tick like Blargg's test roms do!

Does anyone have any thoughts or added information about this?
Post Reply