Programming the OPL3 chip with the Color Computer

This article is intended to give a basic overview of using the Yamaha YMF-262 (OPL3) chip on the Color Computer, to help aid in the understanding of its use on the MEGA mini MPI and the upcoming CoCo SDC sound extender.

The YMF-262 (OPL3) is an FM synthesis sound chip that offers a huge amount of flexibility in generating musical notes and sound effects. It’s backwards compatible with OPL2 sound chips, and starts up in this mode by default.

There are a few good references for programming the chip, including the application manual (data sheet), and the document linked here.

Programming the chip can be a little intimidating at first as there are a lot of options to work with. The OPL3 is extremely flexible in how it generates sound, which leads to a lot of complexity (potentially), but it can be operated in a fairly simple manner as well.  How it’s used is up to the programmer and how much CPU time he wants to devote to manipulating chip settings / channels to get the desired effects.

For the purposes of simplifying things here as we begin, our examples will stick to two-operator melodic tones.

Eighteen operator pairs are available on the OPL3. The simplest way to think about an operator pair is probably as an instrument. So essentially there are 18 ‘instruments’ that you can define.

For each instrument, there are two operators; a carrier wave, and a modulator. The carrier is the basic sound wave for the instrument, which is then modulated in either AM or FM mode to produce a more complex sound.

All the settings for an instrument pair need to be written to specific registers in the chip. Let’s take a look at registers for the first operator pair (or channel).

These registers define the carrier and modulator for the sound.

$20                            $23                  VIBRATO,SUSTAIN,SCALING,MULTI
$40                            $43                  KEY SCALE LEVEL, OUTPUT LEVEL
$60                            $63                  ATTACK / DECAY
$80                            $83                  SUSTAIN LEVEL / RELEASE RATE
$E0                            $E3                  WAVEFORM

In addition to the operators, there are three registers that control the overall channel (instrument). Again for the first channel.


These 13 registers are all that’s needed to define a sound and play it. In its simplest usage, the 10 registers for the operator pair would be set up, and then afterward the sound controlled using only two registers ($A0 and $B0) to change note frequency and key-on / key-off.

Some assembly code
Let’s go through some 6809 assembly code that sets up an instrument and plays through the natural notes in an octave as an example. Leaving out the equates, here is the code that sets up the MEGA mini YMF-262 and plays the scale.

This portion does a little basic setup for the CoCo system and switches the sound source to the cartridge port sound-in line.


Now we set up the MEGA mini’s analog switch to use the YMF-262 for sound, and select it for /SCS routing so that we can program the chip.


Here, we set up the instrument by writing the registers for the operator pair. You can see the register numbers and their data below the routine for writing them. You’ll notice the NOP instruction between selecting the register to be written and sending the data. This is because the YMF-262 requires 32 of its clock cycles to process the register selection (at 14.318MHz). This works out to a 2,233.6ns, which is just slightly less than 2 cycles for the 6809 at .89MHz (2,235ns). You’d want a 4 cycle delay at 1.79MHz.


Now our instrument is set up, except for the frequency data (F-NUM and octave).

Let’s play the octave. At the bottom of the following code, you can see the frequency data for each note based on the A440 pitch standard. This is a 10 digit binary number (0-1023) and the base frequency for each note. This, along with the octave data (block number) in register $B0, determines the frequency of the note.

Three register writes are required per note if the frequency changes. Frequency data, key-on, and key off. A note could be played with only two without changing the lower byte of frequency data.

Notes here are played in succession through the octave and then repeated endlessly.


And that’s really all there is to it for regular melodic notes. Your program of course has to supply the timing for key-on/key-off events, and handle frequency changes, but the OPL can do the rest for simple music. You can also go nuts with the CPU and manipulate the various registers during play for different effects, but you don’t have to.

It’s a very flexible system.

I hope that gives enough insight to get some of us started on writing for the OPL3 on the CoCo. As you can (hopefully) see, it’s really not as difficult to program as it might seem at first. The OPL is *very* geared towards synthesizer type music, and it really shows in its design and operation.

Coming up with instrument definitions
Many instruments and sound effects have been designed for the OPL3, from general midi to all sorts of sounds used in games from back in the 90’s. You can use instrument data from these sources as well as use bank editors such as this OPL3 Bank Editor to experiment and come up with your own instruments.



