| 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. |