Chapter 21 - May 25th, 2015

Come on feel the noise!

Time for a break from all the coding and time to start generating some sound.


Back in the 80's I bought a program called Sound Studio from Oblique Triad that does sound sampling and editing on the CoCo3. I remember attaching my cassette player to the cassette interface with a special audio cable and playing sounds I recorded via cassette to be sampled on the CoCo.


Nowadays, it's just so much simpler to type Free WAV into Google and be taken to a myriad of websites that offer freely downloadable audio samples in WAV format. Programmers have it so easy nowadays!


I decided to follow the lead and go the Google route... and also because my cassette player is currently busted.  :)


The problem I was left with was how to load these WAV files into the CoCo. A few more taps in Google and I located a BASIC program by Stuart Wyss called WAVPLAY that did exactly that. It loads most WAV files in an 8 bit unsigned format straight into the CoCo3's RAM and this then allowed me to take over.


I started off using Digital Sound Studio on my Amiga which allowed me to manipulate the WAV files for use on the CoCo but then ran into problems because it didn't allow me to write out an unsigned WAV file, only signed. WAVPLAY on the CoCo could only read unsigned so, with much hesitation, I had to resort to using Audacity on my PC to do my sound editing. Audacity is a great free audio editor, it just wasn't... retro enough.  :)


With the sound loaded on the CoCo and a few further tweaks, I had gunshots and explosions coming from my game. I haven't added the code to make my plane actually fire or have any objects to blow up yet so I triggered each sound manually by assigning them keys on the keyboard. I could play either sound or both at the same time (two channel) and there was no slowdown in my game. Everything moved as before and the best part of all was that It took up almost no additional time according to my speed evaluation code.


Adding two channel sampled sound playback in realtime with no speed penalty?


Not entirely true... I had within my interrupt service code, the ability to play two sound channels all along. The sound playback was the first component included and then I tapped into this to add the split screen scrolling and Amiga'like raster bars effect. So the routine had been running all along, it just had no sound samples to play.

So this was the big test to see if the sound routine was running at the right rate. I had resampled all my sound samples to 8Khz because that was the lowest Audacity would let me resample down to. The CoCo I estimated would play those samples at about 6 to 7Khz, which was close enough.

This is considered low fidelity (the old phone lines were around 11Khz) but I had to pick the lowest sample rate to reduce the CPU drain yet still create a reasonable sound. I am lucky that gunshots and explosions are more forgiving than pure notes and that they hide most sound artifacts at this low rate.

Oh how I wish the CoCo had a dedicated sound chip!


Hear the noise!

I had reserved one 8K block for sound samples. This is a lot less than what I would have liked but memory is tight when the CPU only has a 64K address space and I wanted to avoid banking the sound table RAM space in and out of the CPU address space so frequently. I will have to devise something if I want to add addition sound effects but these three sounds will make up the bulk of the main in-game effects that need to be played simultaneously during gameplay.


The sound samples are listed below and you can play each sound sample as used in the game by clicking on the sample name or download it by right-clicking on the sample name and selecting SAVE AS.













'86 and '87 GIME compatibility


My development CoCo3 is a PAL unit running the 1987 version of the GIME chip. PAL is normally 50Hz but the GIME can be set to 60 Hz operation and this still works fine on PAL monitors and TV's. My code works on NTSC CoCo3's the same way.


The 1986 GIME though has slightly different timings when it comes to the horizontal interrupts. This plays some havoc with code that relies on this timing so precisely like PopStar Pilot.


The genius of John Kowalski came to the rescue again and he suggested using the 14Mhz (fast interrupt) to trigger the Timer interrupt. A value can be found to closely mimick the Horizontal Interrupt and this will largely do away with the timing discrepacies.


This I found was indeed the case and the one version of the code now works on both '86 and '87 GIME models... almost.


The GIME has another problem with Palette settling time. Robert Gault informed me of this display problem when testing my code. What was happening is that when the palette is altered anytime the GIME is drawing any active part of the display, both versions of the GIME create a visual glitch as the palette registers take the new palette value.


The work around is to time these glitches so they occur off screen and are not visible. The use of the 14Mhz interrupt for the main timing allows that flexibilty and I have worked out values that work correctly for both versions of GIME. All that is left is to add some code to work out which version of GIME is in use and add the appropriate value automatically.


That is a challenge for another chapter and right now, I'm off to make some noise!  Bang!  Kapow!




Copyright 2013 by Nickolas Marentes