Also known as the General Purpose Interface Bus (GPIB), the Hewlett-Packard Interface Bus (HPIB), and the International Electrotechnical Commission (IEC) 625 bus, the Institute of Electrical and Electronic Engineers (IEEE) standard number 488 defines a 'standard digital interface for programmable instrumentation'. Originally written in 1975 and revised in 1978, the standard deals with systems that use byte-serial, bit-parallel means to transfer digital data among a group of instruments and system components.

Put simply this means that data is transmitted over the interface a byte at a time (byte-serial), over eight separate data lines (bit parallel). The flow of data is controlled by three command lines which are used to indicate the successful passage of data from one instrument to another. This is known as a three-wire handshake. In all there are 24 lines connecting instruments on the bus, comprising eight data lines, eight ground lines and eight command lines, three of which are the handshake lines, the other five handling general interface management.

There are two types of data transmitted on the bus: data used to manage the interface itself, and data used by the devices connected by the bus. In the IEEE-488 standard these are known as interface messages and device dependent messages respectively. Devices connected by the bus have one or more of the capabilities of listening, talking and controlling. Under the control of interface messages a listener can receive device dependent messages from another device on the bus, and a talker can send device dependent messages to another device on the bus. A controller sends the interface messages that command the specific actions in the other devices. An example of a listener is a power supply which receives information on a voltage setting and acts upon it. An example of a talker is a digital thermometer which, when commanded, transmits its current temperature reading. A digital multimeter has both the ability to listen and to talk, and a computer usually has all three abilities of listening, talking and controlling.

The Acorn interface was designed for Acorn by a company called Intelligent Interfaces Ltd, who also manufacture the unit. The interface supplied for review was, unlike a lot of review hardware, a production unit, working to the full specification, and containing complete documentation. It arrived in an expanded polystyrene box with one side thoughtfully marked 'TOP'. Inside, in addition to the interface, was an EPROM containing the IEEE filing system, a ribbon cable for connecting the interface to an instrument and the user guide, also produced by Intelligent Interfaces. Also supplied with the review hardware, though perhaps not standard issue, was an application note written by Intelligent Interfaces on the use of functions and procedures in programming the interface in Basic.

The electronics of the interface are housed in the standard Acorn box (teletext adaptor, second processor etc), and connect to the 1MHz bus by a 34 way ribbon cable. Being only 50cm long the cable dictates that the interface is placed next to the microcomputer. The ribbon cable is permanently attached to the interface, but has a 34 way header to allow connection of further 1MHz bus peripherals at the same time as the interface. The interface does not derive its power supply from the computer but has its own mains connection. In the same style as the computer, the interface comes with an integral mains lead with moulded three-pin plug and on-off switch on the rear panel.

On opening the interface one is struck by how little there is inside. The electronics, nine integrated circuits and a handful of passive components, are on a single printed circuit board, and the largest single component is the mains transformer. The construction is excellent. The three main integrated circuits are socketed, and the board does not contain any modifications. By using shrouded connectors on all the a.c. leads, it is impossible to touch the mains supply anywhere.

The user guide also reflects similar attention to detail. A spirally bound A5 volume of 64 pages and appendices, it is clearly laid out and properly printed. It contains introductory information to get the user going, then goes into a deeper study of the interface operation. A complete list of the IEEE commands is given, with programming examples and a clear description of the command and its effect. The guide includes a short description on using the filing system in assembler, and gives the structure of the OSWORD block for each command. There are appendices covering the minimum abbreviations for each command, error messages, and the fitting of the filing system EPROM. The guide finishes with a single page index.

Despite recommending at the beginning of the user guide that the IEEEFS EPROM be fitted by a dealer, appendix 5 gives very detailed instructions on how to fit the EPROM yourself. As with the hardware, the EPROM supplied contained the current production filing system, version 0.02. Given Acorn's penchant for multiple issues of filing systems (eg Econet), it was gratifying to find from a phone call to Intelligent Interfaces that this was the definitive version despite the 'temporary' sound of the version number (no OS 0.10 here). On installing the EPROM and typing *HELP IEEE one is greeted by the rather curt 'IEEE Filing system 0.02', 'Please refer to the User Guide', not the usual list of available commands. As the IEEE commands are not issued directly, prefixed by an asterisk as in the DFS, perhaps this omission is not surprising.

Having installed the EPROM and connected the interface to the 1MHz bus everything was ready to go. Starting at the simplest end I chose to control a single listen-only device, a power supply, which was connected to the interface with the supplied cable.

