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.
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
But with all the activity in the CoCo community regarding sound chips and music, I decided to look into it.
CoCo has a
6-bit DAC (digital to analog converter)
which is simply hardware which creates a varying voltage output by
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
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
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
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
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
the sound without the need for intervention from the computer's CPU
except to alter the control registers of the chips.
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.
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.
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
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.
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:
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.
- 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
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'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:
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:
- 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.
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.
- 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.
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
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
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.