CoCoVGA SAM Accelerator

Some time ago, while thinking about the CoCoVGA display system, it occurred to me that when a system is equipped with the CoCoVGA, it’s no longer necessarily tied to the NTSC carrier frequency.

This opens up possibilities for easily overclocking the system.  At the heart of the CoCo1/2 design is the SAM, or Synchronous Address Multiplexer.  This integrated circuit performs DRAM access and refresh, provides for interleaved memory access between the VDG and CPU, and supplies the system clocks (Q, E, and VDG clock), tying the whole system together.

IMG_20190403_193011A SAM chip

Normally the SAM would derive it’s master clock from a crystal circuit using a frequency of 14.31818MHz.  This is divided by 16 for the CPU clocks and by 4 for the VDG clock.  By utilizing SAM speed registers, the CPU clocks can be doubled (master divided by 8), but in this condition DRAM is no longer refreshed and VDG access to memory is disabled.

IMG_20190320_203910Prototype SAM accelerator

The SAM must run at it’s base frequency in order to provide these essential functions, so my approach is to overclock the SAM itself in order to achieve stable double-speed operation (1.79MHz CPU).  To achieve the desired clock, the SAM is driven directly by the other circuitry on the accelerator board with a clock rate of 28.63636MHz.

The programmable logic on the board intercepts writes to the SAM speed control registers, preventing them from reaching the SAM, and instead varies the master clock.  This allows for easy switching from standard single-speed operation to double-speed.

Because the SAM always thinks it’s at single speed, DRAM and interleaved VDG memory access are handled normally, but at twice the rate.  This does require 150ns or faster DRAMs, and possibly 2MHz rated PIAs (similar to the CoCo3).

This is an easy upgrade for CoCoVGA equipped machines, but will require updated CoCoVGA firmware and the aforementioned chip ratings.  Completely compatible in single speed, there is only one minor difference at double-speed that may be unexpected.  Because the entire system is overclocked by 100%, the VDG interrupts will fire twice as fast as well.  VSYNC is at 120Hz in double-speed mode with this board, and HSYNC is doubled as well.

IMG_20190402_092749Stable memory with RC delays on DRAM strobes (over 1.5 billion verified writes)

This shouldn’t pose a problem to the programmer, as it’s exceedingly easy to skip every other IRQ if you really want a lower rate or otherwise adjust the code to use the appropriate timing.  At this date, the only stable double-speed CoCo1/2 machines will be using this 120Hz system.

Most things will work just fine, but at 2x.  Things using the interrupts for timing might need adjustment to run at the higher rate.  At any rate, the double-speed poke was essentially useless on the CoCo1/2 due to the lack of DRAM refresh.  With one of these accelerator boards, it’s stable and useable.

In the following video, you can see the CoCo running a short BASIC program, switching between .89MHz and 1.79MHz printing characters on the 32 column screen.  The speed difference is apparent, and the transition from one mode to the other seamless!

Switching between speeds

Running the system at 1.79MHz does require DRAMs with a 150ns speed rating or faster, but many CoCos that have been upgraded in the past may already meet this requirement.  I’m not certain yet whether or not the PIAs require upgrading to 2MHz rated parts as found in the CoCo3 (presumably for double-speed use), but those parts are readily available if needed.  Just for fun, I popped a SAM board into a CoCo1 ‘F’ board I had open while programming CoCoVGA boards for shipment.  It ran just fine, and though I didn’t test it extensively, it flawlessly did over 40 passes of the memory test I wrote before I shut it down (~8 million verified writes).

SAM board in a CoCo1

At the time of this writing, I’m about to receive REV02 boards, which include reliability patches I had to make to the initial prototype.  I intend to release these as an optional item for CoCoVGA users that want more performance out of their system.  And thanks to improvements to the CoCoVGA logic by Brendan Donahe, they’ll also enjoy the crisp video output on their monitor, even at 1.79MHz!

REV02 CoCoVGA SAM board design


