ASCII Output Option (a) | Multiple Response Option (z)
Method of Display Word (MDSP) | Setting the Time limit | The Delay Parameter
Frame Duration | Changing the Refresh Rate | Default Frame Duration
There are a number of special display functions that can be selected either by specifying appropriate values for the parameters in the parameter line of the ITM file, or by specifying special control switches in the body of an item. Options specified in the parameter line are intended to be the default conditions for the entire experiment. Options specified within an item are restricted to that item (but there are some exceptions). For a listing of the parameters see Sec. 2.1. The following discussion explains these options in more detail.
Many of the display options are controlled by setting bits in the MDSP word, which is specified in the parameter line. This is achieved by setting the MDSP word equal to the sum of the option code numbers corresponding to the desired options in the summary table below. Detailed explanations of each option are given later (see section 3.2).
1: no feedback at all
2: correct feedback only
4: wrong feedback only
10: continuous running
20: response-contingent display
40: audio tape display
100: display-onset timed from time of request
200: no RT in feedback message
400: double tape-pulse as request
1000: no RT -- right or wrong only
2000: naming time negation
To calculate the appropriate value of the MDSP word, select which options you want, and add the corresponding option code numbers together. For example, if the first line of the item file contains the sequence
m114
then the MDSP word will be set to the value 114, which means that the third, fourth and seventh options are selected (4 + 10 + 100). This number is always an octal number -- i.e., there can be no digit with a value greater than 7.
(a) Option-code 1:
No feedback at all is provided concerning accuracy or time. Normally feedback is provided.
(b) Option-code 2:
Feedback is provided only for correct responses.
(c) Option-code 4:
Feedback is provided only for incorrect responses.
(d) Option-code 10:
No request (footpress) for a new item is required. Successive items will be automatically displayed until an instruction is reached. A request is then required to resume the display.
(e) Option-code 20:
Response contingent display. Each frame in the item is not scheduled for display until the subject responds to the previous frame, or until the deadline is reached (either the default value of 4 secs, or a user-specified value -- see section 3.3i). See section 3.5 for further discussion of this technique.
(f) Option-code 40:
Audio tape display. This is designed for the situation in which the subject responds to an auditory stimulus rather than a visual stimulus. DMASTR takes input from the TAPE PULSE input channel (see Technical Notes, App. A), which is activated by a pulse picked up from an audio channel. When a pulse is received, DMASTR treats this as an instruction to turn the clock on, and waits for a response. See Sec. 3.5f for further discussion of this mode of operation.
(g) Option-code 100:
Exact request-display asynchrony. The first frame in the item is scheduled for display at an exact constant time interval after the request is received. This interval is specified by the DEL parameter (d) in the parameter line. If this option is not selected (the normal situation), then the delay specified by DEL is only approximate . The approximateness is due to the fact that the delay is normally specified with reference to the current time when DMASTR begins scheduling the display for that job. That is some unspecified time after the request has occurred, and if something such as a disk access for another job has been scheduled soon after the request, then the delay might be longer than required. This will not be noticeable, and is of no great concern, since it does not matter greatly if there is a small random variation in this interval.
However, if there is a good reason to demand an exact time interval, then this option should be used. The most likely situation in which this would occur is when the request is generated by a pulse from an audio tape, and the visual display is meant to coincide with material on the tape (see discussion of tape-controlled displays in Sect. 3.5).
(h) Option-code 200:
Suppresses any information about the length of the reaction-time in the feedback message for correct responses.
(i) Option-code 400:
Only a double tape-pulse with exactly 200 msec separating the pulses (onset-to-onset) will serve to trigger a request. This helps to minimize problems cause by spurious pulses generated by noise. The delay after the request is measured from the onset of the second pulse.
(j) Option-code 1000:
Responses are not timed, but are scored as right or wrong only (+1 or -1).
Note: The value of the MDSP word can also be altered by means of a switch within an item (see sec. 3.3d).
(k) Option-code 2000:
Naming Correction Option. In a naming experiment, the experimenter normally monitors the responses made by the subject and records any errors. It is then necessary to find the item number associated with each incorrect response, and then to use FILE to edit the DTP file, negating the RT for each incorrect item.
However, if bit #2000 of the MDSP word is set, the experimenter is prompted to enter either '+' or '-' at the keyboard after each response. A '+' means that the experimenter defines this response to be correct, whereas a '-' indicates that this response was incorrect. In the latter case, the RT for this item is negated in the DTP file.
This would normally be used with a dual screen display, but it also works on a single screen display (but best with DMTG).
The number of items in the file to which a response is expected, including the practice items, but excluding the instructions. Defaults to 0 if not specified, e.g., n135 means 135 items.
The number of ticks delay between pressing the foot switch (the REQUEST) and presentation of the item. Defaults to 20 if not specified. Note: these are ticks of the video clock (1 tick = 16.7 msec, depending on type of video board).
A value of 0 is interpreted as meaning that the delay should be as small as possible (but will not be equal to zero).
The 'd' parameter has generated some confusion, and many users have assumed that if they set a particular value of 'd' on the parameter line, then this will automatically mean that the delay between the REQUEST and the onset of the test stimulus will be equal to 'd' ticks. THIS ASSUMPTION IS NOT CORRECT.
For versions of DM/DMTG prior to Ver 2.57/5.01, the actual situation is this. When DMASTR receives a REQUEST signal, it then reads the next item and assembles any graphics material that may be required, and then plans all the relevant details of the item. After this has been completed, DMASTR then considers the question of when the item display should begin. The first frame of the item is then scheduled to be displayed 'd' ticks FROM THE CURRENT TIME, not from the time that the request was first received. In the example below, 'd' controls the interval between points (b) and (c), not (a) and (c).
If no graphics were involved at all (DM), or if the graphics made minimal demands, then this was not a problem, since the display would usually be scheduled so close to the time of the request that the error was minimal. That is, (c) - (a) was very close to (c) - (b). However, when complex graphics images need to be displayed (DMTG), a considerable error might be involved, since considerable time may have elapsed since the REQUEST was first received (e.g., up to 100 ms in the worst cases, depending on the speed of the machine).
There are two situations in which such an error is critical. First, in cross-modal priming, where a pulse is sent from an external device (e.g., from a VOX connected to a tape recorder), then the user needs to know what the interval between the pulse and the onset of the display will be (allowing for the error involved in the fact that the raster is not synchronized with the tape recorder). The other situation is where response contingent displays are involved, and the user wants to make sure that DMASTR responds quickly to any response.
(Note that RTs are still measured correctly. It is only the interval between the REQUEST and the onset of the display that is not being timed as the user intended.)
The way in which this problem was solved in early versions of DM/DMTG involved setting bit #100 of the MDSP word, which guaranteed that the onset of the display would begin 'd' ticks after the REQUEST had been received (plus the error involved in uncertainty about the position of the raster when the request signal was received). If DMASTR was unable to meet these requirements, the error message "Item xx displayed yy ticks late" was displayed. This has created problems for some users, since they routinely used a small 'd' value (e.g., 2), and they routinely set bit #100 of the MDSP word. Whenever the display becomes anything more than trivial, this error message begins to appear over and over again.
The correct procedure is to make sure that the interval between the REQUEST and the desired onset of the display is reasonably long (say, 7 ticks). Usually, there is no reason at all to have any shorter delay. The only possible situation where a shorter value would be required is a response-contingent display, where the experimenter wants to make sure that the display changes as soon as the subject responds. However, it is doubtful whether the subject would notice much difference between a delay of 2 ticks and 7 ticks.
Because of the way users treated 'd', and because of the clear implication that in applications such as pulse-driven displays or response contingent displays, 'd' ought to guarantee an exact interval, we have decided to in fact treat 'd' in this way.
Thus, the 'd' parameter will function as if bit #100 of the MDSP word had been set. Users who want to change the MDSP word (for other reasons) will not need to worry about resetting this bit. Once 'd' has been specified, the constant request-display onset option will be in force throughout the experiment.
There will be occasions, however, when DMASTR will not be able to cope with short values of 'd'. For example, suppose we have two fonts and a graphics image involved in an item, and we have set 'd' to a value of 2 ticks. If it takes less than 2 ticks (33 ms on a 60 hz monitor) of CPU time to assemble this item, then there should be no problem. However, if the subject presses the REQUEST key before the previous item has ended, then DMASTR cannot begin assembling the new item until the last frame of the previous item has been displayed.
To cope with this situation, a new convention is introduced. If 'd' is set to ZERO, then DMASTR will schedule the display as soon as possible after the REQUEST is received. This should be the preferred option for response-contingent displays.
However, this may not be appropriate for an external pulse-driven situation, such as cross-modal priming, where the relative timing of the speech signal and the visual probe is critical. However, this problem is easily avoided. If the probe item involves a relatively long assembly time (e.g., an image file), then the pulse that triggers this display should NOT be placed right at the critical part of the speech signal. Rather, the pulse should be located well before the critical point, and an appropriately long value of 'd' used.
(Note that these synchronization problems disappear altogether if the VDMTG software is being used.)
This controls the normal (default) duration of a frame in clock ticks. Defaults to 0 if not specified. A clock tick is defined in terms of the refresh rate of the video display, and for EGA/VGA screens, it is 16.67 ms (14.2 ms for recent VGAs, or even 13.8 ms).
How to time refresh rates.
As a general point, it would be wise for people to check their own timing on their own setup. One way is to construct a file with a repetitive on-off signal. If you place a photocell on the display and then look at the output on an oscilloscope, then you will be able to read off the duration directly. Such an item might look like this:
0 %3 "*******" / %3 / %3 "*******" / %3 / %3 "*******" / %3 / %3 "*******" / %3 "*******" / %3 / %3 "*******" / %3 / %3 "*******" / %3 / %3 "*******" / %3 "*******" / %3 / %3 "*******" / %3 / %3 "*******" / %3 / %3 "*******" / ;
A much simpler method is simply to display something for 3600 ticks, and then see how long it takes before it is erased, e.g.:
0 %3600 "display on"/;
At 60 hz, the program should dispay the text "display on" for 60 sec before it is erased. The frame duration (and hence the refresh rate) is calculated by dividing the total number of frames by the time taken to display them. For example:
refresh rate = 3600 / t
where t is the total time taken to display all frames.
The time limit for a correct response (in msec). Defaults to 4000 if zero or not specified.
These have already been discussed in Sec. 2.4.
Enables or disables input lines (see sec. 3.3q)
Decreases the number of lines displayed on high-resolution display devices (EGA or VGA). This has the effect of speeding up the rate at which the screen is refreshed, hence changing the duration of a video tick. The values of the parameters listed below are based on the assumption that you are using an EGA graphics card and a Princeton Ultrasync display. No guarantee can be offered for any other equipment. For example, an NEC Multisync display will allow some increase in speed, but cannot cope with rates in excess of 100 hz.
Two things should be noted. First, the display screen video controls will need to be altered in order to compress the height of the picture. Second, some of the settings mean that the top line of the screen is missing. Some experimentation may be required to find a suitable setting.
The most useful refresh time for many purposes will be 10 msec (100 hz). This is fast enough for most applications, and it is easier to work with multiples of 10.00 than 16.67. Close approximations to this refresh time can be obtained by specifying either 'L202' (which gives a refresh time of 9.979 msec) or 'L203' (10.024 msec). In both cases, however, the top line of the screen is missing. The following table gives some useful values (an asterisk indicates a missing top line).
No. of lines Refresh time No. of lines Refresh time
125 6.454 203* 10.024
126 6.501 224 10.985
137 7.003 225 11.030
159 8.012 246* 11.992
181* 9.017 268* 12.999
The program 'TIMEG' can be used to time your display
NOTE: In some earlier versions, any job that was run after one that changed the refresh rate was also run with the new rate (probably any version of DMTG earlier than version 3.35, or for DM, version 2.44). You should check your versions to see whether they have this fault. To correct the problem, either get a new release of the software, or make sure to bring down the program and re-run it whenever you want to return to the default number of lines.
{ only for DM Ver 2.57 and DMTG ver 5.10 and higher }
It is now possible to get an ASCII output file instead of a binary DTP file. This file has the extension '.AZK', and lists item numbers and RTs in the order in which they were presented during the experiment. This option is selected by inserting the symbol 'A' on the parameter line of the item file.
It should be noted that item numbers are no longer restricted to three digits when this option is exercised.
Problems with the 'A' output option in response contingent displays.
When the user asks for ASCII output of RTs (by placing an 'a' on the parameter line of the item file), there is a problem if the method of display is response contingent. So, for example, in the following item:
001 + "a" / - "b" / + "c" /;
the AZK data file will contain RTs for items 002, 003 and 004 instead of 001, 002 and 003. That is, the item number is incremented before the response is registered, rather than after. Clearly, this is easy to cope with, once you know that it is happening.
In DM v2.61 / DMTG v5.18, this problem has been corrected. Check your version carefully.
{ only for DM Ver 2.57 and DMTG ver 5.10 and higher }
Placing a 'Z' in the parameter line of the item file makes it possible for DMASTR to record multiple RTs. So, for example, the subject might be required to press three keys in response to a stimulus display. DMASTR will record the RTs to each response, and will output them with an identification indicating which response it was. The output file will not be the normal binary DTP file, but will instead be an ASCII file with the extension '.ZIL' (this comes from JCF's description of this option as allowing for a zillion responses, and hence the option is sometimes referrred to as the ZILLION option).
Note that any type of response that your version of DMASTR will accept can be handled in this way.
The normal mode of operation is for ALL responses occurring prior to the timelimit (default setting of 4 sec) to be recorded. An alternative procedure is to set bit #4000 of the MDSP word, which will then use the ENTER key on the keyboard as the terminator.
One problem that arises in KEYBOARD versions of DMASTR is how to give commands to DMASTR. If the ZILLION option is in operation, then ANY key press will be treated as a response, not just the right and left shift keys. In order to give a command during the job (e.g., to halt the job, or to abort it), first press
ESC. This terminates the ZILLION option, and the keyboard reverts to its normal mode of functioning. Otherwise, the ZILLION option is not terminated until the last frame of the item file is encountered.
Should users need to record reaction times longer than 32k msec, a procedure is available which allows the user to specify a scaling factor in the parameter line of the item file, so that all reaction times are divided by this scaling factor. The divisor is specified by including a 'c' switch in the parameter line, followed by a number. All RTs are divided by this number. For example:
n100 f50 c10
This parameter line specifies that the experiment has 100 items, that the frame duration is 50 ticks, and that the RTs should be divided by 10. Thus, the RTs are expressed and stored as centiseconds rather than milliseconds.
Note that this switch must be included on the parameter line of the item file (i.e., the first line).
Note that feedback messages will now contain times in the new units. However, the 't' parameter (the time limit for a response) is still defined in milliseconds. This can now be specified as any value up to 2,000,000,000 milliseconds.