esz001@cck.coventry.ac.uk (Will Overington) (04/25/91)
I am interested in the use of virtual reality in order to develop
a useful user interface for various ideas of mine which have
developed over many years.
Last year, I did quite a lot of work on developing a piece of
software which I called comet and I enclose some of the built in
notes for the system, which hopefully will give an overview of
the ideas behind the system.
I have noticed recent items in sci.virtual-worlds from people
interested in architecture and so on, so I thought that perhaps
people might like to read about my ideas and perhaps, who knows,
those interested in architecture might like to think about how it
could all be realized using virtual world technology.
This is the text file version of the text that appears when using
the comet environment in response to using the command office and
the command ask subsequently.
Welcome to the office of the COMET environment.
The office facility in this piece of software is intended for the
use of anyone who would like to contribute some 1456 software or
a file describing translation to the machine code of some
microprocessor.
If you are simply trying to use the comet environment with
whatever files happen to have been supplied along with it, then
you do not need to use the office.
Telesoftware is the invention that produces a remote access
interactive computer system by means of the unidirectional cyclic
broadcasting of software. No telephone line nor any return
information link is needed to the central broadcasting computer.
W. J. G. Overington has devised an Opportunity Creating
Infrastructure for Telesoftware to contain his ideas for the way
that he would like to see his invention used.
The aim is to be able to provide fee-free education by distance
teaching methods around the world. The idea is that software
would be repetitively broadcast on some of the teletext lines of
various direct broadcast satellite channels. The idea is that
the software would be provided, written in 1456 object code, or
in languages where there is also broadcast a compiler for that
language itself written in 1456 object code, by those users of
the system that were able and willing to do so. It is envisaged
that the software would be marshalled together by a specially
formed incorporated company and that that company would pay for
the broadcasting time used.
The company would gain advertising revenue from selling up to ten
per cent of the space in the telesoftware service for the
carrying of advertisements, such as video game programs to find
various varieties of a manufacturers products in a maze,
adventures with various products being mentioned, and so on.
Only acceptable products would be advertisable on this service.
The idea is that all educational software submitted to the
company would be accepted for broadcasting. A person submitting
software to the company would be issued with a token, a sort of
trading stamp issued by the company. Of the money earned by the
company, some would be used to provide merchandise to collectors
of the tokens. The exchange rate of tokens to real world money
would be able to float to its own level so that there would never
be any question of only a given quota of software being accepted
from software authors. The company would be first and foremost
an educational facility. The redemption merchandise would
include educational materials, such as textbooks and so on. The
magic ingredient of the idea is that one of the items offered
would be a share in the company itself. This would be the only
way for a share to be issued, except for literally but a few
shares issued directly for money in order that the company could
actually have officers to start off. These would only go to
people who had already deposited some software.
This is a far off dream, and may, in fact, remain but a dream.
Who knows?
Over the last few years I have, from time to time, as a leisure
activity been writing a sort of science fiction book, though I
would like to think that it would be regarded as a piece of
literature in the utopian tradition.
Two young men from the city of Florence visit a fictional, small
city state in Italy as part of their studies. The story is set in
the autumn of the year 1456 and during their visit they find out
about a new invention recently brought from Mainz in Germany. It
is a printing press. Later they go through a time warp and are
just over 540 years into the future where they visit the
Telesoftware Institute, which is a somewhat idealized version of
the possible company mentioned above. Both the fictional city
state and the Telesoftware Institute are characterized by tokens
that are only of value in dealings with the fictional issuer, and
the relation to real world money of the tokens is explored.
Certainly, I am hoping that my fictional work will influence the
real world. Only time will tell.
However, this software is being distributed around the world on
floppy discs and if anyone would like to send some 1456 software
to me I will marshall what I get up into, hopefully, a number of
library discs. There is no specially formed company, no tokens,
no redemption merchanise, no shares.
But there is the adventure of it all!
----
Supplementary note, not built into the comet system.
In August and September 1990 I extended the concept of the book
to describe a concept, for which I have coined the word
teleutopia, that I propose might have been used as a staging
point in the establishment of the fictional Telesoftware
Institute, which lies somewhere "in the near future".
It is, in reality, a way that I am developing as a practical
method of moving forward from the existing real world situation
towards a real life implementation of my ideas for a Telesoftware
Institute. It may not work, but I feel that it is worth a try.
A new concept in forming large software systems and its possible
application to virtual reality research.
I am developing a concept for which I have coined the word
teleutopia, that is "tel" plus "eutopia", (and thus pronounced
with five syllables, tel-eu-top-i-a, phonetically tel-yoo-tope-
ee-uh). I envisage a teleutopia as using the existing shareware
and the like mechanisms for distribution of software, but whereas
the software in any one "package" of shareware, is, if I
understand it correctly, usually written by one person or a group
of people working together at the same company, educational
institute or computer club, with a teleutopia the "package" is
formed by a gradual aggregation of files prepared by individuals
all over the world to quite detailed specifications. The
specification would, for any given teleutopia, be devised by the
person who originated that particular teleutopia.
I am not envisaging collections as general as "collections of
pascal programs" being aggregated together as teleutopiaware, but
items far more specific, such as, as a simple example, a videotex
system for PCs forming the starting point for a teleutopia and
designs for character sets, be they roman, greek, hebrew &c being
in the files that people around the world send in.
This is only a simple example, I feel that the concept of
teleutopias could have far reaching effects in the fields of
knowledge bases and open systems. Each teleutopia would then
have a possibly lengthy document specifying how contributions
should be prepared. Naturally, systems would need to have scope
to evolve, rather than being locked in for years to a
specification document that had become obsolescent.
I am researching methods as to how such teleutopian knowledge
bases could be restructured as items gradually aggregated to the
teleutopia. I am also looking at the legal matters.
Being also interested in virtual reality systems, and wishing to
work in applying virtual worlds technology to produce new ways of
presenting and analyzing knowledge, I am wondering whether an
initial attempt to see if a teleutopia is a workable proposition
might be tried in this field, using a sort of virtual reality,
just on a regular PC, without a helmet or goggles, as the way to
help one select what one wants from the knowledge base. That is,
the items in the knowledge base would be items of use to virtual
reality researchers.
It seems to me that as well as software, it might be possible to
gradually aggregate data files of objects of many kinds into such
a knowledge base. I feel that, although this approach may well,
in principle, reduce the unnecessary repetion of coding up
various objects by each research group, the practical effect will
be that each group will have available many more types of object
than if each group were having to prepare all its own data files.
An added bonus would be that people could refer to such objects
in communications, both over the net, on the telephone, in print,
and others wishing to try out their results for themselves would
be able to get copies of the objects from the teleutopian
knowledge base, a copy of which they might already have.
+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+
Will Overington
Department of Electrical, Electronic and Systems Engineering,
Coventry Polytechnic,
Priory Street,
Coventry CV1 5FB,
England.
+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+
Putting forward new ideas is like being a quarterback.
First of all you will loose a few yards by even starting the
play.
Then there will be people trying to put you down.
Sometimes it's best to hand the football to someone who is better
at running, sometimes it's best to forward pass in a controlled,
planned way, but at times, the only thing to do is just hurl it
up in the air in a long forward pass attempt, and hope that
someone out there catches it and RUNS!
+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+
Supplementary document on 1456 object code, in case anyone is
interested.
This document provides an introduction to writing software in
1456 object code.
An interesting feature of 1456 object code is that the actual
codes used as input to the comet program are the normal way of
writing 1456 object code. That is, although there is an
assembler equivalent, it is not regarded as the main way of
writing 1456 object code, as 1456 object code is designed for
ease of being directly written.
Consider the following assembler style language program. It is
not for any particular processor, but, if you have used
assemblers, you will probably recognize the general flavour of a
label field, which may be left empty, an operation code field and
a parameter field, which may or may not have anything in it,
depending upon the particular operation code.
START LOAD #3
ADD #2
STORE ALPHA
HALT
ALPHA DATA 0
For the avoidance of doubt, this program loads the immediate data
of value 3 into a register called 1456A, adds the immediate data
of value 2, stores the result in the data storage unit at the
label ALPHA and then halts.
Consider now rewriting the program so that there is not a
separate label field, but that instead there is a pseudo-
operation called LABEL, that generates no code, but merely
informs us where the label is located.
LABEL START
LOAD #3
ADD #2
STORE ALPHA
HALT
LABEL ALPHA
DATA 0
Consider now using numbers instead of names for labels. The
program can now be written as below.
LABEL 1
LOAD #3
ADD #2
STORE 2
HALT
LABEL 2
DATA 0
In most, possibly all, microprocessor assembly languages that I
have studied, the operation codes for LOAD IMMEDIATE and LOAD
FROM MEMORY are different, but which of these operation codes is
used in assembling any given use of a LOAD instruction is
determined by examining the parameter field, not the LOAD
instruction itself.
For example,
LOAD #$40
and
LOAD $40
respectively, and not, say,
LOAD# $40
and
LOADM $40
In 1456 object code, each operation code is either one letter, or
two characters, the first of which is ! (in speech "super").
There are 100 operation codes available, namely,
A .. N, P .. Z, a .. k, m .. z,
!A .. !N, !P .. !Z, !a .. !k, !m .. !z
The letters uppercase O and lowercase l are omitted in order to
avoid confusion between uppercase O and the figure 0 and between
lowercase l and figure 1.
The LOAD IMMEDIATE is w in 1456 object code and the LOAD FROM
MEMORY is W with the argument being a label number, in octal.
In 1456 object code there is also what I call software
punctuation. These are items that in an assembler language would
be called pseudo-operation codes. This software punctuation
consists of label identification, generation of data spaces and
so on. So we may convert our example to something approaching
1456 object code, though as we shall see, there are a few extra
steps yet.
: 1
w 3
p 2
S 2
H
: 2
/ 0
In order to avoid, when assembling the above, having to look
beyond the length of the last digit in the parameter, because one
does not know that it is the last digit of the parameter until
one has already looked beyond it, the order of the operation code
and its parameter, if any, are reversed. This means that a
parameter, which must be a number, in octal, is ended by the
operation code that uses that parameter.
We thus have the following.
1 :
3 w
2 p
2 S
H
2 :
0 /
We also convert all numbers to being in octal format, though, as
the numbers in this example are all of value less than 8, there
is not any observable difference in doing that here.
A space character and a return character have no significance in
the code thus produced, so it is perfectly acceptable to place it
in free format on as few or as many lines as is desired. We need
to add an = sign, to signify that that is the end of the program,
and we could then have,
1:3w2p2SH2:0/=
but that is somewhat confusing to a human, so it is conventional
to separate each operation by a space character, though it is
usual to omit the space after a : symbol, so as to reinforce the
fact that the : is but a label and is not assembled to give
output code of itself.
1:3w 2p 2S H 2:0/ =
In the above example, note that the figure 2 appears three times.
In the first usage it is immediate data, because p uses it as
immediate data; in the second usage it is the use of a label
address, because S uses it as a label address; in the third usage
it is the definition of label 2, because : is used to define a
label.
Comments can be included in 1456 object code between a *
character and a ; character.
MODULES IN 1456 OBJECT CODE
The 1456 object code system supports separate compilation of
modules in a program. This is performed by using a + character
to signify the end of the module. Compilation of a 1456 object
code program is by two pass assembly. When a module is
separately compiled, both passes of that module are performed
before the first pass of the next module is started. This means
that any label address may be used locally within two or more
different modules without conflict. Only label addresses that
need to be referenced from outside the module need be chosen to
avoid conflict. A practice that is used is that label addresses
in the range 1 to 77 octal may be freely used as local labels
within a module and that higher numbers are allocated to external
entry points to modules. Labels in the range 100 to 177 octal
are for your own module library.
-- esz001@cck.coventry.ac.uk (Will Overington) (04/26/91)
Actually, I was thinking last night, and have come in this morning with the intention, of actually trying to get something going along the lines of a Teleutopia Of Virtual Reality Objects and working out how I should do it. My initial thoughts are for triple coordinates from 0 to 999999999 in each direction, that is, a nice round number of points compatible with easy, don't worry about a sign bit, numbers that can fit within a 32 bit word; in particular within a pascal longint type. This huge data size will enable one to build up detailed objects by scaling and adding. For example, a renaissance villa could have fancy column capitals added onto the top of each column by scaling down a design for a column capital and adding in copies translated to various locations, and so on. In my research projects on the restructuring of knowledge bases I have devised a system whereby software and data can be entwined together by using a language based on a language (alcor) that I designed a few years ago, which was itself based on forth. The method is that each software word starts with a triple letter, for example zzzif zzzthen zzzelseif and so on. The zzz words are fixed in the language, but fff words are user defined for fields within a relational database structure, for example fffquantity. This means that field lengths do not need to be fixed. I have it in mind to extend this concept for the files for the objects, using vvv as the triple key and words like vvvx vvvy vvvz and so on. This will give scope for files to be built that could be treated almost as data files by fairly simple software, yet be obeyed by something a bit more powerful. For example, commands such as vvvfill and so on, whatever that is defined as meaning when I think it out fully. :-) Incidentally, while writing, can I mention a few other points. I have not read all of each of the items, but on the matter of floating point numbers being needed or used for rotating objects in space, I was reminded that a lot of early forth stuff avoided floating point operations and instead preferred to do things like integer multiply by an integer and then integer divide by some large number. Could this be an approach for virtual reality systems, bearing in mind that eventually one needs to end up with integers in order to light up pixels, no matter how detailed a display system one has available. Perhaps things like taking care to avoid accumulating rounding errors need to be taken into account, whether using integers or floating point, for example, if one rotates 40 degrees and then wishes to rotate 25 degrees further on, maybe one should go back to the original and rotate that 65 degrees, rather than rotating the already rotated design a further 25 degrees. I am hoping that, if I can get this teleutopia going, then it will attract not only everyday objects but also will be treated as a medium for original art. There could be designing something on paper and putting it into the required format, but there could also be the concept of the person who wrote in sci.virtual-worlds of working using a helmet to create an object in some virtual material. Did that person suggest, or did I imagine, this as a sort of fluorescent green weightless clay. I am wondering, should someone be able to create a piece of art in this way, how it could be saved into a machine readable form so that it could be sent over the net and someone elsewhere be able to have a copy of the art object. Will Overington +-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+ Putting forward new ideas is like being a quarterback. First of all you will loose a few yards by even starting the play. Then there will be people trying to put you down. Sometimes it's best to hand the football to someone who is better at running, sometimes it's best to forward pass in a controlled, planned way, but at times, the only thing to do is just hurl it up in the air in a long forward pass attempt, and hope that someone out there catches it and RUNS! +-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+-*-+ --
lance@motcsd.csd.mot.com (lance.norskog) (04/27/91)
About the information publishing part: publishing data to subscribers and getting paid will involve some level of encryption technology. This is available today, and if you believe people in sci.crypt, it's trustworthy. The comm broadcast portion is called UseNet and has already been debugged, mostly. A production version of UseNet would not require a trained hacker at each node. It's close, but it's not there yet. There are a few other interesting protocols in this area: IRC, for example, is a worldwide Internet CB-style chat program (quite a trick). About the 1456 part: performance doesn't matter in software. Functionality matters. Programmers are more productive in languages higher-level language than 1456. Also, the more abstract the language, the smaller the code (usually). This is a big win for broadcasting programs on any comm line with less bandwidth than fiber optic. The current wave in making cheaper faster computing is RISC, and picking a CISC object code would have been a bad idea. The next wave will be parallel (2-16 processor) computing. A "dissemination" language should be carefully designed for efficient parallel execution, and the programmer's monoprocessor workstation should include a parallel simulator to ensure that software will work well on a subscriber's parallel machine. Lance Norskog