CoCo2 Composite A/V modulator replacements

Not long after I did my first CoCo project (a composite A/V board) I happened to buy a CoCo2 that had an interesting difference from the usual models.  It had factory composite and sound output in place of the RF modulator! What a surprise!

20141120_190514Tandy factory original composite/sound board

After a little research, I discovered this was a variant that had been intended for educational sales, where a composite monitor was prefered to TV sets as a display.  I was very interested in this as I had just been working on something similar, but this was clearly a different circuit that Tandy used.  It’s also interesting to note that this ‘educational’ model uses the T1 variant (XC80652P) of the MC6847 VDG.

I decided to reverse-engineered the circuit and design some modulator replacements of my own based on this design.  Here is an early prototype of that effort.

Modulator replacements, first prototype

The board is a direct replacement for the RF modulator, requires no modifications to the case, and uses the channel switch to select between B&W / COLOR.

Output appears to be very good. I would say considerably better than the simple reference circuit in the MC6847 data sheet, which was all I’d been able to find previously.

Further working with this circuit, I decided to develop versions for both major modulator types, the ‘vertical’ modulator found in early American produced CoCo2s, and the ‘flat’ type found in Korean models.  Here are some pictures taken during development.


After getting the design more or less finalized, I produced a number of these and sold them to people wanting something a bit better than RF output on their CoCo2s.  Well over 100 boards were distributed.


Type A’s (Korean), in production


Final versions

Identifying modulator types

This portion is to help identify which composite video board style you will need to replace the RF modulator in different CoCo 2 computers.

Type A
I’ll call the first one the “Type A” modulator.  This is found on later, Korean made CoCo 2’s.  It lays flat against the motherboard next to the channel switch.  If your modulator looks like this, you need a Type A Composite board.


Type A, Korean motherboards, ‘flat’

Type B
I’ll call the second the “Type B” modulator. This is found on earlier, US made CoCo 2’s.
It attaches to the motherboard by one of it’s edges, and has the channel switch in the RF box. If your modulator looks like this, you need a Type B Composite board.


Type B, American motherboards, ‘vertical’

Installing the board, Type A

Here you will find some basic instructions for installing the Type A composite video board.  This is how I do it, of course it’s not the only way, and all the usual disclaimers apply.


Removing the RF modulator

The first step after removing the motherboard from the computer, and removing any shielding on the bottom, is to remove the RF modulator box.

You will need a temperature controlled soldering iron for this, as it takes quite a bit of heat.  Somewhere around 350º C is appropriate, otherwise the large ground plane under the modulator sinks too much heat to get the solder for the box ground connections liquid in a timely manner, or heat the signal pins enough to melt the solder at the top of the pin where they are connected to the modulator pcb.

First the modulator pins carrying the various signals should be removed.
Special care needs to be taken not to damage the pads these pins are soldered to.  I’ve found the safest way is to heat the pin from the motherboard bottom while applying moderate pressure to the end of the pin.

When it gets hot enough, you’ll be able to push it up into the modulator box. At this point there is enough of the pin protruding on the top side so that it can be grasped with a pair of need-nosed pliers or the like, and pulled (with moderate force again) while it’s heated again from the bottom until free. Repeat for the other 7 pins.

Heat the large solder connections where the RF box is connected to the ground plane, using a solder sucking device of some sort to remove the bulk of the solder.  Use soldering wick to get what that won’t until the sheet metal tabs of the box are free.  A couple of them will need to be straightened to fit through the slots in the board where they were originally bent to hold them in place prior to soldering.

The modulator should now be easily lifted/gently pried free.

Whew…  The hard part is done!


Preparing the motherboard for installation

Use solder wick to clean up the pads for the pins, and also the rearmost slot in the ground plane where the modulator box was soldered.  This is where the ground lug on the new board will attach. You’ll want to be sure that slot is completely open (free of solder).

Next, insert the board (pins and ground lug), make sure it’s fully seated and level.  Solder one of the pins to hold it in place until you are sure you’ve got it positioned as you want it (down all the way and parallel to the motherboard).

Solder the rest of the pins, and then the ground lug.  The ground lug is soldered to the board, so you’ll want to apply enough heat long enough to solder it to the motherboard, but not so long that it melts the connection on the Composite board; not really an issue as it can’t move around at that point anyway, just something to be aware of.

