DMASTR (DisplayMaster) is a family of MS-DOS programs written in TurboC and FORTRAN IV for displaying alphanumeric or graphics material for reaction-time experiments on an IBM-compatible PC, XT or AT.

The system consists of two major classes of programs. The first are the Display programs (written in TurboC), which are responsible for getting material onto the display screen and recording the subject's reaction time (RT). The second class consists of Dmastr Utilities. These programs assist in the construction and editing of the materials to be displayed, data storage, analysis, and reduction, and statistical analysis.


There are two display programs: DM and DMTG. The first of these is restricted to alphanumeric text displays (i.e., the graphics card is in "text" mode), while the latter allows for far more flexible displays using graphics mode. These programs must be located in a "c:\bin\dm" directory. This directory should be included in the PATH statement in the "autoexec.bat" file. For example:


Occasionally we will use the term "DMASTR" to refer to the display program, rather than "DM" or "DMTG". This simply means that both programs behave the same way. On other occasions we use the term "DM/DMTG".


This program displays standard ASCII text data in the standard IBM font, using hardware character-generation.

Each of the subject-stations is supplied with two response buttons and a footswitch. Pressing the footswitch generates a "request", i.e., a request for a new display. Pressing one button generates a positive response, while pressing the other button generates a negative response. These responses are interfaced to the PC through a parallel I/O board.

