Hi. Here I am with a million questions again. Sorry if its quite
bothersome ^_^ . If you're wondering how I come up with so many questions, or
why I seem incoherent in some places, that's because I type this thing up at
home, offline, and add a question whenever something comes to mind.

********************
SPRITE QUESTIONS:
********************

How does sprite #0 hit detection work in detail? I know that it the bit is
set when a non-transparent pixel of sprite #0 is drawn on a non-transparent
BG-pixel, but what happens when:

1) Sprite #0 is drawn on another sprite (collision with another sprite, not
the BG). Assuming the sprite is ON TOP of the BG.

2) Sprite #0 collides with a sprite BEHIND the BG.

3) Sprite #0 is the 9th sprite on the line. i.e. it was never drawn, but a
BG collision would've occured if it had been drawn.

4) Same as 1) and 2), except that the background is turned off (sprite
collides with another sprite, but no BG)

5) Same as 1) and 2), except that Sprite #0 collides with a "NOT DRAWN"
sprite (9th sprite on the scanline)

6) Either sprites or BG are turned off, but a collision would've occured had
they been turned on. And also what would happen if both were turned off.

And is the sprite #0 hit bit cleared when $2002 is read? The only doc I read
that says that it should is Marat's nes.doc .

Also, in what order are sprites drawn? I know they're prioritized 63->0, what
I meant is that, Y0shi's nestech doc says that the sprites behind the BG are
drawn first, then the BG, and then the sprites that are on top of the BG.
What will happen if 8 sprites (behind the BG) [but are on the right half of
the screen], are on the same scanline as another 8 sprites (on top of the BG)
[which are on the left half of the screen]?

Here's a visual representation:

.....oooooooo....xxxxxxxx.....

Legend :
.... = current scanline
o = a sprite on top of the BG
x = a sprite BEHIND the BG

If I follow the drawing order low_priority_sprite -> BG -> hi-priority sprite
then the sprites "xxxxxxxx" will be drawn first, and "oooooooo" will not be
drawn since the 8 max sprites are maxed out. However, if I follow a
left-to-right pixel draw order, "oooooooo" will be drawn first, and
"xxxxxxxx" will not be drawn. Does anyone know which is which?

Also, when reading PPU memory, there is always a "garbage" read before the
real data (i.e. pipelined), right? Is this also true for the Sprite RAM, or
is the data available immediately? Same question goes for the palette data.

And if they share that behavior, do they also share the same pipeline?

********************
MID-FRAME/SCANLINE QUESTIONS:
********************

Reading Chris Covell's nestech faq, I read that turning off the BG, changing
color emphasis and/or switching to mono can be reflected in the middle of a
scanline. Having written my render routine as scanline-based, this presents a
great problem. Does any emulator actually emulate this PPU feature?

Also, by how much does a color emphasis bit darken the un-emphasized color?
i.e. if I emphasize red, what percentage should I multiply the green and
blue components?

I read in Brad's PPU addressing doc and loopy's scrolling doc that the vram
address is not updated from the temporary 15-bit latch(?) when rendering is
disabled. Does this mean that if BG is enabled but sprites are disabled, then
the vram address won't be updated? What if sprites are enabled, but BG is
disabled? (i.e. do updates NOT happen when some rendering is turned off, or
only when ALL rendering is turned off?)

Are the speed benefits of using a single scanline buffer (instead of a whole
screen buffer) very huge? I'm planning to implement this, but it seems like
my emulator would have to lose the "VSync" feature.

********************
SOUND QUESTIONS:
********************

Where do I start ? I just want to hear the 2 square wave channels first, and
I think I can work it up from there. What do I need to do to emulate it (no
other channels, and if not needed, no IRQs either, yet.) ? I'm just totally
lost in Brad's NESSOUND doc.

And I'm just wondering about the wavelength being 11-bit. Not really a
question ^_^ .

Also, I was looking NESticle's "view wave output" (more like staring at it
for several hours, actually). What's a good way of doing this?


Der Wille zur Macht
Chikara e no Ishi
"The Will To Power"

Can't help you with anything graphics related... but...

As for sound... Brad's doc really covers it all. It might seem overwhemlimg at first (I had to like study it for days and days until I was able to make any sense out of it)... but if you stick with it, eventually it'll make sense.

