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 send mail to
DMDX-request@psy1.psych.arizona.edu with the word "subscribe" by itself with
no quotes and no HTML, MIME or otherwise styled text in the body of the email
(not the subject). Once your subscription is confirmed posts
can be made to DMDX@psy1.psych.arizona.edu.
Please don't send attachments to the list.
The list archive (with a searching facility) is available at:
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 98, 98SE, ME, 2000, and XP (recommended) coupled
with DirectX 7.0 (or later, DirectX 5.0 at the very least). 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.
NT is not recommended at all and probably doesn't work anyway as the latest versions
of DMDX require versions of DirectX that NT doesn't have. Windows
98SE was preferred over 2000 and XP because WDM device drivers were hard to come
across -- but lately these are available so the stability of XP makes it my favorite.
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 waist machine, not by 1997's standards anyway -- most 1998 boxes were
adequately equipped however and anything you buy these days is fine.
DMDX is written so that it is mode ignorant and if people want to use 16 million
colors they can, they will of course not be able to move as much data around as
when using 256 colors on some older video cards (although oddly enough some later
video cards are faster moving 16 bit video data [65535 colors] around than they
are at moving 8 bit data [256 colors]). The catch with DirectX
is that each vendor of hardware must provide DirectX drivers (in our case 5.0 or
later with 7.0 being preferred -- this is important as DMDX uses features found
in 5.0 not previously available, however only 95 flavors of Win32 come with pre-DirectX
5.0) and DirectX is only as good as the drivers for the given device.
This means DMDX is only going to work with any degree of certainty on hardware made
after 1998 or so, if you are technically skilled you may be able to get DirectX
working with pre-1997 cards, however there was a lot of moaning on the web from
people trying to get DirectX to work with older hardware -- if you have questions
contact the builders of your sound and video cards and get the latest DirectX drivers.
If you are using brand spanking new hardware 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.
FAQ.
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:
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).
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 Direct X version 5?
A. Yes, it now requires DirectX 5 although
DirectX 7 is recommended (under some circumstances it will need DirectX 7).
Also works with DirectX 6. And 8 and 9 and whatever gets released in the future
as backwards compatibility is part of DirectX.
Q. Does it work with NT?
A. It might, but you sure won't be able to use the
PIO12 or RawJoystick input devices as these access IO ports directly, a big nono
under NT and Windows 2000 (and XP).
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. At this moment I am sure the syntax
of the VM extensions is not going to be supported, at least initially.
For a start I am not sure that there is a lot of use of these anyway and secondarily
DirectX provides additional abilities that a lot VM deliberatly goes to some length
to prohibit (notably overlapping, DirectSound provides on the fly mixing).
Thirdly, VM assumes I can keep absolute sync with the retrace, it maps out the
whole item's speech before hand -- this is not possible in DMDX, some on the fly
rescheduling may be necessary as sync is restored. Sounds bad,
I know, but this is the price of the Windows environment. 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,
here .
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:
Two video cards. You can plug two PCI video
cards into a machine (or one AGP and one PCI) and one can be used one for an experimenter's
display and the other for a subjects display, however you will have to have Windows
98 (or later). The Hercules monochrome video card is definitely
not supported, and the experimenter's display winds up being the
primary windows display. If you have to save bucks I guess you
can get mono-VGA monitors but they are becoming just as hard to find as Hercules
cards are.
'98's multimon features are only supported on the
later memory mapped video cards (no I/O ports). Cards based
on the Cirrus Logic 5446 and the Tseng Labs ET6000 are the oldest cards that might
work, see the text file Display.txt in your /WINDOWS directory for a list of MultiMon
display adapters, also see the
Multi-Monitor Compatibility
Database (if it's still up).
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
output).
DMDX will indeed be able to use all manner of devices
as long as DirectX can see them (ie, you have drivers for them).
An interesting thing looming on the horizon are Universal Serial Bus (USB) devices
-- keyboards, mice and everything to do with input are going to move to this standard,
the interesting thing for us (besides ease of installation and DirectX drivers
etc) is that the baud rate of this bus is in the 100 kbps range, meaning that
almost all devices are going to become much better candidates for DMDX.
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.
Looks like the USB support will only be found in
DirectX 6.
I have recently had the opportunity to test a USB
device, the Microsoft USB IntelliMouse, however the results were lackluster with
a standard deviation of 3.96ms (and that's without a ball).
I figure commands are buffered up into big blocks for transmission and this introduces
the horrible sd.
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, pretty much all of the
hardware listed here is from the dark ages when the hardware was built before
the drivers were written. Nowadays everyone knows they're going to have to
be writing WDM drivers (the type that Windows XP uses) so hardware compatibility issues are very
rare. 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.
Whole Systems
DELL Inspiron 3000 This laptop
functions beautifully. It already had Windows 95 OSR2 on it
which comes with DirectX 2 so I simply loaded up DX5ENG.EXE, the english runtime
portions of DirectX 5 and let it install itself (typically if there is already
a version of DirectX on a machine a later version will function, usually a lot
better than the earlier one). It complained that it didn't
recognize the Crystal sound system on the machine and I took the recommended
path and left the existing drivers alone (I've mucked with Crystal sound chips
before, they're best left well alone once functioning). I
ran TimeDX and everything is as good as it could be, a 200MHz CPU being more
than enough for normal DMDX operation. I then ran DMDX with
the features test item file and all appears well, the sound portions functioning
nicely as well. Only fly in the ointment is that the default
video mode that DMDX uses is 640x480 and on the DELL Inspiron 3000's display
this has some not so terrific pixel stretching -- however using 800x600 as a
video mode is just glorious, the machine has just enough video memory to use
800x600 in 65535 color mode, the color mode that the feature test needs.
Video.
See the text file Display.txt in your /WINDOWS directory for a list
of MultiMon display adapters, also see the
Multi-Monitor Compatibility
Database (if it's still up). Pretty much all new cards are
going to work well these days, anything based on the NVIDIA Riva128, TNT or TNT2
chips should be fine along with the Matrox G200 and G400 chips, the G400 might
be especially good for Multimon purposes. Any other new chipsets
are probably going to be just fine too.
ATI Radeon 7500 cards.
Don't recall having
any trouble with it when I had one in my XP machine.
NVIDIA TNT Cards. All TNT1 and TNT2 cards
are top performers. Coming with 16MB or 32MB of video RAM
and super fast blitters it's hard to get a better card.
Matrox G400 Cards. Work well and the dual monitor
capabilities
of the G450 are very sweet as long as you are actually using a computer monitor
for the secondary display and not using an NTSC monitor in which case you can
forget it.
ATI Rage Pro. Works nicely and the versions
of it with NTSC output on them actually work when using a NTSC monitor.
Hercules Terminator 3D. Just installed
a pair of Hercules Terminator 3D (T2314EDO) cards (based on the S3 Virge) in
a system and they function flawlessly for 98's multimon uses.
The trick appears to be to get cards that the manufacturers say support multimon
and that have drivers that ship with the 98 CD.
Matrox Millenium. A user reported to
me that it's not so good, it can come with a lot of memory but not all of the
memory is available to DMDX for screen buffers (half of it is reserved for 3D
textures).
ATI Rage/Rage II. A user reported to
me that it functions nicely and comes with 8Meg of ram all usable as screen
buffers.
Tseng 6000. Very nice chipset, appears
to work well with the DirectX 5 drivers.
Hercules Dynamite 128. Nice card, comes
with 4meg of video memory so most display sequences would be buffered completely
in display memory. The machine it's installed in looses somewhat
worrisome (but by no means crucial) amounts of time (the retrace thread repeatedly
goes to sleep for ~25 milliseconds when it shouldn't sleep for more than 13
milliseconds), however it doesn't appear to be affecting things.
The lost time could well be coming from another source other than the video
card. The card also suffers from the same Special Gotcha that
the Diamond Virge does (below) however not to as bad a degree -- in any event
the default state for TimeDX these days is to not use GetScanLine() anyway. Although... I just noticed that the
last buffer (of the 12 or maybe the primary itself) leaves a few stray pixels
of white if the background is changed to gray repeatedly.
Admittedly an unusual thing and overrideable I found by setting the -buffers
command line option to 8 (11 didn't work) but it indicates a hunt for later
drivers may be in order if you have this card.
Seems to work a lot better if DirectX 5's Tseng 6000
chipset drivers are used instead of Hercules' drivers.
Cirrus Logic 5465 AGP. Nice card, shame
about the drivers. Comes with 4meg of video memory so most
display sequences would be buffered completely in display memory however the
drivers will only let one back buffer be used (instead of the 12 available at
640x480x8bpp) which reduces the card to near VGA usefulness, the only thing
going for it is the blinding speed of the systems it comes in and the AGP port
itself.
Given the fact that the drivers cause a protection
fault if I ask for more than a single buffer they might fix it.
Version 1.60 of the drivers crashed, 1.70 just thows a general fault... so use
the newly implemented buffers command line command.
Diamond Virge V330. Nice card, comes
with 4meg of video memory so most display sequences are going to be buffered
completely in display memory (a very good thing). Special Gotcha! God
damn, there I am trying to figure out why DMDX on the development box has stopped
telling me about perfectly obvious to the eye display errors when all the other
machines are still functioning perfectly. Of course, I put
a new video card in a while ago so I go run TimeDX again, the values are slightly
off so I test them and Whoa! No errors at all, wow I sure
did a good job with those routines. Not that I like to disbelieve
my own prowess I go run the test again, hmmm, that's odd, the automatic values
for the retrace duration is 13.345 yet the calculated value for the retrace
in the actual advanced test is 10.023, little alarm bells start going off.
So I manually change the values to reflect a retrace of 10ms and the value drops
again! Matter of fact it follows the sleep time exactly, the
vertical sync thread test for testing whether the retrace is active is always
true! No wonder DMDX reported no errors.
Closer inspection shows the card to be the second
that I've tested that supports GetScanLine(), however this card's
implementation
of GetScanLine() is broken so I've had to add a special flag to override the
use of GetScanLine() in TimeDX's Vertical Retrace Thread Sync.
Diamond Stealth II S220. Nice card, comes
with 4meg of video memory so most display sequences are going to be buffered
completely in display memory (a very good thing).
I notice the latest drivers over on Diamond's homepage (http://www.diamondmm.com/products/drivers/stealth2-s220.html)
mention MultiMon support, having tested them I can testify that they lend a
whole new meaning to the term "bleeding edge" -- I'd wait for some later drivers.
Although it's drivers are still a bit green, I've
designed DMDX in such a way as to avoid the driver's sore spots, the only bad
stuff is TimeDX (one day I might make TimeDX avoid the sore spots too).
ATI Graphics Pro Turbo PCI (mach64).
A very good chipset (it's built in to my mother board), fast blits and it's
the only thing so far that supports the GetScanLine() function so the code has
the least trouble maintaining synch with the retrace.
Cirrus Logic 5430/40 PCI. Slowest card
I have that works, however still emanently usable.
S3 Trio64V+. Nice fast Blits, possibly
the fastest (blitting speed is affected by more than just the video card) amongst
the old cards. The Diamond Steath Video 2001 cards are based
on this chipset.
Only card found so far that functions as a secondary display device
with Windows 98.
Interface Cards.
DMDX can use an 8255 based interface card for input and output.
With the code in TimeDX that allows setting the base address of the interface
card from a registry key PCI interface cards become a much more viable option
although having added InstaCal and DriverLINX interfaces these are a much better
choice.
MetraByte PIO-12. The original ISA interface
card, it still works. There's a PCI equivalent that works
as well.
ComputerBoards CIO-DIO24. The clone we
use when there's an ISA slot available from
http://www.measurementcomputing.com.
The 8255 is socketed so that when you blow one up or it just dies from old age
as they appear to do you can replace the 8255 for a few bucks instead of buying
a whole new interface card. There are high current versions
available as well, all of which should work.
ComputerBoards PCI-DIO24. The clone we
use when there isn't an ISA slot available from
http://www.measurementcomputing.com.
Currently the 8255 isn't socketed, I asked tehm to consider socketing it so
maybe it'll happen some day. But the 8255 in this card isn't
a standard device, I don't even know if you could buy them, it is discrtete
however so replaceing them isn't a theoretical impossibility.
Not that I've seen any of the PCI devices fail yet but we've only used one of
them for a year versus many many ISA cards for many years.
Computer Boards InstaCal drivers. Computer Boards
InstaCal Universal Library drivers can be used for Computer Boards interface
cards under Windows 2000 and XP.
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
for instance.
Monitors
TFT / 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
the
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. Tick values in the 10ms and less range are now possible without having
to re-program the number of scan lines, a kludge of less and less value as time
goes by and hardware diverges from the SVGA specification. To
get these fast refresh rates, 100Hz and above, you need an above average monitor
and a recent video card, say something based on the NVIDIA Riva TNT2 or the Matrox
G400. I haven't personally tested any of these monitors except
the DigiVIEW, various developers have reported the capabilities of these devices.
DigiVIEW 19" HR-75. Handles 640x480 at
150Hz, 1024x768 at 100Hz (maybe the GeForce MX's limits).
Panasonic "Pro 7G" Happy running 640x480
at 160Hz.
IIyama "Vision Master Pro 400" Runs at
up to 200Hz.
Philips 17" Bought in 1994 and does 100Hz.
Sound Output Only
PAS16. Unfortunately the DirectX drivers
for this card that ship with the original Win 95a are inadequate to say the
least. Having installed '95 OSR 2 (specifically skipping all
the media stuff) on a box with a PAS16 in it that PAS16 now works properly.
Ensoniq Soundscape. Works nicely.
Seen some bad stuff in the news groups about one of their later cards (ESS 1868)
causing some trouble with DirectX 5.0 though. ALTHOUGH, having just run the sound
latency stuff at home playing a 50ms file every 100ms and having it get periodically
played in both channels instead of just the left I am less sure of this card's
capabilities.
Crystal CS 4232 based cards. They work,
but only just. The drivers used on my machine have the dreaded
(emulated) after the driver name and the Sound Latency test cuts it to
ribbons. ALTHOUGH, having just re-built the entire development
system with a concommitant upgrade to OSR 2 the Crystal Sound drivers now no
longer have the dreaded (emulated) after the name and indeed are no longer
shredded by the Latency test.
SoundBlaster 16. Works nicely.
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.
Sound Blaster 16 PnP. In the test system
it would appear that it can get overloaded at times but generally it works and
for an older card handling input as well is amazing.
Turtle Beach Montego A3DXstream. As expected
of all new hardware, it works nicely.
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.
Input
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:
Whole Systems
Built in or integrated video motherboards. To make
machines cheaply a lot of companies are building machines that have the
video card built onto the motherboard. Most of these use the main
memory of your machine for the video display so you see things like 448 MB of
RAM in a computer instead of 512 MB. In the past these have been of
questionable value for DMDX machines, however these days CPUs and busses in
general are so stupid fast for DMDX's purposes they're just fine unless
you're wanting to really thrash the machines capabilities with large high
def video for example.
DFI Mother Boards. Time and
time again a system that is functioning weirdly is found to be based on a DFI
mother board. Problems range from periodic crashing to inconsistent
PIO12 functionality to windows constantly reporting that the display adapter
is not configured correctly. Avoid DFI products like
the plague.
Cyrix Processors. Some Cyrix processors
(if not all of them) don't have the high performance timer that is present in
the Pentium chips so DMDX timing will be on the undesirable side using them.
Can't say which processors, I don't have any of 'em but the Unreal game has
had to have a bunch of it's code re-written on account of the above.
Ken maintains a 486 runs DMDX just fine (which would use the same timing code
as the the Cyrix processors in question) -- well, it might look good but I'll
tell you this much, it won't be telling you when it sticks a frame up for an
extra tick.
To test it use TimeDX's Millisecond test, if you
can't enable the high performance timer then it isn't there.
Packard Bell. Heard people having no
end of trouble with their older sound cards.
IBM Aptiva. They don't (or didn't, you
check) support DirectX 5.0
Compaq ProLinea (and Compaqs in general).
These guys hardly even Supported DirectX anything, they build so much custom
hardware that to support something like DirectX on all their hardware (old and
new) would take man years of effort and it doesn't sound like they've put much
effort into supporting what they are selling let alone old stuff.
Portables in general. Once again, custom
hardware goes into almost every single different model (let alone manufacturer)
so driver support that works well with DirectX is generally thin.
Although, see above DELL Inspiron 3000, this laptop functions
flawlessly (well, as flawlessly as DMDX runs). NOTE: Users of laptops may need to pay closer attention to the use of
the high performance timer. This timer can be derived
from the RDTSC instruction available on Pentium 5 and higher CPUs, it's count
is based upon CPU clock frequency, something that normally doesn't fluctuate
-- however a laptop can switch it's CPU clock for it's low power standby, so
some care needs to be taken to make sure the laptop isn't in any a low power
state. For example if the user starts DMDX while plugged into
the wall, then switches to battery, the CPU MHz may drop from 133 to 90.
If I had a laptop I could offer some advice, I don't so I can't.
Video
SIS 650 video chipset computers.
Beyond video
displays that are built onto the motherboard being shoddy affairs at the
best of times I suspect this video chipset is less than terrific for DMDX's
purposes. While I haven't personally encountered DMDX having trouble
with these chipsets I strongly suspect they or their drivers are no good.
NVIDIA GeForce cards. Just got an interesting
reply from NVIDIA about the GeForce MX lockup DMDX induces.
Turns out that the lockup is likely to occur on all GeForce video cards as the
long flipping chains DMDX creates are using up hardware resources on the card,
all previous video cards used RAM resources to create flipping chains and were
essentially unlimited. Seeing as most of these GeForce cards
are way beyond what you need for DMDX (in both performance and price) not many
people are likely to care although the GeForce MX is a really sweet card for
$110. However, it's is NVIDIA's chipset which means that eventually
all of their hardware will be based on it and because NVIDIA are the
power in video cards right now it's certain people will be using the GeForce
chipset with DMDX at some time in the future. Sounds like
NVIDIA have got better things to do that to fix a problem in their drivers that
only a small number of scientists are ever going to encounter so the remedy
is to run DMDX with a shortcut like this:
C:\DmDX\dmdx.exe -buffers 4
It's probably not going to be as good as TNT1 or
TNT2 because that's a pitifully small number of buffers but the day may come
when you have no choice. Hopefully by that time NVIDIA will
have fixed their drivers but it sounds like a pretty major thing to fix so I'm
not holding my breath. Oddly enough 1024x768x16 works without
the override and it is using something like 21 buffers.
ATI Radeon VE cards. And there was I
complaining about GeForce cards needing the number of back buffers restricted
to 4, ATI's Radeon VE needs to have the number reduced to 1.
Maybe it's better with XP but I'm not willing to try it, I tried all versions
of their drivers under Windows ME but all fail miserably.
STB Horizon 64 PCI. Probably (hopefully
for STB's sake) designed before DirectX was a glimmer in Bill's eye.
I tried my hardest to make it fly, wrote code that does not use page flipping
(makes tachistoscopic presentation very bad) and wrote code that does not use
WaitForVerticalBlank(), but when it cheated by returning immeadiatly from GetVerticalBlankStatus()
I gave up, it just does not have enough to work with. This
is very old card by PCI standards, and I thought STB made rather good cards
personally, but this little joke of a card has me wondering.
In light of further research on the matter the card
might be able to be made usable if you could find DirectX drivers for it, I
couldn't. The symptoms indicated above are the symptoms that
you get when DirectDraw knows nothing special about the card and just provides
some generic VGA functions.
Sound
None. Almost any sound card can
be made to function with DirectX (excluding some of the Packard Bell cards),
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).
Input
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.
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. These are the versions we use.
DMDX binaries and demos are here.
The DMDX digital video demo is
here.
Should you be having trouble with DirectX you might
want to check out Microsoft's
FAQ.
Progress to Date.
03/12/09
DMDX 3.3.0.2 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.
09/13/06
DMDX 3.2.0.1 adds data logging functionality to the 2D input devices added
in 3.1.0.0.
10/14/04
DMDX 3.1.0.0 dramatically increases DMDX's scope
with the ability to handle 2D inputs for touch screens and a special mode to
handle the system mouse.
12/12/02
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 3.0.0.13 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.
07/29/02
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
work proceeds.
12/26/00
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:
http://psy1.psych.arizona.edu/~jforster/dmdx/help/dmdxhdmdx.htm and
http://psy1.psych.arizona.edu/~jforster/dmdx/help/timedxhtimedxhelp.htm.
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.
10/10/00
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
http://psy1.psych.arizona.edu/~jforster/dmdx/directx/.
08/07/00
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).
05/23/00
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.
05/20/00
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...
07/22/99
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.
06/07/99
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 DMDX-request@psy1.psych.arizona.edu
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
http://psy1.psych.arizona.edu/cgi-bin/DMDX/thread
.
05/04/99
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).
04/23/98
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.
04/12/98
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.
11/10/98
Stuck a few semantical checks in to 0.22b to catch
obvious errors with clockons, missing CRs and frame delimeters.
10/28/98
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.
10/13/98
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.
9/30/98
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.
9/25/98
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).
9/10/98
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.
8/20/98
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).
8/19/98
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]).
7/17/98
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).
6/23/98
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.
5/18/98
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).
5/14/98
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.
5/7/98
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.
4/28/98
Put a syntax check only mode in that quickly checks
syntax and media files used.
4/16/98
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.
4/8/98
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...
3/27/98
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...
3/19/98
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.
3/13/98
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.
3/11/98
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!
3/7/98
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.
3/4/98
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.
3/2/98
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.
2/13/98
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'.
2/10/98
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).
2/6/98
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.
1/28/98
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...
12/11/97
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.
12/01/97
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.
11/18/97
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 $ $.
11/13/97
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.
11/03/97
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.
10/24/97
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.
10/21/97
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.
10/17/97
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.
10/15/97
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.
10/13/97
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.
09/24/97
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.
09/20/97
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.
09/16/97
After a break for illness and other projects I am
back at it. The PIO code is completed, now the sound code.
08/01/97
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.
07/16/97
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.
07/13/97
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.
06/27/97
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.
06/12/97
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
currently is.
06/04/97
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.
05/29/97
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.
05/14/97
Font selection code in TimeDX done.
First bug in DirectX circumvented, must not release a DirectDrawSurface until the
derived DirectDrawSurface2 is finished with. Sometimes.
05/05/97
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).
DMDX Updates
Page.
As a general
rule all new hardware is going to work with DMDX, pretty much all of the
hardware listed here is from the dark ages when the hardware was built before
the drivers were written. Nowadays everyone knows they're going to have to
be writing WDM drivers (the type that Windows XP uses) so hardware compatibility issues are very
rare. 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.
To make
machines cheaply a lot of companies are building machines that have the
video card built onto the motherboard. Most of these use the main
memory of your machine for the video display so you see things like 448 MB of
RAM in a computer instead of 512 MB. In the past these have been of
questionable value for DMDX machines, however these days CPUs and busses in
general are so stupid fast for DMDX's purposes they're just fine unless
you're wanting to really thrash the machines capabilities with large high
def video for example.