Why is the NES init code like this (6502 assembly)?

Question

; We now have about 30,000 cycles to burn before the PPU stabilizes.
; One thing we can do with this time is put RAM in a known state.
; Here we fill it with $00, which matches what (say) a C compiler
; expects for BSS.  Conveniently, X is still 0.
txa
@clrmem:
    sta $000,x
    sta $100,x
    sta $300,x
    sta $400,x
    sta $500,x
    sta $600,x
    sta $700,x  ; Remove this if you're storing reset-persistent data

; We skipped $200,x on purpose.  Usually, RAM page 2 is used for the
; display list to be copied to OAM.  OAM needs to be initialized to
; $EF-$FF, not 0, or you'll get a bunch of garbage sprites at (0, 0).

inx
bne @clrmem

Basically what it seems to do is initialize all the aforementioned addresses with 0, increment x, jump back to the start of the label, fill all the addresses with 1, increment x again, and it happens over and over until BNE is false (so if the Zero flag is 1). So basically when INX happens when X is 0xFF, X will be 0 (right?), and BNE will be false, and it will stop branching and continue down the program. I understand the majority of the rest, but why does it do this with the seemingly random memory addresses? Why 0x000, 0x100, 0x200, etc? And why does this loop happen 256 times? The code after this shows the program waiting for a second VBLANK (NES PPU related), which I kind of get, but what's with the 256 time loop? It states that it needs to burn about 30k cycles, but why in this way?

NOTE: Turns out I wasn't paying attention while reading the code, and I forgot what the STA instruction did for a second when I asked this question. Some of the above information is not correct.

Answer 1

Look more closely at the STA (Store Accumulator) instruction. Given

sta $300,x

it's storing the accumulator into $300+x, and x is incrementing..

So, across successive iterations you're performing:

Accumulator -> $300+00
Accumulator -> $300+01
Accumulator -> $300+02
...
Accumulator -> $300+FF

Why it needs to do this: since there is a required wait time, why not place memory in a "known state". This helps eliminate unpredictable behavior due to bugs later on. For example, in C: an uninitialized pointer always having a value 0 (null) can be helpful.