ChromaTalk Archives: August 2000

• New Articles (3 messages)
• Chroma power supply upgrades (7)
  • PSU upgrade - reset board: LAST CALL
• Phil? (3)
• Mailing List Moved (2)
• Chroma for sale (3)
• Dying ROMs? (2)
• Hello, and Newbie question. (15)
  • Interfacing
  • Velocity Steps
  • Newbie question resolved
• Comparison - Rev 12 vs Rev 14 firmware (2)
  • Comparison - Chroma Rev 12 vs Expander Firmware
• When Threshold = value, etc.
• Expander
• Power Supplies that Need to be Turned on More than Once

New Articles

Chris Ryan [21030691] · Sun, 6 Aug 2000 16:51:16 -0700

I've posted two new articles by David Clarke: "ChromaKnob" describes his "more intuitive and more easily used programming interface" custom built hardware add-on for the Chroma that he was telling us about a couple of months back.

"Keyboard Velocity Curves" analyzes the way the keyboard scanning processor works between firmware revisions.

Thanks, David!

Chris

Don Tillman · Sun, 6 Aug 2000 19:34:35 -0700 (PDT)

"ChromaKnob" describes his "more intuitive and more easily used programming interface" custom built hardware add-on for the Chroma that he was telling us about a couple of months back.

Wow. This is really, really nice.

-- Don

Don Tillman
Palo Alto, California, USA
http://www.till.com

Dave Bradley [16330135] · Sun, 6 Aug 2000 19:34:35 -0700 (PDT)

Where do I order mine??!!!

That thing is so cool, it's just crying out for one of those engraved Schaeffer front panels.

Dave Bradley
Principal Software Engineer
Engineering Animation, Inc.

Chroma power supply upgrades

Mike Maloney · Sun, 6 Aug 2000 22:31:30 -0400

I've finally decided to bite the bullet and upgrade the power supplies in all my Chromas.

With Don Tillman's gracious permission, I'm going to have circuit boards made up for the reset circuitry based on his "Nuclear Powered Chroma" article. If there are any others interested in doing this, I'm willing to get additional boards made, which I will sell at something resembling the real cost of manufacture, shipping, and handling.

If there are enough people interested, I may also be willing to kit up all the necessary parts to do the transplant. (The incentive for me doing this is to get enough people on the train to get a break on parts).

If you are interested in doing this, please let me know. For budgeting purposes, expect the total cost of this upgrade to be in the neighborhood of $185.00 each if you are daring enough to try it yourself, more if you want to pay someone qualified to do it for you. This can be brought down a little if enough people buy in. Unless you are handy with electronics or don't care if you blow up your Chroma, I'd suggest having someone do it for you.

I'll polish up some details if there is enough response. There is no timetable for making this happen, just "reasonably soon".

Mike Maloney

Dave Bradley [16330135] · Mon, 7 Aug 2000 09:38:13 -0500

I'm interested. Does your $185 estimate include the cost of the switching supply, or is that just the cost of the reset board (gulp)?

Mike Maloney · Mon, 7 Aug 2000 13:27:34 -0400

Oops - didn't mean to scare you. Yes - This includes the switching supply (that's the big money), circuit board, parts, wire, connectors - everything, plus it a healthy margin of error. I just didn't want to start sharpening the pencil before I had defined the full scope of the project, had some ideas on quantities, etc.

Dave Bradley [16330135] · Mon, 7 Aug 2000 12:55:25 -0500

Cool. I'm in.

Fredrik Beckmann · Mon, 7 Aug 2000 23:26:47 +0200

Hi Mike!...

I'm not that familliar with the Hi teck. Why does one need that upgrade of the Chroma Powersupply?!...

Dave Bradley [16330135] · Mon, 7 Aug 2000 16:42:47 -0500

Fredrik, see this article:
http://www.till.com/articles/ChromaPowerSupply/

Mike Maloney · Fri, 18 Aug 2000 19:11:01 -0400

PSU upgrade - reset board: LAST CALL

About two weeks have passed, so I'm about ready to say every body has spoken up. Come Monday morning, I'm going to get the PCB house working on the reset boards. So if you want in, let me know NOW!

Pricing Status:

Since we don't have the quantities required to command any discounts (the switching supply was the thing I was hoping to save some money on), I'm going to go on and fix the prices on this stuff. Just the circuit board, schematics, parts list: $7.00 + S/H reset board assembled, tested, mother approved: $25.00

[begin disclaimer mode]
BEAR IN MIND: I'm not in the business of creating easy to assemble kits, with solder by number instructions. I'm not offering unlimited tech support or anything like that. If you don't have a decent meter, know the brand of solder by smell, or if you have any doubts at all, buy the assembled version. It's cheap compared to the frustration you can cause yourself and the resentment you might feel towards me. I'm not trying to suggest that this is some difficult assembly job, just wanted to let you know that owning a soldering iron does not necessarily qualify one to use it. If you screw up, you could seriously damage a valuable and rare instrument.
[end disclaimer mode]

Allied Electronics has the requisite Power One MAP80-4000 switching supplies for $148.00. Add Molex connectors and a bit of wire and you are set with a stable new supply for your Chroma. So it looks like the original $180-ish to do the whole treatment is pretty accurate. A bit less if you solder up the board yourself.

I'll finalize any remaining details in the next few days, and will contact anyone directly who expressed interest.

Mike Maloney

P.S. If you didn't catch my prior posts, and are wondering "What is this guy babbling about anyway?"

