Why is a Windows system necessary?
New Features You Need to Know About.
Why is a Windows system necessary?
New Features You Need to Know About.
The new Windows 95/98 version of DMASTR has now been released. For some months now, colleagues here at the University of Arizona, at the Cognition and Brain Sciences Research Unit in Cambridge, at Cambridge University, and at other sites have been testing the pre-release versions, and most of the serious bugs now appear to have been eliminated. It should be noted that none of these bugs compromised the accuracy of measurement of RTs, or of the timing of the displays. Instead, they tended to be the type that totally prevented a script from running at all. (This is meant to be reassuring; far better that a script not run at all than to give misleading results.)
Users of a DOS-based DMASTR system are locked in to aging hardware and software. Given how quickly the technology changes, it will become more and more difficult to maintain old equipment. Even today, it is getting harder to locate monochrome monitors (required for DOS-based DMASTR running on dual screens). Also, users of the sound system are forced to use a specific speech editing system (BLISS) that works only with a limited range of sound cards, many of which are now defunct. However, with Windows-based DMDX, we have access to Windows device drivers, so that any device that works with Windows will work with DMDX.
The switch to a Windows system has a number of advantages. First and foremost, we are not limited to the EGA video mode imposed by the Borland graphics interface. Instead, the full range of video modes can be used. Any Windows font can be used, and you can display Windows bit-mapped image (.bmp) files. Further, one is free to select any type of sound card, so long as it has drivers that work with Windows (which is certain, otherwise the manufacturers wouldn't be able to sell them). One can use any speech editor, so long as it works with Windows (i.e., generates .wav files). One can use the keyboard, the mouse, a joystick or a game pad as an input device, along with the familiar PIO 12 card that we've used all along. One can also use digital video displays, streaming audio and video (for very large files).
How is this flexibility achieved?
DMDX uses DirectX (this is provided with later versions of Windows 95 and all versions of Windows 98). This software gives the Windows programmer better access to the actual hardware, which is essential for accurate timing. The main purpose of DirectX is for game-playing, which places very high demands on the responsiveness of the system. If you don't have DirectX on your computer (it would be in a folder called c:\Program Files\DirectX), then you can download it from the DMDX site, or from Microsoft.
It is generally believed that it is virtually impossible in a Windows program to get accurate timing of displays, or accurate measurement of reaction times. This is true for applications that do not make use of DirectX, but not for DMDX. However, this is not to deny that Windows still manages to get in the way every now and again.
The major problem concerns timing of displays. Occasionally, Windows will interrupt DMDX just as it is about to perform some time-critical task. We cannot prevent Windows from doing this, and we cannot predict when it is likely to happen. To cope with this, DMDX is designed so that it can detect when it was interrupted, and it can recover from such interruptions in the vast majority of cases.
How is this possible? In order to control display timing accurately, DMDX must keep track of how many screen refreshes have occurred since the last display. This involves monitoring a particular register to see when the refresh occurs. The signal that indicates this is very brief, so DMDX must go into a tight loop in order to detect it. However, sometimes Windows will interrupt just before a refresh occurs, and by the time DMDX gets control back, the refresh may already have occurred.
But all is not lost, since DMDX has access (on Pentiums) to a High Performance Timer, which keeps excellent time (accurate to within a microsecond), no matter what Windows is doing (i.e. it is uninterruptable). So if DMDX knows the refresh rate you are using, it can easily determine whether it missed a refresh signal, and can keep track of how many retraces must have occurred. But if it is interrupted just before the critical retrace occurs (i.e., when the next frame has to be displayed), then a display error will occur. By the time DMDX gets control back, as much as three or four screen refreshes may have taken place. Thus it is impossible to recover. DMDX nevertheless goes ahead and displays the frame, even though it is being displayed late.
In many applications, this will not be critical. It will simply mean that for example, one frame was displayed for 75 ticks instead of 72. But in applications where the inter-stimulus interval is critical, this will be important (note that the frame that is displayed late affects the duration of the previous frame, but not subsequent frames). However, the output file will contain a note to the effect that a frame was displayed late, along with the item number, and a statement of which frame was displayed late. The data from that trial can then be discarded, if you so desire.
Another possible disadvantage is that it may not be possible to program the refresh rate of the subject's display as precisely as was possible with DMTG. TimeDX (a sister-program to DMDX) includes an option which allows you to change the number of lines displayed on the screen (as in DMTG), but unfortunately, this only changes the Primary display. If you are using a single monitor system, this is fine (this includes dual displays using a video splitter, since this is really a single display system), but if you are using a dual monitor display (the MultiMonitor option), then the Primary display is going to be the experimenter's display, since it will be associated with the keyboard. The subject's display is the Secondary monitor, and this will be unchanged. Of course, if the subject views the Primary display (i.e., sits at the keyboard), then there is no problem.
Some limited control of the refresh rate of the Secondary display is possible by selecting different video modes (i.e. resolutions). TimeDX will let you know what refresh rates are available. Note that some graphics cards will permit very high refresh rates with some monitors. We have heard of one system that gets as low as 8 ms.
It should be noted that these timing problems relate to the timing of displays, not the measurement of RTs. Theoretically, similar considerations should apply here, although we have been unable to detect such errors when measuring against an external clock. These errors probably exist, but have a very low probability of occurrence, and probably amount to no more than 2 or 3 ms. (DMDX comes equipped with several test modes, which enable the user to check the accuracy of timing -- see Test Modes 2 and 3 in the DMDX Help file). Display timing errors will occur more frequently if you have other background programs running, but will occur less often with faster machines. In any event, you should make sure that any machine running actual experiments does not have any other background programs running.
On-line Help File. First, there is now an on-line Help file, accessed from the DMDX dialogue box. In time, there will also be supplementary notes written as an .html document.
TimeDX. DMDX will not run until you have run TimeDX. This program is designed to establish the properties of your machine (graphics resolution, refresh rates, type of sound card, presence of PIO card, etc.), and to record these in the Windows Registry, so that DMDX will know what kind of machine it is running on. TimeDX also has its own Help file.
Standard file formats. DMDX uses standard Windows formats: .bmp files for graphics, .wav files for sound files. In addition, digital video is also supported (including the ability to measure RTs to critical frames within such displays). Streaming video and/or audio can also be used for off-line situations, such as presentation of contexts, instructions, etc.
Output Files. The default output mode is now an .AZK file (a text file listing item number and RT in the order presented to the subject, plus warning messages about display timing errors). The assumption is that users will feed this output into an application such as Excel for future processing. However, users can still use the .dtp output option.
Input File. The old .itm file has been replaced by an .rtf (rich text) file. These can be produced by any Microsoft Word for Windows program, also by Write and WordPad.
WYSIWYG. Manipulations of the appearance of text within the .rtf file will be transferred to DMDX. So, if the text appears as red in the .rtf file, it will appear as red on the display screen. If it is in 10 point in the .rtf file, it will be 10 point on the screen.
Switches and Parameters. Instead of having a single character as the first element of a switch or parameter, DMDX allows for any number of characters, e.g., <NoFeedback>. Note the use of angled brackets. These are referred to as "Keywords" in the Help files, and a complete listing is available there.
We now have a DMDX List Serv, which users are encouraged to use. After you subscribe to this service, you may then post queries or problems or comments to this server, which will be distributed to everyone on the list. Anyone who knows the answer may then post a reply. That way, knowledge is accumulated and distributed. For details about subscribing and unsubscribing, click here.
A manual will be written at some stage. Much of the material from the DOS-based DM/DMTG manual is still relevant, however.
Jonathan has written a very comprehensive on-line Help system for both DMDX and its sister-program TimeDX. Click the Help button when you run either of these programs.
Queries should be sent to the DMDX List Serv, not Jonathan.
Thanks to the efforts of Mike Ford and Matt Davis at the Cognition and Brain Sciences Research Unit in Cambridge, we have an excellent introduction to DMDX available on the Web.
We all owe a tremendous debt to Jonathan Forster, who took on the task of taming Windows single-handed. I doubt whether any software package can duplicate the range of options available in this system, and as Bill Gates said, you can't beat the price.
In addition, none of this would have been possible without the facilities and support of the Department of Psychology at the University of Arizona.
Thanks also to John Allen, Jeff Bowers, Matthew Chung, Matt Davis, Zia Dikman, Mike Ford, Gareth Gaskell, Michael Johnston, Ralph Mertens, Dennis Norris, Mary Peterson, David Schnyer and other trusting souls who committed themselves to DMDX during the teething stage.
Prepared by Kenneth Forster
Last Updated: July 31, 1999