Skrasoft Dev Blog

Most of my hobby time lately has been spent sourcing parts and doing circuit layout for the Pokey module, but yesterday I spent a little more time with the 1-bit D/A I was working on. Spectral plots are in order!

Running the output of the FPGA directly into my soundcard with a couple wires, this is the output spectrum for a 1k sine wave:

Blue Picket Fences

Alright, so that looks pretty terrible. The sine wave data is 16-bit, so the noise floor should be around -96 dB (the bottom line of the graph), yet it’s in the -86 range. There’s also a lot of distortion: both even and odd harmonics.

One potential reason for these problems is that my soundcard probably does not like 25 MHz input frequencies. To help that a little bit, I added an RC filter between the FPGA and soundcard. Using 16 kHz as a cutoff, the new result looks like this:

Noise Censorship

That’s much better. True CD quality would just have one spike at 1000 (for 1 kHz), as 2k, 3k, 4k… are distortions. The worst case offender is just under -40dB, giving this converter noise performance greater than 16-bit, but distortion performance that’s around 7-bit. I do not have an obvious solution for the distortion problem, nor can I prove with my current setup that it *isn’t* just a result of my soundcard not being able to handle the high frequency energy. If anyone has any insights, please add a comment or two.

Like Kicking a Slinky

Several weeks ago, I ported a 2nd order delta sigma D/A converter block diagram from “Principles of Digital Audio” into some Verilog for an FPGA.

The output is a 1-bit logic signal that, when smoothed, matches the input. The human ear does this smoothing naturally, so that slinky-looking wave will actually sound just like a sine wave. Notice that the 1-bit output looks more like an actual sound wave in air: variations in pressure following amplitude.

Delta sigma generates a stream of pulses that have a density corresponding to input amplitude. There is a lot of noise in addition to the input signal, but as long as it’s supersonic it does not audibly matter. I did learn, however, that it can really screw with a microphone preamp. Saying “2nd order” refers to the feedback system the converter uses. Higher orders push more converter noise past the range of hearing.

I ran a digital sine wave generator into my D/A and tied the FPGA pins straight into my soundcard. It was a just a quick sanity check.

Click Here to listen , but be aware it’s just a 1k sine wave

The converter I built was for a 16-bit input, and that recording ended up with a noise floor on par with 14-bit performance. The distortion is pretty high, but that could be clock jitter, a lack of proper filtering, or even the sine wave generator itself. I was just happy that it was making intelligible sound in the very first test on actual hardware.

The Pokey.synth module uses a microprocessor to control the Pokey. It works well, but it is a little slow. In this case, slow means that register writes happen around 100,000 times per second. That means all the sample rates preceding it can’t total more than 100 kHz. Since there are two channels of pitch control, two channels of volume control, and one bit crusher, each ends up with a pretty low sample rate.

The two limiting factors are the speed of the microprocessor and the interface between the micro and Pokey. The Pokey clocks address and data bits on specific edges of its clock, so writes have to either be done slowly or carefully. The instructions in a PIC run at 1/4th the chip’s clock speed, so even a 60 MHz clock can only toggle pins at a rate of 15 MHz. Factoring in everything else the processor needs to do, there isn’t a whole lot left for careful data transfers. The process becomes throwing data onto a bus in the cheapest way that sticks.

Clocking a Pokey at  its standard 1.79 MHz theoretically means it can handle 1,790,000 register writes per second. I had never heard of anyone actually testing that, so I made a project of it in hopes of getting much better FM control. Instead of controlling a Pokey from a microprocessor, I’m now using an FPGA. The nice thing about FPGAs is that they are essentially customizable hardware. I wrote an interface for the Pokey that can transfer data on literally every clock cycle… 1.79 Megabytes of data per second.

The test sequence is a pulse wave pattern done using a single channel’s D/A directly. It writes alternating values of 0 and 15 to the channel. The resulting wave looks like this:

Shark Conga Line

That wave is switching at a full 1.79 MHz. The data is actually switching so fast that the hardware cannot track it well. At audio frequencies the pulse wave looks perfect, but up here parasitic effects slew the square edges into exponential curves. The extra long pulse at the end is because the pattern isn’t exactly 10101010101010… it was simpler to double a data value every few cycles.

I would post an audio clip, but not even your pet bat would be able to hear it.

Tonight I solved a hardware problem with the Pokey module that had been a mystery for quite some time. In celebration, it only makes sense to post about an unrelated change from last weekend.

When the Pokey adjusts pitch on a noise waveform, it can often change timbre completely or even go silent. With analog tuning control, an incoming voltage can end up teetering on the brink of stability between two different sounds. For very slow pitch changes, it can end up sounding like a bad connection.

Click here to hear some “before” pitch changes

A common solution would be to add hysteresis. That is, keep a record of *how* the signal is changing. If it has been increasing and keeps increasing, let it pass as-is. If it has been increasing and tries to decrease, ignore the change unless it is more than some set amount.

That sure is a lot of logic to add, though. It requires looking at the last direction moved, the current direction, and how far it is trying to move. Instead, I went with a simpler approach. I’ll spare the math, but the resulting process looks like the following graph. Red is the noisy input signal and blue is the smoothed output.

