|
|
| Line 252: |
Line 252: |
| <span id="AGI112"></span> | | <span id="AGI112"></span> |
| ==AGI v1.12 sound format== | | ==AGI v1.12 sound format== |
| | The sound format used in AGI version 1.12 (and also in the pre-AGI game Winnie the Pooh in the Hundred Acre Wood) is less structured from the format described above for AGIv2 and AGIv3. |
|
| |
|
| The sound format used in version 1.12 of the AGI interpreter was quite different from the format described above for AGIv2 and AGIv3. It still uses the PCjr format for the note data but it does not store the duration as a separate field. The best way to describe it is by an example:
| | In this format the note data is separated to "rows" of fixed duration of 2. Each row contains the data for all the four generators and ends with the byte 0. The data consists simply of register values that the player dumps to the sound chip. Because of this they can be in arbitrary order. An exception is the frequency updates that need two bytes and the chip expects them to come in the correct order. Often a row contains only one 0 which means the chip state is not updated on this row. |
| | |
| | By convention the data usually appears to be in opposite order compared to AGIv2 SOUND resources. For example: |
|
| |
|
| <pre> | | <pre> |
| 90 80 16 B0 A0 15 D0 C0 0E FF E4 00 80 17 A0 16 C0 11 00 | | 90 80 16 B0 A0 15 D0 C0 0E FF E4 00 80 17 A0 16 C0 11 00 |
| 80 16 B1 A0 14 C0 12 00 80 16 B2 A0 16 C0 13 00 ... | | 80 16 B1 A0 14 C0 12 00 80 16 B2 A0 16 C0 13 00 ... |
| </pre>
| |
|
| |
| The first thing to point out is that the PCjr note data is in the opposite order to AGIv2. Secondly, all four parts are included together rather than in separate sections. Taking the above example, lets look at the first note and show the equivalent AGIv2 notation.
| |
|
| |
|
| <pre>
| |
| 90 80 16 --> 03 00 16 80 90 | | 90 80 16 --> 03 00 16 80 90 |
| </pre>
| |
|
| |
| Now, the duration isn't immediately obvious, but we will come to that in a short while. The followint three bytes give the first note for the second part, the third part, and the noise part (at least as far as this example is concerned).
| |
|
| |
| <pre>
| |
| B0 A0 15 --> 03 00 15 A0 B0 | | B0 A0 15 --> 03 00 15 A0 B0 |
| D0 C0 0E --> 03 00 0E C0 D0 | | D0 C0 0E --> 03 00 0E C0 D0 |
| FF E4 00 --> 33 00 00 E4 FF
| |
| </pre> | | </pre> |
|
| |
|
| The data that follows after these initial four starting notes is basically any changes in the note value which each 3 duration step. For example,
| | <span id="IIgsFormat"></span> |
|
| |
|
| <pre>
| |
| 80 17 --> 03 00 17 80 90
| |
| </pre>
| |
|
| |
| Note that 0x90 doesn't need to be stored because that byte has retained its value. Every 0x00 byte that is encountered is the end of one set of note changes. Each set of note changes is the equivalent of a duration of 3 in the AGIv2 format. Continuing with our example,
| |
|
| |
| <pre>
| |
| A0 16 --> 03 00 16 A0 B0
| |
| C0 11 --> 03 00 11 C0 D0
| |
| </pre>
| |
|
| |
| The example now encounters a 0x00 byte which means that the noise voice isn't changed at this point. In fact, from the AGIv2 equivalent note above, you will see that the noise note will not change until 49 (or 0x33) sets of note changes have been processed.
| |
|
| |
| <pre>
| |
| 80 16 --> 03 00 16 80 90
| |
| B1 A0 14 --> 03 00 14 A0 B1
| |
| C0 12 --> 03 00 12 C0 D0
| |
| </pre>
| |
|
| |
| How exactly the AGIv1.12 interpreter knows which voice is having its notes changed, and which bytes of the note are being changed, is not yet certain. On some occassion a sets of changes will contain only one byte which corresponds to one of the bytes which makes up one of the voices note value, but how it knows which one is a mystery to me.
| |
|
| |
| On other occassions, there could be a whole chain of 0x00 bytes which means that during that whole time, none of the voices are changing their notes value.
| |
|
| |
| <span id="IIgsFormat"></span>
| |
| ==SOUND resource format (IIgs version)== | | ==SOUND resource format (IIgs version)== |
|
| |
|