DMDX Updates Page.

Last Updated: 03/04/24 j.c.f.

Updates as I construct DMDX can be found here.
Hits since 5/20/99:

Problems using DMDX?

General Notes. 

      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 UPDATED! Windows 7, Windows 8.1 and Windows 10 (recommended), it also appears to work with Windows 11 however I haven't had a chance to test it in person yet.   There are no Macintosh or Linux versions of DMDX, nor are any versions planned, however using the Direct3D renderer DMDX works reasonably well in a VirtualBox virtual machine using their "experimental" WDDM Direct3D drivers in their Guest Additions and I see people running DMDX on a Mac using Wine or a Wineskin.    Windows 95 support has been dropped and is only available in the archived 2.9.05 version.    Windows 98 support was dropped in version 5 so you'll need the archived version and Windows XP and Vista were dropped in version 6 so you'll need the archived version for them (although I suspect was the last one that operated with XP as when I recently set up a XP virtual machine it complains the later binaries aren't win32 executables so the new compiler is producing something XP can't grok).
      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 Microsoft 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 from a performance perspective, there may still be driver issues with particular setups (see below).  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:
	ms 	n
	523	87
	524	200
	525	239
	526	46		Mean	524.4ms
		572		sd	0.843ms
Version 2 results:
		 		Mean 	524.37ms
				sd 	0.77ms
PIO12 values with an 11025KHz 16 bit wave file playing:
	522	2
	523	90
	524	193
	525	227
	526	50		Mean	524.4ms
		562		sd	0.874ms
PIO12 values with 1 frame displayed every 100ms:
	522	12
	523	81
	524	170
	525	180
	526	59
	527	7		Mean	524.4ms
		509		sd	1.010ms
PIO12 values with 5Mbps network transfer between two other machines at the same time (which was an extreme amount of traffic at the time the test was run back when 10baseT was special):
	523	92
	524	196
	525	230
	526	53		Mean	524.4ms
		571		sd	0.868ms
MicroSoft Serial Mouse 2.0A (no ball):
Version 1 results:
	523	3
	524	334
	525	222
	526	12		Mean	524.4ms
		571		sd	0.545ms
Version 2 results:
				Mean 	524.37ms
				sd	0.35ms
	508	1
	512	35
	513	53
	523	7
	524	1
	526	152
	527	321
	530	1		Mean	524.4ms
		571		sd	5.154ms
Instacal QPIO12 values with at twice the closure rate:
Version 3 results:
	ms 	n
	261.8	701
	262.8	346
	261.7	38
	261.9	19
	262.7	19
	262.9	13
	261.6	2
	263.0	2
	261.5	1
	262.0	1
	262.3	1
	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 (win95) only 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 error).
      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:
	ms 	n
	118.4	14
	119.0	13
	118.6	12
	118.8	11
	119.1	10
	118.9	9
	118.5	8
	118.7	8
	118.3	7
	119.2	4
	118.2	3
	119.3	1		Mean 	118.72ms
		100		sd 	0.29ms

      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:

Hardware Features Used by DMDX:

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 a priority.

Hardware found to be unusable with DMDX:

Latest files:

      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 04/03/03) 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 here.
      DMDX 1.3.01 is provided for 486 processors, 2.9.05 is provided for Windows 95 support, is for Windows 98/ME, is for Windows XP and is for Vista.    These are the versions we used to use, we almost always use the current version.
      DMDX binaries and demos are here.    The DMDX text / graphic / audio demos in are here    The DMDX digital video demo in DVDEMO.ZIP is here.