The most common failure in the Chroma is the power supply. Don Tillman wrote a great article on replacing the questionable supply with a modern switching supply, the details of which are available at http://www.till.com/articles/ChromaPowerSupply/. The upshot of it is that you get a far more stable and reliable power supply, and your Chroma weighs less. With Don's permission, I'm getting circuit boards built for the reset circuit that enables you to use an off-the-shelf switching supply for the Chroma, and I'm offering the Chroma community a chance to get on the train.

Phil?

Dave Bradley [16330135] · Mon, 7 Aug 2000 09:41:26 -0500

Any word on answers for the interview questions for Phil Dodd yet?

Chris Ryan [21030691] · Mon, 7 Aug 2000 17:36:17 -0700

I haven't heard from him for a while. I sent him a message today asking about it.

Chris Ryan [21030691] · Mon, 7 Aug 2000 20:37:46 -0700

Just got a reply; he's busy with a big project until the end of the month. I'll post the interview as soon as it's done ...

Well, it turns out it wasn't done for almost two years, for a variety of reasons. See Philip Dodds/Tony Williams Interview for the end result.

Mailing List Moved

Chris Ryan [21030691] · Mon, 7 Aug 2000 16:14:57 -0700

Hi everyone,

I've finally found a new home for ChromaTalk (which has existed on my California ISP since I moved back to British Columbia last October). Neil Bradley of Synthcom Systems has very kindly agreed to host the list free of charge. The new address for the list is [address removed]; you have all been subscribed. I haven't done a lot of configuration yet, so those of you who have been getting digests will at least see an interruption.

The list moved again in April 2006: see the main ChromaTalk page for current subscription information.

Jerry Leonard [21030100++] · Mon, 07 Aug 2000 19:00:59 -0700

Thanks Chris, everyone greatly appreciates all of the effort and time you've put into this.

Chroma for sale

Dave Nagy · Mon, 7 Aug 2000 18:09:27 -0700 (PDT)

Hi All,

I've got a Chroma that I had planned to hold on to, but that I really don't have room for anymore. After many trips to Goodwill, and much closet cleaning, I've disposed (sniff) of all my other old music gear. I had hoped to "allocate space" for the Chroma but I still couldn't free up a spot for that big ol' Anvil case. Perhaps someone on the list might be able to give it a good home?

I don't recall the serial number offhand, but the description seems to match that of most of the Chromas I see advertised:

Case, pedals, footswitch, MIDI interface...

Hasn't been plugged in in 4-5 years. Was serviced about 10 years ago. Had to replace a "voice card" or somesuch. Towards the end it would intermittantly fail to "cold boot" and you would have toggle the power switch in order to make it successfully through the self test. (Power supply issue, so I hear.)

Bought it from a fella in Berkeley, CA in about '87. I believe he also bought it used, but I don't know the history going any further back.

Good condition except for the that durn foam sticking to the wood!

I shudder to think about how this could be shipped, so if there's anyone in the SF Bay Area that's interested, so much the better. It'd be nice if I could get as much as $500 for it, but make me an offer.

Thanks for your time.

Larry C [21030864] · Tue, 8 Aug 2000 08:41:33 EDT

Hi Dave:

They are worth a lot more than $500.00. Dont let anyone tell you different. Check the Ebay history on that Instrument, I saw one sell for well over a thousand.

Good Luck,
Larry

Roger John Lesinski Jr · Tue, 8 Aug 2000 08:44:58 -0400 (EDT)

I agree with you there, but I sure as hell would not use ebay as a scale in order to determine how much something is worth.

Dying ROMs?

Dave Bradley [16330135] · Fri, 18 Aug 2000 11:44:30 -0500

I'm seeing a lot of talk lately on the synth lists like AH [Analogue Heaven mailing list] about old synths dying because the ROMs are decaying.

Should I be concerned with getting copies of my Chroma ROMs blown? Anybody done this already? Are the chips still available?

David Clarke [21030085++] · Fri, 18 Aug 2000 19:51:40 -0400

My $0.02 are that the EPROMs shouldn't really wear out any sooner than any other chips in the synth - so I wouldn't be too worried. Even if a chip did happen to die, I'm sure you'd be able to find at least 1 other Chroma owner who'd be able to burn you a replacement.

If you did want to 'back up' the firmware, I'd recommend just getting a binary copy of the ROM image and storing it on your computer. That way you could then generate one or more EPROMs whenever you wanted.

The EPROMs used in the Chroma are still fairly widely available.

Regards,

Dave

Hello, and Newbie question.

Mark R. David [21030170+] · Fri, 18 Aug 2000 13:19:07 -0400

Hi there, everyone. Though I've had a Chroma since (I think) 1984, I've only recently gotten interested in doing something with it again. My expander needs some repair, and in the process of figuring out who could help me with that, I found this list. ( I also own an Arp 2600; also needs a little work). For the repair, I'm heading up to Dave Wilson at the Synthesizer Museum, in Nashua NH.

But I have a different question for you all, one which I was unable to find addressed in the archives. I would like to build (from scratch) a Windows controller/editor for the Chroma, using Chroma's native programming protocol, not MIDI. I know, it's a little offbeat, but it just sounds like a fun hack. I'm a programmer by trade, and what I think I need to do is build a device driver (a first for me), and an application program that reads from/writes to the device. But I am not, by any stretch, a circuit-builder, analog or digital.

So the question is, can I plug the Chroma into my computer's parallel port? Are the electronics compatible? Will I be able to read/write signals? Will I fry stuff on one or both ends? Has anyone tried this? It's a 25-pin plug, so it looks like a natural thing to try. But all the computer hookups I've read about seem to involve a custom card, which I don't know how to build. Even if I could buy such a card, the computer I ultimately want to use this with is a laptop, and only has PCMCIA expansion slots.

