Software for the analytical laborato-
`ry is just becoming available to take
`advantage of this new desktop PC com-
`puting mode. In this article, we explore
`the concepts and implications of multi-
`tasking for PCs in the laboratory and
`relate how such programs work when
`implemented in current multitasking
`operating systems. We also describe ex-
`ample applications in data presenta-
`tion, analysis, and acquisition.
`Multitasking operating systems
`include task switch-
`Multitasking can
`ing, multiprocessing, coprocessing, dis-
`tributed processing, and parallel pro-
`cessing. In this article, multitasking re-
`fers to running multiple concurrent
`programs or multiple copies of a pro-
`gram on a single PC. The distribution
`of tasks among many computers in a
`network (distributed processing) and
`the various ways of using multiply con-
`nected central processing units (CPUs)
`to carry out tasks (parallel processing)
`in
`not discussed. Coprocessing,
`are
`which a single CPU controls the bulk of
`the task and portions of the code are
`executed by a math chip or coexisting
`CPU within the same PC, will be dis-
`cussed.
`that a
`Multitasking does not mean
`single CPU is running many programs
`simultaneously. PCs typically have a
`single instruction stream and thus can
`task at a time. The
`handle only one
`apparent simultaneous execution of
`several programs is handled by a pro-
`cess known as time slicing or context
`switching. As illustrated in Figure 1, a
`CPU executes one or more
`computer
`instructions (such as MOV or PUSH)
`in one program until it receives a signal
`to switch to another task (or context).
`This signal triggers the system to save
`the current state of the executing pro-
`including all CPU flags, regis-
`gram,
`ters, and memory states, and begin exe-
`cuting another program. When another
`signal is received, the system saves the
`information about the second process
`and restores the state of the machine to
`begin executing where it left off in the
`first process.
`For two completely compute-bound
`programs (i.e., computing continuously
`rather than waiting for an input), this
`method of sharing computer resources
`is not productive because one CPU still
`runs all of the instructions of each pro-
`cess. No time is saved because the CPU
`would take the same amount of time to
`In
`both processes sequentially.
`run
`fact, the overhead involved in switch-
`ing between the tasks will consume
`some CPU time, so the time to multi-
`task the two processes will probably be
`greater.
`However, many programs
`spend
`most of their time in a loop, waiting for
`input from the keyboard, mouse, or se-
`rial port. This dead time, sometimes
`
`0003-2700/91 /0363-030A/$02.50/0
`© 1990 American Chemical Society
`
`Multitasking
`l_rJ (Laboratory
`Personal
`Computers
`
`Richard B. Lam, James W.
`Cooper, Scott Thieret, Jean-
`Christophe Simon, and
`Edward P. Clarke, Jr.
`Laboratory Automation Group
`IBM T. J. Watson Research Center
`P.O. Box 218
`Yorktown Heights, NY 10598
`
`History has a cyclical nature, and com-
`puting systems history is no exception.
`From their initial
`introduction, tradi-
`tional mainframe computers quickly
`
`evolved to serve multiple users.
`Jobs
`in batch mode, and eventually as
`run
`interactive sessions, appeared to the
`to be run simultaneously. This
`users
`time sharing mode of operation is stan-
`dard for mainframe and minicomputer
`systems today.
`Evolution of the personal computer
`(PC), originally conceived for the single
`user and for relatively simple comput-
`ing tasks, has also followed this path.
`PC capabilities have inevitably grown
`toward making the desktop computer a
`viable multitasking platform.
`
`30 A • ANALYTICAL CHEMISTRY, VOL. 63, NO. 1, JANUARY 1, 1991
`
`Downloaded via MASSACHUSETTS INST OF TECHNOLOGY on February 12, 2021 at 01:23:57 (UTC).
`
`See https://pubs.acs.org/sharingguidelines for options on how to legitimately share published articles.
`
`MICROCHIP TECH. INC. - EXHIBIT 1034
`MICROCHIP TECH. INC. V. HD SILICON SOLS. - IPR2021-01265 - Page 001
`
`

`

`referred to as a “spin loop,” is a waste
`of CPU cycles unless the extra CPU
`time is used to handle other processes.
`The effective use of the CPU is handled
`by a system task known as the schedul-
`er or dispatcher.
`A scheduler can use two main strate-
`gies for control when the CPU switches
`to an alternate task: cooperative and
`In coopera-
`preemptive multitasking.
`tive multitasking, the scheduler must
`wait for a program to relinquish control
`to the system. Another program is then
`selected to run while the previously
`running program waits for its next
`turn. Applications written for this type
`of system must he “multitasking
`aware” and give up control at certain
`points in the program. Microsoft Win-
`dows and the MultiFinder system on
`the Apple Macintosh both use coopera-
`tive multitasking. Because all pro-
`grams must be written to cooperate in
`relinquishing time, this method is not
`strictly suitable for data acquisition
`where timing may be important.
`By contrast, preemptive multitask-
`ing is controlled by the system in con-
`junction with a timer or other low-level
`interrupt. The system scheduler sim-
`ply takes control with each interrupt
`and switches tasks without notifying
`any processes. Time slices are provided
`on a priority basis, and individual ap-
`plications have little control over how
`the system assigns CPU time. Thus it is
`difficult, but not
`impossible, to con-
`struct real-time applications. The most
`preemptive operating systems
`common
`for PCs today are OS/2 and UNIX.
`Other proprietary versions of UNIX
`include QNX and Apple's AUX,
`Processes and threads. With OS/2
`and UNIX you can start multiple ap-
`plications by using the operating sys-
`tem command line interface or by se-
`In addi-
`lecting programs from a menu.
`tion, it
`is possible for applications to
`start “child processes” under both op-
`erating sytems. Child processes are
`that
`completely separate programs
`manage their own
`such as
`resources
`files and memory. For example, a child
`process might be started to plot a spec-
`trum on some hardcopy device, thus
`freeing the parent process for other ac-
`quisition or analysis tasks. These child
`processes are also referred to as back-
`ground tasks, with the parent or
`cur-
`rently active process running in the
`foreground.
`intrin-
`Multitasking systems do not
`inter-
`sically require a graphical user
`face (GUI) such as Windows, OS/2 Pre-
`sentation Manager, X Windows,
`or
`Motif for UNIX. However, most mod-
`ern operating systems offer some vari-
`ant of the “point-and-shoot” interface
`with drop-down or pop-up menus, dia-
`log boxes with push buttons, and list
`and check boxes. For these graphical
`screens, the operating system allocates
`
`a session, consisting of either a full
`or a window, for each applica-
`screen
`tion. Such windows provide convenient
`interfaces for organizing and
`visual
`tracking the status of running applica-
`tions, Applications may, however,
`make use of multiple windows without
`having each window correspond to a
`child process.
`A multiple process example. To il-
`lustrate how child processes can be
`used in the laboratory, consider a phar-
`maceutical analysis laboratory where a
`series of samples must be run through
`an automated analysis procedure. The
`sample handling, extraction, and anal-
`ysis procedure generates sample weight
`and LC data, which must he integrated
`
`these operations is computationally in-
`tensive, each could be carried out on a
`single multitasking computer.
`Threads. Under OS/2, a simpler
`type of multitasking is available using
`“threads,” or sections of a single pro-
`gram that are started by and run asyn-
`chronously from the main process (I).
`Every application has one main thread:
`Other threads share the data and re-
`of the main thread. Threads
`sources
`therefore require less overhead than
`separate child processes and are as easy
`to implement as subroutines.
`A program can use threads whenever
`it needs to perform some activity that
`might take a long time to complete. For
`example, it might start a thread to load
`
`A/C INTERFACE
`
`into a report for the scientist. A techni-
`a program that starts a child
`cian runs
`process to control a robot to handle
`each sample. A second child process
`collects data from a balance, and a
`third logs data from a liquid chromato-
`graph. Meanwhile, another application
`integrates the peak data, the results of
`which are linked via dynamic data ex-
`change to a document in a word pro-
`cessing program. Procedures similar to
`this example are often carried out
`to-
`day using two to five conventional com-
`puters, each controlling one aspect of
`the analysis. However, because none of
`
`a large file from disk, scale data for
`display, perform complex math calcu-
`lations, or acquire data. In our hypo-
`thetical
`pharmaceutical
`analysis
`above, the application might use one
`thread for writing the balance and
`chromatographic data to a disk file.
`Another thread could scale the incom-
`ing chromatographic data and plot it to
`the screen. Still another thread could
`send the data to the report program.
`Synchronization and communica-
`tion. Whenever multiple processes op-
`erate on the same
`or dependent data,
`in synchronizing these
`problems occur
`
`PUSH BP
`MOV BP, SP
`MOV DX, DEV
`
`Active
`
`MOV AL, 9
`OUT DX, AL
`MOV DX, CTL
`MOV AL, 0
`1_
`
`OUT DX, AL
`
`MOV BH, AL
`MOV JK, BX
`
`FIADD JK
`DEC SI
`JNEAVG
`
`Active
`
`Time
`
`Figure 1. Illustration of multitasking two processes.
`The number of instructions actually run within each time slice is proportional to the length of time
`allocated by the system to each process.
`
`ANALYTICAL CHEMISTRY, VOL. 63, NO, 1, JANUARY t, 1991 • 31 A
`
`MICROCHIP TECH. INC. - EXHIBIT 1034
`MICROCHIP TECH. INC. V. HD SILICON SOLS. - IPR2021-01265 - Page 002
`
`

`

`A/C !NTERF=ACl
`
`tasks. In our example, the process read-
`ing the balance must somehow commu-
`nicate the data to the process or thread
`responsible for storing the data in a file.
`Similarly, the chromatography data ac-
`quisition code must pass the digitized
`to data logging and
`detector signal
`peak analysis routines. This may re-
`quire synchronizing with the peak
`analysis routine so that peak areas
`are
`not computed until all
`the data are
`available. There are five techniques for
`such interprocess communication:
`semaphores, signals, messages, pipes,
`and shared memory.
`Semaphores are used to synchro-
`nize operations between processes or
`threads. Semaphores are simply global
`variables or special operating system
`structures that are set and cleared by
`the communicating processes. They al-
`low processes to share common
`re-
`such as files or data without
`sources
`conflicts. For example, it would be fool-
`ish to change the value of a variable
`controlling the resolution of a spec-
`trum while a spectral scan is in prog-
`two processes should
`ress. Likewise,
`not actually control the spectrometer
`at the same time. Therefore, the acqui-
`sition routine sets a semaphore con-
`to the resolution vari-
`trolling access
`able until the acquisition is complete.
`The process trying to change the value
`waits for the semaphore to clear before
`continuing. To avoid the dreaded spin
`loop, which wastes computer time, op-
`erating systems provide calls that re-
`linquish all of a thread’s time slice until
`the semaphore clears.
`Signals are special inputs, triggered
`by keystrokes, mouse movement, but-
`ton presses, or other user actions, that
`cause execution to transfer to a routine
`called a signal handler. Operating sys-
`tems often have default signal handlers
`for signals such as floating point errors
`or control-break keystrokes. You can
`write other signal handlers to control
`situations such as interrupting an ex-
`triggering an alarm. For
`periment or
`example, stopping an automated anal-
`ysis may require resetting a robot arm
`to a home position and closing any
`open files.
`Messages are function calls made by
`the operating system to procedures
`that manage the behavior of windows.
`Because many processes have a main
`window, these calls provide a way for
`windows to communicate. In a window-
`the application program
`ing system,
`tells the operating system the location
`of these procedures, and the operating
`system makes function calls to these
`routines when the window needs to be
`updated. You can, however, pass mes-
`sages to these windows through the op-
`erating system and even define mes-
`
`Ithere are
`five techniques for
`such interprocess
`communication:
`
`semaphores,
`signals, messages,
`pipes, and shared
`memory.
`
`sages with private meanings for chang-
`ing application-specific parameters.
`Pipes are used to pass streams of
`data between processes. The communi-
`cating thread opens a pipe for reading
`or writing by an operating system call.
`The read and write handles to a pipe
`are returned by the operating system
`and can be provided to child processes
`as their standard input or output de-
`vice handles. Alternatively, named
`pipes enable separate programs
`to
`communicate by referring to a specific
`pipe name, analogous to a file name.
`Data are read from or written to pipes
`just as for files, with the added advan-
`tage that named pipes are bidirectional
`and can be used for reading and writing
`by both processes.
`When two processes need access
`to
`the same block of data, it may be ad-
`vantageous to use shared memory.
`Shared memory allows two processes to
`read and write to the same memory lo-
`cations if both of
`them have been
`granted access to that memory. In pro-
`tected-mode operating systems you
`cannot, however, write to any memory
`to which you have not been given ac-
`cess. As with named pipes, named
`shared segments are analogous to file
`names. The process may obtain the
`selector value
`segment
`name
`or
`file. To prevent both
`through a pipe or
`processes from writing to the memory
`simultaneously, you control access
`to
`
`shared memory using a semaphore.
`Figure 2 (p. 35 A) shows one way to
`design the pharmaceutical analysis ap-
`plication software from a process view-
`point. Several methods of interprocess
`communication are used—the thread
`controlling injection of a sample into
`the chromatograph uses a semaphore
`as a start signal for the LC data acquisi-
`tion. Similarly, another thread informs
`the balance (when a sample is ready to
`be weighed) through a semaphore. The
`chromatographic data are displayed by
`a thread spun by the acquisition task.
`When the chromatogram is complete,
`the data are passed through a pipe to
`the analysis routine. The sample
`weights and peak areas are available to
`the analysis and report processes
`through shared memory. The analysis
`task also uses a thread to store the data
`automatically in a disk file.
`Access to devices in multitasking
`systems
`In a multitasking system connected to
`it
`is quite possible that
`any device,
`more than one program will attempt to
`that device at
`the same
`time.
`access
`Whether the device is a disk, a display,
`or an analog-to-digital converter card,
`this can have serious consequences if
`the access is not strictly controlled by
`the operating system. Thus, applica-
`tion programs may not make direct
`changes to device registers.
`Instead,
`the application makes calls to a single
`program that has control of the device,
`called a device driver. Although such
`drivers traditionally have been written
`in assembly language with great diffi-
`culty, modern compilers make it possi-
`ble to write them in languages such as C
`(2). These device drivers control multi-
`ple access to the device either by allow-
`ing only one program to open the de-
`vice at a time or by queuing requests
`until the device is free.
`OS/2 allows access
`to device registers
`using special program sections called
`IOPL Segments, but only a device driv-
`register and service interrupts
`er
`can
`from a device. Thus an application pro-
`gram can request access to device regis-
`ters under slow data-rate conditions,
`but a device driver must be written if
`the device is to signal the computer
`using interrupts.
`Timing requirements in multitasking
`systems
`One of the principal problems inherent
`in multitasking systems is the amount
`of overhead introduced by time slicing
`and process scheduling. Because of this
`overhead, high-speed data acquisition
`may be problematic: A data point may
`be missed if
`the system cannot
`ac-
`knowledge an interrupt before another
`continued on p. 35 A
`
`32 A • ANALYTICAL CHEMISTRY, VOL. 63, NO. 1, JANUARY 1, 1991
`
`MICROCHIP TECH. INC. - EXHIBIT 1034
`MICROCHIP TECH. INC. V. HD SILICON SOLS. - IPR2021-01265 - Page 003
`
`

`

`A/C INTERFACE
`
`one occurs.
`The interval between the time a de-
`an interrupt and the time
`vice causes
`that the device’s interrupt service rou-
`
`tine begins executing is called the in-
`terrupt “latency.” In operating sys-
`tems such as OS/2 this latency is usual-
`ly ~50 fis (3). Thus, it might not seem
`
`possible to do data acquisition at rates
`>20 kHz. In addition, if several devices
`are attached to the same interrupt lev-
`el, then polling to find out which device
`
`Parent
`process
`
`Shared
`memory
`
`Child
`processes
`
`Pipes and
`semaphores
`
`Threads
`
`Figure 2. Sample process architecture for a pharmaceutical analysis application.
`Circles indicate processes or threads, solid boxes represent shared memory segments, and outlined boxes denote semaphores, A pipe is used to transfer the
`digital LC data between the acquisition and integration tasks.
`
`ANALYTICAL CHEMISTRY, VOL. 63, NO. 1, JANUARY 1, 1991 * 35 A
`
`MICROCHIP TECH. INC. - EXHIBIT 1034
`MICROCHIP TECH. INC. V. HD SILICON SOLS. - IPR2021-01265 - Page 004
`
`

`

`A/CZ INTERFACE
`
`caused the interrupt may further ex-
`tend this latency.
`When data acquisition continues for
`than a few milliseconds at a time,
`more
`other interrupts probably also will oc-
`cur, The most likely such interrupt is
`the time-slicing interrupt, which, un-
`der OS/2, occurs every 32 ms. If anoth-
`er process becomes active after such a
`time slice, your process could,
`in
`theory, miss a data point. Fortunately,
`if the device signals the computer with
`interrupts, your program will
`receive
`the data point whenever it occurs
`un-
`less data points are coming far faster
`than the time-slicing interrupt.
`More serious than this, however, is
`the fact that many multitasking sys-
`tems also support virtual memory, so
`any program can
`use more memory
`than the computer actually has avail-
`able by swapping parts of memory to
`disk. If a program requests more mem-
`ory than is currently free, memory
`must be swapped and moved and inter-
`rupts must be turned off for the dura-
`tion of the swap, because the interrupt
`return location itself may be moved.
`Clearly, this could result in a severe
`data-handling problem.
`There are several possible solutions.
`If
`the data rates are slower than 20
`kHz, interrupts will always be acknowl-
`edged in time; if the length of the ac-
`quisition is very short, the time-slicing
`interfere. If the ac-
`interrupt will not
`quisition time is longer, the priority of
`the process should be set higher than
`the time-slicing interrupt by selecting a
`in the
`low-numbered interrupt level
`PC—usually level 3.
`However, all of these potential prob-
`lems are easily solved if the acquisition
`board supports direct memory access
`(DMA). These boards use a separate
`chip within the computer to transfer
`data along the bus from the board to
`the PC’s memory without using the
`CPU at all. Such data transfers take
`place regardless of which process is
`running or which interrupt is occur-
`ring. We have found that DMA device
`drivers can run at the maximum speed
`of the board in multitasking systems.
`Finally, some more powerful acquisi-
`tion cards allow you to acquire data
`into onboard memory at very high
`speeds. One such card (from QuaTech,
`Inc., Akron, OH) allows acquisition of
`up to 1 Mbyte of data at speeds up to
`1 MHz.
`Data acquisition under UNIX
`UNIX presents special problems for
`data acquisition because the usual
`UNIX scheduler uses a “fairness” algo-
`rithm that gives all
`tasks equal
`amounts of computer resources.
`This
`approach was adopted because UNIX
`
`was designed to be a multiuser and a
`multitasking system. Thus each task
`may be associated with a separate user
`who will expect to get reasonable com-
`puter response. Because of this design,
`no particular task can get and keep the
`high priority needed for a real-time
`data acquisition program. The only
`way to solve this is by modifying the
`UNIX kernel to allow processes to ad-
`just their priorities irrespective of the
`fairness algorithm.
`
`One kernel that has these modifica-
`tions is IBM’s AIX 3.1, which runs
`on
`RS-6000 workstations. We have begun
`writing device drivers for the RS-6000
`to understand the features of the sys-
`tem and to see how it can fill our
`labor-
`atory’s needs. Real-time UNIX sys-
`tems can be used for instruments or
`experiments with moderate-to-high
`data acquisition needs and high com-
`putational requirements.
`The AIX 3.1 kernel allows the user
`to
`
`Figure 3. Schematic ot the PS/2 and Wizard Card configuration.
`i386 and i860 processors and the PS/2 32-bit dynamic random access memory (DRAM) con-
`The Intel
`nected to the Micro Channel bus are shown. The image data are collected and displayed by the i386 using
`the system RAM. A 64K shared memory segment is mapped to the Wizard Card address space and used
`to transfer the data to the Wizard 64-bit DRAM, where the image is rendered. The new image data are
`transferred back through the 64K memory segment for subsequent display.
`
`Figure 4. Disk magnetic readback signal data displayed as a series of lines, one for
`each successive track.
`
`36 A • ANALYTICAL CHEMISTRY, VOL. 63, NO. 1, JANUARY 1, 1991
`
`MICROCHIP TECH. INC. - EXHIBIT 1034
`MICROCHIP TECH. INC. V. HD SILICON SOLS. - IPR2021-01265 - Page 005
`
`

`

`modify process priorities to be as high
`than the
`as necessary—even higher
`scheduler itself, so the scheduler can-
`interrupt a high-priority acquisi-
`not
`tion task. We have found that this fea-
`ture allows interrupt-driven data ac-
`quisition at rates as fast as 25 kHz.
`In fact, with the eight-word buffer
`present on the National Instruments
`MIO-16 card, we are able to avoid tim-
`ing problems simply by reading all
`newly acquired data points each time
`In addition, be-
`an interrupt occurs.
`cause this is a DMA-controlled card, it
`is not limited by the interrupt latency
`considerations if DMA is used instead.
`Application examples
`the IBM T. J. Watson Research
`At
`Center, our scientific data acquisition,
`analysis, and presentation strategy is
`based on an internal tool called Sci-
`Bench. This program is written specifi-
`cally for multitasking environments,
`using either AIX (the IBM version of
`UNIX) and OSF/Motif or OS/2 Pre-
`sentation Manager. This software runs
`on either PS/2 or RS-6000 computers,
`and a commercial OS/2 version is avail-
`able. Some of the current SciBench ap-
`plications and development work in
`progress are described below.
`Stepper motor control. One of the
`operations in our
`labora-
`most common
`tory is the manipulation of samples as
`their surfaces are studied by various
`techniques. This is usually done by us-
`ing a set of stepper motors to manipu-
`late the position of the surface. Stepper
`motors are controlled by using either a
`General Purpose Interface Bus (GPIB)
`interface or a serial
`eight-bit parallel
`(RS-232C) interface. In both cases, the
`commands are simply sets of charac-
`the
`ters sent to the RS-232C port or
`GPIB device driver provided by the
`manufacturer. One such GPIB inter-
`face card is available from National In-
`struments, Inc. (Austin, TX) with de-
`vice drivers for both OS/2 and AIX. As
`stepper motor motions are fairly slow,
`there are no real data rate problems
`and the manipulation code can easily
`be written in C or, in the case of OS/2,
`also in compiled BASIC (4). In one cur-
`a controller
`rent application, we use
`connected to the serial port to control
`five stepper motors that move a sample
`in three dimensions while allowing two
`further angles of motion to an X-ray
`for X-ray crystallographic mea-
`source
`surements.
`Image rendering using the IBM
`Wizard Card. The IBM Wizard Card
`is a Micro Channel bus master card
`containing an Intel
`i860 microproces-
`sor chip with eight megabytes of 64-bit
`onboard memory. Although this pro-
`can be used as a very fast math
`cessor
`
`Figure 5. Data from Figure 4: (a) mapped into a circular array and (b) rendered in
`three dimensions on a PS/2 with an Intel i860 coprocessor.
`
`ANALYTICAL CHEMISTRY, VOL. 63, NO. 1, JANUARY 1, 1991 • 37 A
`
`MICROCHIP TECH. INC. - EXHIBIT 1034
`MICROCHIP TECH. INC. V. HD SILICON SOLS. - IPR2021-01265 - Page 006
`
`

`