All that’s left now is the power leads.  The WHITE wire connected to P2 is the AC power to the board, and will be attached to the anode of one of the large power diodes on the motherboard.  This should be ~ 8.4 VAC,  you can use a voltmeter to verify.  The RED wire connected to P1 supplies DC voltage to the board, and will be attached to the cathode of one of the large power diodes.   It should read ~ +9.9 VDC.

Type A installed.jpg

Type A, installed

Once the power leads are attached, you just need to trim the pins sticking out of the bottom of the motherboard (the ground lug is pre-cut and should not need trimming).

I will have already set the potentiometers while connected to a TV and an oscilloscope for testing, before sending the board. They can be adjusted if needed on your particular setup, but try it first. 🙂

And that’s it! Put it all back together and enjoy Composite video on your CoCo2.


Type B Power Connections.png

Power connections, Type A

Notes for the Type B

Installing the Type B composite boards is essentially the same, but watch the power connections carefully. The diodes are reversed in their orientation on the motherboard.

CoCo MECH mechanical keyboard


One thing the CoCo community has needed for some time is a viable way to repair or replace the keyboards in our aging machines.

The original CoCo keyboard is a membrane type internally, with the circuit printed on mylar.  Many of these mylars are wearing out today, and the conductor tends to develop cracks in the section connecting to the motherboard.

In the recent past, there has been talk of having a run of replacement mylars made, with a couple of individuals going as far as to get quotes.  Though an option, prices seem to be expensive enough that to date this has not happened.

Cloud9 has developed a solution that involves a very thin PCB with tactile switches being used to replace the mylar in original keyboard casings which looks like a good option.

Having wanted to make a keyboard replacement myself for quite some time, I decided to throw my hat into the ring with my own design.  I had a couple of criteria for the final keyboard.

  1. It had to use standard modern key switches of the current de facto standard
  2.  It had to be a drop-in replacement

Later models of the CoCo1, as well as CoCo 2 models and the CoCo3, can all accommodate the same design.  These are models I’ve targeted.

One of the major obstacles to a new keyboard for the CoCo is that like most early computers, the legends on the keycaps are not laid out as they are in what has become the standard layout over the years.  This means that new keycaps that will fit modern key switches cannot be purchased with pre-labeled keys.  Blank keycap sets are available, but then there is the issue of labeling them in a professional fashion.

Of course there are companies that will produce custom keycap sets for you, but prices and minimum quantities are high, and any change in design would be very expensive.

One of the ways manufacturers label keys is using lasers.  After investigating this a bit, I decided that would be a good way for me to go.  Owning the laser system myself would allow me a great deal of flexibility as well, enabling me to put nearly anything on nearly any keycap at a whim.

So I purchased a 20w fiber laser system for the purpose (and for other things).

IMG_20180817_114940 copy
20w fiber laser system

The system is quite flexible, and does the keycaps with ease.


Laser marked keys, an early test

Keycap marking with the laser

With a solution for the keys decided on, I moved on to the rest of the design.  To avoid needing special molded or printed parts for a keyboard housing while still providing enough rigidity, I decided on a design that would sandwich aluminum bars between the switch PCB and a top plate (bezel) around the keys.

Board BottomBoard Top Initial PCB design

Another issue with a CoCo drop in keyboard is how to go about the connection to the motherboard.  This I accomplished with a thin (.6mm) PCB for the main board connector and a ribbon cable.  Receiving the PCBs back for the fabricator for all this, I proceeded to assemble a prototype.

PCBs for prototype keyboard


Switches installed

  The keyboard is modeled after the original CoCo3 keyboard, shown with the prototype in the picture below.


Prototype with original CoCo3 keyboard

First test, CoCo MECH keyboard

Next I installed the aluminum frame, drilling and tapping the rails to fit the PCBs.  I assembled this prototype in a hurry with hand tools.  Things will be more precise in actual production, but still, this went well.

Prototype with frame installed



Prototype installed in a CoCo3


Installed in an ‘F’ board CoCo 1

I made some changes and produced a 2nd revision of the board which I’ll order to continue development with.  This project has gone extremely well so far and I don’t see any issues in further refining it into a great drop in keyboard option for our CoCos!


REV02 design, main PCB

After receiving back REV02 PCBs, I built a prototype using that board.  And experimented with different colored keys in the set, similar to how the original Color Computer 3 keyboard looked.


