Showing posts with label Specs. Show all posts
Showing posts with label Specs. Show all posts

Wednesday, September 13, 2017

Novation Bass Station Schematic

It seems that no one has a schematic of the original Bass Station, so I drew one up. This is from the keyboard version with board markings "Novation Bass Station SM, Issue 4, 1995".

DCO

At the beginning of the signal chain is the DCO. There are two identical DCOs, so we'll just look at one I've dubbed "OSCA".

DCO

At the top is an exponential current source that charges capacitor C10/2. It's built around a transistor pair marked "FMA1". Based on that marking I believe this is the correct datasheet.

At the bottom left is the sync pulse generator. When a pulse or square wave is fed into the "OSCA_SYNC" net a short pulse is output at pin 4 on U20B. The width of this pulse is determined by the RC network formed by R29 and C9. Together they cause a small delay between pins 5 and 6 changing logical state. While these inputs are unequal the output will be high.

This sync pulse enables transistor Q2 to sink the charge stored in C10/2 thereby "resetting" it to VSS. The capacitor is then able to charge back up via the exponential current source. This cycle results in a sawtooth wave that is present on pin 5 of U18B.

U18B serves as a buffer for the sawtooth, but can also be switched to generate a squarewave. Nets OSCA_WF_SW and OSCA can be connected or disconnected via multiplexer U12. If connected the opamp is configured as a noninverting amplifier outputting the sawtooth. If unconnected the opamp is configured as a comparator, comparing the pulse width CV, OSCA_PWM_CV, on pin 6 and the sawtooth on pin 5. This results in a PWM squarewave as pictured below.


Multiplexer
PWM CV

Mixer

Next in the chain is the mixer. The mixer is made of two simple VCAs, one for each oscillator. Each VCA works off of a single linear CV. The mixers serves only to change the relative volume of the oscillators, not to apply the volume envelope.
Oscillator Mixer

VCF

After the mixer is the filter. It's closely related to the OSCar filter that is, in turn, based off of the Wasp filter. It should be noted that the inverting stage present in the OSCar has been removed from the Bass Station. This stage allowed the filter to be switched into a high-pass mode. Without it, the Bass Station is stuck in lowpass mode.

Bass Station VCF
OSCar VCF
I find it interesting that the resonance is under CV control, but cannot be modulated. It does respond to MIDI though.

VCA

Last in the chain is the main VCA. It's another simple, one-OTA VCA. Unlike the mixer VCAs it includes an exponential current source and responds to modulation from one of the envelopes. It also has a trimmer to adjust the offset voltage.
VCA

CV Header

The final thing of note is an unlabeled header. It breaks out most of the internal CV and audio outputs. Almost all of them tap directly after a buffer and, with the addition of a 1K resistor, are safe to connect to other devices.

Unfortunately none of them are really suited to take a signal as input. Nearly every signal would have to be disconnected from its destination and fed through a summing-amp instead. With this summing-amp an external CV signal could then be mixed in with the existing CV.
CV Header

Full Schematic

Here is the majority of the analog section of the Bass Station. I've omitted the dull CV multiplexer and buffers.



Bass Station Schematic




Saturday, October 10, 2015

DR 220 ROM

The DR 220's ROM is partially audio data and partially pattern/miscellaneous data.

The 220 comes in two flavors: 220A(coustic) and 220E(lectric). Most of the differences can be toggled and are contained in the gate array(IC1). The rest are in the sound ROM(IC2).

I haven't bothered breaking down the data portion since it doesn't appear to contain anything too interesting. Some simple tests suggest that it holds pattern/song data, instrument names for the lcd and instrument volumes. The volumes can be increased beyond what the normal interface allows, but it's buggy and can distort.

The audio is encoded as mono, signed, 8bit-packed, 12bit mu-law PCM @ 25KHz. A partial departure from the Roland standard.

None of the address lines nor data lines are jumbled and no samples are interleaved. It's pretty straightforward. Mu-law encoding is the big hurdle.

