Thursday, September 18, 2014

chipspeech Diary, Part 1

In case you haven't noticed, we take hardware research and emulation very seriously here at Plogue.

-We never take any information for granted, whether its from official datasheets, patents or third party research.

-We always double check and investigate what we do on hardware: creating custom tests suites for each and every chip, sending values and capturing the results digitally.

-We then create models and iteratively refine them as we add new tests, often for virtually every possible edge case there is.

You can imagine that this is a long, VERY long process. We sadly never know when our products will ship because simply knowing how an integrated circuit works in and out does not magically make it a product! (stating the obvious)

We started this project 8 years ago but it really started kicking into speed in the last 3. Back then there wasn't a single 'speech chip' plugin out there(at least I think). And there is now a handful of them, and STILL we are not ready to party with the rest of them.

We hope that this new blog series will help you wait a little bit longer for what we hope will be the one that sets the standard, like chipsounds did.


It all began with gathering, or more like compulsive hoarding of nearly every vintage consumer device that talked. We set our start point to 1975,  the date where the first ever speech synthesizer IC reached the market, the TSI Speech+  up to the dawn of the 90's where essentially everything went boringly intelligible. 

How many devices are we talking about?
Quite a lot actually.

Thursday, September 11, 2014

Plogue livenes

Is a Nintendo Entertainment System "homebrew" application that I've developed in order to improve the emulation of the RP2A03 for chipsounds 2.0, which is currently in development.

It allows you to change the values of the APU's memory mapped registers ($4000 to $4017) using nothing but the Nintendo d-pad.

A side effect is that it can also be used to generate live minimalistic 'music' on a NES by manually toggling a bit at a time, which is of course completely unintuitive!

Changing the pitch value for a specific channel on a musical scale implies changing multiple bits at once, something that is clearly impossible here.

As I like a challenge, I tried to see if I could make something remotely musical out of this incredible restriction set. The following piece was recorded live (not sequenced in any way) on a real NTSC NES:

A)The main DMC 'sample' that starts the piece is actually the application code and graphics being interpreted as Delta Modulation.
B)My NES is stereo mod-ed, so there is a slight touch of post mix and reverb, but that's it.

If you want to try it our for yourself you can download the latest .nes ROM here

Revision history:
1.1 Fixed the wrap around on the lower part of the screen
1.0 Initial version

How can you run this on a real NES and not just in an emulator?

1)Put it on a Powerpak
2)Make yourself a nice UNROM (Mapper 2) dev cartridge out of one of those carts
(mirroring is irrelevant). I won't get into the details of that, but here's what mine now looks like:

Thursday, October 10, 2013

chipcrusher re-sampling vs frequency response

Quite a few users have complained about chipcrusher's peculiar 'dry' frequency response compared to what they get with other common decimator plugins. This post hopefully will explain a few things.

Lets say we bypass the bit reduction, distortion and post filtering and only concentrate on the task of downsampling the plugin's input signal. which would be say at 96kHz. and that chipcrusher's re-sampler would be at 44.1kHz, its internal maximum.

There are two important aspects to consider:

1)Typical results achievable using a vintage sampler is very different from 'your typical Bitcrusher VST'.

99% of bitcrushers/decimator plugin out there use the same tired algorithm that was posted more than 10 years ago on This method does NOT band limit the input signal prior to the downsampling, it just sample and holds using a counter... any sample!

This is not what classic samplers did. Any engineer with half a brain at least tried to filter analog audio signal so it wouldn't contain harmonics over the Nyquist frequency of the target sample rate!. If you skip this pass, you will get extra aliasing all over the spectrum.

2)Not all lowpass filters are created equal.

All versions of chipcrusher prior to v1.005(available soon) used a CPU friendly downsampling setting which - in retrospect - might not have suited everyone's taste since it was not steep enough for high frequency content.