Communication between the computer and the interface is through two channels. A command channel is used for transmitting bus commands and for receiving information on the interface status, and a data channel used for transmitting and receiving data to and from other devices on the bus. This rather unusual approach is a consequence of the communication being through a filing system rather than a more conventional I/O driver.

The first steps therefore are to select the filing system and to open the command and data channels:

 10 *IEEE
 20 cmd%=OPENIN("COMMAND")
 30 data%=OPENIN("DATA")

The integer variables used in lines 20 and 30 can be chosen to suit your needs, but having been assigned, all transfer of information is referenced by these variables.

The bus address of the power supply is assigned in a similar manner:

 40 power%=OPENIN("5")

where '5' is the numeric address set up on dual-in-line switch on the rear of the power supply. All devices on the bus have a numeric address which is used to uniquely identify them. The computer must also be assigned an address. Any number between 0 and 30 is acceptable, though custom has the system controller assigned to address '0.

 50 PRINT#cmd%,"BBC DEVICE NO",0

This instruction is sent to the interface through the command channel referenced by the integer variable 'cmd%' assigned in line 20. The phrase "BBC DEVICE NO" is one of the 28 commands that may be issued to the interface. It can be typed in full or abbreviated to 'B'. All commands have abbreviated forms with the most used commands abbreviated to a single letter. The saving in memory space comes with a lack of readability, a problem experienced in normal basic operation when using long variable names.

Having assigned addresses the interface is initialised with the CLEAR command, and instruments prepared for remote operation with the REMOTE ENABLE command:

 60 PRINT #cmd%,"CLEAR"
 70 PRINT #cmd%,"REMOTE ENABLE"

Everything is nearly ready now for the power supply to be given an instruction. This will be a string of ASCIl characters. In order for the device to know when the string has finished it recognises particular characters as marking the end of the string. These characters may change from one instrument to another and should be set up if they differ from the default character of 'line feed'. The power supply used recognised 'carriage return/line feed', so:

 80 PRINT #cmd%,"END OF STRING",CHR$(13)+CHR$(10)

This finishes the preparation. It seems awkward, but only needs to be done once, so can be relegated to a procedure:

 10 *IEEE
 20 PROCinitialise

This gives readability to the main program flow, and defines a procedure that could be used in subsequent programs.

The power supply used had two ranges, 0-10V, and 0-50V, with 1000 discrete programmable steps in each range. The required voltage had to be translated to a particular step in the 0-999 range and prefixed with '1' for the lower range , and '2' for the higher range, giving an effective four digit number between 1000 and 2999. This number is then transmitted to the power supply as a string.

A combination of function and procedure was used to get round the problem of a procedure not returning a value:

 30 REPEAT
 40 voltage=FNget_volts
 50 PROCvolts(voltage)
 60 UNTIL FALSE

The function to obtain the required voltage could be a simple INPUT statement, or could include limit value checking, to ensure that the requested voltage lay between 0 and 50 volts. The procedure to set the voltage has to scale the voltage within the required range, convert it to a string, and transmit it to the interface:

100 DEFPROCvolts(voltage)
110 IF VOLTAGE>9.990 THEN volts$=STR$(2000+INT(voltage/0.05+05)) ELSE volts$=STR$(1000+INT(voltage/0.01+0.5))
120 PRINT #cmd%,"LISTEN",power%,"EXECUTE"
130 PRINT #data%,volts$
140 PRINT #cmd%,"UNLISTEN"
150 ENDPROC

When these lines are executed the power supply that has been assigned to 'power%' sets itself to the voltage 'voltage'. This may seem very long winded, and is compared with other dedicated controllers, but by using the function and procedure statements available on the BBC computer, a concise and readable main program can still be maintained.

Having mastered the control of a simple listen-only device, the next step was to link in a talker so that information could be received by the computer. The obvious complement to the power supply was a volt-meter connected up to measure the voltage set upon the power supply.

As the interface has already been set up the only preparatory statement necessary is to assign the address of the meter in PROC initialise:

80 dvm%=OPENIN("7")

The taking of a measurement is a two stage process. Firstly the meter has to be set to measure the correct function, volts in this case, with a given resolution. More complex meters might require more information such as which input on a multi-input instrument, whether a number of readings are to be taken and averaged, is any processing of the reading necessary before outputting the data etc. Information on the codes required are obtained from a particular instruments handbook.

For the meter in question, the setting up was accomplished by:

200 PRINT #cmd%,"LISTEN",dvm%,"EXECUTE"
210 PRINT #data%,"J3D3T1N1YlQ1R0"
220 PRINT #cmd%,"TRIGGER",dvm%,"EXECUTE"
230 PRINT #cmd%,"UNLISTEN"

This sequence only needs to be executed once unless any of the parameters in line 210 need to be changed, so it can normally be included in the initialisation procedure.

As actually reading the meter needs the return of the measured value, this is handled by a function call:

90 answer = FNmeter
.
.
300 DEF FNmeter
310 PRINT #cmd%,"TALK",dvm%
320 INPUT #data%,voltage$
330 PRINT #cmd%,"UNTALK"
340 =VAL(voltage$)

The way the transfer works should be fairly obvious from this function. A particular instrument, here denoted by 'dvm%' is commanded to talk, i.e. transmit its data. This is inputted on the data channel into the variable 'voltage$'. The command 'UNTALK' puts the bus back into a quiescent state, and the value transmitted is turned from a string to a numeric value using the function 'VAL' and returned to the calling program.

The simple examples of the previous section where a talk-only device, the power supply, was set to a given voltage, and a talker/listener, the voltmeter, was set to a known state and made to transmit a measured value, may seem trivial, but in essence such sequences are all that is necessary in perhaps 80% of applications. Transmission of simple strings between instruments and the controller is all that is necessary to measure the frequency response of an amplifier, to measure the frequency spectrum of an oscillator, or measure the performance of a complex electronic system.

So far we have only seen ten of the possible 28 commands in use. The remaining eighteen fall into three groups:

1. Block data transfer
2. Instrument status
3. Bus status control

The block data transfer instructions 'READ BINARY', 'WRITE BINARY', and 'TRANSFER' are for moving specified numbers of bytes both between a controller and an instrument and between two instruments - one acting as the talker, the other as the listener. In this way, data dumps may be performed by copying the contents of a instrument memory straight to a plotter.

The second group, instrument status, covers the use of serial and parallel polls and bus status. The status request command 'STATUS' returns an integer's worth, i.e. four bytes, of information on the bus status. Individual bits indicate the current status of a number of bus functions. To check for specific states the requisite bit has to be masked out. For instance, if an instrument needs attention from the controller, it generates a service request (SRQ). The presence of an SRQ is indicated by bit 5 in the status word being set. This could be handled by:

490 DEFPROCstatus
500 PRINT #cmd%,"STATUS"
510 INPUT #cmd%, state%
520 state%=state% AND &20
530 IF state%=0 ENDPROC

If SRQ is not set the status procedure terminates, otherwise the SRQ must be handled. How to handle the SRQ brings in the serial and parallel poll instructions. If there is only one instrument on the bus then it must be generating the SRQ and it can be accessed directly using a serial poll. This instructs the instrument to return status information to the controller, from which the controller can work out why the SRQ was generated and take appropriate action.

If there is more than one instrument on the bus, then which one has generated the SRQ is not known. Two courses of action are then open to the controller. Either it can serial poll each instrument in turn until the one generating the SRQ is located, or get the instrument to 'own-up' by using a parallel poll. In a parallel poll, each instrument is allocated a particular bit in a status byte.

When a parallel poll is issued, the instrument generating the SRQ sets its bit in the status byte, thus the controller can immediately distinguish which of eight instruments (there are only eight bits in a byte), is requesting attention. This particular instrument may then be serial polled for more specific information. This sequence is illustrated in the following code:

540 PRINT #cmd%,"PARALLEL POLL REQUEST"
550 INPUT #cmd%, poll%
560 IF poll% AND 4 PROCserial_poll_dvm
570 IF poll% AND 6 PROCserial_poll_psu
580 IF poll% AND 6 PROCserial_poll_psu
590 ENDPROC
595 DEFPROCserial_poll_dvm
600 PRINT #cmd%,"SERIAL POLL",dvm%,1
610 INPUT #cmd%,status$
620 status=ASC(status$)
630 IF status AND &40=0 ENDPROC
640 status=status AND 7
650 IF status=4 PRINT"Out of range value"
660 IF status=5 PRINT"Unrecognised character"
670 ENDPROC

The digital voltmeter used was set to respond to a parallel poll on bit 3 (line 560). When presented with a serial poll command it returns one byte of status information (line ), bit 6 of which is set if it generated the SRQ (line 630). This check is merely a 'belt-and-braces' way of double checking the origin of the SRQ. If it did generate the SRQ, bits 0,1, and 2 are set to indicate one of two error conditions, these are examined on lines 640-660 and appropriate messages printed out.

