- Email: [email protected]
FORTH and microprocessor applications at the Royal Greenwich Observatory
FORTH and n roprocessor applications at the Royal Greenwich Observatory The Royal Greenwich Observatory at Herstmonceux, UK, has been using microprocessors since 1976. Scientists there have found FORTH to be suited to their needs, lan G van Breda and Neil M Parker say why and describe how it has been used In common with other activities that make extensive use of electronics and computing, astronomy has been profoundly affected by the availability of minicomputers and microprocessors. These devices have brought with them a revolution both in the quality of astronomical data and in the ease with which that data may be obtained; many exciting astronomical research results have been obtained as a direct consequence. This paper describes the microprocessor program at RGO, including the hardware, why it was chosen and how it is possible to cope with rapid technological changes, and the software which unifies the different processors. It describes highlights o f the projects for which microprocessors have been used so far, and discusses some likely future developments in astronomical applications.
microprocessors FORTH astronomy Since their introduction at the Royal Greenwich Observatory (RGO) in 1976, microprocessors have played an important part in data acquisition and control for astronomical instruments, as well as for data reduction and analysis. They have also become indispensible tools in the development cycles of instruments in the laboratory, and have found uses as logic replacements, intelligent instrument controllers, minicomputer replacements, personal computers and fast controllers; both 8 bit and 16 bit devices have been used in additlon to bit-slice chip sets. In any microprocessor project, software and the choice of language are crucial. The personal computers at RGO use BASIC but, for real-time applications, a more powerful interactive language was needed. FORTH was chosen for this purpose, because of its combination of high execution speed and powerful interactive command structure. Also, since it includes its own operating system, editor and assembler, it is probably the most highly standardized of all programming systems, making it simple to transport software between processors, and to adapt to new processors as they become available. This paper discusses general aspects of the work at RGO, and is divided into four sections: a general overview of the hardware used at RGO; a brief description of FORTH, which will probably be unfamiliar to most readers; descriptions of the projects for which the various microprocessors Royal Greenw=ch Observatory, Herstmonceaux Castle, Hailsham, East Sussex13N27 ] RP, UK
vol 7 no 5 lune 1983
have been used; and finally, an indication of likely future developments.
HARDWARE OVERVIEW Motorola 6800 8 bit microprocessors were the first to be used in this work. Subsequently, Digital Equipment LSI-I I series was added to the program, while maintaining the M6800 capability. The AMD 2900 series bit:slice chip set was also adopted, and there are plans to use the Motorola 68000 processor.
M 6 8 0 0 systems The reasons for choosing the M6800 initially, as opposed to a processor such as the Intel 8080, were not exceptionally strong. One of the authors had previous experience of the Motorola device, and it was well supported by the manufacturer, had good interfacing hardware and flexible development systems were available. At the time the project was started, funds were strictly limited, as microprocessors had not been widely accepted in astronomy, and it was necessary to begin with an RGO-designed Eurocard system; software was developed by cross assembly from an ICL 1903T mainframe computer. However, the process was very slow and, when funds became available after it had been shown that 'microprocessors actually work', a number of Motorola Exorciser development systems were purchased, each complete with dual floppy-disc drive. In addition, PROM programmers and user system evaluation (USE) modules were bought, allowing the Exorciser to replace the microprocessor integrated circuit in a target stand-alone system during development, prior to producing a PROM version of the program. Exorcisers have also been used as replacement minicomputers. Software was purchased in the form of micrOFORTH and subsequently of polyFORTH. This allowed a greatly improved and more rapid software development cycle over the cross assembler. A Camac crate controller was designed for the M6800, making use of the memory-mapping facilities of the I/O I . More recently, a version compatible with the EUR 65002 specification for auxiliary crate controllers has been developed. One special Exorciser is based on a set of circuit cards developed at CERN for their Caviar system 3 . It includes a Camac branch driver for use with 'A2' type crate controllers, an IEEE 488 bus controller and a cassette tape
0141-9331/83/040203- 08 $03.00 © 1983 Butterworth & Co (Publishers) Ltd
203
interface, as well as a video momtor drwer which plovides simple display facilitles. This exorclser is used mainly for test work. Whde Motorola Exorciser and Micromodule Chassls systems have been used for application purposes, the RGO Eurocard system has also been retained for those applications requiring a more compact format. This system zs referred to as the modular microprocessor system (MMS). Similar card systems are available commercially, but the MMS card systems are more economical to use, partly because the development costs have been pald m the past, and partly since they are well understood by observatory engineers and techniclans, as well as being backed up by a good supply of spares. More recently, a Motorola Exorset development system has been purchased, which uses the M6809 microprocessor, along with exorFORTH software. This will be used as an intelligent terminal for engineering diagnostics at the new observatory under construction at La Palma in the Canary Islands.
LSI-11 systems In 1978, work was begun at RGO on solid-state area detectors; in particular, charge-injection devices (CIDs) and charge-coupled devices (CCDs). These required two-dimensional image-handling software in addition to the more usual instrument control software. While the Exor¢iser could cope with instrument control, the 2D image software needed a more powerful processor. For this purpose the LSI-I 1 16 bit microcomputer was chosen. This choice was conditioned mainly by the fact that there was already a PDP-I 1/34 at RGO with FORTH imaging software for controlling a microdensltometer. Initially, the LSI-I I/2 processor was used, but more recently this has largely been superseded by the faster LSI-I 1/23. The standard disc used with the LSI-I I has been the ubiquitous Diablo series 30, 2.5 Mbyte removable cartridge drive. However, since the system is used a great deal for image handling, larger capacity Winchester discs have been added. Floppy discs have also been used, particularly for 'travelling' systems used to observe at remote sites, for which two Standard Engineering MIK 11/2 CAMAC controllers have been purchased. These controllers each contain an LSI-I I / 2 CPU and allow memory and peripheral devices to be mounted within the CAMAC crate. The original software on the PDP-I 1/34 was a miniFORTH system, and poIyFORTH has also been purchase. More recently, a 'home-designed' system closely compatible with polyFORTH has been introduced. This system, apart from overcoming some awkwardnesses in polyFORTH, optimizes the speed of disc transfer, as well as making it somewhat easier to precompile relatively large applications into PROM. These facilities are particularly useful where observations are being carried out at a remote slte, as the computer is then less dependent on the disc being in working order, particularly where low output datarates are encountered, such as in conventional astronomical photometry and polarimetry. Compatibility is maintained between systems by using essentially the same software~ with only the innermost section of the disc handler being specific to the particular type of drive. Because FORTH accesses the disc in a standardized fashion, the user will be unaware of differences between drives.
204
Bit-slice processors Whde the above processors wdl cope with the malo~Et~ ~1 applications, especially where complex operations aIrconcerned, the need occasionally arL~e~ h~ .~ pro~e~_~t,t whose speed ol operation ts very important, but who~c' program is not too complicated. In this cast., bit-slice processors are used, for which the authors have adopted the AMD 2900 series as standard In the first apphcation, programming was carried out on a bit-by-bit basis; the program was tested first using EPROM, then changed to much faster PROM foJ the running system. In more recent desagns, a writeable control store has been used wtth mlcrocode compdat~on being carried out on a host LSI-11. A special FORTH mic~ocodc comDler has been written that permits a rapid edit compile cycle that is ideal for development In these systems, PROMs may stdl be used for fixed apphcatlons
Motorola 68000 In a recent application to pattern recognmon in a phot.ographic plate measuring machine, greater arithmetic power was required that was available from the LSI-11/23. However, the difference was not great enough to warrant the establishment of a new standard processor within RGO. For this purpose, three Motorola 68000 processors were chosen. Programming will be carried out using a FORTH system running in a host Exorciser. This will enable the program to be downloaded into the 68000 using an asynchronous link Eventually the program will be set up in EPROM.
Specialized test equipment Three logic analysers are used for momtoring hardware and software. Two were supplied by Hewlett Packard (models 1610A and 1615), while the third is a Tektronix model 7D10 with DF1 display formatter. Buffer cards which incorporate ribbon-cable connectors for the HP logic analysers are available for the Exorcisers and MMS. These enable the microprocessor bus signals to be connected to the anatysers quickly and accurately. A printer for the HP analysers allows test procedures and samples of results to be incorporated in maintenance manuals.
Coping with technological change Since microprocessors are subject to very rapid technological change, it is amportant to establish a framework that allows for rapid developments, especially in the real-time processing and control fields. For this purpose, the authors have adopted the concept of quantum jumps in technology. In hardware, this means standardizing initially on a particular processor (in their case the 6800) and then doing all jobs, where feasible, using that processor. Only when there is a genuine requirement for more processing power is a different processor introduced (LSI-11), which then also becomes an accepted standard. In this way, the problem of trying to 'keep up with the latest model' is avoided. However, when there Js a major improvement in a microprocessor series, ut is then reasonable to change up (6800 to 6809, LSI-11/2 to LSI-11/23), provided that there is compatibility and that the software can be made to look essentially identical. Nevertheless, standardization is intended to help and not hinder, and should not therefore stand m the way of specialized developments; the use of the 68000 processor in a one-off application illustrates the point
microprocessors and microsystems
While hardware standardization helps to rationalize the almost bewildering choice of microprocessors and their variants, it is the software more than anything else that draws different branches of a microprocessor project together (although bus standardization can be a considerable help too). Again the software should not be allowed to fossilize, and should be reviewed alongside the quantum jumps in hardware technology. This is also reasonable, since different hardware devices tend to be used in orthogonal applications. Thus the M6800s are normally used here for instrument control, while the LSI-I I s tend to be used as minicomputer replacements. As mentioned above, some software work on the M6800 was carried out using a cross compiler on the 1903T computer. Some work has also been done using the Motorola disc operating system (MDOS) on the Exerciser, particularly in respect of software for PROM programming. However, the dominant force unifying the work on microprocessors at RGO has been the use of the FORTH language. Apart from its excellent features as a real-time interactive language, it enables users to transfer readily between processors without having to learn different job-control languages and editors. Thus, a user who has programmed for 6800 or LSI-I I may readily convert to microcode programming for the AMD 2900 series, since the high-level microcode looks like normal FORTH, apart from the fact that allowance must be made for the ability of a bit-slice processor to carry out more than one action at a time.
FORTH P R O G R A M M I N G SYSTEM While FORTH has been in use by an enthusiastic band of followers for over a decade now, it has only recently begun to achieve wider popularity, especially amongst hobbyists. Readers may thus be unfamiliar with the language; the authors will therefore describe some of its most important features.
Historical invented by Charles H Moore in the late 1960s. It was first implemented on an IBM 1130, coded in FORTRAN.This was the culmination of a number of years of work on interactive languages by Moore, using a number of different hosts, including ALGOL and COBOL. The name FORTH was intended to be 'fourth', representing fourth-generation computers, but because the IBM 1130 could only accommodate five-letter identifiers, a contraction was required and the 'u' was dropped. Subsequently, FORTH was used on the National Radio Astronomy Observatory 11 m telescope at Kitt Peak, where it continues to lead a distinguished career in the discovery of molecules in space; this was the first 'modern' version of FORTH. The language was taken up particularly in the astronomical community, and especially by Elizabeth Rather at Kitt Peak National Observatory, where it has been used in a large number of real-time applications. After Moore and Rather left at the time Forth Inc. was formed, a large number of new application areas were opened up, and today astronomy is only a minority user of the language. FORTH 4,s was
Principal features of FORTH FORTH is an interactive language that uses a linked dictionary for interpreting words input from a terminal. The dictionary defines the action to be taken in response to an input word, and is precompiled so that execution is very
vol 7 no 5 lune 1983
rapid. Data is communicated between sections of program usually by means of a parameter stack, which is also used for temporary storage of numbers input from the terminal. FORTH contains an assembler that allows dictionary entries to consist of straight assembler code, and an editor for entering and editing programs on-disc. A virtual memory scheme is used for handling both programs and data on the disc. The system in FORTH contains a basic dictionary that includes definitions used by most applications, including the editor and assembler. Programming consists of adding further definitions to the dictionary to form an 'application vocabulary'.
Stack When numbers are typed at the terminal, they are left on the parameter stack where they can be picked up by a command later. This gives rise to reverse Polish notation, where arguments precede their operators. Dictionary entries may, if appropriate, use parameters left on the stack and/or leave results there.
Dictionary The dictionary is open ended, so that new definitions may be added either from the terminal or, more usually, from the disc. For example, an astronomer may wish to insert a definition that closes down a telescope for the night. This may be done, say, by typing in : GOOD-BYE CLOSE MIRROR CLOSE DOME PARK ; This would enter a dictionary definition named GOOD-BYE, with cross references to the five words CLOSE... PARK (note CLOSE occurs twice) as well as the semicolon, which is used to complete the definition. At this point, no action has been taken, and only compilation has occurred. Note that all the 'words' (any string of characters separated by spaces), apart from GOOD-BYE, were already in the dictionary at the start of compilation. The : is particularly interesting, as it is a normal FORTH dictionary entry. When it is executed as part of the input by being looked up in the dictionary, just as any other FORTH word would be, it makes up a new dictionary entry named GOOD-BYE, links it into the dictionary and enters a compile mode that in turn enters all the items in the definition until the semicolon, which then returns FORTH to its normal execute mode. If GOOD-BYE is typed later, it is looked up in the dictionary and its components CLOSE... PARK are executed in turn. One way of implementing CLOSE is for it simply to leave, say, a ~)on the stack. The antithesis, OPEN would then leave 1 on the stack. Subsequently, MI RROR and DOME would each test the value on top of the stack, performing the appropriate close operation if the value was zero, open if nonzero.
Logical structures Logical jumps and loops, both definite and indefinite, can all be implemented within the confines of a dictionary entry. Thus the definition above may be used elsewhere in the telescope vocabulary, by closing down if it starts raining: :CHECK RAINING IF GOOD-BYE THEN; where RAINING leaves a nonzero value on the stack if it is raining, zero if it is not. If CHECK is typed at the terminal, or executed as part of another definition, it will
205
close the telescope down If =t is raining, but wdl do nothing otherwise. Note the reverse Polish notation, where the condition precedes the IF. The more general IF . . . E L S E . . THEN clause may also be used: if the item on the stack at the time IF is executed is 'true' (nonzero), the words between IF and ELSE are executed; if 'false' (zero), the word~ between ELSE and THEN are executed. There arc related structures for definite and indefinite loops. S~m~lar structures are also available in the assembler.
Mass storage A virtual memory scheme ts used that allows data to be accessed on disc as if it were normal memory. For example, data arrays may be defined on the disc. This facility is achieved by swapping blocks 1024 byte long in and out of the disc. The same virtual memory scheme is used for loading programs. The program is kept in source form and, as each block is read, it is compiled just as if it had been typed at the terminal. Because FORTH compiles very rapidly, it ~s not necessary to have both source and precompiled versions of a program on disc. Apart from reducing the amount of disc space needed, it greatly simplifies the programmer's view of the system. Earlier FORTH systems used an 'irreducible minimum' dictionary called a kernel to set the system going, the majority of the basic system then being loaded from source, including such facilities as the assembler, editor, stack operators and multitasking. More recently, there has been a trend to use a larger precompiled system for more instant start up, although applications remain in source form and the source for the basic system is still available to permit modification.
General The keynote of FORTH is simplicity; it lends itself equally
well to use in large applications, like image processing, as it does to small 'blind' systems which execute only a single word and need no terminal. PROM-based systems may be generated typically by performing a special compilation that leaves an image of the PROM on disc. An interesting feature of FORTH is the way m which traditional distinctions are blurred or even eradicated. Thus there is no real distinction between the following pa~rs of items: program and data information on disc; inputting commands from disc or terminal; putting numbers on the stack inside a program or explicitly at the terminal; compiling from disc or terminal; system words, including assembler and editor; and application words. It is thus much more appropriate to describe FORTH as a programming system or software environment than a language; there is no separate operating system. Good FORTH programs comprise vocabularies with words that are relatively short. Each definition should contain only very few logical structures. This makes it possible to test all logical paths through each definition. The result has been found in practice to lead to very robust software with relatively few bugs, once complete testing has been carried out. The fact that the component definitions remain accessible to the user is a great help when debugging equipment. For example, a complex program that controls a number of electric motors will make use of definitions that control individual motors. As these definitions are accessible at the terminal, the motors may be checked individually in a simple interactive way.
206
It is possJble to separate dtllererlt ~sectlon~~)1 the dl~++,+~ ary into unconnected vocabularies. Th~s alluw~ dwllezen[ applications to use the same words, but t<) L'XeUUIU thcn~ m the c o n t e x t o l t h e a p p h c a t i o n . The deflmtJcm mt'ntloned earher Is a typfcal ~asu When used normally ~t c~t+lpJlc'~ ,~ new deftnitmn into core, when used to plecxJrnpde a basic system, it sets up the delmition m disc space, when used m the context of mlcrocode compdatlon on to chsc, using a host microcomputer, tt names a subroutine that ~.an be referenced m the subsequent mi+rocode -I he ability to change the contextual meamng of wolds ~sa ve~ powerful feature of FORTH
APPLICATIONS This section briefly describes the various projects lor which microprocessors have already been used at RGO.
Motorola 6800 applications The M6800 has been used both as an intelligent logic device and as a mimcomputer replacement, particularly in the control of instruments, where high processing speed Js n~)t essential. The first four applications described in th~s sectlon follow a slmilar general structure, as shown in Figure I In each case the instrument concerned is mounted on a telescope and has ats own local microprocessor controller, mounted on or m ~t. Muluway connections link the microprocessor to electromechanical devlces such as motors and transducers m the instrument To communicate with the outside world, an RS232C asynchronous llnk is used lot carrying high-level commands and status mformatJon. This wdl normally be connected to an instrumentation or control computer, but may also he operated in a standalone mode using either a VDU el an 'engineer's controller-', which is microprocessor-based and Is able to generate the appropriate command messages on the hnk m response to dedlcated push-buttons, and to dhplay status mformatlon received from the instrument ThJs scheme has been adopted as a general standard for control of instruments at the telescope The serial link greatly slmphfles wlrtng, and datarate Js not a limltatlon, since control and status operations, as distinct Irom detection el the hght from an oblect, may be relatweiy slow. The interlace is one o[ the most wlde)y used, and may be connected to the computer elther directly or through CAMAC. The ability to operate the instrument duectlv from a VDU Is el considerable assistance in dlagnostics.
Taurus interferometer Taurus 6'~ is an imaging Fabry Perot interferometer developed jomtly by Imperial College, London, UK, and RGO (Figure 2) It is designed primarily for use wtth two-dimenstonal area detectors to map velocity fields of astronomical emlsslon-hne sources, using the Fabry Perot etalon as a narrowband tunable filter. Besides a servocontrolled scanning etalon, the instrument contains various filter mechamsms and moveable mirrors which can be moved m or out of the light path. The movement of the mechanisms and the separation and parallelism of the etalon plates are controlled by a microprocessor mounted on the telescope with Taurus and constructed using the MMS card system. Programmmg was carrted out m ASSEMBLER language on an Exorctser using MDOS. The instrument is normally controlled by the observer through an Exerciser runmng mucroFORI-H that acts as an instrument computer.
m/croprocessors and mtcrosystems
Taurus also contains a photomultiplier, which may be used either for monitoring variations in sky transparency or for wavelength calibrations, the latter using standard sources under control of the onboard microprocessor. Photomultiplier output is recorded by means of photon counting using a hardware counter built into the Exorciser. Automatic calibration software with graphics output has also been implemented. Taurus is a 'travelling' instrument, and has been used very successfully at a number of major observatories worldwide.
Acquisition and guidance unit The unit ('A & G box') has been developed for the 2.5 m telescope on La Palma as a joint project with Dunsink Observatory, Dublin. It is fully automated, containing a TV camera and autoguider head, both on × -Y slides, together with an array of filter slides, moveable mirrors and calibration lamps. All these various mechanisms are controlled by a local microprocessor controller based on the MMS system. An asynchronous link connects It to a telescope control computer, following the scheme of Figure I. Cassegrain spectrograph This spectrograph has been designed for the 2.5 m telescope on La Palma. From the electronics point of view it is similar to the A & G box above: ~t contains a variety of electromechanical devices controlled by an MMS system mounted alongside the instrument and connected to the telescope control computer via an asynchronous link. Prime focus assembly and plate camera This instrument is intended to provide automatic facilities for the prime focus on the 2.5 m telescope. Automatic facilities are required since this focus lies at the top of the telescope where access is difficult. The facility consists of a basic assembly and a plate camera. The assembly provides
Telescope
Instrument
tl I
telescope focussing, instrument rotation and autoguider probe positioning and focussing. Detectors may be electronic or photographic. For photographic work, a plate camera is provided, with remote plate and filter changing, as well as remote control of calibration sources, fiducial marks, shutter, dark slide and various clamps. The basic assembly and plate camera are each controlled by a separate MMS system mounted off the telescope, because of the restricted space available for electronics at the prime focus. Once again, each controller accepts commands and returns status over an RS232C asynchronous link. In normal use on La Palma, the basic assembly will be controlled from the telescope control computer, while the plate camera will be controlled from the instrumentation computer.
Four-star photometer As its name suggests, this instrument is a device for measuring the brightness of four stars simultaneously. It uses a single photomultiplier, which has light fed to it from each star in turn, through a system of fibre optics and a rotating mask. The rate of sampling of each star is high, compared with variations in atmospheric conditions, allowing such effects to be calibrated. This feature is particularly useful for measuring variable stars that show only a small percentage variation in brightness. Synchronizing information from the mask, and photon output pulses from the photomult~plier, are passed to an Exorciser that accumulates counts for each of the four channels. Channel count information is output periodically at the terminal. A sliding average count for each channel is also maintained, and plotted on a four-channel recorder in logarithmic form as astronomical magnitude. Autoguider The atoguider is used to determine the tracking error of a telescope as it follows an object in the sky. It does this by sensing the position of a star in the focal plane of the telescope, using an image dissector photomultiplier. The sensztive area of the dissector consists of a small parch on the cathode, defined by an electron lens, that can be moved around the front surface by changing the current in a pair of magnetic deflecting coils. The reference star image is scanned, using the deflecting coils, to determine the position of its centre, and so to provide a measure of tracking error. Scanning, in the form of a Maltese cross pattern, is controlled by an M6800 microprocessor mounted in a
Local m=croprocessor controller Asynchronous hnk
VDU I
Control/instrument computer
Engineer's controller
I
Observer Figure 1. M6800 instrument control concept
vol 7no 5 /une 1983
Figure 2. Taurus Fabry-Perot scanning interferometer moun ted on the A nglo-A ustralian Telescope
207
Motorola micromodule chassis (Figure 3). It also collects photon counts from the photomultiplier. An AMD 9511 arithmetic chip is used to speed up calculation of the star image centre, which is carried out about once per second. Communication with the telescope control system ~s through an asynchronous link. Extensive memory-mapped graphics facilities are available to give useful information during observation, such as a low-resolution picture of the star field, the position of the guide star with respect to ~ts fiducial point, the size of the atmospheric 'seeing', cross-sectional plots through the star image and statistics of the tracking errors. The user selects from various options by means of a light pen and menu displayed on the screen. Programming was originally in microFORTH, but has recently been converted to po]yFORTH. The final version will use a fixed PROM program, incorporating access to FORTH for diagnostics as described below. The guider will be used on the 1.0 m and 2.5 m telescopes at La Palma.
Reticon photon counting system This detector (RPCS) was budt as a spectroscopl~ detector for use on the 1.9 m telescope at the South Alrican Asuo nomical Observatory (SAAO) 8. The RPCS is mounted on an intermediate dispersion spectrograph at the Cassegr am focus of the telescope. It has two optically coupled threestage image intensifiers {Figure 4), so that the spectrum projected onto the front of the intensifier stack appeal s at the rear phosphor in the form of bright scintillations. The rear phosphor is coupled fibre-optically to a dual ReUcon diode array, each with 936 elements; one for the objecl, and one for sky background The Reticon is scanned at intervals ol 3 ms. Photon events in each frame are centred to half a &ode and counted, one count per event, in two recirculating memories running synchronously wfth the readout to give 1872 'bins' for each spectrum. These memories, along with event detection and display logic, are mounted in a ser=es of CAMAC modules. For development purposes, an Exorciser running under polyFORTH was used in conjunction with a CAMAC crate controller of the type outlined above; data output was to a DC300 magnetic cartridge. The RPCS has now been incorporated into the observatory minicomputer system used at SAAO, and is m regular use for observational research
LSI-11 applications So far, the LSI-I I has been used mainly as a minicomputer replacement in digital imaging applications
Figure 3. Image dissector autoguider on laboratory bench
3 - stage
5 - stage
intensifier
tntenstfler
Solid-state detectors In this project, solid-state detectors are used in the analogue mode 9'1°. A typical system is shown in Figure 5. The solid-state area detector (CI D or CCD) is mounted in a liquid-nitrogen-cooled cryostat at the telescope focus, to keep the dark signal down during long integrations on faint objects. A microprogrammable bit-slice controller is used to generate the waveforms needed to extract the
Detector head electronics
Rettcon d=ode arroy
Spectrum
Telescope control room
CAMAC
Dtsplay
Circulatmg
Event
Crate
memories
detect;on
controller
CRT
!: ..... I
I
I
J
. . . . . . . .
Instrument computer
Figure 4. Reticon Photon Counting System 208
mtcroprocessors and microsystems
charge on the chip, using slow-scanning techniques. The controller, which may need to be mounted several metres away, is connected via an optically isolated parallel link to a 'local driver box' close to the chip, that generates the correct signal levels and edges for the detector. It also contains signal extraction circuitry and an analogue-todigital converter. Digital image data is passed down a parallel RS422 balanced-line link to an LSI-11/23 microcomputer, either via CAMAC or using a direct interface to the Q-bus. The link is also used to download the controller microprogram from the microcomputer. Images may be displayed using a digital TV memory, mounted either in the computer chassis or in a separate display unit. Data is recorded either on disc or magnetic tape, and software is provided for image processing so that data quality can be assessed at the telescope.
Software development One LSI-11/23 has been allocated to software development for the PDS microdensitometer (PDP ] 1/34A). Since the microdensitometer is a heavily used national facility, software development time on it is limited. The LSI-11/23, which has a cartridge disc compatible with that on the microdensitometer, permits most of the software to be developed without interfering with the scientific use of the microdensitometer. Bit-slice processor applications Bit-slice processors have been used in two applications: a CAMAC serial highway driver, and for programmable waveform generators for solid-state detectors.
CAMAC serial highway driver In this application, a driver was required for mounting in a Nova computer to control a remote CAMAC crate 11. The CAMAC serial highway (RS422 signalling) was used, operating in the byte parallel mode.
LN2 cooled cryostot
Loco I drwer
CCDch~p
I
box
/\ Ophcolly=soloted parallelhnk M=croproorornrnable controller
Telescope control room
RS422 parallellink
I ~
LSI- II
~
Standard peripherals
TV d=splay Figure 5. Layout of cooled solid-state detector system
vo/ 7 no 5/une 1983
The driver operates under the conventional computer DMA mode. CAMAC commands are compiled into 'frames' in the computer, consisting of from two to four computer words, depending upon the type of command. A command is executed by sending the address of the frame to the driver, which then picks up the contents of the frame, using DMA access, and executes the command. Where appropriate, data is transferred to or from memory, also under DMA. Commands may be single, with or without data, or in the form of block transfers. The serial highway driver was implemented using a pair of Am 2909 sequencers and four Am 2901 chips to form a 16 bit ALU, along with a 48 bit wide microprogram in PROM. The main function of the driver is to collect commands and to any write data from the computer memory under DMA, to divide the command up into bytes and transmit those bytes, to assemble the resulting reply and to put any read data back into the computer memory under DMA. Microprogramming was carried out on a somewhat laborious bit-by-bit basis, with coding chosen to minimize the number of bits programmed in the PROMs, according to the most frequently used field codes. This meant that most bugs could be fixed by blowing one or more bits in the PROM. For convenience, EPROM was used to develop the program using a slower clock rate, before converting to bipolar PROM.
Solid-state camera controllers Two controller designs have been implemented for the solid-state detector program, one for the CID, and the other for CCDs. Several copies of the latter are planned. The CID controller is somewhat different, in that the chip must be run in the nondestructive multiple readout mode to reduce the effect of noise in the output amplifier. The controllers use an Am 2910 12 bit wide controller with three Am 2901s, forming a 12 bit ALU used for 'do loop' counting and subroutine nesting. A writeable control store is used for the microword; in the CCD case this may be extended by adding cards to the system, 16 bits at a time. Standard microword width for the ~CD controller is 80 bits. The microword contains individual bits for driving individual detector chip control lines, so that arbitrary sequences of clock signals may be implemented, making it a simple matter to experiment with different waveforms to drive the chip in order to obtain optimum performance. An important feature of the development cycle has been the use of microcode FORTH. As mentioned above, it is possible to change the meaning of familiar FORTH words by switching context to a different vocabulary. A microcode vocabulary is used to change the meaning of 'colon' definitions, so that they become microcode subroutines, while logical structures are interpreted in the form of conditional jumps. Thus the user may write microcode in a way that looks essentially identical to other FORTH; the source blocks may be edited in the normal way using the standard FORTH editor. However, when these blocks are compiled in the context of the microcode vocabulary, they form an image of the microcode on disc which may be downloaded to the microcontroller writeable control store. There are two significant differences from programming in conventional FORTH. • The user must be aware of pipelining in the bit-slice processor, since, although its effect is not visible in the
209
•
program text, such details as setting up the condition code for a logical jump must be done in the microcycle previous to the jump. The end of each mlcrocycle must be delineated by a special symbol, as several activities can take pla6e in one cycle, e.g. more than one clock driver line might be changed at the same time.
Use of this compiler has greatly simplified the development of the microcode and allowed more experimental modes to be evaluated than could otherwise easily have been tried.
FUTURE DEVELOPMENTS There are numerous hardware and software developments that are hkely to have a considerable effect on the use of microprocessors in astronomy A few topics where requirements already exist are given below.
Memories While the RAM memory requirement for programs has remained relatively unchanged, the size of digital images in regular use has been expanding rapidly. Currently, 512 x 512 pixels will cover most applications, but there are plans to build CCD detectors an order of magmtude larger in area. If these images are to be processed efficiently, with minimal disc transfers, then significant fractions of each image must be able to be held in RAM at any one time. Developments m large RAMs, array processing, high-capacity but physically small Winchester discs and 32 bit microprocessors will have important effects m this area. Ultimately, it may be expected that astronomers will have personal microcomputers on their desks that are capable of handling large images, so greatly improving the efficiency with which observational research can be undertaken.
Serial interfaces Whde parallel access is reqmred to fast dev=ces such as memory, many external devices are slow and can adequately be served by a low-speed serial interface. Within a large instrument such as a spectrograph, ~t would be an advantage to control electromechanical devices with a simple lowpower interface chip mounted on each mechanism and connected to the control processor by a twisted pair. In this area, the Hewlett Packard HP-IL, combining low power with simple wiring may prove very useful
I nstruction sets The majority of instruction sets on microprocessors are not related to any high-level language, and are therefore much less efficient when used for this purpose. However, the Pascal Micro Engine from Western Digital has been designed with PASCAL in mind, and coprocessors have been produced for other microprocessors to support serial instruction sets; various prototype FORTH computers have also been built. Clearly, a great improvement in processing power would accrue if a microprocessor were to be produced with a FORTH-oriented instruction set.
Voice input/output It is apparent that voice input and output will be used increasingly in the future, principally for operation, but also for programming. Because of FORTH's dictionary structure, it is especially well adapted to accepting voice input. When associated with software that assists the user.
210
voice I/O should greatly slmpldy the task th~ user la~.', when confronted with a new instrument at the telescope. it should also help wtth diagnostics, partlculally b~, s[al~ who are unfamdlal wrth lhc u~e of computcr~
Diagnostics and black boxes Where a microprocessor b incorporated rote a dused or 'black box' devtce, attention must be pard to the types oi dtagnostic facilities needed Diagnostics might range trom simple control of electromechanical mechanisms, for the mechamcal engineer concerned wzth optical alignment, to sophisttcated diagnostics for the electromcs engineer investigating a subtle system ploblem. The iormer are easy to anticipate but need to be well defined, use el the controls should not reqmre much training. The latter ate difhcult to anticipate, but a htghly trained person wd] be using them The balance between spending time on designing good d~agnostJcs and spending time finding faults with poor diagnostics depends very much on individual circumstances. Astronomical instruments tend to be one-oifs, and so time spent in prowding dJagnostscs Js unhkcly to be well repaid in time saved on fault finding itsell However, when the cost of telescope downtime Is considered, good diagnostics are essentzal. Recently, the authors have developed a FORTH system to run in read-only memory which will form the basis for futureM6800apphcationsofth~stype I t l s w n t t e n msuch a way that the black-box apphcatlon runs effher as a background task, or can be aborted, allowing a VDU to be plugged in to access the FORTH system. This makes a large vocabulary available for diagnostics, comprising the mdwldual definmons that make up the applicanon Inth~sway, very Ifftle extra effort is needed to prowde very powerful diagnostics which can be tadored to the user's reqmrements, making a separate engineer's controller unnecessary
Networks and distributed intelligence Astronomical instrumentation has followed the recent tend to distributed intelligence, with neatly all instruments on telescopes now contaimng thetr own control mtcroprocessors. This has paralleled the trend towards structured programming m software. A particularly exerting development has been that of local area networks, which allow intelligent devfces to commumcate with each other An interestmg future use of networking is Jn telescope drive systems. Conventional optical telescopes use an equatorial mounting that contains an reclined polar axis that is parallel to the rotation axis of the Earth. To track a star, the telescope ~s rotated about this axts at a uniform rate, in the sense that ncutrahzes the rotatton of the Earth. Only minor corrections are then necessary to track the star accurately. Unfortunately, because the axis Is inchned, mechamcal engineering problems arise that become sevcre for large telescopes. Mechamcally a far simpler solution ts to use verttcal and horizontal axes in the form of an 'alt-az' (altitude and azimuth) mounting. Both axes must then be driven actively, and at varying rates. An elegant way of achieving this is to use a microprocessor to drive each axis, each processor being responstble for calculating the movement of its axis, as a function of time, m order to track a particular star. These may be connected via a network to other processors, such as guidance sensors, to form a complete control system. In such a configuration, processors could 'talk FORTH'
m~croprocessors and mtcrosystems
to each other when transferring information or commands. An instrumentation computer, VDU, engineer's controller or voice input terminal could then be connected to the network, either to control the whole system, or to debug the exercise individual processors. There will almost certainly be local area networks at the new observatory on La Palma, both for instrumentation and some aspects of control. Similar networks are being implemented or planned at RGO, and it is possible that, m the future, a satellite link between these networks might be used to permit remote observing and diagnostics. Thus, individual expertise at RGO could be applied to problem solving without the individual having to travel to La Palma, greatly increasing the effective use of resources. CONCLUSIONS During the last few years, microprocessors have found increasing use at the Royal Greenwich Observatory, where they have been incorporated into a variety of different devices at a variety of different levels. Throughout, we have attempted to establish standard approaches, where appropriate, both to unify concepts and to optimize the use of equipment and manpower. As a consequence, a sound foundation has been laid which, It is hoped, will support many exciting new developments in the near future.
2
mittee of European Laboratories, Eur6500 (1978) 3
REFERENCES 1
Parker,N M 'A simple but fast microprocessor controller for CAMAC' Proc. ESO/SRC Conf. Applications of CAMAC to Astronomy Geneva, Switzerland (1978) p118
vol 7 no 5 lune 1983
Cittolin, S and Taylor, B G 'CAVIAR - interactive microcomputer control and monitoring of multicrate CAMAC systems' IERE Conf. Proc. (No 41) microprocessors in automation and communications
University of Kent at Canterbury, 19-22 September 1978, p 3O9 4
Moore, C H 'FORTH: a new way to program a minicomputer' Astron. Astrophys. Suppl. Vol 15 (1974) p 497
S
James, J S 'What is FORTH? a tutorial introduction' Byte Vol 5 No 8 (August 1980)
6
Taylor, K and Atherton, P D 'Seeing-limited radial velocity field mapping of extended emission line sources using a new imaging Fabry-Perot system' Mon. Not. R. Astr. Soc. Vol 191 (1980) p 675
7
Atherton, P D, Taylor, K, Pike, C D, Harmer, C F W,
Parker, N M and Hook, R 'Taurus: a wide-field imaging Fabry-Perot spectrometer for astronomy' Mon. Not. R. Astr. Soc. (1982)
8
Jorden, A R, Read, P D, and van Breda, I G 'Photoncounting reticon system description and performance' Proc. SPIE Conf. instrumentation in astronomy IV USA (1982)
9
Jorden, P R and van Breda, I G 'The RGO charge injection device camera system' Proc. SPIE Conf. sohd-state imagers for astronomy Vol 290 (1981) p113
ACKNOWLEDGEMENTS Many people at RGO have contributed to the projects discussed here. In addition to those mentioned in the references, David Thorne has been largely responsible for the autoguider, Normal Walker has been in overall charge of the four-star photometer and Martin Fisher and Tony Seabrook have done much work on the hardware.
Multiple controllers in a CAMAC crate ESONE Com-
10 Jorden, P R, Thorne, D J and van Breda, I G 'The Royal Greenwich Observatory charge-coupled device camera' Proc. SPIE Conf. Instrumentation in astronomy IV USA (1982) 11 van Breda, I G 'A CAMAC serial highway driver' Proc, ESO/SRC conference on appflcations of CA MAC to astronomy (1978) p 132
211
microprocessors FORTH astronomy Since their introduction at the Royal Greenwich Observatory (RGO) in 1976, microprocessors have played an important part in data acquisition and control for astronomical instruments, as well as for data reduction and analysis. They have also become indispensible tools in the development cycles of instruments in the laboratory, and have found uses as logic replacements, intelligent instrument controllers, minicomputer replacements, personal computers and fast controllers; both 8 bit and 16 bit devices have been used in additlon to bit-slice chip sets. In any microprocessor project, software and the choice of language are crucial. The personal computers at RGO use BASIC but, for real-time applications, a more powerful interactive language was needed. FORTH was chosen for this purpose, because of its combination of high execution speed and powerful interactive command structure. Also, since it includes its own operating system, editor and assembler, it is probably the most highly standardized of all programming systems, making it simple to transport software between processors, and to adapt to new processors as they become available. This paper discusses general aspects of the work at RGO, and is divided into four sections: a general overview of the hardware used at RGO; a brief description of FORTH, which will probably be unfamiliar to most readers; descriptions of the projects for which the various microprocessors Royal Greenw=ch Observatory, Herstmonceaux Castle, Hailsham, East Sussex13N27 ] RP, UK
vol 7 no 5 lune 1983
have been used; and finally, an indication of likely future developments.
HARDWARE OVERVIEW Motorola 6800 8 bit microprocessors were the first to be used in this work. Subsequently, Digital Equipment LSI-I I series was added to the program, while maintaining the M6800 capability. The AMD 2900 series bit:slice chip set was also adopted, and there are plans to use the Motorola 68000 processor.
M 6 8 0 0 systems The reasons for choosing the M6800 initially, as opposed to a processor such as the Intel 8080, were not exceptionally strong. One of the authors had previous experience of the Motorola device, and it was well supported by the manufacturer, had good interfacing hardware and flexible development systems were available. At the time the project was started, funds were strictly limited, as microprocessors had not been widely accepted in astronomy, and it was necessary to begin with an RGO-designed Eurocard system; software was developed by cross assembly from an ICL 1903T mainframe computer. However, the process was very slow and, when funds became available after it had been shown that 'microprocessors actually work', a number of Motorola Exorciser development systems were purchased, each complete with dual floppy-disc drive. In addition, PROM programmers and user system evaluation (USE) modules were bought, allowing the Exorciser to replace the microprocessor integrated circuit in a target stand-alone system during development, prior to producing a PROM version of the program. Exorcisers have also been used as replacement minicomputers. Software was purchased in the form of micrOFORTH and subsequently of polyFORTH. This allowed a greatly improved and more rapid software development cycle over the cross assembler. A Camac crate controller was designed for the M6800, making use of the memory-mapping facilities of the I/O I . More recently, a version compatible with the EUR 65002 specification for auxiliary crate controllers has been developed. One special Exorciser is based on a set of circuit cards developed at CERN for their Caviar system 3 . It includes a Camac branch driver for use with 'A2' type crate controllers, an IEEE 488 bus controller and a cassette tape
0141-9331/83/040203- 08 $03.00 © 1983 Butterworth & Co (Publishers) Ltd
203
interface, as well as a video momtor drwer which plovides simple display facilitles. This exorclser is used mainly for test work. Whde Motorola Exorciser and Micromodule Chassls systems have been used for application purposes, the RGO Eurocard system has also been retained for those applications requiring a more compact format. This system zs referred to as the modular microprocessor system (MMS). Similar card systems are available commercially, but the MMS card systems are more economical to use, partly because the development costs have been pald m the past, and partly since they are well understood by observatory engineers and techniclans, as well as being backed up by a good supply of spares. More recently, a Motorola Exorset development system has been purchased, which uses the M6809 microprocessor, along with exorFORTH software. This will be used as an intelligent terminal for engineering diagnostics at the new observatory under construction at La Palma in the Canary Islands.
LSI-11 systems In 1978, work was begun at RGO on solid-state area detectors; in particular, charge-injection devices (CIDs) and charge-coupled devices (CCDs). These required two-dimensional image-handling software in addition to the more usual instrument control software. While the Exor¢iser could cope with instrument control, the 2D image software needed a more powerful processor. For this purpose the LSI-I 1 16 bit microcomputer was chosen. This choice was conditioned mainly by the fact that there was already a PDP-I 1/34 at RGO with FORTH imaging software for controlling a microdensltometer. Initially, the LSI-I I/2 processor was used, but more recently this has largely been superseded by the faster LSI-I 1/23. The standard disc used with the LSI-I I has been the ubiquitous Diablo series 30, 2.5 Mbyte removable cartridge drive. However, since the system is used a great deal for image handling, larger capacity Winchester discs have been added. Floppy discs have also been used, particularly for 'travelling' systems used to observe at remote sites, for which two Standard Engineering MIK 11/2 CAMAC controllers have been purchased. These controllers each contain an LSI-I I / 2 CPU and allow memory and peripheral devices to be mounted within the CAMAC crate. The original software on the PDP-I 1/34 was a miniFORTH system, and poIyFORTH has also been purchase. More recently, a 'home-designed' system closely compatible with polyFORTH has been introduced. This system, apart from overcoming some awkwardnesses in polyFORTH, optimizes the speed of disc transfer, as well as making it somewhat easier to precompile relatively large applications into PROM. These facilities are particularly useful where observations are being carried out at a remote slte, as the computer is then less dependent on the disc being in working order, particularly where low output datarates are encountered, such as in conventional astronomical photometry and polarimetry. Compatibility is maintained between systems by using essentially the same software~ with only the innermost section of the disc handler being specific to the particular type of drive. Because FORTH accesses the disc in a standardized fashion, the user will be unaware of differences between drives.
204
Bit-slice processors Whde the above processors wdl cope with the malo~Et~ ~1 applications, especially where complex operations aIrconcerned, the need occasionally arL~e~ h~ .~ pro~e~_~t,t whose speed ol operation ts very important, but who~c' program is not too complicated. In this cast., bit-slice processors are used, for which the authors have adopted the AMD 2900 series as standard In the first apphcation, programming was carried out on a bit-by-bit basis; the program was tested first using EPROM, then changed to much faster PROM foJ the running system. In more recent desagns, a writeable control store has been used wtth mlcrocode compdat~on being carried out on a host LSI-11. A special FORTH mic~ocodc comDler has been written that permits a rapid edit compile cycle that is ideal for development In these systems, PROMs may stdl be used for fixed apphcatlons
Motorola 68000 In a recent application to pattern recognmon in a phot.ographic plate measuring machine, greater arithmetic power was required that was available from the LSI-11/23. However, the difference was not great enough to warrant the establishment of a new standard processor within RGO. For this purpose, three Motorola 68000 processors were chosen. Programming will be carried out using a FORTH system running in a host Exorciser. This will enable the program to be downloaded into the 68000 using an asynchronous link Eventually the program will be set up in EPROM.
Specialized test equipment Three logic analysers are used for momtoring hardware and software. Two were supplied by Hewlett Packard (models 1610A and 1615), while the third is a Tektronix model 7D10 with DF1 display formatter. Buffer cards which incorporate ribbon-cable connectors for the HP logic analysers are available for the Exorcisers and MMS. These enable the microprocessor bus signals to be connected to the anatysers quickly and accurately. A printer for the HP analysers allows test procedures and samples of results to be incorporated in maintenance manuals.
Coping with technological change Since microprocessors are subject to very rapid technological change, it is amportant to establish a framework that allows for rapid developments, especially in the real-time processing and control fields. For this purpose, the authors have adopted the concept of quantum jumps in technology. In hardware, this means standardizing initially on a particular processor (in their case the 6800) and then doing all jobs, where feasible, using that processor. Only when there is a genuine requirement for more processing power is a different processor introduced (LSI-11), which then also becomes an accepted standard. In this way, the problem of trying to 'keep up with the latest model' is avoided. However, when there Js a major improvement in a microprocessor series, ut is then reasonable to change up (6800 to 6809, LSI-11/2 to LSI-11/23), provided that there is compatibility and that the software can be made to look essentially identical. Nevertheless, standardization is intended to help and not hinder, and should not therefore stand m the way of specialized developments; the use of the 68000 processor in a one-off application illustrates the point
microprocessors and microsystems
While hardware standardization helps to rationalize the almost bewildering choice of microprocessors and their variants, it is the software more than anything else that draws different branches of a microprocessor project together (although bus standardization can be a considerable help too). Again the software should not be allowed to fossilize, and should be reviewed alongside the quantum jumps in hardware technology. This is also reasonable, since different hardware devices tend to be used in orthogonal applications. Thus the M6800s are normally used here for instrument control, while the LSI-I I s tend to be used as minicomputer replacements. As mentioned above, some software work on the M6800 was carried out using a cross compiler on the 1903T computer. Some work has also been done using the Motorola disc operating system (MDOS) on the Exerciser, particularly in respect of software for PROM programming. However, the dominant force unifying the work on microprocessors at RGO has been the use of the FORTH language. Apart from its excellent features as a real-time interactive language, it enables users to transfer readily between processors without having to learn different job-control languages and editors. Thus, a user who has programmed for 6800 or LSI-I I may readily convert to microcode programming for the AMD 2900 series, since the high-level microcode looks like normal FORTH, apart from the fact that allowance must be made for the ability of a bit-slice processor to carry out more than one action at a time.
FORTH P R O G R A M M I N G SYSTEM While FORTH has been in use by an enthusiastic band of followers for over a decade now, it has only recently begun to achieve wider popularity, especially amongst hobbyists. Readers may thus be unfamiliar with the language; the authors will therefore describe some of its most important features.
Historical invented by Charles H Moore in the late 1960s. It was first implemented on an IBM 1130, coded in FORTRAN.This was the culmination of a number of years of work on interactive languages by Moore, using a number of different hosts, including ALGOL and COBOL. The name FORTH was intended to be 'fourth', representing fourth-generation computers, but because the IBM 1130 could only accommodate five-letter identifiers, a contraction was required and the 'u' was dropped. Subsequently, FORTH was used on the National Radio Astronomy Observatory 11 m telescope at Kitt Peak, where it continues to lead a distinguished career in the discovery of molecules in space; this was the first 'modern' version of FORTH. The language was taken up particularly in the astronomical community, and especially by Elizabeth Rather at Kitt Peak National Observatory, where it has been used in a large number of real-time applications. After Moore and Rather left at the time Forth Inc. was formed, a large number of new application areas were opened up, and today astronomy is only a minority user of the language. FORTH 4,s was
Principal features of FORTH FORTH is an interactive language that uses a linked dictionary for interpreting words input from a terminal. The dictionary defines the action to be taken in response to an input word, and is precompiled so that execution is very
vol 7 no 5 lune 1983
rapid. Data is communicated between sections of program usually by means of a parameter stack, which is also used for temporary storage of numbers input from the terminal. FORTH contains an assembler that allows dictionary entries to consist of straight assembler code, and an editor for entering and editing programs on-disc. A virtual memory scheme is used for handling both programs and data on the disc. The system in FORTH contains a basic dictionary that includes definitions used by most applications, including the editor and assembler. Programming consists of adding further definitions to the dictionary to form an 'application vocabulary'.
Stack When numbers are typed at the terminal, they are left on the parameter stack where they can be picked up by a command later. This gives rise to reverse Polish notation, where arguments precede their operators. Dictionary entries may, if appropriate, use parameters left on the stack and/or leave results there.
Dictionary The dictionary is open ended, so that new definitions may be added either from the terminal or, more usually, from the disc. For example, an astronomer may wish to insert a definition that closes down a telescope for the night. This may be done, say, by typing in : GOOD-BYE CLOSE MIRROR CLOSE DOME PARK ; This would enter a dictionary definition named GOOD-BYE, with cross references to the five words CLOSE... PARK (note CLOSE occurs twice) as well as the semicolon, which is used to complete the definition. At this point, no action has been taken, and only compilation has occurred. Note that all the 'words' (any string of characters separated by spaces), apart from GOOD-BYE, were already in the dictionary at the start of compilation. The : is particularly interesting, as it is a normal FORTH dictionary entry. When it is executed as part of the input by being looked up in the dictionary, just as any other FORTH word would be, it makes up a new dictionary entry named GOOD-BYE, links it into the dictionary and enters a compile mode that in turn enters all the items in the definition until the semicolon, which then returns FORTH to its normal execute mode. If GOOD-BYE is typed later, it is looked up in the dictionary and its components CLOSE... PARK are executed in turn. One way of implementing CLOSE is for it simply to leave, say, a ~)on the stack. The antithesis, OPEN would then leave 1 on the stack. Subsequently, MI RROR and DOME would each test the value on top of the stack, performing the appropriate close operation if the value was zero, open if nonzero.
Logical structures Logical jumps and loops, both definite and indefinite, can all be implemented within the confines of a dictionary entry. Thus the definition above may be used elsewhere in the telescope vocabulary, by closing down if it starts raining: :CHECK RAINING IF GOOD-BYE THEN; where RAINING leaves a nonzero value on the stack if it is raining, zero if it is not. If CHECK is typed at the terminal, or executed as part of another definition, it will
205
close the telescope down If =t is raining, but wdl do nothing otherwise. Note the reverse Polish notation, where the condition precedes the IF. The more general IF . . . E L S E . . THEN clause may also be used: if the item on the stack at the time IF is executed is 'true' (nonzero), the words between IF and ELSE are executed; if 'false' (zero), the word~ between ELSE and THEN are executed. There arc related structures for definite and indefinite loops. S~m~lar structures are also available in the assembler.
Mass storage A virtual memory scheme ts used that allows data to be accessed on disc as if it were normal memory. For example, data arrays may be defined on the disc. This facility is achieved by swapping blocks 1024 byte long in and out of the disc. The same virtual memory scheme is used for loading programs. The program is kept in source form and, as each block is read, it is compiled just as if it had been typed at the terminal. Because FORTH compiles very rapidly, it ~s not necessary to have both source and precompiled versions of a program on disc. Apart from reducing the amount of disc space needed, it greatly simplifies the programmer's view of the system. Earlier FORTH systems used an 'irreducible minimum' dictionary called a kernel to set the system going, the majority of the basic system then being loaded from source, including such facilities as the assembler, editor, stack operators and multitasking. More recently, there has been a trend to use a larger precompiled system for more instant start up, although applications remain in source form and the source for the basic system is still available to permit modification.
General The keynote of FORTH is simplicity; it lends itself equally
well to use in large applications, like image processing, as it does to small 'blind' systems which execute only a single word and need no terminal. PROM-based systems may be generated typically by performing a special compilation that leaves an image of the PROM on disc. An interesting feature of FORTH is the way m which traditional distinctions are blurred or even eradicated. Thus there is no real distinction between the following pa~rs of items: program and data information on disc; inputting commands from disc or terminal; putting numbers on the stack inside a program or explicitly at the terminal; compiling from disc or terminal; system words, including assembler and editor; and application words. It is thus much more appropriate to describe FORTH as a programming system or software environment than a language; there is no separate operating system. Good FORTH programs comprise vocabularies with words that are relatively short. Each definition should contain only very few logical structures. This makes it possible to test all logical paths through each definition. The result has been found in practice to lead to very robust software with relatively few bugs, once complete testing has been carried out. The fact that the component definitions remain accessible to the user is a great help when debugging equipment. For example, a complex program that controls a number of electric motors will make use of definitions that control individual motors. As these definitions are accessible at the terminal, the motors may be checked individually in a simple interactive way.
206
It is possJble to separate dtllererlt ~sectlon~~)1 the dl~++,+~ ary into unconnected vocabularies. Th~s alluw~ dwllezen[ applications to use the same words, but t<) L'XeUUIU thcn~ m the c o n t e x t o l t h e a p p h c a t i o n . The deflmtJcm mt'ntloned earher Is a typfcal ~asu When used normally ~t c~t+lpJlc'~ ,~ new deftnitmn into core, when used to plecxJrnpde a basic system, it sets up the delmition m disc space, when used m the context of mlcrocode compdatlon on to chsc, using a host microcomputer, tt names a subroutine that ~.an be referenced m the subsequent mi+rocode -I he ability to change the contextual meamng of wolds ~sa ve~ powerful feature of FORTH
APPLICATIONS This section briefly describes the various projects lor which microprocessors have already been used at RGO.
Motorola 6800 applications The M6800 has been used both as an intelligent logic device and as a mimcomputer replacement, particularly in the control of instruments, where high processing speed Js n~)t essential. The first four applications described in th~s sectlon follow a slmilar general structure, as shown in Figure I In each case the instrument concerned is mounted on a telescope and has ats own local microprocessor controller, mounted on or m ~t. Muluway connections link the microprocessor to electromechanical devlces such as motors and transducers m the instrument To communicate with the outside world, an RS232C asynchronous llnk is used lot carrying high-level commands and status mformatJon. This wdl normally be connected to an instrumentation or control computer, but may also he operated in a standalone mode using either a VDU el an 'engineer's controller-', which is microprocessor-based and Is able to generate the appropriate command messages on the hnk m response to dedlcated push-buttons, and to dhplay status mformatlon received from the instrument ThJs scheme has been adopted as a general standard for control of instruments at the telescope The serial link greatly slmphfles wlrtng, and datarate Js not a limltatlon, since control and status operations, as distinct Irom detection el the hght from an oblect, may be relatweiy slow. The interlace is one o[ the most wlde)y used, and may be connected to the computer elther directly or through CAMAC. The ability to operate the instrument duectlv from a VDU Is el considerable assistance in dlagnostics.
Taurus interferometer Taurus 6'~ is an imaging Fabry Perot interferometer developed jomtly by Imperial College, London, UK, and RGO (Figure 2) It is designed primarily for use wtth two-dimenstonal area detectors to map velocity fields of astronomical emlsslon-hne sources, using the Fabry Perot etalon as a narrowband tunable filter. Besides a servocontrolled scanning etalon, the instrument contains various filter mechamsms and moveable mirrors which can be moved m or out of the light path. The movement of the mechanisms and the separation and parallelism of the etalon plates are controlled by a microprocessor mounted on the telescope with Taurus and constructed using the MMS card system. Programmmg was carrted out m ASSEMBLER language on an Exorctser using MDOS. The instrument is normally controlled by the observer through an Exerciser runmng mucroFORI-H that acts as an instrument computer.
m/croprocessors and mtcrosystems
Taurus also contains a photomultiplier, which may be used either for monitoring variations in sky transparency or for wavelength calibrations, the latter using standard sources under control of the onboard microprocessor. Photomultiplier output is recorded by means of photon counting using a hardware counter built into the Exorciser. Automatic calibration software with graphics output has also been implemented. Taurus is a 'travelling' instrument, and has been used very successfully at a number of major observatories worldwide.
Acquisition and guidance unit The unit ('A & G box') has been developed for the 2.5 m telescope on La Palma as a joint project with Dunsink Observatory, Dublin. It is fully automated, containing a TV camera and autoguider head, both on × -Y slides, together with an array of filter slides, moveable mirrors and calibration lamps. All these various mechanisms are controlled by a local microprocessor controller based on the MMS system. An asynchronous link connects It to a telescope control computer, following the scheme of Figure I. Cassegrain spectrograph This spectrograph has been designed for the 2.5 m telescope on La Palma. From the electronics point of view it is similar to the A & G box above: ~t contains a variety of electromechanical devices controlled by an MMS system mounted alongside the instrument and connected to the telescope control computer via an asynchronous link. Prime focus assembly and plate camera This instrument is intended to provide automatic facilities for the prime focus on the 2.5 m telescope. Automatic facilities are required since this focus lies at the top of the telescope where access is difficult. The facility consists of a basic assembly and a plate camera. The assembly provides
Telescope
Instrument
tl I
telescope focussing, instrument rotation and autoguider probe positioning and focussing. Detectors may be electronic or photographic. For photographic work, a plate camera is provided, with remote plate and filter changing, as well as remote control of calibration sources, fiducial marks, shutter, dark slide and various clamps. The basic assembly and plate camera are each controlled by a separate MMS system mounted off the telescope, because of the restricted space available for electronics at the prime focus. Once again, each controller accepts commands and returns status over an RS232C asynchronous link. In normal use on La Palma, the basic assembly will be controlled from the telescope control computer, while the plate camera will be controlled from the instrumentation computer.
Four-star photometer As its name suggests, this instrument is a device for measuring the brightness of four stars simultaneously. It uses a single photomultiplier, which has light fed to it from each star in turn, through a system of fibre optics and a rotating mask. The rate of sampling of each star is high, compared with variations in atmospheric conditions, allowing such effects to be calibrated. This feature is particularly useful for measuring variable stars that show only a small percentage variation in brightness. Synchronizing information from the mask, and photon output pulses from the photomult~plier, are passed to an Exorciser that accumulates counts for each of the four channels. Channel count information is output periodically at the terminal. A sliding average count for each channel is also maintained, and plotted on a four-channel recorder in logarithmic form as astronomical magnitude. Autoguider The atoguider is used to determine the tracking error of a telescope as it follows an object in the sky. It does this by sensing the position of a star in the focal plane of the telescope, using an image dissector photomultiplier. The sensztive area of the dissector consists of a small parch on the cathode, defined by an electron lens, that can be moved around the front surface by changing the current in a pair of magnetic deflecting coils. The reference star image is scanned, using the deflecting coils, to determine the position of its centre, and so to provide a measure of tracking error. Scanning, in the form of a Maltese cross pattern, is controlled by an M6800 microprocessor mounted in a
Local m=croprocessor controller Asynchronous hnk
VDU I
Control/instrument computer
Engineer's controller
I
Observer Figure 1. M6800 instrument control concept
vol 7no 5 /une 1983
Figure 2. Taurus Fabry-Perot scanning interferometer moun ted on the A nglo-A ustralian Telescope
207
Motorola micromodule chassis (Figure 3). It also collects photon counts from the photomultiplier. An AMD 9511 arithmetic chip is used to speed up calculation of the star image centre, which is carried out about once per second. Communication with the telescope control system ~s through an asynchronous link. Extensive memory-mapped graphics facilities are available to give useful information during observation, such as a low-resolution picture of the star field, the position of the guide star with respect to ~ts fiducial point, the size of the atmospheric 'seeing', cross-sectional plots through the star image and statistics of the tracking errors. The user selects from various options by means of a light pen and menu displayed on the screen. Programming was originally in microFORTH, but has recently been converted to po]yFORTH. The final version will use a fixed PROM program, incorporating access to FORTH for diagnostics as described below. The guider will be used on the 1.0 m and 2.5 m telescopes at La Palma.
Reticon photon counting system This detector (RPCS) was budt as a spectroscopl~ detector for use on the 1.9 m telescope at the South Alrican Asuo nomical Observatory (SAAO) 8. The RPCS is mounted on an intermediate dispersion spectrograph at the Cassegr am focus of the telescope. It has two optically coupled threestage image intensifiers {Figure 4), so that the spectrum projected onto the front of the intensifier stack appeal s at the rear phosphor in the form of bright scintillations. The rear phosphor is coupled fibre-optically to a dual ReUcon diode array, each with 936 elements; one for the objecl, and one for sky background The Reticon is scanned at intervals ol 3 ms. Photon events in each frame are centred to half a &ode and counted, one count per event, in two recirculating memories running synchronously wfth the readout to give 1872 'bins' for each spectrum. These memories, along with event detection and display logic, are mounted in a ser=es of CAMAC modules. For development purposes, an Exorciser running under polyFORTH was used in conjunction with a CAMAC crate controller of the type outlined above; data output was to a DC300 magnetic cartridge. The RPCS has now been incorporated into the observatory minicomputer system used at SAAO, and is m regular use for observational research
LSI-11 applications So far, the LSI-I I has been used mainly as a minicomputer replacement in digital imaging applications
Figure 3. Image dissector autoguider on laboratory bench
3 - stage
5 - stage
intensifier
tntenstfler
Solid-state detectors In this project, solid-state detectors are used in the analogue mode 9'1°. A typical system is shown in Figure 5. The solid-state area detector (CI D or CCD) is mounted in a liquid-nitrogen-cooled cryostat at the telescope focus, to keep the dark signal down during long integrations on faint objects. A microprogrammable bit-slice controller is used to generate the waveforms needed to extract the
Detector head electronics
Rettcon d=ode arroy
Spectrum
Telescope control room
CAMAC
Dtsplay
Circulatmg
Event
Crate
memories
detect;on
controller
CRT
!: ..... I
I
I
J
. . . . . . . .
Instrument computer
Figure 4. Reticon Photon Counting System 208
mtcroprocessors and microsystems
charge on the chip, using slow-scanning techniques. The controller, which may need to be mounted several metres away, is connected via an optically isolated parallel link to a 'local driver box' close to the chip, that generates the correct signal levels and edges for the detector. It also contains signal extraction circuitry and an analogue-todigital converter. Digital image data is passed down a parallel RS422 balanced-line link to an LSI-11/23 microcomputer, either via CAMAC or using a direct interface to the Q-bus. The link is also used to download the controller microprogram from the microcomputer. Images may be displayed using a digital TV memory, mounted either in the computer chassis or in a separate display unit. Data is recorded either on disc or magnetic tape, and software is provided for image processing so that data quality can be assessed at the telescope.
Software development One LSI-11/23 has been allocated to software development for the PDS microdensitometer (PDP ] 1/34A). Since the microdensitometer is a heavily used national facility, software development time on it is limited. The LSI-11/23, which has a cartridge disc compatible with that on the microdensitometer, permits most of the software to be developed without interfering with the scientific use of the microdensitometer. Bit-slice processor applications Bit-slice processors have been used in two applications: a CAMAC serial highway driver, and for programmable waveform generators for solid-state detectors.
CAMAC serial highway driver In this application, a driver was required for mounting in a Nova computer to control a remote CAMAC crate 11. The CAMAC serial highway (RS422 signalling) was used, operating in the byte parallel mode.
LN2 cooled cryostot
Loco I drwer
CCDch~p
I
box
/\ Ophcolly=soloted parallelhnk M=croproorornrnable controller
Telescope control room
RS422 parallellink
I ~
LSI- II
~
Standard peripherals
TV d=splay Figure 5. Layout of cooled solid-state detector system
vo/ 7 no 5/une 1983
The driver operates under the conventional computer DMA mode. CAMAC commands are compiled into 'frames' in the computer, consisting of from two to four computer words, depending upon the type of command. A command is executed by sending the address of the frame to the driver, which then picks up the contents of the frame, using DMA access, and executes the command. Where appropriate, data is transferred to or from memory, also under DMA. Commands may be single, with or without data, or in the form of block transfers. The serial highway driver was implemented using a pair of Am 2909 sequencers and four Am 2901 chips to form a 16 bit ALU, along with a 48 bit wide microprogram in PROM. The main function of the driver is to collect commands and to any write data from the computer memory under DMA, to divide the command up into bytes and transmit those bytes, to assemble the resulting reply and to put any read data back into the computer memory under DMA. Microprogramming was carried out on a somewhat laborious bit-by-bit basis, with coding chosen to minimize the number of bits programmed in the PROMs, according to the most frequently used field codes. This meant that most bugs could be fixed by blowing one or more bits in the PROM. For convenience, EPROM was used to develop the program using a slower clock rate, before converting to bipolar PROM.
Solid-state camera controllers Two controller designs have been implemented for the solid-state detector program, one for the CID, and the other for CCDs. Several copies of the latter are planned. The CID controller is somewhat different, in that the chip must be run in the nondestructive multiple readout mode to reduce the effect of noise in the output amplifier. The controllers use an Am 2910 12 bit wide controller with three Am 2901s, forming a 12 bit ALU used for 'do loop' counting and subroutine nesting. A writeable control store is used for the microword; in the CCD case this may be extended by adding cards to the system, 16 bits at a time. Standard microword width for the ~CD controller is 80 bits. The microword contains individual bits for driving individual detector chip control lines, so that arbitrary sequences of clock signals may be implemented, making it a simple matter to experiment with different waveforms to drive the chip in order to obtain optimum performance. An important feature of the development cycle has been the use of microcode FORTH. As mentioned above, it is possible to change the meaning of familiar FORTH words by switching context to a different vocabulary. A microcode vocabulary is used to change the meaning of 'colon' definitions, so that they become microcode subroutines, while logical structures are interpreted in the form of conditional jumps. Thus the user may write microcode in a way that looks essentially identical to other FORTH; the source blocks may be edited in the normal way using the standard FORTH editor. However, when these blocks are compiled in the context of the microcode vocabulary, they form an image of the microcode on disc which may be downloaded to the microcontroller writeable control store. There are two significant differences from programming in conventional FORTH. • The user must be aware of pipelining in the bit-slice processor, since, although its effect is not visible in the
209
•
program text, such details as setting up the condition code for a logical jump must be done in the microcycle previous to the jump. The end of each mlcrocycle must be delineated by a special symbol, as several activities can take pla6e in one cycle, e.g. more than one clock driver line might be changed at the same time.
Use of this compiler has greatly simplified the development of the microcode and allowed more experimental modes to be evaluated than could otherwise easily have been tried.
FUTURE DEVELOPMENTS There are numerous hardware and software developments that are hkely to have a considerable effect on the use of microprocessors in astronomy A few topics where requirements already exist are given below.
Memories While the RAM memory requirement for programs has remained relatively unchanged, the size of digital images in regular use has been expanding rapidly. Currently, 512 x 512 pixels will cover most applications, but there are plans to build CCD detectors an order of magmtude larger in area. If these images are to be processed efficiently, with minimal disc transfers, then significant fractions of each image must be able to be held in RAM at any one time. Developments m large RAMs, array processing, high-capacity but physically small Winchester discs and 32 bit microprocessors will have important effects m this area. Ultimately, it may be expected that astronomers will have personal microcomputers on their desks that are capable of handling large images, so greatly improving the efficiency with which observational research can be undertaken.
Serial interfaces Whde parallel access is reqmred to fast dev=ces such as memory, many external devices are slow and can adequately be served by a low-speed serial interface. Within a large instrument such as a spectrograph, ~t would be an advantage to control electromechanical devices with a simple lowpower interface chip mounted on each mechanism and connected to the control processor by a twisted pair. In this area, the Hewlett Packard HP-IL, combining low power with simple wiring may prove very useful
I nstruction sets The majority of instruction sets on microprocessors are not related to any high-level language, and are therefore much less efficient when used for this purpose. However, the Pascal Micro Engine from Western Digital has been designed with PASCAL in mind, and coprocessors have been produced for other microprocessors to support serial instruction sets; various prototype FORTH computers have also been built. Clearly, a great improvement in processing power would accrue if a microprocessor were to be produced with a FORTH-oriented instruction set.
Voice input/output It is apparent that voice input and output will be used increasingly in the future, principally for operation, but also for programming. Because of FORTH's dictionary structure, it is especially well adapted to accepting voice input. When associated with software that assists the user.
210
voice I/O should greatly slmpldy the task th~ user la~.', when confronted with a new instrument at the telescope. it should also help wtth diagnostics, partlculally b~, s[al~ who are unfamdlal wrth lhc u~e of computcr~
Diagnostics and black boxes Where a microprocessor b incorporated rote a dused or 'black box' devtce, attention must be pard to the types oi dtagnostic facilities needed Diagnostics might range trom simple control of electromechanical mechanisms, for the mechamcal engineer concerned wzth optical alignment, to sophisttcated diagnostics for the electromcs engineer investigating a subtle system ploblem. The iormer are easy to anticipate but need to be well defined, use el the controls should not reqmre much training. The latter ate difhcult to anticipate, but a htghly trained person wd] be using them The balance between spending time on designing good d~agnostJcs and spending time finding faults with poor diagnostics depends very much on individual circumstances. Astronomical instruments tend to be one-oifs, and so time spent in prowding dJagnostscs Js unhkcly to be well repaid in time saved on fault finding itsell However, when the cost of telescope downtime Is considered, good diagnostics are essentzal. Recently, the authors have developed a FORTH system to run in read-only memory which will form the basis for futureM6800apphcationsofth~stype I t l s w n t t e n msuch a way that the black-box apphcatlon runs effher as a background task, or can be aborted, allowing a VDU to be plugged in to access the FORTH system. This makes a large vocabulary available for diagnostics, comprising the mdwldual definmons that make up the applicanon Inth~sway, very Ifftle extra effort is needed to prowde very powerful diagnostics which can be tadored to the user's reqmrements, making a separate engineer's controller unnecessary
Networks and distributed intelligence Astronomical instrumentation has followed the recent tend to distributed intelligence, with neatly all instruments on telescopes now contaimng thetr own control mtcroprocessors. This has paralleled the trend towards structured programming m software. A particularly exerting development has been that of local area networks, which allow intelligent devfces to commumcate with each other An interestmg future use of networking is Jn telescope drive systems. Conventional optical telescopes use an equatorial mounting that contains an reclined polar axis that is parallel to the rotation axis of the Earth. To track a star, the telescope ~s rotated about this axts at a uniform rate, in the sense that ncutrahzes the rotatton of the Earth. Only minor corrections are then necessary to track the star accurately. Unfortunately, because the axis Is inchned, mechamcal engineering problems arise that become sevcre for large telescopes. Mechamcally a far simpler solution ts to use verttcal and horizontal axes in the form of an 'alt-az' (altitude and azimuth) mounting. Both axes must then be driven actively, and at varying rates. An elegant way of achieving this is to use a microprocessor to drive each axis, each processor being responstble for calculating the movement of its axis, as a function of time, m order to track a particular star. These may be connected via a network to other processors, such as guidance sensors, to form a complete control system. In such a configuration, processors could 'talk FORTH'
m~croprocessors and mtcrosystems
to each other when transferring information or commands. An instrumentation computer, VDU, engineer's controller or voice input terminal could then be connected to the network, either to control the whole system, or to debug the exercise individual processors. There will almost certainly be local area networks at the new observatory on La Palma, both for instrumentation and some aspects of control. Similar networks are being implemented or planned at RGO, and it is possible that, m the future, a satellite link between these networks might be used to permit remote observing and diagnostics. Thus, individual expertise at RGO could be applied to problem solving without the individual having to travel to La Palma, greatly increasing the effective use of resources. CONCLUSIONS During the last few years, microprocessors have found increasing use at the Royal Greenwich Observatory, where they have been incorporated into a variety of different devices at a variety of different levels. Throughout, we have attempted to establish standard approaches, where appropriate, both to unify concepts and to optimize the use of equipment and manpower. As a consequence, a sound foundation has been laid which, It is hoped, will support many exciting new developments in the near future.
2
mittee of European Laboratories, Eur6500 (1978) 3
REFERENCES 1
Parker,N M 'A simple but fast microprocessor controller for CAMAC' Proc. ESO/SRC Conf. Applications of CAMAC to Astronomy Geneva, Switzerland (1978) p118
vol 7 no 5 lune 1983
Cittolin, S and Taylor, B G 'CAVIAR - interactive microcomputer control and monitoring of multicrate CAMAC systems' IERE Conf. Proc. (No 41) microprocessors in automation and communications
University of Kent at Canterbury, 19-22 September 1978, p 3O9 4
Moore, C H 'FORTH: a new way to program a minicomputer' Astron. Astrophys. Suppl. Vol 15 (1974) p 497
S
James, J S 'What is FORTH? a tutorial introduction' Byte Vol 5 No 8 (August 1980)
6
Taylor, K and Atherton, P D 'Seeing-limited radial velocity field mapping of extended emission line sources using a new imaging Fabry-Perot system' Mon. Not. R. Astr. Soc. Vol 191 (1980) p 675
7
Atherton, P D, Taylor, K, Pike, C D, Harmer, C F W,
Parker, N M and Hook, R 'Taurus: a wide-field imaging Fabry-Perot spectrometer for astronomy' Mon. Not. R. Astr. Soc. (1982)
8
Jorden, A R, Read, P D, and van Breda, I G 'Photoncounting reticon system description and performance' Proc. SPIE Conf. instrumentation in astronomy IV USA (1982)
9
Jorden, P R and van Breda, I G 'The RGO charge injection device camera system' Proc. SPIE Conf. sohd-state imagers for astronomy Vol 290 (1981) p113
ACKNOWLEDGEMENTS Many people at RGO have contributed to the projects discussed here. In addition to those mentioned in the references, David Thorne has been largely responsible for the autoguider, Normal Walker has been in overall charge of the four-star photometer and Martin Fisher and Tony Seabrook have done much work on the hardware.
Multiple controllers in a CAMAC crate ESONE Com-
10 Jorden, P R, Thorne, D J and van Breda, I G 'The Royal Greenwich Observatory charge-coupled device camera' Proc. SPIE Conf. Instrumentation in astronomy IV USA (1982) 11 van Breda, I G 'A CAMAC serial highway driver' Proc, ESO/SRC conference on appflcations of CA MAC to astronomy (1978) p 132
211