MONET – Monash University’s Campus LAN in the 1980s – A Bridge to Better Networking

Abstract

Monash University, Australia developed an in-house local area network called MONET during the 1980s to meet the needs of the university’s computer users. The Monash University Computer Centre team created and installed an economical computer access network across an extensive campus with distributed computer installations and a large numbers of users. MONET was an early implementation of a Local Area Network (LAN) at a time when LAN concepts were evolving and specific hardware and software for the purpose did not yet exist. MONET became a successful large scale system that was in development and then operation to support all the University’s computer services for over a decade. It was also commercialized and used by various other organizations.

1 Introduction

The growing demands of student and staff access to computer facilities in the 1960s and 1970s stimulated the development of a terminal access Local Area Network (LAN) at Monash University, Melbourne, Australia. It came to be known as MONET for Monash University Local Area Network. The LAN was developed in-house by the staff at the Monash University Computer Centre. The project was started in 1979 and a prototype system was in place from 1981. The network continued to be used at Monash University across several campus sites until it was superseded by an Ethernet network from mid-1991.

During the 1970s, early computer networks consisted of individual computers connected by point-to-point telecommunication links. The computers ran their own proprietary operating systems, then later UNIX, and the network protocols evolved into systems such as X.25 and TCP/IP, for example ARPANET. User access terminals were limited to being directly attached to their local mainframe computer.

With the proliferation of multiple, smaller mid-range computers onsite, this stimulated a need for the user terminals to switch between the different computer systems. Hence the emergence of centralized terminal exchanges similar to PABX systems. The geographical distribution of these computers over a campus environment created the further need for the switching system to be also distributed physically over the site. MONET was Monash University’s response to this requirement.

The MONET system was developed at a time when the Ethernet LAN concept existed but no Ethernet product had yet appeared. While contemporary networks at the time provided computer-to-computer connectivity, MONET aimed instead to provide a network to interconnect basic Visual Display Unit (VDU) terminals and host computers distributed across the university campus. The original installation at Monash’s Clayton Campus covered an area of just over 1 km².

2 Early Computer Networks in Australia

Australian digital computing started in 1949 with the successful testing of a locally designed computer which is now called CSIRAC. It was produced by the government research group CSIRO – the Commonwealth Scientific and Industrial Research Organisation.¹ During the 1950s and 1960s, a growing number of systems were purchased from English and American manufacturers by university and government facilities as well as some commercial sites. They were stand-alone installations directly accessed by local computer staff using punch cards or paper tape.

The first forms of “networking” or communication between computers appeared in the 1960s with the physical movement of magnetic tapes or packs of punch-cards between locations. This was later replaced by electronic communication over telephones lines. For example, the CSIRO established a system of CDC computers around their offices in Australia in 1963 which initially communicated data by exchanging tapes. This was the first stage of a network called CSIRONET.² The University of Sydney linked their computers, a first generation installation called SILLIAC and a newer KDF9 computer, in 1966.³ In 1970 the government authority, the Postmaster-General’s Department (later split to form the Australian Post Office and Telecom Australia) commissioned UNIVAC to build a packet-switching network called the Common User Data Network or CUDN. It was installed initially in their Haymarket Exchange in Sydney in 1970 and then in the Lonsdale Exchange, Melbourne in 1972.⁴

In the 1970s access to computer facilities moved away from cards or tape to the use of teleprinter and then later VDU terminals. These terminals could be used to enter and receive data but needed to be connected to a computer to process the data. They had limited memory. Smaller, relatively cheaper computers, including ‘minicomputers’ such as DEC PDP models also became available from the 1970s into the 1980s. The move to using terminal access rather than cards, coinciding with the expansion of computer centres to include multiple computers as well as minicomputers and printers away from the centre, prompted a need to communicate between large numbers of different units within a local group. While universities were developing their own resources, government bodies such as the Telecom Research Laboratories and other research groups were also developing networks. Telecom Australia created a network, called TACONET or Telecom Australia Computer Network by 1976 which connected a set of Honeywell mainframes at their facility in Clayton.⁵ The Australian Atomic Energy Commission, located at Lucas Heights, New South Wales, produced its own network, known as AAEC DATAWAY Network, using their IBM/360-65 with a PDP-9L, and with capacity for 128 addresses, in the late 1970s.⁶

3 The Development of Computing at Monash University

Monash University was established from 1958 with a campus at Clayton Victoria Australia and has since expanded to include several other campus sites both locally and internationally. Computing at Monash University started in 1962 with the installation of a Ferranti Sirius computer at the Computer Centre, Clayton campus. Professor Cliff Bellamy was appointed the Director of the Computer Centre in 1964. He had a diverse role supervising staff involved in various activities including hardware and software development, and maintenance of their operational computer services. Some of the staff also had academic commitments.

The first computer in the Centre soon proved to be too small for university requirements and the Centre’s facilities were updated regularly over the next years with a CDC3200 in 1964 and a series of Burroughs mainframes from the 1970s as well as several Digital Equipment Corporation (DEC) VAX 11/780s and a smaller number of VAX 11/750s from the late 1970s. The move from a single mainframe computer to several computers created a need for the terminals to be switched between the different systems with minimal human interaction. At this point, the University recognised that it needed a network system to connect the distributed installations and allow each terminal, physically spread around the campus, to connect to any of the computers. There was no suitable commercial solution available so the Computer Centre formed a project team to develop one.