`A/CZ INTERFACE
`
`coprocessor for any number of mathe-
`matical purposes, one of its primary
`uses is in the computation of graphical
`images. We have been conducting ex-
`periments in the rendering and visual-
`ization of scientific data on
`a PS/2
`using the Wizard Card in place of high-
`er performance computers such as the
`RS-6000 or mainframes. Because the
`i860 runs
`asynchronously as
`a co-
`processor, the PS/2 CPU is free for oth-
`er tasks.
`Communication between the PS/2
`and the Wizard Card is accomplished
`by using a named pipe and a block of
`shared memory. Parameters are trans-
`ferred to the card through the pipe, and
`a message signaling completion of the
`computation is sent back to the PS/2
`through the same pipe. Data are trans-
`ferred in blocks using a 64K block of
`shared memory between the two pro-
`cessors, as shown in Figure 3 (p. 36 A).
`When the PS/2 is started, the Wiz-
`ard Card loads and runs
`a small pro-
`gram executive. When the SciBench
`request for an
`program receives a user
`image-rendering operation, a PS/2 pro-
`gram is run that signals the card to load
`the rendering program into its memory
`and begin executing it. In a typical op-
`
`eration, the application program sends
`a two-dimensional graphical image bit
`map and rendering parameters to the
`Wizard Card. The i860 CPU, operating
`as an independent computing engine,
`performs the calculation to construct a
`view of the image from an angle other
`than directly above using perspective,
`incident an-
`shading, and a light source
`gle. A replacement bit map is returned
`to the memory of the PS/2 along with a
`pipe message to redisplay the data. The
`computation runs ~40 times faster than
`on a PS/2 with a 20-MHz 80386 and
`80387. A typical rendering of a 200 X 200
`pixel bit map takes ~4 s.
`Figure 4 (p. 36 A) shows original flat
`data representing magnetic readback
`signals from successive disk tracks. A
`calculation was performed to move
`data points from their linear positions
`to their positions on concentric disk
`tracks, resulting in the circular bit map
`representation (Figure 5a, p. 37 A).
`This bit map was
`then rendered into
`three dimensions, where the intensity
`was converted to height (Figure 5b).
`Scanning electron and tunneling
`microscope data. Acquisition of data
`from a scanning electron microscope
`(SEM) presents a high data acquisition
`
`l)\4cevtr yAyj ^cLAich^-
`Slash
`sample prep
`time
`with SFE
`Call (800)228-4250
`Learn about Isco’s
`new supercritical fluid
`extraction system.
` 
`Use low-cost, non-
`toxic CO, instead of
`expensive and
`hazardous solvents.
`
` 
`
`Selectively extract
`a wide range of
`analytes.
`  Efficiently produce
`analysis-ready samples
`for GC, HPLC, etc.
`L
`
`fax
`
`Phone or
`now.
`We’ll send you
`applications
`bulletins along
`with full product
`information.
`
`HO. Box 5347
`Lincoln NE 68505
`Tel: (402) 464-0231 lr,„_
`Fax:(402)464-4543 ISCO
`
`007
`S
`1.5 kV
`100 pm
`01
`Figure 6. Electron micrograph of a semiconductor slice, digitized from a Cambridge
`Instruments SEM and enhanced by averaging 16 scans.
`
`CIRCLE 64 ON READER SERVICE CARD
`38 A • ANALYTICAL CHEMISTRY, VOL. 63, NO. 1, JANUARY 1, 1991
`
`MICROCHIP TECH. INC. - EXHIBIT 1034
`MICROCHIP TECH. INC. V. HD SILICON SOLS. - IPR2021-01265 - Page 007
`
`

