Search options (Page 5 of 5)

Added NSFe version, since NSFPlay will be supporting NSFe very soon, and it helps keep players from cutting off the long tracks. (Also has track names.)

When resizing, resize it to some integer multiple, e.g. 200%, 500%, 1300%. Otherwise some of the pixels will be wider than others and it will look uneven. If you want a final size that is not an integer multiple, I recommend resizing it to a size larger than what you want, then turn on high quality resizing (e.g. lanczos) and downsize from there.

No, not really. I don't really have any desire to argue what words mean. I only wanted to clarify what I was trying to say, which was that the decision not to use sine was probably not a cost saving measure, and you seem to at least partly agree with this, don't you? I don't think I will get anything out of trying to design/describe an actual sine generator circuit, so please excuse me if I leave off details of that at this point. I'm sure you could do it as well as I can. I was a little confused by the words you were using, but I think we know what each-other means by now.

There are a number of things on the chip that could have been cut with some foresight, I think. The envelope and length counters in particular don't offer much, and the majority of games ignore them. The length counter in particular has a rather large and useless lookup table attached to it. The triangle has its own redundant "linear counter" in addition to the length counter; not sure what that was about.

Another weird thing is that the periodic noise mode was apparently not present in the original run of Famicom units. Not sure what the story is on that one; maybe there was a problem that disabled it by accident that they fixed in subsequent runs?

Lookup tables are fairly simple to implement as logic, I don't know what you mean by "sparing any ROM"; I wasn't talking about a lookup table like you would implement in software. At this scale, it would be similar in logic complexity to things like counters, and I mentioned them as a practical way to do a 4-bit 16-stage sine wave in comparison to the 4-bit 16-stage triangle. My point was that complexity was not the reason they didn't pick a sine wave; they didn't pick it because triangle is superior.

If you really want to know the particulars of the triangle implementation, you might learn how to read the Visual 2A03 project. I personally don't have the skill/knowledge to do it quickly, though, so I've kind of held off on attempting to gain knowledge that way.

The SID is a great chip, and that's a cool article (thanks for linking it). Its design is drastically different though; particularly how it uses one underlying binary counter to output the 3 different waveforms by changing how its bits are output. (Compare to the 2A03 where each channel has a single purpose.) A large sine wave LUT with resolution like the other 3 waveforms would be impractical for this for sure, but a 4-bit/16-step sine wave LUT would probably have been quite doable actually for the SID -- though it would have been pointless to implement such a thing.

It's not necessarily any cheaper/easier to make a saw than a triangle the way they did it. The triangle wave generator is not a CPU running a program; it is a collection of logic that outputs to a DAC, so there is no "processing" or "computation" time in that sense. Oscillators on the 2A03 are not sharing a common processor resource (i.e. time); each one runs in parallel.

I'm not sure whether a saw wave generator would have taken less logic parts, but my intuition is that the difference in this case would have been negligible. I'm certain the VRC6 saw wave has a lot more logic components than the 2A03 triangle.

9H0ST I think has the best explanation. A saw has very strong harmonics which make it harder to blend with other sounds. The triangle is preferred for bassline for the same reason that a bass guitar is usually preferred to a baritone saxophone for this purpose. Similarly, consider a saw wave with no volume control like the triangle. This would probably be about the same level of complexity to implement, but imagine how hard it would be to balance with the other channels. Triangle is pretty hard to balance already, but at least because its audible bandwidth is mostly underneath/separate from the pulse channels it's manageable.

The triangle has no volume control, because it's built very similarly to the pulse channels. Each of these has a 4-bit output; in the case of pulses the DAC is either the square's volume setting or 0. In the case of the triangle, the shape of the triangle has 16 steps, already using its 4-bits of output. It'd be a lot of extra parts to be able to control its volume (you'd need an 8-bit output, and some logic to control the amplitude).

fluidvolt: They actually made a few bad design decisions on the 2A03. The DPCM frequency table is particularly poorly chosen, in my opinion. The length counter table is somewhat useless, as well. The DPCM also conflicts with the data bus used by controllers, so games that use DPCM have to read the controller state 3 times every frame to prevent bad button-press data. (Interesting thread at NESDev about DPCM frequencies here.)

Good album.