Progress to Date.


      Well I think the addition of parsing Unicode to UTF-8 outside quotes in item files completes the Unicode odyssey we've been on the last few years with DMDX, if there's another place DMDX could handle Unicode and it doesn't I can't think of it, I declare DMDX to now be a fully Unicode aware program (assuming the Unicode option is in effect of course).  After having added named counters to match the named macros it dawns on me people might want to use special characters unique to their locality in those names, lordy, was that ever a mistake.  While it was relatively straight forward getting the Unicode counter names working macros were another thing entirely.  In order to have Unicode outside quotes in item files I have to use UTF-8, something I'd already more or less done for localized keywords (never went anywhere and the code for it remained dormant) but a macro has to expand within quotes, no particularly big deal except macros can contain other embedded macro definitions so we have to be able to mark up our UTF-8 names back to UTF-16 found in quotes.  Beyond having to deal with UTF-16 surrogate pairs (emoticons anyone?) I had to pull the recursive macro code written in the late eighties for DM apart and rebuild it; for one thing it wasn't handling embedded named macros now that they're UTF-8 and for another if anyone had tried to use Unicode in the subject ID I mention below I'm pretty sure any use of macro S would have produced mojibake.  I spent close to a week on and off with the debugger on that trying to get the new expansion code to work the way the original code was calling it; not only that, the debugger gets it's knickers in a twist occasionally when debugging recursive routines, can't say I blame it, mine get twisted with recursive stuff too, I still remember my amazement at getting that original code working at all...
      And then as I'm updating the Unicode notes I realize that using UTF-8 outside quotes has serendipitously solved a lacunae from all the way back when I first added Unicode to DMDX in the late aughties and that was that in order to include Unicode characters in a macro body one has to quote the definition of that macro, as in mM"ॐ", something I go to some lengths to point out in the Unicode notes (it arises because DMDX strips RTF control words out outside quotes but Unicode is encoded with RTF control words).  Well having Unicode outside quotes now means you can gaily have mM+ॐ+ and it will now expand correctly when you use ~M in quotes.  I love it when an unintended side effect is actually beneficial.


      Spent the last few weeks (periodically) removing references to in the help and elsewhere and making them HTTPS psy1 references and putting a .htaccess file on it that redirects all traffic to psy1 as UITS is retiring that server.  They would also like to banish psy1 but that battle is still being fought, if we loose then I'll set up an AWS server -- which doesn't come for free so people frequently using psy1's remote testing features will be donating to that cause, if you want to help feel free to send me an email (jforster{@}arizona[.]edu), won't be more than a few bucks a month.  Hopefully if this comes about UITS can point psy1's DNS record at the new Amazon server and people won't notice the rather dramatic underlying changes.


      After a year of fixing and tweaking various things it occurs to me that if DMDX can use Unicode file names for resources it should also be able to open and read item file names with non-ASCII characters in them too, so we have DMDX where I've not only allowed browsing to said item files to run them with DMDX I've also updated most of the utilities (ANALYZE, AZK2CSV etc) to use Unicode file names too.  For completeness' sake I've updated the command line parsing code to use the wide Unicode versions even if batch files need a bit of jiggering (you have to set the code page to UTF-8 with chcp 65001).  And seeing as the subject ID can be used as part of a filename it's now UTF-8 as well.  While there's a good chance you could have always used names with characters from the machine's local code page you for sure couldn't use characters from other code pages (so if your machine was Korean you could probably use Hangul but not Hebrew) and a bit of testing here with Hebrew makes me believe it may not have always been possible even then as I had the machine's language set to Hebrew but wasn't able to open files with characters from that alphabet. Said fix also re-enabled the use of relative path names for resource files that had been busted for almost 15 years, oops, pretty sure I noticed it on at least two occasions but each time a fix would be found before I had to crack open the compiler so I never fully investigated it, this time I ran over it as I had to rip up all the file I/O to handle UTF-8 names.


      A few months ago someone sent me a file with Hebrew characters for it's file name which reminded me about DMDX's long standing inability to load graphics and other resources that use non-ASCII characters in their names (the long standing advice has just been to use ASCII resource names) and it got me wondering whether DMDX's recent additions to the Unicode option might not finally allow DMDX to in fact load such files.  After a fair bit of work it turns out that it does and after several weeks of progressively finer tuning the Unicode option is now much more usable than it used to be.  Besides allowing the use of any Unicode characters or code page extended characters in resource file names version can now render UTF-8 characters in diagnostics and error messages which means that after DMDX converts them from it's own internal representation to UTF-8 they are much easier to parse and look much the same as they do in an editor (in the past such was not the case when the Unicode option was on), I never realized just how powerful UTF-8 was, sure is a shame Microsoft went down the UTF-16 path (actually it was UCS-2 back then) when they developed Windows NT, it would have made life much easier if they'd chosen UTF-8 (to be fair they may have had to make the decision before UTF-8 existed or was ready for prime time).  Sure wish I'd known about UTF-8 when I put DMDX's Unicode option in years ago.  Regardless, after a couple of weeks of not thinking of yet another error message that needs conversion I think I've pretty much nailed it.


      And just when it looked like things were going to get quiet again I get a request to control a Gazepoint eye tracker using TCP/IP.  This is something I'd been waiting for for some time as it always appeared to me to be the next logical medium to send signals between machines to synchronize them but no one ever asked for it and I wasn't about to go looking for it's use preemptively.  However having gotten the request in version we now have the tcpip input device that will open a connection to either a remote machine or a process using the loopback address ( that's either using the Open Gaze API or some another type of API, be it JSON or what have you.


      Looks like the built in introduction I started back in December is more less completed along with the ability to port a version of it to HTML in the help file.  It started out being a simple thing to address the people who complain about DMDX's steep learning curve (you'd never believe that there are people that claim it's easy to use) but then as more and more things occurred to me it's now a pretty comprehensive affair only lacking examples for presenting media files (which it can't do, people will have to fall back on the traditional demos).


      Well that didn't take long, normally there's eons between updates here but I recently got access to a modern touch screen device (a very nice Inspriron 11, even with  a meek AMD processor in there it handles DMDX with aplomb).  I'd always hoped that DirectX could be used to interface with modern touch screens but having gotten one to play with I see it's definitely not the case and one needs to use the Windows Touch system to interface to it.  However adding support for Windows Touch necessitates the cessation of support of Windows XP so I had left it alone not having privileged people hound me for it.  Now of course XP is years out of support and I don't see very much evidence of it's use with DMDX so will go down as the last version supporting XP (although I suspect was the last one that operated with XP) and will be set aside and always available in the legacy downloads.  All hail the king, we now have version of DMDX supporting the new windowstouch 2Did pseudo input device.


      Recent work takes DMDX up to version and includes the support of generic PIO devices, dramatically tighter parsing of parameters to keywords, comprehensive Unicode support for East Asian fonts (DMDX will now translate double byte code page references to Unicode correctly so that item files that contain mixed Unicode and double byte code page references found in Vietnamese item files for instance now work) and a built in introduction/demo item file that made me nicen up a number of DMDX's features related to textual display (you can tell retirement can be a tad, unchallenging, shall we say)...


      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 to support AMD's FreeSync and NVidia's G-Sync technology along with a couple of new test modes (14 & 15 in version 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 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 the fish...


      And in right quick time we have DMDX where we exploited the new 3D rendering path to support NVIDIA 3D Vision stereo shutter glasses... 


      OK, it's time to release DMDX 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 released to check the new 3D rendering path needed for rigorous tachistoscopic performance under Windows 8. 


      DMDX 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 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 adds data logging functionality to the 2D input devices added in


      DMDX 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 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 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 work proceeds.


      I thought I'd just whip out a RTF to HTML converter for windows help files, wrong.    Instead, after days of head pounding recursive call nightmare debugging sessions we now have a rather finely crafted RTF2HTML utility with the resulting Help files now online at: and    The ASCII art is still kludged but at least it's usable now, after spending a day looking at what I'd have to do to automate bitmaps in the .RTF file that could either produce .HLP or .HTML the kludge and the ASCII art don't look so bad at all.


      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 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    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 IMG2BMP is 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> switch.


      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 64 chipset.
      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 a bit.


      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 the file.


      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 I imagine.


      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.    Sheesh.


      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 without which life would be much harder than it currently is.


      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).

Should you really want to communicate you can eMail to: jforster@someplace.spam.dont.go

The Top.