BTW, if I get this to work, I will certainly share the results with anyone interested.

Thanks,
Mark David

David Clarke [21030085++] · Fri, 18 Aug 2000 20:13:34 -0400

Hi there, everyone. Though I've had a Chroma since (I think) 1984, I've only recently gotten interested in doing something with it again. My expander needs some repair, ...

Do you have both a Chroma and Expander?

Out of curiosity, how many others out there on the list have both?

But I have a different question ...I would like to build (from scratch) a Windows controller/editor for the Chroma, using Chroma's native programming protocol, not MIDI. ...

There are some benefits to this - for one, some of the parameters have a greater range via the Chroma interface than they do over MIDI.

So the question is, can I plug the Chroma into my computer's parallel port? Are the electronics compatible? Will I be able to read/write signals? Will I fry stuff on one or both ends? Has anyone tried this?

While they have the same physical connector, the Chroma port and a PC's parallel port are not pin-pin compatible.

My recollection is that pin's 18-25 are ground on the PC parallel port, and these happen to represent a full 8-bit byte of data lines for the Chroma interface. As well, the pins which are defined as ground (and power) on the Chroma port are defined as parallel port outputs.

Unfortunately, I don't think it would be just a matter of remapping the pins either as the Chroma uses 10 pins for output data/output strobes and 10 pins for input data/data strobes whereas the parallel port has only 5 digital inputs (and 12 digital outputs).

Even if I could buy such a card, the computer I ultimately want to use this with is a laptop, and only has PCMCIA expansion slots.

The best solution that I can think of is to actually do the interface serially. A few years ago I built a Chroma-Serial box which converts the 8-bit parallel data from the Chroma into a standard serial interface which can be hooked up to any PC.

This way you can directly access the Chroma port via a PC/terminal with standard serial I/O commands. At one time (before I had a midi interface) I actually wrote a windows midi driver to talk to this Chroma-serial box (i.e., instead of accessing a midi interface in the PC it talked to a serial port).

Regards,

Dave

Chris Ryan [21030691] · Sat, 19 Aug 2000 10:08:38 -0700

At 8:13 PM -0400 2000/08/18, A. Gordon Clarke wrote:

There are some benefits to this - for one, some of the parameters have a greater range via the Chroma interface than they do over MIDI.

That's interesting. Examples?

Mike Maloney · Sat, 19 Aug 2000 15:09:19 -0400

Do you have both a Chroma and Expander?

Out of curiosity, how many others out there on the list have both?

I count myself among the lucky few. (Heck, I would consider myself fortunate to just have a Chroma)

There are some benefits to this - for one, some of the parameters have a greater range via the Chroma interface than they do over MIDI.

Not a problem. Use RPN's and you can have 14-bit resolution. The only things that this would apply to would be volume, the levers, and the pedals, all of which run 8-bit resolution. (Obviously, the levers could use the wheel and pitch bend controls). But unless the CDI spec changed after 1983 (which is the copy I have), those are the only performance variables that exceed the standard MIDI 0-127 range.

Unfortunately, I don't think it would be just a matter of remapping the pins either as the Chroma uses 10 pins for output data/output strobes and 10 pins for input data/data strobes whereas the parallel port has only 5 digital inputs (and 12 digital outputs).

Enhanced Printer Ports are bidirectional, which makes interface a snap. And I assume (maybe wrongly) that just about any printer port on a computer these days is an EPP. There are a bunch of resources out there for using parallel ports, including prefab .dll, .vbx., and .ocx add-ons. www.lvr.com has a bunch of links, and the site owner has a book on the subject he is selling as well.

At one time (before I had a midi interface) I actually wrote a windows midi driver to talk to this Chroma-serial box (i.e., instead of accessing a midi interface in the PC it talked to a serial port).

This is the point at which the interface becomes black magic to me - I haven't a clue about writing device drivers for Windows. :-< Someday I may have time to do something about that - but I'm pretty sure it's not going to be soon.

Mike Maloney

David Clarke [21030085++] · Sat, 19 Aug 2000 14:25:44 -0400

That's interesting. Examples?

Upon checking, there are fewer than I remember, but one (for instance) is "volume." This controller can take on MIDI values 0-127 but on the Chroma, the main instrument volume parameter is actually mapped 0-255 (ditto on the Chroma Polaris).

Using the Chroma interface directly also gives you direct control over the 'switches' not currently mapped via the Chroma Cult MIDI inteface (filter LP/HP selection or patch mode, etc.)

David Clarke [21030085++] · Sat, 19 Aug 2000 19:49:07 -0400

Enhanced Printer Ports are bidirectional, which makes interface a snap. And I assume (maybe wrongly) that just about any printer port on a computer these days is an EPP.

... but you'd still have to build a mini hardware interface between the Chroma and EPP port, correct? (I could very well be wrong, but doesn't EPP's do their bidirectional comms via a set of byte-wide bidirectional lines? That is to say, you if wanted to use this port to talk to the Chroma, you'd at the least need a set of buffers/latches to hold your data available).

At one time (before I had a midi interface) I actually wrote a windows midi driver to talk to this Chroma-serial box (i.e., instead of accessing a midi interface in the PC it talked to a serial port).

This is the point at which the interface becomes black magic to me - I haven't a clue about writing device drivers for Windows. :-<

I hate windows programming, but the Borland C/C++ windows developers kit used to come with a sample MIDI application - one which gave full code for a midi monitor. I just used parts of this, and then tied in some serial I/O routies. It wasn't pretty code by any stretch of the imagination, but it worked for what I used it for.