Mu-law is a logarithmic encoding that was used on some older drum machines: Linn, Oberheim, etc. The idea of it is to exploit our non-linear perception of sound. The encoding gives more precision to lower(quieter) amplitudes that we have better perception of. Conversely is has to remove some detail from higher(louder) amplitudes that we can't discern as well. It's a tradeoff for the more "valuable" part of the signal.

The nuts and bolts of the encoding work like scientific notation. Each number gets translated into a significand(mantissa) and an exponent. In the 220's case, the four least significant bits of each byte are the mantissa, the next most significant three are the exponent and the most significant is the sign bit. For whatever reason, the sign bit is nonstandard for mu-law. If the bit is set the byte must be inverted before being decoded.


TR-505 ROM

The TR-505 is very similar to the 626. Same sound chip, same general design.

The audio is encoded as 8bit, mono, linear PCM @ 25Khz. Standard Roland fare.

The sound ROM(IC11) has a smattering of jumbled data and address lines that makes it hard to read/write. Most of the pins can be unscrambled in software but, the actual chip(TC531000P) has a non-standard pinout. Its A16 is where most 28pin chips have an output enable line. A little rewiring is required to read it and a larger chip is required to duplicate it.

Even with the pins in order, the sounds are still scrambled. The short interleaved samples and the long chunked-up samples are sorted just like the 626, so I'll just reiterate a bit.
The short samples are combined: one sound on the odd addresses and one sound on the even addresses.
The long samples are put into "piles": A,B,C,D. Each pile contains every fourth byte. A has every fourth byte starting from 0, B has every fourth byte starting from 1, C every 4th from 2, D 4th from 3.

As one final point of confusion, A0 is inverted. Some basic glue logic was used to generate A0 (and A13-A16) and it was probably just easier to invert A0 in the ROM rather than invert the signal. Based on the binary I've found, no other address lines are inverted.

Here is the ROM table from the service manual.

TR-626 ROM

The 626's ROM is entirely audio data. Its data bus is wired directly to an R2R DAC and nothing else.

The audio is encoded as 8bit, mono, linear PCM @ 25KHz. This is a standard used by a few Roland machines: 707, 505, etc.

It's the simplest audio encoding and the ROM is effectively a WAV file without the header. Audacity can import it as an 8bit, unsigned, mono "raw binary". If you try this you'll find some recognizable drum sounds, but lots of static and strange noises.

The trouble comes from how the address lines are ordered and manipulated. First off, address lines 6 & 8 are swapped. Since the board is single sided, this was probably done for layout purposes.

The rest of the problems stem from the fact that two gate arrays control different portions of the address bus. IC14 (MB63H114) handles lines 1-12(A1-A12). IC13(MB671189PF) has A0 and A13-A17.

Some of the shorter samples are "interleaved", one sample on the odd addresses, the other on the even. IC13 forcing A0 constantly low(or high), while A1-A12 count normally, will select one of the two samples.

The longer samples (cymbals) are fragmented into 8k chunks. With some experimenting, I found that these chunks are just the opposite of the interleaved samples. They are ordered like dealt cards: 1 card(byte) for hand(chunk) A, 1 byte for chunk B, 1 for A, 1 for B, etc.
So, if you pick the bytes alternately, you'll get the original sample.

The service manual actually explains that this is the result of a kind of "retcon". IC13 is there to give IC14 access to a larger ROM. IC14 was not designed with this in mind. IC14 stops counting up once it reaches its max value of 2^12. IC13 gets around this by assuming the role of the least significant bits(the bits that count up the fastest) and making IC14 count the more significant, "slower" bits. By the time IC14 counts up to 2^12 the combination of IC13 and IC14 has actually counted up to, say, 2^14.

The service manual also gives us a nice table with some confusing naming conventions. The negative address lines indicate that you shift all the other lines left to make room. The A0 column serves to show if a sample is on the odds or evens.