*start*
03115 00024 US
Date: 9 June 1982 9:37 am PDT (Wednesday)
From: Stewart.PA
Subject: Voice on the Arpa Wideband net
To: VoiceInterest↑.pa
cc: Stewart
Reply-To: Stewart
From the MAY INTERNET MONTHLY REPORT
WIDEBAND PROJECT
ISI has been participating in the Wideband Satellite
program along with Lincoln and SRI, but progress reports
have not previously been included in this forum.
One aspect of our work which has an internetting flavor is
an interface for voice traffic between the commercial
Switched Telephone Network (STN) and the packet internet.
The STNI is single card which can operate in several
environments; the most common application is in the Lincoln
PVT where it plugs in place of the PCM card. STNIs at ISI,
LL and SRI will allow the Wideband Net to be used as a
trunk for calls among normal telephones in the vicinity of
the three sites. The STNI provides this function by
plugging into a telephone line on a PBX or central
exchange. It is accessed by a call from any telephone, and
then it interprets Touch-Tones commands to establish a
connection across the packet network to another voice
terminal. If that voice terminal has an STNI connected, the
remote STNI is instructed "pick up" its phone line and dial
the desired number within the vicinity of the remote site.
Protocols have been implemented to allow a user to route
the call manually through the packet network, or to simply
give the area code an number of the destination and have
the routing determined automatically (for the limited set
of areas).
Recent work on the STNI includes the addition of three
important new functions:
- DTMF (Touch-Tone) generation for dialing out of the
STNI: Dialing was previously done with dial pulses for
compatibility with older systems. The tone dialing was
added entirely in software by playing canned tones
through the on-board PCM codec.
- Dial-tone detector: It is difficult for the STNI to
detect when a telephone connection to it is hung up by
the other end. The best clue is that the central
exchange will time out the idle line after a short
interval and play a dial-tone to the STNI. A "dial-tone"
detector has been implemented in software to watch for
constant-amplitude input above a fairly high threshold
for at least 8 seconds. The detector is insensitive to
the dial-tone frequency, which may vary among exchanges.
- Serial vocoder interface: A protocol standard is being
defined by the network speech community for interfacing
low-rate vocoders, such as LPC, using an asynchronous
serial channel. It is now possible to connect such a
vocoder to the STNI through an RS-232 channel on the
board. The STNI also provides analog connections to the
phone line which can be used by the vocoder if desired.
Steve Casner
*start*
00962 00024 US
Date: 9-Jun-82 10:46:15 PDT (Wednesday)
From: Fisher.ES
Subject: Re: Voice on the Arpa Wideband net
To: Stewart.PA
cc: Irby.pa, Verplank.pa, DaveSmith.pa, Fisher.es
Reply-To: Irby.pa, Verplank.pa, DaveSmith.pa, Fisher.es
I'm assuming everone saw the message to VoiceInterest↑.pa sent by Larry.
Having previously worked at ISI on their voice efforts, I arranged a demo with Steve Casner along with the folks on the cc to see a demonstration of the Linear Predictive Coding (LPC) implementation and the local STNI hardware about 6-9 months ago at ISI. This progress report confirms the progress and general direction that they were pursuing at the time of that last meeting.
Maybe after Exxon purchases Xerox, ha ha, after all their other dirt-ball companies fail; maybe several Ethernet local networsk connected by satellite link(s) providing voice and data support will be one of those fun projects we'll all get to work on.
-- Bill
*start*
00973 00024 US
Date: 11 June 1982 10:09 am PDT (Friday)
From: ornstein.PA
Subject: Sara Papazian
To: Stewart, Swinehart, Taft, Boggs, Schroeder, Dalal
cc: Taylor, ornstein
I got a call from Ms. Sara Papazian who has done Ethernet work at Olivetti. She
was pointed my way by an old BBN friend who has been doing some work with
Olivetti. She has recently moved to Berkeley where her husband is (I believe)
teaching at UCB - and she is looking for suitable employment. She has an MS
from Cal. Tech. and PhD from Pisa (both with honors) and sounds crisp over the
phone.
I am sending each of you a copy of her resume and have asked my secretary to
contact all of you and arrange an informal lunch gathering (here) some day of
mutual convenience next week so we can chat with her, see if she is suitable for
SDD, CSL, or whatever. It isn't necessary that all of us be there - just some
reasonable subset - so if you are overloaded, please beg off.
Thanks,
Severo
*start*
00503 00024 US
Date: 11 June 1982 1:39 pm PDT (Friday)
From: ornstein.PA
Subject: SLC parts
To: Stewart
cc: VoiceProject↑, ornstein
Reply-To: ornstein
I talked to Bob Markle and he says Vir Dhaka has tons of SLC parts and there's
absolutely no problem in our getting them. They sell to the Lotus folks for $40
each (or so) but Markle indicated that if we didn't have money for them, Vir
might just give them to us.
The WD2001 (Encryption chip) is next on my list to verify availability.
S.
*start*
01294 00024 US
Date: 17 June 1982 11:24 am PDT (Thursday)
From: ornstein.PA
Subject: Work Statement for Duvall
To: Stewart, Swinehart
cc: ornstein
How does the following look as a work statement for Duvall? These are
essentially the items that he bought into for a week's work.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Note: The references to work items are abbreviated here. They refer to
corresponding items discussed in detail in earlier messages between Duvall,
Ornstein, and Swinehart.
1. Incorporate into sources those fixes already made by Swinehart and Stewart
regarding space limitations and D-machine compatibility
2. Modify the compiler to accept "&P" where P is a procedure and "&P" yields
the address of that procedure
3. Change LDR86 to work with large programs
4. Fix the following code-generation problems
a) direct memory operations on structure fields
b) jump range overflow problem
c) problems with case statements
d) Group Directuive problem
e) "AH/AL" bug
f) forward reference bug
g) move immediate to memory bug
5. Produce a loader error file
6. Modify compiler error file behavior
7. Add "Sys.Bk" facility
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
S.
*start*
00573 00024 US
Date: 17 June 1982 11:45 am PDT (Thursday)
From: Stewart.PA
Subject: Re: Work Statement for Duvall
In-reply-to: ornstein's message of 17 June 1982 11:24 am PDT (Thursday)
To: VoiceProject↑
I don't care particularly if
e) "AH/AL" bug
f) forward reference bug
g) move immediate to memory bug
get fixed or not.
The "d) Group Directuive problem" is one of the "fixes already made by
patching."
We can survive without "a) direct memory operations on structure fields,"
although they would be nice because less code would be generated.
-Larry
*start*
04302 00024 US
Date: 17 June 1982 5:03 pm PDT (Thursday)
From: ornstein.PA
Subject: Etherphone Hardware Report
To: VoiceProject↑
cc: Dalal, Levin, McCreight, Mitchell, Lampson, Ornstein, Schroeder, Taft,
Thacker
Reply-To: ornstein
1. We hope to demonstrate simple phone calls using the Multibus prototypes and
the Etherphone Server in early July.
2. The digital board design is "finished" (the last *known* bug has been fixed).
It just fits nicely on a Multibus card. There's some flakiness with the present
prototype, but evidence suggests it's just a flakey chip, bad connection, or
something peculiar to this particular board. Larry is going to make touch-ups to
the drawings and Monday morning Rosemary will do the re-work. If it then
seems OK, we will proceed to build two more copies - on Multibus cards.
3. Mike has found a reasonable looking power supply for only $83. He is going
to test it under load. The power consumption of our little box may be on the edge
of what can be convection cooled. I hope we don't need a fan.
4. Mike says that the break-even cost between making more stitchweld Multibus
versions and a proper PC version (wherein the connectors could be properly
mounted, etc.) is about ten units. So it seems we should go for the PC versions -
after the three Multibus prototypes are proved out. Just how many PC versions
we will want to build is unclear. Ordering the raw (unpopulated) boards is quite
cheap after the one-time layout etc. is paid for. So probably ordering 50 will not
be a great deal more expensive than ordering say10. We could order the parts to
populate most of them later if money is short or we want to wait to gain
confidence. My personal feeling is that populating 10 PC ones at first is about
right.
5. Larry, Mike and I all agree we should socket all the chips. The total cost is on
the order of $50 per board and makes debugging much easier.
6. I propose that the way we handle debugging is not to invest large amounts of
Larry's time in providing diagnostics and training. We will probably really want
to build about 10 at first and suggest that what we do is provide the technicians
with a known good board and a known good chip set. They can then verify
boards by plugging in the good chip set and running a full-whammie exerciser
(probably the "operational" program) - and checking with Larry when something
doesn't work. Once they thus obtain good boards, they can then plug in
unknown chip sets doing binary search for bad chips (probably Larry will be
able to help them do somewhat better than just binary-search). The point is to
minimize Larry's investment right now in preparing a good test environment -
even at the expense of somewhat less efficient debugging. That way the total
investment of Larry's time in debugging (even including having to help with
hard cases) is probably smaller - so long as the total number of boards is modest
- like 10 or so. By the time we've got that far - it will be more obvious what to
do about debugging larger numbers.
7. We plan simply to plug all three Multibus prototypes into the same Multibus
chassis (for power). Larry has a small "analog board" (a mini version of the real
thing with connections only to handset and Codec and filter - but without
telewall interface or analog switching, or spkr. or mike. etc - i.e. none of the
fancies). We are going to build a triple version of this mini "analog board" to go
with the three prototype phones. That will enable us to do some testing.
8. In the fullness of time, Larry will finish the design of the analog board. We
are able to adopt a fair amount of the logic from Belleville's design, but we are
going to use a 4-wire telephone (instead of the 2-wire) so that part of the design
needs to be modified. It is expected that the analong board will occupy roughly
1/3 the area of the digital board. A third board, the "Locator" board as yet
undesigned and un-thought out, might require roughly 2/3 of the digital bord
area. Our notion thus is to have two layers, one made up of the digital board and
the other of the Analog board and Locator board - perhaps mounted on standoffs
from the digital board. The Locator board can be added later (or not). There are
lots of leftover I/O signals available for dealing with it.
Severo
*start*
01186 00024 US
Date: 17 June 1982 5:13 pm PDT (Thursday)
From: ornstein.PA
Subject: 12 volt (Dorado) Transceivers
To: Clark
cc: VoiceProject↑, ornstein
Reply-To: ornstein
Larry,
I wonder if we could borrow two Dorado transceivers from the Garage for a
couple of months? They are for the Etherphone project. Eventually we will need
to order one per etherphone but I am reluctant to place a sizeable order until we
verify that things are working right. We have borrowed one from Dave Boggs
and the first prototype seems to work fine with it. The next stage is that we're
building two more Multibus based copies and want to test them in a tiny system
- hence the desire for two more transceivers. When all that works, we plan to
convert the board to PC form and at that point we should order however many
transceivers we're going to need - and will then return the borrowed ones.
We would want to replace the "stinger" of the borrowed transceivers with a BNC
connector (as we have on the one we've presently got). That's a trivial thing and
we would of course put them back to their original state when done.
Let me know if this is feasible or a problem.
Thanks,
Severo
*start*
00431 00024 US
Date: 18 June 1982 8:58 am PDT (Friday)
From: Swinehart.PA
Subject: Re: 12 volt (Dorado) Transceivers
In-reply-to: Your message of 17 June 1982 5:13 pm PDT (Thursday)
To: ornstein
cc: Stewart, Swinehart
Boggs yesterday showed me a prototype for a 4 way Ethernet multiplexor (4
controllers, one transceiver.) Assuming it will work with our configuration, is
that an option to using multiple transceivers?
*start*
00331 00024 US
Date: 20 Jun 1982 13:40 PDT
From: Stewart at PARC-MAXC
Subject: Re: 8086 cross-assembler
In-reply-to: Sumit.Bandyopadhyay at Super-Vaxen's message of 7 Jun 1982
23:46:45-EDT
To: Feldman at Sumex-Aim
cc: Stewart
Can you let me know if you find one? -Larry
I'm interested in c compilers and loaders too.
*start*
00863 00024 US
Date: 21 June 1982 9:49 am PDT (Monday)
From: ornstein.PA
Subject: Multiplexing Ethernet Controllers
To: Boggs
cc: VoiceProject↑
Reply-To: ornstein
David,
We are in the process of making up two more copies of the Etherphone hardware
(so that we'll have a total of three prototypes to work with in various ways).
We're not going to distribute them physically, just plug them all into the same
multibus chassis (for power only). So in theory we need a couple more
transceivers (we use the 12 volt Dorado type). I asked Larry Clark about maybe
borrowing a couple ahead against future Dorados, but Dan says:
"Boggs yesterday showed me a prototype for a 4 way Ethernet multiplexor (4
controllers, one transceiver.) Assuming it will work with our configuration, is
that an alternative option to using multiple transceivers?"
Comments?
S.
*start*
00399 00024 US
Date: 21 June 1982 10:25 am PDT (Monday)
From: ornstein.PA
Subject: Transceivers
To: Stewart
cc: VoiceProject↑
Reply-To: ornstein
Since sending the last msg. about maybe using Boggs' multiplexer, I got a
confirmation that we are getting a couple of transceivers on loan from the
Garage. I would assume that is better, simpler, etc. and thus the way to go. Do
you agree?
S.
*start*
00418 00024 US
Date: 21 June 1982 10:43 am PDT (Monday)
From: TonyWest.PA
Subject: Re: Transceivers
In-reply-to: Your message of 21 June 1982 10:25 am PDT (Monday)
To: Ornstein
cc: Stewart, Boggs
I think you should still get Boggs to show you his latest widget -- I think you might be better off with one of those rather than separate Dorado Transceivers. I saw one last week and he did a neat job...
Tony
*start*
00340 00024 US
Date: 21 June 1982 10:45 am PDT (Monday)
From: Stewart.PA
Subject: Re: Transceivers
In-reply-to: Your message of 21 June 1982 10:25 am PDT (Monday)
To: ornstein
cc: VoiceProject↑
Transceivers are slightly better. I imagine Bogg's transceiver mux is a 15 volt
type. (Although it may run from wall power.)
-Larry
*start*
01288 00024 US
Date: 21 June 1982 10:46 am PDT (Monday)
From: TonyWest.PA
Subject: Worth a look?
To: Stewart
at this compiler?
---------------------------
Mail-from: Arpanet host SRI-CSL rcvd at 19-JUN-82 0826-PDT
Mail-from: ARPANET host SRI-UNIX rcvd at 7-Jun-82 1042-PDT
Date: 7 Jun 1982 at 1224-CDT
From: Bill Lee <lee@utexas-11>
Subject: Reply to: compiler front-ends wanted
To: menlo70!sri-unix!hplabs!jf at Berkeley
cc: Unix-Wizards at sri-unix
Via: Utexas-11.ArpaNet; 7 Jun 82 10:37-PDT
Remailed-date: 19 Jun 1982 0624-PDT
Remailed-from: the tty of Geoffrey S. Goodfellow <Geoff at SRI-CSL>
Remailed-to: Unix-Wizards: ;
We have a C compiler that we wrote from the ground up without using any
Bell Labs code. We used lex and yacc to produce the scanner and parser. It
conforms to the description of C in "The C Programming Language" by Kernighan
and Ritchie. It is currently being distributed as an experimental compiler.
There are some licensing considerations involved with the compiler but they
shouldn't be a problem if you are only interested in the front-end. You or
anyone else interested should feel free to call me and discuss it.
Bill Lee
University of Texas at Austin
(512) 471-3241
-------
------------------------------------------------------------
*start*
04332 00024 US
Date: 21 Jun 1982 17:51 PDT
From: TonyWest at PARC-MAXC
Subject: TRIPOS Software Distribution Tape
To: GC @ XNET
cc: TonyWest, Stewart
Please forward this message to:
Telex number 81240 CAMSPL G for:
Telex number 81240 CAMSPL G for:
Telex number 81240 CAMSPL G for:
To: Dr. Martin Richards, Tel: 223-352435
Computer Laboratory
Cambridge University
Corn Exchange Street
Cambridge CB2 3QG
England
From: Anthony West
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto
California 94304
USA
----------------------------------------
Dear Martin,
Since our last conversation about Tripos, our project which
would have been a client for it has taken a turn in a new
direction. As we have not yet received the tape, we would
like to cancel our order.
I guess the right way to do this is for you to tear up our purchase
requisition and for us to tear up your invoice. I will check with
our purchasing department to see if we actually paid the University
any money yet. Please let me know if this would be OK with you.
I extracted the relevant part of the message I sent you on
Dec 2 1981 ordering the tape, which I hope will give you
sufficient information to trace it with your accounting folks.
Tony
-----
Date: 2 Dec 1981 17:55 PST
From: TonyWest at PARC-MAXC
Subject: TRIPOS Software Distribution Tape
To: GC @ XNET
cc: TonyWest, Stewart
.....(stuff deleted).....
Based on out last telephone discussion, I have arranged for
an official Xerox Purchase Order to be sent to you, ordering
one "Tripos Distribution Tape".
The order assumes that the cost of the distribution tape (note,
this means the cost of preparing the tape etc.) is 350 pounds.
I stress that I am operating on the basis that the money is for
the tape and not for the software. That way, both we and you
avoid the potential problems associated with the Computer
Laboratory being cast in the role of "Software Vendor".
The normal practice is that, after receiving the order, you
would send the tape and an invoice for this amount.
However, it is important for Xerox to be enabled to send you
the money before the end of December, since the expense
budget concerned lapses then. Since we are all friends, I
would like to ask you if we can cut corners in the following
way:
I hereby notify you that the Official Xerox Purchase Order
Number is M53980, I repeat M53980. Please could you send off
to me an invoice which refers to "your order number M53980"
for the sum of 350 pounds, as if you were sending it with
the shipment of the tape. When the invoice arrives, Xerox
can send you the cheque (in sterling) more-or-less immediately.
Since this is the urgent part, we have decoupled it from the
actual delivery of the tape, which may follow at your
convenience. As we discussed in our last telephone
conversation, please could you include the following on the
tape:
* BCPL Compiler for 8086 and for 68000
* TRIPOS Kernel for 8086 and 68000
* Tripos Sources of both 8086 and 68000 implementations
* As much documentation as possible
* Assemblers for 8086 and 68000 (if you have them)
* Sources for the latest version of the filesystem
* Anything else you might think is useful, for
example, the source code of the little object module
linker program used to assemble separately compiled
code modules together for the 68000, and the utility
which converts them into Motorola S-records.
Please consider the above to be a wish-list, I would not
want you to send us anything which is not in the public
domain, or which you are not authorised to give to us.
The understanding I have is that, unlike IBM, Xerox is not
particularly interested in maintaining any rights to the
software developed here under TRIPOS. Thus, in the (at the
moment, seemingly unlikely) eventuality that we generate
some code which might benefit either of you, there would be
no problem about sending it to you.
.....(more stuff deleted).....
----------------------------------------
You may reply by TELEX to 22921 HQ RX in LONDON
and request that the message be forwarded to:
TonyWest
SAC: RD
Xerox Palo Alto Research Center, USA
NB: Please do not put a space between Tony and West
or else the message will not be forwarded correctly to me.
------------------------------------------------------------
*start*
00420 00024 US
Date: 22 June 1982 11:30 am PDT (Tuesday)
From: ornstein.PA
Subject: Voice Money for DuVall
To: Mitchell
cc: VoiceProject↑
Reply-To: ornstein
Jim,
We've just negotiated for Bill DuVall to make some fixes and additions to the his
C-compiler that we're using to create Etherphone (8088) code. Cost will be $2500.
It's arranged as a consultant. Lemme know if you need more information.
Severo
*start*
02905 00024 US
Date: 23-Jun-82 17:25:13 PDT (Wednesday)
From: Verplank.pa
Subject: References to voice segments
To: Swinehart, Stewart, Birrell, Schroeder
cc: Dalal, Trigoboff, Redell, Verplank, Kabcenell.es, Alfvin.es
We need some advice on how to keep voice on a file server while shipping around documents which contain references to it.
Here are some alternatives. Which do you like? What have we left out? Are there better alternatives?
0. No References.
The voice data is stored with the document. If I don't have space on my machine I can't retrieve the document.
1. Auto-cache.
Here the user's illusion is the same as with 0, except the system does its best to find storage as close to the user as possible.
a. When storing voice, it is first buffered on my workstation disc, then forwarded to my "voice server".
b. When opening a document to read it, the referenced voice segments are brought to the local disc for instant access.
c. The mail system creates as many copies of the message as necessary, keeping reference counts, deleting the cached voice when the reference count goes to zero.
2. Pre-allocated file-server storage.
Each user who can store voice is allocated space on his local file-server.
a. When storing, the voice goes directly to the fileserver.
b. When playing, the voice comes directly from the fileserver.
c1. When mailing, only the references are forwarded
-or-
c2. When mailing the
3. User-choice Reference/Real.
When creating/copying the user always has the option of making the voice real (data with document) or reference (data on user's file server)
a. When storing, the choice would ordinarily be "make reference" in which case the data goes directly to my "voice server"; if I was expecting to edit it I might "make real" during recording (or after!) so that the data would be on my workstation for quick response, etc.
b. When playing, the voice comes directly from the server if it's a reference, directly from the workstation if it's real.
c. When mailing, if I'm smart, I only send documents with references in them. The recipient has the choice of leaving them as references or "making them real"; the recipient's copy of the voice goes on the recipients workstation or local "voice server".
The worst problem here seems to be the case where I, in Palo Alto, send voice in a message to someone in, say, El Segundo. Either, 0) the recipeint waits a long time before hearing anything (listen slowly?) or 1) I forward the voice to some server in El Segundo, or 2) the mail system does the forwarding or 3) the recipient does the forwarding, or 4) someone dials the telephone to hear the voice message. or 5) we don't use references. Any other suggestions?
The other main problem is whether to keep reference counts and what to do about garbage collection, etc.
Where is the best source of wisdom on such issues?
--Bill
*start*
00361 00024 US
Date: 24 June 1982 11:36 am PDT (Thursday)
From: ornstein.PA
Subject: Dorado Ethernet Transceivers
To: Henning
cc: Clark, ornstein, VoiceProject↑
Reply-To: ornstein
This is to acknowledge receipt today of two (2) Dorado Ethernet Transceivers -
on loan from the Garage to the Voice Project - for which we thank you most
kindly.
Severo
*start*
00924 00024 US
Date: 24 June 1982 3:39 pm PDT (Thursday)
From: ornstein.PA
Subject: Simple Analog Board
To: Stewart
cc: VoiceProject↑, ornstein
Reply-To: ornstein
I have made Sil dwgs. for the simple analog setup (copying your little board
three times) which I have if you want a set. Mike is busy making it plus cables.
He'll probably be finished by the time you read this. I verified all dwgs. against
your actual board. You don't seem to have been totally compulsive about keeping
AGND and GND separate (except for the joint) but I explained the desire to Mike
and it's manifest on the dwgs.
Rosemary is wiring up two more ETT boards. Probably finish Monday - at least
with one of them.
Hartnet says that -ES means Engineering Sample and that the -2's we're getting
are the latest mask. The price he had "quoted" of $18 each was not upheld by the
company and they're actually costing us $40 each. Ouch!
S.
*start*
02526 00024 US
Date: 25 June 1982 9:46 am PDT (Friday)
From: Swinehart.PA
Subject: Re: References to voice segments
In-reply-to: Verplank's message of 23-Jun-82 17:25:13 PDT (Wednesday)
To: Verplank
cc: VoiceProject↑, Birrell, Schroeder, Dalal, Trigoboff, Redell, Kabcenell.es,
Alfvin.es
Reply-To: Swinehart
I guess my preference is for something close to (2) -- Pre-allocated file-server
storage. (Preference is reflected in our current design, so it had better remain
my preference, right?) By pre-allocation I assume you mean that each user is
given a quota, not that the space itself is pre-allocated.
Severo tells a story of an experimental system (at BBN?) in which the voice is
stored with the data. Messages took minutes to arrive. I think you'd get that
kind of behavior in any system that tried to ship the voice around with the
messages; and recording directly to a file server seems like it's going to work
fine. Of course, if the recipient is distant, the voice file will have to be copied
and cached remotely, before it can be played. In some organizations, the
statistics of this may make the two basic approaches essentially equivalent.
Probably the transfer of the voice wants to wait until the recipient wants to hear
it -- that way, in an annotated document, the recipient has the option of
choosing not to bother with the voice, saving time and money. (Heresy!!)
Our view on editing is that only pointer structures to voice segments will be
manipulated by the editor -- like Bravo piece tables, or whatever. These pointer
structures will be stored with the document, or at least not in the voice file
system. The only access to the voice server will be to record new segments, to
play previous segments (starting and ending on specified time boundaries), and
to delete entire voice files, or perhaps segments thereof. This will work unless
the editor wants to be real specific about the kind of "voice envelope" that it
displays on the screen. Even there, asking the voice server for envelope
information sounds like a more winning scheme than shipping the bits.
Right now this is just opinion. In a few months, we plan to have at least a few
results to back up or refute the opinion.
The BSTJ April (?) issue apparently has a description of the Bell Labs voice
storage system -- the one they field-tested in Philadelphia. Now AT&T has to
convince the FCC that it's OK to deploy it in the way that they want to, so
there's still time to beat the Christmas rush.
Dan Swinehart
*start*
00529 00024 US
Date: 26 June 1982 12:29 pm PDT (Saturday)
From: Stewart.PA
Subject: Re: C feature
In-reply-to: Your message of 25 June 1982 10:28 am PDT (Friday)
To: Swinehart
cc: Stewart
I noticed that a while ago. It is one some of my gotchas lists. I think, however,
that only the calling code thinks the result is in AL, the called code returns the
result in BL (X) as always..
Some of my early ASM routines returned the same value in both registers, just
in case any callers had declared the routine char xxx.
*start*
01086 00024 US
Date: 25 June 1982 11:22 am PDT (Friday)
From: TonyWest.PA
Subject: TRIPOS Tape
To: Stewart.PA
cc: VoiceProject↑.PA
Reply-To: TonyWest.PA
Larry:
as you know, on Tuesday I sent off a telex to Martin Richards asking to cancel our order for his Tripos tape.
Well, in accordance with Murphy's law, doing that provoked the tape into arriving yesterday (it's taken 6 months) with the amazing amount of 27.48 pounds of postage on the envelope!
I tried to call Martin, and succeeded in tracking him down at CERN. He said that he was going to be sending us an invoice, and I am not sure that it would be a good idea to try to back out of the agreement at this point. He seems to have put in a certain amount of work to get all of the material together for us.
(FYI: The order is worth $700 of expense money).
I think we should meet and discuss this.
The tape contains a lot of Tripos source code (for 8086 or 68000), and the latest 68000 system, including vast amounts of documentation.
I will notify Peter Deutsch of this, in case he has any interest.
Tony
*start*
00659 00024 US
Date: 25 June 1982 11:34 am PDT (Friday)
From: TonyWest.PA
Subject: TRIPOS OS
To: Deutsch
cc: Stewart
Peter,
We have received from Cambridge University a tape of the TRIPOS Portable Operating System.
I have quite a bit of experience with the system, which is a small, message-passing kernel and a load of utilities all written in BCPL.
The port that I have is for the 68000, and I wonder if you have any interest in it?
When I used the system, I was very impressed by its responsiveness, particularly the speed of the BCPL compiler, which typically compiles small programs in seconds (<10).
Documentation also available.
Tony
*start*
00359 00024 US
Date: 25 June 1982 10:28 am PDT (Friday)
From: Swinehart.PA
Subject: C feature
To: Stewart
cc: Swinehart
Turns out that character functions return their values in AL. So lc() has to be
declared as int lc(), etc., for it to work right. I guess this is so that CBW can
immediately follow a call to a character function, etc.
ho ho.
*start*
00296 00024 US
Date: 27 June 1982 2:20 pm PDT (Sunday)
From: swinehart.PA
Subject: Re: C feature
In-reply-to: Your message of 26 June 1982 12:29 pm PDT (Saturday)
To: Stewart
cc: Swinehart
No, a compiled char procedure returns its results in AL. At least the test version
I made did.
*start*
00637 00024 US
Date: 28 June 1982 3:42 pm PDT (Monday)
From: ornstein.PA
Subject: Re: IFIP working conference on interconnected high-performance
personal computing systems
In-reply-to: Your message of 28 June 1982 3:32 pm EDT (Monday)
To: VoiceProject↑
cc: ornstein
Reply-To: ornstein
I think we should seriously consider submitting a paper on the Etherphone and
associates. It seems like a natural and I doubt if there will be any competition
worthy of the name. It'll be a fair amount of work to write such a paper - by
December - and have it be creditable - but the midnight sun, I ask you. . . . . .
What think ye?
S.
*start*
01392 00024 US
Date: 30 June 1982 4:59 pm PDT (Wednesday)
From: ornstein.PA
Subject: Parts Cost for Etherphone
To: Stewart, Swinehart
cc: VoiceProject↑, Overton
Reply-To: ornstein
Mike and I just sat down and made a very rough overall cut as follows:
Digital board $50
Analog Board $50
IC's for Digital board $320
Sockets for Digital board $50
IC's for Analog Board $150
Power Supply $80
Connectors (and cables) $50
Transceiver $100
Mike and Spkr $30
Handset $50
Metalwork $50
TOTAL $980
Pretty close to our $1K original guess - but then this is something of a guess too.
IC parts are based on the real stuff for Digital board and the expensive items on
the Analog board. Is my wild guess at the Handset cost reasonable? Other items -
e.g. mike and spkr?
We have $20K of capital we can spend. Thought is to spend as much as
reasonable of it now (to beat later possible cuts). The layout and other onetime
charges can be expensed, no problem. So I suggest we order parts (IC's, sockets,
transceivers, connectors, everything we're reasonably sure of that we'll use -
maybe even handsets if we can settle on reasonable ones) for 15 units now. Plan
to build at least 10 units - perhaps 12 - depending on how it works out in detail.
If our cost estimate is right, that should leave us $5K in our capital account for
buffer. How does that seem?
S.
*start*
01099 00024 US
Date: 29 June 1982 10:14 am PDT (Tuesday)
From: ornstein.PA
Subject: Re: IFIP working conference on interconnected high-performance
To: VoiceProject↑
Reply-To: ornstein
Date: 28 June 1982 4:08 pm PDT (Monday)
From: ornstein.PA
Subject: Re: IFIP working conference on interconnected high-performance
personal computing systems
In-reply-to: Your message of 28 June 1982 3:32 pm EDT (Monday)
To: Lampson
cc: ornstein
Would an Etherphone paper be suitable? Would it preclude publication in a
wider forum later?
S.
---------------------------
Date: 28 June 1982 8:15 pm EDT (Monday)
From: Lampson.PA
Subject: Re: IFIP working conference on interconnected high-performance
personal computing systems
In-reply-to: Your message of 28 June 1982 4:08 pm PDT (Monday)
To: ornstein
Yes, I think it would be highly suitable. You would have to write it with a
reasonable proportion of different words, since North-Holland is definitely
considered a formal publication. But the content could be more or less the same.
------------------------------------------------------------
*start*
00459 00024 US
Date: 6 July 1982 5:14 pm PDT (Tuesday)
From: Swinehart.PA
Subject: DFs
To: Stewart
cc: Swinehart
Larkbase and LarkComm are new. I compiled those files whose .ASM's and
.DEC's didn't exist yet -- found typos in Signaller (harmless pointer mismatch
message) and Random, fixed same. New Pup.h and various communications
thingies.
Routing works, until we have to cache things. Time works. Pups work. On to
WSD and greater things.