Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédenteProchaine révisionLes deux révisions suivantes | ||
agi-game:specifications-resources [2021/05/24 14:59] – frater | agi-game:specifications-resources [2021/05/24 15:29] – frater | ||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
- | ====== Logic resources | + | ===== AGI Specifications Resources : Logic resources ===== |
- | ===== Introduction | + | ==== Introduction ==== |
At the heart of Sierra' | At the heart of Sierra' | ||
Ligne 287: | Ligne 287: | ||
| FC | **or** | | FC | **or** | ||
- | At present these are the only high value codes encountered. The ''' | + | At present these are the only high value codes encountered. The //if// and //or// codes are like brackets, i.e. the code will be at the start and the end of the section of codes that it refers to. The following example will illustrate this: |
Example: KQ1, Room 2. | Example: KQ1, Room 2. | ||
Ligne 311: | Ligne 311: | ||
When the interpreter encounters a 0xFF it will then interpret the following code values as being in the condition code range until it encounters the next 0xFF which switches it back into normal AGI command | When the interpreter encounters a 0xFF it will then interpret the following code values as being in the condition code range until it encounters the next 0xFF which switches it back into normal AGI command | ||
- | mode. The two bytes immediately following the second 0xFF determine how many bytes this ''' | + | mode. The two bytes immediately following the second 0xFF determine how many bytes this //if// statement lasts for before the //if// is ended. |
us or the machine, does three things: | us or the machine, does three things: | ||
Ligne 331: | Ligne 331: | ||
</ | </ | ||
- | ==== The '' | + | ==== The **else** command and more on brackets ==== |
- | The '' | + | The **else** statement will always continue after an **if** bracket block. This next feature is important and has caused a number of hassles in the past. When an **else** statement follows an **if**, then the bracket distance given after the **if** statement //will be three bytes longer// (this is a consequence of the way the interpreter handles |
Here's an example: | Here's an example: | ||
Ligne 352: | Ligne 352: | ||
</ | </ | ||
- | Usually you would expect the bracket distance to be 0x0002 but in the above case it is clearly 0x0005 which illustrates the difference between a straight '' | ||
- | The '' | + | Usually you would expect the bracket distance to be 0x0002 but in the above case it is clearly 0x0005 which illustrates the difference between a straight **if** statement and an **if..else** structure. |
+ | |||
+ | The **else** | ||
==== Test conditions ==== | ==== Test conditions ==== | ||
Ligne 384: | Ligne 385: | ||
==== Arguments ==== | ==== Arguments ==== | ||
- | You may well be asking how the interpreter knows how many arguments each code has and what type of argument each argument is. This information is stored in <tt>agidata.ovl</ | + | You may well be asking how the interpreter knows how many arguments each code has and what type of argument each argument is. This information is stored in '' |
Inside this file there is a table which contains four bytes for each AGI command and condition code. These four bytes are interpreted as follows: | Inside this file there is a table which contains four bytes for each AGI command and condition code. These four bytes are interpreted as follows: | ||
Ligne 394: | Ligne 395: | ||
The type of arguments value is interpreted as follows: | The type of arguments value is interpreted as follows: | ||
+ | < | ||
| | ||
| | ||
+ | </ | ||
- | If the bit is set, argument is interpreted as a variable; otherwise | + | If the bit is set, argument is interpreted as a variable; otherwise the argument is interpreted as a number. It is unknown what bit 0 does since no AGI command or AGI condition code has more than seven arguments. |
- | the argument is interpreted as a number. It is unknown what bit 0 does | + | |
- | since no AGI command or AGI condition code has more than seven arguments. | + | |
Examples: | Examples: | ||
- | *0x80 Says that the commands first argument is a variable. | + | |
- | *0x60 Says that the second and third arguments are variable numbers. | + | * 0x60 Says that the second and third arguments are variable numbers. |
- | ===The messages section=== | + | ==== The messages section ==== |
- | The messages section of a logic script contains all the strings that can | + | |
- | be displayed by that logic script. These strings are encrypted by | + | The messages section of a logic script contains all the strings that can be displayed by that logic script. These strings are encrypted by xor' |
- | xor' | + | |
Example: KQ1, Room 2. | Example: KQ1, Room 2. | ||
- | < | + | <code C> |
if (said(look, alligators)) | if (said(look, alligators)) | ||
{ | { | ||
Ligne 422: | Ligne 422: | ||
In the above example, the print statement is represented as: | In the above example, the print statement is represented as: | ||
+ | < | ||
65 08 | 65 08 | ||
+ | </ | ||
- | The 0x08 is the number given to the string and corresponds to its | + | The 0x08 is the number given to the string and corresponds to its position in the list of strings at the end of the logic script. |
- | position in the list of strings at the end of the logic script. | + | |
The format of the message section is as follows: | The format of the message section is as follows: | ||
- | {| border=" | + | ^ Offset |
- | |- | + | | 0 | Number of messages |
- | ! Offset | + | | 1-2 | Pointer to the end of the messages |
- | ! Description | + | | 3-4 | Array of message pointers |
- | |- | + | | ... | Array of message pointers |
- | | | + | | ? | Start of the text data. From this point the messages are encrypted with Avis Durgan (in their unencrypted form, each message is separated by a 0x00 value) |
- | | Number of messages | + | |
- | |- | + | |
- | | 1-2 | + | |
- | | Pointer to the end of the messages | + | |
- | |- | + | |
- | | 3-4 | + | |
- | | Array of message pointers | + | |
- | |- | + | |
- | | ... | + | |
- | | Array of message pointers | + | |
- | |- | + | |
- | | ? | + | |
- | | Start of the text data. From this point the messages are encrypted with Avis Durgan (in their unencrypted form, each message is separated by a 0x00 value) | + | |
- | |} | + | |
- | ===Implementation=== | + | ==== Implementation |
- | The implementation for each AGI statement is found in the <tt>agi</tt>/ | + | The implementation for each AGI statement is found in the //agi/// file. This is the AGI interpreter itself. The data in the '' |
- | file. This is the AGI interpreter itself. The data in the | + | |
- | <tt>agidata.ovl</ | + | |
- | implementation for an AGI statement. Below are a couple of examples: | + | |
Example: MH2, equaln. | Example: MH2, equaln. | ||
- | < | + | < |
; | ; | ||
0D71 AC LODSB ;get variable number | 0D71 AC LODSB ;get variable number | ||
Ligne 472: | Ligne 456: | ||
Example: MH2, equalv. | Example: MH2, equalv. | ||
- | < | + | < |
; | ; | ||
0D82 AC LODSB ;get first var number | 0D82 AC LODSB ;get first var number | ||
Ligne 487: | Ligne 471: | ||
</ | </ | ||
- | These two examples show the difference between how numbers and | + | These two examples show the difference between how numbers and variables are dealt with. In the case of a variable, the variables number is used as an index into the table of variable values to get the value which is being tested. It appears that the variable table is at offset 0x0009 in the data segment. |
- | variables are dealt with. In the case of a variable, the variables | + | |
- | number is used as an index into the table of variable values to get | + | |
- | the value which is being tested. It appears that the variable table is | + | |
- | at offset 0x0009 in the data segment. | + | |
- | ===How the interpreter handles the code=== | + | ==== How the interpreter handles the code ==== |
- | The following 8086 assembly language code is the actual code from | + | The following 8086 assembly language code is the actual code from the MS-DOS version of Manhunter: San Francisco. There are some calls to routines which aren't displayed. Take my word for it that they do what the comment says. For those of you who can't follow whats going on, I'll explain the interpretation in steps after the code block. |
- | the MS-DOS version of Manhunter: San Francisco. There are some calls | + | |
- | to routines which aren't displayed. Take my word for it that they do | + | |
- | what the comment says. For those of you who can't follow whats going | + | |
- | on, I'll explain the interpretation in steps after the code block. | + | |
- | < | + | < |
;Decoding a LOGIC file. | ;Decoding a LOGIC file. | ||
1E6C:2EF2 56 PUSH SI | 1E6C:2EF2 56 PUSH SI | ||
Ligne 605: | Ligne 581: | ||
1E6C:2FA4 EBDE JMP 2F84 | 1E6C:2FA4 EBDE JMP 2F84 | ||
1E6C:2FA6 AD LODSW | 1E6C:2FA6 AD LODSW | ||
- | 1E6C:2FA7 03F0 ADD | + | 1E6C:2FA7 03F0 ADD |
- | s) | + | |
1E6C:2FA9 E954FF | 1E6C:2FA9 E954FF | ||
</ | </ | ||
- | '' | + | //Situation 1.// |
- | execution mode. In this routine, if the code is below 0xFC, then it is | + | Every logic script starts in normal AGI command execution mode. In this routine, if the code is below 0xFC, then it is presumed to be an AGI command. It will then call the main command execution routine which will jump to the relevant routine for the specific command using the jump table stored in '' |
- | presumed to be an AGI command. It will then call the main command | + | The command is performed and it returns to the main execution routine where it loops back to the top and deals with the next code in the logic file. |
- | execution routine which will jump to the relevant routine for the | + | |
- | specific command using the jump table stored in <tt>agidata.ovl</tt>. | + | |
- | The command is performed and it returns to the main execution routine | + | |
- | where it loops back to the top and deals with the next code in the | + | |
- | logic file. | + | |
- | '' | + | //Situation 2.// |
- | If the code is an 0xFF code, then if jumps to the ''' | + | If the code is an 0xFF code, then if jumps to the **if** statement handler. In this routine is basically assesses whether the whole test condition evaluates to true or to false. It does this by treating each test separately and calling the relevant test command routines using the jump table in the '' |
- | statement handler. In this routine is basically assesses whether the | + | |
- | whole test condition evaluates to true or to false. It does this by | + | |
- | treating each test separately and calling the relevant test command | + | |
- | routines using the jump table in the <tt>agidata.ovl</ | + | |
- | Each test command routine will return a value in <tt>AL</tt> | + | |
- | says whether it is true or not. Depending on the NOTs and ORs, the | + | |
- | whole expression is evaluated. If at any stage during the evaluation | + | |
- | the routine decides that the expression will be false, it exits to | + | |
- | another routine which skips the rest of the ''' | + | |
- | and then adds the two byte word following the closing 0xFF code to | + | |
- | the execution pointer. This usually has the affect of jumping over | + | |
- | the ''' | + | |
- | to the ending 0xFF then it knows the expression is true simply because | + | |
- | it hasn't exited out of the routine yet. At this stage it jumps over | + | |
- | the two bytes following the closing 0xFF and then goes back to | + | |
- | executing straight AGI commands. | + | |
- | '' | + | //Situation 3.// |
- | the code 0xFE is encountered, | + | If in the normal execution of AGI commands, the code 0xFE is encountered, |
- | two bytes which follow form a 16-bit twos complement value which is | + | If you're confused by this, the following example will probably explain things. |
- | added to execution pointer. This is all it does. Previously we said | + | |
- | that the 0xFE code stood for the ''' | + | |
- | in actual fact correct for over 90% of the time, but the small number | + | |
- | of other occurrences are best described as ''' | + | |
- | If you're confused by this, the following example will probably explain | + | |
- | things. | + | |
Example: | Example: | ||
- | < | + | <code C> |
if (said( open, door)) { | if (said( open, door)) { | ||
// first block of AGI statements | // first block of AGI statements | ||
Ligne 659: | Ligne 607: | ||
</ | </ | ||
- | The above example is how the original coder would have written the AGI | + | The above example is how the original coder would have written the AGI code. If we now look at the following example, it is not hard to see that it would achieve the same thing. |
- | code. If we now look at the following example, it is not hard to see | + | |
- | that it would achieve the same thing. | + | |
- | < | + | <code C> |
if (!said( open, door)) goto label1; | if (!said( open, door)) goto label1; | ||
// first block of AGI statements | // first block of AGI statements | ||
Ligne 674: | Ligne 620: | ||
</ | </ | ||
- | This is exactly how all ''' | + | This is exactly how all **if**s and **else**s are implemented in the logic code. The **if** statement is a conditional branch where the branch is taken if the condition is not met, while the **else** statement is a nonconditional jump. If a 0xFE code appears in the middle of some AGI code and wasn't actually originally coded as an **else**, then it was most likely a **goto** statement. |
- | implemented in the logic code. The ''' | + | |
- | conditional branch where the branch is taken if the condition is | + | ==== The **said** test command ==== |
- | not met, while the ''' | + | |
- | jump. If a 0xFE code appears in the middle of some AGI code and | + | |
- | wasn't actually originally coded as an ''' | + | |
- | most likely a ''' | + | |
- | ===The < | ||
The above assembly language code does raise a very important point. | The above assembly language code does raise a very important point. | ||
- | The ''' | + | The **said** command can have a variable number of arguments. Its code is 0x0E, and the byte following this byte gives the number of two byte words that follow as parameters. |
- | code is 0x0E, and the byte following this byte gives the number of | + | |
- | two byte words that follow as parameters. | + | |
Examples: | Examples: | ||
- | < | + | <code C> |
if (said(marble)) | if (said(marble)) | ||
if (said( open, door)) | if (said( open, door)) | ||
</ | </ | ||
- | In the above examples, the values 0x011E, 0x0237, and 0x0073 are just | + | In the above examples, the values 0x011E, 0x0237, and 0x0073 are just random word numbers that could stand for the words given. |
- | random word numbers that could stand for the words given. | + | |
- | ===Inner loops=== | + | ==== Inner loops ==== |
- | At first I almost totally discarded the existence of loops in the AGI | + | At first I almost totally discarded the existence of loops in the AGI code because it seemed to me that execution of the logic script continually looped. Loop code like " |
- | code because it seemed to me that execution of the logic script | + | |
- | continually looped. Loop code like " | + | |
- | statements wouldn' | + | |
- | increment with each pass and an ''' | + | |
- | value of the variable and take action if it was withing the desired range. | + | |
Example: | Example: | ||
- | < | + | <code C> |
if (greatern(30, | if (greatern(30, | ||
print(" | print(" | ||
Ligne 715: | Ligne 648: | ||
</ | </ | ||
- | I have found evidence of this sort of thing taking place which means | + | I have found evidence of this sort of thing taking place which means that they must loop over continuously. I don't know whether this is something that the interpreter does itself or whether it is part of |
- | that they must loop over continuously. I don't know whether this is | + | the AGI code, e.g. at the end of one logic script it calls another which then calls the first one again. With the existence of the conditional branching and unconditional branching nature of the **if** and |
- | something that the interpreter does itself or whether it is part of | + | **else** statement, it is easy to see that some of the structures such as " |
- | the AGI code, e.g. at the end of one logic script it calls another which | + | |
- | then calls the first one again. With the existence of the conditional | + | |
- | branching and unconditional branching nature of the ''' | + | |
- | ''' | + | |
- | structures such as " | + | |
Example: | Example: | ||
- | < | + | <code C> |
FF FD 0D FF 03 00 FE F7 FF | FF FD 0D FF 03 00 FE F7 FF | ||
Ligne 733: | Ligne 661: | ||
</ | </ | ||
- | The above translation is a simple one which is taken from SQ2. The | + | The above translation is a simple one which is taken from SQ2. The value 0xFFF7 is the twos complement notation for -9 which is the exact branching value to take the execution back to the start of the **if** |
- | value 0xFFF7 is the twos complement notation for -9 which is the exact | + | statement. If the above example had AGI code between the 0x00 and the 0xFE, then there would be code within the brackets of the " |
- | branching value to take the execution back to the start of the ''' | + | statements or used **goto** statements to achieve the same result. |
- | statement. If the above example had AGI code between the 0x00 and the | + | |
- | 0xFE, then there would be code within the brackets of the " | + | |
- | structure. I don't know whether the original AGI coders used these | + | |
- | statements or used ''' | + | |