Home

Daqarta for DOS Contents

Introduction

Downloads

Free Registration

Contact Us

Daqarta for DOS Data AcQuisition And Real-Time Analysis Shareware for Legacy Systems

From the Daqarta for DOS Help system:

MISCELLANEOUS:

ALERT:

The Daqarta alert is a short beep under most conditions. It is used to notify you to check the message line when there is an error, and may also be used in certain other circumstances such as if you are trying to exceed some limit, etc.

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: If you set Alert to Flash or Off, the User Tone will automatically be set the same.

CONFIGURATION FILE:

This file, named DQA.CFG, gives Daqarta certain initialization instructions and tells it which ADC board driver to use, as well as which plug-in modules to install. This is a plain ASCII text file, with one module entry per line, that may be prepared with any text editor. Unlike the "installed" drivers used with hardware devices in many other systems, the modules loaded via this file will only be held in memory during the Daqarta session, so you will have your full DOS memory free after you Quit.

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:
 STIM3A.GEN     ;Stimulus Generator module

 DDISK13A.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 STIM3A 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.

DISASTER MANAGEMENT:

DISASTER RECOVERY ATTEMPT - CAUTION!

Daqarta is an "open" system, with specifications available to all registered users. This allows programmers to write custom plug-in modules for special applications. However, it also allows possibile problems to arise due to bugs in modules that are not part of the normal Daqarta package. Because the system was designed for "mission critical" use, where data may be difficult, expensive, or impossible to re-acquire, Daqarta includes a special key sequence to restore main program control in the event that a plug-in module gets hung up.

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.

SYSTEM REBOOT - CAUTION!

When a plug-in module causes a Daqarta lock-up, the first response if critical data must be saved should be the above Disaster Recovery Attempt. If that gives the message that the attempt is being made, it means that the keyboard is still able to respond. However, if this does not restore enough normal operation to save your data, you have no recourse but to abandon it and reboot your system.

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.

CPU REGISTER DISPLAY:

CTRL-ALT-INS will display the contents of the CPU registers at the instant of the key press by temporarily overwriting the Key Option area of the screen. This is unlikely to be of any value to the average user under any normal operation. It is included in Daqarta to facilitate debugging by developers who are writing drivers for new data acquisition boards or other custom plug-in modules.

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.

GO:

Questions? Comments? Contact us!

We respond to ALL inquiries, typically within 24 hrs.

INTERSTELLAR RESEARCH:
25 Years of Innovative Instrumentation