Skrasoft Dev Blog

Just a quick post this time… The Pokey module panel graphics are finished and being sent off to get made. Here’s a rendering:

I never really noticed this until I started getting into really low frequencies on the Pokey, but it only actually changes the output pitch on transitions of the current square wave signal. The chip itself can read hundreds of thousands of pitch settings per second, but they are only applied at the next transition of the current square wave. For example, going from a low pitch square wave to a high pitch square wave looks something like this:

The first line is the current square wave output, and what it would do if it ran forever. The second line is an instant pitch change, and the third line is along the lines of what the Pokey actually does. Note that the new pitch data in that example was sent soon before a transition in the low frequency. The worst case is when the new data gets written right *after* a transition, and doesn’t kick in for half a cycle of the low frequency wave:

This implies that the clock dividers driving the logic only update their divide value when they output a pulse. Pokey square waves come from pulsing a T flip-flop, so there are two pulses per output cycle. That means if the current square wave is 1 Hz, the next pitch written won’t happen right away. It can take up to 500 milliseconds to change.

This all came up because of a new feature in the Pokey module design. A Pokey square wave in 16-bit mode with the usual pitch control ranges from about 13.5 Hz to hundreds of kHz. However, the Pokey itself has a bit that can be flipped to drop the range about 4.8 octaves and go down to 0.5 Hz! Initially I planned to have switches on the back of the module for this because I ran out of space on the front. More recently I’ve updated the pitch handling routines to automatically flip that bit as necessary to make the desired pitch. This initially created a slight problem, though, because flipping that bit takes effect almost instantly and drops the current pitch by 4.8 octaves. To go from 14 Hz to 13 Hz, that bit has to get flipped at some point. If the current pitch data is for 14 Hz and the bit gets flipped, the result ends up somewhere inside a 0.5 Hz square. Then, even if the pitch data for 13 Hz is written instantly, it may not take effect until a full second (half of a 0.5 Hz cycle) has passed! In other words, there may be a full second of silence inserted when going from 14 Hz to 13 Hz.

Eventually I came up with a workaround that reliably shortens the silence to about 43 milliseconds when flipping the aforementioned octave-dropping bit. This still creates some audible artifacts when switching between frequencies just above and just below 13.5 Hz, but it lets the pitch CV and knobs control a much greater range without adding any switches.

I made some recording of the worst case switching artifacts. Going from a high note (hundreds of Hz) to a note below 13.5 Hz is not really noticeable. It’s the low frequencies where it becomes clear because of missed/extra pulses when crossing the threshold.

Here’s an example playing two pitches an octave apart that straddle the crossover point:

Click here for audio clip one

This next example is some sweeps that go through the crossover point:

Click here for audio clip two

The more I use the module with this change, the more I like it. It only applies to a channel in 16-bit pitch mode, but there is already a switch on the front panel for that.

There is now one completely-built Pokey module prototype (though without panel artwork). The FPGA code is around 90% done. It still needs some minor usability tweaks and top secret configuration features.

More importantly, I made a few audio clips to show some of the current features.

This first clip plays a major scale on the 6 different wave settings. I’m running a Kenton Pro Solo into the pitch CV input on channel 1. A Doepfer A-141 VCADSR is going into the channel 1 volume CV input. The different types of noise have different amounts of pitchability. The notes that sound like they’re missing in a couple spots are a side-effect of how the Atari chip generates noise. There’s a little more info about why it happens in this post.

Click here for clip one

The second clip runs a Blacet Micro LFO into the CV wave input for channel 1. It’s set to a sawtooth wave to sweep through the different noise types. I’m tweaking two knobs: LFO rate and Atari channel 1 pitch. I also change the pitch resolution of the channel from 8-bit to 16-bit about halfway through, making the trip back down sound less steppy. Each channel has a switch on the front panel to jump between pitch resolutions.

Click here for clip two

The previous two clips have both been one voice by itself. This third clip starts as one voice, but then adds in the second voice slightly de-tuned. I flip the “highpass” switch that gives a nice octave effect, and then over-drive the channels via their volume knobs. The louder one channel is, the more it will modulate the other. The very end is back to one channel.

Click here for clip three

This last clip is more experimental. It combines the Aux input with low frequency noise. The signal path is a Blacet Micro LFO triangle wave into the Pokey synth AUX input. I’m also running one of the Atari channels set to noise at a sub-audio frequency. The low frequency noise creates rhythmic patterns that vary with pitch and modulate the volume of the AUX input. When the rhythm is changing it’s because I’m tweaking the sub-audio frequency and new patterns form automatically. The changes in pitch and timbre are because I’m also tweaking the Sample Rate knob for the aux input.

Click here for clip four

Keep in mind that even though the channels modulate each other to varying amounts, there are three independent channels on this thing mixed to a single output.
Channel 1: Atari oscillator #1
Channel 2: Atari oscillator #2
Channel 3: Aux input

The two oscillator channels are identical in terms of features and controls. The Aux input has a gain/attenuation control and controllable sample rate.

Still chugging along on the Pokey synth module FPGA code. Last night I finished the first draft of the A/D sequencer. The result: knobs work! Based on the current scheme, the sample rates should be:

Pitch inputs: ~40kHz each
Volume inputs: ~40 kHz each
Wave inputs: > 40kHz each
Aux input: ~40 kHz
Sample rate input: ~20 kHz

The pots are sampled in the single-digit kHz range.

Here are a couple quick audio demos:

Audio 1

Audio 2

I made these to check how the channels modulate each other at different settings. I’m just turning knobs on the front panel; there isn’t anything connected to the inputs yet.

Layout finished for the Pokey module main board prototype a month or so ago, and this past Monday two bare PCBs came in. My weeknights have been spent soldering parts and testing power supplies. There are five power rails for running the digital and analog stuff combined. When I was looking at Altera FPGAs, it looked like the design would need seven, but Xilinx parts are more forgiving. I wanted to use a Xilinx Spartan 6, but those are only available in BGA format (ie, impossible to solder by hand) until August. I settled on a Spartan 3A part.

The Soldering Zone

Anyway, this is just a rambling status update. The power supplies are doing what they should and nothing is getting hot. The first audio spewed forth last night, and here’s a clip of what that sounded like:

Click here for a .wav

It’s the same test code I used in this post, just migrated to a Xilinx FPGA and self-contained. It’s good to see that it’s working on a standalone module now instead of just on a dev board. Progress!

Knobs 'n' Lights 'n' Stuff

The three LEDs show “pitch clipping” and whether or not the aux input is available. The pitch inputs take -5 to +5, giving a 10 octave CV span. Since the Atari chip is somewhat limited in its frequency response, there are LEDs to show when the requested pitch is either too high or too low for the chip to handle. There’s a switch on the PCB that lets you control if a clipping channel should either mute or just play its most extreme frequency. Muting is useful for keeping chords in tune.

My next step is to get the A/D converters talking. I’m shooting for at least a 30 kHz sample rate on each of the Pitch and Volume CV inputs. That means pitch input 1 will be updated at least 30k times a second, pitch input 2 will be updated at least 30k times a second, and so on. The finalized sample rates, along with other tech specs like input impedance, will be in the manual.

In terms of overall time frame, I ordered 1000 potentiometers in early May. They take 12-14 weeks to get, putting actual release of the Pokey module in the range of August/September. The FPGA code is currently about 25% complete. Bifurcating technobabble flux capacitor.

While waiting to hear back from Xilinx on some FPGA questions, I started a legitimate FPGA emulation of a Pokey chip. The sound generation hardware is, from what I can tell, completely digital up to the D/A converters. The outputs from different channels on a real chip modulate each other in the analog world, but it should be possible to get most of the way there in an FPGA.

My favorite “problem” with the Pokey is that the same frequency settings at two different times can create different sounds or even go from sound to silence. This happens because the noise generators run at very high speeds, but they are “sampled” by lower speed clocks to generate the output. The net result is 1-bit aliasing that creates predictably unpredictable results.

Obviously any true hardware emulation should have the same problems, so I put together some Verilog based on my current understanding of how the Pokey internals work. If my understanding is correct, I should be able to create patterns from one frequency value that give different timbres or even silence.

For the sake of brevity: it worked! I simulated the engine running with different frequency values until I found frequency values where a low speed clock synchronized with a pattern in the higher speed noise generators. By then jumping to a different frequency and back, the phase of this synchronization shifts and the output pattern changes timbre.

First is an extremely wide output shot from a logic simulation. “N” is the frequency register setting (AUDF in the Pokey datasheet). Several output configurations are shown as the bottom three lines. Notice that N is 3 most of the time, but the shape of T_4_OUT changes each time N jumps to 100 and back.

Sync In, Sync Out

Click the image for a full-scale version.

Next is the money shot. There had to be a case where an output could “disappear” by grabbing a pattern of all zeros or all ones.

Everything and the Kitchen

I’m not vouching that my Verilog code is 100% correct, especially given that it’s based on my understanding of some conflicting/incomplete data. It’s just nice to know that it has the right problems. It’s the good kind of bad, the Powerglove kind of bad.

As a side note, the Pokey datasheet and the De Re Atari chapter (7) on the Pokey contradict each other. De Re shows every distortion setting going through a divide-by-2, while the Pokey datasheet shows that some configurations, in fact, do not divide by 2. I believe the datasheet is correct in this case, though the block diagram in De Re Atari is useful for getting a general idea of the structure. The divide-by-2 settings just seem to mean “run through a T flip-flop.”

Prototype PCBs came in this week for the Pokey synth module front panel. Everything matches the drill test panel nicely. The next step is to get the main board prototype finished, ordered, and built.

Bare Board

Placed Parts

Mechanically Maniacal

I’ve been making hardware changes to the Pokey module so that it can actually be manufactured. Yesterday evening I took a break to write some more Verilog FPGA code for the Pokey controller. The previous test was to write to the Pokey as often as possible, which came out to 1.79 million times per second. This test added a finished start-up routine and tweaks frequency/volume registers to check for glitches.

Listen Here

It is just a simple test. The volume is modulated by a digital triangle wave, and the pitch is modulated by a slower digital triangle wave. Everything works just as expected. There is a lot more stuff I need to port from the microprocessor into Verilog, but it’s going faster than I originally expected. I probably won’t be using dsPIC chips for audio projects anymore after finding out how much more can be done with an FPGA.

In other news, my company is now official. The new name has a better ring to it than “skrasoft,” but I’ll save it for when this module goes on sale. I’m working as fast as I can to start manufacturing without sacrificing any of the features. There are several as-of-yet-unmentioned new features in the FPGA version of the module.

For those who missed it, I posted a test video of the old microcontroller-based module on Vimeo here:

http://www.vimeo.com/9258219

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.