`

`rate problem, because data are avail-
`able as scan lines at rates of up to 100
`kHz. Whereas the final data may be
`acquired more slowly for improved sen-
`sitivity, the adjustment of the sample
`requires relatively rapid feedback.
`In our experiments, we set an SEM
`to produce an image scan in 4 s. During
`this scan, we
`read 500 lines of 500
`points each with a retrace interval be-
`tween them. The device driver for this
`the
`experiment was designed to use
`National MIO-16 analog-to-digital
`converter card, running at 11 jus per
`data point. This card has a real-time
`clock connected to two counter-timers.
`triggers acquisition of
`One counter
`each data point and the other triggers
`each successive line scan. When a line
`the latter counter
`commences,
`scan
`an interrupt and the interrupt
`causes
`service routine collects all 500 data
`points for that
`line before exiting
`5.5 ms later. Then the PS/2 copies the
`data from the acquisition buffer and
`interrupt while the
`awaits the next
`scan retrace takes place. At the end of
`the acquisition, data are placed into a
`bit map for display. These data contain
`all of the information present in the
`original video image, but they are now
`in digital form where they can be en-
`hanced by averaging successive images
`and processed using various contrast
`enhancement techniques. Figure 6 il-
`lustrates an electron micrograph of a
`semiconductor slice obtained by aver-
`aging 16 SEM images using this acqui-
`sition routine and displayed using Sci-
`Bench.
`
`Summary
`As PC systems grow in power, user
`ex-
`pectations of their performance natu-
`rally increase. The demand for greater
`faster turnaround, and
`productivity,
`higher quality laboratory analysis con-
`In addition,
`tinues.
`research experi-
`ments are becoming more complex, re-
`quiring many analog-to-digital and
`digital-to-analog control and monitor-
`ing channels. Meeting these demands
`requires the creative use of current
`software tools to construct more
`pow-
`erful user applications. Multitasking is
`clearly an indispensable tool for devel-
`oping such programs. Future software
`applications in robotics, data acquisi-
`tion, instrument calibration and moni-
`remote communications, and
`toring,
`data analysis will enjoy enormous
`benefits from the use of multitasking
`techniques.
`
`The magnetic readback signal disk data were pro-
`vided by Anthony Praino and the SEM image data
`by Oliver Wells, both of the IBM T. J. Watson
`Research Center.
`
`NUPRO
`Valves and
`Filters (or
`Analytical
`Applications
`
`NUPRO Valves and Filters offer these design
`and performance choices:
`  End Connections: SWAGELOK" Tube Fittings,
`NPT, Tube Stub, Weld, CA|ON VCO® & VCR®
`  Service Ratings: vacuum to 6000 psi;
`temperatures to 900°F
`STOCKED FOR IMMEDIATE DELIVERY
`BY AUTHORIZED SALES AND SERVICE
`REPRESENTATIVES.
`
`NUPRO COMPANY
`4800 East 34515 Street
`Willoughby, OH 44094
`
`COMPANY
`
`p—.Wnurro
`A SWAGELOK
`METERING
`Valves for precise flow control in
`laboratory and instrument systems
`a accurate, repeatable How
`adjustment with no initial surge
`a compact, low dead space
`  stem threads removed from
`system
`
`SHUT OFF
`Compact valves for reliable flow regulation
`and shutoff
`a stem threads removed from system fluid
`a compact designs
`a ball tip or regulating stems
`
`a quick-acting, 1/4 turn
`a full flow
`a easy maintenance
`
`FILTRATION
`Inline and tee type filters to protect
`instruments by removing hard particle
`contamination from fluid lines
`  choice of sintered and wire mesh
`elements from 0.5 to 440 microns
`  compact designs
`  all metal construction
`
`SWAGELOK - TM Crawford Fitting Company
`TM Cajon Comoany
`CAJON, VC0 & VCR -
`© 1986 SWAGELOK Co., all lights reserved N-56la
`
`CHECK & RELIEF
`Relief valves open at pre-set pressure
`check valves allow
`unidirectional flow control
`  cracking pressures 1/3
`to 6000 psi
`  smooth floating poppet
`  positive back stop
`
`£ J
`
`CIRCLE 127 ON READER SERVICE CARD
`
`ANALYTICAL CHEMISTRY, VOL. 63, NO. 1, JANUARY 1, 1991 • 39 A
`
`MICROCHIP TECH. INC. - EXHIBIT 1034
`MICROCHIP TECH. INC. V. HD SILICON SOLS. - IPR2021-01265 - Page 008
`
`

`

