DMDX Help.

Interfacing Issues Overview.

    DMDX can interface with other computers or equipment with the addition of a parallel input/output interface card (PIO for short) or over the network using a TCP/IP socket as of version with the tcpip input device.  It can also interface with other custom written software by signaling an event, here we mostly deal with the hardware solutions however.  It can send a set of signals at a maximum rate of once per retrace, it can receive signal onsets as part of it's normal input processing.  As of version of DMDX you can now in fact use printer ports with the inpout32.dll option in the TimeDX PIO test (to use it you will first need to run InstallDriver.exe in the DMDX program folder with administrative access to install the ring 0 kernal mode driver interface for the DLL), and it could now in fact use serial ports as long as they've been set up beforehand (I leave that as an exercise for the reader).  Prior to you could already receive serial data with the addition of third party software and indeed such software is still necessary to receive serial data (not send it).  Other than that you're looking at a custom interface card, exactly which interface cards can be used depends on the operating system you are using, there being substantially less flexibility under Windows 2000, XP and later OSes rather than earlier operating systems that don't restrict low level I/O operations (unless you use the new inpout32.dll functionality), see the TimeDX PIO Test for details.  The labs in Arizona use the Measurement Computing PCI-DIO24 cards, they are cheap and their drivers function nicely.  Laptops can use the PCMCIA (or PC-CARD) version (which I can't find on their site any more, they pretty much sucked anyway) or even the USB devices, say the USB-DIO24.   You can get devices with more than 24 lines however only the first device's 24 bits of I/O are currently accessible to DMDX.

    Once you have set the card up (and if you're using the Measurement Computing stuff you need to use their InstaCal software before you use anything else) with the TimeDX PIO Test you must make DMDX use that device by declaring one of the input devices a PIO can behave as using the <InputDevice> keyword.  The first such cards were named PIO-12 cards (despite the fact that they had 24 I/O lines) so DMDX uses the name PIO12 to refer to whatever PIO card DMDX happens to be using.  The various devices primarily vary depending on how many of the I/O lines are used for input and how many for output, the original PIO12 device using 16 input lines and 8 output lines.  After that queued variations on devices exist that were added to handle issues under Windows 2000 and XP (the non-queued versions should not be used under win2K/XP).

    There are two methods that DMDX can use to output data, latched and non-latched with the default mode being latched outputs, once a word is output it stays output.  Non-latched mode can be used with the <RevertOutput> parameter where DMDX reverts the output to a specified state a specified period after the data is output.  <RevertOutput> can also be used to control the initial state of the PIO and does not also necessarily switch DMDX to non-latched mode.  Data can be output once per frame with <Output> and it's hexadecimal or counter based equivalents.  Output data can be inverted with <InvertOutput>.

    When DMDX uses the PIO for input it uses negative logic, logic 0 (0 Volts) is an active signal, logic 1 (5V) is inactive.  In order for DMDX to see signals from the PIO the DMDX octal MIP word must be set to mask off unused bits of input, the default value for this word is 7 which limits DMDX's input to the lower 3 bits of input.  Bits must also be mapped to various DMDX signals if the defaults are not usable, see the Input section.

   Note that if you need to build an interface to a Neuroscan machine there's a very technical issue that will need some special action before you start building cables due to DMDX's default use of port C for output and the Measurement Computing software splitting that into two 4 bit nibbles requiring two separate requests from DMDX and every now and then DMDX gets interrupted between them causing there to be a few microseconds between the nibbles and Neuroscan sees this as two events and gets pissy because it wants a resting state between codes. Paradoxically having added support for legacy LPT interface cards using inpout32.dll these dinosaurs in combination with a later version of DMDX ( or later) offer a superior solution to this nibble problem (see the PIO test documentation for details, to use it you will first need to run InstallDriver.exe in the DMDX program folder with administrative access to install the ring 0 kernal mode driver interface for the DLL).  Barring that you're probably going to want to use the port B bits and pio12OP16 to output 16 bits of data and only use the top 8 bits of the output word (there are ways to semi-elegantly deal with this in your item file if you get that far using counters and multipliers, for example if your original code had <op 16> some creative search and replacing can make that <set c1 = 16 * 256> <op c1> and if you have to share item files between machines that use port C and machines that use port B you could make that 256 a counter or a macro that's set to either 256 or 1 depending on whether you want to run it on a port B machine or a port C one).

DMDX Index.