I've been thinking about updating the NESSOUND document.
The purpose of this string is to discuss the topics the document currently doesn't have.
Finally, if there's anyone out there who's been itching to take over control of the almost 3-year-old doc, please speak up.

as it stands, I have:

- $4017 operation
- the $4011 "volume" effect
- minor things (as FluBBa mentioned in another post)

- BT

Does it mention how on the pulse channels, writing $4003/$4007 resets the waveforms or something, causing a pop? It's really noticable in that old Comic Baker cover, and the game 'Demon Sword' uses it as an effect in it's title screen music. It must be caused by the length counter or something.

Ah yes. Matt Conte once posted on the list that writes to $4003/7 reset the duty cycle counter (although in not so specific terms). Anyways, I had never confirmed this, but from what I gathered, it's probably true. This would be another thing I'd add; thanks for pointing it out.

- BT

Another thing. For those of you out there who have written some sort of NSF/NES emulator, and have followed my original sound doc down to a tee, have you ever had a problem with the over-lengthy (or missing) triangle output tones on tunes in Balloon fight? I once had SnowBro (Kent Hansen) e-mail me in regards to it, but I couldn't provide him with an answer. At the time, he had not implemented cycle counting into his NSF emulator, so it was not clear if this was the problem. Matt Conte had suggested that "The problem is that there appears to be a latency between when $4008 is written to and when the linear length counter actually starts its countdown".

Anyways, has anyone ever had a problem with over-lengthy (or missing) triangle channel tones in some games, after implementing the triangle counter as described in the doc? If so, what did you do to resolve the problem?

- BT

Nope, I never had any problems with the linear counter.

With this reported latency, would that mean the output is enabled for a little longer, or the output is delayed?

If it helps any, the shortest value I've ever seen an NSF put to the linear counter is 2 (1/120th of a second). That was done by Rush 'n Attack, on the tune it plays when the guy is parachuting down.

>With this reported latency, would that mean the output is enabled for a little longer, or the output is delayed?

Well, I'm not really sure, since it was a long time ago, and it wasn't me who had the problmem with it. I actually had coded up a crude NSF emu at the time, but I didn't implement full channel features support (like length/linear ctrs, & sweeps), so I couldn't test this alleged latency for myself.

The fact that you haven't had any problems (from what I understand you've written a NSF emu also) would probably indicate that there is no "latency" at all. So, I'll consider this topic nullified. Thanks for the feedback.

- BT

The 'latency' for the linear counter deals with the following (from NESSOUND.txt):

Writes to $4008
---------------
old new mode
--- --- ----
0 X count
1 0 no change (during the write cycle), count
1 1 no change

The "write cycle" does not refer to the CPU cycle during which the write was made, but the 240Hz linear counter cycle during which the write was made.

--
Quietust
P.S. If you don't get this note, let me know and I'll write you another.

>The "write cycle" does not refer to the CPU cycle during which the write was made, but the 240Hz linear counter cycle during which the write was made.

Is this an assumption, or is this somthing you've found to hold true? After all, I wrote the document you quoted from, and when I mentioned "write cycles", although I guess I didn't mention what type, I had CPU cycles in mind (but I was basing this on an educated guess).

Please, if you've confirmed what you've stated (or if it's proven knowledge), then let me know, since it's unclear to me if you know this to be a fact.

- BT

After looking at my data again, your information does seem to explain the reason the original problem was occuring. Thanks for the help.

- BT

Here's a small yet interesting addition... credit goes to Izumi. for informing me about this:

The Famicom's CPU went thru 4 versions. RP2A03E thru RP2A03H (I think US & Europe NES systems only contained 'G' & 'H'?). What's most interesting is that 93-bit looped noise wasn't implenented on the 'E' version.

Here's a small yet interesting addition... credit goes to Izumi. for informing me about this:

The Famicom's CPU went thru 4 versions. RP2A03E thru RP2A03H (I think US & Europe NES systems only contained 'G' & 'H'?). What's most interesting is that 93-bit looped noise wasn't implenented on the 'E' version.

~:: Oh Takuto, my kawaii catgod of fate ::~

> RP2A03E thru RP2A03H ...

Interesting. Over the years, I've literally opened up 100 or more different NES control decks, and never saw any variations on the CPU & PPU part # (it was always 2A03G & 2C02G), and I've seen just about all the revisions of the NES's motherboard (from 3 to 11). Thanks for the tip.

- BT