Mike Maloney · Sat, 19 Aug 2000 21:12:48 -0400

... but you'd still have to build a mini hardware interface between the Chroma and EPP port, correct? (I could very well be wrong, but doesn't EPP's do their bidirectional comms via a set of byte-wide bidirectional lines? That is to say, you if wanted to use this port to talk to the Chroma, you'd at the least need a set of buffers/latches to hold your data available).

Right - and a tiny bit of glue logic to handle the ACK and FULL lines.

Like beauty, "snappiness" is in the eye of the beholder. ;-)

Chris Smalt [21010280+] · Sun, 20 Aug 2000 04:39:00 +0200

Mike wrote:

But unless the CDI spec changed after 1983 (which is the copy I have), those are the only performance variables that exceed the standard MIDI 0-127 range.

I thought velocity had more steps too.

Chris

Mike Maloney · Sun, 20 Aug 2000 18:08:08 -0400

I thought velocity had more steps too.

Quite the opposite - velocity range is 0 -31. (again, according to 1983 docs)

Mike Maloney · Sun, 20 Aug 2000 19:21:27 -0400

But I have a different question for you all, one which I was unable to find addressed in the archives. I would like to build (from scratch) a Windows controller/editor for the Chroma, using Chroma's native programming protocol, not MIDI. I know, it's a little offbeat, but it just sounds like a fun hack. I'm a programmer by trade, and what I think I need to do is build a device driver (a first for me), and an application program that reads from/writes to the device. But I am not, by any stretch, a circuit-builder, analog or digital.

Well, you started me a-thinkin' - actually, you don't even need to build a device driver - you can if you want, but if you poke through some of the links at www.lvr.com you will find everything you need to talk directly to your parallel port. So it's just a matter of developing the application to decide what you want to tell it.

And if you are just trying to send it patch information, I don't think you need any interface except for rewiring a cable - but you won't be able to get info back from the Chroma. So it wouldn't be able to edit existing patches. You can, however, write patches to the Chroma.

And as I write, it occurs to me that if you want to be really sleazy about it, you could add a second parallel port to your computer, and do a breakout of the Chroma interface cable to have bidirectional communications...it's tacky, but it will work.

Erik Vellinga [21010286] · 21 Aug 2000 19:35:27 +0100

Interfacing

Nice idea Mark. Do you also send all of us your circuit to let it be played by your page? I have made an interface myself, a couple of years ago but I lacked the time to finish it. it would be like a Chroma Cult MIDI interface. It was based on a 8032 uP design but I could not get the in and output software buffers right.The Chroma language is mostly simular of MIDI a lot of commands are alike and even the same. If you are going serial why not MIDI, you could use SysEx info to talk in Chroma language to the Chroma ? Why not rebuild the Cult interface a lot of us are so interested in. I could send the codes i already have for the 8032. Using only the Chroma parallel interface to the PC would indeed need a buffer of some kind, it's circuit is drawn in the interface manual of the Chroma. Using another EPP port on the PC would go as an input to the PC. Parallel is MUCH faster than serial !

BTW, Dave do you have the complete assembly list of the program in EPROM in a txt file? That could be modified to even say: " Hi Erik " when the Chroma powers up? I know poking into the display is hard to do but it's an example. I would like to make my own velocitiy table as I mostly use the keyboard to play piano through MIDI and I cannot get used to the respons of the keyboard...

Erik

David Clarke [21030085++] · Mon, 21 Aug 2000 21:55:04 -0400

Velocity Steps

I thought velocity had more steps too.

Quite the opposite - velocity range is 0 -31. (again, according to 1983 docs)

Actually, velocity will have a bit of a different problem (although probably not much of a problem at all, to most).

Since midi velocity is 0-127, the midi interface has to convert the 0-31 to 0-127.

The Chroma Cult/KMX interface does it essentially via the following equation:

Midi Velocity = ((Chroma Vel + 1) x 4) - 1

What this means is that for a Chroma Velocity of 0-31, you get a MIDI velocity of 3 to 127. That is to say, although the Chroma can output a keystrike with "zero" velocity, you will never be able to see a "zero" velocity on MIDI.

Again - probably not a problem for 99.9% of the time; however, something to keep tucked away in the back of your mind ...

Mark R. David [21030170+] · Mon, 21 Aug 2000 12:51:32 -0400

Newbie question resolved

Thanks everyone for your responses.

It looks like I'm going to build a circuit. While some parallel port hacks might actually work, I want this to be fully functional, bi-directional, able to support (at least) 2 Chromas, and able to be used on any computer (not just EPP parallel ports, does not require 2 ports, etc.).

Also, I'm still going to do with in native Chroma commands instead of MIDI. Mostly just because I want to.

Since I have to build a circuit, I might as well go in through the serial port instead, as Dave Clark suggested.

The good news is, if I design the circuit right, I'll be able to use a vanilla device driver for the port instead of having to write a custom one.

In answer to Dave's question, I do have both a Chroma & expander. So I'll put two 25-pin connections on the box, and figure out a way for the computer to specify/determine which one the commands are going to/coming from. Does anyone have MORE than 2 Chromas/expanders? I suppose we could go higher, if necessary.

Thanks for th lrv.com site, Mike Mahoney. It looks like I'll need to buy one of their books.

It occurred to me that, if I get this working, I should set up a Web page with an applet that actually plays your Chroma in real time. Maybe we could get everyone to hook up simultaneously and have the Web page play EVERYONE's Chroma in sync!

Thanks again, everyone. I'll let you know how it goes.
Mark David

