Jump to content
IGNORED

TRS-80 coco help....again.....SOUND...


GreenDayRlz

Recommended Posts

You need to find a copy of the technical manual. I see a link to one that is gone, but much of it seems to be on archive.org:

 

http://web.archive.org/web/20060519101743/...oco/coco_tm.htm

 

Luckily, it seems that the big diagrams got archived. (also, if you replace "20060519101743" with "*", you will see the versions for that page)

 

As I recall, sound is a simple 6-bit D/A converter, which is also used for the cassette output. I see it on page 66, and it seems to be on the high six bits of PIA1 port A. It looks like the sound output select bits are PIA0 CA2 and CB2, and also PIA1 CB2.

Link to comment
Share on other sites

http://www.coco3.com/modules.php?name=Cont..._sound_register

 

http://www.electronics.dit.ie/staff/tscarf...pia/6821pia.htm

 

You need to take a look at the 6821 and understand what it does. You get sound by setting some of it's pins to outputs, then by writing values into it's control registers. The first link I posted is a tutorial on how to do that and read the analog joysticks.

 

The second one is some info about the 6821 that should help you put the tutorial into context..

Link to comment
Share on other sites

oops!

 

http://www.electronics.dit.ie/staff/tscarf...821pia/6821.pdf

 

That's the data sheet that describes the functionality of the 6821.

 

Remember, the CoCo is a memory mapped machine, so the register names in the data sheet will equate to memory addresses you can "poke" STA to.

 

Look at the code fragments in the first link to map those out.

Link to comment
Share on other sites

WOW!

 

Thanks, I will experiment with. Getting joysticks into my game would be awsome, and would only take about 10 mins to modify my program to use them. I left tons of space for keyboard expansion lol, from 3050 to 3100...I think that`s alot lol. I`m justa beginer though....

Link to comment
Share on other sites

I'm 40 now. Was into the Coco, Atari and some C64 during the mid to late 80's. At one time, my good friend and I had the CoCo and Atari setups writing assembly language for all sorts of stuff.

 

The 6809 is a very fun CPU to program. It's got lots of great addressing modes, and it's quick. On the CoCo 2, the graphics were not stellar, but there is enough to do fun things.

 

My fave was the CoCo 3, which I toyed with in the very early 90's for a while. IMHO, it has lots of untapped potential. Great little machine.

 

In the mid-90's I sold all but the Atari machine to pay for some life stuff. Regret that, but maybe will play again someday.

 

If you are into sound, there is an expansion pac for the CoCo that delivers two channels of A/D sound. It's 8 bit per channel, I think and it takes assembly to drive, but it's a lot of fun. It works in a fashion similar to the limited 6 bit DAC you have in the CoCo 2.

 

The real headache with sound on that computer is that there is no sound hardware to assist you, meaning you've got to weave the sound into your game code, or have game play stop when a sound is played. This requires a kernel of sorts that divides activities across sound, game computation, reading the joystick, and doing graphics. Not easy stuff, but then again, the 6809 is not exactly a wuss CPU either.

 

My activities with the CoCo back then were mostly limited to graphics and I/O. Wrote some minor league games and explored assembly a lot. I didn't do all that much with sound, mostly because I was distracted by the Atari and C64 sound chips. Those can run while code is executing, so it was easier...

 

One thing that the Apple and CoCo share is bit banging sound. That's where you are responsible for basically all the speaker movements. On the Apple, many game sounds were made an intergal part of game loops. I suspect this is probably a good approach for the CoCo.

 

Get your game up and running first, then weave in the sound after the fact.

 

Good luck. That pile of docs at that site is really a find though. Most all of what you need to know about that computer is there.

 

Be sure and browse up and down the directory structure. I only linked a coupla things that would point you to the sound generator.

 

It's gonna go like this:

 

Configure the 6522

 

Write values to it in a loop

 

You get sound!

 

What values you write will determine the volume of the sound. It's a DAC, so imagine the lowest value being speaker rest and the highest one being speaker popped out. Alternate between these and you get a LOUD square wave. Alternate between closer values and you will get a quieter one. Vary the time between movements and that's pitch.

 

Very simple stuff there.

 

After a time, you can then ramp through sets of values to get other waveforms. Those take more compute time though...

 

IMHO, that's a very fun retro computer. The multi-media isn't the best, but there are good docs and learning assembly on that 6809 is a good experience.

Link to comment
Share on other sites

Re: What happened?

 

I grew up! Getting older sucks man. Enjoy your kid time --hope I am talking to the same person I did a while back, if not, sorry!

 

Seems that the circle of busy life comes around though. My kids will be leaving the home soon, and I've just moved. In time I'll be free to tinker and explore more, so all is not lost.

Link to comment
Share on other sites

Lol, sorry I guess.

 

I`m 14, and I think that every time it goes through 256 Keyboard "CHECKS", It will first go see if a sound is going on, then goto a sub routine that will make the next step in the sound and then jump to program to see if there`s another asteroid coming (Random I guess), and them move all the asteroids, and then check to see if your dead.

 