CoCo3 style key colors – REV02



Keyboard to main board connection



With the keys marked

Moving along towards actually producing these, I started looking for something a bit easier to manufacture for the various parts of  of the keyboard (outside the PCB and keyswitches themselves) and have decided to use 3d printing to produce plastic parts to fill this role (printed in PETG).

To be able to do this I acquired a large format printer, a Creality CR-10 S5, which has a 500x500mm print bed, giving me the width to do keyboard parts.


Creality CR-10 S5, printing keyboard parts

Screen Shot 2019-06-07 at 9.58.52 AMIMG_20190512_172310

Keyboard parts set

After designing the plastic parts for the keyboard, including a support for CoCo2 machines, I printed out a set and assembled a unit.  This results in a very nice keyboard which is very stable and pleasant to use once installed and the CoCo case is buttoned up.

Keyboard installed in an American CoCo2

I’ll probably also be adding (as an option at least) a vinyl layer on the keyboard top plate for those that don’t want to see the pattern left in the plastic by 3d printing.

Vinyl sheet added to top plate

After working with the support system for a while, it became apparent that different supports would be needed for pretty much every case style.  Below is a video showing installation in a CoCo3 with the supports I devised for that machine.

Installing in a CoCo3




…more to come…



CoCo3 RGB to s-video

Quite some time ago I made a few RGB to s-video adapters for the CoCo3 using the Analog Devices AD725 encoder IC.  These produced some really good results and were used by a couple of people in the CoCo community for doing video capture to produce youTube videos and the like.


Initial video converter example

One unexpected thing that I discovered in working with these was that although they worked well with the ’87 version of the GIME chip found in the CoCo3, they were non-functional with the original (1986) version.

For those who are unaware, the ’86 version of the GIME chip differs from the ’87 in several respects.  Among other things, memory timing errors exist in the ’86 that prompted the ’87 revision to make fixes.   RGB output levels and sync timing also differ.

Discovering that whatever differences were actually enough to affect whether the video could be converted with an encoder IC like the ‘725 intrigued me.  I set out to study the differences and create a converter that would work with both versions if possible.

The only signals involved in conversion are the 3 analog video channels, and the 2 sync signals.  I did a pretty involved study of the signals using an oscilloscope, and though there were a number of minor differences, the chief difference, and as it turns out, the problem in conversion turned out to be the HSYNC pulse.

The HSYC pulses on both GIMEs are wider than they should be, though in the case of the ’87, it has been somewhat corrected, bringing it close enough to spec to function with the AD725 encoder.  The pulse starts much too early on the ’86 however, and just won’t work.

You can see the difference in HSYNC width in the built in composite video here.  The output from the 1986 GIME is pictured up top.


Composite signal – 1986 vs 1987 GIME

As you can see, the HSYNC pulse starts earlier and is nearly half a microsecond wider in the 86 version.  This results in video off center on televisions.  This is the composite signal however.  We are using the separate syncs available at the RGB port for our converter.  Here is a comparison of HSYNC at the RGB port.


GIME RGB port HSYNC – ’86 vs ’87

Even more of a difference in pulse duration here, which must be cleaned up to a certain degree by the internal conversion circuitry when generating composite in the GIME.  Though both of these are pretty wide for an HSYNC pulse.  For example, both PAL and NTSC video call for a pulse width of 4.7us.  CGA, another 15.7KHz format, calls for a similar duration.  Suffice it to say, the GIME has a wide HSYNC pulse, too wide in the case of the ’86 GIME.

Note, this did work with old CRT displays such as the CM-8 and CRT televisions as they are among the most forgiving of display types as far as signaling is concerned.  For conversion with a modern encoder IC though, it’s a no go.

With what I learned of the signals, I decided to design a new converter reconstructing the sync signals as needed.  I also wanted to generate (in addition to s-video) a good composite video signal from RGB, something better than the built in composite for RGB games, and possibly supporting artifact colors as well.

To do this, we need a clock for the encoder IC that is synced to the GIME clock itself, otherwise terrible artifacting results (dot crawl, etc).  My solution is to tap the GIME clock circuit, and feed that signal into our converter.  This 28.636MHz clock then can be divided down to provide the NTSC encoder, and also to drive the logic reconstructing the syncs.  Using this method also has the benefit of not needing a clock generating circuit on the converter PCB itself.  I settled on a Xilinx CPLD to handle these tasks, and designed a new board.