4 MONET

The staff of Monash Computer Centre started work on a local area network, which came to be known as MONET, in 1979. The team developed the project in-house. They were aware of early pioneering local area networks developed at other universities such as the ALOHAnet at the University of Hawaii and the Cambridge Ring at Cambridge University Computer Laboratory.⁷ They were also aware of the concepts underpinning emerging local area and packet switched network technologies such as Ethernet (which grew out of ALOHAnet) and X.25. These were under active development in parallel with MONET but, at the time, had not yet been ratified as formal standards, nor were commercial products or services based on these ideas yet available.

The Monash team set out to create a cost-effective terminal access network using 8-bit microprocessors suitable for the large, widely-spread campus of Monash University.⁸ A precursor project to develop a terminal concentrator to connect to their Burroughs mainframe had been undertaken in 1978. This was built using a Motorola 6800 microprocessor development kit and communicated with the mainframe using the Burroughs Poll/Select Protocol. This set the scene for the subsequent more ambitious MONET project, as they now had familiarity and expertise with developing serial data communications systems using the then available early microprocessor hardware and their primitive assembler language programming. A memo written in April 1979 by Keith Heale discusses the practical aspects of starting the project and the need for money from the Centre’s budget to build some working prototypes.⁹ By late 1979 a team had been established and included Dr Cliff Bellamy, Neil Clarke, Keith Heale, Patrick Miller and Barry Treloar. Later contributors to implementing the network software and hardware included Stephen Dart, Peter Gordon, Russell Keil, Neil Houghton, John Mann, Keith Lewis, Carlo Kopp and a number of Computer Centre engineering staff.

With their geographical and economic constraints in mind, initially the team identified the following goals. Firstly to provide VDU terminal access to multiple computers and also computer to computer connectivity in a distributed multi-computer environment. The large distances on Clayton campus imposed a number of engineering constraints, and they also wanted to incorporate off-campus modem connections via existing Telecom telephone services. The network should have high reliability, and tolerate effects from electrical storms over a wide area and problems with electrical supply faults over different buildings. Reliability objectives included minimising the effect of a failure of a single piece of equipment on the network as a whole. Ultimately, the team wanted to achieve an efficient network over a large campus with a low connection cost per port.

The team’s solution was to create a network using a common communication ‘bus’ to connect ‘nodes’ distributed over the campus. All nodes could communicate with every other node. This required a method to control the use of the common bus by competing nodes. The team selected the Carrier-Sense Multiple-Access with Collision-Detection (CSMA/CD) system. The team worked through 1979 to 1981 to develop a bus network using two twisted wire pairs communicating between nodes, which were ultimately duplicated for reliability and capacity and extended via repeaters to achieve campus-wide reach. Each node comprised two (and ultimately more) microprocessors communicating via a dual-port shared memory (Fig. 2). The nodes were coupled to the bus cables by ferrite toroidal transformers, so as to provide high voltage electrical isolation. The nodes transmitted onto the bus using a novel ONEs line and ZEROs line encoding method, for easy recovery of data, bit-rate clock and collision-detection while providing for unambiguous jam signalling. These signals were further encoded using conventional 3-level AMI (Alternate Mark Inversion) encoding to eliminate low-frequency and DC components prior to transmission to line.

Software development for the MONET system had the following aims.

• Essential that all devices be addressed by name;

• Security mechanism to define multiple user access classes via a novel ‘digital locks and keys’ mechanism;

• A means of controlling the allocation of resources among competing groups of users;

• No down-line-loading of code or control tables to initialise the network after restoration of power after a failure.

The MONET Terminal Processor software was developed by Patrick Miller, including a novel access control system using digital ‘locks and keys’ to provide for multiple access classes. This comprised a bit-pattern in the ‘lock’ assigned to each host port and each user port had an access ‘key’ which had to match the pattern before they could use the network to connect to the desired host computer. This allowed both host and user ports to be grouped in access classes.

The team also saw the need for a central management tool. This was developed by Stephen Dart in Pascal and was named the NETMAN program. This provided overall monitoring and management of the network, as well as a more streamlined method of administering the access classes and digital ‘locks and keys’. The need for better control of access and management of the network became more important as the network grew and number of users increased.

5 Theoretical Underpinnings – State of Knowledge and Technology at the Time

5.1 The Need (‘Business Driver’)

The move in that era from a single centralized ‘mainframe’ computer to a multiplicity of physically smaller mid-sized multi-user computer systems created the need for a terminal exchange (analogous to an in-house telephone exchange or PABX, but for computer terminals rather than telephones) so that any terminal could connect to any computer at will.

The need for not only the terminals but also the computers to be physically distributed across a large university campus added the requirement that the terminal exchange also be physically distributed, so that any terminal anywhere could connect to any computer anywhere else, rather than just to computers centralized within a single main ‘Computer Room’ (or more recently ‘Data Centre’).

Hence the need for a distributed terminal access network was born.

5.2 The Gap

While some terminal exchanges were starting to appear (from suppliers such as Gandalf and Micom) these were centralized devices (‘star’ topology), analogous to a monolithic PABX, and hence were only suitable for connecting to computers co-located within a centralized data centre.

Furthermore the popular serial data communications interface at the time was EIA RS-232, which was intended only for very short distances, had no high voltage isolation, and certainly could not cover the range of a large university campus. Some form of line driver (‘media converter’) would be required on each RS-232 line to remotely located terminals and computers. There was no commercially available distributed terminal access network to meet the university’s requirements.

