Some thoughts...
> How easy/difficult would it be to disassemble the
> 80186 code using a standard Intel disassembler?
It should be no harder or easier than any other disassembly project.
You would take the binary images from the PROMS, combine to make a
consolidated image and then run through a disassembler.
You would need to identify things such as the reset vector location, and
start adding symbols for jumps, etc. - until you can get to a version of
the code which you can otherwise identify what parts of it do.
I've always had a irrational dislike of x86 assembler, so I've never
really had too much interest in this myself.
> Is there any documented Polaris code anywhere?
Not insofar as I know.
> ∗Slider 'snap' mode toggle:
Depending on the end goal, it may be easier to implement this with an
external knob/controller interface. The external device can query the
Polaris to find out the current setting of the knob and will then only
edit from that point onwards (e.g., you can use a rotary encoder vs. a
slider where its position has signficance).
That having been said - if you had a fully disassembled image - and
assuming there's space left in the PROMs, the "don't start to change
until you're at the old value" idea doesn't seem like it would be too
difficult to achieve.
> ∗Expander mode:
I'd expect this to be the toughest to achieve (well).
> ∗Reverse pitch bend toggle:
Lever 1 and Lever 2 (as well as the Pedal) are read by the CPU as an
analog voltage (e.g., it comes into the CPU via an ADC). That means, in
software, you could choose to handle the data however you wanted. You
could reverse the sense of the data - or, you could even choose to
assign those levers (or the pedal) to modulate different elements of the
patch.
> ∗Oscillator Mix:
>
> The Polaris has both oscillators at 100% volume
> with no way to adjust their levels. Definitely a hardware
> mod.
Unless there was a desire to make this only a HW setting (e.g., a knob
to adjust mix), this would likely be both a HW and SW mod. The HW mod
would be to allow one of the signals to be attenuated (vs. the other) -
the SW mod to allow some way to control this and to make it a 'storable'
patch parameter.
> ∗Full Resonance Sweep:
>
> Currently the Polaris has 8 levels of filter resonance provided by a
> CEM3372. ... Why this method was chosen is unclear but I suspect
> it might have to do with what is actually pleasing to the ear...
Like the Rhodes Chroma, the resonance is set via 3 weighted resistors.
The processor can individually control whether these are on or off. The
3 inputs lead to 3 bits of control - or 8 discrete resonance steps. The
top-most setting is intended to allow self-oscillation.
To allow fully discrete control would require HW modifications and well
as SW modifications - which would effectively use a DAC to drive the
resonance on the chip vs. the three discrete SW bits.
> ∗Auxiliary Display:
> What I envision is an external LCD display with an
> onboard microcontroller that plugs into the Chroma interface.
> This would display currently edited parameter names...
This actually wouldn't be difficult to do. All that you would need is a
small controller (perhaps a Microchip PIC), a few resistors and a
low-power LCD. I suspect the Chroma Port would have sufficent 'extra'
power for this. The 'effort' on this one would be writing the PIC code,
so that the text which is shown will be what you want to see for the
parameters.
We built something similar to the Rhodes Chroma
(
http://www.rhodeschroma.com/?id=cpuplusalphadisplay); however, prior to
bringing the code into the Chroma's CPU board similar code was running
externally (via the Chroma Port) in a knob box:
http://www.rhodeschroma.com/content/chromaknob/chromaknob5.jpgA later incarnation of that box used a PIC and a four-line LCD display.
The Parallax Model 27979 display was a good compromise for price and
power consumption (and ease of interfacing).
David C.