

|
Volume Number: | 1 | |||
Issue Number: | 9 | |||
Column Tag: | Assembly Language Lab |
"Wired for Sound"
By Chris Yerga, MacTutor Contributing Editor
Can You Keep a Secret?
One of the Macintosh's best kept secrets is its wonderful sound driver. This beauty is capable of generating a variety of sounds including simple tones, multi-voice music, complex speech, and digitally recorded sounds. In spite of its power, it is relatively easy to use once the programmer takes the time to understand a few basic concepts. This month's column concerns itself with the sound driver and the techniques the programmer must employ to use it. First will come a description of the device manager, with emphasis on it's relation to the sound driver in particular. The actual sound driver description is next, followed by a sample program that ties it all together.
First Things First
First, a bit of background information on the device manager. The device manager is the part of the Macintosh ROM that allows the use and control of devices, which are usually hardware peripherals connected to the Mac. Examples of devices are the serial ports, the disk drives, the sound driver, etc (desk accessories are also considered devices, however, we will not include them in our general discussion).
There are two types of devices: character and block. Character devices can read or write only one character at a time and they must do so sequentially. That is, they cannot access any data other than the very next character. Whereas block devices read and write data in 512 character blocks and are randomly accessible. This means that they have access to any block of data, regardless of its position. Another matter of note is that many device manager routines may be executed either synchronously or asynchronously. Synchronous execution means that the calling program remains idle while the requested I/O operation is performed. Conversely, asynchronous I/O operations are performed while the calling program is running.
Now Some Specifics
The device manager is one of the portions of the Macintosh ROM that has a register based calling interface. As you may remember from previous columns, this means that the programmer invokes the desired trap macro with address register A0 pointing to a data structure in memory. It is through this data structure that parameters are passed between the calling program and the routine.
The data structure that the device manager routines use is called the ioParamBlock (from here on abbreviated as ioPB). Figure 1 shows the structure of the ioPB. The numbers in parenthesis are the byte offsets from the base address of the ioPB. There is a byte-division ruler to the right of the figure to ease the judgement of lengths.
The programmer need not concern himself with the first four fields of the ioPB, the device manager routines use them internally.
The fifth field, ioCompletion, is used for asyncronous I/O operations. When the device manager has finished an asyncronous operation, it will jump to the routine pointed to by ioCompletion, if it is nonzero. For example, you could request that the device manager send a page of data asynchronously through the serial port. While the device manager was doing this, you could set up the next page of data to be sent. When finished, the device manager would jump to your completion routine, which in turn would send the next page of data.
Upon returning from a device manager call, the ioResult field will contain a code describing what error, if any, occurred. IoNamePtr is only used when first opening a device. It points to the name of the device to be opened. All open devices are assigned reference numbers by the device manager. These reference numbers must be specified by the calling program and are stored in the ioRefNum field.
The device driver allows Control/Status calls to certain devices. These calls allow the user to send commands to devices (such as configuration commands) or to get status information from devices. A control/status call requires that the programmer send a control code to the device; this code is contained in the CSCode field of the ioPB. Certain control calls also need parameters of their own. These parameters are passed through the CSParam field.
When a read or write call is made, the address of the data buffer is passed in ioBuffer. The number of bytes that the programmer wants to read or write is contained in the ioReqCount; the number of bytes successfully read or written is returned in ioActCount. IoPosMode and ioPosOffset are used only with block devices. They allow the data to be accessed non-sequentially.
To use the sound driver from assembly language, the programmer must set up the appropriate fields of the ioPB, load A0 with a pointer to it, and then call the trap macro. Asyncronous execution is flagged by appending ",ASYNC" to the end of the trap name. For example to write a data buffer to a device, you would set up it's reference # etc. in the ioPB, store a pointer to the buffer in the ioBuffer field, load A0, and then execute _Write,ASYNC.
The sound driver is broken into three pieces: the square-wave synthesizer, the four-tone synthesizer, and the free-form synthesizer. Each synthesizer generates a different type of sound and requires a specific amount of processor time. Each type of sound is generated by making a write call to the device manager requesting that the proper data is sent to the sound driver. The square-wave and four-tone synthesizers will be described here.
Nothing Fancy
The simplest subset of the sound driver is the square-wave synthesizer. When running asynchronously, the square-wave synthesizer uses approximately 2% of the processor's time- a modest degree of overhead. However, the type of sounds that this synthesizer is capable of creating are limited to simple tones or beeps.
To get the square-wave synthesizer going, the programmer simply writes a SWSythRec to the sound driver. The first word of the SWSythRec is -1. This tells the sound driver that the data in the record should be routed to the square-wave synthesizer. Following this is a list of tones to be produced. The end of the tone list is dentoed by a zero.
Each tone is 3 words long. The first word is the count value, where frequency = 783360 / count. Complete lists of count values for the C major scale and the equal tempered scale are contained in Inside Macintosh. The second word is the amplitude, or volume, of the tone. This value ranges from 0-255 inclusive, with 255 being maximum volume. The last word is the duration of the tone, in 1/60ths of a second.
An example set of data will make the above explanation clearer. The sample will be 3 tones with frequencies of 1000, 2000, and 4000 Hertz. The amplitude of the tones will be half volume. The lengths of the tones will be .5, 1, and 1.5 seconds.
The count values are calculated by dividing 783360 by the frequency. 783360/1000 = 783; 783360/2000 = 392; and 783360/4000 = 196. The amplitude will be 127 ( half of 255 ). Given that 1 second = 60 duration units, calculating the duration values is done by: (.5 )* 60 = 30; 1 * 60 = 60; 1.5 * 60 = 90.
The data looks like this:
A Barbershop Quartet in Your Mac
The four-tone synthesizer is the most taxing in terms of processor use- approximately 50%. However, it allows up to 4 tones to be produced simultaneously, allowing multi-voice music and chords to be produced. Its record, FTSynthRec, has the most complex structure of the three synthesizers.
The first word of data in the FTSynthRec is always a 1. Following this is the duration of the sound, again in 1/60ths of a second. Next are 4 pairs of values for each of the four tones to be produced.
The first long word of each pair is the rate value, a fixed-point number which is analogous to the SWSynthRec's count value. (A discussion of fixed-point numbers can be found on page 11 of the Memory Manager Introduction in Inside Macintosh ) In this case, the frequency is derived by the formula: frequency (Hz) = 1000000 / (11502.08 / rate). The last element of the pair is a long integer phase value. The phase can range in value from 0-255, and tells the square-wave synthesizer how many bytes in the tone's waveshape definition to skip before starting the tone (If this confuses you, don't worry about it. Great sounds can be created without any regard for phase).
After the four pairs of values come four Waveshape pointers, which point to waveshape definitions in memory. Each waveshape definition consists of 255 bytes that describe the shape of one pulse, or click, sent to the speaker. Consider a tone of any frequency. It is comprised of a series of pulses, or "clicks", that create a tone when generated at a certain rate. The pulse itself is a general unit used by all tones, and therefore has no effect on the frequency of the resulting tone if it is designed correctly. Figure 3 shows the waveform description of a square pulse. Although it is the simplest possible waveform to generate, it is not as "natural" sounding as a sine pulse. In most cases, a square pulse or a sine pulse will suffice; however, by changing the wave definition, various musical instruments can be simulated.
A C major chord will suit well for a set of sample data. This chord is comprised of the notes C, E, and G. The table in Inside Macintosh gives us fixed-point rate values of 3.03654, 3.79568, and 4.55481 for these notes. The equivalent hex values for these numbers are $030959, $03CBB0, and $048E06 respectively. A duration value of 60 will generate the sound for 1 second. Using the default phase value of 0, the only remaining task is the initialization of the waveshape definitions and pointers.
The sample waveshape definition is created by filling a 255 byte block of memory with data - the first half (bytes 0-127) with the value 255 and the last half (bytes 128-255) with the value 0. When this is done, the address of the block of memory is stored in the waveshape pointers of our three tones.
Here is a sample FTSynthRec with the data for a C major chord:
There are two other differences that make the four-tone synthesizer different from the square-wave synthesizer. After the FTSynthRec is set up in memory, it is not directly written to the sound driver. Rather, a six byte block is written. The first two bytes comprise an integer word of value 1. The last four bytes of this block contain a pointer to the actual FTSynthRec in memory. The second difference is that, by nature of this calling scheme, only one FTSynthRec can be written at a time. Therefore, it is necessary to loop if there is more than one sound to generate.
The program gives examples of using both the square-wave synthesizer and the four-tone synthesizer. One useful item is the macro named Center, which when given a string, the center X coordinate of the grafport, and the Y coordinate at which the text should appear, will draw the text centered at the given Y coordinate. This saves a great deal of "hit-and-miss" experimentation if, like me, you don't sit down and calculate the correct centers by hand.
With this information and a bit of patience, the average reader should be able to implement sound in his next assembly application to give it that special touch of style.
; ; Sound Example #1 ; ; ; © 1985 By Chris Yerga for MacTutor INCLUDE MacTraps.D ; Declare external labels XDEF START ; Define Macros ; Note that this clever macro will center a ; string for you about the MidPT, on line Y ; for use with the _DrawString trap call. MACRO Center String,MidPT,Y = CLR.W -(SP) ;Save room for INTEGER ;width of string PEA '{String}' _StringWidth CLR.L D3;Clear the high word of ;D3 so the DIVU works MOVE.W (SP)+,D3 ;Get the width (in pixels) in D3 DIVU #2,D3 ;Divide by 2 MOVE.L #{MidPT},D4 SUB.W D3,D4 ;Subtract (Width/2) ;from center point MOVE.W D4,-(SP) ;Push the X cordinat MOVE.W #{Y},-(SP);Push the Y cordinat _MoveTo;Position the pen PEA '{String}' _DrawString |;End of Macro symbol ;*** Local Constants *** AllEvents EQU $0000FFFF MaxEvents EQU 12 DWindLenEQU $AA ; see DS storage area ; Start of Main Program BadPtr: _Debugger ;Should never get ;here. Is called when there is ;a problem with the memory ;manager. START: MOVEM.L D0-D7/A0-A6,-(SP) LEA SAVEREGS,A0 MOVE.L A6,(A0) MOVE.L A7,4(A0) ;Initialize the ROM routines PEA-4(A5) ;QD Global ptr _InitGraf ;Init QD global _InitFonts;Init font manager _InitWindows;Init Window Mgr _InitMenus;Guess what...yes! CLR.L -(SP) _InitDialogs _TEInit ;Init ROM Text edit MOVE.L #AllEvents,D0 _FlushEvents _InitCursor ;Get the standard arrow ;Allocate the memory that we need MOVE.L #50,D0 ;Get a 50 Byte ;nonrelocatable block _NewPtr CMP#0,D0;Did we get the block?? BNE BadPtr;Nope...jump to MacsBug LEAParamBlock,A1 ;Save the Ptr MOVE.L A0,(A1) MOVE.L #255,D0 ;Get a 255 byte block for waveform def _NewPtr,CLEAR ;and fill it with ;zeros while you're at it CMP#0,D0;Did we get the mem? BNEBadPtr ;Nope...Debugger time LEAWave,A1;Save the Ptr MOVE.L A0,(A1) ; Set up the ioParamBlock fields MOVE.L ParamBlock,A0 ;Get the Ptr to ioParamBlock CLR.L 12(A0);No completion routine MOVE.W #-4,24(A0) ;The Sound Driver reference # CLR.W 44(A0) ;Standard positioning CLR.L 46(A0);No offset for the write ;Fill the Wave buffer with a simple ;Square Wave definition MOVE.L Wave,A0 ;Get the base ;address of the block MOVE.L #127,D0 ;Set up the wave definition MakeWave: MOVE.B #255,(A0)+ ;Set bytes 0-127 of the wave def ;and increment A0 DBRA D0,MakeWave ;loop until 127... ;Set up the Dialog Box CLR.L -(SP) ;Save room for DIalogPtr MOVE.W #128,-(SP) ;The ResID of the dialog PEADStorage(A5) ;Where to put the DialogRec MOVE.L #-1,-(SP);Put it in front, _GetNewDialog LEADHandle,A2 ;Save handle, but keep it MOVE.L (SP),(A2);on the stack _DrawDialog ;Draw the dialog.. LEADHandle,A2 MOVE.L (A2),-(SP) ;Set the Dialog to ;the current GrafPort _SetPort MOVE.W #7,-(SP) ;Select Athens _TextFont MOVE.W #18,-(SP);in 18Pt size _TextSize Center Sound Example #1,206,35 MOVE.W #1,-(SP) ;Select Chicago _TextFont MOVE.W #12,-(SP);in 12Pt size _TextSize Center ©1985 Chris Yerga for MacTutor,206,52 ; Main Event Loop MAIN: CLR.L -(SP) ;NIL for FilterProc PEAItemHit;VAR ItemHit _ModalDialog;handle the dialog for us! MOVE ItemHit,D0 ;Get the result CMP#1,D0;Is it Square Wave? BEQSquare ;Yes.... CMP#2,D0;Is it 4Tone? BEQFourTone ;You got it.... CMP#3,D0;Is it Bye Bye?? BEQ Adios ;Uh huh... BRAMain ;Keep going till we get ;a valid event... Square: MOVE.L ParamBlock,A0 ;Get the Ptr to ioParamBlock MOVE.L #SqEnd-SqBegin,36(A0) ;The length of the data, so we ;can tell the device manager ;how much to write LEASqBegin,A1 ;Ptr to our data buffer MOVE.L A1,32(A0) _Write ;this is the actual Write call. ;Be sure to have A0 pointing to ;your ioParamBlock! BRAMain ;We're done for now.. SqBegin: DC.W -1;This tells the sound ;driver that the data is ;for the square-wave ;driver. ;Play the C major diatonic scale... DC.W 5937,128,20 ;C DC.W 5278,128,20 ;D DC.W 4750,128,20 ;E DC.W 4453,128,20 ;F DC.W 3958,128,20 ;G DC.W 3562,128,20 ;A DC.W 3167,128,20 ;B DC.W 2969,128,20 ;C DC.W 3167,128,20 ;B DC.W 3562,128,20 ;A DC.W 3958,128,20 ;G DC.W 4453,128,20 ;F DC.W 4750,128,20 ;E DC.W 5278,128,20 ;D DC.W 5937,128,20 ;C DC.W 0,0,0 SqEnd: DC.W0 ;End of the data FourTone: MOVE.L ParamBlock,A0 ;Get the Ptr to ;our ioParamBlock MOVE.L #6,36(A0) ;ioCount (how many ;bytes to write) ;in this case always ;6 bytes MOVE.L Wave,A2 ;Get the Ptr to the ;waveshape def LEAFTSynthRec,A1 ;Get the Ptr to the sound table MOVE.L #3,D0 ;Loop 4 times SetWave: MOVE.W #30,(A1) ;Set the tone length ;to .5 seconds ADDA #34,A1;Adjust A1 to point ;to WavePtr fields MOVE.L A2,(A1)+ ;Set 1st WavePtr MOVE.L A2,(A1)+ ;Set 2nd WavePtr MOVE.L A2,(A1)+ ;Set 3rd WavePtr MOVE.L A2,(A1)+ ;Set 4th WavePtr DBRA D0,SetWave LEAFTBegin,A3 ;Set the BuffPtr in ;the ParamBlock MOVE.L A3,32(A0);to point to our data ;buffer LEAFTSynthRec,A2 ;Set the FTSRecPtr ;in the Data MOVE.L #3,D3 ;Loop 4 times FTLoop: MOVE.L A2,2(A3) ;Set the ;pointer to point ;to the next sound MOVE.L ParamBlock,A0 ;Get Ptr to ;ioParamBlock in A0 _Write ;Write it! ADDA #50,A2;Point to the next ;tone record DBRA D3,FTLoop ;and loop... BRAMain ;Thank you... ;The four-tone record is unique in that it is not actually written ;to the sound driver. Rather, only a ptr to the actual tones is ;written. This means that only one set of 4 tones can be written ;at a time. FTBegin: DC.W 1 ;Four tone = 1 DC.L 0 ;Holder for Ptr to the actual ;tones FTSynthRec: DC.W 60;Do sound for 1 sec DC.L $3CBB0,0 DC.L $5B188,0 DC.L $4DBC3,0 DC.L $00000,0 DC.L 0,0,0,0 ;Place holders for ;WavePtr's DC.W 60;Do sound for 1 sec DC.L $36A85,0 DC.L $50F95,0 DC.L $6D50A,0 DC.L $00000,0 DC.L 0,0,0,0 ;Place holders for ;WavePtr's DC.W 75;.5 SEC DC.L $287CA,0 DC.L $3CBB0,0 DC.L $30959,0 DC.L $00000,0 DC.L 0,0,0,0 DC.W 30 DC.L $1E5D8,0 DC.L $287CA,0 DC.L $30959,0 DC.L $00000,0 DC.L 0,0,0,0 ADIOS: LEA SaveRegs,A0 MOVE.L (A0),A6 MOVE.L 4(A0),A7 MOVEM.L(SP)+,D0-D7/A0-A6 RTS ; Program Variables SaveRegs: DCB.L 2,0 ;For saving the SP etc.. DHandle:DC.L0 ;For the dialog Handle ItemHit:DC.W0 ;For _ModalDialog ParamBlock: DC.L 0 ;For the ioPB Wave: DC.L0 ;For the WaveShape definition ; Dialog Record DStorage: DS.W DWindLen ; END OF SOURCE CODE ; Resource File ; for Sound Exercize #1 RESOURCE 'BDOG' 0 'IDENTIFICATION' STRING_FORMAT 2 DC.B 'FREEWAVE VER -0.1 OF 3/19/85' STRING_FORMAT 0 .ALIGN 2 RESOURCE 'BNDL' 128 'BUNDLE' DC.L 'BDOG';Name of Signature DC.W 0,1 ;Data DC.L 'FREF';FREF Mappings DC.W 0 ;1 Mapping ( 1-1 = 0 ) DC.W 0,128 DC.L 'ICN#';ICN# Mappings DC.W 0 ;2 Mappings ( 1-1 = 0 ) DC.W 0,128 .ALIGN 2 RESOURCE 'FREF' 128 'FREF#1' DC.B 'APPL',0,0,0 .ALIGN 2 RESOURCE 'ICN#' 128 'Application Icon' INCLUDE WaveIcon.ASM .ALIGN 2 RESOURCE 'ICON' 128 'DlogIcon' INCLUDE SoundIcon.ASM ; Dialog Box .ALIGN 2 RESOURCE 'DLOG' 128 'AboutBox' STRING_FORMAT 2 DC.W 95,50,270,462;BoundsRect DC.W 1 ;ProcID DC.B 1,1 ;TRUE for visible DC.B 0,0 ;FALSE for GoAway DC.L 0 ;Refcon (Chuckle!) DC.W 129 ;DITL ResID DC.B 'HI';Title (unused) ; Dialog Box Items .ALIGN 2 RESOURCE 'DITL' 129 'AboutBox items' DC.W 3 ;4 Items in the list ;(4 - 1) = 3 ; Item #1 DC.L 0 ;Handle holder DC.W 114,41,136,201 ;BoundsRect DC.B 4 ;Button DC.B 'Square Wave ' ;Text Preceded by length byte ; Item #2 DC.L 0 ;Handle holder DC.W 114,210,136,361;BoundsRect DC.B4 ;Button DC.B 'Four Tone ' ;Text Preceded by length byte ; Item #3 DC.L 0 ;Handle holder DC.W 144,41,166,361 ;BoundsRect DC.B 4 ;Button DC.B 'Ive had enough fun for now' ;Text Preceded by length byte ; Item #4 DC.L 0 ;Handle Holder DC.W 60,194,92,226 ;BoundsRect DC.B 128+32;Disabled Icon DC.B 2 DC.W 128 ;ICON ResID STRING_FORMAT 0 ;EOF Linker file !START /Output Sound ] SoundOff /Resources SOResource /TYPE 'APPL' 'BDOG' $

- SPREAD THE WORD:
- Slashdot
- Digg
- Del.icio.us
- Newsvine