5.3 The Knowledge Base

At that time the seminal local area network (LAN) academic papers covering ALOHAnet, token ring, CSMA, Ethernet and related techniques had been published, but no Ethernet integrated circuits (ICs or ‘chips’) or products yet existed. When Ethernet products did subsequently appear, these were for computer to computer communication, not terminal to computer, and initial implementations were via a very unwieldy coaxial cable (‘thick coax’) in practice suitable only for interconnecting computers within a central data centre. Indeed, Ethernet solutions for basic VDU terminals never did appear, with the PC era (and Ethernet) completely superseding and replacing VDU terminals (along with their serial RS-232 connections).

From the early research base, it was known that reliable collision-detection was important to maximize the throughput of an Ethernet-style LAN, and protect it from congestive collapse. Important features of CSMA/CD, and implemented by MONET, comprise:

• packetized data frames transmitted over a single shared bidirectional cable;

• Carrier Sense: do not start transmitting a packet while another transmitter is already active;

• Collision Detection, to minimize time wasted sending damaged data packets;

• a ‘Jam’ phase following a collision, to ensure that all contending transmitters ‘see’ the collision and initiate the backoff action; then

• Abort: all senders prematurely terminate current transmission; followed by

• Backoff: each transmitter waits a random delay before attempting to re-transmit, without which the contending transmitters are likely to re-collide if they all start resending simultaneously; and

• an error-protecting acknowledgement and retransmission protocol to protect against lost and damaged data packets – MONET used a standard 16 bit CRC error detection method.

It was also known from contemporaneous solutions, such as CCITT G.703 at the 2.048 Mbit/s rate (as used widely in the then digitization of the telephone network), that digital transmission on twisted-pair cables could be successful over campus distances, providing the cable was treated as a match-terminated transmission line.

It was also well known that inter-building cabling would need high-voltage isolation to protect the sensitive electronics from impacts of lightning strikes and other mains power disturbances, and that balanced differential transmission techniques would be required to minimize electrical noise and interference affecting the twisted-pair wiring.

5.4 The Predecessor Project – Terminal Concentrator

A predecessor project to implement a terminal concentrator, built around a Motorola 6800 microprocessor development kit, gave the Monash Computer Centre team the necessary experience and familiarity with the hardware set and developed knowledge base and intellectual property around writing assembly language serial data communications and multiplexing technology, in that case using the Burroughs Poll/Select line protocol.

This in turn provided them the necessary springboard and confidence to embark on the much more ambitious MONET project

6 The Components of the MONET Solution

While in the very earliest stages of the MONET development, the Motorola 6800 card set and backplane were re-used from the predecessor concentrator project; one by one these were all replaced as the more demanding MONET application outgrew their capabilities. The replacement cards were all fully developed in-house by the MONET team.

The basic idea was to re-purpose the existing concentrator as the terminal interface (this became the Terminal Processor (TP) sub-system shown on the left side of Figs. 2 and 7), while replacing the Poll/Select multiplexed line with a wholly new interface to a CSMA/CD bus (this became the Bus Processor (BP) sub-system shown of the right side of Figs. 2 and 7).

Due to the limited clock speeds of microprocessors of that era, these could comfortably implement serial data communications applications (under software program execution of byte-by-byte i/o) only at low data rates. For example concentrating several 2400 bit/s terminals into a 48 kbit/s multiplexed line might be a typical limit of the era. The Motorola 6809 microprocessors used in the MONET system operated at a 2 MHz clock rate (i.e. 0.5 µs cycle time), with each instruction in turn consuming several such cycles to execute.¹⁰ Thus the microprocessor was only capable of executing several hundred thousand primitive opcode machine instructions per second. Therefore, the higher data rates envisaged for the MONET bus (which was to carry the entire university’s traffic on the one cable) would require special hardware design approaches throughout.

Similarly, to maximise performance, software needed to be written from scratch by the University team in the microprocessor’s native assembler language. Subsequently common software suites for UNIX or TCP/IP were both unavailable for the microprocessors at hand and, had they been, would have been unfeasibly slow for the application.

6.1 Dual Port Memory (DPM) Architecture

The Terminal Processor (TP) would be kept busy transferring characters byte-by-byte (under software program control) to and from as many terminal ports as would physically fit within the chassis. To insulate the TP from the ‘high-speed’ bus activity, so that the TP could focus on moving as many characters as possible, a dual port memory architecture was introduced. The backplane was physically split between the TP side and the BP side (Fig. 2). The only means of communication between the TP and the BP was via the DPM. Each processor would operate autonomously and communicate with the other via messages and data packets they placed in (and fetched from) the DPM. Thus from the TP’s perspective, transmission on the bus was ‘automatic’ – the TP software would simply place the data packet in the DPM and off it would go. Similarly data from the bus simply appeared in the DPM ‘as if by magic’ i.e. without the TP doing anything.

The two DPM cards that form the DPM assembly, and straddle between the TP and BP ‘sides’, can be seen towards the middle of Fig. 2, and the flat cables interconnecting the two DPM cards can just be made out near the middle of Fig. 7.

