back to the main page


search the CNL site


links to information for neuroimagers and visitors to Tucson

Useful DMDX Links:

DMDX related Tools and Tricks

Other Free Presentation Programs:

Getting Started

From the Official DMDX page, download and unzip the most recent version of DMDX. You may find it useful to make shortcuts to DMDX and TimeDX, since they don't install themselves in the start menu. If DMDX complains about not finding a registry key associated with video settings, run the TimeDX "Time Video Mode" and choose "Save Last Value in Registry". You may need to run several TimeDX tests before DMDX will work properly. DMDX comes with help files, the "Keyword" help to be particularly useful.

Write your DMDX programs in Word or Wordpad. All programs should be saved as rtf (rich text format) files. If you have trouble with programs saved in Word, reopen them in Wordpad and save them. Programs consist of two parts: 1) the extended parameters on the first line that tell DMDX general characteristics of the program, and 2) the items to be presented. Here is a very simple program:

F500 <cr>
1 "Hello World"/;

Here are what the parts of the program mean:
rame length=500 ticks,
continuous run,
item "1",
display "Hello World", (by default, black letters on a white background)
"/" ends the frame (after 500 ticks),
";" ends the item

The MR3 Scanner Mice

One of the things you'll need to know to save mouse press information for subjects at the scanner is that particular codes correspond to particular mouse buttons on the two mice at the scanner, like so (this is how it works for DMDX anyhow):

Start the Scanner with DMDX in 3 Easy Steps

As we undergo hardware and software changes at the scanner, ...and as people experiment, we learn more. Special thanks goes to Shioahui Chan who spent a lot of time and effort figuring out what happens and why). 1) Add 2 Lines (shown in red, below) of code to your DMDX program. These should, of course precede any items that will be part of the experiment.

<ep> F118 d5<ContinuousRun> <RecordClockOnTime> <nfb> <AzkiiResponses> <dfs 80> <bgc 000000000> <writingcolor 000255000> <zillion> <id "keyboard"> <id pio12> <eop>

0 "READY?" ;
100 <Output 254> c;
101 <o 255> %1 / <o 254>/ "READY?" <ms% 4000>/;

1001 * + "XXX";

The parameter line (in black at the top) has several standard DMDX specifications. The only critical parameter is probably that you use continuous run " <ContinuousRun> or <cr> ".

The first item line (in black) (0 "READY?" ;) is used to just have something on the screen when you first press RUN on DMDX. The screen will be displayed until you can press the space bar to start the experiment.

Lines 100 & 101 trigger the start of the scanner, followed immediately by another "READY?" screen which will stay on for the specified number of milliseconds (ms% = set milliseconds for this frame duration), in this case 4 seconds (2 TRs). Test the timing to make sure you have a blank or "Ready" (as in this example) set to stay on for the correct number of TRs.

Experimenters should not begin to collect data during at least the first 5 TRs. The scanner starts at item 100.

The scanner is triggered by the <Output 254> statement (also written <o 254>). It turns out not to be necessary to have the "254" statement in there twice (at least, not for the 3T as of February 2006). It may be necessary with different hardware, so always try before you commit. It apparently doesn't hurt anything to have it in there twice...but the second command is ignored.