I`m making this program a bit at a time. I`m stuck on how I`m going to randomize when the asteroids come up.

 

 

I was thinking making a program that counts from 1 to 99 in regular way, and every 256 checks goes to set the asteroid if less then 32, and at that spot.

 

WILL EDIT THIS LATER, SORRY HAVE TO GO!

Link to comment
Share on other sites

So are you doing this in assembly language or BASIC?

 

If you are using assembly language, I think the best way to handle the sound would be with a horizontal retrace interrupt. I know there is one because I've used it. (The Videotex cartridge used it to get a rock-solid 300-baud serial input, at the cost of about 50% of the CPU time. And the only reason I know how much time it took was that I spliced it to work in BASIC.) And now that I think of it, unlike the horizontal retrace interrupts in many video game console systems, this one works on every scan line, not just the picture area.

 

So you could have sound samples somewhere, whether digitized or wave tables, and the interrupt routine can add together two or three or four channels of them and push the new volume level out continuously. Since you probably don't need 15KHz sampling resolution, you could have a flag or counter to have it work on only every second or third scan line.

Edited by Bruce Tomlin
Link to comment
Share on other sites

Wha?

 

I`m doing it in assembally. Right now I need someone to tell me what to store and where and at what time. I know it`s six bit. That TRS-80 coco assembally lang. book has sound in it, and it`s not exactly written for 14 year olds. It doesn`t tell you how to, just how it works. Anyone got any more help?

Link to comment
Share on other sites

  • 1 month later...

Um, the Apple II and Coco's sound are very different. The D/A converter on the CoCo is way better than toggling the speaker at different speeds for different tones.

 

If you can get a copy of an old Rainbow issue that focused on sound and music it has everything you really need. I'll see if I can find my copy.

 

The concept is pretty simple.... implementation can range from simple to crazy complex.

If you can get a copy of an old Rainbow issue that focused on sound and music it has everything you really need. I'd have to look up what issue. There was also an issue of Color Computer Magazine with the source for multi-voice music.

 

Without that... here is the basic description. You have to set the PIA to enable the sound and then you just output the 6 bit data from the waveform to the D/A converter at the proper sample rate. The best way to do that is with an interrupt handler that drives the D/A converter and times the interval to advance through the waveform data. The pitch is controlled by altering the number of cycles in the timing to count through the waveform.

You can go even simpler by just outputting bytes to the D/A converter inline with your code using timing loops. Early CoCo games like Space Assault did this.

The BASIC SOUND and PLAY commands also do this. They use a sign wave for the waveform but instruments, voice or other sounds can be used with more complex waveforms.

 

If you want decent sound you'll want to create waveforms and use interrupts. The CoCo3 timer interrupt is one of the best ways to produce sound.

 

BTW, the source code to Pac-Dude Monster Maze is available and it includes music and sound playback routines.

http://nitros9.lcurtisboyle.com/pacdude.html

Don't expect any comments.

Edited by JamesD
Link to comment
Share on other sites

Ok, I got out my copy of Assembly Language Graphics for the TRS-80 Color Computer.

The book starts out with a sound program early on but it is entered with a monitor rather than assembler which may give you the inner workings but it complicates things.

 

I don't have time to test this but it is an attempt at commenting and converting the code to assembler source.

 

SNDMSK  EQU  $3F   ; this is the setting for the PIA to enable sound.  Binary = 00111111 (6 bits for the D/A converter)
SNDNABL EQU  $FF23; the PIA is memory mapped in this range.  This is the register we set to enable/disable sound.
SNDOUT  EQU  $FF20; the PIA addres where we output sound data

	ORG   $0700 
	LDA   #SNDMSK ; load the PIA setting
	STA   SNDNABL  ; set the PIA
	LDX   #$FF  ; load X decimal 255
@L1	 LDB   #$5F  ; tone value $5F aka decimal 95
@L2	 STB   SNDOUT ; write the tone value to the D/A converter
	NOP   ; delay a few cycles before we output again
	NOP
	NOP
	INC B ; increment the tone value
	BNE  @L2 ; check the CPU flags and branch if B not equal to zero
	DEX   ; decriment x
	BNE  @L1 ; check the CPU flags and branch if X not equal to zero
	RTS ; return to BASIC or monitor
	END

Link to comment
Share on other sites

If you look at the program... it presents the basics of what you need to do.

Output data to the D/A converter at regular intervals and vary the data to alter the waveform.

The example is very simple and it appears to create a sawtooth waveform.

 

Within a game you would load the current tone value, output it, increment it and save it for the next output.

Then you would continue with more game logic. You would need to execute enough instructions of your game to create a similar delay and then repeat the sound output. The sound routine would be called with a JSR.

As you get better at programming you modify the sound subroutine to use a waveform table instead of a loop.

On a computer with a sound chip the chip continues to drive the sound output between accesses.

With a D/A converter however, you have to output lots of data to keep driving the sound.

Link to comment
Share on other sites

  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...