Difference between revisions of "CSBwin/User Questions"
Paul Stevens (talk | contribs) |
m |
||
| (13 intermediate revisions by 2 users not shown) | |||
| Line 10: | Line 10: | ||
==== What's the ''State of Machine'' push buttons? ==== | ==== What's the ''State of Machine'' push buttons? ==== | ||
| + | |||
| + | ANSWER: An instance of a DSA is like an instance of a switch. It is placed in one of the dungeon cells and acts like its definition. For example, you might provide a definition of a DSA that displays some text. You would plant 'instances' of that DSA at various places in the dungeon and each 'instance' would display different text, depending on its location or whatever. But there is only one 'definition'. This is analogous to a 'Coin Slot'. The definition of a coin slot provides a graphic and each instance of a coin slot opens a different door or closes a different pit or whatever. | ||
| + | |||
| + | OK. A DSA is a state machine. The state must be remembered. Where shall we put the number that represents the DSAs state? The 'State of Machine' dialog provides you with a choice. You can store the machine's state 'Local' in each 'instance' of the DSA so that each instance can have a different state. The disadvantage of this is that the number must be 31 or less. I doubt anyone has found that to be a limitation because the state can be any number during execution of the DSA; it is only between executions that the limit applies. A second option is to store the state in the 'Definition' of the DSA. The downside (or, perhaps in some cases, the upside) of this is that all 'instances' of the DSA share the same state. This might be used to your advantage if you wanted a DSA that could receive more than 12 different messages. The number can be any size. The third option is to store the state in Parameter B of the instance of the DSA. This allows numbers as large as 1023 and is the same as 'Local' except that parameter B can no longer be used as a parameter. No problem. Use parameter C instead! | ||
== Memory Related == | == Memory Related == | ||
| Line 15: | Line 19: | ||
=== Parameters === | === Parameters === | ||
==== What are parameters: C,D,etc? ==== | ==== What are parameters: C,D,etc? ==== | ||
| + | |||
| + | ANSWER: In a given cell of the dungeon you may place several DSAs. They are piled up just as several daggers might be piled up in a corner somewhere. Each DSA has two parameters named 'A' and 'B'. But each DSA can also reference the parameters of all the DSAs that are BELOW it in the pile of DSAs (or list of DSAs). The DSA directly below is referenced by specifying paramteter C and D. The DSA below that is referenced by parameter E nd F. Notice that you cannot reference the parameters of DSAs that are ABOVE, only the ones BELOW. Normally, those DSAs that are referenced as C, D, etc. are 'Do Nothing' and have no code. They are placed in the dungeon only to provide additional parameters for a DSA above them in the pile. But that is not a restriction. When a message is sent to a cell in the dungeon, each DSA in that cell will be activated in turn and any code will be executed. Assume that two DSAs are in the pile. The top DSA can reference parameters A, B, C, and D. The bottom DSA can only reference its own two parameters as A and B. | ||
=== Stack === | === Stack === | ||
| Line 29: | Line 35: | ||
* Are the valid GV indices: 0,1, 16,17, 32,33 48,49 ? | * Are the valid GV indices: 0,1, 16,17, 32,33 48,49 ? | ||
* What happens if I read/write to an invalid GV? | * What happens if I read/write to an invalid GV? | ||
| + | |||
| + | ANSWER: It is not that complicated. There are up to 64 global variables numbered 0 through 63. The four banks of 16 are simply four 'windows' into the 64 values. You must write them in groups of 16. Any group with fewer than 16 will be ignored and no more may follow. In your example, there would be no global variables because the first group is incomplete and that will be ignored along with all the following groups. | ||
| + | |||
| + | Attempting to read/write a non-existent variable ill cause an error message and, in the case of read, a result of 0xcdcdcdcd. | ||
| + | |||
| + | By the way, the number 64 is EASILY increased if it would be useful. It is a totally arbitrary limit. | ||
=== Variables === | === Variables === | ||
| Line 35: | Line 47: | ||
What memory does the &Vn@ and &Vn! instructions access? | What memory does the &Vn@ and &Vn! instructions access? | ||
| + | ANSWER: Temporary memory. Like the stack itself, these (local) variables survive only during a single execution of a DSA. References to these variable is checked. You cannot &Vn@ a variable before you &Vn! the same variable. | ||
== Filter Related == | == Filter Related == | ||
| Line 42: | Line 55: | ||
=== L$ === | === L$ === | ||
This is stated to push the location of the current ''master cell''. What is it? | This is stated to push the location of the current ''master cell''. What is it? | ||
| + | |||
| + | ANSWER: The Master/Slave concept has never been fully implemented and there is no need to implement it. So the location of the 'Master cell' is simply the location within the dungeon where you put an instance of the DSA. If it were a 'Pit' then it would be the location of the pit. But it is a DSA so it is the location of the DSA. If the word 'Master' had not been included in the description then there would probably be no confusion. | ||
=== Case - syntax === | === Case - syntax === | ||
I'm not understanding the syntax, could someone please provide some examples? | I'm not understanding the syntax, could someone please provide some examples? | ||
| + | |||
| + | ANSWER: ??{<case><case><case>........} (n ... ) | ||
| + | |||
| + | The "(n ... )" part of the syntax definition says that the '??' statement needs a single number ('n') on the top of the stack and replaces it with nothing. | ||
| + | |||
| + | A 'case' statement is normally used when a variable can have many values and you want something different to happen for each of those values. Let us make a particular example. Let us say that the parameter B can have three different values: 4, 12, and 7. If the value is 4 we want to jump to 6S2; if the value is 7 we want to jump to 3T1; if the value is 12 we want to jump to 3T2. If parameter B is any other value then we want to place the number 105 on the stack. Here is the code (notice that the outermost delimiters are braces, not parentheses): | ||
| + | |||
| + | LB ??{(4,6S2)(7,3T1)(12,3T2)} L105 | ||
=== IfElse - syntax === | === IfElse - syntax === | ||
I'm not understanding the syntax, could someone please provide some examples? | I'm not understanding the syntax, could someone please provide some examples? | ||
| + | |||
| + | ANSWER: IfElse ::= ?[<J|G>[<state>][<column>]][:<J|G>[<state>][<column>]] | ||
| + | |||
| + | ?X means do X if TOS is non-zero. | ||
| + | |||
| + | ?X:Y means do X if TOS is non-zero else do Y. | ||
| + | |||
| + | ?:Y means do Y if TOS is zero. | ||
| + | |||
| + | TOS is the value on the top of the stack. | ||
| + | |||
| + | X and Y can only be 'J'umps or 'G'otos. | ||
| + | |||
| + | |||
| + | Example: ?JC0:GT1 | ||
| + | |||
| + | This says that if the top of the stack is non-zero then 'J'ump to line CO. If the top of the stack is zero then 'G'osub to line T1. | ||
| + | |||
| + | Example: ?:J3T2 | ||
| + | |||
| + | This means 'J'ump to line T2 on state 3 if top of stack is zero. | ||
=== Flow Control and ''nextState'' === | === Flow Control and ''nextState'' === | ||
The ''nextState'' modifier of an instruction is ignore for all instructions other than the first in the sequence. How does this work with the various Flow-Control instructions, say '''&J*'''. Does the DSA keep the same state it was in (assuming no '''&SETNEWSTATE''' instructions in the called routine)? | The ''nextState'' modifier of an instruction is ignore for all instructions other than the first in the sequence. How does this work with the various Flow-Control instructions, say '''&J*'''. Does the DSA keep the same state it was in (assuming no '''&SETNEWSTATE''' instructions in the called routine)? | ||
| + | |||
| + | ANSWER: Yes. 'Jumps' and 'GoSubs' do not alter the value of 'nextState'. Only the very first instruction executed when the DSA is activated by a message and &SETNEWSTATE can change 'nextState'. | ||
| + | |||
| + | [[Category:CSBwin|User Questions]] | ||
Latest revision as of 16:27, 6 January 2009
General
DSA Editor Box
What's the DSA Group ID & Master vs. Slave
Both the numeric value and what's a slave?
SHORT ANSWER: Ignore these things.
LONG ANSWER: You can only send 12 different messages to a DSA. S0 S1 . . . T3. What would a person do if he wanted to force the player to press 13 switches in the proper sequence? Punt? Cry? No! The plan was that he could add 'Slave' DSA's in neighboring cells, each of which could receive 12 additional messages. In this way you could expand the number of possible messages. But I think it was never needed nor implemented. Subsequent features have made it easier to handle this problem without resorting to slave DSAs.
What's the State of Machine push buttons?
ANSWER: An instance of a DSA is like an instance of a switch. It is placed in one of the dungeon cells and acts like its definition. For example, you might provide a definition of a DSA that displays some text. You would plant 'instances' of that DSA at various places in the dungeon and each 'instance' would display different text, depending on its location or whatever. But there is only one 'definition'. This is analogous to a 'Coin Slot'. The definition of a coin slot provides a graphic and each instance of a coin slot opens a different door or closes a different pit or whatever.
OK. A DSA is a state machine. The state must be remembered. Where shall we put the number that represents the DSAs state? The 'State of Machine' dialog provides you with a choice. You can store the machine's state 'Local' in each 'instance' of the DSA so that each instance can have a different state. The disadvantage of this is that the number must be 31 or less. I doubt anyone has found that to be a limitation because the state can be any number during execution of the DSA; it is only between executions that the limit applies. A second option is to store the state in the 'Definition' of the DSA. The downside (or, perhaps in some cases, the upside) of this is that all 'instances' of the DSA share the same state. This might be used to your advantage if you wanted a DSA that could receive more than 12 different messages. The number can be any size. The third option is to store the state in Parameter B of the instance of the DSA. This allows numbers as large as 1023 and is the same as 'Local' except that parameter B can no longer be used as a parameter. No problem. Use parameter C instead!
Memory Related
Parameters
What are parameters: C,D,etc?
ANSWER: In a given cell of the dungeon you may place several DSAs. They are piled up just as several daggers might be piled up in a corner somewhere. Each DSA has two parameters named 'A' and 'B'. But each DSA can also reference the parameters of all the DSAs that are BELOW it in the pile of DSAs (or list of DSAs). The DSA directly below is referenced by specifying paramteter C and D. The DSA below that is referenced by parameter E nd F. Notice that you cannot reference the parameters of DSAs that are ABOVE, only the ones BELOW. Normally, those DSAs that are referenced as C, D, etc. are 'Do Nothing' and have no code. They are placed in the dungeon only to provide additional parameters for a DSA above them in the pile. But that is not a restriction. When a message is sent to a cell in the dungeon, each DSA in that cell will be activated in turn and any code will be executed. Assume that two DSAs are in the pile. The top DSA can reference parameters A, B, C, and D. The bottom DSA can only reference its own two parameters as A and B.
Stack
Array
Global Variables
How do they work?
Global variables seem to be set up in four-banks of (up-to) 16 variables each in Edit/Global Info, the Edit Database and Global Variables in the Database Type pull-down menu, thus allowing a maximum of 64 global variables. For each of the four banks you choose the number of variables.
Assuming that I set each of the four to having two each:
- Are the valid GV indices: 0,1, 16,17, 32,33 48,49 ?
- What happens if I read/write to an invalid GV?
ANSWER: It is not that complicated. There are up to 64 global variables numbered 0 through 63. The four banks of 16 are simply four 'windows' into the 64 values. You must write them in groups of 16. Any group with fewer than 16 will be ignored and no more may follow. In your example, there would be no global variables because the first group is incomplete and that will be ignored along with all the following groups.
Attempting to read/write a non-existent variable ill cause an error message and, in the case of read, a result of 0xcdcdcdcd.
By the way, the number 64 is EASILY increased if it would be useful. It is a totally arbitrary limit.
Variables
Q: Where are they?
What memory does the &Vn@ and &Vn! instructions access?
ANSWER: Temporary memory. Like the stack itself, these (local) variables survive only during a single execution of a DSA. References to these variable is checked. You cannot &Vn@ a variable before you &Vn! the same variable.
Filter Related
Instruction Related
L$
This is stated to push the location of the current master cell. What is it?
ANSWER: The Master/Slave concept has never been fully implemented and there is no need to implement it. So the location of the 'Master cell' is simply the location within the dungeon where you put an instance of the DSA. If it were a 'Pit' then it would be the location of the pit. But it is a DSA so it is the location of the DSA. If the word 'Master' had not been included in the description then there would probably be no confusion.
Case - syntax
I'm not understanding the syntax, could someone please provide some examples?
ANSWER: ??{<case><case><case>........} (n ... )
The "(n ... )" part of the syntax definition says that the '??' statement needs a single number ('n') on the top of the stack and replaces it with nothing.
A 'case' statement is normally used when a variable can have many values and you want something different to happen for each of those values. Let us make a particular example. Let us say that the parameter B can have three different values: 4, 12, and 7. If the value is 4 we want to jump to 6S2; if the value is 7 we want to jump to 3T1; if the value is 12 we want to jump to 3T2. If parameter B is any other value then we want to place the number 105 on the stack. Here is the code (notice that the outermost delimiters are braces, not parentheses):
LB ??{(4,6S2)(7,3T1)(12,3T2)} L105
IfElse - syntax
I'm not understanding the syntax, could someone please provide some examples?
ANSWER: IfElse ::= ?[<J|G>[<state>][<column>]][:<J|G>[<state>][<column>]]
?X means do X if TOS is non-zero.
?X:Y means do X if TOS is non-zero else do Y.
?:Y means do Y if TOS is zero.
TOS is the value on the top of the stack.
X and Y can only be 'J'umps or 'G'otos.
Example: ?JC0:GT1
This says that if the top of the stack is non-zero then 'J'ump to line CO. If the top of the stack is zero then 'G'osub to line T1.
Example: ?:J3T2
This means 'J'ump to line T2 on state 3 if top of stack is zero.
Flow Control and nextState
The nextState modifier of an instruction is ignore for all instructions other than the first in the sequence. How does this work with the various Flow-Control instructions, say &J*. Does the DSA keep the same state it was in (assuming no &SETNEWSTATE instructions in the called routine)?
ANSWER: Yes. 'Jumps' and 'GoSubs' do not alter the value of 'nextState'. Only the very first instruction executed when the DSA is activated by a message and &SETNEWSTATE can change 'nextState'.