Associated commands not used in this example are "PARALLEL POLL ENABLE" and "PARALLEL POLL DISABLE" which enable/disable the parallel poll on a specific addressed instrument, and "PARALLEL POLL UNCONFIGURE" which stops all instalments taking part in a parallel poll.

In large systems having more than eight polling instruments, there: may be two instruments responding on one bit of a parallel poll. In this case it might be nice for the controller to serial poll each to find the instrument requesting service.

The third and final group of commands are those associated with general bus status control. There are four pairs of commands handling similar functions, and a single un-paired command:

GO TO LOCAL
Return addressed device to local

REMOTE DISABLE
Return all devices to local

SELECTED DEVICE CLEAR
Clears specified device

DEVICE CLEAR
Clears all devices on the bus

TAKE CONTROL
Pass control to another controller

REQUEST CONTROL
Request control from system controller

TIME ON Enable timeout

TIME OFF
Disable timeout

LOCAL LOCKOUT
Locks panel controls on a specified device

These are all self-explanatory and are used in a variety of ways. For instance 'GO TO LOCAL' would enable an adjustment to an instrument to be made, setting a power supply voltage, whilst other instruments were still under bus control.

'REMOTE DISABLE' on the other hand might be the last statement in a program, that returns all instruments to local control before halting.

Not all instruments respond to all commands. A careful examination of the operating manual will reveal which do not respond to polling, or do not permit block transfer of data. The set of 28 commands, though, allows as much control as each instrument permits, giving the programmer the opportunity to extract as much from the instrument as possible.

On the hardware side the interface was virtually faultless. Its construction is sound with several nice touches, such as the covering of all points at mains voltage inside the interface. With so few components the reliability should be good, but if anything does go wrong then maintenance should be straightforward due to the ease of access.

My only quibble on the hardware side is with the cable connecting the interface to the instruments. The usual configuration is for a screened cable with a stackable connector at each end. The cable supplied by Acorn is a ribbon cable with a non-stackable connector at each end. This forces the controller to be at the end of a chain, or a single branch in a star-connected system which is a limitation not experienced with other controllers. In addition, the non-stackable connector does not have the screw-fit attachment found on conventional bus connectors, leaving the possibility of it becoming disconnected behind a bank of equipment.

When it comes to the software, different people expect different things. The command set in EPROM enables you to perform quite complex bus control operations, but in a rather laborious fashion. The need to operate at the 'TALK/UNTALK' level is balanced by the ability to confine these sorts of operation to functions and procedures, in which case the main program flow takes on the look of a higher level controller.

Documentation, though not abundant, is sufficient, and what there is is well written and well presented. It is though aimed more at the experienced user than at the beginner. A novice in programming instruments on the bus will need more information than the user guide provides, particularly as the low level approach to control means that the programmer is not protected by a sophisticated I/O driver.

I experienced no problems with the interface. I plugged in the EPROM, connected up the 1 MHz bus and away it went. However, another interface, purchased by a colleague, failed to work until a pull-up resistor was connected to pin 1 of the EPROM. Talking both to Intelligent Interfaces and to Acorn failed to throw any real light on the cause, as it seemed to be an isolated incident that no-one else had reported.

Whilst not exactly a problem, I did come across an 'effect' which was a little disconcerting. In common with all filing system ROMS, the IEEEFS moves PAGE upwards in memory to claim space for a work area. If this space is re-claimed for program use, it can still be affected by the IEEEFS. Pressing ESCAPE or BREAK/OLD causes certain memory locations to be overwritten, resulting in a corrupted program. This could be embarrassing if one was trying to run an analysis program on data collected over the interface, where all memory space was valuable.

This effect is due to the necessity to leave the bus in a known state if a control program was interrupted using the ESCAPE or BREAK keys. As the claiming of work space, and the overwriting of these memory locations takes place even if the interface is not connected (cf the teletext adaptor), then the only way out is to remove the EPROM. Not a practical proposition on a day-to-day basis though.

On balance I found the interface to be easy to use. As an experienced user of the bus, the low level programming required was not a problem, though a first time user would require more general information on the bus operation than had been supplied.

For use in industry or in education, the Acorn interface provides a cost effective alternative to the currently acceptable range of controllers. Question marks fall over reliability, maintenance and support, but the answers will only be found with time.