…more to come…


Mega-mini USB module

To make the serial ports on the Mega mini MPI more useful.  I plan on designing several modules that will connect to the UART header on the side for connection to other devices.

The first of these is a dual USB serial bridge module that will allow direct connection via a USB cable to a modern Mac or PC for a hi-speed serial connection.

They use an FT232 serial USB to UART bridge IC, which I chose because of it’s capabilities, ease of use, and it’s good driver support for modern OSes.

IMG_20190117_165940Mega mini USB module, assembled prototype

Connection speeds of up to 921600 baud are supported, with some initial tests showing sustained transfer rates on the CoCo of 52KB per second at .89MHz on a CoCo2, and 78KB per second on a CoCo3 at 1.79MHz.

IMG_20190118_143827IMG_20190118_174741.89MHz transfer test at top, 1.79MHz at bottom

You can see the prototype module connected to the Mega mini in this next picture.  I need to design a 3d printed case for the module soon to bring it all together.

IMG_20190117_170300.jpgModule in Mega mini UART port

REV02.pngREV02, likely the final design


The GIME-X project is a collaborative effort involving Gary Becker and myself.  Gary heads up the CoCo3FPGA project and so has done a lot of work implementing the CoCo3 in FPGA form.

We had previously worked together on getting the analog board add-on for the CoCo3FPGA project produced, and when Gary approached me with the idea of working on an FPGA based GIME chip replacement I was delighted.  Especially as this was something I’d already been thinking about, as well as it being something that would be really useful, as original GIMEs are not available to replace dead ones.

IMG_20190328_084923A 1987 version GIME

Gary is handling the Verilog, while I’m responsible for designing and building the hardware.  I decided to go with a lower-end Altera Cyclone IV FPGA in the 144 pin QFP package for cost and ease of use/manufacturing.  It was also a device I’d previously used in the CoCoVGA design, so I had some experience with it, and it was more than up to the task at hand.

So I designed a PCB that would plug into the GIMEs PLCC socket.

20180412_21224520180412_212254The GIME-X

The board has the necessary FPGA, level translating buffers (5v to 3.3v logic), regulators, oscillator, flash, and DACs to pull a replacement together.  In addition to the normal functionality of the GIME, enhancements are added, such as VGA video output and additional graphics modes.

53345306_2319737351639277_3698342458220871680_oGIME-X, REV03

We’ve made a lot of progress, going through a few revisions of the hardware until we had that part sorted out.  At this stage we have a working board and configuration, and are refining the Verilog while testing it with various hardware and software working on making it as compatible as possible.

Artifact colors will be simulated on the VGA output for games that use them.  I made the following video shortly after that was implemented.


Simulated composite artifacts

As we get nearer to completion of the GIME-X project ad prepare for production there are a number of things to consider to help it go smoothly.

One of the larger hurdles involved in making a board that plugs into the GIME socket is the PLCC plug that will be required.
While such a thing is available out there, they are clearly not a high demand item, and range from ridiculously expensive (as in over $100 each) to merely annoyingly so. The cheapest I’ve found is still $10 per part, a significant amount when the other components are added up as well.
68-pin PLCC plug
Add to this that most of them are very high profile, and not useful because of clearance considering where the GIME is situated on the board (partially underneath the keyboard).
Luckily for prototyping efforts, I was able to modify the least expensive plug available to get just enough clearance with the design. This is an option for production, but expensive, time consuming, and even then still has barely adequate clearance.
What to do?
After some thought, and studying the adapters I modified for use on the prototypes, I came up with an idea.  The plug uses pins with a 1.27mm spacing, which are too long, resulting in the need to trim them for a lower profile.  Shorter pins are available as SMT headers.  By combining these with a 3d printed block for the plug body, I have a solution that is inexpensive (about $1 per plug), and no more trouble to manufacture with than modifying the expensive ones.
SMT headers and 3d printed plug
3d printed PLCC plug installed
Another benefit is that these are also of the lowest profile possible, giving me more clearance for the GIME-X.  They also fit more deeply into the socket for a more secure fit.

