Some data acquisition board drivers or other plug-in modules may be using the same system timer that the beeper uses. If Daqarta detects that the timer is already in use, it alerts you instead by flashing the screen panel background color to black, then bright white, then back to normal.
You can preview the Alert with the &-key (SHIFT-7). The default tone frequency is 880 Hz for 1/8 second.
You can change the Alert to better suit your needs via CTRL-7. (CTRL-SHIFT-7 will also work.) This will prompt you to enter a frequency, and after you enter that you will be prompted to enter a duration. Then the new Alert will be given. This operation is identical to that for the User Tone... check that reference for more details.
The standard computer "beeper" system uses a tiny speaker with poor frequency response. You may need to try several different frequencies to get one that is clearly audible.
You may prefer to always use the flashing alert instead of a tone, or you may wish to disable the Alert completely. If you enter a negative frequency (-1 will do), the Alert system will rotate between Tone, Flash, Off, and back to Tone on successive negative entries. The new alert will be given immediately, so you will know which you have selected. You will not be prompted for a duration, and the existing settings for tone frequency and duration will not be changed.
NOTE:
A semicolon indicates that the remainder of any line is a comment and should be ignored by Daqarta. You can use this at the start of a line to temporarily remove a module from your setup, or after a module name to add an explanatory note.
NOTE:
The format for the first 4 lines of DQA.CFG is fixed.
Each line must be present in the proper order, or else
commented out or left blank. Subsequent lines may be
in any order and will load in the order they appear.
A typical DQA.CFG file might look like:
INIT ;May use M:0, F:0, B:n, or V:x params DEMO.ADC ;ADC module MUST come 2nd! SGRAM.PAL ;Spectrogram palette file MUST come 3rd! MAIN.PAL ;Main palette file MUST come 4th! ;Above 4 lines must be present in order, or leave ;placeholder (empty or ;) lines. ;Add-in modules follow, empty or commented (;) lines ;ignored: STIM3.GEN ;Stimulus Generator module DDISK13.DRV ;DDisk Write BIOS INT 13h replacement
The first line must start with INIT instead of a module name, followed by any parameters for initialization options. You may leave this line blank if no parameters are needed. Currently supported options are:
B:n Where n is 8 to 64 to set the STIM3 Buffer on an
absolute segment boundary for full duplex DMA
output.
F:0 To omit all Help Files. Normally used only when
in dire need of extra memory, since it only saves
about 24 Kbytes or so.
M:0 Tells Daqarta to look for DQA.MAC in the current
directory on start-up. Otherwise, it looks for
it in the directory that holds DQA.EXE. Allows
you to have different macro files for different
experiment types, each with its own directory.
V:x Force Video type, where x = E to force EGA
operation on a VGA graphics board, or V to force
VGA operation on an early VGA clone that doesn't
support video detection. Using V:v instead of V:V
forces the use of the standard BIOS function for
VGA palette updates. This is much slower than
Daqarta's direct method, so you may get an annoying
flicker on slower CPUs during palette changes.
However, this may be needed for some clone VGA
boards with non-standard register usage.
The EGA BIOS function is fast, and is used with
both V:E and V:e parameters. The V:e parameter
forces a black border (default for EGA boards),
while V:E allows the border to track Panel color
for emulating EGA with a VGA monitor, or for those
few EGA monitors fast enough to handle this. (If
not, you may see a retrace streak near the bottom
of the screen.)
The second line always holds the ADC driver name. Sometimes you may wish to use a system without an ADC board to analyze data collected elsewhere, or you may wish to experiment using the built-in test generator when no board is present. In this case, the second line must be left blank or commented out with a leading semicolon if you do not use DEMO.ADC other ADC driver.
Each driver or module entry must include the full name and extension of its file. Each file is assumed to reside in the same disk directory as Daqarta and the DQA.CFG file itself.
After the file name, on the same line, may come any parameters needed by that driver, such as board address, IRQ or DMA numbers, model number, conversion speed, or digital output port address. Each consists of a single letter followed by a colon, then the parameter value or string. Additional parameters are separated by one or more spaces. A typical example for the DAS16X.ADC driver instead of the above DEMO.ADC would be:
DAS16X.ADC M:DAS-16G1 A:h330 I:5 ;Comments here!
The parameters tell the DAS16X driver that the board Model is a Keithley Metrabyte DAS-16G1 or equivalent clone, whose base Address is at 330 hex, and which should use IRQ 5. You will need to consult the Help system for your particular board driver to determine proper parameter usage and value ranges. You can view this without a board, or without activating an installed board, via the A:0 parameter trick.
If you need to use a lot of parameters, the line may grow quite long. There is no arbitrary limit to how many characters you can include on a line, but for ease of viewing in your text editor you may continue on the next line by starting it with an underscore. This may be continued for as many lines as needed, with the whole works counted as a single line. For example:
INIT ;This is the 1st line. DAS16X.ADC M:DAS-16G1 A:h330 I:5 D:3 C:1 _ P:L1 R:2.5 S:E10 ;This is still the 2nd (ADC) line. _This comment is still part of the 2nd line. SGRAM.PAL ;This is the 3rd line. MAIN.PAL ;This is the 4th line.So even though the ADC line is three lines long, it is treated as the "second line" and maintains the required line positions of the following .PAL entries.
Any comments must appear only after all parameters, whether the entry is a normal single line or continued for multiple lines... you can't use multiple parameter lines, each with its own comment. However, once the comment begins, you can extend that over additional lines simply by starting each with an underscore as before, and they will all be counted as part of the original line.
Note that the underscore option requires that there be some text, either parameter or comment, after the file name on the original line. The line break must not come within a single parameter (like A:h330), but only between parameters or after the last parameter.
The third and fourth lines always hold the names of any default Spectrogram and main multi-palette files, respectively. If either or both of these is not used, the line(s) must be left blank or commented out.
Subsequent lines hold the names of plug-in modules that you wish to include, in the order that Daqarta will load them. There is a limit of 24 modules that can coexist at one time, including the ADC driver but not the two palette files. More modules may be loaded if they do not remain resident while Daqarta runs... for example, a module that just modifies an initial program setting, but doesn't actually install any extra code.
Check the documentation for any third-party plug-ins to see if they need to be loaded in a preferred order.
CTRL-ALT-HOME, depressed in that order, will break out of any active routine and return to the main Daqarta processing and key handling routine. This MAY allow you to save critical data to a file or otherwise recover from disaster. The message line will show:
Attempting Disaster Recovery...
There are a lot of unknowns and caveats here, however. First
of all, this can only work if the wayward module did not
disable the keyboard interrupt. Second, it is possible for a
module to insert its "hooks" into the main processing loop, so
that even if control is wrested from the faulty routine, it
may be passed right back to it on the next processing pass.
In an attempt to deal with this latter issue, beginning with Daqarta version 1.10 the CTRL-ALT-HOME sequence also enters Pause mode to halt additional processing attempts.
If you do need to use this in an emergency, be aware that there is no way to know what other damage the defective code may have done. The safest course is to immediately save any critical data to disk, then Quit Daqarta and restart, perhaps after editing out the suspected offending module from the DQA.CFG file. Do NOT assume that you can continue operating, or think that you can always recover a second time.
In short, there are ABSOLUTELY NO GUARANTEES with this! However, if it pulls your fat out of the fire even once, it will have proved worthwhile.
The main users of this feature are expected to be those who are developing plug-in modules, since code bugs are a fact of life in the early stages of software development. Sometimes just the ability to Quit normally without having to do a complete reboot after a crash can be a big time saver.
CTRL-ALT-DEL performs a "warm boot" from Daqarta just as it would from any DOS program. ALL DATA THAT HAS NOT BEEN SAVED TO DISK WILL BE LOST. This warm boot may be faster than the full system hardware test "cold boot" obtained by hitting the reset button, and it is definitely easier on your system than turning the power off and back on. However, just as in other programs, this won't work if the offending module has disabled the keyboard interrupt. If the Disaster Recovery Attempt gave the expected message, then CTRL-ALT-DEL will most likely work.
If you are using a module that is still under development, the programmer may request that you activate this display and write down the contents of specific registers if you encounter certain types of problems. Use of this display should not cause any problems during normal operation, since this feature just displays the registers and returns operation to where it left off.