Overview of Cyberterm, 
	      a Cyberspace Protocol Implementation

KEYWORDS

cyberspace, protocol, Cyberterm, virtual reality, SECTOR, AGENT

AUTHOR

Michael Snoswell, Programmer in Imaging Systems, Vision Systems Limited,
Second Avenue, Technology Park, The Levels, 5095, South Australia.

ABSTRACT

Although the concept of cyberspace has variously been used to describe
concepts ranging from being in a particular directory in a file system to a
full immersion/neural-tap type 3D environment, few attempts have been
made to establish a fundamental connection layer under which any
independent interaction within such an environment may take place. A
number of system concepts have been developed that would be essential
tools towards realising the more advanced version of cyberspace mentioned
above (eg head mounted displays, datagloves, 3D 'Rooms', MUDs etc) but
little work has been done on producing a base level integration layer between
any of these systems in an extensible fashion. The problem is analogous
to the development of words with which to communicate, rather than
focusing on sentence structure, or poetry. Once the words are there and
the grammer is established, any data or concept can be communicated.
The Cyberterm project arose from a desire to provide a freely available
framework for communication, with example code implementation so that this
basic communication hurdle could be overcome and the more abstract
features of virtual reality, cyberspace conferenceing etc could be focused
upon and developed.
	This protocol has been called Cyberspace Protocol (CP) and software 
which implements this protocol is called a Cyberterm (CT). The CP version
is currently 0.3 beta.

THIS DOCUMENT

This document is an overview of ideas and concepts that have evolved
over the last year or so. It is not meant to be comprehensive, exhaustive,
complete or static. 

The first part of this article discusses some broad ideas and then
gives a brief description of the terms used. Following this is a semi
technical discussion on a walk though some of aspects of the system.
After that a brief description of the software as it stands is
given, along with projected milestones.

This article mentions many ideas and concepts that stem from the use
and implementation of the Cyberspace Protocal (hereafter called CP). 
A large portion of this paper discusses broad uses of CP and the resulting 
system characteristics rather than focusing on the protocol alone. 
The reason for this is two-fold:

  1) The protocol by itself would seem pretty meaningless without 
     describing how it works and how its resulting use affects the 
     dynamics of a system, and 
     
  2) The protocol isn't firmly set. As the system is developed, more 
     holes are found and things change. There are a dozen or so basic 
     messages and a dozen or so rules that are followed, these are in flux
     although a base set is firmly established.

It is hoped that this paper will give readers some familiarity with the
type of system that is beeing aimed for. A more complete description
will be left to the source code itself when it is released. 

Note: Where possible terms in capitals refer to concepts/objects which 
are peculiar to this system. This is to try to differentiate items 
when using English to describe some ideas etc, to make things a bit clearer.



SYSTEM OVERVIEW

The need for a low cost, low bandwidth cyberterminal (CYBERTERM) has 
arisen due to the increasing need to communicate over existing data 
channels with existing hardware. The system is aimed for widespread use 
over a number of platforms and data connections. Initial release is planned 
for late '92 in a shareware format with full source code for all available 
systems.



INTERFACE

The interface is simply using the screen with the keyboard and mouse to 
provide a window view into a 3D environment. 

The addition of Glove, HMD and other devices will be encouraged but not 
initally supported and will not be required. 



INITIAL SYSTEM

