General
Clock on signal (*) | Erasing the display area (E) | On-line changes in MDSP word (&)
Animation (a) | Comments switch (!) | Continuous running (c) | Diagnostic run
Input enable switch (k) | Output switch (o) | RT correction factor |
Control of frames
Individual frame timer (%) | Fixed position display (p) | Non erasing frame (!) | Line Control (@)
Graphics
Graphics frame (g) | Positioning of Graphics Frame (x,y) |
Fonts
Installing a Font | Selecting a Font |
Color-related Topics
Changing colors (v) | Changing the Palette (vv) |
There are also a number of display options that are specified by display-control switches inserted into the item itself. These options are valid only for the particular item in which the special character appears (unless otherwise noted).
Throughout, blanks are ignored, except in text. Also, the display-control switches can be in either upper or lower case.
For complex situations, it may be necessary to designate special frames which receive special timing control. Normally, frame i+1 is scheduled to be displayed FD ticks after frame i, where FD is specified in the parameter line.
However, if frame i contains the display-control character % followed by a number, e.g., %3, then the value of FD is temporarily altered to 3, so that frame i+1 is scheduled 3 ticks after frame i.
Normally, this means that frame i has a duration of 3 ticks, but this is really only true if frame i+1 is superimposed on frame i, and therefore erases frame i prior to the display of frame i+1. In DMTG this is always the case, but in DM this will only be true if the second frame is written on the same line as the first frame (DM is far more line-oriented than the graphically-oriented DMTG). If the second frame is on a different line, it will not erase the first frame, which will persist while the second frame is being displayed.
So, the frame-timer is really not a direct method of specifying the duration of a frame. Strictly, DMASTR only receives instructions about the time at which each frame is to be displayed. It does not consider when frames should be erased. That responsibility is left up to the user.
The most common application of this option is %0, which means that the current frame and the next frame have the same onset (i.e. are displayed simultaneously). This is only sensible if the next frame does not erase the current frame, i.e., is on a different line.
When a frame containing the symbol "*" is displayed, the millisecond clock is read and the time stored. This time is subtracted from the time when a response occurs to produce the reaction time.
This signal also indicates that a response is now expected. Any response which occurs before "*" will be ignored.
The clock-on signal may be placed anywhere in the frame, except in the text area. This symbol, as with all display-control symbols, is not displayed.
Frames are normally displayed on line 1. However, if the frame contains the line control symbol (@), it will be displayed on line 2, centred in the normal way.
The symbol @ should be read as "down one". If @ is followed by a number, e.g., @2, then this should be read as "down 2". Any frame containing this sequence would be displayed on line 3. Thus, @@ is equivalent to @2.
Note that in DM each successive frame will erase the previous frame only if both frames are scheduled on the same line. Once a frame has been scheduled for a different line, it is the user's responsibility to erase it (see notes below on the display-control character E).
Users should note that in a multi-job version of DM, they are limited by the number of lines assigned to the job. The smallest number of available lines is 4 (when the number of jobs is also 4). Within these limits, users can display material on any line, but it should be noted that feedback is displayed on the fourth line.
Note: This option has been extended in DMTG. The number following @ can be negative, in which case the display line is one above the center of the screen.
If you wish parts of the display to be normal and others response contingent, you can modify the MDSP word on-line. For example, suppose you want RSVP on the first five frames, but you want the target item (the second last frame) to remain on the screen until the subject responds. The correct procedure is as follows:
+100 &0/"The"/"dog"/"went"/"to"/"the"/&20/-*"splode"/ ;
The first occurrence of & sets the MDSP word to zero and the frame duration is controlled by FD. The second occurrence of & sets the MDSP word to 20 prior to the scheduling of splode and prevents the erase frame from being scheduled until a response is received. Note: the change to the value of MDSP does not take effect until the following frame.
If a frame contains the switch "!" it will not erase the previous frame, but will overprint it. The consequence of this varies slightly for the two display programs.
In DM, a frame will remain on the screen until it has been erased. But in DMTG, a slightly more active approach is required to keep a frame on the screen. This results from the fact that DMTG uses two video pages, and changing from one frame to the next means changing from one video memory page to the next. Consequently, if something is to remain on the screen while something new is presented, the information must be copied from one video page to the next.
The non-erase symbol ('!') is used to inform DMTG that the material from the previous frame should be copied across to the new video page. For example:
"frame 1"/ ! @1 "frame 2";
Without the '!', frame 1 would disappear when frame 2 was presented, even though it does not overwrite the same part of the screen (in DM, both frames would appear).
This is also true even when several frames are scheduled to appear simultaneously. DMTG requires that the non-erase symbol appear in each
frame after the first. For example:
%0 "frame 1"/ !@2 "frame 2";
Note: The last frame in a series of frames scheduled for simultaneous display must NOT contain '%0'.
This switch signals that the frame to be displayed is a bit-mapped graphics image, and that the text material in that frame is actually the filename for the image (DMTG only). For example:
002 "apple"/g"carrot"/;
will display the word "apple" in frame 1, followed by the graphics image contained in the file 'carrot.img' (the default extension for image files is 'img'). If this file cannot be located, DMTG warns the experimenter, and prints on the screen the name of the missing file.
Note that the filename can include a path, e.g.:
002 g"\graphics\img\carrot"/;
For information on the preparation of image files, see Section 13.
This option has two effects. It enables the user to specify the left-to-right start position of a frame, and it also allows for incremental display, in which frames are displayed as in normal text, i.e., each new word appearing to the right of the preceding word, instead of being superimposed on the previous word (as in RSVP).
To specify the starting position, include P followed by the number of blank spaces from the left edge of the screen before the text is to begin. For example:
+25 P15"The"/"dog"/"went"/"home"/;
The first frame of this item would be positioned 15 spaces from the left of the screen.
Each subsequent frame will begin immediately to the right of the end of the preceding frame. This is particularly useful for word-by-word sentence reading experiments. Thus, the relative positions of the letters in the above example would look like this:
<15 spaces>Thedogwenthome
except that only one word would be visible at a time.
If you wish to have each successive frame superimposed on the preceding frame (i.e., non-incremental display), then the P parameter should be re-specified for each frame. Thus:
+25 P15 "The"/ P15 "dog"/ P15 "went"/ P15 *"home"/;
In DMTG, there is a further option available. The P switch can take two numbers separated by a comma. The first number functions as above, while the second specifies the number of pixels separating the starting positions of successive frames, e.g.,
+025 P15,50 "The"/"boy"/"went"/*"home"/;
means that the second frame begins 50 pixels to the right of the beginning of the first frame. This option is useful where the distance between frame onsets needs to be constant, no matter what the frame contains.
Any frame containing the switch "B" will cause the bell to be sounded. Placing a ^G in the text area will not have the same effect (it appears on the screen as an uninterpretable character).
If an item contains the switch "C", the next item will be scheduled for display (with the default delay) without waiting for a request from the subject. This can be located in any frame. This has a similar effect to option number 10 in the MDSP word, but is more local in its effects, since it applies only to a single item, rather than the whole file.
Note: This option can be used if you are presenting a list of items for study at a fixed rate (not self-paced). However, in order to precisely control the interval between items (specified by the DEL parameter), remember to set bit #100 of the MDSP word (the exact request-display asynchrony option).
Switch "E" will erase the display area for a job. This is the easiest way to erase a multiple-line display.
e.g., 001 "blah"/@1"blah"/@2"blah"/E;
In DMTG, this switch is particularly useful if you are having problems erasing a graphics image.
Switch "L" must be located in the last frame of the job, e.g.,
000 L"Thank you that's all";
This automatically causes the bell to sound in the control-room.
This has quite different interpretations in DM and DMTG.
In DM, where a monochrome display is used, switch "V" means that the current frame will be in reverse video. Thus:
001 V"blah";
presents the test "blah" as black letters on a white background. One could set this up in advance: e.g.,
001 "context" / V" "/ V "target" / ;
The second frame (blank) displays a white background, and the third writes the word "target" in black letters on this background.
In DMTG, the function of the v switch is to change the color associated with the foreground or background using the following color codes:
Color control is achieved by specifying two numbers after the v switch, separated by commas (no spaces). The first number sets the background color, and the second sets the foreground color. For example,
+1 v1,4 *"dog"/;
This will change the background color to color number 1 (blue), and the text "dog" will appear in color number 4 (red). This change will remain in effect until a new value for the 'v' switch is specified.
Previous discussions of color in DMTG have been expressed in terms of the 'foreground' color and the 'background' color. The screen itself was written in the background color, and the text was written in the foreground color.
The more complex requirements of MultiChrome versions of DMTG require a more sophisticated understanding of what actually happens. Basically, the colors that appear on the screen are controlled by a two-stage mapping operation. The initial input to this function is given by integer values ranging from 0-15 written into the screen memory for each pixel. Call these 'screen memory values'. The second stage involves feeding these numbers into a function called the 'palette', which maps screen memory values onto instructions to the color guns, i.e., actual colors. This involves associating screen memory values with what we will call 'color numbers'.
Suppose we think of the screen memory value '0' not as 'color 0', but merely as the '0th color on the palette'. By changing the organization of the palette, we can make the number '0' mean any color we wish.
Normally, the palette associates the screen memory value '0' with the color number 0 (black), and the screen memory value '1' with color number 1 (blue), etc. This is the default setting. However, the palette can be changed, so that a screen memory value of 0 could produce color number 2 rather than color number 0. Or it could be that several screen memory values could all be mapped onto the same color number.
In the MultiChrome version of DMTG, the palette can be changed by specifying the mapping function between screen memory values and color numbers. This is done by specifying up to 16 numbers after the v switch, e.g.:
v0,0,0,0,0,0,1,1,1,0,0,0,0,0,0,0
The first value is the color number assigned to a screen memory value of 0. The second number is the color number assigned to a screen memory value of 1, and so forth, up to a value of 15. The example above would have the effect of converting screen memory values of 6, 7, and 8 to color 1 (blue), with all other values being expressed as color 0 (black). Hence we would have a black background.
Essentially the same logic applies in two-color versions of DMTG, except that only two numbers can be specified in the palette function, as in the example in section 9 above.
Not all 16 numbers need to be specified. If, for example, you only wish to change the first four values, then the remaining 12 can be omitted, e.g.,
v0,1,1,0
If a value of -1 is specified, the color value for that screen memory value will be left untouched.
Note that in two-color DMTG programs, the text to be displayed is always entered into screen memory as the value 1, and the background is always given the value 0. Hence the first number in a palette function always specifies the color of the background, and the second specifies the color of the text.
Note also that in MultiChrome versions of DMTG, it is possible to change the text value written into screen memory by means of the 'w' switch, e.g.,
+1 w3 *"dog"/;
would have the effect that the text would be entered as the value '3' instead of '1'. What color that would appear as will depend on the palette currently in force.
The full palette specification is rather cumbersome, especially if it is repeated over and over again. To avoid this, use a macro to define a single symbol to be equivalent to the whole string.
For example:
mP:v0,0,0,0,0,0,1,1,1,0,0,0,0,0,0,0:
this defines the symbol 'P' to be equivalent to the palette function, and this can then be invoked in subsequent frames as follows:
+01 ~P * g"picture"/;
It is also possible to change the actual colors associated with the color numbers. So, for example, if one wanted to change the color called 'black' (color 0) so that it had a little more red in it, then one can use the vv switch as follows:
vv0,10,0,0
The first number following the vv switch is the number of the color to be changed (in this case, 0), and the next three numbers specify the amount of red, green and blue in the color. These numbers range from 0 to 63, where 63 is full strength.
To respecify the entire palette, one could have 16 x 4 = 64 numbers, but you only need to include a specification for the colors you are changing. For example:
vv6,13,63,63,9,4,4,4,12,55,16,11
changes the 6th, 9th and 12th colors.
Whenever a TIF file is input to EDTSCR (or M_EDTSCR), a copy of the palette is written out to disk as a vv file.
Multichrome versions of DMTG allow for high-quality graphics images, such as the grey-scale output from a scanner, which is good enough to present recognizable faces. However, such image files take a long time to load, and hence it would not be possible to present them tachistoscopically.
To see why this is the case, it is useful to know something about how DMTG works. The EGA graphics card provides two screens, one called the Active screen, the other the Inactive screen. Changing a display involves simply switching between screens, so that the Inactive screen becomes the Active screen, and vice versa. To display a sequence of frames, a display program must draw frame 1 in the Inactive screen, and then wait for the appopriate time to switch the display to that screen. However, meantime, it can do nothing about frame 2, since there is no screen to write that frame to. If a rapid transition is called for, the program quickly gets into a bind, since it must complete the drawing of frame 2 in the Inactive screen before it is time for frame 1 to be replaced.
Since drawing is very slow, DMTG would be restricted to very slow presentation rates (even for two-color images) if this was the method it used. Instead, the following is the procedure it actually uses. As soon as an item is finished, DMTG begins planning the next item. This involves drawing each frame in the Inactive screen, and then copying the resulting image to an area of memory called the 'far heap'. Thus, each frame is 'pre-compiled', so that it can be copied very rapidly back into the Inactive screen memory when needed.
For reasonably small two-color images, this procedure means that DMTG can present a new image every 16.7 msec. But with large multi-colored images, it could take up to 125 msec just to copy the image back into screen memory from the far heap.
One solution to this problem is to load the image file into the screen memory while the palette function is set so that all screen memory values are associated with the same color as the background, and therefore the image is invisible. After a suitable time has elapsed, the palette function is changed to the normal value, and then is switched back to the original value. E.g.,
+1 v0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 g"face1" /
! %3 v0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 /
! v0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 ;
In the first frame, the image "face1" is displayed, but with the palette function set so that all screen memory values are associated with the same color as the background, and hence nothing is visible. In the second frame, the non-erase symbol ('!') prevents the image from being unloaded (it has the effect of copying the image into both screen memories), and changes the palette function back to normal for just 3 ticks, so that the image becomes visible. In the third frame, the change in palette instantly erases the image. Note that it is important to keep the non-erase symbol here. If it had been omitted, then DMTG would have tried to load a 'null' frame consisting of a screenful of blanks, in order to erase the previous image. This process is just as slow as displaying another image, and if this took more than 3 ticks, then our exposure time would have been greater than 3 ticks (note that DMTG would warn you that it was unable to display a frame at the requested time).
Changing colors by changing the palette also makes it possible to display rapid sequences of multi-colored images. To do this, use a graphics package to draw each picture in non-overlapping sets of colors (i.e., no color used for the first picture is used for the second). These two pictures are then captured by SNAPSHOT. The trick now is to superimpose these graphics images on the screen, and to manipulate the palette so that all the colors used to draw the second figure are mapped onto the same screen color as the background, while all the colors used to draw the first figure are mapped onto a different color (or colors). When the composite figure is shown with this palette, only the first figure will be visible. Switching to the second figure only requires that the palette be changed, so that all the colors used to draw the first figure are now mapped onto the background color, while the colors used to draw the second figure are
now mapped onto some non-background color(s).
As an example, suppose we use screen memory values of 1 for the first figure and values of 2 for the second. That is, when the image file for these figures were captured, the first figure was in blue and the second was in green.
Now, we present a fused version of these two figures in the following way:
0 %0 v 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 g"figure1"/ !g"figure 2"/
! v 0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0 /
! v 0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0 / E;
In the first two frames, the two images are fused together and displayed with the color palette set so that both figures are displayed in the same color as the background (black), and are therefore invisible. In frame 3, the first figure is now revealed in color 1 (blue), and in the fourth frame, the second figure is revealed in the same color. These transitions can take place virtually instantaneously, because the graphics images have already been read into memory. All that is required to display them is the appropriate change in the palette, which is extremely fast.
Note the importance of the '!' symbols. In frame 2 it causes the second figure to be superimposed on the first, while in frames 3 and 4, it prevents erasure of the images so that the color change will have the desired effect.
Because of the way that the four color planes are used (generating 2x2x2x2 = 16 different colors), there are restrictions on how the colors can be used. If each figure is to be presented in only one color, then colors 1, 2, 4, and 8 can be used, making it possible to store 4 separate figures on the screen at once. If you need more than one color per figure, then only two figures can be stored in advance, the first using colors 1, 2, and 3, the second using colors 4, 8, and 12.
Similar procedures can be used if a whole screen of text must be presented very rapidly. One can use the 'w' switch to manipulate the color used for writing text, but using a palette function that makes the display invisible. In the following example we present just a single word of text on each frame for illustrative purposes, but actually it could be an entire screenful of text.
+1 %20 v0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 w1 "text1"
! %20 w2 "text2" / ! %20 w4 "text3"/ ! %20 w8 "text4"/
! %2 v0,1 / ! %2 v0,0,1 / ! %2 v0,0,0,0,1 /
! %2 v0,0,0,0,0,0,0,0,1 / v0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0;
The switch F signals that you are about to specify a feed-back message to be used subsequently. This is followed by C (for the message to be used for correct responses), W (wrong responses), or T (too long). Whatever character appears next is the delimiter, which must also appear at the end of the message, e.g.,
FC=Good=
This sets up "Good" as the correct feedback message. If you wanted to suppress feedback for, say, wrong responses (but not correct or too long responses), then the following will suffice:
FW==
These feedback specifications can appear anywhere, so you could theoretically have a different feedback message for every item. Generally, the best procedure is to locate them in an instruction (locked into a fixed position so that the scramble program will not shift it -- see the section on scrambling for further details), which contains a C control character so that the subject does not have to press the footswitch to request the next item (remember, nothing will appear on the screen), e.g.,
$0 C FC=OK= FW== FT=Speak louder=;$
There is a limit of 20 characters to any feedback message.
The number which follows R is a correction factor to be subtracted from the reaction time for this item. This is used for acoustic experiments (when bit #40 of the MDSP word has been set), where the onset of the acoustic stimulus is signalled by a tape-pulse, which also starts the clock. However the tape pulse will not necessarily exactly co-incide with the stimulus, and hence a correction needs to be applied to the reaction time. For example:
+23 r43 *""/;
has the effect that 43 ms would be subtracted from the observed RT for item number 23 before it was stored.
Note: This correction is applied only when bit #40 of the MDSP word is set.
Problems with Acoustic stimuli.
When subjects are responding to an acoustic stimulus, DMASTR is instructed to time the response from the time that a TAPEPULSE is received, not from the onset of a frame with a CLOCKON symbol ('*'). This option is selected by setting bit #40 of the MDSP word. The reason for this is that the subject is responding to an acoustic event, not a visual event, and hence no visual display is required (unlike, say, cross-modal priming). However, in actual fact, an item containing a null frame with a CLOCKON symbol is still required to inform DMASTR of the item number and the correct response. The CLOCKON symbol is retained because this input switches DMASTR into the state of 'expecting a response'. An unexpected consequence of this procedure is that DMASTR will still take account of the value assigned to the delay parameter ('d'), which specifies the delay between the request (in this case, the TAPEPULSE) and the beginning of the visual display. The way that the 'd' parameter is taken into account is that DMASTR will ignore any response that occurs before this delay has expired. If no value for 'd' is specified in the parameter line, a default value of 20 ticks is assigned, and this means that DMASTR will ignore any response that occurs before 20 ticks have elapsed. This means that reaction times faster than 320 ms (on a 60 hz display) will be ignored.
The upshot is that a short duration of, say, 6 ticks should be specified for 'd' when bit #40 of the MDSP word is set.
The symbol D allows the delay between the request and the display onset to be varied for each item separately. See the discussion of the 'd' parameter for details.
This is used to control an external device, such as a remote-controlled tape deck.
Jobs 1 and 2 control two output lines each, PC4 and PC5 for job 1 and PC6 and PC7 for job 2 (no provision is made for jobs 3 and 4). Two lines per job are allocated because it takes two lines to control a Nakamichi MR-2, one line for play, the other for pause. The O switch outputs the data, and the actual output is done when the frame it is in gets displayed (as opposed to when the item is scheduled), so:
o3
would set both output lines for that job high. When the job is not active both output lines are driven high. The way booth 2 is wired up bit 0 controls the pause button and bit 1 controls the play button, both are active low, so:
o1 / o3 %3600 / o2 / o3
would play the tape for a minute and then pause it. The o3 is equivalent to releasing the button after you have pressed it.
Change in the output codes for the PIO
{ only for DM Ver 2.57 and DMTG ver 5.10 and higher }
Previous versions of DMASTR used only the highest four bits of port C of the PIO card. For single-job versions of DM and DMTG, the entire 8 bits are now used. Users who are upgrading to the newer version will either have to rewire the cabling for the PIO card, or leave the wiring the same and change the output codes. If the latter option is chosen, then you should use a value of 16 instead of 1, 32 instead of 2, 64 instead of 3, etc. If you choose to rewire, then bit 0 of the output is connected to pin 29, 1 is connected to 28, 2 is connected to 27,......, and bit 7 is connected to pin 22.
This switch permits the user to instruct DMASTR to ignore certain inputs. The default value enables the request key and the response keys (disabling the Vox and the Tape Pulse inputs). It is an octal word like the MDSP word. Values are:
REQUEST 01 (footswitch)
NEG_RESP 02 (negative response button)
POS_RESP 04 (positive response button)
TAPE_PULSE 10 (pulse from tape recorder)
VOX 20 (vocal naming response)
As with the MDSP word, the user should add the values associated with the desired inputs. So, for example, the default value is 7 (1 + 2 + 4). Or, to enable just the VOX, for example, then include 'k20' at the beginning of the item file.
There is also a K parameter (see sec. 3.2.10) which functions in exactly the same way. The switch version is sometimes more useful when you wish to change the inputs during the experiment.
This option is available in DMTG only, and enables the user to install a number of different fonts (stored as CHR files in the directory c:\bin\dm). A font is installed by including the "I" switch in any frame followed by a text delimiter (any character), followed by the name of the CHR file (the extension can be omitted), followed by a repetition of the text delimiter to indicate the end of the filename.
The standard fonts currently available are:
trip.chr a triplex font (proportional spacing)
sans.chr sanserif (proportional)
litt.chr a (very) small font
nonp.chr a non-proportionally spaced version of sanserif
So, for example, to install the sanserif font, include the following:
/ i+sans+ /
Note that it takes some time to load a font. If multiple fonts are required, then the install switch can be repeated within a frame, thus:
/ i+sans+ i+trip+ /
The first font to be installed becomes the default font for the display, including feedback.
Font specification also optionally includes the size of that font in fractional format with the -W and -H switches (width and height) inside the delimiters. Size is indicated by two integers separated by a slash. Thus 3/2 means to increase the size of the font by a ratio of 1.5. Reduction to half-size would be given by 1/2, etc. To change the height of the font, preface this ratio with -H. To change the width, preface with -W. For example:
/ i+sans -h1/2 -w1/2+ /
You can set up any number of indexes with different sizes and the same font. There is no time overhead incurred to change size. If you wanted the sanserif font in two sizes, one normal and the other one and a half times tall and three quarters as wide, then the first frame of the item file would contain:
/ i+ sans+ i+ sans -h3/2 -w3/4+
If more than one font has been installed, you have to be able to select which font is to be used to display text. This is done with the Q switch. The number following this switch denotes the font (numbered in order of installation). For example:
000 i+sans+ i+trip+ i+sans -h1/2 -w1/2+ q1"here"/q2"we"/q3"are";
would display "here" in normal sanserif, "we" in triplex, and "are" in half-sized sanserif.
Note that each time the 'Q' switch is used to switch from one font to another, the 'chr' files for the new font must be read from disk. This will increase the time required to prepare the display image, which could create problems when an extremely fast response-time from DMTG is needed, i.e., when the interval between the request and the onset of the display must be very brief (see sect. 3.5g). An error message will be displayed on the experimenter's display if the display routines are unable to keep up with requirements (as already noted, this restriction does not apply when switching between different-sized versions of the same font).
If this becomes a problem, then there a number of solutions. One is to create a ram disk and to locate all files, including EGAVGA.BGI, the CHR files, and the ITM file in a directory on that drive. If you then log onto that directory, so that it is the current directory, then DMTG will know where to find the appropriate files, and will be able to read them much faster. Alternatively, one could instal a virtual disk, or a disk cache system.
If the first character of an item (i.e., the CR indicator) is equal to "!", DMASTR will ignore that item altogether. This allows the user to insert comments into the item file, without having them displayed. For example:
m0 n25 f50
!This is the priming phase;
+001 *"dog"/;
Note that the comment line must be terminated by ";". That is, DMASTR will ignore everything between "!" and the next ";". Also note that the comment need not take up a separate line:
! install sanserif font;000 i+sans+ *"dog"/;
To absolutely position a bit-mapped graphics image in DMTG, the 'X' and 'Y' switches are provided, which define the pixel position of a frame from the top left corner of the screen. The dimensions of the screen are 640 x 350 on an EGA device (these dimensions change however with other displays). In the interests of speeding up the display, there is the requirement that x coordinates should be in multiples of 8. For example:
+023 g x56 y200 *"carrot"/;
will display the graphics image file "carrot.img" starting on line 200 at the 56th pixel position. If the x co-ordinate had been, say 55, DMTG would have moved to the nearest multiple of 8.
If text is being displayed, then only the 'Y' switch will have any effect. Positioning of text absolutely is better done by using a combination of the line control ('@') and the 'P' switch.
{ valid for versions from 27/1/93 }
Including a switch of the general form 'An,m', where n and m are integers has the effect of rescheduling the current frame m ticks in the future, this process to be repeated n times. For example:
0 %10 a100,20 "xxx" / %10 a100,20 "ooo"/ ;
This will generate the display "xxx" for 10 ticks, and then the display "ooo" for 10 ticks, this cycle being repeated 100 times. The actual procedure is that the "xxx" frame is scheduled for display in the normal way, except that when it is actually displayed, the value of 'n' is decremented, and if it is nonzero, the same frame is re-scheduled for display m ticks from that time.
It is advisable to include a final frame that does not contain an animation switch. Also, the results are somewhat unpredictable if any frame not containing an animation switch is inserted into a sequence of frames that all contain an animation switch.
This feature has been available for some time, but has not previously been documented.
In this mode, the experiment runs itself continuously without waiting for any requests, or responses from the subject. The item number is stored as the reaction time so that the operation of the unload program, and updating can be checked (i.e., you know that the RT for item 001 should be 1, for item 002 it should be 2, etc.). By monitoring the subject's screen, the experimenter can also check the display.
For the single-screen versions of DMASTR, the 'D' switch is specified thus:
G1BSFILEA/D
If you are using the dual-screen version with menu, then you will be prompted for this option. Respond to the prompt by typing 'D'.
In some applications, it is important to store some identification of the subject in the DTP file. This is done by including the "I" switch, and specifying a number as a value of the switch. For the single-screen version, the switch is specified as follows:
G1BSFILEA/I4
This will store the number 4 in the slot normally reserved for the reaction time for item 255. Avoid using this item number if using this option.
As before, the menu-driven version will prompt the user for this information.
Only one character can be used. However, this permits up to 92 distinctive IDs, using the shift key. For example, one could number in the following way: 0 - 9, A - Z, a - z.
These IDs can be examined using FILE. If you wish to view the ID as the actual ASCII character that you typed in, then the command 'A509' should be used. This asks for the ASCII interpretation of the 509th byte, which is the low byte of the 255th word.