At high sample rates using some A/D hardware (especially DAS-16 family and compatibles), you may experience channel jumping where the data from one channel appears on a different channel (i.e. the channels appear to “swap” in the middle of the frame). HEM Data has determined that this is a result of the behavior of certain Windows video drivers which causes this problem.

Background

Page 3-33 of the Intel 386DX Microprocessor Hardware Reference Manual states:

HOLD has priority over most bus cycles, but HOLD is not recognized between two interrupt acknowledge cycles, between two repeated cycles of a BS16 cycle, or during locked cycles.

In VDDINT.ASM of the Microsoft Windows 3.1 Device Development Kit, the following comment is found:

NOTE: this must be a byte move because 386 locks out DMA during word or dword move to video (byte wide) memory

Explanation

Though a bit unclear, if we assume that these two comments are referring to the same phenomena, then we conclude that DMA requests are suspended during the execution of REP MOVSW and REP MOVSD instructions in the processor. HEM Data has verified that the Rectangle API in Windows does execute a REP MOVSW to video memory.

HEM Data has verified and demonstrated that the standard VGA video driver supplied with Windows 3.1causes channel jumping, while an OEM supplied video driver for the same machine does not. Windows 95 also exhibits the same symptoms. Therefore, the channel jumping syndrome will be machine (computer and video card) and video driver dependent.

Solution

There are four potential solutions to the channel jumping problem:

• Use a non-DMA pacing mode
• Change to a different video driver
• Use A/D hardware that has an on-board FIFO
• Change to a different motherboard