c62d2810 |
1 | This is an email posted to nesdev by Ki a while back. I have removed one |
2 | line at the end regarding the B flag of the cpu(the information was |
3 | incorrect, which Ki noted in a later email). |
4 | |
5 | -------------------------------------------------------------------------------- |
6 | |
7 | By reading Brad's NESSOUND document, we know that there is a |
8 | "frame counter" in the NES/FC APU. I would like to post |
9 | some more on this. |
10 | |
11 | The frame counter is reset upon any write to $4017. It is |
12 | reset at system power-on as well, but is NOT reset upon |
13 | system reset. |
14 | |
15 | Thanks to Samus Aran, we now know the exact period of the |
16 | PPU's single frame. In another words, we are now sure that |
17 | the NMI occurs on every 29780 2/3 CPU cycles. |
18 | |
19 | However, the APU's single frame is NOT 29780 2/3 CPU cycles. |
20 | What I mean by "APU's single frame" here is that it is the |
21 | number of CPU cycles taken between the frame IRQs. |
22 | |
23 | The APU's single frame seems to be: |
24 | |
25 | 1789772.727... / 60 = 29829 6/11 [CPU CYCLE] |
26 | |
27 | Below is a simple diagram which shows the difference |
28 | in periods of the PPU's single frame and the APU's. |
29 | |
30 | |
31 | RESET 29780 2/3 CPU CYCLES NMI |
32 | PPU |------------------------------------------| |
33 | | 29829 6/11 CPU CYCLES IRQ |
34 | APU |----------|----------|----------|----------| |
35 | |
36 | |
37 | Note that if you write $00 to $4017 on every NMI, the frame |
38 | IRQ would NEVER go off even if it is enabled. This is because |
39 | the the period of NMI is slightly shorter than the period of |
40 | the frame IRQ. This causes the frame counter to be reset |
41 | before the frame IRQ goes off. |
42 | |
43 | When you write zero to bit 7 of $4017, the frame counter will |
44 | be reset, and the first sound update will be done after 7457 CPU |
45 | cycles (i.e. 29829/4). 2nd update will be done 7457 after that, |
46 | same goes for 3rd update and 4th update, but the frame IRQ occurs |
47 | on 4th update, resetting the frame counter as well. |
48 | |
49 | When you write 1 to bit 7 of $4017, the frame counter will be |
50 | reset, but the first sound update will occur at the same time. |
51 | 2nd, 3rd, and 4th update will be done after 7457, 14914, 22371 |
52 | CPU cycles after the first update respectively, but the 5th |
53 | update will be 14914 cycles after the 4th update. This causes |
54 | sound output to last 1.25 times longer than that of bit 7 = 0. |
55 | |
56 | |
57 | $4017W: |
58 | |
59 | o when the MSB of $4017 is 0: |
60 | |
61 | bit7=0 |
62 | |---------|---------|---------|---------|---------|---------|---- |
63 | 1st 2nd 3rd 4th 5th(1st) 6th(2nd) |
64 | |
65 | |
66 | o when the MSB of $4017 is 1: |
67 | |
68 | bit7=1 |
69 | |---------|---------|---------|-------------------|---------|---- |
70 | 1st 2nd 3rd 4th 5th(1st) 6th(2nd) |
71 | |
72 | |
73 | On 1st, 3rd, 5th, ... updates, the envelope decay and the |
74 | linear counter are updated. |
75 | |
76 | On 2nd, 4th, 6th, ... updates, the envelope decay, the |
77 | linear counter, the length counter, and the frequency sweep |
78 | are updated. |
79 | ---- |
80 | |
81 | The original info was provided by goroh, and verified by me. |
82 | However, it could still be wrong. Please tell me if you |
83 | find anything wrong. |
84 | ---- |
85 | |
86 | (Correction from my last posting) |
87 | |
88 | I have checked once again and it turned out that the frame IRQ |
89 | was NOT disabled upon system reset. What actually prevented the |
90 | frame IRQ to occur after system reset was, in fact, the I flag. |
91 | I checked this flag shortly after system reset (right after stack |
92 | pointer was initialized), and the flag was 1, although I never |
93 | executed "sei" after reset. Therefore the I flag of the PR2A03G |
94 | is 1 on system reset. |
95 | |
96 | Thanks Matthew Conte and Samus Aran for pointing out the |
97 | inaccuracy. |