As for viewing a wave output of NESticle... don't really think that'll help you much. But maybe it will give you an understanding of how the waves are supposed to look.

Square waves are called Sqare waves because they resemble squares =P (simple enough). That means your output is going to look something like:

000088880000888800008888

If you draw a line using those points, it will look like a repeating box in a square or rectangular shape. That's the kind of wave that the square channel generates.

Triangle goes like:

0123456789ABCDEFFEDCBA98765432100123...

which makes like a zig-zag or triangular shape.


Noise is very similar to the square wave.. only the length of the generated wave is pseudo-random, so it sounds like fuzz.



Anyway, to get the basics on how the square channels work, here's a sloppy diagram to show how it goes (note I'm just trying to give the idea of how this works, this probably isn't an accurate representation of what really goes on inside the NES):

NES Clock signal -> Programmable Timer -> Duty Cycle Generator -> Volume -> Output

- The NES sends a clock signal every cycle (1789772.7272 times a second)
- that signal decreases the counter in the programmable timer (wavelength).
- When that counter hits zero, the counter is reset (to the wavelength value written to the registers), and the Duty Cycle Generator is clocked
- When the duty Cycle generator is clocked, a 16-step counter is incremented.
- If that duty cycle counter is less than the current duty cycle, the current volume is output, otherwise 0 is output.

The other parts of the square wave (envelope/decay, length counter, sweep unit), work independantly of the above.

Envelope/decay (when active) alters the volume level.
Sweep Unit alters the Programmable Timer
Length Counter can shut off the whole channel (force output of zero)

Envelope/decay, Sweep Unit, and Length Counter are all triggered by clocks sent by the Frame Counter, which (as said above) works somewhat independantly from the other sound hardware. It even gets clock signals at a different rate (about 240 Hz).

Once you understand how the flow works, Brads doc suddenly makes a WHOLE lot more sense. I hope I helped clear it up.

I'll try to answer some of these from what I know.

1. Nothing happens. Only sprite #0 to BG collisions are detected. If you mean both sprites are on top of the BG, then it would still be a hit.

2. It can't collide with another sprite, but if it's behind a BG tile then I think it would collide with that. But I've never tried putting sprite #0 behind the BG, so I'm not sure.

3. sprite #0 is the highest priority sprite and will always be drawn. If sprites 0 - 10 were on the same line, 0 - 7 would be the ones that are drawn.

4. nothing happens, nothing to collide with.

5. depends only on the background.

6. no collision can happen unless sprites and BG are both enabled.

I believe it is cleared when $2002 is read. Code to wait for a sprite #0 collision waits until that bit is set, then waits again for it to be cleared.

With the sprite priorities, the X position of the sprite isn't important. The PPU has temporary memory to place 8 sprites, for each scanline it will start at the top (sprite 63) and keep loading each sprite that's in range into it's memory until it's checked all of them. So in your example, the ones to be rendered will be the ones that are lower in memory.

About reading sprite-RAM, I have no idea. I don't know if any games even touch the $2004 register directly. From a programmer's point of view, reading/writing normal RAM and using the sprite DMA is much more convenient in almost every situation I can think of.

mid-scanline stuff:
Yes, there are a couple emulators that come to mind that support mid-scanline stuff. Nintendulator and Nestopia. If you mostly want your emu to run games, scanline-based PPU rendering should be fine for probably 99% of the existing stuff. Pirates! is one game that comes to mind that uses mid-scanline changes.

The VRAM address will be updated if either sprites or BG is enabled. I'm not sure about the color emphasis and other stuff.

I hope this info helps. If I'm wrong about anything, I'd like to be corrected.

> I believe it is cleared when $2002 is read. Code to wait for a sprite #0
> collision waits until that bit is set, then waits again for it to be cleared.

No, it actually stays on and doesn't get reset until the PPU starts rendering the next frame. In Years Behind, I used this "feature" to be able to have two syncpoints. The NMI first does stuff that takes a variable # of instructions and then waits for the sprite hit bit to CLEAR. It then runs the timed scanlinecode for n number of scanlines and then displays the volume window where again a few variable # of cycles routines are called, after which it waits for the sprite hit bit to be SET.

I'm unsure of exactly when the bit actually gets cleared though. Just that Nintendulator doesn't do it right. (at least not for PAL)

// Bananmos