Random Access Memory (RAM) read/write times had by then (1980) become sufficiently fast (200–400 ns), compared with the 1 µs cycle time of the CPUs. Thus the DPM could effectively interleave accesses from both the TP and BP sides without delaying either CPU (by cycle stretching) by any appreciable amount. Each RAM chip had a capacity of only 4 K bits[sic], thus when fully loaded with chips a pair of DPM cards had an ultimate capacity of 2 cards × 3 rows × 4 K bytes = 24 K bytes. Theoretically, two pairs of DPM cards could be installed in the one chassis, doubling the DPM capacity to 48 K bytes, but this capability was not generally utilized in practice.

6.2 Synchronous Data Link Control (SDLC) Card

While no Ethernet chips yet existed, what did exist was a Western Digital SDLC/HDLC integrated circuit. This implemented in hardware a number of functions that could be offloaded from the BP software, in particular packet framing (header and footer and the necessary associated automatic zero insertion and removal technique) and Cyclic Redundancy Code (CRC) error-check computation. In combination with a Direct Memory Access (DMA) controller chip (eventually housed on the BP’s MPU card), this meant that the ‘high-speed’ bus i/o was fully implemented in hardware. The BP software only needed to set up each communication transaction, and the SDLC/DMA hardware directly handled all the datacomm transfer between the DPM and the bus – the BP was completely relieved of any character forwarding workload.

The 1.5 Mbit/s rate of the MONET bus was simply selected due to that being the maximum data rate of the available family of SDLC chips, nothing more nor less scientific than that. Thus, all other components of the MONET system had to be designed to accommodate that rate.

Although there was only one SDLC chip on the MONET SDLC card, the card was actually fitted with two bus interfaces, for reliability – in case either one bus cable had a breakage, and to allow live maintenance on the cable network without affecting user services.

6.3 Bus Interface Module (BIM) Card

The Bus Interface Module (BIM) card implemented the novel MONET ‘ONEs’ and ‘ZEROs’ line coding method. Serial data bits for sending on the bus were separated such that data 1 s were transmitted on one line (the ‘ONEs’ twisted pair) while data 0 s were transmitted on a separate line (the ‘ZEROs’ twisted pair). Each line was then separately and further encoded using a conventional AMI (Alternate Mark Inversion) 3-state (+1, 0, –1) encoding scheme so as to eliminate low-frequency and DC components and thus allow transformer coupling onto the bus cable, to achieve the high-voltage isolation requirement. The two ferrite toroidal transformers, which featured hand-wound bifilar windings to achieve the required bandwidth and isolation, can be clearly seen on the BIM card in Fig. 1d and below in Fig. 3 (one transformer for each of the ONEs line and the ZEROs line).

Fig. 1.

Examples from private collection N. Clarke.

Key MONET cards – From left to right: 1a. DPM card (one half of a Dual Port Memory assembly); 1b. MPU (Micro Processor Unit) card; 1c. SDLC (Synchronous Data Link Control) card; 1d.BIM (Bus Interface Module) card

Fig. 2.

Diagram by N. Clarke.

MONET node – chassis, backplane and cards layout. Typical configuration – configured with 32 ports of RS-232 with modem controls as required for session control of host computer ports and modems. Legend: NAB = Node Adaptor Backplane; OSI = Octal Serial Interface card; CLK = master backplane CLOCK generator

Fig. 3.

Line isolation transformers. Detail from Fig. 1 d showing hand-wound toroidal line isolation transformers and associated components

This encoding scheme was logically very simple to implement, while delivering the lowest line-rate (1 baud per bit) self-clocking line-code, from which received data, bit-rate clock and collision-detection could all be easily decoded, while the Jam condition could equally easily be indicated by transmitting on both the ONEs and ZEROs line simultaneously (i.e. as an illegal coding violation), viz (Figs. 4 and 5):

Fig. 4.

MONET’s ‘ONEs and ZEROs’ line code and Collision Detection logic

Fig. 5.

Illustration of MONET’s ‘ONEs and ZEROs’ line code and Collision Detection logic

A self-clocking line-code was required as each data packet was sent independently from different transmitters, without the possibility of a network-wide master clock. Rapid clock acquisition was required to keep frame header introducer to minimum length. Simple logic was required due to the low density of general purpose logic chips then available. Minimum baud rate was required to maximize distance between repeaters.

Even so, the size of the Monash Clayton campus was such that bus repeaters (active regenerators) were required. This was implemented as a pair of stand-alone BIM cards connected back-to-back. As each bus comprised two bus cables, for reliability, this meant that a complete repeater comprised a total of four stand-alone BIM cards connected back-to-back in pairs.

The BIM card derived only power from the NAB backplane, obtaining all data and control from flat-cable connection direct to the SDLC card (as per Fig. 2).

6.4 Node Adaptor Backplane (NAB) – Synchronous Backplane Bus

The MONET Node Adaptor Backplane (NAB) was originally based on the S100 backplane of the Motorola Microsystems card-set¹¹ inherited from the predecessor project. A number of important changes were made, in addition to splitting the backplane between the TP and BP sides.

Crucially, to accurately orchestrate the many devices that would contend to access the backplane and DPM, Clarke replaced the asynchronous analog (monostable multivibrator) timers used on the Motorola cards by a master synchronous clock broadcast across both sides of the NAB. Along with DC power, this clock was the only signal common across both the TP and BP sides of the NAB (refer Fig. 2).

The contending devices that needed to be synchronized were:

• the two master devices on the BP side: the BP CPU and the SDLC/DMA sub-system

