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

Stay tuned!

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.


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….

64 column Infocom interpreter

Infocom released a number of it’s interactive fiction titles for the Color Computer in the 1980s, just as it did for most computers of the era.  The versions released for the CoCo targeted the standard 32 column text screen of course.  With it’s limited text display  (32×16) and no true lowercase, the standard CoCo1/2 screen is really less than ideal for interactive fiction like Zork.

With the addition of a 64 column alphanumeric mode to the CoCoVGA project, it occurred to me that this mode would be great for the Infocom adventures.  So I set out to see what could be done.  Source code not being available at the time, my plan was to disassemble an existing interpreter,  and modify it.

In doing this, I learned quite a bit about how the Infocom games work.  I’ll share here some of what I discovered.

The software for an Infocom adventure consists of two parts; the interpreter, and the ‘Z-machine’ or ‘story file’.  The z-machine itself is essentially a snapshot of the memory contents of a virtual machine (computer).  The interpreter executes z-machine instructions and implements them on the host machine, while also managing virtual memory, and providing I/O for the virtual machine.

In this way, Infocom was able to easily port their games to any platform, by simply writing a new interpreter.  The z-machine itself being the same from system to system.

The virtual machine’s memory map consists of three major parts; Dynamic Memory, Static Memory, and High Memory.  Dynamic memory contains things such as game objects/information and global variables, and may be read from and written to by the virtual machine.  Static memory contains the dictionary and various language tables, and may only be read.  High memory contains the virtual machine’s executable code, the ‘Z-Code”.

Dynamic and static memory are loaded into host ram on startup, and remain there.  The beginning portion of high memory (the executable z-code), is loaded into host ram at startup, and additional blocks of high memory are swapped in as called for during execution.

The z-code is made up of instructions and operands for the virtual machine.  The interpreter executes this code, implementing the needed functions on whatever the host system happens to be.

On the CoCo interpreter I worked on at least, the virtual memory system uses 256 byte pages.  These are tracked through a table by the interpreter so they can be loaded into CoCo memory from disk and referred to as called for by the z-code being executed.

After learning enough about the interpreter and how it operates I was able to adjust things to make room for a larger video page, and alter the screen handling routines to make use of the CoCoVGA’s 64×32 W64 mode.  I also discovered that the z-machine files themselves handle lowercase.  The CoCo interpreters have additional code that converts everything to caps for the 32×16 alpha screen, since most CoCos do not do lowercase.  I also circumvented that conversion in order to display in lowercase on the CoCoVGA since it has that capability.

Infocom adventures on the CoCoVGA 64 col mode!

Once I had completed the CoCoVGA versions, I realized it would be simple at that point to alter the code to make a 64 column version for the CoCo3.  So I did that as well.  I whipped up some boot track loaders to go along with the interpreter/z-machine packages and made .DSK images which can now be found on the Color Computer archive.

And on the CoCo3 in 64 columns!

They are available for download here…  for the CoCoVGA  …or here…  for the CoCo3

Check them out if you’re a CoCo Infocom fan!

Please note that I left the original disk I/O routines intact, so if running on the CoCo SDC, you’ll need to switch to the stock Disk BASIC in bank 1 after mounting the .DSK image for it to run properly.