Changes

Jump to navigation Jump to search

AGI/Specifications/Sound

1,463 bytes removed, 18:16, 10 June 2011
<span id="AGI112"></span>
==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 In this format used in version 1the 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.12 The data consists simply of register values that the AGI interpreter was quite different from player dumps to the format described above for AGIv2 and AGIv3sound chip. Because of this they can be in arbitrary order. It still uses An exception is the PCjr format for frequency updates that need two bytes and the note data but it does not store chip expects them to come in the duration as correct order. Often a separate fieldrow contains only one 0 which means the chip state is not updated on this row. The best way  By convention the data usually appears to be in opposite order compared to describe it is by an AGIv2 SOUND resources. For example:
<pre>
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 ...
</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
</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
D0 C0 0E --> 03 00 0E C0 D0
FF E4 00 --> 33 00 00 E4 FF
</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)==
19

edits

Navigation menu