• a multiprocessor architecture on the TP side: ultimately multiple TPs and the MPI (see later section below)

• synchronized access to the DPM

• as well as the various responding devices like the OSI serial line cards

Consequently, henceforth all the MONET developed cards were driven from this master clock.

An 8 MHz (quartz crystal oscillator) clock was chosen, so as to subdivide the backplane’s nominally 1 µs cycle time into around eight 125 ns ‘phases’. This choice allowed more than enough time within each phase for the clock to propagate throughout all boards and for the LS-TTL logic to well and truly settle; while also providing sufficient granularity to stretch a CPU cycle by small increments, as required by memory or backplane contention. While internal CPU cycles ran at the full 2 MHz rate of the CPU, consuming only four 125 ns clock ‘phases’, external backplane and memory accesses ran to a longer more complex sequence. For example, an unfettered OSI or DPM read or write might require 2 or 3 phases, but could be stretched in additional 125 ns increments if the DPM or backplane was already servicing another processor.

Thus the variable number of phases allowed for the following periods within the CPU’s backplane access cycle:

• CPU address bus and data bus settling time

• address decode/decision time

• backplane contention (with potential cycle stretching as required)

• memory/device read/write time, including

  • DPM contention (with potential cycle stretching as required)

6.5 Micro Processor Unit (MPU) Card

In completely rebuilding the CPU card to meet the needs of the MONET project, the following major changes were adopted. The same MPU board was to be used as both the BP and the TP.

• Upgrade the original 6800 processor chip with the then available Motorola 6809 CPU.

• Add the DMA controller – as required by the BP side.

• Add the synchronous clock cycle sequencing (as above).

• Add a multiprocessor capability (for the TP side) comprising a backplane contention and daisy chain prioritization scheme – this allowed for multiple TPs to be fitted over time, to cope with increasing loads as port density (e.g. to 48+ ports) and data rates increased (e.g. from typically 2400 bit/s originally to 9600 bit/s or more) over the life of MONET in the field, while ultimately also supporting the addition of the MPI Unibus connection later in the project (see below).

6.6 Octal Serial Interface (OSI) Card and Adaptors

To increase the MONET node’s terminal port density, an 8 port serial interface card was developed (the OSI card). It could be fitted with a range of serial adaptors including:

• RS-232 with full modem controls, which consumed an adjacent NAB slot (refer Fig. 2). This was required for session control signalling for modems and for VAX serial host computer ports.

• RS-232 data-only (for user terminals), this was a daughter board fitted directly to the OSI without wasting a 2^nd NAB slot, so as to allow additional OSI cards and/or additional slave TPs to support the additional port load.

• 20 mA current loop, which had greater distance reach than RS-232.

6.7 Logic Implementation – PROM Logic and Finite State Machines

General purpose logic density was quite limited in that era, e.g. four 2-input NAND gates or two flip-flops or a shift register per 14 to 20 pin chip. This consumed a significant amount of circuit board real estate for even quite simple logic requirements.

An alternative then available was ‘high-speed’ Programmable Read-Only-Memory (PROM) which delivered settling times (of the order of 20 ns), similar to that achievable using collections of LS-TTL gates, roughly an order of magnitude faster than normal RAM and ROM memory available at the time.

PROMs could therefore be used as a general purpose logic substitute, for both arbitrary combinatorial logic and, with the addition of a parallel-in-parallel-out shift-register could also be used to implement simple finite-state-machines, as required by various MONET hardware sequencers (described above and below).

A simple Pascal-like programming language and compiler was developed in-house by Clarke to streamline the generation of PROM object files (bit patterns to reflect the desired logic). This comprised:

• a declaration section to define names for: input variables, output variables, state variables, state names and state code values (the state variables were also available, if sensibly chosen, to also be used directly as additional output variables)

• a combinatorial logic section for immediately executed logic, of the form:

  $$ {\texttt{OutputVar}}\,\,{\texttt{:=}}\,\,{\texttt{logical\,\,function\,\,of\,\,Input\,\,and\,\,State\,\,Variables}} $$

• an ‘executable’ section to define the operation of finite state machines, of the form:

  $$ {\texttt{when\,\,CurrentState\,\,if}} \,\,{\texttt{<}}{\texttt{logical\,\,expression}}{\texttt{>}}\,\,{\texttt{then\,\,NextState}} $$

This made the generation of PROM data so easy that several PROM-based logic elements appeared on all key MONET boards, for both combinatorial (logic) and sequential (state machine) implementation, making various design tasks feasible within the limited board area, due to the higher logic density of PROM as compared with general purpose gate chips.

Use of PROM was chosen over FPLA/FPGA, seeing as PROM can guarantee implementation of any arbitrary logical combinations of any complexity, without needing to constrain the logical design by limitations within a specific FPLA/FPGA chip, thus in turn simplifying and generalizing the PROM’s compiler language (which therefore did not need to take into consideration architectural constraints within FPLA/FPGA chips).

7 End-User Interface – MONET Session Control

A simple command line interpreter was provided to allow the end-user to nominate which computer to connect to, or to disconnect. Each command was prefixed with an escape character (Control-P or DLE character) to differentiate the command from normal text. <Control-P> (the ASCII Data Link Escape character) was chosen as it had no other usage in communicating with any of the computer systems that MONET was targeted to (Burroughs, VAX, UNIX, etc.). End-user commands comprised:

• <Control-P>C <computer name>

  to Connect to a port on the nominated computer

• <Control-P>D to Disconnect a session

• <Control-P>S to determine current connection Status

Developers and support staff had access to additional commands after providing a password.

There were also inactivity timeouts to force disconnect of valuable computer ports where the user may have forgotten to do so, as well as signalling between MONET and host computers (e.g. via RS-232 modem control signals) to force disconnect following logout or to force logout following disconnect where the user may have forgotten to logout before disconnecting.

In response to a connection request command, the MONET system would either respond to the user with a connection successful status message including host computer’s name and port number, or an access denied message if the ‘locks-and-keys’ access controls had prevented that user port from connecting to that host. This allowed, for example, staff terminals in secure admin offices to access sensitive student records, HR and finance systems, while preventing student terminals in public areas from doing so.

8 Subsequent Embellishments

Once the basic MONET kit (above) was in extensive use, a number of enhancements were made:

• X.25 multiplexed interface (SSP card) – required for commercial customers

• extension of the Monash installation to other campuses – due to Dawkins era amalgamation with Chisholm Institute – MONET nodes at each site were interconnected by multiplexed serial link via 64 kbit/s permanent call over the University’s digital PABX network

• DEC Unibus interface

8.1 MONET Unibus Interface

By far the most ambitious component of the MONET project was development of a direct interconnect between the DEC Unibus and the MONET node, as this required not only additional hardware and software development on the MONET side, it also for the first time for the project, also required significant hardware and software development within the VAX host computer itself.

The DEC computers (VAX and PDP) did not have a multiplexed interface like the Burroughs Poll/Select line. Instead each individual terminal port was presented as a separate RS-232 port (several RS-232 ports per Unibus card). This required many discrete serial lines between MONET ports (as per Fig. 2) and VAX ports. Full modem-style interfaces were required for session control signalling.

Not only was this inefficient in terms of hardware real-estate at both the MONET and VAX Unibus ends, and much cabling in between, it was also a drain on CPU time within both the MONET TP and the DEC VAX, due to character by character processing at both ends of each serial line.

To address this, a project to develop a direct interface was embarked upon. To eliminate the character by character CPU overheads, more DMA was called for. The team was by now so comfortable with multiprocessor DMA techniques that this was a natural progression. This required the design of two wholly new hardware modules: a Unibus card, called the Unibus Communications Processor (UCP) and a MONET card, called the Monet Parallel Interface (MPI). The MPI card extended the 8-bit NAB bus via flat cables to the UCP card installed within the VAX (refer Fig. 6).

Fig. 6.

MONET interface to DEC Unibus – From left to right: UCP (Unibus Communications Processor) card; MPI (Monet Parallel Interface) card. This assembly replaced a multiplicity of serial lines between a VAX and a co-located MONET node.

Fig. 7.

Photographer: Tony Miller, Monash University Archives, MONPIX Image Number 1553

Computer Centre director Dr. Cliff Bellamy explaining MONET in the Monash University Computer Centre, Clayton in 1986

The heart of the UCP was a Motorola 68000 microprocessor. As time had by now moved on, and the 16-bit Motorola 68000 microprocessor had since become available, it was chosen for the UCP due to the Unibus also having a 16-bit architecture (the VAX had inherited the Unibus from the preceding PDP family to leverage the extensive range of PDP interface boards). The quirky result was that this newest most powerful CPU chip resided solely within a single peripheral card, while the main BP and TP processors remained the original more limited 6809 devices.

Thus the hardware challenge was to implement a number of address/data/control parallel bus format conversions:

• to interface the DEC Unibus to the UCP’s on-board 68000 architecture (of note the Unibus and 68000 used opposite conventions for ordering the high and low bytes within their respective 16-bit words, adding further difficulty);

• to interface the on-board 68000 buses to a long-distance form of the NAB extended to the UCP by the MPI;

• and at the MPI end to convert this to the NAB format so that the UCP/MPI combination appeared as just another TP within the MONET node’s multiprocessor architecture, while the DPM appeared within the 68000 UCP’s address space;

• the NAB had not been conceived for extension over the longer distances needed to reach beyond the internals of the MONET node chassis, thus the challenge at the MPI end was to convert the NAB into a form suitable for extension, as a parallel bus, to the UCP card to be located within a nearby VAX.

The software challenge, within the UPC’s 68000 software and companion driver software within the VAX itself, was to make the UCP appear simultaneously:

• as a TP from the point of view of the MONET node, in which the 68000 software would directly deposit and retrieve data packets from the node’s DPM, and

• as a bundle of serial lines from the point of view of the VAX, but without the VAX incurring character-by-character interrupt and processing load, which was the case for their ‘real’ serial interface cards.

The need for software development beyond the MONET node itself, saw the introduction of a new member to the core team, John Mann, one of the Computer Centre’s VAX software specialists. John developed the UPC software suite, on both the 68000 and VAX driver sides, handling the communication from VAX applications all the way through to interacting with MONET’s multiprocessor message passing protocol via the node’s DPM.

9 Circuit Board Fabrication