David Clarke [21030085++] · Mon, 21 Aug 2000 23:44:03 -0400

Does anyone have MORE than 2 Chromas/expanders?

I'm a embarrassed to say so - but yes ... 2 Chromas and 1 Expander.

One of my next little projects will be a 'chroma port merger/patch bay.' (I want to be able to have a Chroma hooked up to an Expander at the same time it is hooked up to MIDI and to my knob box ...) The plan is that this will be a box with 4 DB-25 connectors - which will route messages to/from the devices, as appropriate.

David Clarke [21030085++] · Sat, 26 Aug 2000 13:56:58 -0400

Velocity Steps (JL Cooper vs. Chroma Cult)

... just a quick followup to one of my own posts a week or so ago:

The Chroma Cult/KMX interface does it essentially via the following equation: Midi Velocity = ((Chroma Vel + 1) x 4) - 1 What this means is that for a Chroma Velocity of 0-31, you get a MIDI velocity of 3 to 127. That is to say, although the Chroma can output a keystrike with "zero" velocity, you will never be able to see a "zero" velocity on MIDI.

The JL Cooper ChromaFace does the more straightforward conversion - namely just multiplying the Chroma value by "4". That means we have:

Chroma Velocity	Chroma Cult	JL Cooper
0	3	0
1	7	4
...
30	124	120
31	127	124

Dave

Comparison - Rev 12 vs Rev 14 firmware

David Clarke [21030085++] · Sat, 19 Aug 2000 19:29:48 -0400

Back in June I said:

"I haven't forgotten that I promised to do a comparison between the Rev 12 and Rev 14 firmware - I've just gotten a little sidetracked as of late. At present, I have identified all the code/instruction differences and I'm about 3/4 done in terms of knowing what each of those changes really mean (in terms of Chroma operation/use)."

It's now August and I really haven't done any more with the comparison (I'm ending up doing work-releated assembler investigations so I really don't feel like looking at more assembler when I get home ...)

Anyway, I figured I might as well post what has been done to date and leave it at that.

Here goes:

Overview

Changes which occurred when going from Rev 12 to Rev 14:

• Addition of 2 pressure related Set-Split commands
• Changed memory-map location of Safe Buffer/Chroma Buffer/Cassette Buffer
• Increased number of 'steps' available in sequencer mode
• Included additional error checking on some Chroma interface commands
• Implemented Pressure-related Chroma Interface commands
• Bug fixes for Pedal 1-2/Lever 1-2 Chroma output data (now correctly sends an Inst0 and Inst1 command instead of two Inst0 commands - as noted in interface document)
• Codes are output the Chroma Port for 'unused' Set-Split commands 46 - 49 (thus allowing Chroma Cult midi interface to detect and act on a "set split 46" command.)
• The location of some code variables (memory location $00DF and below) changed between revisions.
• Some variables are stored in different locations in the internal representation of the instruments and/or channels (for instance, the converted PEDAL 1 data is stored at instrument offset $64 in Rev 14, but is stored at offset $68 in Rev 12).
• The locations of particular functions/routines in ROM have changed. Since the firmware contains many 'vector' handler tables, these tables will therefore have different data stored in them in the two firmware revisions.
• Rev 12 code is smaller than the Rev 14 code. Rev 12 has extra space at the end of the last EPROM, whereas the Rev 14 code essentially takes up all available ROM space.
• At several places R12 code duplicates code used elsewhere in the firmware - R14 code simply calls this common code. (no functional difference between the two).

Specific Changes

The following outlines details of the specific differences between Rev 12 and Rev 14 code (based on a line-for-line comparison of the two.) Note: While the details of the changes of specific handler address/RAM variables were captured as part of this comparison, this data is not, in general, included here as these changes do not have any functional impact on the code. Also, minor code changes (such as the order of instructions where the order was not important) are also not necessarily detailed below.

Location of Buffers/Logical Software Elements

The location of the major buffers changed between ROM revisions. As well, the memory location of the "instrument" and "channel" definitions were changed. The table below outlines these differences:

	Rev 12	Rev 14
Cassette Buffer Base	$BFF	$140
Safe Buffer Base	$140	$241
Chroma Output Buffer Base	$1C0	$2C0
Base of Inst. 0	$600	$690
Inst. Def'n Size	$C0	$B8
Base of Chan. 0	$200	$300
Chan. Def'n Size	$40	$39

Aside from variable/buffer changes, the first real departure in code occurs at address $C448 (ref. Rev. 14 code). Rev 14 has two extra lines of code at this address that update the system-wide 16-channel mode from the instr. value. This code relates to the attack handler used for Kybd Alg 3 (All Channel Poly).

This change will explicitly ensure that the notes played by the handler are appropriate for the channel definition (i.e., 8- or 16-channel mode).

In the "Load Packet" Chroma Port handler (Chroma Port Opcode $04), the Rev 14 code has an extra "COMA" instruction which is not found in R12. This will change the "type of error" value reported in the "Error Packet" output. The expected difference in data (presented from the Chroma Port) is as follows:

	Rev 12	Rev 14
Error Packet (read error)	04 02 00 FF	04 02 00 00
Error Packet (cass. not running)	04 02 00 00	04 02 00 FF

Rev 14 generally handles pressure commands and chroma interface pressure info more completely (i.e., in Rev 14 C_INTF_PRES Chroma Interface Pressure setting is cleared/set appropriately, in several locations).

Chroma Port Opcode $01 (Identification)

When queried with this Opcode:

• R14 will output 010103
• R12 will output 010102

Chroma Opcode $03 (Write Program) Handler

Format of command: 03 pp dd ... dd