The system will initially be designed around a 386SX PC (or better), 
with Amiga and X11 (on a Sun IPC) ports being made, but with no special 
provisos for these machines at this point. All connections will be via
modem with possible TCP/IP connections for the Sun. Each Cyberterm is
fully self contained on each machine and can operate on a stand-alone basis.
Software is currently being written and a beta version will be available 
in a few months (now is July '92). Release will be via request to selected 
users for immediate feedback, followed by general shareware release.



SYSTEM ARCHITECHETURE

The whole nature of the cyberspace is controlled by the messages that are 
sent, which implicitly define the rules for objects, users etc within the 
cyberspace. To more clearly describe the nature of these rules and 
messages, a number of terms have been borrowed and coined to describe 
new/borrowed concepts. Once these terms are defined, then it becomes 
much clearer as to how the whole thing fits together and the interaction of 
objects and the nature of this interaction will become evident as you 
understand the rules and contraints which define the behaviour of the 
cyberspace.



DEFINITIONS

These definitions are brief and are given to allow a fuller understanding of
the descriptions to follow.

CLIENT

A CLIENT is the term to describe a person (USER) who is connected to a
system. The CLIENT may be automated (an AGENT).

SERVER

A SERVER is the central message handling facility which handles the data
flow between CLIENTS. (A bit like a BBS)

LOCAL SERVER (LS)

A LOCAL SERVER is a SERVER that resides on the same machine as the
CLIENT.

REMOTE SERVER (RS)

A REMOTE SERVER is a SERVER which is not at the same physical machine as 
the CLIENT in question.

CYBERTERM (CT)

This is the term to define the CLIENT and the LOCAL SERVER together which a USER
interfaces to. This all resides on his local machine.

SECTOR

A SECTOR is a region of CYBERSPACE which is controlled by a single SERVER.

SECTOR CONTROLLER (SC)

This is another term for the SERVER, but which covers the CLIENT that is
local to that SERVER (akin to a News conference moderator or a BBS
sysop).

PERMASPACE (PS)

PERMASPACE is an area of the SECTOR which has been allocated for a
specific purpose. The data defining this region resides in the SC which
controls the SECTOR.

PRIVATE PERMASPACE (PPS)

PERMASPACE can belong to a single CLIENT (or else it belongs to the SC). If a
USER acquires a region of a SECTOR for their own use, that region is
called PRIVATE PERMASPACE and is controlled by the owner CLIENT's LOCAL
SECTOR CONTROLLER (ie the SERVER which resides on their own machine).

LINE

A LINE is the connection from the SERVERs to the CLIENTS, LINEs can be
virtual or real.

AGENTS

AGENTS are macros that use the messages and protocols of the system to
perform tasks as the USER himself would. There are 3 types of AGENTS
defined so far. PRIVATE AGENTS, SC AGENTS and INDEPENDENT AGENTS.

ASPECT

ASPECT is the description of an OBJECT and covers visual and audio
definitions (dynamic and static) in an extensible hierarchy of 
increasing complexity. All objects have default ASPECTs.

CYBERSPACE CONFERENCING (CBC)

This is the initial "let's get together and have a chat" aim of the
system and is useful when people ask "So what are you working on?". You
say, "I'm working on a Cyberspace Conferencing system", or something
like that.

GUEST

A GUEST is a CLIENT who is remote to your location who is connected to
your LOCAL SERVER.

BBS

A bulletin board system, which when in "chat" or "conference" mode is a
good analogy for what this system will build upon (ie a graphical
version of a BBS CB channel.)

OBJECTS

OBJECTs are any things which exist within a SECTOR and are listed in a
SERVER database. This includes CLIENTS, AGENTS, PERMASPACE etc.

ID

ID applies to AGENTS, CLIENTS and SERVERS. It is a unique 32 bit number
where the top (MS) 4 bits define what type of object the ID belongs to.

FAR - 1,000 units
NEAR - 100 units
CLOSE - 10 units
VERY_CLOSE - 1 unit (ie 26 adjacent units)



A DEMONSTRATION RUN THROUGH

Perhaps the best way to show how the various features of the system interact
and the effect of the protocol on system implementation is to give a 
description of a typical session on a CT. This description will not be 
exhaustive and will give only some technical details of the message passing 
that will take place during such a session. A complete description of all 
the features will not be given here as that would take too long and this 
is only meant to be an overview. However, what I hope is to be able to 
give some insight into what the working system will be like.

First off when you start up the CYBERTERM you have a blank screen with maybe 
a few control buttons around the edges. 

The first step is to log into the LOCAL SERVER. Now this is a SECTOR 
CONTROLLER that resides on the same machine and in the first incarnation of 
the software is all in the same executable. 

This connection is done by hitting the 'connect' key (or mouse button etc). 
This will send a REQUEST_TO_ENTER message to your LOCAL SERVER, but first 
the interface will require that you enter some parameters. These are:

  1) your proposed entry point into the LOCAL SECTOR, and 
  
  2) the proposed viewing direction. 
  