All the earlier MONET boards were fabricated as double-sided printed circuit boards, fabricated using conventional photo-etching processes outsourced to a nearby commercial facility. Graphics were all designed in-house and rendered using stick-on adhesive tapes and decals, onto clear plastic sheets, as was typical for the era. Three overlaid sheets were used, for common, top and bottom layer graphics. Earlier work in the department had used red and blue graphics to denote each layer. All MONET boards were however designed using flexible black crepe adhesive tapes, the results of which can be seen in the curved tracks evident in Figs. 1 and 3. Components were loaded onto the printed circuit boards manually, initially in-house by a manufacturing team led by Russell Keil, and then subsequently by Racal for higher volume manufacture.

However the higher complexity of the UCP and MPI boards presented a greater challenge. These were fabricated using an outsourced robotic facility located in Perth, Western Australia. The resulting multilayer boards comprised two embedded power/ground plane layers fabricated using conventional double-sided photo etching processes over which were laid multiple overlapping layers of discrete insulated wires robotically laid into a resin bed. Required holes were then robotically drilled, the insides of which and the pads for which were then electrochemically plated. Fabrication information was supplied by data file. The resulting boards were no thicker than a conventional printed circuit board. This was a very effective technology for high-density low-volume custom circuit board fabrication. Unfortunately it suffered a high rate of failure where the in-hole plating would not make contact with the exposed cross-section of a wire intended to end in the hole. In response, in-house development of the supplied design software comprised: firstly re-sorting the wiring data geographically to minimize the robot time (boards were charged by fabrication time), and then modifying an HP flatbed XY plotter to automatically QA test continuity of each and every wire of each incoming board, again using a geographically sorted wire list, so that the human operator’s probe (A-end) and the plotter’s probe (B-end) never collided during the QA process.

10 From Early Tests to Patent

The first test nodes were installed from April 1981 and development work continued throughout 1982.¹² The nodes could be connected to computer ports, terminals, printers, Telecom modem lines and other serial I/O devices. By November 1982 the new network was being installed to connect to the available computing facilities which, at this stage, included a dual processor Burroughs B6700 computer, nine VAX computers¹³ and a range of printers and graph plotting devices.¹⁴ At the beginning of 1983 there were 40 nodes in the network with connections across 700 terminals and 350 ports on 16 medium to large computers.¹⁵

The University team tested their network on site and also delivered a network to the Victorian Totalizator Agency Board (TAB) and the Telecom Research Laboratories for further test sites. In November 1981, the TAB confirmed they were ready to implement “an ‘in house’ local Data Network based on the Monash developed MONET”. This network was given the name TABNET. The Monash staff would provide consulting work to TAB’s system engineers and supply three fully configured MONET nodes at AUS$4000 each.¹⁶

The major rollout of the MONET network was undertaken during the mid-1980s. Dr Carlo Kopp was a Computer Systems Engineer from 1985–1987 at the Computer Centre and responsible for network installation across the campus during this period. The cabling team installed a backbone cable from the nodes attached to the VAX, Burroughs and other systems within the Computer Centre to the distributed nodes at various sites around the campus. The first cabling was focussed on the student computer labs and then research computer facilities. Later the administrative areas were connected and then individual cabling for academic staff. It was a difficult task as the existing buildings did not have suitable ducting for computer cabling and the service staff lead by George Cobb had to be creative in finding ways to feed the cabling around the buildings.¹⁷

By 1983 the staff at the Computer Centre was confident that the new network was running effectively. Their next step was to apply for a patent and also to find a commercial partner. After lawyers assessed the paperwork, Monash University applied for an Australian patent on 30 April 1984 for an invention entitled, “Improvements relating to digital communication systems” with the inventors listed as Dr Clifford Bellamy, Neil Clarke, Peter Gordon, Keith Heale, Patrick Miller and Barry Treloar for the owner, Monash University. The assigned number for the patent is AU1984028267.¹⁸

The patent process took several years and was finally granted in 1988. They also applied to patent the system in Europe and paper work was filed under EP-O148191 on 30 April 1984. This was at the same time as transferring the technology to RACAL-Milgo which did not pursue it and the European patent application lapsed.¹⁹

11 Monash University and RACAL-Milgo Australia Pty Ltd

With the network running successfully on campus, Cliff Bellamy then sought a business partner to manufacture the MONET system and produce a commercial product during 1983. Several businesses showed interest in the new LAN including Burroughs, Datacraft and Digital Equipment Corporation (DEC). Treloar and Bellamy attended the National Computer Conference in US that year and then went on to visit the offices of Burroughs, Micom, Research INC. and DEC for technical presentations on MONET.²⁰ Nothing came of these discussions and then in January 1984 Monash again called for interest in joint manufacturing the system in the magazine Computerworld.²¹ This produced two definite possible business partners including RACAL-Milgo Australia Pty Ltd. RACAL-Milgo was a large international firm that had offices in several cities in Australia. RACAL Electronics was an English company that went into a joint venture with the American firm Milgo in 1969. Milgo was an early manufacturer of modems and specialised in networking. The company is now part of the Thales Group.²²

In May 1984 R.G. Gregory, from RACAL-Milgo wrote to Cliff Bellamy with the companies’ offer for a partnership to sell MONET. They would pay Monash University a technology transfer fee and then the University would receive 10 % royalty on sales value to third parties. Monash would supply RACAL-Milgo with all the MONET components and software including processor boards with battery backup, X.25 interface, VAX serial interface, and network manager system. The company would manufacture and market the system with an advertising campaign. This offer was accepted and RACAL-Milgo started on the new venture.²³