You can see chipcrusher's default precision somewhere in this animation made using 96kHz -> 44.1kHz with a white noise as source. All the other settings will be available. We have added a new 'Precision' parameter to set the steepness/cpu use ratio you desire. BTW The first picture in the lot is from a "do not pre filter" setting, we offer 6 such settings, from 6 point spline to truncation. Aliases like crazy, but to each is own.

Saturday, June 29, 2013

Making arcade cabinet impulse responses.

Here are a few pictures we took while capturing impulse responses for chipcrusher in late 2011...
Sorry for the mess, our office is a perpetual hardware dismantling lair.

Thursday, June 6, 2013

GBA SP Speaker Impulse Response

Looks fun? This is what I did for each and every speaker impulse in chipcrusher's Post Processing section.

The goal is to capture not only the frequency response of the speaker itself, but also the effect of its casing and internal components: resonance, cancellations etc.

Its thus very important to make sure to properly close the unit (which can be complicated by the tight confined space) with your soldered speaker leads dandling out without changing the tonal balance of the unit.

A few carefully created test tones are then 'injected' through the leads and recorded with one or more microphones in a mostly anechoic space at a few inches from the device. 

Next the recordings are processed with custom software.

Once thats done, and we are sure the recorded IR data is valid, we need to do the inverse: reopen, unsolder,
close and make sure it works. While the microphones are set up I usually also record native console sounds (games or test code), through that same setup, for later comparison.

Luckily no unit were destroyed, and everything worked just like it did before.

(But you can imagine the stack of devices that I have in the office and in my basement)... there is a psychological condition for that, and also a TV show about it.... Rest assured I ONLY keep tech stuff. :)

Saturday, September 8, 2012

Galaxian's digital oscillator explained.

The Namco Galaxian arcade PCB generates a few different types of sounds:

  1. Analog Fire sound.
  2. Analog Explosion sound
  3. Three Analog 'Rack Noises' (alien drones)
  4. Monophonic Digital Oscillator, which does the quirky intro tune and the aliens being destroyed.

The latter being digitally controlled and generated, it makes it a perfect candidate for the chipsounds bandlimited oscillator generators. The following explains how the digital part is generated:

First, a variable speed pulse is created by using two cascaded 4-bit counters (74LS161) (B). The input clock (2H @ 1.536MHz) is divided by a variable amount according to the last 8-bit value received from the 74LS273 (A)  flip flop. This is done by the Z80 CPU (which runs the game code) when it indirectly sets the !PITCH signal and the required pitch value into the "I/0 & Ram Data Bus" by writing to a specific address in external memory.

This pulse then drives pin 13 of a 74LS393 binary counter (C) which in turn outputs a 4-bit (16 step) binary pattern: 0000, 0001,0010,0011,(...),1111  or  0,1,2,3,(...),15 in decimal.
If those 4 output bits were to be sent to a 4-bit DAC, the result would have been a pretty standard saw waveform with no volume control. But this is obviously not what the Namco engineers wanted...

In this particular design, only 3 output bits of the '393 are used (QA, QC and QD, but NOT QB).
Resistors (D) (15k, 22k, 10k and 33k) are inserted onto the bits to create a weird R-2R 'esque ladder DAC. Also some 'components' of the signal are only added into the DAC depending on two extra
CPU controlled bits (Vol1 and Vol2).  Each driving two of the four available analog gates in the 4066 (E)

If you are following so far you understand that this can generate 4 different waveforms. Once you know this, its relatively trivial using voltage divider maths to figure out what those waveforms would look like.
I used an excel sheet for these maths:

From tests on my board the Vol1 bit is always 0 during gameplay, so logically only the [0,0] and [0,1] waveforms are actually ever used in the game. My guess its that vol1 never gets to be 1 to match the volume of the analog sounds this PCB also generates.

I successfully compared the two available waveforms with actual recordings of the board:

And they were included as oscillators definitions in chipsounds 1.6 under "05 - Arcade/Galax"