In a more advanced system these parameters will probably be pre-set in 
an option menu and stored in a configuration file, so you don't have 
to enter these details each time.

(Note: There are quite a few places where things can be pre-set like 
this, as you'll see).

Once the CLIENT software has assembled this data it sends the message to
the LOCAL SERVER. This message consists of:

	1. your ID, a unique identifying code (4 bytes) that defines you 
	as a human CLIENT as well as giving you a unique handle for reference 
	purposes.  
	
	2. the length of the following message (2 bytes) 
	
	3. the message code (2 bytes), which in this case is REQUEST_TO_ENTER. 
	
	4. the proposed entry location within the remote SECTOR (3 x 32 bits)
	
	5. the proposed viewing direction within the remote SECTOR (3 x 32 bits)

Note: All data relating to position and velocity is sent as 4 bytes in
fixed decimal format, with 2 bytes integer and 2 bytes fraction, integer
fraction signed.

The connection between the CLIENT and the LOCAL SERVER is a buffer 
that is a LINE for the CLIENT and a VIRTUAL LINE for the SERVER. 

A daemon type function transfers the message across to the SERVER's 
VIRTUAL LINE (and visa versa). 

The reason this is done is so that the software for a REMOTE SERVER and 
the LOCAL SERVER will be the same, except that the daemon will be 
different (ie transfering data to and from a modem, serial line, socket, 
or whatever). So as far as the SERVER is concerned it is running 
autonomously from the CLIENT and the human interface handling software.
(in fact a REMOTE SERVER is the same software on another machine,
complete with it's own CLIENT and USER who calls it their LOCAL SERVER. A
central SERVER simply has lots of physical lines for connection, whereas
the server on your local machine will have 1 physical LINE (eg modem) but
many VIRTUAL LINES so many people can enter your PRIVATE PERMASPACE and
reside in your LOCAL SERVER over the one LINE.)

The LOCAL SERVER checks its internal database of objects to see if you are
allowed to enter at the specified point (more on that in a moment) then
sends a MOVE_TO message back to the CLIENT. This includes the CLIENT's
ID to make sure the right person gets the message (not necessary
obviously as you're the only one logged into your machine), the message
length, the messgae type (MOVE_TO) in this case, a location
tuple, a direction tuple and a velocity tuple (which is zero in this
case). Now it looks like we're already sending redundant information, but
these are generic commands that can apply to many situations.

Your CLIENT software now gets this MOVE_TO message and can throw up
an image on the screen which shows what the SECTOR looks like from this
viewpoint.

What's there to display? Well by default the 'floor' of the sctor is
blue and can be displayed as a grid. The spacing between the lines of the
grid, and whether it is solid or wireframe is a configurable option and is a
function of the display software, not of the system as a whole.

The range of co-ords is 2**16 (65536), signed, as a 32 bit fixed decimal 
number. This effectively gives a cube 65536 units on a side. That seems 
small but think of each unit as one metre. This means the SECTOR is about 65kms
cubed, with increments down to 1/65 mm. I really think this will cator
for system (and user) requirements for a long time to come. There is
room for much more detail than this actually (2**32 times more) as is 
shown later under PRIVATE PERMASPACE.

Okay, so we see a blue grid below us. Our CLIENT software is keeping
track of our velocity and co-ords at the last vector change (ie time
stamped when we received the MOVE_TO message) in its internal object 
database (this is separate from the SERVER's  object database). 
So a simple look at the time and a scan of the object database will give the 
current location of all objects and the screen can be updated accordingly. 
If your machine is slow this screen update is slow etc.

Now that you're logged into the LOCAL SERVER things get a bit more
interesting. To make things a bit clearer I'll skip over the details a
bit here and get to a remote connection.

Suffice to say that the objects contained in the LOCAL SERVER all belong
to your PRIVATE PERMASPACE. There may be objects here, for instance that
represent your hard disk and so you may have a graphical operating system
where you can move files, launch applications etc. You can construct
objects and store them for later use. Certain areas may be defined as
doorways to the control of real-world apparatus by telepresence etc. 

You now have your own SECTOR, a whole world really, in which to create
and move. This system in later implementations may be tailored to the
host machine and become a GUI like MS Windows or OpenLook etc, making the
Cyberterm well worth using on its own. 

The next step is to send a TRANSFER_SECTOR command. This will move you
to another SECTOR. This will obviously be a REMOTE SECTOR. It's up to
you to specify a legal SECTOR you wish to transfer to and it's up to
your LOCAL SECTOR CONTROLLER to know how to connect to the SECTOR.
Asumming all this has been set up (the connection details for each physical 
line your SC has will be defined in the configuration files), your LOCAL SC 
(for a modem connection) dials up the remote SC and identifies itself as 
an SC that has a CLIENT that wants to enter. This is sent as a 
REQUEST_TO_ENTER command (as before). Your CLIENT software knows that to 
issue a TRANSFER_SECTOR message you must enter a location and view 
direction so it prompts you for them (or gets it from pre-set options 
as before). The local SC passes the info on to the remote SC. If the 
request message is okay, a MOVE_TO command is sent from the remote SC 
to the local SC which now knows that any data coming in from the CLIENT 
(on LINE x) is transfered straight to the remote SC (on LINE y) and visa versa.
This is easy to implement because each message has the CLIENT ID at the
beginning, so it is a simple matter for the SC to chech to see if that CLIENT
has a redirection flag set. If the flag is set, the SC gets the message length
(the next 16 bits of the message) and then gets the whole remainder of the
message as a block and passes it directly out to the redirected line.

Now that your CLIENT software has a new location and viewdirection it
adjusts it's internal object database and updates the screen accordingly
(the blue grid).  The SECTOR you came from is represented by a single
OBJECT (a blue cube by default) that is your PRIVATE PERMASPACE.

When you entered the SECTOR the SC sent a message of its own to all 
other users who are within NEAR (100 units) of where you entered.
These messages say what your ID is, the message length, the message type
(PERSONAL_ASPECT_DATA), your vector, viewdirection and location (this is
actually a PERSONAL_ASPECT_DATA message which has ID, vector and
location in the front of the message but without the ASPECT data as the
SC doesn't have this yet). 

These other users may have their systems set up to ignore these 
(unexpected) messages, but if they process them then you, 
the new user, will appear on their screens in the appropriate place and will be
placed in their individual object databases. They may also have a
database of 'know ASPECTS' and can check to see if they already know
what you look like and so can display you in your full glory straight
away. Alternatively they may have their system set up to automatically request
your APSECT if it is unknown and to display it then.

Now you can send a message (or a more sophisticated system would be
pre-set) to ask the REMOTE SC what the brief details are of all users
within NEAR of your location (that is, to send you PERSONAL_ASPECT_DATA
messages with ID, vector and direction. This is a PERSONAL_ASPECT_DATA message.
The SERVER sees that the CLIENT ID you sent doesn't match the ID of the 
sender (by checking whose on that LINE) and so it know the message must be 
a request for information. It looks for the ASPECT data in its own database
or asks the CLIENT in question for the data, then sends the information
back to you. This data is added into your CLIENT's object database (with 
a time stamp) and the objects appear on your screen with the default 
ASPECT. You can request the details of other users over different distances 
first off if you like. Once you know the ID of other users you can 
REQUEST_ASPECT_DATA of a specific ID, to whatever level of detail of 
ASPECT exists.  So on your screen these other users appear as arrows 
(their default ASPECT) or their real shape (ie higher level ASPECTS). 

When you move (that is, change your velocity or direction) your CLIENT
automatically sends a message (MOVE_TO) to the SERVER. If this is okay by
the SERVER then it sends a MOVE_TO message to you telling you where to
move to (the reason for this is made clear later) and then the SERVER 
distributes the message to all NEAR CLIENTS. In this way, as you watch 
your screen with these objects moving around in straight lines until 
they change vector or velocity when you get a message from the REMOTE 
SC telling you their new velocity/direction. If you turn around your 
system sends a MOVE_TO message that is distributed and others see your 
shape turn around etc.

It is important to note that there is no collision control and it is quite
possible for you to move straight through someone else. This is a
controversial decision that is open for objections, but (as will be seen
later) is not always true and it is within the current CP to change this.

Note: The only possible exception to this is stopping over a PERMASPACE
unit you do not own.

An optional message that you can send to the SC is CHANGE_UPDATE_RATE 
which tells the SC how often to send you location, vel etc updates 
of all CLIENTS within a given distance of yourself. Normally you would 
have to request this information specifically and the position of users 
you see on the screen may be false (for example a user may drift out 
of the NEAR distance from you but your object database is still tracking 
them saying they are moving at such and such a vector and speed when 
actually they may have changed direction etc. So with a CHANGE_UPDATE_RATE 
message you can request to be updated on the status of users who are 
NEAR or FAR or whatever say every 10 seconds. Of course if they move when 
they are within NEAR of you then you will be automatically updated anyway).

Other commands within a SECTOR are SEND_MAIL, REQUEST_PRIVATE_PERMASPACE etc.

Similarly to  requesting the ASPECT of users in the area, you can
request the ASPECT of PERMASPACE in the area. 

PERMASPACE is permanaent regions that default to blue. 

These will usually consist of PRIVATE PERMASPACE but some regions may 
be owned by the SC such as public database access areas and public 
bulletin boards (more on these later).

Just like CLIENTS, PERMASPACE has a default ASPECT that is a blue cube
that occupies the unit cube that is the centre of its local co-ordinate
space. Requests for higher level ASPECTS may reveal these cubes to be
buildings, flashing lights or data structures etc. 

A PRIVATE PERMASPACE ASPECT may reveal that it belongs to a friend of 
yours. (It may his name on top or maybe you recognise his style of 
castle!) 

You can move through PERMASPACE but you CANNOT stop (ie have 0 velocity) 
when in a unit cube of PERMASPACE which does not belong to you. 

So you stop one unit away (VERYCLOSE) and send a 
REQUEST_TO_ENTER_PRIVATE_PERMASPACE. This is interpreted by the SC as 
a TRANSFER_SECTOR message, to the LOCAL SERVER of the user who owns 
that PPS. If the request is okayed by the owner then you are sent a 
MOVE_TO message that moves you to the coords of the PP. 

Now you have transfered to a new SECTOR and are controlled by
the owner's private SC on his machine. The remote SC you were controlled
by now routes all your data straight to the LINE that that new SC is on.
(in a similar way to how your LOCAL SC is re-routing all your data
straight through to the modem).

Once again your screen is blank and you can request to see what's around
you. This person may have his SECTOR set up to look like a lounge room
or as rolling hills etc. All messages from users who you could see before
(ie those outside that unit cube of PPS that you're in) are filtered out
to reduce bandwidth requirements (you may, for instance want to keep mail
coming through. If you have a powerful system you may still get all
'outside' messages but make the walls of the living room appear
transparent like smoked glass etc).

Now that you are in his SECTOR you must abide by his rules. If you send
a MOVE_TO message that will make you collide with objects in his PPS (eg a
chair or wall) then his sector can return okay for that request, but
when it calculates that you've hit a wall, it can send an addittional
MOVE_TO message that sets your velocity to zero. In this way you must
follow the rules he has set up in his PPS. Obviously if he proves to be
obnoxious you can send a EXIT_SECTOR message that the main REMOTE SC
intercepts and so moves you back out into public cyberspace,
garuanteed.

Other users can enter the PPS of your frined at the same time  so you
can have a 'private conference with only those present'. At that time
his LOCAL SC has set up secondary virtual LINES to allow the
messages from several remote CLIENTS to come down the one modem
connection. As each message is preceeded by the message senders ID, it's
a fairly simply task for the SC to put the incoming messages into
the appropriate virtual LINE buffers so the it thinks there are lots of
people/modems connected up.

Of course, the main remote SC may also provide private conference rooms where
similar duscussion can take place.

This PPS may alternatively be the front end to access a commercial
database, a game service, a ticket sales office etc.

So you want to establish your own PPS within the public SECTOR? You send
a REQUEST_TO_ACQUIRE_PRIVATE_PERMASPACE message that is sent via the REMOTE
SC to anyone who is CLOSE to you (within 10 units). If less than 50% of
those nearby say 'no' to the SC then you aquire 1 unit of PPS and this is
registered in the SC's object database. You can optionally send
PERMASPACE_DATA messages to the SC that define the ASPECT of your PPS to
whatever level of detail you desire so others can see your new
acquisition. Clearly, you can aquire several PPS units next to each other
and build up a composite structure that is more impressive.

This acquisition is monitored by the REMOTE SC and there may be limits defined.

Some reqions of PPS that belong to commercial users may be large. For example 
a database service for shares information may have a large area of PPS that
(when you request to see higher level aspects) may be a large building
surrounded by wide grass areas with fountains and gardens. Maybe there
would be large areas within the owned PPS block that has no higher ASPECT so
that in a crowded area of many PPSs the structure will stand out as it
has all this 'open' space around it. In the same way office blocks today
in large dense city areas surround themselves with grassy promenades and
foyers with open areas and plants. Of course a default level display
would show just a large matrix of blue wireframe cubes.

You can send mail to a friend by several methods. The most straight
forward would be to use the SEND_MAIL message where you specify the
recipients ID and then the message size and then the message itself.
(no set format). The mail will be sent straight to his LINE. 

He may have his CLIENT software set up so mail appears as a flashing icon on
the computer screen or as a full letter box outside the little cottage that is
his PPS.

Mail can also be sent to a location (using an AGENT) and the SC will 
try to inform the owner. This AGENTS may have the ASPECT of a piece of paper
or an envelope or a flyer with the message as text, built into its ASPECT.

In a similar way a true bulletin board could be set up, where people
could leave messages for others to read simply by leaving AGENTS at 
predefined locations setup to be massage areas.

So you can conference with otheres, send mail, access commercial
services etc.

The commercial services may first connect to the system using their
original 2D flat screen interface, so when you enter their PPS you just
see a single screen. In this way the interface changes would be minimal
to start with but they could develop better interfaces to make data
access more efficient. A statistics service could have a PPS where data was
represented as dynamic 3D structures etc.

Probably the most useful items within the cybersapce are your AGENTS.
These items exist as packets of messages that together form an entity
that is a type of OBJECT. See the comprehensive definition later on for
details. AGENTS can do whatever you can do, in your place. Some AGENTS
are simply OBJECTS that you use (for instance a 'design-an-aspect' AGENT
may allow you to draw items in 3D (walls, texture, motion etc) by issuing
messages to define ASPECT as it is moved by your Glove when certain gestures
are used. It may be an access key tool (eg you might buy a '10 shot' AGENT 
from a database service. When you want to access that database you instruct 
the AGENT as to what you want. The AGENT then goes off to the database's 
PPS (moving as any other CLIENT would, so others would see it travelling) 
and gets a high prioirty of service (because you paid for it!) and also 
knows how the database works and so can access the data faster and then 
mail the data back to you (or maybe return to you itself with its ASPECT 
changed to show you the data) and after the tenth use it doesn't come back. 

The last sort of AGENT is independant. These actually are macro
languages that are executed by the SC and may act as guides
to newcomers or perform tasks within the sector for you (ie like a
servant). They can exist by themselves. You can have an AGENT that
'lives' in your PPS and answers requests to enter from other CLIENTS while
you are tied up somewhere else. Now this brings on all sorts of
possibilities. You could send an AGENT to a conference in your place and
it may respond to text as a human would, to gather data for you. For
this reason and others, there is one strict rule, and that is that the
default ASPECT of AGENTS are a white star made of three perpendicular
axes.

Another example is to have several AGENTS that travel with you in unison
and which have ASPECTS that fit into yours to make one larger, more
impressive ASPECT.

One ASPECT detail that hasn't been mentioned is sound. Obviously a sound
interface would be good (so you can talk to people you meet rather than
just sending mail or typing stuff in during a private conference). Sound
would be easy enough to implement into the SEND_MAIL message protocol
(you get mail from someone who is in such and such a direction
therefore the headphones position the sound source accordingly). But I
would like to incorporate it into the ASPECT as well so you could hear
someone comming, even if you were looking in the wrong direction.

Due to its complexity, however, sound ASPECT details will be left to 
future CT implementations.

Note: It's clear that this system is open to abuse to rogue CLIENTS that send
invalid messages. Or AGENTS roaming around accruing PPS for their owner.
Or worse still, AGENTS with the ID bits set to indicate it is a human,
sent out to bother people etc. The buck will have to stop at the SERVER 
and so this program/system could end up being a pretty awesome beast as far 
as functionality goes. This is where the 'God' concept comes in. It could be
implemented, for instance, to force collisions when OBJECTS are coincident,
or to limit speed etc. This amount of control is only limited to the SERVER
implementation. Some SECTORS may exist as lawless grottos where no-one is
who they say they are and CLIENTS immitate you once they have your ID etc.
Others SECTORS may be impecably realistic and well behaved (sort of like the
difference between UNLAWFUL/EVIL and LAWFUL/GOOD in AD&D). This protocol 
allows for all such systems to work together.



SOFTWARE STATUS

The system so far has a CLIENT that connects to the LOCAL SERVER and
allows the user to move around within their own SECTOR, requesting 
information on and displaying PERMASPACE objects that are already in the 
SERVER's object database. The default objects in the SERVER are 3D block
representations of the directory structure of the hard disk and are created
when the SERVER is initialised.

This is all done with solids polygons. Calculations are in floating point 
and are being modified to fixed point maths before any more work is done. 
The virtual line/modem links are implemented but not tested.

The first release of the software will not address display, interface or
speed related problems. It will provide a simple base framework upon which
others may build, knowing that whatever additions are made, they will still
be able to connect to other users on other systems.

This system currently works on a PC and on a SUN (X11).

The graphics library used is VOGLE, but REND386 is being incorporated 
for 386 PCs. An Amiga version is in the works (mainly just requires the
VOGLE driver). VOGLE is available from most ftp mirror archive sites, I got
it from the Australian ftp mirror site, archie.au:/graphics/graphics/echidna

The nature of the system will be such that if you have a PC XT with 
hercules graphics then you can display only wire frame images at 1 frame per 
second (or whatever the software can manage). If you have an Indigo or 
similar then you are lucky enough to be able to display 30 frames a second,
solid or rendered. The idea is that all the different systems will be able to be
functionally connected together in a meaningful manner. If you have a full 
body suit, you get better integration into the cyberspace etc.

The code is in ANSI C. This system is ideal stuff for C++ but that would limit
the platforms we could easily port to (and not enough people are comfortable 
with it yet).

SOFTWARE RELEASE

Initial software release is late December 1992, with possible beta releases
before that (September/October). A mail list exists for those wishing to 1) 
receive the latest news on the system as it is released 2) those wishing 
to offer programming assistance, and 3) those who wish to receive the 
beta release. Just email me, requesting to be added to the list.

Michael Snoswell				June 1st, 1992
snoswell@sirius.ucs.adelaide.edu.au     	Revised July 17th, 1992