Two display options are available. The first has only one display screen (either monochrome or color). This screen handles the material to be displayed to the subject and the task of echoing the commands given by the experimenter on the keyboard. The second version has two screens -- one monochrome and the other color (the organization of the PC's memory makes it impossible to have two graphics boards of the same type). The monochrome screen is used to display information to the experimenter, while the color screen is used to display material for the subject.

DM permits up to four different experiments to be run simultaneously and asynchronously; that is, they can start and stop at different times. The display screen is divided up into as many as four job areas, each consisting of five display lines. A copy of this display is sent to a slave screen in each of the subject testing stations. This display is masked so that only the relevant portion of the screen can be seen. The keyboard is used by the experimenter to load and unload jobs (experiments), save data, transfer files, etc. The programs that run this option are labelled to indicate the number of jobs permitted, e.g., DM4, DM2, etc. This option was developed back in the days when the very expensive PDP-11 was the cheapest alternative around. But today, it is seldom used. The default version, DM, runs just one job.


This program uses the TurboGraphics Library available in Version 2.0 of Borland's TurboC, which means that text can be presented in a much more flexible fashion. Text is displayed using "stroked" fonts, which can be enlarged to whatever size is needed. Several different fonts are available, or the user can design their own fonts (see Sec. 13). Or, graphics can be presented as a bit-mapped graphics image.

Because of the extra time required to process and display graphical information, DMTG allows only one job to be run at a time. Like DM, this program also comes in a dual-screen version or in a single-screen version. DMTG uses both pages of video memory; one page is currently being displayed while the details of the next frame are being calculated in the second page.


This is a version of DMTG that presents acoustic stimuli as well as graphics, and allows for precise synchronization between them. It uses the format specified by the BLISS speech editing system developed by John Mertus at Brown University.

Display terminology.

Each experiment consists of a number of items which can be of three types:

(a) instructions or reminders to the subject

(b) practice items

(c) experimental items which require a timed response.

Each item consists of a sequence of frames. All the material specified within a frame is displayed simultaneously. Frames are scheduled for display at different time intervals.

Raster synchronization.

Both DM and DMTG display programs are synchronized to the sweep of the raster down the screen, which is essential for the accurate measurement of reaction-times. Each time the raster returns to the top of the screen, an interrupt is received. The code servicing this interrupt examines a queue of scheduled frames. Each frame is scheduled to occur at a specific time according to a clock which is synchronized with the raster. For video systems running at 50 hz (e.g., the Hercules monochrome graphics card), each "tick" of this clock is equivalent to 20 msec. For systems running at 60 hz (e.g., EGA or VGA cards), each tick corresponds to 16.7 msec. More recent SVGA cards run at 70 hz, where a tick is 14.2 ms, or 72 hz (13.8 ms). This synchronization is essential for the accurate timing of diplays and the measurement of reaction-times, since in an unsynchronized display, there is no way to know precisely when the display onset occurs.

One consequence of adopting a video display is that display times can be varied only in multiples of ticks. So, with an EGA display, the shortest display time is normally 16.7 msec (1 tick), and the next shortest is 33.4 msec (2 ticks). However, reaction-times are measured with an accuracy of 1 msec.

(Note: For power-users with display screens that are capable of locking in to a range of refresh rates -- e.g., the Princeton Ultrasync or the NEC Multisync -- there are procedures for changing the refresh rate, and hence the length of a tick -- see Sec.3.3.)

Simulated vs real video interrupts

DM and DMTG are both designed to operate with video interrupts. That is, the graphics card generates an interrupt whenever the vertical retrace of the raster occurs. This makes possible the synchronization of the display program with the raster scan.

However an increasing number of manufacturers are abandoning the video interrupt feature, which means that you have to use the 'simulated' video interrupt version of DMASTR. In its original implementation, the interrupt was generated artificially through software, so that the interrupt was simulated, but this did not have the effect of synchronizing the program with the raster. In later versions (circa 1988) this was improved to produce real synchronization. The method is as follows. First, DMASTR times the refresh interval. Suppose a refresh occurs every 16.6 ms. DMASTR sets a counter to zero immediately after a refresh has occurred. This counter is incremented by the interrupt routine that services the clock, which interrupts every millisecond. After a count of 13 is reached, DMASTR goes into a tight loop monitoring the video retrace bit. As soon as it occurs, the simulated interrupt is generated as before. This works very well, but it means that DMASTR wastes 3.6 out of every 16 ms in a tight loop, which means that it cannot do any further work on preparing the display.

This reduces the efficiency of DMASTR, but if you are not putting it under very much pressure, this doesn't really matter -- especially if you have a 386 or better. How do you tell? You get error messages saying:

"Item 1 (frame blah) scheduled 1 ticks late, not displayed"

(incidentally, a very common cause of this error is forgetting to specify any value for the frame duration, meaning that it has the default value of 0, which makes it very difficult to display things on time).

However, users who are reprogramming the refresh rate may run into trouble. If you have refresh rate of 6 ms, then DMASTR will still spend 3.6 ms waiting for the video retrace bit, which means that 3.6 out of every 6 ms is locked up, leaving only 40% of CPU time for preparing the display.

Previously, it was necessary to run different programs depending on whether the video card supported an interrupt on the vertical retrace. The presence (or absence) of an interrupt is now automatically detected by both DM and DMTG, and the appropriate method of synchronization is automatically selected. What method is being used will be signalled in the sign-on message. If it contains 'VidSim', then the program is using a simulated video interrupt.

Hardware requirements.

If you have only a monochrome display adaptor, then you are automatically restricted to using a single-screen version of DM with a monochrome display.

If you have an EGA or VGA card, then you have the choice of running DM or DMTG. If you also have a monochrome board, then you can run with a separate monochrome monitor for the experimenter.

The responses of the subject are normally interfaced to the PC via a 16-bit parallel I/O board (for details on the type of board to use, and the wiring requirements, see Technical Notes in Appendix. A). Both DM and DMTG poll this device every msec, and a software debounce is provided.

For each job, five input channels are available. These are defined in the following way:

Channel 1: Request for display

Channel 2: Negative response

Channel 3: Positive response

Channel 4: Pulse from tape recorder

Channel 5: Pulse from voice-operated switch (VOX) for vocal naming

If a parallel I/O board is not available, then the standard Centronics printer port can be used, although you are now limited to just three inputs. Alternatively, a Mouse could be used, although this may lead to error in the estimation of RTs.

Another option is to use the keyboard as the response device. In this case, the space bar acts as a request signal, the right-hand shift key acts as a positive response, and the left-hand shift key acts as a negative response.

These hardware options are not all available in the one program. That is, if you want to change options, then a new version of the program must be obtained.

Naming conventions for DM/DMTG programs.

The convention is that certain options are treated as default conditions, and hence are not mentioned in the name. The default conditions are:

Single screen

PIO input

Video interrupt

Single job

The name is composed of up to 6 segments, each segment specifying an option. The letter(s) chosen to designate an option are followed here by an underscore, but the underscore should not be included in the name, unless it is the case that the default values are adopted for all options. The default conditions are indicated in parentheses, and should not be specified.

(a) DM_ or DMTG_ (one or the other must be specified)

(b) Type of display: E_xperimenter screen as well as subject screen (otherwise, single screen)

(c) Response input type: K_eyboard, M_ouse (Microsoft), C_entronics printer port, (default: PIO board)

(d) Number of jobs: 2_, 3_, 4_, (default: 1)

(e) Multichrome capability: C_olors, more than 2, (default: 2 colors only)

Thus, DME means a dual screen, PIO, video interrupt, single job, monochrome display. If the single screen version was selected (i.e., defaults selected throughout), then the name would be 'DM_'.

DMK means a single screen display with video interrupt and keyboard input .

A DM program that had a single screen, with video interrupt, PIO input and four jobs would have the name DM4.

It is assumed that individual labs will not attempt to maintain these distinctions in everyday testing situations. That is, the programs in 'c:\bin\dm' that actually run the experiments will always be called 'DM' and 'DMTG', no matter what version they might be. It is for this reason that we have used the underscore in the names for the default versions, i.e., 'DM_' and 'DMTG_'.


The following is a brief guide to the steps required to run an experiment on the DMASTR system. For further details, consult later sections of this manual.

To run an experiment, you need to construct two files. The first is called an ITEM file (the extension of the filename is always ITM, e.g., EXP1.ITM), and this contains the actual materials to be displayed to the subject, along with special characters that control how they are to be displayed. The second file is a DATA file. This should have the same filename as the item file, but with the extension DAT, e.g., EXP1.DAT. This file contains a description of the design of the experiment, e.g., the number of conditions, the number of items in each condition, which items belong to which conditions, etc. It will eventually also contain the raw data from each subject, plus a summary of the means for each subject in each condition (averaged over items), and the means for each item in each condition (averaged over the subjects).

After you have decided what items you are going to use in the experiment, you should assign each item an item number. It is a good idea to number the items consecutively in each condition. For example:

Condition 1: items 1-15

Condition 2: items 21-35

Condition 3: items 41-55

In general, it is helpful (but not essential) to give the first item in each condition a number ending in 1.

Items that require the subject to respond YES should be given a positive sign, while items that require a NO response have a minus sign (e.g., -025).

Prepare a list of all the items to be given to a given subject in the following sequence:

First item in first condition

First item in second condition

First item in third condition (and so on)


Second item in first condition

Second item in second condition (etc.)


Last item in first condition

Last item in second condition (etc.)

Last item in last condition.

Normally, there is a limit of 255 on the number of items. Except under special circumstances, no item can be given a number greater than 255. It is customary to give all practice items the same number (250), but again, this is not essential.

Apart from the special case of practice items, no two items should be given the same number. The reason is that DMASTR will record a response only for the most recently presented item. Note also that the sign placed in front of the number (indicating the correct response) does not change the item number -- i.e., +25 and -25 count as the same number.


The item file can be constructed on any word-processor, provided that it is in non-document mode. We assume here either WordStar or CL (a local version of WordStar written by Mike Durham).

An item is divided up into a number of "frames". The symbol indicating the end of a frame is "/". All characters within a single frame are displayed simultaneously. Characters in the next frame will not be displayed until some later point in time.

Initially, all you need to type in is the item number (followed by a space), the characters to be displayed (enclosed in quotation marks), the end-of-frame markers, a special symbol ("*") indicating which is the target frame (the frame that the subject must respond to), and finally, a special symbol (";") to indicate the end of the item. For example:

+001 "doctor"/*"HOUSE"/;

+021 "fish"/*"MOUSE"/;

-031 "steer"/*"NORN"/;

The symbol "*" indicates the target frame, and ";" indicates the end of the item. Although not indicated above, each line has of course been terminated by <cr>. This is not a critical feature, since <cr> is ignored. Note also that there is nothing between the final "/" and the ";". This is equivalent to a blank frame, as in:

+001 "doctor"/*"HOUSE"/"";

Since each frame erases the frame that came before it, this blank frame merely serves to erase the previous frame. Otherwise, "HOUSE" would remain on the screen until the subject requested the next item.

Two additional lines now need to be added. The first line of each item file is called the parameter line, and contains various parameters prefixed by a lower-case letter. These specify properties of the item file, such as the number of items, the duration of each frame in ticks, the method of display to be used. For example:

n43 m17 f25

These parameters specify that there are 43 items in the experiment (including the practice items), to be displayed with the method of display designated by the number 17, and where each frame duration is 25 ticks unless otherwise specified. These parameters are defined and explained in Sec. 3.

The second line that needs to be added goes at the very end of the item file, and carries a message to the subject that the experiment has ended. For example:

0 L"That's the end -- thank you.";

The fact that the item number is zero means that this is just an instruction. The "L" signifies that this is the last frame in the item file.


It is most important to choose a filename that is unique for each experiment. If MS-DOS is asked to write a file to disk, it will first erase any other files which have the same name. Since the data generated by each subject will have the same filename as the item file (but a different extension), problems will arise if several experiments have the same filename.

The filename can have up to 8 letters. The recommended structure for an experiment name is as follows:

(a) the initials of the experimenter (two letters)

(b) up to four letters designating the general topic

(c) a number indicating which experiment in the series

(d) a letter indicating which file (if more then one).

For example, if Bill Smith is running his third experiment in a series of experiments studying the frequency effect, and the experiment involves two counterbalanced sets of items, then the item file name for the first of these sets might be "BSFQ3A.ITM", and the second might be named "BSFQ3B.ITM".

Note that for each item file, there must be a corresponding data file with the same name, e.g., "BSFQ3A.DAT" and "BSFQ3B.DAT".


After the item file has been entered, you should use the utility program ICHECK to check the syntax of the file. The command is:

ICHECK <filename>

The output consists of a list of errors and an attempted diagnosis of the reason or the error.


After you have finished constructing the item file, the next step is to construct a data file. This is done by running the program DATMAK (for details, see Section 6). For the moment, we will merely indicate what goes into a data file.

Each item file has a corresponding data file. In this file is located a short description of the purpose of the experiment, specification of the number of conditions, the number of items in each condition, the item numbers for each condition plus a number of instructions on how the data are to be analyzed.

After you have run each subject, the data for that subject are added to the data file. In addition, the data file contains a running update of the mean RTs and errors for each subject in each condition, and for each item. The data file is stored on your own disk, along with your item files.


Location of ITM file.

To run an experiment, a copy of your item file must be stored on drive C of the display computer in the current directory. This would normally be your own directory on drive C. Under special circumstances, you might want to run an item file from a different drive without logging onto that drive.

Display Type

There are several different display types possible with DM/DMTG, and the precise instructions for running the program depend on which display type you have. The two types are as follows:

1. Dual-screen display. The experimental items are displayed on the color screen for the subject, and the experimenter has a separate monochrome display which is divided into two windows. Possible commands are listed in the upper window, along with prompts for commands. A copy of the item being displayed to the subject, and the subject's response is displayed in the lower window. This option applies to both DM and DMTG.

2. Single-screen display. If there is no separate display for the experimenter, then the experimenter's commands are echoed on the top line of the screen. No menu or prompts are provided.

The following summary of commands assumes a single-screen version. The dual-screen system differs in that the user is prompted separately for each of the constituents of a command.

Keyboard Commands.

(a) Getting a job (G).

The DMASTR System permits up to four experiments ("jobs") to be run at once. Your first task is to get an available job assigned to you. The general format for this command is:

G<job number><password><filename>

(the angled brackets should not be typed -- they merely indicate the structure of the command).

If you are running a single-job version of DM/DMTG, then the job-number is always 1. This may be omitted.

The password serves to identify you as the originator of this job, and must be used in all job-related commands. Usually, experimenters use their initials as a password.

The filename is the name of the item file that you wish to run.

So, suppose also that your initials are BS and that the file you wish to run is BSFQ1A.ITM. The necessary command is:


If you were using a multi-job version, and you wished to get job number 2, then the command would be:


The program should now respond "Getting file -- Wait", and when this is completed, it will display "Experiment Ready" on the display screen.

Other possible responses are:

?No File? This means your item file can't be found. Try again, in case you typed the file name incorrectly.

?Job not free? This means somebody else is using that job. Try another job.

After you have successfully loaded your job, you should load your subject into the appropriate booth, having read the instructions to him/her, and having made sure that he/she knows what to do (e.g., which buttons to press, and how to use the footswitch).

The experiment now should run itself.

Note: The only difference for the dual-screen version is that you are prompted for each of the three elements of the command.

(b) Stopping a job (S).

When the experiment has finished, you need to save the data. This is achieved by typing the "S" command.

The general format for this command is:

S<job number, if necessary><password>

To take our example from above:


or, if we were using a multi-job version:


If all goes well, DMASTR will respond with "Job Stopped". But instead, you may get the following messages:

?Job not finished? The subject has not finished the experiment.

?Bad password? The password does not match those of the person who got the job. This means either you have mistyped the password, or you have tried to stop the wrong job.

This command creates a file in the current directory of drive C containing the RT data in binary format. This file has the same file name as the item file, but with the extension "DTP" -- meaning "temporary data file". If such a file already exists (i.e., you have saved the data from more than one subject), then the RT data from this subject is added to the end of the previous file.

(c) Aborting a job (A).

If something went wrong during the experiment, and you do not wish to save the data from the experiment (or you were just trying it out), then the ABORT command is used. This is given by the command "A":

A<job number, if necessary><password>

Once again, the password has to be given (this prevents somebody else accidentally aborting your experiment).

So, the command for the above example would be:


or, in the multi-job case,


(d) Transferring an item file (T).

As mentioned earlier, item files need to be stored on drive C. If the display program is already running, and you wish to transfer a new item file onto drive C without stopping the program, then place a disk with the item file in drive A, and type the following command:


No password is necessary.

DM/DMTG will then ask whether your disk is in drive A, and if it is, you should respond by typing "Y". If it isn't, then either put it in and type "Y", or type "N" to cancel the request. DM/DMTG will then copy the file onto drive C. This command is really intended for the multi-job versions of DM, where jobs may already be running for other experimenters.

(e) Unloading data (U).

Recall that the "S" command saves your data in a "DTP" file in the current directory of drive C (extending the file as each new subject is run). When you want to analyze the results, you need to unload the accumulated data to a floppy disk, which is then transferred to another machine for analysis. The unload command achieves this.

First place a disk in drive A. Then issue the command:


No password is required. DMASTR will then respond:


If the answer is "Yes", type "Y". DMASTR will then copy the DTP file across to drive A (adding it to any existing DTP file with the same filename). If the answer is "No", then insert your disk in drive A and type "Y". Responding "N" will simply cancel the request.

If you have DTP files from several versions of the same basic experiment, then it is more efficient to use a wildcard. For example:


will unload any DTP files on drive C with the names bsfq1a.dtp, bsfq1b.dtp, bsfq1c.dtp, etc.

Alternatively, you could simply type:


which will copy all DTP files with a filename beginning with "bs".

There is also a stand-alone utility program called "UNLOAD" which works in exactly the same way. In this case, your data disk is inserted in drive A as before, but you now issue the following command to the DOS prompt, not DMASTR:

UNLOAD bsexp1*

(f) Skipping an item (X).

This command is used while a job is running, and has the effect of skipping the next item to be displayed. This is intended for use in experiments where the DMASTR display must be synchronised with some external device, such as a tape recorder.

The command requires a password, and has the form:

X<job number, if necessary><password>

In DMTG, the user is prompted for this information.

(g) Halt (H) and Resume (R).

If it is necessary to temporarily prevent the experiment from proceeding any further, then the "halt" command is used, which has the form:

H<job number, if necessary><password>

After the current item has been responded to, the job will freeze. The experiment can then be continued using the "resume" command:

R<job number, if necessary><password>

Note: Automatic repeat of file input name.

Control R works as in WordStar for G, T, and U commands in DM and DMTG. That is, the most recently specified filename can be reinstated by typing control R.

Note: Command line control of DM/DMTG

( only for DM Ver 2.57 and DMTG ver 5.10 and higher )

It is possible to run DM/DMTG with an item file specified on the command line (i.e., at the DOS prompt). For example:

DMTG exp1

will run DMTG with the ITM file 'exp1.itm' (passwords will be ignored). If the experiment terminates normally, the data will automatically be saved, and the program will terminate.


To analyze the results of the experiment, it is necessary to run the program UPDATE. This attaches the DTP file to your DAT file, and then calculates the mean RTs in each condition for both a subject-based analysis and an item-based analysis.

First, insert your disk (containing your DAT file, as well as the DTP file) in drive A.

Next, type the following command:


This program will now tell you what to do. Basically, all you have to do is to respond "Y" (yes) or "N" (no). For further details see section 8.

When UPDATE terminates, it creates two files. One is simply a copy of the original DTP file on drive C, only now it has the extension RDB, which means "raw data backup". Each time you update, any existing RDB file with the same filename is erased, so this provides a backup only of the most recently updated DTP file. The other file is also located on drive C, and has the extension DBK. This file is a backup copy of the existing DAT file on your floppy disk in drive A.


(a) Prepare a list of items, arranged in the correct order.

(b) Type up your item file, using a word processor in non-document mode.

(c) Have your item files transferred to drive C.

(d) Construct a DAT file for each item file using DATMAK.

(e) Run a trial version of experiment on yourself to check that the experiment runs correctly.

(f) Run ISUM (see section 7) to make sure that all items are present and in the correct conditions.

(g) Run the subjects.

(h) Unload the DTP file to a floppy disk.

(i) Run UPDATE to incorporate the data onto your DAT file.


ITM: item file

DAT: data file

DTP: temporary data file written to drive C

DBK: a backup copy of DAT file created by UPDATE on drive C.

RDB: a backup copy on drive C of the last DTP file unloaded.

ISM: a disk copy of the output from ISUM (see sect. 7)

DAS: an ASCII file giving the mean RTs and error rates of each subject and/or item in each condition (this is generated by the CONCAT program, see sect. 9).

ISM: summary file generated by ISUM

CHR: character or font file for DMTG


Location. These programs would all normally be located in the directory c:\bin\dm. However, they could be located in any other directory, provided that directory is included in the PATH statement.

However, all CHR files and the file EGAVGA.BGI must be located in a directory c:\bin\dm if you wish to use DMTG.

Display Programs

DM text-mode item display program (multiple-job)

DMTG graphics-mode item display (single-job only)

Item-file Construction Utilities

CL WordStar look-alike editor operating in non-document mode, with some extra features -- used for constructing item files

ICHECK syntax checker for ITM files -- used to locate errors in the item file (see Sec. 11)

FRAME a frame-oriented ITM file editor (see Sec. 11)

ILEAVE an interleaving program for ITM files -- rearranges the order of items in a structured manner (see Sec. 11)

INUM generates lists of item numbers (see Sec. 11)

BSCRAM randomly scrambles the order of items

ISELECT randomly selects a specified number of items from a larger list of items (see Sec. 11)

Data Analysis Utilities

DATMAK used for constructing DAT files

UPDATE incorporates DTP files into DAT files and computes subject and item mean RTs and error rates in each condition

UPD.BAT contains complete output from UPDATE (useful on the network)

UNLOAD transfers DTP files from drive C to DAT files on drive A, using wild-card filenames

ISUM outputs a summary of performance on each item, arranged by conditions

ISUMM.BAT contains output from ISUM (useful on the network)

CONCAT outputs means in selected conditions from DAT file in ASCII format; output file (a DAS file) is suitable for input to standard statistical routines

PQRAOV a three way ANOVA program suitable for DAS files

FILE an editor for files in binary format (e.g., DAT files)

HIST histogram plotter

MINF minF' calculation

DASFILE performs statistical comparisons (t-test, correlation) on conditions in DAS files

DASCONV converts DAS files into appropriate format for the Perlman statistical package

Graphics Utilities

SNAPSHOT A graphics screen capture program

EDTSCR Converts output from SNAPSHOT to DMTG format

M_EDTSCR Converts output from SNAPSHOT to DMTGC format (multichrome images)