The "c" in item 100 means "continuous run". It seems not to be necessary as long as "continuous run" was already specified in the parameter line at the head of the file (so, we really don't need it in our example, because we have <ContinuousRun> in our parameter line).

<o 255> sends an "inactive" signal to attached hardware. <0 255> will not start the scanner. In fact, <o 255> appears to be unnecessary.

In item 101, the order of the parameters <o 255> and <o 254> did not appear to matter. The scanner always started with <o 254>.

In sum, if you keep both lines, you should understand that the scanner is triggered at line 100, NOT 101.

You could trigger the 3T scanner (at least) with either of the following single line commands, instead of the red 2 line command above:

+100 * <t 0> <Output 254> c;




+101 <o 255> %1 / *<o 254>%1/ "READY?" <fd 724>/;


or, probably even:


+101 *<o 254>%1/ "READY?" <fd 724>/;


If you use line 100, the time out parameter <t 0> makes the item disappear as quickly as possible. So, use this line to trigger the scanner immediately with no delay (or as close as you can get to no delay).


If you use line 101, note that it has been altered from our original command to wait for 12 seconds <fd 724> (frame duration 724 in ticks-which corresponds to about 12 seconds on Pharaoh) instead of 4 seconds. We have added the * so that DMDX COT will be synchronized with the scanner. %1 is a frame duration of one tick (if left unspecified, frame duration will correspond to your default (which may be pretty long).

The last line is a sample stimulus. The rest of the experiment would follow as usual.

2) The black BNC cable (marked "TO MRI TTL", and coiled on the floor near the patch panel, on the side opposite the computers) from the MRI computer gets plugged into the
button box BNC port labelled "To MRI TTL".

3) On the User CVs page on the MRI console, set "External Trigger" to "1" (default is "0").
This tells the scanner to wait for you to press the "Scan" button before it begins the experiment (actually, it gives you 24 seconds in which to press the "Scan" button.

Writing your DMDX programs in Excel

Some users have found it very helpful to write their DMDX programs in Excel, save the
excel file as Formatted Text (space delimited), and then open it in Wordpad, do minor editing to eliminate extra spaces, and save it as .rtf file. The key is to create item numbers so that you can sort by condition and then utilize all the useful excel copy and sorting commands to make your programming life easier. Also, it is important to have your columns wide enough to display all the text in each cell, otherwise whatever is not viewable will be lost iin the conversion to wordpad. To see such an Excel file, go here and download sample.xls.


Zil files with multiple responses are pretty complex and do not import into excel easily. To circumvent this problem we have created zilverter, a java program that will mark up a zil file (as long as you have not altered it) as xml so that you can then extract the information of interest into columns. The file includes a README.txt that explains how to install and use the program, an xsl file that extracts the data into a csv file suitable for excel, a test zil file (so you can make sure zilverter runs on your system and see what file format it expects). It also includes several jar files which you should just leave there...they are important to the process of creating xml, but you don't have to do anything to them or put them anywhere special. Just leave them in the directory with your other zilverter stuff.

Before you unzip, you should put it in a directory of its own.

Before you try to run zilverter, read the readme and install the (java runtime environment) jre 1.4.1 or later. Make sure the jre you installed is at the beginning of your path (again, see the redme for details).

You should find that you can get the whole thing installed and running in under an hour...especially if you are running on Windows 2000 or XP (which the readme assumes).

Matt Davis's awk tools

First off, you'll want to go to Matt Davis's homepage and get the tools:

Matt Davis's Homepage (and useful scripts)

You'll find two tools: gawk.exe is the Awk text-processing programming language for Windows. Put the executable in a reasonable place (Davis suggests creating a directory "bin" on your c drive and putting it in there. In addition, Davis provides a script written in the awk language and intended to reformat the DMDX azk output. The script is called getdat.awk. Put it in the directory with gawk.exe. Davis provides an example of how his awk script reformats the data on his page. He also provides instructions on how to run the script by right clicking your azk file and choosing "convert to text"...after you set up the right click option and add or change some file associations.

getdat is a nice script for formatting .azk files. However, it does not extract COTs. It is designed to format .azk files w/ multiple subjects by Subject # and then by Item # and RT. Note: COTs are not output ! If you want COTs output, run getdat_with_rcot.

We found the following just as easy (easier?) as we had some trouble setting up the right click options under Windows XP.

Extract Zip file to desktop.

Create folder for getdat, getdat_with_rcot & gawk (I created a folder called 'bin' on the C drive: C:/bin).

Move gawk and getdat into C:/bin.

Move your .azk file to C:/bin

To launch command prompt: Start Menu->All programs->accessories->command prompt

In command prompt window move to your directory where your .azk files and getdat & gawk are located.
>C: <enter>
>cd bin
>dir (command for examining contents of the folder/directory-your files should be listed)
>gawk.exe -f getdat.awk "test.azk"

This produces test.txt in the same directory with only the RT data for each subject. This should be a nicely formatted file that can be opened using Excel.
>gawk.exe -f getdat_with_rcot.awk "test.azk"
This produces test.txt in the same directory with the RT AND COT data for each subject. This should be a nicely formatted file that can be opened using Excel.