Documentation/tech/cpu/4017.txt

   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.