| 0 | Turns off the test mode.
|
| 1 | Turns on the Display Test Mode. When DMDX is waiting for a request and there is no active display it displays a test screen with information about how well DMDX is keeping track of the vertical retrace.
|
| 2 | Turns on the Millisecond Callback Latency test. When DMDX is waiting for a request and there is no active display it displays a test screen with information about the millisecond callback latencies. Currently a particular routine, called millisec() should be called by the OS every millisecond, it is responsible for polling input devices and turning clocks on and dispatching sound event related tasks. Win32 not being a real time OS this does not in fact occur at exact millisecond intervals and can in fact have large latencies, this test mode allows one to see exactly what latencies are involved. The latencies reported by this test measure the error in polling the PIO12 and Joystick (and RawJoystick) input devices (amongst other things) and not interrupt driven devices like the keyboard or the mouse (see testmode 6).
|
| 3 | Functionally equivalent to test mode 2 but it only monitors millisecond callback latencies while the display is active.
|
| 4 | Turns on the Sleeping Interval test. Prior to DMDX flipping the display so the next display buffer becomes visible the vertical retrace routine sleeps for as long as it calculates that it is safe to sleep for to allow the movingimages() routine to move something into the last display buffer to deal with situations similar to the tachistoscopic acid test (many single tick frames) as there is no other time under those circumstances to move those displays. This test measures whether the machine is in fact sleeping for the requested amount of time as a sleep here of longer than intended would generate a display error.
|
| 5 | Functionally equivalent to test mode 2 but it only monitors millisecond callback latencies while DMDX is waiting for an input.
|
| 6 | Turns on the Positive Response Latency test.
This test and others like it require
external hardware to close a key contact on a regular basis. When DMDX is waiting for a request and there is no active display it displays a test screen with information about the positive response latencies. This test was designed to enable us to measure the variability (if any) induced by the OS by measuring the keyboard autorepeat keystrokes, however due to the fact that DirectInput filters a keyboard's autorepeat keystrokes the test looses most of it's use (grrr). If you build a circuit that closes a switch on a regular basis you could see what variability (if any) is present in RTs from various devices (see Input) without having to trigger things from the CRT thus eliminating a small source of variability. If you use the PIO12 input device it's inter-trial polling interval should be set to every millisecond (instead of every ten milliseconds) with <id pio12 1,1>.
It should be noted that test mode 6 is an extreme worst case scenario as a new frame is being displayed as soon as the previous is assembled (on most machines this would be every other tick), a more realistic test is to use test mode 8 on items similar to those used in your experiments.
|
| 7 | Functionally equivalent to test mode 6 but it only monitors positive response latencies while the display is active.
|
| 8 | Functionally equivalent to test mode 6 but it only monitors positive response latencies while DMDX is waiting for an input. In order to make this test mode have any meaning at all DMDX will never actually see a response, it will simply record the latency data.
|
| 9 | Functionally equivalent to test mode 6 but it stores RTs instead of positive response latencies. This is designed for use with a
phototransistor triggering off a white display some fixed number of ticks after the clock is turned on that is hooked up to some response device allowing a real world test of latency and variation of different response devices. The test only stores positive RTs (ie, correct ones) should someone ever want to use the test for another purpose.
|
| 10 |
Input Device button monitoring. With TestMode 10 active any new
input
devices will list all their buttons in the diagnostics (both on screen and in
diagnostics.txt), any button mappings in the item file will be listed and as
buttons are pressed their names will be listed. Along with the human
readable name the decimal values of each character in the button name are
listed to facilitate debugging any weird font issues.
|
| 11 | Not Used.
|
| 12 | Monitors duration of millisecond callback, should always be 0.0ms or at worst 0.1ms. This is a useful test when using InstalCal drivers and the QPIO12 input device as the polling of the devices is done in the callback. If the duration of the callback rises nastily when using QPIO12 only polling every other millisecond should be considered (see <id>). Fortunately all machines tested so far have negligible values in this test.
|