• pp = program number
• dd ... dd = 59 data bytes

Interface manual says that if pp is not between 0 and 50, the data is accepted and ignored.

Both Rev 12 and Rev 14 will strip off 59 data bytes (of garbage) from the interface) if pp > 50 but Rev 14 adds code to specifically check:

If pp = 00 (program 0 - the working program) or if pp = the currently selected program number (i.e., the one displayed on the panel), the PROGRAM MODIFIED flag is explicitly set (since, a modification is being made to the program on the panel).

(**NOTE Actually, the Rev 14 code looks redundant - making a special case for 'cur prog' and prog 00 - but then it later globally sets the program modified flag. Rev 12 does not make these checks, and will apparently only indicate a change to the programs - PROG MODIFIED BIT - if we've just updated Program 0 ... this would appear to be more correct; however, it doesn't address the case where Prog 0 is based on Prog N, and Prog N now changes.)

Chroma Opcode 06 handler (Read Parameter):

Interface document says:

"06 pp nn

nn = parameter number in program pp

Return value is 06 vv, where vv is parameter value. If pp or vv is out of range for the inst., the return value is undefined."

R14 checks to see if the program number is valid, R12 does not. Although the interface manual says that the returned value is "06 vv" where vv is undefined if the program is out of range, this is not strictly the case - both Rev 12 and Rev 14 will always return "0" (i.e, "06 00") in the case of an error.

There is also a typo in the interface manual. It says

"If pp or vv is out of range for the parameter ...."

This should read:

"If pp or nn is out of range..."

It is impossible for "vv" to be an invalid value - it is either '0' or confirmed to be a valid param. value (via the code).

Chroma Opcode 07 handler (Write Parameter):

The Interface manual indicates:

"07 pp nn vv

If pp is out of range for the inst, then vv is ignored. If vv is out of range for the parameter, the result is undefined - except that the parameter is never set to an illegal value."

Rev 14 will check the provided program number and will ignore the value if the program number is out of range. Rev 12 does not perform any check on the program number (both Rev 14 and Rev 12 do check to confirm that the param number is OK).

