TimeDX(This page is based on the TimeDX Help file)
TimeDX is designed to allow you to test all components of DMDX before using it in order to make sure that the whole lot works individually and in combination. This is doubly true for the various video modes that DMDX could use, since their refresh interval must be examined in order that the retrace can be correctly anticipated. This needs to be done for each different video mode used.
The steps in using TimeDX are as follows:
Step 1.
Check that the Millisecond Timer is functioning. Fortunately for us the Multi-Media extensions to Windows include a timer callback that does not suffer from all the bad things that a regular timer in Windows does, however originally under Windows 3.1 there was little chance of a single millisecond timer being of any use so the timer had a system definable resolution. Under Windows 95 this resolution appears to always be 1 millisecond (very fortunate), however seeing as it could change it is wise to check it none-the-less. This test is only really of importance if the high performance timer is not present, if said timer is available all the callback is likely to be used for is for polling the PIO.
Step 2.
Check that the Video Mode you want to use works. In order for DMDX to use a given video mode the video card must be capable of having two buffers of data, so for 640x480 with 16 bit color you need to have a video card with more than a megabyte of video memory -- this test will tell you what you can and cannot use. Note that if you are re-programming the number of display lines each different number of lines is considered a different display mode.
Step 3.
Time the video mode’s Refresh Rate. This test does nothing fancy so it’s values are slightly skewed (unless the high performance counter is being used in which case it’s results are rock solid), however leaving it timing the retrace for ten or twenty seconds will give a very good result. You want this for Step 5.
Step 4.
Next you are going to jump ahead to the Advanced tests. Check that the millisecond clock and the system clock keep pace with each other while there is a bunch of Video activity. This step is optional, you may only perform it once for a single video mode or go back to it if Step 5 is hopelessly broken.
Step 5.
This one’s a big test, another Advanced test, you are going to fire up the Vertical Retrace Sync Thread and determine the values that will let DMDX synchronize itself with the vertical retrace. The value from Step 3 will be useful here, as the retrace thread is running it provides a successive value of the retrace interval based on it’s current ability to synchronize with it, if you are not seeing the value from Step 3 then you can try resetting the running values or if that doesn’t get it you’ll have to tune the values.
For each video mode you might use you will have to perform Steps 2 and 5, with Step 3 being a real aid. The values you determine will be written to the registry where other routines can retrieve them when they wish to synchronize with the vertical retrace -- which I figure is eons ahead of having to always wait several seconds as video modes are changed for the automatic routines to determine the characteristics of the new video mode. The down side is that if you ever change video cards you will have to re-time all the video modes.
For now ignore the Sound Buffers, one thing at a time.
The important things to remeber here are that the test has to be performed before the results can be saved to the registry and that until you do this DMDX will not run, instead it will be complaining about registry keys missing.
Step 6.
Use the Tachistoscopic Acid Test. This will check whether your machine is in fact capable of running DMDX, or to what degree it is capable of it.
Again, ignore the Sound buffers.
Step 7.
Now you can play with the Sound stuff. Pick some .WAV files and play them. During this and the next few sound related test if you notice less than stellar performance from your sound card you may want to choose a different Direct Sound driver, some drivers are less than excellent (and, no, I don’t know why more than driver one can appear).
Step 8.
Next you want to go back to the Advanced test and tell it to play a few buffers as well, see if the parameters need more tuning, it is normal for the error rate to got up a bit. Then you want to go to the Tachistoscopic Acid Test and see that it still works while playing sound buffers.
Step 9.
Use the Sound Latency test even if you don’t have a oscilloscope as this test really cuts the duds out. Of the three sound cards I had decided were OK two failed (one miserably) just playing the audio portion of the test, I didn’t need an oscilloscope.
Step 10.
Use the Input test to see how the various input devices you might want to use perform. The names of both input devices and the buttons on then will probably be needed for DMDX as the item file will more than likely wind up specifying which input device to use and which buttons are the correct, incorrect and request keys.
Step 11.
If you are going to using a PIO then you will want to set up it's address with in the PIO Test test, and if you are going to be using another machine to monitor DMDX then you will want to set up the network address with the Network Monitor test.