Every millimeter counts (3d plug on right)


So there you have it, an easily available and more economical solution for the PLCC plug.

Other additions to the design also seem appropriate as the project nears completion.  For instance, an NTSC encoder and analog circuitry to support composite and s-video connections, as well as support for >512K memory expansions.

To these ends, I’ve revised the design for the next prototype boards, which you can see here…

Improved design with NTSC video and >512K support



…more to come…

CoCo Chiptunes Player

The CoCo Chiptunes player is a little application I wrote to help with development of the Mega-mini MPI with it’s built-in YMF-262 (OPL3) FM synthesis chip.  It also supports the CoCo PSG (Yamaha YM2149), and will be updated to support other CoCo sound chip devices as they are made available, such as Jim Brain’s CoCo SDC Expander.

The program uses a menu system similar to the CoCo SDC Media Player’s to browse and select files on the SD card for playback.


CoCo Chiptunes Player

Both OPL2, OPL3, and YM files that have been converted to .CCT (CoCo Chiptune) format can be played back.  Initially, the system required a CoCo PSG to be in the multipak, as it utilized the 512K RAM chip there for storage when playing chip data.  With version .3, the player now utilizes a ring buffer in upper RAM, and no longer requires extended memory beyond 64K.

Requirements for use currently are; a 64K CoCo 1/2/3, a Mega-mini MPI, or any other MPI and a CoCo PSG.  A 6309 CPU, and a CoCo SDC is also required.

Attached at the end of this page, you’ll find a link to a .DSK image with the player.  To run the program, simply mount the image in drive 0 using your SDC, and type ‘DOS’, then press enter.  From there browse to a .CCT meant for your particular sound device and hit enter to play it.  The ‘BREAK’ key will exit playback and return you to the browser menu.

At the link you’ll also find a zip containing .CCT files to play.  Unzip the file and copy the .CCT’s over to your SD card containing the player .DSK image.  It’s a work in progress so there may be a glitch or two, but I hope you enjoy it anyway.  🙂

I haven’t had an opportunity to test every file included, and not all of them are great, but there’s definitely some gems in there.  Give it a try and let me know what you think!

Download the Player!




CoCo OPL Composer

Now that a number of MEGA-mini MPI’s have made their way out into the world, it’s time to start in with some software to support some of it’s extended features, and to help with further development.  One of these features is the YMF-262 (OPL3) chip included in the MEGA-mini.

Though VGM style music is pretty easy to prepare and play back using a few cross-platform tools and a player that I wrote for the CoCo, I wanted to try something a little different.  Something that would let you use the CoCo itself to compose music for the chip.

Thinking about how I might want to go about this, I decided on some features.


  • would run on a single-speed (.89MHz) CoCo1/2
  • would use the CoCoVGA’s 64 column text mode
  • would generate sound data designed to play from interrupt
  • would keep the resulting data as compact as possible (without using compression)
  • would use a ‘tracker-like’ interface

One of the first things I determined was the general form the data would take.  Using a tracker like format, the song pattern is 14 channels (columns) wide and uses one line per interrupt period to display the events for each channel.

I determined that at a minimum, we would need to define the following events (in the data) in order to operate the YMF-262…

  • a ‘start interrupt period’ indicator per line (IRQ period)
  • a ‘key-on’ event – the command to start playing a note
  • a ‘key-off’ event – the command to stop playing a previously issued ‘key-on’
  • an ‘end-of-song’ indicator

Deciding to structure these events as a series of commands, I came up with the following command (event) format.  Commands can be of variable byte size, and are arranged in channel order (0-13) after an IRQ indicator.  The upper nibble of a command byte indicates the command.  The lower nibble indicates the channel the command is for.  If the command requires additional data, it will immediately follow the command byte.

$Fx – start of IRQ period.

