You might want to try the DMDX mailing list. The idea is that if
someone is having trouble they can post to the list instead of mailing Ken
(and him then coming and bugging me) and if someone other than us has solved
the problem they can perhaps provide the answer. If you want to be on it:
1. Send a message to email@example.com from the address you want to
subscribe to the list. 2. In the subject line of your message, type in:
subscribe dmdx Firstname Name (replace 'Firstname Name' by your own first name
DMDX is the successor to DMTG and DM before it.
It moves Dmastr on to state of the art hardware running under some implementation
of Win32, currently including Windows XP
(with DirectX 9), Windows 7 (recommended) or Windows 8. There
are no Macintosh or Lunix versions of DMDX, nor are any versions planned. Windows
95 support has been dropped and is only available in the archived 2.9.05 version.
98 was dropped in version 5 so you'll need the archived 184.108.40.206 version.
Win32 is chosen as aside from the fact that it appears
to be the only direction to go in, it would appear to have some longevity, it being
the core of routines that Micro$oft are building several operating systems around
-- so when the next OS gets built I shouldn't have to do anything, or if I do it
shouldn't be very much. DirectX is the standard that allows access
to the hardware with as little intervening OS stuff as possible and it is now the
layer that Win32 uses to communicate with the hardware itself.
The actual hardware that this all runs on was not
any panty waisted machine, not by 1997's standards anyway -- most 1998 boxes were
adequately equipped however and anything you buy these days is fine. The catch with DirectX
is that each vendor of hardware must provide DirectX drivers and DirectX is only
as good as the drivers for the given device. This means that if DMDX is
behaving poorly you have to find the webpages of the builders of your sound and video cards and get the latest DirectX drivers.
If you are using brand spanking new hardware or a new OS often the drivers that
come with them are overly conservative and getting the latest drivers from the
vendor rarely hurts and will almost always fix DMDX if it is behaving oddly.
To facilitate figuring out how given hardware is
supported by DirectX the TimeDX program determines the capabilities of the DirectX
components available. TimeDX (like TimeG before it) was the test
bed that the individual components of DMDX were built and tested in before rolling
them all together into an usable program.
Q. How accurate is the response timing?
A. For those people concerned about MYORS in Behavior Research Methods, Instruments and Computers 1999, 31 (2), 322-328
I built some new test hardware that produces a electronic switch closure every 524.3ms
(a 2.000MHz crystal divided by 2 to the 20th power) and using Test Mode 8 (which
simply records the time between response signals) with a single post target mask
the following results were obtained:
PIO12 values are:
Version 1 results:
526 46 Mean 524.4ms
572 sd 0.843ms
Version 2 results:
PIO12 values with an 11025KHz 16 bit wave file playing:
Instacal QPIO12 values with at twice the closure rate:
Version 3 results:
263.1 1 Mean 262.13ms
1144 sd 0.47ms
Test machine for the Version 1 results was an AMD-K6
300 with a Riva 128 4M video card and 64Meg of RAM under Windows 98.
Test machine for the Version 2 results is a Celeron 400 multi-monitor system with
a Riva TNT 16M primary display and a S3 Virge GX 4M secondary display, the secondary
display being used as the subject's display with 128MB of RAM under Windows 98SE.
Test machine for the Version 3 results was an Athlon 1700+ with NVIDIA GeForce 4MX
video card with 512MB of RAM under Windows XP. As you can see
the standard deviations are nothing like Moyors' ~16ms under Windows 95 -- which
just goes to show that if you are going to test an operating system then writing
code specific to that operating system will yield much better results than writing
code for another operating system (DOS) that the operating system you are testing
provides backwards compatibility for.
The standard deviation for the keyboard is as high
as it is due to the standard keyboard polling effect that is part of all keyboard
hardware and is unavoidable and is also the reason the keyboard should never be
used as an input device, Moyors' test uses the keyboard auto-repeat as a signal
generator and not as a real response device as we are using it (we cannot use the
keyboard auto-repeat as a signal generator as DirectX filters auto-repeat codes,
we have to repeatedly generate keystrokes instead and thus incur the keyboard timing
I had high hopes for the Microsoft USB IntelliMouse
as a low error input device but as results show, it's lackluster.
Interestingly enough using test mode 9 that is designed
to be used with a phototransistor triggering off the display (it just stores positive
RTs), over one hundred trials with a PIO-12 on the third test setup produces a standard
deviation of 0.29ms, almost exactly millisecond accurate timing, substantially better
than the test mode 8 results would indicate. The trouble with
test mode 8 is that it measures two variabilities, the beginning and the end of
each period, test mode 9 however knows pretty much to the microsecond when the retrace
began so it's variability is substantially lower:
Instacal QPIO12 values, refresh 11.76ms, trigger after 10 frames Version 3 results:
Q. Does it work with future operating systems?
A. It might, but as we found out with Windows 8's release, there's a
chance it will do poor things so we had to write a new renderer to handle that.
Q. Will it support old Item Files?
A. Yes, it's Dmastr, it wouldn't be Dmastr unless
it read those horrible old inscrutable scripts. That is not to
say that the ITM file structure will not have new things added to it, easier
alternative methods for doing things and so on. For instance,
the way fonts are specified is different as TT Fonts are another ball park compared
to the Borland ones, but that is not to say that results similar to what would have
been produced with DMTG are not possible.
Things I have done with it:
RTF item Files. In order to smooth the
use of different fonts that contain extended character sets it occurred to me
that the item file is going to have to have those fonts in it (no other way to
reasonably tell what the text is otherwise) which complicates things no end.
The easiest solution that I saw was to use the RTF (Rich Text File) format for
item files, meaning the .ITM file extension will probably not be usable, or long
files names could be used with names like "itemfile.itm.rtf".
This means the editor you use must produce RTF files, MS Word and the standard
WordPad both do. It also means that the font must be usable
in those editors that produce RTF files.
Matter of fact, given the power of this the old font
specification methods have been abandoned and even the pure ASCII .ITM file format
has been pretty much abandoned. If people want to use old item
files they'll have to save them as an RTF file (no big deal) and if the file contained
font manipulation stuff this is going to require re-working any way.
Using the RTF file enables usage of bold, italic, COLOR, multiple fonts and styles
and colors all within a single frame -- no hassle, there in the item file, as
close to WYSIWYG as we're gonna get any time soon.
Sound. The VM extensions are long gone. What
is provided instead is a much simpler scheme of specifying when a given file is
to be played that is integrated into the regular syntax of a frame specification.
If at a later date someone needs the enhanced and exceptional control of the VM
syntax then it can be added as an additional way of specifying the position and
duration of sounds, more than likely it will be it's own separate non-display
driven program however.
Also, it uses .WAV files now, no more .ADF, no more
BLISS. A good shareware program I use is CoolEdit 96.
Palette manipulation. The V and VV switches
for palette manipulation are not going to be supported. This
is for a number of reasons, firstly the minimum color depth appears to be 256
colors (I say appears because it is possible someone will write drivers for a
video card that has support for lower depth) and the main reason these switches
exist is to overcome the limitations of 4 bit color, to use the 256 colors the
little used W switch will suddenly become the hot item. On most
machines 256 colors is no problem as far as tachistoscopic speeds are concerned,
so there is no reason not to use them (that and the fact that I haven't seen a
driver yet that supports color depths less than 256 colors).
Second, if people want to do color stuff from scanned pictures then 16 bit color
presents no major hurdle to most systems, 2 meg of video memory will be required
which is rapidly becoming the standard amount of video memory anyway, if people
want to do tachistoscopic presentation with large 16 color images then 4 meg can
be utilized. Third, from a programming point of view, writing
a program that handles both 256 color modes and 65535 colors (16 bit) is a major
pain, something I can do without -- 16 bit color does not have a palette so just
designing the thing becomes a major headache. Lastly, and most
importantly, I don't think I can build code to swap the palette around like DMTG
does. DMTG has the ability to stop everything else and just
watch for that vertical retrace, something DMDX will not have the luxury of doing,
and the palette needs to be changed immediately after the retrace -- I
don't think there's any way DMDX would be able to this (actually there is, I'm
just not going to do it, too risky). Basically the costs are
going to be that old item files that resort to extreme chicanery with the V and
VV switches won't work and if people want to do work with scanned images or any
image that uses anything other than basic Windows colors then they will have to
use 16 bit color (which means they may have to buy a better video card with 4
meg of video memory on it).
Graphics. No more .IMG
files, kiss EDTSCR goodbye, it's all Window's .BMP files now.
And, yes, I have written a converter,
I wasn't going to for the longest while as the aspect ratio has changed, all the
old images will appear squished, however DMDX has the ability to stretch bitmaps
so it makes more sense to make a converter. The converter will
however only work with monochrome .IMG files, 16 color .IMGs are still unreadable
by anything except EDTSCR.EXE.
Digital Video. Using
DirectShow DMDX can now display Digital Video files, .MPG, .AVI, Apple Quicktime,
whatever codecs you've got installed DMDX can play. It is however
going to take a fast processor and hard drive not to drop any frames (a P200MMX
isn't even close).
Audio Input. Two special
input devices interface with DirectSoundCapture, the DigitalVOX device and the
RecordVocal device. The DigitalVOX input device does away with
external electronic voice keys using a microphone and sound card instead and the
RecordVocal input device writes the subject's vocalization to disk.
Hardware Features Used by DMDX:
Multi-monitor machines. You can plug two
monitors into a lot of PCs these days and one (the primary display) can be used one for an experimenter's
display and the other for a subjects display.
GamePads and So Forth. In using DirectInput DMDX can interface to joysticks, mice and such without too
much trouble, while mice behave a bit better than standard keyboards joysticks
are an excellent alternative to installing a PIO-12 (as long as you don't want
The reason I include such information is not that
I expect people will want to use a joystick or a gamepad per se, but that these
devices are much more amenable to modification (ie, to build a regular response
box out of) than a PIO card. Not that the PIO won't be supported,
it is already, but the skill required is reduced to 'Can you operate a soldering
iron' from 'Can you read and understand a simple schematic diagram'.
All that will be required is to solder switches in parallel to existing ones,
if someone wants to get really carried away they can junk the plastic of the original
device, but this is not necessary.
Interface Cards. DMDX
can use an 8255 based interface card for input and output (usually referred to
by me as a PIO-12).
Hardware found to be Usable with DMDX:
As a general
rule all new hardware is going to work with DMDX. The exceptions are interface cards and
laptops. Interface cards will generally need modifications to DMDX to
handle new ones and laptops should be the ones that are built for gamers --
although we've seen any number of business class laptops work when audio is not
Been a long time since we saw a desktop DMDX wouldn't work with, even ones
with cruddy built in video chipsets on the motherboard work nicely these
These laptops tend to function beautifully.
Pretty much all new cards are going to work well these days.
DMDX can use an 8255 based interface card for input and output.
While it does have a counter on it you don't have to use it. Better to
buy the following card:
Computer Boards nstaCal drivers. Computer Boards
InstaCal Universal Library drivers can be used for Computer Boards interface
cards under Windows 2000 and XP etc.
Keithley cards with DriverLINX drivers. While their products
cost three times that of Computer Boards and as long as you have a mother
board that still POSTs with the Keithley card installed (anything with an ASUS
A7M266 won't) Keitheley cards under Windows 2000 and XP are usable with the
DriverLINX drivers installed (they have some kind of emulation mode of Direct
I/O for older OSes). But snakes alive are they crappy
drivers. Not only are the DriverLINX drivers 100 times slower
than the InstaCal drivers (.1ms to read the card vs .001ms) but they are fragile
as hell in a multithreaded environment (read DMDX). Be sure
you use the queued version of the DMDX input devices, QPIO12 instead of PIO12
TTFT / Flat Panel / LCD devices
The prevalence of LCD devices these
days can make purchasing a CRT rather difficult, however if you are
interested in tachistoscopic presentation rates the extra effort will
not be for waste as there are several caveats to TFT use as noted in
TimeDX documentation. Notably one has to make sure one is using
the native resolution of the display but even beyond that there are
several gotchas as some models (predominantly nicer PVA displays) have
significant lag no matter what you do. And if you really have to use
a TFT display for tachistoscopic presentations you'll want one with a low
response rate but the ones with really low response rates come with other
drawbacks. Really, not recommended unless you do some serious
research on the issue.
CRTs. Good luck finding these any more. Tick values in the 10ms and less range are now possible
with LCD monitors made to cater to gamers so the reliance on CRTs is no longer
Sound Input and Output
Soundblaster Live Platinum with Live Drive.
Excellent card, very clean, very good signal/noise ratio, and excellent latencies
with no appreciable variability.
AC '97 and Crystal Sound inbuilt sound.
Lots of modern mother boards have built in sound these days and the ones I've
come across work nicely.
As a general note, DMDX will not be doing anything with the axes of input devices
unless one used the 2DInputDevice keyword, it will only be using the buttons.
PIO card based response boxes. See
Interface Cards above.
Regular Mice and Keyboards. They work,
timing characteristics need to be measured on an individual basis as there are
large variations even within one model.
Logitech Wingman Extreme. Works. The
polling timebase is 3 milliseconds and the POV "hat" basically won't ever be
usable (unless I modify DMDX to record axes) because technically it's an axis
kind of thing. If you short the axes pots out then the timebase
can drop to 1 ms.
Any old joystick or joypad or gamepad.
All joysticks are usable in one form or another.
Hardware found to be unusable with DMDX:
Macintosh computers running Virtual Machines. DMDX
is just plain not going to work in a Vitual Machine, regardless of whether
it's a Mac or whatever (we just happen to see people trying it on Macs).
The amount of activiy required to track the raster is not possible in a VM
(you can of course run DMDX in
EZ mode and forget about tachistoscopically accurate timing).
Bootcamp is pretty much your only option if you want to run Windows and
OSX on the same hardware, other boot loaders are available for limux
machines and so on. Trick is only one OS should be running at any
one time, the second you're sharing hardware between two active OSes the
abstraction of the hardware to allow two OSes to run will get in DMDX's
Microsoft Surface Pros. Some
people seem to be having issues with these machines. After extensive testing
our basic recommendation remains to avoid Microsoft Surface Pros however for
people doing remote testing this is not exactly reasonable so 220.127.116.11 contains
code that at least stops DMDX locking the things up and may in fact allow a
strong semblance of functionality. We say "may" because there was at least
one issue that remained with the tachistoscopic acid test however it appears
to be idiosyncratic and there's nothing else I can think of that might address
it at the moment. Basically what happens now is that if the retrace tracking
thread gets blocked for a second or more DMDX switches into a relaxed retrace
tracking mode that doesn't hammer the vertical blanking bit and instead only
polls it once per millisecond. And obviously if you're looking for an event
that's a few tens or hundreds of microseconds in duration you're going to miss
a lot of them polling once per millisecond. Fortunately machines I've tested
(two) can still track the raster well enough to not generate display errors
(this is with the tachistoscopic acid test so a pretty rigorous test).
Unfortunately the Surface Pros inadequacies don't stop there and on at least
one Surface Pro the first frame of a tachistoscopic batch can be missing.
Maybe the Surface Pro's 3D drivers can't handle two threads making requests at
once, maybe it's just that machine, who knows. The user of that machine is
going to use EZ mode on it and not test subjects with it, at least they'll see
the full display and worst case it's a tick off in it's presentations.
A bit of sleuthing after the HP EliteBook problems surfaced makes it look like
the Intel HD 520 video chipset in the Surface Pro machines
appears to be source of the problem as the HP device has the 5500 version of
the same chipset in it. Argument against that is that my Dell Inspiron
15 5566 has an Intel HD 620 video chipset and it's golden. Difference may
be that I perform clean installs of the OS on my machine, no shovelware.
That or the Intel 5xx and 55xx devices are just cursed...
HP EliteBook 820 G2 laptops. Similar
to the Surface Pro problems it appears these HP Elitebooks are similarly
cursed with having to use relaxed raster tracking if not
Given that Windows 7 was in use on at least one of these I'm thinking it's
the Intel video chipset that may be cursed so it's Intel HD Graphics 5500 is
listed as problematic below in the video section.
Built in or integrated video motherboards. The rule
used to be that there was nothing intrinsically wrong with built in video
chipsets (in the early days this was definitely not the case). However
given that most built in video chipsets tend to be from Intel and we have
two cases of exceptionally poor performance with the Intel 520 and 5500
devices there's a pretty strong caveat now.
Intel HD Graphics 5500 and 520 video
chipsets. See the Surface Pro
and HP Elitebook problems in the whole system section above. Appears to
have stupidly cursed video drivers. I'd be avoiding anything from Intel that
begins with a 5 as my Intel 620 is fine whereas both the 520 and 5500 are
unusable without countermeasures.
NVIDIA cards. Classic DMDX (prior to auto mode)
would have problems on these cards unless the back buffers were limited to
4. Seeing as auto mode already limits the back buffers to 2 with the
classic DirectDraw rendering path and the Direct3D path limits itself to one
ATI cards. They're fine these days.
None. Almost any sound card can
be made to function with DirectX,
however if there are no specific drivers for the card then the dreaded (emulated)
appears after the cards name and latencies for that card will typically be 200-300
milliseconds (not good). Worst case if you're using RecordVocal you
overrun protection for it.
Parallel port based response boxes. I
am reluctant to put any effort into writing code to support these.
The primary domain of use for these is on laptop computers that are portable
testing stations where you cannot put a PIO card into the machine, the only
other use for it is the convenience of not having to install a PIO card.
The later is easily solvable, the former however is rapidly becoming impossible
even if I were to write code. It appears that a lot of the
later laptops have such sophisticated power management and EPP/ECP protocols
built in that regular Dmastr is unable to get at switches connected to a parallel
port and that either users are incapable of disabling said features to return
the port to a plain vanilla STD parallel port or it is in fact impossible to
do. This trend is unlikely to stop given that the standard
parallel port is really abysmal at transferring megabytes of graphics to a printer,
which is what happens almost all of the time when printing from windows (the
only time is doesn't is when the printer has all of the fonts used in
the document, and how many of you Windows only users know what fonts your printer
has?), so laptop manufacturers really have very little incentive to continue
to provide, or more accurately, test, whether their device still functions as
a standard port. Worse, even if they do provide STD
mode, it is likely that on power up the laptop decides that there is no printer
connected to the port so it stops providing power to the port.
Computer Boards is making a PCMCIA card with an 8255
on it so laptops can now have millisecond accurate response gathering.
It's the PCM-D24CTR3.
The DMDX version number scheme now follows
Microsoft's A.B.C.D format,
where the A version number (3 as of 04/03/03) indicates system level changes, I
don't expect this will change in a very long time.
The B version number (0 as of 04/03/03) indicates very major additions or
changes, the C version number (1 as of 04/03/03) indicates significant additions
to DMDX's functionality or significant steps in the code base such as finishing
the port to the MS VC 6.0 compiler. The D version number (4 as of
indicates minor additions that are more often than not fixes to
existing things. DMDX version 1 and 2's version numbers
were A.B.CC. TimeDX retains the 3 number variant.
The latest version of DMDX is
DMDX 1.3.01 is
provided for 486 processors,
2.9.05 is provided
for Windows 95 support. These are the versions we use.
DMDX binaries and demos are here.
The DMDX digital video demo is
Should you be having trouble with DirectX you might
want to check out Microsoft's
Progress to Date.
So more to save me thinking
about it every time it comes up in conversation than any actual request for it I've made the modifications to DMDX
18.104.22.168 to support AMD's FreeSync and NVidia's G-Sync technology along with a
couple of new test modes (14 & 15 in version 22.214.171.124) for testing how the
freesync code is running (given that the video handler is now being called every
millisecond or so instead of every retrace) allowing the presenting of displays of any arbitrary duration as long as it's as long as or longer than the minimum refresh interval of the display itself (typically these devices appear to have a native refresh rate of 144 Hz which opens up displays down to 7 or so milliseconds). For the uninitiated
in a FreeSync or G-Sync system there is no longer any fixed raster interval as such, instead retraces are generated whenever there's a change in the display.
DMDX 126.96.36.199 finally resolves the issues the Direct3D renderer had with
digital video. While the previous code developed in 2014 ran moderately well
combining it with <AbortItemExpression> would produce crashes (and of course the
vast majority of the time if you're using <dv> you're also using <aie>).
After an extensive debugging session I discovered that only wholesale
reconstruction of the way the Direct3D video rendering code operates would solve
the crashes given the completely evil way the VMR9 code was functioning (it was
doing things like allocating surfaces after it was given and acknowledged the
stop command). Of course, this is probably the way I should have gone in
the first place as (a) it's simpler and (b) closer to the example code but it
didn't occur to me at the time and that's because I now just block the VMR9
thread once it's produced a frame to be rendered until DMDX finally renders it,
no more out of phase efficiency and so on. While more of a bug fix
than a feature update this is likely to be the last new development for DMDX as
the UofA has cut my position and unless someone else decides to fund DMDX's
development (or a relative of mine needs something) I'll just be doing minor
fixes and answering questions on the list serve. I'll also keep psy1 alive
as long as possible for remote testing and other services it provides, it's
already been converted into a VM running on John Allen's servers so kudos to him
for stepping up and helping the wider DMDX community. It was an amazing 20
years (almost thirty really if you include DM and DMTG the immediate
predecessors to DMDX) and while I never thought I'd build a Turing complete machine
(I'm pretty sure DMDX is one) it's so long and thanks for all
And in right quick time we have DMDX 188.8.131.52 where we
exploited the new 3D rendering path to support NVIDIA 3D Vision stereo shutter
OK, it's time to release DMDX 184.108.40.206 and TimeDX 5.0.0. While there are still a few problems with digital video playback under Direct3D in DMDX 5 and the experimenter's display when using Direct3D is a nice uniform shade of blue the absolute vast majority of people aren't going to notice and it will take me quite some time to resolve those issues (the VMR9 code for Digital Video has already sucked the last two months of development time I have and there's no sign of it being perfect yet) and there are for sure more and more people with Windows 8 that are using DMDX so it's time to get the general distribution updated to handle win8.
Alpha versions DMDX 220.127.116.11 released to check the new 3D rendering path needed for
rigorous tachistoscopic performance under Windows 8.
DMDX 18.104.22.168 released with soldieron mode to handle DDERR_SURFACELOST recovery (improved handling when not soldieron too),
unicode macros and a major overhaul of original macro code.
DMDX 22.214.171.124 adds a Unicode path to DMDX with the -unicode command line option
to deal with otherwise intractable Asian fonts. Didn't ever really think we'd make
a Unicode DMDX but due to a fortuitous feature of RTF text files it turns
out it was relatively simple for 97% of cases, moderately complicated for
another 2% and only a right pain for the last 1%... Amongst other recent
developments we've been working on a remotely executable version of DMDX
that's packaged up in a self extracting archive that lets experimenters post
experiments on their web servers and have users run DMDX on their machines.
It's using DMDX's EZ mode that dispenses with raster synchronization and once
a bit more work is done that will allow DMDX to handle a loss of application
focus it should be pretty solid.
DMDX 126.96.36.199 adds data logging functionality to the 2D input devices added
DMDX 188.8.131.52 dramatically increases DMDX's scope
with the ability to handle 2D inputs for touch screens and a special mode to
handle the system mouse.
As far as I can tell all of the work I intended
to do (and then some) for Version 3 of DMDX is done, DMDX 184.108.40.206 and TimeDX 3.0.05
look like a wrap. Among the myriad things added are an installer, a .CHM help
file that is searchable with an index and a table of contents, radically restructured
RecordVocal and DigitalVox devices that won't break a lot of broken audio drivers
and that allow variable length recordings, input devices that work on any international
machine, and last but by no means least a vastly improved automatic refresh timing
routine in TimeDX that I've only seen fail on machines with broken video drivers
where DMDX wouldn't stand a chance of running anyway (and when it does fail it fails
safe with a notice for the user so if it works at all it works properly).
Of course, there are a ton of smaller changes too.
I'm currently porting DMDX to the Microsoft Visual
C++ 6 compiler and there will be several repercussions. First,
the version number will be 3 and the previous 3D work will be dropped.
Also, there will be a semi-major version number (as in 3.0.0.00) added as I expect
version 3 will be around for large number of years. I don't think
the 3D path is going to eventuate so DMDX's current structure is likely to have
extreme longevity and I'm going to need more flexibility for version numbers.
Lastly, Windows 95 support is going to be dropped. The current
version 2.9.05 will get archived for anyone that needs 95 for an OS as 1.3.01 is
currently archived for anyone that needs 486 processor support.
Other than that no one should be able to tell the difference although several aspects
of the program are likely to become significantly optimized (notably the high performance
timer code). There may be other repercussions, I'll know as the
I switched DMDX 2.1.00 to use DirectX version 7 so
that a TimeDX Enhanced Retrace Rate test can be done. The new
test allows unequivocable measuring of the retrace interval, the catch is your video
card must be capable of unsynched flips which basically means it has to have been
made since DirectX 7 was released last year some time -- or at the very least to
have had a completely new suite of drivers released for it that know about DirectX
7's new features. This probably means that machines running 2.1.00
should have DirectX 7 installed (sorry, but I can't test it, all my machines already
have DX7 installed and I'm not about to retrograde any of them as I've never found
a downside to having version 7 installed), DX70ENG.EXE for the English version at
Ok, the preliminary release of DMDX 2.0.00 and TimeDX
2.0.01 are up on the website. The old version of DMDX (1.3.01)
is still available in DMDX1301.ZIP, I won't be deleting it any time soon as it's
the only version of DMDX that can work on old 386 and 486 machines.
I won't be updating version 1 again, any fixes or modifications will be made to
the version 2 code. The new version includes greatly enhanced
(read largely re-written) support for multi-monitor machines (the secondary subject's
display can now be a part of the windows desktop which it tends to be by default)
and exclusive use of the win32 Performance Timer (read microsecond accurate RTs
if you can find an input device that accurate and basically more accurate timing
all round). I'm still working on it, sorting out joystick polling
issues raised previously and other things but testing by me to date indicates I
haven't broken anything and that RTs are in general at least 0.3ms more accurate
than they used to be so I'd like people to at least start testing it.
Note, you must use the new TimeDX to record registry settings for the new DMDX,
they use different forks of the registry tree (so version 2 settings won't upset
version 1 code).
Well I finally crafted a reliable retrace rate determination
routine -- well as reliable as '98 will allow. Instead of trying
to detect the retrace I realized I could simply use the Flip routine that changes
the displayed page of video memory, as it can't be executed twice in a row until
the first flip is finished it's guaranteed in synch, and given that TimeDX 2 is
only using the high performance counter it's just a case of call Flip 100 times
and wait for the last flip to finish and divide by 100, viola, accurate values to
2 significant digits (or more with larger Ns). This removes what
I consider to be TimeDX 1's most crucial failing.
I have begun the version 2 re-write.
Issues addressed by this will include optimizing the code to only use the High Performance
Counter found on Pentium class machines (read: "no more 486 support"), redesigning
TimeDX's and DMDX's use of windows so that MultiMon systems are far less prone to
problems and in general cleaning up a lot of TimeDX that is no longer of any use.
Hell, I might even update which DirectDraw interfaces are used, get away from using
the original DDS for Flip but DDS2 for everything else (because DDS2->Flip is
fucked broken) and use DDS3 for everything. 'Course,
then I'd have to figure out the new damned GUIDs...
Among many things that 1.1.10 has in it is another
new input device, the RawJoystick. This device simply polls port
201H that is the low level interface to the ancient IBM analog game port interface,
it doesn't use generic routines that read the axes so it is as fast as a PIO12 and
due to the enhanced ease of wiring up switches (no more messy resistors) it becomes
the method of choice for millisecond accurate custom response switches.
The DigitalVOX tests now also checks for incompatable sound devices that report
functionality but in fact provide no data.
I knew I shouldn't have released 1.00, no sooner
is it out the door than another major feature is added. Now we
have version 1.1.00 that has a couple of new input devices, the DigitalVOX device
and the RecordVocal device. The DigitalVOX input device does away
with external electronic voice keys using a microphone and sound card instead and
the RecordVocal input device writes the subject's vocalization to disk.
Also, I accidentally wiped the update in here about
the DMDX mailing list. The idea is that if someone is having trouble
they can post to the list instead of mailing Ken and if someone other than us has
solved the problem they can perhaps provide the answer. So far
it looks like it's just a mechanism for me to answer people's queries, haven't seen
much if anything in the way of trivial problems. If you want to
be on it send mail to DMDXfirstname.lastname@example.org
with the word "subscribe" by itself with no quotes in the body of the email (not
the subject). Once your subscription is confirmed posts can be
made to DMDX@psy1.psych.arizona.edu.
The list archive is available at
Ok, the problems section is empty and the to do section
is full of little things that I might never do, 1.00's out!
The help file is now a new beast with indexes everywhere and the latest tweaks
have been applied to the multimon code. To celebrate Ken is putting
the finishing touches to his user level documentation (as opposed to my stuff that
is more or less reference level).
1.00's gonna take a little bit longer, I've decided
to rework the DMDX help file providing indexing for all the keywords and it's a
lot of work.
Long time no update, this puppy's getting pretty
stable. Version 0.27 incorporates fixes and features needed over
the last few months, once I've added a few more key things like an <OverSize> keyword
to catch stray pixels with arabic fonts version 1.00 should be released.
Things fixed or added include: <StreamingAudio> for long audio instructions, <NoNTNPrompt>,
<pan> and <volume> for wave files, <xy>, wave file and graphic file of same name
confusion fixed, repeated nut to butt playing of the same wavefile, keyword parsing
issues when no spaces separating two of them fixed, <ClearFeedback>, and <TimeCriticalFrames>
for suppressing error messages in .AZK output for people that don't care at all
about errors or only wish to know about errors when they count.
Stuck a few semantical checks in to 0.22b to catch
obvious errors with clockons, missing CRs and frame delimeters.
The ability to tune priorities of processes has been
added to 0.22, more as an exploratory effort to see if the display error rate can
be lowered on some machines still having trouble -- there will probably be much
more tweaking here as doing things like making the retrace thread supreme also means
that the PIO inputs aren't polled while it's active, not to mention the possibility
of bombing some other part of the OS (although it currently looks like DirectX just
ups the ante when DMDX boosts itself, possibly not a bad thing because then DirectX
might stop functioning if it didn't up it's priority). See TimeDX's
Advanced / Task Priorities for more info.
Multiway branching added to DMDX 0.21, fixed the
missing " crash. It would appear that DirectX 6 fixes the pauses
after DX initialization, apparently previous versions wrote to the registry after
startup and this would take some time to get flushed. People with
excessive refused flip messages should be aware that reducing the sleep time in
TimeDX fixes this problem.
I'm tweaking all the priority stuff so the next version
may have significantly improved immunity to other machine activites (not that the
current stuff is shabby), due primarily to my realizing that high performance timer
code will not be blocked by a THREAD_PRIORITY_TIME_CRITICAL retrace sync thread
(the original callback timer code is blocked); between that and boosting the whole
process to REALTIME_PRIORITY_CLASS there should not be anything that stands in it's
way (hopefully, not at least according to my process viewer).
I'm also changing most of the file I/O over to pure win32 function calls so I can
use a flag (FILE_FLAG_WRITE_THROUGH) that makes any disk writes get performed at
the time of the call as opposed to some arbitrary time later, usually in the middle
of a tachistoscopic presentation. Changing these kinds of things
is likely to upset large portions of DMDX (like the Digital Video already looks
like it's gonna need a bit of TLC) so you might wanna make sure you keep a copy
of 0.21x before using the next release.
Found a major oops in TimeDX 0.29 remembering video
modes with some number of scan lines other than 480 and then re-programming the
number of scan lines to 480 (say 800x480 instead of 800x600) the next time it ran
(which crashes the DELL Inspiron 3000 laptop, not too surprising, which b.t.w. is
very nice DMDX box). Also, in version 0.20a of DMDX the <ZillionEnterKey>
keyword/MDSP bit has been changed to provide feedback as the user types a response.
The .IMG file to .BMP converter
done along with DMDX 0.20 which when used with <DefaultBMPMultipliers 1.0,1.371>
will stretch all the .BMP files to the correct aspect ratio. Version
0.20 also includes dramatically better WYSIWYG .RTF file parsing in that you no
longer need to make sure text formatting falls inside the text double quote delimeters.
Oh yeah, the default output format is now .AZK, if anyone wants a .DTP file they
will have to use the <DTP> keyword (I doubt anyone was using it as there was a bug
in the code that wrote the binary data).
Released DMDX 0.19 with alpha blending, stretchable
bitmaps and Digital Video. There is a Digital Video demo that
lives on PSY1 because
it is over 4 megabytes. I'll probably be writing a monochrome
.IMG file to .BMP converter given that you can now stretch bitmaps in DMDX, I'll
probably also implement a global bitmap stretching factor similar to the <FontMultipliers>
Added alpha blending to fade from one frame to the
next, very cool if CPU intensive. The demo item file Features.RTF
now requires a 16 bit per pixel display to facilitate the alpha blending demo and
the graphics (which should always have been displayed with a 16 bpp display).
DMDX 0.18 released. Digital Video
will probably be in the next version, till then I had to release the current fixes
which include: fixed REQUSCHED and D param (use of either resulted in ISI times
in tics that were the value of the current millisecond timer, oops), last used item
file now remembered, fixed rect. of wrong color on some devices, <!> remarks, tuned
multimon code to use DETACHED secondary displays (that are not part of the desktop),
introduced <safemode> for latched up item files. All video modes
will need to be re-timed as the registry key names have changed to facilitate differentiating
between identical display cards on multimon systems (I've also changed the default
sleep times to free up more CPU cycles on machines with High Perforamce counters
[read: all pentiums]).
In the process of adding (or seeing if adding is
possible) support for DirectShow enabling the display of .MPGs, .AVIs, Apple QuickTime
and whatever else it supports. If it works (and doesn't blow the
rest of DMDX up) there'll be a new frame specification akin to the sound and graphic
frame specs, it's duration will be however long the .AVI (or whatever) file plays
for -- I've seen no reference to cursors in the multimedia file formats yet so cursor
control will not be immediatly forthcoming, perhaps the duration will be overridable
and the initial playing position but these are likely to be values in the item file,
either time, percentage or number of frames. .AVIs will be played
full screen (this could be overridden in the item file I suppose), it's faintly
possible that the audio from the .AVI and DMDX could be mixed although there will
be no special attempt to get them in synch (if you want the audio in synch with
the video put it in the .AVI that way).
Despite MicroSoft's decision to not make DirectDrawEnumerate()
function the way they said it would function I have managed to get the Multimon
stuff functioning -- 'course you need '98 to do it but DMDX will function with it
when you get a Multimon system together. Currently the only cards
I can find that function as a second display device are cards based on the S3 Trio
As a result of the secondary display device being
a memory mapped device the code that re-programs the number of scan lines on a display
cannot function with a secondary display device, maybe I'll have luck and find that
there is some sort of standard for memory mapped displays but don't hold your breath.
Made the Naming task Negation code use the remote
Monitor (if found). Changed the PIO code to allow changing it's
base address, primarily done because Computer Boards is making a PCMCIA card with
an 8255 on it (the PCM-D24CTR3) and it doesn't have jumpers on it so people will
have to run the configuration utility to change the address -- on top of that it's
generally more difficult these days to make sure 310 is free for the PIO.
This means laptops can now have millisecond accurate response gathering (which they
basically lost with the advent of the ECP and other variants of the parallel port).
Put the start and end cue code in to play portions
of wave files, fixed a number of small things (like 24 bit wave files causing the
machine to allocate something like 64 megs of swap space...), changed the demo quite
The remote monitor network code is coming along nicely,
this means you can monitor DMDX's operation from another machine assuming they are
networked together with TCP/IP. Pretty cool if you ask me.
Seeing as it's TCP/IP that machine can be anywhere in the world which at first I
thought was pretty useless, but as Ken points out, it actually stands a chance of
being useful for us to remotely diagnose a machines operation without having to
transfer the diagnose.txt files -- not that that's any big inconvenience transfering
Put a syntax check only mode in that quickly checks
syntax and media files used.
Left the implementation of the millisecond callback
to dispatch vid_int() INCOMPLETE. movingimages() (I guess) screws
up when there is a long lag between msec callbacks and seeing as the whole operating
premise is that this doesn't happen I'm not going to invest any more time in getting
it going. Maybe NT has a better callback (the opinion of people
on the wire appears to be that NT has much better multi-tasking) but that can be
left for a later date. Looks like we're going to implement the
ability to play a section of a wave file between cursors, or more accurately, the
ability to play a file from some point other than it's beginning and the ability
to stop playing a file at some point other than it's end.
Implemented the ultimate in retrace syncronization.
If the high performance counter is present (and it would appear to be present on
all Pentium machines) DMDX uses the millisecond callback to dispatch vid_int() as
the callback is the only thing that doesn't get pre-empted too much.
The blitter I suspect still gets it and things that grab the win16 mutex probably
also get it; the former is still dealt with by keeping the blits small and the later
are not much of a problem as they are typically associated with the drawing routines
and they are typically not active during critical displays. The
reason this wasn't done before was that I hadn't yet thought of a way to do it (you
can't sleep if you are running at real time priority) -- needless to say the final
result is an amazingly complex process. Now, if I can just get
it working properly...
Made a nice little demo that'll go up on the web
page when I've fixed all the little things it turned up in DMDX...
Due to the joysticks extreme usefullness as an input
device (error of +/- 1.5ms or so) and the fact that a program compiled with the
DX 3 SDK can't see a joystick on a DX 5 machine we have decided to make the minimum
version of DirectX needed 5.0 instead of 3.0.
Two historic dates on two successive Friday
the 13ths, ooooh. It's benched and I didn't find anything
out of whack ('course I've also fixed a dozen things too). The
thing's smart enough now to detect if a loss of synch has occured at a critical
time and flag them as display errors (might eventually write this to the ascii output
file, I dunno) otherwise it gracefully recovers so my guess is it's just about
done. Call version 0.08b the Beta release. The only other things to be added are
minor details (like the ability to use a cursor in a sound file to set it's duration
to sync. with the visual display). And of course fixes for the
odd combinations of things that don't work that will always pop up...
Hot damn, I was even using the animate switch with sound files in testing it.
Sound is done. Well, at least,
whole files anyway, playing portions of files between cursors can wait for looong
time. Next benching and more benching.
Man, DMDX has more threads than you can poke a stick
at. The kernal (your operating system) has three threads (typically),
DMDX has one for the main processing of DMDX, preparing images and moving them into
video memory, a second thread to keep track of the vertical retrace, a thread per
input device, a thread to play sounds and it uses the system timer callback, effectively
another thread. That means your average DMDX with two input devices
has SIX threads!
All input devices debuggered, haven't measured their
latencies (on our machines anyway) yet. Output debuggered too.
Response contingincy crashes it but other than that (and the hundred other things
that haven't been found yet) it's probably usable. Sound goes
in next week.
The keyboard and mouse drivers work (polled PIO and
joystick still to be debugged -- actually output and and just about everything else
too), but it is a functioning Dmastr nonetheless.
Finished coding the input stuff.
About as complex a thing as I have ever designed -- with the number interruptions
I had while writing it it will have some interesting little funkadoodas for a while
Finally deduced how to get the back buffer's COM
objects, the documentation is wrong about three different ways...
Anyways, another historic date, we have tachsitoscopic Dmastr under
Win32, DMDX lives! No input or nothing,
just display only (well, it does use a space bar for a request), but it goes and
it uses all available video memory to do it's thing and I ain't getting error
messages out the wazo about it not being able to get things displayed at the right
time so it's cookin'.
Nothing like a 13 hour straight coding session at
home ('cept for a slight break to break in the new driver at the driving range,
a real splurge there with a TI Bubble 2, mmmm hhmmmm) to figure out the nitty gritties
of the display code. Colds are good for something I guess.
Which, I might add, was a good deal more tricky than I had realized, I hadn't quite
scoped out just how complicated any number of back buffers can be if you aren't
blithely updating the whole buffer. Not to say it's all working
yet, or even running with real page flips, but the simulated mode is mostly together
which is a huuuge step. Put it this way, it works
well enough that if you accidentally turn the clock on it latches up like Dmastr's
supposed to if there's nothing to respond with (and there ain't, not yet anyways).
Most of the drawing routines are done, although there
is probably going to be many modifications owing to the possible complexity of RTF
syntax and DMDX implimentation of a subset of it. Next comes the
tricky bit, the tachistoscopic routines that take what has been drawn in memory
and display it in a timely fashion -- I am going to leave the sound till last, too
many people need basic DMDX ASAP. Finally got tired of Word 6.0
(my file names tend to be longer that 8.3 these days...) and installed 97 and noticed
this convert to HTML option so I converted the help files for TimeDX and DMDX and
put them up (above) so people can get a better idea of what's happening.
Well, after a slightly longer than intended break
(the engineer resigned leaving me to carry the technical support load by myself)
I am back at it writing the drawing routines. Got off to a good
start by lifting a rather complex set of function calls from the MicroSoft site
(and adding a bunch of error checking) and having it all work, TimeDX can now load
BMP files -- just how well and how many different types remains to be seen, but
it's a good start and if bits of it don't work I am at a loss to see how I could
change anything actually...
item_sched() started. Looks like
we won't be getting any early betas in December as I will be leaving for Oz soon
and will be back in January when work will commence on the graphic code (text only
to begin with) and then the video memory frame buffering display code -- so maybe
late January instead. item_read() is no longer limited, no max.
item size (within reason, as with all unlimited DMDX things your machine's RAM poses
the only limit), the display queue will be the same, no number of frames limit.
Cleaned up a few bits of TimeDX and DMDX's scrambling,
figured out a bit of the palette madness that is Windows in 256 colors.
Started moving job_get(), item_read(), getp() and all manner of timeless Dmastr
routines into DMDX.
Built the keyword parser and modified the scramble
routines so there are no limits other than available memory, no block number limits,
no fixed text limits, no items per block, nada. Fixed a long standing
error in the scramble routines dealing with $$, it still isn't correct leaving a
stray $ in the scrambled output, moral, don't use $$, use $ $.
For want of being unable to decide what to do next
I have begun writing the RTF parser and scrambling routines for DMDX.
Looks like the RTF is going to be a can of worms for a while, largely because there
are so many things you can do with RTF that DMDX will not do.
Re-did the retrace code so it can take advantage
of the high performance timer if it's present, and it's sweet.
So good, the automatic sleeping and timeout values are actually usable now.
Added detection of certain errors so there is the strong chance of DMDX being able
to take emergency measures should '95 grab the CPU for a while.
Chucked a few ping packets at a box keeping synch with the retrace and it didn't
even notice them, a very good thing as the network is rapidly becoming an indispensable
part of a computer.
Well, having found out the behavior of the millisecond
callback I have incorporated the High Performance Counter into the millisecond code
and it appears to have had a good effect, at least I can use the highest priority
for the retrace sync thread now (it used to over-ride the millisecond callback,
now using the high performance counter the time is not dependant on the callback).
Actually, given the thing's resolution (microseconds on these pentiums) I may be
able to measure the retrace exactly and do things with it, more testing will ensue
to see if this is indeed necessary as it's looking very good already.
Found out one of the reasons it's so hard to keep
track of the retrace, the millisecond clock is all over place.
It probably has 1000 callbacks per second but the phase varies all over place, time
between callbacks can vary from .2 msec to 1.8 msecs... Probably
and argument for the fastest damned machine you can afford.
Historic Date. The file
DMDX.CPP has been created. Doesn't do spit, but it is
created. Gotta make TimeDX export it's Driver settings to the
registry so DMDX can get at them.
Sound Latency test completed. Revealed
the fact that even though an emulated (no hardware support from DirectX Setup App.)
DirectSound driver may sound perfectly nice it's onset time is through the roof
(200-300ms for the emulated Crystal CS 4232). A sound card with
a driver supported in hardware (Sound Blaster 16, not emulated) has an onset of
15ms or so, this will vary with CPU and sound card. Mixing multiple
sources appears to have negligible (2-3ms) effect.
DirectInput done, good thing the DirectX 5 docs were
at hand, I'd never have figured out what was supposed to happen from the DirectX
3 docs, rather akin to learning a language from a dictionary, it assumes you know
what you want to do and what all the parts are for already. Might
check the latency of DirectSound mixing as I saw a worrying reference to it being
slow in the News Groups. Thinking hard about DMDX design.
Tachistoscopic routines appear to survive having
the sound system active, there is a larger timeout rate with cards not supporting
the DirectDraw GetScanLine function but it's only a few percent and there is no
visible visual degradation (read loss of synch with the retrace).
There also appear to be longer periods on all machines where the timeout rate goes
right up, but even then it does not appear to be catestrophic.
Guess I'll have a look at DirectInput and then it's time to start thinking hard
about DMDX's foundation.
Yowza, got the sound going, only one fantastically
subtle error in there -- DirectSound was carefully muting all my buffers for me
because it thought TimeDX was two apps and not one, a little frustrating.
Thank God I can't meditate otherwise I'd have never figured that one out, sitting
for meditation allows one to see really subtle things if one isn't actually absorbed
in the state one is supposed to be absorbed in, as is the case almost all of the
time with me. Next we see if the tachistoscopic routines are upset
by DirectSound stuff going on.
After a break for illness and other projects I am
back at it. The PIO code is completed, now the sound code.
Major success this week, didn't even have to pull
too many hairs out. Built code to re-program the number of scan
lines on the screen (read, adjust the refesh rate) and to access the PIO card.
The hairs come from the fact that this is Win32 and you're not supposed to access
the I/O ports anymore, and to enforce this the compiler indeed no longer has inportb()
etc., so you have to buy the Turbo Assembler (32 bit version) just for two instructions.
Used Event Signaling from the video retrace thread
to the tachistoscopic routine (so the thread doing the tachistoscopic presentation
goes to sleep till the retrace thread specifically wakes it up), a much less daunting
task than redesigning the whole damned thing and it works much better
than on 07/13/97. It even works through Multiply Missed retraces,
something I was hoping for and am impressed to see working (which is not to say
there is not a bunch of code to make it work, just that it's amazing that
it actually works without me having to pull my hair out fighting the SOB), although
a lot of that is still dependant on how well the user tunes the sleeping and timeout
values for a given video mode.
Matter of fact it's working so damned well right
now I don't think it'll ever muck up a prime (unless it's too big), especially if
I implement triple buffering in the video routines.
Well, I've been playing with the Tachistoscopic Acid
test for a while now and as best as I can tell DMDX is going to loose track of the
retrace periodically and that's that. Meaning that every now and
then a frame is going to be displayed for longer than requested because some other
process (read KERNAL32.DLL) is going to snatch a bunch of CPU cycles and as of right
now there ain't spit I can do about it and it ain't for lack of trying, believe
me. Time will tell if I can minimize the interferance further,
but my guess is it's only going to get less, not go away. About
the only occasion I can think of where this is unacceptable (and un-get-aroundable
except by using DMTG) would be where you don't want people to know if there is a
tachistoscopic prime at all, ever -- because every now and then one of those primes
will be visible, might only be one in several hundred items, but you won't miss
it when it happens. Your stats should wash these out without any
trouble and the voice parts of DMDX will know about it so the sound will get back
in sync (assuming you are not playing enormous many second long sentences, I can
only re-sync when any given sound starts) so it's not a total wash, DMDX can still
be built, but it's not going to have the rock solid nature DMTG has.
A price we pay I guess.
Seeing as the ONE routine I can rely upon is the
millisecond timer I'll try reconstructing the tachistoscopic code using the millisecond
callback to Flip the displayed page and see if things work better.
Had a little bit of trouble building a reliable vertical
retrace synchronizer, time will tell how well it functions on different boxes as
it can utilize one of two possible schemes depending on the video card.
I'm back to using passpoints -- with multiple threads, millisecond callbacks and
DirectX page flipping I don't think anything short of an ICE would handle TimeDX.
Millisecond interrupt code completed.
Turns out that hidden deep in the Multi Media extensions there is a usable millisecond
interrupt -- kinda, but it appears to be working. Major hurdle
overcome there, many thanks to Deja News
http://postnews.dejanews.com/ without which life would be much harder than it
Lordy Hallelujah, found the Flip hang, there it is,
documented all the way four levels down in the last minute release notes, "BTW,
DDS2->Flip may hang, use DDS->Flip as a work around". DirectX
is a seriously tough thing to interface to without thousands of dollars for MSDN.
Even with the public DirectX news group that still took days.
Tired of fighting BC 4.52 and will now use 5.01 till
5.02 turns up in a week or two. At least I can step through programs
now instead of suffering from passpointitis. Of course, that's
assuming I am not deep in a bit of EXCLUSIVE mode DirectX where you can't see nottin
'cause the IDE don't know about DirectX... Must see if I can get
the debugger to run over the net between the two machines, but I'd have to RTFM
for that so it'll wait I guess.
Font selection code in TimeDX done.
First bug in DirectX circumvented, must not release a DirectDrawSurface until the
derived DirectDrawSurface2 is finished with. Sometimes.
First step of TimeDX done, code to initialize DirectDraw.
This actually represents a hell of a lot of work (like at least 1000 pages of documentation
read to begin with).