BAM Format

BAM format is no longer the preferred music format. BAM is still supported, but MIDI is a better choice

Inside RPG files, .BAM songs 0-99 are lumps gamename.##, where the extension is not padded with zeroes, and songs 100+ are song###.bam.

They are potentially the most complicated files (outside of .HS Files/.HSX Lumps). They are a series of commands that describe music. Here is the official Bam specification:

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 company's 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 isn't 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.

However, some of the included examples use command 127. In order to be used with these files, you may wish to treat command 127 as a zero-length delay instead of an error.

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.

IBK Format

The IBK format (Instrument BanK (I think)) is a subset of the SBI format. It contains many 16 byte records, followed by their corresponding 8-byte-padded names.

The 16 bytes consist of 11-bytes of instrument data (corresponding to the voice definition data), followed by 5 bytes of mystery/reserved-ness.

See Also

• BAM Developer's Kit

List of Lumps in the RPG file format

ARCHINYM.LMP . ATTACK.BIN . BINSIZE.BIN . BROWSE.TXT . DEFPAL#.BIN . DEFPASS.BIN . distrib.reld . FIXBITS.BIN . general.reld . heroes.reld . heroform.reld . LOOKUP1.BIN . MENUITEM.BIN . MENUS.BIN . PALETTES.BIN . PLOTSCR.LST . SFXDATA.BIN . SLICELOOKUP.TXT . slicetree_#_#.reld . SONGDATA.BIN . UICOLORS.BIN
Map Format : E . D . L . N . P . T . Z
BAM . DOR . DOX . DT0 . DT1 . DT6 . EFS . FNT . FOR . GEN . HSP . HSZ . ITM . MAP . MAS . MN . MXS . PAL . PT0 ... PT8 . RGFX . SAY . SHO . SNG . STF . STT . TAP . TIL . TMN . VEH

List of other OHRRPGCE file formats

gameconfig.ini . ohrkey . ohrrpgce_config.ini . persist.reld . RELOAD . RELOAD common formats . RSAV . SAV