Measurement Computing Personal488 rev.3.0 For DOS & Windows 3.Xi - Manual (Page 84)

II. SOFTWARE GUIDES - 8. Driver488/DRV 8G. QuickBASIC
Personal488 User’s Manual, Rev. 3.0 II-69
Once we have started the transfer, we can check the status:
980 PRINT#1,"STATUS"
990 INPUT#2,ST$
1000 PRINT ST$
The status that is returned is typically:
CS21 1 L100 000 T0 C0 P1 OK
Notice P1 which states a transfer is in progress, and L which shows we are still a listener. If the bus
device is so fast that the transfer completes before the program can check status, the response is P0
showing that the transfer is no longer in progress. We can also WAIT for the transfer to complete and
check the status again:
This time the status must be P0 as the WAIT command waits until the transfer has completed. Now that
we know the transfer is complete, we are ready to print out the received data as shown above.
BASIC VARPTR & SADDR
The BASIC VARPTR and SADDR functions must be used with caution. The first time a variable such as
I or ST$ is encountered, or an array such as R%() is dimensioned, space is made for it in BASIC’s data
space. The other variable or arrays may be moved to make room for the new item. If the memory
location of an item must be fixed, then BASIC cannot be allowed to encounter any new variables or
arrays. For example, in the
ENTER statement shown above, Driver488/DRV is told the memory address
of R$ (for GW-BASIC, R%(0) ). Then, while the transfer is going on, the Driver488/DRV status is read
into the string variable ST$ . If ST$ has not been used previously then BASIC would have to create a
new ST$ and might move R$ . Of course, Driver488/DRV would have no way of knowing that R$ has
been moved, and the data would not be placed correctly into R$ .
Interrupt Handling
The IEEE 488 bus is designed to be able to attend to asynchronous (unpredictable) events or
conditions. When such an event occurs, the bus device needing attention can assert the Service
Request (
SRQ ) line to signal that condition to the controller. Once the controller notices the SRQ , it can
interrogate the bus devices, using Parallel Poll ( PPOLL ) and/or Serial Poll ( SPOLL ) to determine the
source and cause of the SRQ , and take the appropriate action.
Parallel Poll is the fastest method of determining which device requires service. Parallel Poll is a very
short, simple IEEE 488 bus transaction that quickly returns the status from many devices. Each of the
eight IEEE 488 bus data bits can contain the Parallel Poll response from one or more devices. So, if
there are eight or fewer devices on the bus, then just the single Parallel Poll can determine which
requires service. Even if the bus is occupied by the full complement of 15 devices, then Parallel Poll
can narrow the possibilities down to a choice of no more than two.
Unfortunately, the utility of Parallel Poll is limited when working with actual devices. Some have no
Parallel Poll response capability. Others must be configured in hardware, usually with switches or
jumpers, to set their Parallel Poll response. If Parallel Poll is not available, or several devices share the
same Parallel Poll response bit, then Serial Polling is still required to determine which device is
requesting service.
Serial Poll, though it is not as fast as Parallel Poll, does offer two major advantages: it returns
additional status information beyond the simple request/no-request for service, and it is implemented on
virtually all bus devices.
The SRQ line can be monitored in two ways: it can be periodically polled using the STATUS command,
or it can be used to cause an external interrupt when asserted.
1010 PRINT#1,"WAIT"
1020 PRINT#1,"STATUS"
1030 INPUT#2,ST$
1040 PRINT ST$