Data and theoretical estimates reported by Segalowitz and Graves (1990) and Crosbie (1990) regarding delays of serial Microsoft mouse response registration are corrected and extended. Empirically measured mouse responses clearly confirm a theoretical minimum delay time of22.5 msec for Microsoft-compatible serial mouse devices. Timing accuracy of key actions for the serial, bus, and PS/2 mouse devices are presented. SERIAL MOUSESegalowitz and Graves (1990) present timing details for the serial mouse and recommendations concerning time corrections. Although the reported delay times of the serial Microsoft mouse seem to be valid, the theoretical estimates of the transfer rate of the Microsoft mouse were based on an incorrect assumption. The Microsoft mouse transfers a 3-byte information block at 1,200 baud, with 7-bit word length, and 1 start and 1 stop bit. Thus, 27 bits (9 bits x 3) are to be transferred for each information block, and this takes at least 22.4999 msec.Segalowitz and Graves (1990) assumed a 5-byte block similar to the Mouse Systems mouse. On the basis of that assumption, and ignoring the data format of serial communication, they derived the number of bits to be transferred on each block (5 x 8 = 40) that would produce a minimum delay of 33 msec. In addition to the wrong generalization from the Mouse Systems mouse to the Microsoft mouse protocol, the published measurements also contain inconsistencies. For example, although the minimum transfer delay is estimated at 33 msec, the authors reported 25 msec as the shortest recorded interkey interval, and a mean delay of 31 msec.To determine the minimum delay, both mouse keys of a Microsoft-compatible NCE Hypermouse 860/PC were electronically connected via an open collector circuit with the parallel interface of an 8-MHz AT clone. Mechanical influences of the mouse buttons were therefore not included in the tests. Standard features of the Experimental RunTime System (ERTS)l were used for validating mouse response registration. ERTS includes output via the parallel interface as well as interrupt-driven mouse registra- tion via a user-defined event handler (Microsoft, 1986;Rinck, 1988). Trials were defined in such a way that ERTS itself triggered the mouse responses 100 msec after the beginning of response time registration.A moving mouse was also found to distort the delay times by as much as one information block (Segalowitz & Graves, 1990). All measurements were therefore made with the mouse ball removed. The mouse cursor was turned off in all test situations to avoid extra execution times of the mouse driver. Cursor updating may cost considerable time and is even sometimes synchronized with the vertical retrace. Table 1 lists the recorded mouse registration times for the NCE mouse and Version 6.13 of the Microsoft mouse driver. Keypress times were varied in 5-msec steps, from 5 to 35 msec. The true response-delay time was 100 msec. On the average, observed values for the make action (key pressed) are delayed by 24.4 msec. This result is clearly in lin...

The Experimental RunTime System (ERTS) is a software package for developing and running nonadaptive, trial-oriented reaction time experiments (Beringer, 1993). ERTS is based on a special-purpose programming language consisting of a small set of high-level data types and commands, which can be used to formulate an experimental paradigm (average about 90 commands per paradigm). The experimenter is freed from using general programming languages (such as PAS-CAL or C) and from considering system-dependent aspects, such as timing accuracy, screen synchronization, asynchronous response registration, and graphics mode programming. The command files are created and edited with any conventional text editor. After preparsing the command code, ERTS directly executes the experimental session. ERTS outputs a results table that lists reaction times, responses, and other information in fixed-format ASCII for each trial. Because of the short command code and the high-level data type checking mechanisms, experimental definitions are more likely to be free of error than when conventional programming languages are used. An add-on software tool (ERTSCODE) is available for coding and transforming raw scores into factorial descriptive statistics. ERTS and ERTSCODE may be run in batch mode to automate experimental sessions and data management. Runtime performance is optimized. Response registration is exclusively asynchronous (interrupt triggered) and is not affected by ongoing stimulus presentations. The registration of make and release actions from standard keyboard, mouse, external keys (via LPTx), and voice-key (via soundcard) is supported. Response registration and event timing is controlled with millisecond accuracy, with the exception of hardware-dependent distortions of response devices (Beringer, 1992). Timing is accurate across trial boundaries, because results are stored only at the end of each block. Thus, continuous, trial-oriented paradigms (e.g., sustained attention tasks and tapping) can be realized. ERTS implements VGA graphics. Pictures are not screen oriented, but are defined, separate components that are independent of screen locations. Text and graphics pictures are both displayed in high-resolution graphics mode. Besides using the regular systemfont, text pictures may also be displayed in high-quality, large-scale

No abstract

No abstract

This paper presents an extension of the Graves and Bradley (1987) millisecond timer, which avoids potential measurement errors of 54.9 msec. The synchronization of the system timer count with the BIOS timer counter must be taken into account to eliminate such errors.Although there are many variants of language-specific implementations of millisecond timers (see, e.g., Brysbaert, Bovens, d'Ydewalle, & Van Calster, 1989;Creeger, Miller, & Paredes, 1990;Crosbie, 1989;Heathcote, 1988), there are only a few underlying algorithms for accessing high-resolution time on a standard mM Pc. Basically, such algorithms fall into two types: implementation of an interrupt-driven low-resolution software counter, or direct reading of the time out of the timer chip. Algorithms of the latter type are superior, because they produce no overhead for the CPU-in contrast with algorithms that implement interrupt-driven software counters triggered by system timers (Buehrer, Sparrer, & Weitlrunat, 1987;Dlhopolsky, 1988) or serial interfaces (Emerson, 1988b). A tradeoff between clock resolution and CPU processing overhead is always inherent in such interrupt-driven software counters.The algorithms presented by Graves and Bradley (1987) and Emerson (1988a) read the timer chip directly. Whereas Graves and Bradley's (1987) algorithm reprograms Channel 0 of the timer chip into mode 0, Emerson uses the timer in the standard mode 3, in which the timer counts down twice with increments of 2. Using mode 3 has some caveats, in that the status bit of the timer has to be taken into account and this mode is also not applicable on an IBM XT (Emerson, 1988a).Thus, the millisecond timer algorithm of Graves and Bradley (1987), which was originally introduced by Smith and Puckett (1984), is in principle the most efficient and precise timer algorithm available for the mM PC. After some testing, however, the algorithm turned out to be unstable with respect to the measured time delays by as much as 54.9 msec. Presenting a Turbo Pascal implementation of Graves and Bradley's (1987) algorithm, Bovens and Brysbaert (1990) also reported the same problems when using the original algorithm. Within their Turbo Pascal routine, they presented a correction method similar to the one suggested in this paper.The measurement error in Graves and Bradley's (1987) algorithm is not surprising from a technical point of view.The algorithm is based on reading the BIOS timer counCorrespondence shouldbe addressed to Jorg Beringer, Institut fiir Psychologie, Technische Hochschule Darmstadt, Hochschulestraf3e 1,6100 Darmstadt, Germany, ter of the BIOS Data Area at 0040:006C together with the fast running system timer count (ffiM, 1987). Concatenating both timer values results in a 16 +32 = 48-bit integer value, which represents the current system time in units of system timer ticks. The algorithm relies on the assumption that the BIOS timer counter is updated via INT08 without any delay. Unfortunately, this is not the case when interrupts are disabled. Although interrupts are di...