Data between this marker and the next ‘$Fx’ byte is the event data for this period, appearing in order of the channels (0-13).  Data is only present for a channel if there is an event for the period

$Ex – ‘key-on’ event.   This is a two-byte command

The lower nibble is the channel number, a note/octave byte follows this with the note encoded in the upper nibble (A-G = 1-7) and the octave number (0-7) in the lower nibble.

$Dx – ‘key-off’ event.  One byte

The lower nibble is the channel (0-13).

$Cx – ‘song-end’

Indicates the end of song data.

These are the possible events I’m implementing to start with in building the composer.  This scheme leaves room for eleven other commands to be defined at some later time if needed, but for now, this gives us something to work with.

The byte-stream used in the composer during editing is stored in the same arrangement as the final generated data will be in order to use the available system memory as efficiently as possible.

With the basic data format settled on, we move on to the user interface.  Laying down the basic structure of the pattern editor screen.


The editor screen

The layout of the editor screen is shown above.  You can see the pattern laid out by line number (IRQ period) and sound channel.  Fourteen of the available eighteen 2-operator channels on the YMF-262 are used due to screen width.  Fourteen is quite a few instruments to work with though.  The remaining four can be used for additional in program sound effects depending on the software (game or whatnot) using the generated song.

The following video shows some of the initial progress.  Pattern editor window display, navigation, and IRQ based parsing and playback of the data have been implemented.  Next I’ll be working on the user interface for entering events in the editor.

Off to a good start

Since the last update I’ve been working on implementing some of the interface features for placing and removing events.  I have a method of placing notes by octave and note in the pattern, and was even able to grab a piece of sheet music off of the internet and enter a recognizable tune into the first channel in just a few minutes.

Entering events

I’ll be working on ways to make entering events quicker and easier as I work on other features of the program, such as loading and saving sequences to the CoCo SDC.  My plan right now is to save the data out into files on the FAT volume that’ll be easy to take into a modern machine to use in cross-development environments for putting together CoCo software.

But before I implement loading/saving, I think it’s time to nail down how timing will be used in the composer.  In particular, I’d like to make it easier to transcribe sheet music into the pattern.  This should also make it easier for actual musicians who are accustomed to reading and writing music to work with.  After some study of how timing information is encoded into sheet music, I think I’ve settled on how to handle timing.

My understanding is now that 4/4 timing is the most common employed, and so we’ll go with that as we move along.  The 4/4 time signature indicates 4 quarter notes per measure.  Song tempo is measured in beats per minute (BPM) and relates to our notes in that it gives us our note (and rest) durations, which are measured in beats.


From this, we’re able to calculate the time in seconds of a note, for instance, a quarter note in a 120 bpm song would have a duration of 1/2 of a second (120/60 = 2 beats per second).

Different pieces of music use all sorts of different tempos (bpm), so our composition software must take that into account.  In order for the timing of our pattern based system to closely follow the usual system for music, we’ll use beats for our timing as well.

Notes can go down to very short durations, as little as a 256th note, or 1/64th of a beat.  This is probably a little impractical for what we’re trying to do here, as we are also trying to minimize (or at least be reasonable with) storage and playback requirements of music on the CoCo.

Take for example a song at 120 bpm.  A whole note would be 2 seconds, a 256th note .0078125 seconds (128th of a second).  I think a more reasonable downward limit on note duration for our purposes is a 32nd note (1/8 of a beat), which will also be more in line with human hearing perception at beat rates we’ll likely be using.

So, going from that reasoning, our shortest duration, measured in beats, will be 1/8 of a beat.  Since our composer operates on interrupt periods, this means 8 IRQs per beat will be the basis of our timing, from which we’ll calculate the timer setting for our IRQs.

In other words, from the user perspective, you’ll set your beats per minute, and then just remember that each line is 1/8 of a beat.  The bpm will be adjustable to make it easy to transcribe and write music.

*** more to come ***