In Rev 12, if an illegal program number is provided, the result will be undefined (i.e., the value will be stored to NV memory - but not to a valid program address. Bad things could happen.

Also, Rev 14 will set the 'Program Modified' bit if pp = either the current program or program 0. Rev 12 does not ever set the Program Modified bit for Chroma Opcode 07.

Chroma Port Handler Opcode $13 (Restore)

R14 clears C_INTF_PRES and outputs a Pressure Switch off Chroma command - R12 does not.

Chroma Port Handler $14 (Pressure off) & 15 (Pressure on)

This command is implemented on R14 but not implemented (it is ignored) on R12.

Chroma Port Handler $68-$6F (Pressure Command)

Implemented on R14, not implemented (ignored) on R12.

Pedal 1 handler - R12 will send out two Instrument 0 pedal commands out the chroma port, R14 corrects this and sends 1 Inst0 command and 1 Inst1 command.

Pedal 2 handler - R12 will send out two Instrument 0 pedal commands out the chroma port, R14 corrects this and sends 1 Inst0 command and 1 Inst1 command.

Lever 1 handler - R12 will send out two Instrument 0 pedal commands out the chroma port, R14 corrects this and sends 1 Inst0 command and 1 Inst1 command.

Lever 2 handler - R12 will send out two Instrument 0 pedal commands out the chroma port, R14 corrects this and sends 1 Inst0 command and 1 Inst1 command.

Main Loop - General Code Changes

Slightly Different Code/Order of Code from $D2B2-$D416 (Rev. 14)/$D25D-$D325 (Rev. 12). Many of these changes address pressure issues. (Not fully investigated).

Difference in Calculation of Note-Specific Values Stored in Channel Def'n

The 'channels' defined in the Chroma contain a value representing the played key/note. The procedure which stores this data to the channels differs in the way they handle portamento and glissandro values/notes.

These changes are at 0xE03B in Rev. 14 and 0xDEDB in Rev. 12 and specifically deal with how the calculation is done to see if the 'slide' or 'glide' has been completed yet. The changes could be a natural result of how notes are handled internally on the two revisions.

Apparent Error in R12 "Release Threshold"

Rev. 12 contains the follow lines of code:

CLR A
LDB PLAYED_VELOCITY
CMPA RELEASE_THRESHHOLD

Rev. 14 contains the follow lines of code:

CLR A
LDB RELEASE_THRESHHOLD
CMPB PLAYED_VELOCITY

There are two notable differences. First, in Rev. 12, the last line compares the stored RELEASE_THRESSHOLD against "A", which will always be 0. This would appear to be an error (since you're not actually comparing the played value vs. the threshold value). This is corrected in Rev. 14.

Even if the "A" vs "B" error did not exist, the comparison is done in a different order between the two revisions, so the 'sense' of the threshold wouldn't be correct.

Different Internal Representation of Notes

Rev. 14 references the centre of the keyboard as note "0"; however, Rev. 12 doesn't (split values differ by $20). This results in quite a few differences between the Rev. 12 and Rev. 14 code (to take this into account at different locations).

Implementation Differences - Writing Values to DAC

There is a difference between how the Reference DAC (RDAC) value is gathered/calculated (before the main MDAC value is written). The general commands used are similar; however, they're exercised in different orders.

Implementation Differences - Sweep/Arpeg. Code

Slight changes near location $EC04(R14)/$EA4B(R12) which pertain to details of how sweep/arpeg. routines are handled.

Correction/Change to Env. Decay Mod = Pressure Handler

Rev. 14 negates raw value before doing a branch, R12 does not (presumably to address how the actual Pressure Sensor works).

Slight difference in "Sweep Ampl Mod = -Velocity" and "Sweep Ampl Mod = Velocity" Handlers

Rev. 12 has an additional line of code which ensures that the internal calculated velocity value is not a negative value. Rev. 14 has no such extra line.

Extra Pressure Support

At different locations, the Rev. 14 code has extra code to init/handle the C_INTF_PRES values (i.e., STA C_INTF_PRES). These lines of code are not present in Rev. 12.

RAM Initialization (Key/Note data)

Rev. 12 has an extra line of code which is used to store $BF to A. Rev. 12 uses this as a loop counter (i.e., it init's $BF spots in the volatile ram of key/note data). Rev. 14 code does it differently, it actually fills from $C54 up to $FFC (i.e., it uses the location address to see how far it should go). Rev. 14 code allocates has more space for Key/Note stack data ($EA spots or so).

Auto Tune Button Handler

R14 defines an "Auto Tune" to be a type "0" Reset.

R12 enables the cassette motor signal when it performs a write to the MSCO register to mute the oscillators before it does the tuning. In R14, the muting is still done, but the cassette motor is placed in the 'stop' position.

Set Split[n] Decoding

Rev. 14 has extra code in this area. First, it checks to see if [n] was 46..49. If it was then it enables data to go out chroma port and outputs a single byte dependant on the value of [n] selected.

{{The code will output n+$CA, so 46 ($2E) will output an "F8"}}

There is no such code in Rev. 12.

Difference in definition of TAP_ENBLD Variable

Rev. 14 defines the value of $FFFF to disable the tapper whereas Rev. 12 uses $FFF0 (no functional impact or changes seen by user of keyboard - strictly a programatical change).

Implementation of Set Split 16 (Chroma Interface Perform Disable)

If keys are playing/held down and Set Split 16 is done:

Rev. 12 simply outputs a:

"D8 kk 1F" (i.e., a release command for instrument 0, for note kk and a release velocity of $1F - for each held note). There is a problem with this in that it does not release any notes being played over the Chroma Interface on the link instrument.

Rev. 14 does a calculation on the key number (to adjust for redefinition of the centre of the keyboard), and then will outputs commands of the form:

"D8 kk 00" and "D9 kk 00" (i.e., does 'releases' for inst0 and inst1.) Note - the Rev. 14 output always has a release velocity of '0', as contrasted to the fixed release velocity of '$1F' for Rev. 12.

Implementation of Set Split 31 (Special Reset #1)

• R14 Defines RESET_VAL as $80
• R12 Defines it as $1

Implementation of Set Split 32 (Special Reset #2)

• R14 Defines RESET_VAL as $1
• R12 Defines it as $2

Implementation of Set Split 33 (Special Reset #3)

• R14 Defines RESET_VAL as $81
• R12 Defines it as $3

Set Split 34 (Chroma Interface Pressure Disable)
Set Split 35 (Chroma Interface Pressure Enable)

These commands are not defined in R12, but they are implemented in R14.

Different Time to Velocity Data

At outlined in the graphs on the Chroma site, the 128 byte table used to convert keyboard attack/release 'times' into velocity values contains slightly different values between the Rev. 12 and Rev. 14 firmware.

Default/Initial 'Pressure' Based on Velocity

In Rev. 14, there is a default pressure value assigned to a keystrike if the keystrike velocity is high enough. Specifically, Rev. 14 has a 32 byte lookup table (with values ranging from $0 - $3F) which will be used to assign a keystrike pressure value (even if the optional pressure sensor is not installed). Typically speaking, only the most fast keystrikes will result in a non-zero default, initial pressure.

In Rev. 12, this 'default' pressure table is only 16 bytes long, is filled entirely with zeros and is actually not ever referenced in the code.

Different Handling of Boards During a Reset

There is specific code to determine how boards should be 'ordered' by default. This is set via the 'Reset Val' in Rev. 14. On the Rev. 12 firmware, the location of the code to force the default reset board ordering is in a slightly different code location.

Differences in Code Structure in Auto Tune Routines

Rev. 14 code makes specific checks for the value of "Reset Val." Depending on the type of reset chosen, (i.e., there are 4 reset types in R14), tuning errors will either be acted upon or ignored. Rev. 12 code, if the auto tune timer overflows, then the code will stop trying to further tune that board.

In this same code, there is a difference in operation between R12 and R14 as it pertains to the cassette motor control. Specifically R12 enables the cassette motor signal when it performs a write to the MSCO register to mute the oscillators before it does the filter tuning. In R14, the muting is still done, but the cassette motor is placed in the 'stop' position.

There are also some other minor changes in this code - but they are stylistic changes, not functional ones (ex. using "LDA #$1" instead of "INCA" when the previous value of "A" was known to be "0" - these are functionally the same WRT to the code).

Calculation of RDAC

A slight change was made between revisions in the determination of the "reference" / RDAC values. Specifically Rev. 14 uses a literal value of $9249 in this calculation, but Rev. 12 uses a value of $9248 instead.

Available Code Space

Rev. 12 ROMs have space available from $FDA3 to $FFEF - Rev. 14 does not.

David Clarke [21030085++] · Mon, 21 Aug 2000 23:29:11 -0400

Comparison - Chroma Rev 12 vs Expander Firmware

After receiving my Expander I quickly compared the firmware to both the Rev. 12 and Rev. 14 Chroma firmware. By far, the Expander firmware most closely matched that of the Rev. 12 Chroma, with only a handfull of small changes.

The specific changes between the Rev. 12 Chroma firmware and the firmware found in my Expander (EPROMs marked as "305-60370n" where n = 1..8) are outlined below:

In response to the 01 (Identification) Command:

• A Rev. 12 Chroma will respond with: 01 01 02
• The Expander will respond with: 01 02 02

Lever 1/Lever 2 Changes:

In addition to losing the keyboard keys, the Expander also loses the two levers found at the left-hand side of the keyboard.

At two locations in the Expander firmware, Lever 1/Lever 2 data was modified to ensure that it always returns a value of "0" (i.e., no lever movement).

Ignore Keyboard Keystack:

In the routine which checks for new keyboard data, a switch is changed between the Chroma and the Expander. In the Chroma there is code like:

• LDA #$0
• LBNE {code location}

in the Expander this is changed to:

• LDA #$1
• LBNE {code location}

In the first case (Chroma), the branch is never made - in the second case (Expander), the branch is made and all the keyboard related scanning/processing routines are skipped.

LED/Flash Info:

A slight change is made in the Expander regarding how to handle 'flashing' buttons/LEDs.

Left Panel Routines:

Modifications are made to the code to address the differences between the "Link" buttons between the Chroma and Expander.

When Threshold = value, etc.

David Clarke [21030085++] · Sat, 19 Aug 2000 21:26:01 -0400

The Chroma Programming Manual has this to say about Set Split 22 (Release Threshold):

"... Release velocities below a certain threshold yeild (sic) one release time while velocities above the threshold yeild (sic) a different release time ..."

The manual also says (under Set Split 21 and Set Split 22) that:

"... using [SET SPLIT], [21] causes the threshold to be set to whatever number is in the parameter display, regardless of what parameter is selected ... the threshhold is a number from 0 to 31 ..."

On this rainy afternoon, the points aboved raise two questions in my mind, namely:

Q1) What happens when the velocity unique equals the threshold value (i.e., not above or below the threshold)?

Q2) What happens if the value in the display is outside of 0..31? (i.e., if the value in the display is -14? Or 50?)

A1) As best as I can tell from the code, the case where THRESHOLD = PLAYED VALUE is treated exactly the same way as when THRESHOLD > PLAYED VALUE.

A2) [SET SPLIT] [21], [22], [23] or [24] don't actually set the threshold "... to whatever number is in the parameter display"; rather, it will actually set the value to $1F AND (parameter in memory which drives the parameter in the display).

For instance if we have:

Value in Display	Threshold Set To
0	0
15	15
31	31
43 ( = 00101011)	11 ( = 00001011)
63 ( = 00111111)	31 ( = 00011111)
-64 ( = 11000000)	0 ( = 00000000)
-14 ( = 11110010)	18 ( = 00010010)
-7 ( = 11111001)	25 ( = 00011001)

NOTE: There is a further 'special case' to this explanation. The 'Link Balance' values are displayed in terms of multiples of 2 (i.e., -14 .. +14), but the internal value only actually ranges from -7..7. For the sake of the Set Split [21], [22], [23] and [24] commands, it is the _internal_ value which is used, not the displayed on. That means if we use a 'standard' parameter (like Mod 1 Depth) and the display shows -14 we have:

Value in Display	Threshold Set To
-14 ( = 11110010)	18 ( = 00010010)

but if we use the 'link balance' parameter and the display shows -14 we have:

Value in Display	Threshold Set To
-14 ( = 11110010)	25 ( = 00011001)

Regards,

Dave

Expander

David Clarke [21030085++] · Mon, 21 Aug 2000 23:14:48 -0400

UPS was kind enough to drop off a Chroma Expander at my door today.

I've done a quick comparison of its firmware vs. that found in a Chroma. The detail of that comparison is contained in another piece of e-mail; however in summary, the firmware in this particular Expander is almost identical to the Rev 12 Chroma firmware.

That would tend to mean that this Expander will experience difficulties with the Chroma Cult/KMX midi interface in the exact same way that a Rev. 12 Chroma would (i.e., you'll more or less loose the use of patches 46-49).

Further, there's a note in the JL Cooper Chromaface manual which says:

"Your Chroma will only send the proper code to the Chromaface when you push the Set Split 46 if it has the Rev 1.4 software(most recent) software installed. If you don't have this software, or you are tyring to use the Chroma Expander, you will need to enable this mode ...."

This note would tend to indicate that while there was a "Rev 14" release for the Chroma, there wasn't such a release for the Expander.

Does anybody know if there was ever a "Rev 14" firmware for the Expander?

Does anybody have an Expander which _doesn't_ experience the Rev 12 limitations listed above? If the answer is 'no', would those of you who use an Expander with a midi interface find it a benefit to have the Expander to behave in a manner similar to the Chroma (running Rev. 14 S/W)?

Regards,

Dave

Power Supplies that Need to be Turned on More than Once

David Clarke [21030085++] · Sat, 26 Aug 2000 14:02:50 -0400

Quite a few people have had Chroma's that need to be turned on (and then turned off and back on again) in order for the keyboard to properly start up.

While there are certainly many different reasons this could be occurring, a good first thing to look at/change are C10 and C12 on the power supply board.

These two small capacitors effectively control when the reset signal will be issued to the microprocessor (and allow the system to start up).

On at least 3 separate Chroma's I've found that these needed to be replaced.

C10 and C12 are both 3.3uF, 35V electrolytic caps and are physically located between the large main PSU capacitor (47000uF) and the transformer (diagonally between them.

If you're having the problem mentioned above, you might want to consider changing these caps (and while you're at it, you may want to use a 50v part instead of the 35v one ...)