BAM Specification 2001/08/29 - Draft 3 - James Paige BAM (Bob's Adlib Music) is a format for synthetic music created by BriTech International/Hamster Republic Productions. The format is designed to make good use of the FM synthesis chip in your sound card (also known as the "Adlib Chip"). All BAMs are played in "Melodic" mode, as opposed to "Percussion" mode. Sadly, now that Wavetable synthesis is standard, FM is rather obsolete. ---BAM Header--- Every BAM file starts with a 4 byte header CBMF (67,66,77,70). This header can be used to tell the difference between a real BAM file, and some other type of file that just happens to have a .BAM extension. As a point of trivia, CBMF stands for Creative Bob's Music File. The "Creative" is because the header for a .VOC file also starts with a C that stands for "creative". Had we known this was the companys name (Creative Labs) and not just a flattering adjective, we would have chosen another letter. Oh well. Fans of the format can pretend it means "Cool" and detractors can pretend it stands for "Crappy" What follows after the header is a chain of sequential commands. A command is one byte, and may be followed by several more bytes of data, as required by the command. All of the voice commands leave room for 16 voices even though only 9 voices are supported in all current implementations of BAM at the time of this writing. A BAM playing program or library should gracefully ignore the last 7 voices if it isnt capable of playing them. BAM creating programs that support more than 9 voices should always use the lower numbered voices first. voices are numbered 0-8 (or 0-15 in an extended implementation) ---Byte Commands--- 0 Stop-song A code byte of zero causes the song to stop. because end-of-file also means stop, this code is never really needed, but BAM creating utilities should write one at the end of the file anyway. 1-15 Reserved 01-0F hex A code byte in the range of 1 to 15 does not have any special meaning, but should serve as a sign that the BAM file is corrupt, or has unknown features. 16-31 (16+voice) Start-note 10-1F hex A code byte in the range of 16 to 31 turns on a voice. This command is followed by one byte that tells what frequency to use. The frequency is in the range of 0 to 127 32-47 (32+voice) Stop-note 20-2F hex A code byte in the range of 32 to 47 turns off a voice. This command is not followed by any data bytes. 48-63 (48+voice) Define-instrument 30-3F hex A code byte in the range of 48 to 63 is a setvoice command. This command reads the next eleven bytes as an instrument, and assigns it to a voice. This is the BAM equivalent of the MIDI "program patch change". The eleven byte instrument definition is in SBI format (see note at the end of this file). Most BAM files start by defining all the voices that will be used, but anyone writing a BAM player shouldnt count on this. Instruments can be redefined in the middle of a song. (but you should be aware that reassinging a voice's instrument in the middle of playing a note with it can result in some rather unpredictable sounds) 64-79 Reserved 40-4F hex A code byte in the range of 64 to 79 does not have any special meaning, but should serve as a sign that the BAM file is corrupt, or has unknown features. 80-95 (80+label) Set-Label 50-5F hex A BAM file can contain up to 16 labels (numbered 0-15) that can be used for jumping and looping. A code byte in the range of 80 to 95 sets the position of a label. When the BAM player sees this command, it should remeber its position in the file. This command is not followed by any data bytes. Label zero should automatically point to the beginning of the song by default. The other labels should be left undefined by default. 96-111 (96+label) Jump 60-6F hex A code byte in the range of 96-111 represents a jump to a label. It is followed by one data byte. If the label that corresponds to the jump has not been set yet, then the jump should be ignored. There are three kinds of jumps, which depend on the data byte, finite, infinite, and chorus. A data byte in the range of 1 to 253 is a finite loop that should be repeated x times, where x is the data byte. A data byte of 254 is an infinite loop (a GOTO jump). Most BAM files will begin by marking label 0, and end with an infinite loop to label 0. A data byte of 255 is a chorus (a GOSUB jump) that causes the song to jump to the corresponding label, but return when it encounters an End-of-chorus (RETURN) command. BAM players should support loop-within-loops, but do not need to support choruses-within-choruses. 112 End-of-chorus 70 hex A code byte of 112 causes the song to jump back to wherever the last chorus jump (GOSUB) command was executed 113-127 Reserved 71-7F hex A code byte in the range of 113 to 127 does not have any special meaning, but should serve as a sign that the BAM file is corrupt, or has unknown features. 128-255 (127+time) Wait 80-FF hex A code byte in the range of 128-255 is a wait. The time is in 1/32 of a note. That means that a code byte of 159 would wait for the length of a whole note. This command is not followed by any data bytes. For a delay longer than 4 whole notes, you must use more than one delay command in a row. (End-of-file) Stop-song If the end of the file is reached, the song should stop. Normally, BAM music will use a label and an infinite jump to repeat endlessly, and in that case the end of the file will never be reached. (Note that this the actual end of the file, not the ASCII EOF character 26) ---SBI Format--- The SBI (Sound Blaster Instrument) format contains a 4 byte header, a 32 byte instrument name, 11 bytes of instrument data, and 5 reserved bytes. All we care about is the 11 bytes of data. You can pull this out of any file that contains SBI data, such as a .IBK file. If you want full documentation of SBI format, search around on the net. Its not hard to find.