Red represents the eternal struggle between order and chaos... or something

It looks just like it’s been low pass filtered, but the overall frequency response has actually changed very little.

Click here for some “after” pitch changes

Listen to how sudden the transitions are now. There is no more loitering between timbres.

I’m currently doing an updated circuit board layout with all the minor changes I made to the prototype. Hopefully in a matter of weeks I will have the first few completed modules to use for demos and beta testing.

Things have grown a little convoluted because of all the projects I’ve mentioned up until now. I’d like to narrow it down to just a few until I can make enough money from selling finished devices to fund further designs. Prototyping is not cheap, so I need to be more realistic.

Pokey synth(s)

The Pokey module for use in Frac and Euro modular synthesizers will be the first thing I release. Right now I have the first prototype up and running, but there are still some circuit changes to make. The good news is that these are all minor. The overall design is working how I envisioned it, including the speed-sensitive tuning controls.

Along with that, I am checking out local manufacturing houses for stuffing the circuit boards. I am trying to have this done locally. There is also the metal work, which got a little more complicated with the addition of the Euro form factor.

I’ve mentioned a Pokey MIDI synthesizer a few times. That, however, is being put on hold. It still needs a considerable amount of DSP written, and I still do not have MIDI working 100%.  It works about 99.99% of data transfers, but there is still an occasional glitch every thousand commands or so that needs to be fixed.

2A03 synth(s)

The 2A03 MIDI synth is on hold until I get a lot more time or some outside help. The 2A03 module (also in Euro and Frac) is the second module I plan to release. On the upside, it should take about 1/4th the development time of the Pokey module. On the downside, it’s been more than a year and a half since the Pokey design was started.

ODB

This is a module I’m making as a break from soundchip modules. Without giving too much away, it is based around concepts of high-fidelity 1-bit audio.

Since every post needs a picture, here’s one from the digital sketchbook:

Still needs a lot of work

I made an Octave script to simulate and graph all the 2A03 sweep unit settings as they change pitch over time. It is based entirely on my understanding of some documentation I found online… no measurements have actually been done. Each staircase represents one iterated combination of bit shifting and clock dividing. Something about the various quantizations weaving in and out of each other is strangely hypnotic.

Sweeeeeeeep

Droppin' Logs

Open them in a new window for the full glory.

As many developers have found, the 2A03 triangle wave registers are missing a relatively important feature: volume control. The noise channel gets 16 steps, the square channels get 16 steps, and the PCM channel gets 128 or so.  As for the triangle channel, it’s either “on” or “off.”

Limitations lead to creativity. The triangle, noise, and PCM channels all share the same output pin on the 2A03. The actual NES audio output design leads to some messy non-linearity. The result is a triangle wave that can be modulated by the PCM channel. I cannot name any games that use this effect, but it is relatively well-known.

So what does it mean?

As the signal on the PCM channel increases, the triangle wave gets quieter. If the PCM channel isn’t being used, it can provide crude volume control.

Under Control

That picture shows the result of a test program that I made. It is a looped series of 128 triangle wave bursts. With each burst, the value on the PCM channel is increased by one. Over 128 bursts the volume drop is noticeable. It can be seen and heard.

Click here to hear the whole thing*

The two large pops (and all the small spikes in the picture) are related to DC offset issues. That is a story for another day.

*+1000 bonus points if you pictured the title screen to Uninvited after the first 2 seconds of this

Wave file here

Most of the 2A03 control tests have been on scopes and logic analyzers, so I did a quick test for actual audio. It does a small frequency sweep for two duty cycles of each pulse channel, some noise bursts, and a small triangle wave frequency sweep.

As has been well-documented all across the Internet, the NES 2A03 is not a sound chip. Though it contains all the Nintendo sound hardware, it is very much a processor that needs properly-formatted program data to run.

For making a real-time synthesizer module that can fit into an analog synth, I want to make the 2A03 behave and interface just like a sound chip. My goal is a register update rate of 200 kHz. According to my calculations, the fastest theoretically possible is around 270 kHz.

To say it a little more clearly, my requirement is that the chip must be able to update the sound hardware 200,000 times per second. The second goal is to have this be as close to real-time as possible. Third, there is no program EEPROM or esoteric dual-port RAM. Lastly, the control system cannot burden the processor that connects to it. Pokey chips, SID chips, et al are able to take simple data and address commands as input. This should behave similarly.

This past week, I finally tested my first draft control system. The test was to write directly to the PCM register as quickly as possible. I used a sawtooth wave to exercise the full range of PCM values, and a square wave to test speed. The result: success at 126 kHz! The theoretical performance should’ve been 128 kHz, which is less than 2% off. The next goal is to get the control system handling 200 kHz. In the meantime, scope shots:

Delicious Linearity

The Usual

Innocence Lost

I’ve been doing tests on a 2A03 to figure the best way to trick it into taking a program generated in real-time. You may wonder why there are so many probes, why some probes seem to probe other probes, or why at least one probe is missing a wire. The reason is simple: for science.