Chapter 04 - Let there be music (Part 1)

It's been a hectic June that has hindered progress on Gunstar.

Here in Australia, June is the end of our Financial Year and that has meant a very busy time at work. All accounts had to be finalized and closed before the end of the month.

July wasn't any better when we unfortunately lost my Father-in-Law to heart failure and will take some time for all to accept.  :(

As things begin to settle, I have resumed work on Gunstar.

Music is one feature I haven't incorporated in my programs thus far. Not being too familiar with the generation of actual music, not anything worth listening to at least,  I always chose to focus on providing great sound effects.

But with all the activity in the CoCo community regarding sound chips and music, I decided to look into it.


The CoCo has a 6-bit DAC (digital to analog converter) which is simply hardware which creates a varying voltage output by feeding byte values of 0 to 63. This varying voltage is manipulated by software to form waveforms and sent to the audio output to be heard as sound.

The DAC's output can be channelled to the cassette port for recording audio to save programs and data to tape. It can be routed to the audio out and  RGB connector (CoCo3) for audio playback. All CoCo's mix the audio generated to the RF television output.

The DAC itself is a very useful circuit that can also be used as an ADC (analog to digital convert) with the combination of a comparator circuit within all CoCo's to read up to 4 analog lines such as from the joysticks.

But using the DAC for sound requires the CPU to devote time to feed it the required data stream. Depending on how heavily a program is using the CPU, the amount of time left over for the generation of sound is limited. A program that only plays music for example could devote most of the CPU time to the generation of good quality sound, but a game that requires as much of the CPU time as possible for the generation of graphics and gameplay will leave less time for sound.

This is the predicament I face with Gunstar. It's the same as with any game I've created but due to the high CPU demand required by the Sprite Engine (Chapter 2 of this blog), it is especially more restrictive.

Sound Chips versus the DAC

Back in the early 80's and before the CoCo3 was released, Radio Shack released two hardware add-ons to provide the CoCo with sound generating hardware.

The Orchestra 90 was a cartridge which included two 8-bit DAC's. It functioned very similar to the CoCo's internal 6-bit DAC except it was 8-bits resolution which allowed higher fidelity. Also, with two separate DAC's, it allowed for two physical channels to be played in stereo. The sound was output via two RCA jacks for the left and right output channels.

Software mixing of the data streams within the CoCo could provide two audible channels to each physical channel to achieve four voice sound and music. More is also possible but with degrading sound quality.  The same can be done with the standard built-in 6-bit single channel DAC.

CONS:  The Orchestra 90 cartridge, as with the CoCo's built-in DAC, also required the main CPU to devote time to feed the DAC data streams and therefore offered no advantage to alleviate CPU burden for sound within a game.

The audio output required a separate line for amplification from the standard built in DAC sound to the TV/monitor. Not a game stopper but it did require more hardware taking up desk space. This cartridge saw more support in the area of music but very little for games.

The Speech-Sound Cartridge (S/SC) was a different beast that provided a dedicated sound chip (AY3-8913) as well as a dedicated speech processor (SP0256-AL2). Basically, you set registers within the chips to control the internal functions. The chips themselves generated the sound without the need for intervention from the computer's CPU except to alter the control registers of the chips.

The S/SC actually contained its own mini CPU with 4K of ROM to contain the operating software and 2K of RAM to store sound and speech data. All audio was output back into the CoCo where it could be re-routed to the normal audio/monitor connections.

CONS:  The S/SC was a  slow device to operate due to the way the I/O was implemented but there was a way this could be alleviated I am told .  The speech quality sounded very Stephen Hawkins 'like that was fine if you were creating a game featuring the Daleks from Doctor Who but was annoying after a while.

The biggest problem with this cart was that it didn't work on the CoCo3 at the higher clock speed of 1.79 Mhz. A fix was documented that explained how to modify the cartridge internally but it was too much to expect every CoCo3 user who had this cartridge to attempt this mod. Also, writing software for the CoCo3 at the slower .89 Mhz defeated the purpose of using the cart to make up for lost CPU cycles when you lost 50% of them to make the cartridge work without the modification. Thumbs down!

Both of these cartridges required the user to have a multi-pak interface to have them operate alongside with a disk controller.

Using the S/SC from a commercial software standpoint presented too many barriers that limited the audience size for software to take advantage of it. This would explain why there were so few programs released in the last 30 years that actually used it and those that did, failed to exploit it to anywhere near it's potential. 

The lack of a built-in sound chip as a standard part of the original CoCo design has been a great omission that has seen the CoCo play the underdog when it came to game audio compared to competing systems.

Radio Shack's compromise for the CoCo3

Tandy had a target to manufacture an enhanced CoCo3 with more features yet be cheaper to manufacture than the current model of CoCo2. The CoCo3 offered many sought after features with improvements in the visual output, CPU speed and was tailored to run the Level II version of OS-9.

Unfortunately, the inclusion of a sound chip was omitted to keep costs down and as a compromise, offered advanced interrupt handling (required for OS-9 Level II) of which the new Programmable Timer interrupt, along with faster CPU, would allow the capability to more effectively generate sound via the built-in DAC as well as improved bit-banger serial port timing (this saved the addition of a serial UART chip).

The CoCo community strikes back!

We have recently seen a number of  projects in the community to provide an alternative option for Radio Shack's long discontinued sound cartridges.