`A/C INTERFACE
`
`References
`(1) Cooper J. W. Writing Scientific Pro-
`grams Under the OS/2 Presentation
`Manager, Wiley-Interscience: New York,
`1990.
`(2) Cooper J. W. Personal Eng. Instrum.
`News 1990, 7(8), 43.
`(3) Baitinger F., IBM Boeblingen, personal
`communication.
`(4) Cooper J. W. Microsoft QuickBASIC
`for Scientists; Wiley-Interscience: New
`York, 1988.
`
`Jean-Christophe Simon (above)
`re-
`ceived his diploma from the Ecole Na-
`tionale Superieure de I’Aeronautique
`et de L’Espace Toulouse in France. Fie
`is an exchange student
`through the
`AIPT program at the IBM T. J. Wat-
`son Research Center.
`
`Scott Thieret (far left, group) received a B.S. degree in electrical engineering
`and computer science from the University of Vermont in 1989. He is a supplemen-
`tal staff programmer for the Laboratory Automation Group at
`the IBM T. J.
`Watson Research Center.
`in analytical
`Richard B. Lam (second from left, group) received his Ph.D.
`chemistry from the University of North Carolina at Chapel Hill
`in 1982. He joined
`IBM Instruments in 1984 and is currently a research staff member in the Labora-
`tory Automation Group. His research interests include computers in instrumen-
`tation and