Copyright 2003 Psychonomic Society, Inc. 116Behavior Research Methods, Instruments, & Computers2003, 35 (1), 116-124DMDX is a Win32 program designed to precisely timethe presentation of text, audio, graphical, and video mate-rial and to enable the measurement of reaction times (RTs)to these displays with millisecond accuracy. It representsan extension of a suite of DOS-based programs known asDMASTR, developed and tested at Monash University inAustralia over a period of 15 years, starting in 1975, by ateam including the first author, Rod Dickinson, Wayne Mur-ray, and Mike Durham. Graphics and sound capabilitieswere added in 1989 by Jonathan Forster, and the extensionto a Windows 9x platform was carried out by JonathanForster at the University of Arizona in 1997.The purpose of the present article is (1) to inform the re-search community about the existence of the software andits capabilities, (2) to provide a nontechnical explanation ofhow the software works, and (3) to answer the skepticismexpressed in some quarters about the possibility of usingthe Windows operating system in a real-time environment(see, e.g., Myors, 1999).First, a brief historical note. The DMASTR suite wasoriginally developed by the first author in 1975 for a PDP-11 computer running under RT-11. It was written in as-sembler code (MACRO) and was an interrupt-driven pro-gram that synchronized the activity of the display programwith the position of the raster in the display monitor,thereby enabling accurate measurement of the time inter-val between when the display actually appeared and whenthe subject responded to that display. The RT-11 operatingsystem gave the programmer total control over all the op-erations of the computer, so that the programmer knewprecisely when each display event occurred and when eachresponse was made by the subject. With the advent of farcheaper IBM-compatible PCs, the switch was made in 1983to a DOS-based program (DM) written in C with no lossof control over timing. This version of DMASTR was stillpurely text based. In 1989, the second author extended thesystem to include graphical displays and sound, using theBorland Turbographics C library. However, this program(DMTG) was restricted to a particular graphics format(not widely supported), a particular speech-editing system(BLISS, developed by J. Mertus at Brown University), andas a consequence, it was also limited to a narrow range ofsound cards for which BLISS drivers had been written.As MacInnes and Taylor (2001) point out, attemptingto stay with DOS means that researchers are restricted tooutdated hardware and software, a problem that becomesmore acute with each passing year. As the supply of soundcards suitable for DMTG began to dwindle (suppliersgoing out of business or completely changing the designof the card), it became clear that any new application hav-ing a life span of more than a year or two would have to bebased on the de facto Windows standard. The idea was thatif a piece of hardware worked with Windows, it would alsowork with DMASTR. In that way, we could keep abreastof new technology without having to write new device dri-vers for every new piece of hardware to come on the mar-ket. That was the goal that drove the development ofDMDX. In addition, there was the obvious benefit ofgreatly enhanced graphics. Furthermore, the fact thatDMDX was a Windows program meant that it used ac-cepted formats for fonts, image files, and sound files,which in turn gave the user a wide range of support tools.DMDX is a hybrid name. The DM in the name indicatesits lineage as part of the DMASTR system. The DX refersto DirectX, a set of DLLs (dynamic link library routines)Over the years, a number of individuals have made invaluable contri-butions to the development of the DMASTR system. They include thelate Rod Dickinson (to whose memory this paper is dedicated), MikeDurham, Wayne Murray, and Kevin Ackley. The support of the Psychol-ogy Department at the University of Arizona has also been critical, as havethe criticisms, suggestions, complaints, and requests of many colleagueswho have used DMDX. Special thanks go to Matt Davis and Mike Ford(MRC Cognition and Brain Sciences Unit) and Anna Woollams (Mac-quarie University). Finally, the senior author expresses his profoundgratitude to the junior author for creating such a professional extensionto the DMASTR family. Correspondence concerning this article shouldbe addressed to K. I. Forster, Department of Psychology, University ofArizona, Tucson, AZ 85721 (e-mail: [email protected]. edu).DMDX:A Windows display programwith millisecond accuracyKENNETH I. FORSTER and JONATHAN C. FORSTERUniversity of Arizona, Tucson, ArizonaDMDX is a Windows-based program designed primarily for language-processing experiments. It usesthe features of Pentium class CPUs and the library routines provided in DirectX to provide accuratetiming and synchronization of visual and audio output. A brief overview of the design of the programis provided, together with the results of tests of the accuracy of timing. The Web site for downloadingthe software is given, but the source code is not available.DMDX 117that gives the Windows programmer access to the actualhardware—a development driven largely by the need toprovide a fast-action, dynamic gaming experience. WhenDMDX requires something to be displayed, it issues acommand to DirectX, not to Windows.DMDX runs on Win32 machines only (this rules outWindows 3.1), and DirectX should be available as part ofthe system.1Details of the earlier DOS programs (DM andDMTG) and the current version of DMDX can be foundat the DMASTR Web site (http://www.u.arizona.edu/~kforster/dmastr/dmastr.htm). Documentation for Di-rectX can be obtained by downloading the DirectX De-velopment Kit from http://www.microsoft.com/directx/download.asp. However, users of DMDX do not requirean understanding of DirectX.Timing Problems With aMultitasking Operating SystemThe problem with asking Windows to do something ata specified time is that Windows is a multitasking envi-ronment. There may be other applications running thathave a higher priority, and hence, the operating systemwill not always carry out an operation whenever it is re-quested. Even if there are no other applications running(something that we insist on for accurate timing inDMDX), the Windows kernel may still interrupt the exe-cution of DMDX to determine whether any other taskneeds to be serviced. These tasks may include such thingsas