Concentrating on the ones that provide an actual sound chip... these have been based on a similar sound chip as used in the S/SC but avoid all the complexity of a micro controller to allow more direct access to the sound chip and support all models of the CoCo. The simpler design also makes for a lower price point than the original which cost around $100US around the mid 80's. At time of writing...

  • John Linville has created a cartridge capable of storing up to 256K of bank switched ROM along the lines of the Super ROM Paks that Radio Shack sold with games like Super Pitfall, Robocop and Predator and also provides a SN76489 sound chip.

Time to make a decision

So getting back to Gunstar, I needed decide if I create sound for the built-in DAC or one of the sound cartridge designs.

At this early stage of development, I've chosen to stick with the standard 6-bit DAC and here is a list of reasons why:

  • From a commercial program development point of view, I need to create for the largest and widest possible customer base available. The glory days of the CoCo when the customer base for games software was in the thousands are over. The market is much smaller nowadays. If I am to spend so much time and effort developing a commercial grade game, I need to target as many potential customers as possible. I can only do that by making my software run on as many CoCo3 configurations possible. The base configuration I am targeting is a CoCo3 with 512K and disk access device such as a CoCoSDC or Drivewire.

    When you consider that over 500 CoCoSDC's have been sold, that makes a healthy number of people who have what I consider to be the greatest ROM pak ever made for the CoCo. Fast loading of any program, whether it be disk, converted ROM Pak or cassette, on a single cartridge which can also operate as a Hard Disk for those who use OS-9. It's just too bad it didn't include a sound chip as part of the design... but that's another story.  :)

  • If you've read Chapter 3 of this blog, you'll read about what I have already created for the sound effects in Gunstar. My FIRQ interrupt driven, two channel sound effect routine plays digital samples with minimal CPU overhead using the CoCo's standard 6-bit DAC. As a bonus, they sound fantastic and are easy to use. The internet provides a wealth of freely downloadable WAV sound effects that can be converted to the CoCo.

  • The end product can be sold to the consumer at a lower price, widening the number of potential sales. The inclusion of a sound chip immediately bumps your costs by around $20 when you include a PCB, electronic parts and cartridge case. Add to that an increased postage cost from Australia and my game would have to sell at around $40-$50. This is not totally prohibitive and would amount to a nice collectable product for those inclined. But for many others, that price point crosses the barrier of whether to buy or not to buy especially if they are not specifically gamers.

    Looking at my last game PopStar Pilot, it was sold on CD from which people could extract the DSK to mount into their CoCoSDC or Drivewire. I sold the complete bundled package for $25US including postage from Australia. PopStar Pilot went on to sell over 70 copies and showed not only a market for good low cost games but also the generous support of the CoCo community. (That's why I have returned to create Gunstar).

  • At one point, I contemplated the possibility of having the current DAC sound effects AND sound cartridge (if one was detected) to combine music from the sound chip and mixed in with the DAC sound effects. People without a sound cart would miss out on the music but still hear the digital sample sound effects.

    This seemed like the best option... until I found that due to the internal routing of audio lines within the CoCo, the two sound sources could not be mixed into one.

But I was still stuck with the desire to include music in my game and while I experimented with the possibility of expanding my FIRQ sound effect routine to include music during game play, the results did not meet my expectations. There simply wasn't enough CPU cycles left over to produce GOOD music as well as sound effects during game play. Gunstar will be a CPU demanding game. A less demanding game would allow such but I was setting high goals and without the aid of a sound chip, I would have to sacrifice the in-game music.

But I'm not one to accept complete defeat! I wanted to have some music in the game, even if it were not in-game and so my mind began to wander into the realms of creativity.   :)

A sound chip in software!

I was relatively familiar with the internal workings of the General Instruments AY-3-8910 sound chip that most of the CoCo sound chip options for the CoCo used or were based on.

Without going in to detail, the main features of this chip are:

  • 3 separate sound channels.

  • 3 separate square wave tone generators each assigned to one of these channels.

  • One variable noise generator which can be selectively mixed to any of these channels.

  • Attack and Delay envelope control on each channel.

I have chosen to try and mimic these functions via software and have begun a side project to create an engine that will do just that. I am calling this, my chip-sound routine.  This is still a work in progress but the chip-sound functions that are working at the moment are:

  • 4 separate sound channels.

  • 3 of the sound channels are driven by separate square wave tone generators.

  • The 4th channel is driven by a variable noise generator.

  • Attack, Sustain and Release envelope control for each channel.

As you can see, I am closely modeling it on the AY-3-8910 sound chip. In the future, I may even add extra tone generators to create other waveforms such as sawtooth and triangle waveforms but I am keeping it simple at this point.

Introducing GTracker!

To the right is a screenshot of the song composer I am currently creating to compose music for my chip-sound routine. It is titled GTRACKER which stands for Game Tracker. It is written in machine language and I hope to eventually release the software along with the final game as a tool for people to use in the development of non-in-game music or stand alone.

The program is roughly modeled on the famous Amiga MOD player program but using tone generators and envelope control code instead of samples. John Kowaski's CoCo MOD player more closely functions and supports the Amiga MOD player format... but he's a genius and I am not.   :)

The area on the right is where the 4 tracks are composed. The area in the top left is the Pattern Sequencer. Below that is where the various parameter control settings are displayed such as the Attack, Sustain, Release (ASR). And in the centre are some of the keyboard control options.

WHEN and IF it is successful, I will compose some original music to include in the Gunstar Title and Game Over screens.

This is all a learning experience for me but hopefully will eventuate to become a useful tool for future game development.

To be continued...

In Part 2 of this chapter, I hope to have GTracker completed and I can demo some of the music I create.

Copyright 2017 by Nickolas Marentes