A new RGB2NTSC converter

The new board works very well, providing compatibility with both ’86 and ’87 GIMEs.  Artifact colors on CoCo 1/2 games are also supported, over the composite connection only.  The long stemmed button in the center of the board is used to adjust the color phase for artifact colors in CoCo 1/2 games.  The following is a little demo video showing the converter in action.

The new converter in action

The output is very good, and I’m more or less satisfied with the state of this project.  I’ll probably produce a few for release to interested members of the community to use and enjoy.

Here is a video showing the installation of the one-wire mod…

Installing the mod


Update 01/2019:  I’ve designed a case for the board and have started making these available as a regular item (a handful were sold last year without cases).  Converter and cable kit shown below.


Kit with cables


And here is the manual…   RGB2NTSC manual

CoCo SDC media player

A while back, I stumbled upon a project by Chris Martin, who was trying to get an SG24 video player working with the CoCo SDC on the CoCo. To this end, he had created an image converter for the individual frames.

After playing with the converter a bit, I was very interested in this idea, and decided to see if I could help get it going.

One problem I faced with a video player was getting as uninterrupted a flow of data as possible from the SD card into video memory. At the time, individual commands to read each 256 byte sector of a large file would have to be sent to the MCU, along with status polling for each sector to determine readiness of the SDC. This resulted in some undesirable delays in the byte stream and reduced the number of frames per second I’d be able to achieve.

I brought this issue to Darren Atkinson, the creator of the CoCo SDC, and he was very helpful in implementing a new stream command in the firmware. With this command it was now possible to issue a single command to the MCU, whereupon it would continue to feed sectors to the data port until either an abort command was issued, or the end of file was reached.

The sector size for this command was also increased to 512 bytes, further increasing throughput. Polling of the ready bit would still be needed to allow the MCU time to fill it’s data buffer from the SD card (roughly 1,000 cycles @.89MHz IIRC), but this could be handled with careful buffering on the CoCo side.

With the stream command implemented, I realized this could be used for not only video, but audio and other data that required fast transfer in large amounts. Maximum transfer rates with a 6309 CPU and the TFM instruction were around 180KB per second at .89MHz, and 250KB per second or more at 1.78MHz. Sufficient to do some interesting projects!


SDC media player menu

Rather than create a separate stand alone player for these different formats, I wanted to do something that would accommodate multiple streaming formats. I settled on the idea of embedded player modules in the data files. In this way, a common menu/file browser system could launch any media for playback, with the specific code needed to use it embedded in the file before the data.

I dubbed the file format as ‘CoCo SDC media file’ with an extension of .CSM on the SD card in order to be recognized by the system.

Everything is written in assembly, and the computer is operated in all-ram mode, with a 64KB machine being required. System memory for the media player is laid out as follows…


Media player files must conform to the following;
– named by the 8.3 convention with ‘CSM’ as the extension
– at least 82,944 bytes in total (header, player module, and data)
– must be an even number of 512 byte sectors (pad out the file if needed)

Here’s the format…


The first 16 bytes of a .CSM file are a text description, in CoCo specific ASCII, that will appear to the right of the file name in the menu system.  Otherwise the 1,024 byte header may be used for module-specific data as needed.

Upon selection of a .CSM file by the menu system, the header and executable module code are streamed into ram at $6800-$FEFF.  Code execution is then passed to the module at $6C00.  At this time, the .CSM file is still mounted, though the stream command has been aborted.  The module must initiate stream or sector read commands as needed during playback.  The following is an example of starting streaming at the beginning of media data (sector 76) from a module.


Starting a data stream

Note that proper polling of the CoCo SDC’s status register must take place as needed to ensure accurate transfer of data.

During execution, modules may make use of the buffer areas from $0400-$37FF, as well as the module scratch space from $6800-$6BFF.  Modules may not overwrite data in the $3800-$67FF region, or below $0400.

On exit, modules should shut down cleanly and jump to the return vector at $0053.


The file browser will resume where it left off, allowing selection of the next .CSM file.

I’ve written several modules for use with this system that can be found on their own pages in the software projects section.  If you’d like to write your own player module and have any questions, feel free to contact me.

Here is a link to the current version of the media player and some tools….