RACAL-Milgo entered into full scale production employing Australian engineers, draughtsmen and production staff. While emphasising that the MONET system was a proven, reliable Australian-designed and Australian-made product, the main sales feature was the price. Their advertisement in 1985 quoted a typical price of AUS$200 per port connection. They also had seven installed sites to demonstrate the working systems. The network at Monash University was used by salespeople to show the system to potential customers and Centre staff made themselves available to answer technical questions. On 26 May 1985 the local Melbourne newspaper, The Age, reported under the title, “Monash ‘invention’ takes off” the success of the new LAN and named several large customers who had installed the system including Telecom Research Laboratories, the Victorian Harness Racing Board, St Vincent’s Hospital and Victorian TAB. The Monash team also published several papers during 1985 on the development of the MONET system, including papers in the Australian Computer Journal²⁴ and Computerworld.²⁵

The sales of the new LAN system produced an income stream for Monash University. RACAL-Milgo started paying royalties to the University by October 1984. The University had by then already received the technology transfer fee. In a royalties payment notification letter in June 1986, RACAL paid Monash just over AUS$35,000 for sales made earlier in the year with a further AUS$21,000 to be paid on receipt of invoices for additional installation sales.²⁶

Monash University continued to maintain its own MONET system. By 1986 they had 2,200 ports supporting 1400 terminals, about 80 printers and 18 medium to large computers. The Centre had acquired a new mainframe, a Burroughs B7800, as well as 15 DEC VAX machines and 2 Pyramid computers; they also had a number of minicomputers distributed around different departments.²⁷

Monash University continued to use the MONET network throughout the 1980s. By mid-1988 there was still some developmental work on circuit boards and software but the project was drawing to a close. Neil Clarke told staff that they intended to have all hardware development work completed by the end of 1988.²⁸

In October, 1989 the commercial agreement between Monash University and RACAL-Milgo was dissolved.²⁹ This was due to changes in the structure of the RACAL organisation. They transferred excess stock to Monash University in lieu of royalties and stopped marketing the network. Existing customers maintained contact with Monash and continued to be partially supported. The Monash University Computer Centre was still supplying revised MONET software to a customer in 1990.

12 MONET and Ethernet

The commercial success of MONET was eclipsed by the development of other commercial networking devices including Ethernet and token ring systems, including proprietary solutions such as IBM’s Token Ring. Ethernet had contemporary beginnings, with Xerox PARC installing a network using their new technology in the mid-1970s. Through the 1980s, these different approaches to networking competed for dominance, but it was the Ethernet system that became the accepted world standard with IEEE recognition on 23 June 1983.³⁰

The emergence of mainstream personal computers (PCs) in the 2^nd half of the 1980s led to their progressive replacement of basic VDU terminals as user interface devices. The general purpose and higher performance computing capability of PCs progressively led to the migration from serial RS-232 data communications (inherent to VDUs) with Ethernet, firstly within the LAN and subsequently over wide-area telecommunications networks with the progressive replacement of voice-band modems with ADSL, HFC and similar Internet delivery technologies.

In parallel with the development of PCs, Ethernet itself was evolving – from its original awkward and limited ‘thick coax’ cable, through its ‘thin coax’ and then to the CATx UTP cable that we are familiar with today. In so doing, Ethernet displaced other competing LAN technologies such as token ring based systems. At the same time, the Internet and its suite of IETF communications standards (TCP/IP etc.) exploded into dominance over other wide area network protocols such as X.25.

The end result was PCs, Ethernet and the Internet replaced basic VDU terminals, RS-232 and ‘dial-up’ modem services across the board, in turn superseding RS-232 based terminal access networks such as MONET and other serial terminal exchanges which all became no longer required.

In 1991 MONET was replaced on the Monash University campus by an Ethernet network. The MONET network was too slow for large file transfer applications. The Ethernet system required a new network of optical fibre cable and would operate at speeds up to 10 million bits per second.³¹ This new network coincided with Australia’s exposure to the Internet and subsequently the World Wide Web.

13 Conclusion

The 1970s saw a huge growth in the number of computer installations within organisations and the movement of data between computer systems. There was also a rise in the number of people who used computers. This all led to an increase in the number of individual terminals being required to access multiple computers. The need to create some form of network was critical in university communities. It was a new field and computer engineers came up with individual solutions for their own environments. Staff at Monash University Computer Centre met this challenge by combining their skills in hardware and software to produce their own network. Once a solution was found, Dr. Cliff Bellamy, with his entrepreneurial flair, actively sought a business partner to manufacture and market the network on a commercial scale. This generated useful income for the Computer Centre as well as serving the University’s aim to work with industry in Australia. It was an innovative network solution developed in-house using the then available general-purpose digital integrated circuits and microprocessor chips. Although MONET was ultimately replaced by a different solution, the MONET network had met the key criteria set by the University in 1979 to create and install an economical computer access network across an extensive campus with distributed computer installations and a large numbers of users (Figs. 8 and 9).

Fig. 8.

Photographer: John Millar, Monash University Archives, MONPIX Image Number 1565

Handover of MONET software to RACAL Electronics. L-R: Dr. Cliff Bellamy, Mr. Robert Morgan, Mr. Roland Horat and Mrs. Gail Morgan, dated 1984

Fig. 9.

Reproduced by permission of the Thales Group

Advertisement for MONET system sold by RACAL-Milgo, Computerworld Oct 18, 1985 p. 22