*start*
00540 00024 US 
Date: 4 Jan. 1982 1:55 pm PST (Monday)
From: Stewart.PA
Subject: More on 2716s
To: Belleville
cc: Stewart

Roy Ogus tells me:

a)   As set up, the program that takes Intel Hex output and puts it in EPROM
does not handle 8086 style memories with the even bytes in one EPROM and
the odd bytes in another.

b)   You've used the program to generate 2716s for Cub.

Does this mean that you didn't use 16 bit wide ROM or that you didn't use quite
the same program as Roy's or that you have a conversion utility?

	-Larry

*start*
01316 00024 US 
Date:  5 JAN 1982 0906-PST
From: DAWSON
Subject: Re: Remote debugging etc.
To:   Stewart
cc:   DAWSON

In response to your message sent  23 Dec. 1981 2:31 pm PST (Wednesday)


Larry,
Why not use the Chat protocol?  This would require a fairly smart
kernel, able eg to examine and modify registers and memory locations
and interrogate I/O locations, but it's only about 8 K of code
(size of the Intel debugger).  In fact, you are welcome to the
Intel debugger sources (does all the above plus instruction disassembly
and setting breakpoints) if you don't already have them.  The RS232
part of them is very well proceduralized (is that a word?)
Of course this would mean downloading was a series of 'modify
memory location' commands (ie 
SW<ascii-segment>:<ascii-offset><CR><ascii-hex-word>[,<ascii-hex-word>]*
for a net overhead of about 50% over straight binary over the net,
but at 10 Mbps you should be able to afford that (unless you have VERY
bit programs.  Then at the debugging end you would put a little bit
of protocol 'on top of' the Chat protocol to make downloading
easier.  This would also allow you to Chat to your device from almost
any machine, not just one running some new protocol.  Questions welcomed.

John  (8*935*3147, Dawson.PA)

PS for bit programs read big programs.
*start*
00713 00024 US 
Date: 5 Jan. 1982 9:43 am PST (Tuesday)
From: Stewart.PA
Subject: Re: Remote debugging etc.
In-reply-to: Your message of 5 JAN 1982 0906-PST
To: DAWSON
cc: Stewart

Thanks for the info.  I'd be interested in the debugger sources, as all I have are
the ROMs and the listing.  I'd like at least to be able to modify its port addresses
etc.  Have you got assembler source or only PL/M?  I've got an assembler...

I've gotten ether downloading working now, a new protocol, sigh, but it works
well.  I didn't want to use the telnet protocol because it requires full ethernet
bytestreams, which take quite a bit of code to implement.  I wrote a very simple
one using packet exchanges.

	-Larry

*start*
00814 00024 US 
Date:  5 JAN 1982 1205-PST
From: DAWSON
Subject: Re: Remote debugging etc.
To:   Stewart
cc:   DAWSON

In response to your message sent  5 Jan. 1982 9:43 am PST (Tuesday)



The source I have is official Intel assembler.  I have it on a Intellec-readable
diskette, and in hardcopy form (about 6000? assembly instructions).  I have
recompiled and modified it, including the I/O stuff, so I could answer some
questions about it.  With a little work I could maybe get it on 1/2" tape --
how would you like it?    I take it you didn't like the Chat idea, which is
of course how the Intel downloader normally works.  Oh well.  Let me know
how you'd like the debugger source.  PS If you're interested you're welcome
to come by Versatec and see what we're doing (have done) with 8086 stuff.

John
*start*
00492 00024 US 
Date: 5 Jan. 1982 4:07 pm PST (Tuesday)
From: Stewart.PA
Subject: Re: Remote debugging etc.
In-reply-to: Your message of 5 JAN 1982 1205-PST
To: DAWSON
cc: Stewart

Yes I'm interested in the Intel assembler source.  It would have to be some form
that can get onto my Alto though.  1/2 inch tape would do.  There is a
possibility that SDD has hooked their MDS somehow to the world.  I'll check into
it.  I'll probably come by Versatec sometime, more later...

	-Larry

*start*
00896 00024 US 
Date: 5 Jan. 1982 5:04 pm PST (Tuesday)
From: NDSmith.PA
Subject: Digital voice files
To: Stewart.PA

Larry-

Can you help us with the following request? If so, please let me or Mike
(Trigoboff) know where and roughly what digital voice files you have. 

On another subject, we will have drawings of the PC boards (not the layouts)
next week (1/14/82).

On still another subject, I'd like to arrange to see your lab and hear a little bit
more about your research sometime. 

							Nancy

---------------------------

Date:  5-Jan-82 16:28:10 PST (Tuesday)
From: Trigoboff.PA
Subject: Digitized Voice File(s)
To: Belleville, NDSmith
cc: Verplank, Trigoboff

Do either of you know where I can find one or more digitized voice files of the
sort that might someday be produced by the voicebox?  Thanks ...

	Mike
------------------------------------------------------------

*start*
00566 00024 US 
Date: 5 Jan. 1982 6:37 pm PST (Tuesday)
From: Ogus.PA
Subject: Prom blowing information
To: Stewart
cc: Ornstein, Ogus

Larry,

Try this for starters:

[Iris]<Workstation>Tools>Prom>

	HowToBlowProms.text  -  documentation about blowing proms
	PromDoc.bravo  -  documentation about generating the binary-format
			proms (a little out of date in terms of the Mesa file names)
	PromSources.dm  - the Prom blower sources.

I still haven't found the correct Mesa config file yet.  Will keep looking.

Let me know if you have any questions.

Roy.
*start*
00552 00024 US 
Date:  5 JAN 1982 2210-PST
From: STEWART.PA
Subject: Voice files
To:   Trigoboff, NDSmith
cc:   Stewart

I don't have any voice files on tap, but one of the CSL Altos has
Auburn audio hardware and software capable of recording any
amount of the stuff to disk.  Probably the best thing to do is
for some of you to drop by.  I'll sow you how to use the stuff and
you can record as much as you want.  Might even lend you a complete
Auburn setup if you've got an Alto II and want to use it often.
I think we've got a spare.
	-Larry
*start*
00454 00024 US 
Date: 6 Jan. 1982 10:15 am PST (Wednesday)
From: Ornstein.PA
Subject: Re: Production Etherphones
In-reply-to: Your message of 2 Jan. 1982 3:24 pm PST (Saturday)
To: Thacker
cc: VoiceProject^
Reply-To: Ornstein

OK. I'll plan on us doing all the engineering and will try to have a reasonable
manufacturing "package" for the garage. You and I should talk about what that
should include but we're not quite ready for that yet.

S. 

*start*
00531 00024 US 
Date: 7 Jan. 1982 4:11 pm EST (Thursday)
From: ALLEN.WBST
Subject: Re: Please add these names...
In-reply-to: Stewart.PA's message of 1 Jan. 1982 4:33 pm PST (Friday)
To: Stewart.PA
cc: 

All changes were made except for the duplicate address for Dahlia2.  You can use
duplicate machine names, but not duplicate addresses. 

In the future, please use the form set up for network address changes etc.  If it
isn't stored on your file server, it is stored [erie]<forms>Laurel.NameRequest. 
Thank you.

Gail


*start*
03150 00024 US 
Date: 7 Jan. 1982 3:08 pm PST (Thursday)
From: Ornstein.PA
Subject: Belleville's Voice Box and the Etherphone
To: VoiceProject^
cc: Belleville, Overton

Larry and I went to talk to Bob to understand Whether, How, When, and How
Much - all concerning incorporation of his logic into our Etherphone. Here is a
report. Also included are some comments from an ensuing conversation with
Mike Overton concerning packaging. (Forgive and correct errors - and Bob, I
hope you'll forgive my adjectival use of your name).

We need to decide some of these issues soon since, depending on which way we
decide to do things, we may want to place some sort of order with Bob for copies
of his stuff or parts or something.

OBSERVATIONS (in no particular order)

Looks as though our schedules match reasonably well. They are just bringing up
a prototype - it seems to be going well.

About the end of January, when their prototype is working, they will give us
their SIL drawings so we can build some copies to go with our Etherphone
prototypes.

In the production units there will be two PC boards. The larger one, containing
most of the stuff as well as the power supplies (4 voltages), is about 6" x 12"; the
other, much smaller board contains the speaker, the tape recorder, the
volume-control slide, the power amplifier, etc. There are some 22 connections
between the boards.

They are not going to be able to provide us with finished (built, tested) units.
The best we can do is to utilize their design and their PC boards. They could
provide us with the parts (including the boards) but we would have to worry
about assembling and testing them. The garage can do this for us but we will
have to tell them how to do it and how to test them in particular.

I don't know what form is the best for us to build our prototype versions of their
stuff. Their prototype has been built by hand wire-wrapping directly from the
SIL drawings (which haven't been analyzed or anything). I had a conversation
with Mike Overton who suggested we use a second Multibus board. (Mike has
fortuitously ordered some extra boards to come up to the minimum discount
number). He  also notes that if we do that, we would (in the prototypes) share
the Multibus' power supplies for Belleville's stuff and ours. Shared power would
eliminate the Belleville pwr. supplies which might leave enough acreage on the
Belleville board so that we could collapse his second smaller board onto the first
- especially considering that we don't want much of the stuff on that board (the
tape unit, the speaker and volume control). Given that, then we might consider
making our own "Belleville" board for our production units (via the same
"automatic" route we will use to convert our Multibus Etherphone board to PC).
This would then yield a cleaner package containing 2 similar type boards - plus
shared power supplies. That is the plus. The minus is that we muck more with
Bob's stuff in configuring it onto our board - rather than just using his already
laid-out, known-to-work design. Mike argues that we'll end up doing that
anyway for the prototypes. . . .

Comments?     

*start*
00398 00024 US 
Date: 7 Jan. 1982 3:24 pm PST (Thursday)
From: Stewart.PA
Subject: Re: Activity Report - Voice Project
To: VoiceProject^
cc: Stewart
Reply-To: Stewart

Looks fine.  I might point out that the Gatewayness of the Alto has nothing to do
with its ability to reflect voice packets coming from the Lark prototype.  Any
Alto will work.  Indeed, we don't use the gateway for that.

*start*
00173 00024 US 
Date:  7 JAN 1982 1947-PST
From: STEWART.PA
Subject: Roms
To:   VoiceProject^
cc:   Boggs

The Ether downloader is now in ROM (!).  -Larry and David
*start*
00823 00024 US 
Date: 8 Jan. 1982 12:47 pm PST (Friday)
From: Swinehart.PA
Subject: The Tables That I Need
To: Stewart
cc: Swinehart

1. 1 ea.  256 x 16 (low 8 significant) table, converting u255 to 16 bit linear.  This
could be a file in the form of a BCPL table, which could be compiled into the
Etherphone0 program.

2. set of 256 x 16 (low 12 significant) tables, converting u255 to 12 bit linear,
attenuated by varying amounts (including 0 db?)  These should be in files
containing the bits, maam, only the bits.

3. set of 4096 x 16 (low 8 significant) tables, converting 12 bit linear to u255,
attenuated by varying amounts (definitely including 0 db.)  Just the bits.

4. A 65K x 16 (low 12 significant) table converting 16 bit linear to 12 bit linear,
+64K of dynamic RAM to hold it.  Just kidding.

/dcs

*start*
06158 00024 US 
Date: 8 Jan. 1982 1:41 pm PST (Friday)
From: Ornstein.PA
Subject: Activity Report - Voice Project
To: Schroeder
cc: VoiceProject^
Reply-To: Ornstein

Introduction

In mid-1981 CSL launched a new research project to investigate ways of
integrating voice into our prototype office systems. The main goal is to explore
this important new application area, but as a side effect the project is providing
an early test-bed for the Cedar programming environment. The first step is to
put in place a set of basic voice-handling facilities upon which a variety of
experimental systems can then be built. This first step is expected to be finished
during the summer of 1982.         

Activities

We spent about three months deciding what constituted a suitable basic set of
facilities and in doing the overall system design. The design was then formulated
as a proposal, discussed with the laboratory, and reviewed by an advisory
group.  We decided to incorporate the standard telephone (both the physical
instrument itself as well as its communication functions) into our system. The
instrument (including speakerphone-like arrangements) would be our voice
transducer, and taking over the job of providing phone services would facilitate
exploration of ways to improve this service - not so much the quality of
transmission but the often annoying human "connection protocols."  A second
major decision was to use the Ethernet to pass both control information (e.g.
messages associated with establishing calls) and the actual voice data itself.  This
decision gave us a uniform method of dealing with voice data for regular phone
conversations as well as for experimental uses of voice in such things as editing
of voice messages, voice-annotated-documents, etc.

A microprocessor-based "Etherphone" associated with each telephone provides a/d
and d/a conversion, encryption and decryption, and packetizing and
de-packetizing of voice to and from the Ethernet. The Etherphone is to be
kept small and simple and thus all system-level decisions (e.g. even such simple
things as how to make connections between phones) are relegated to a
separate "Etherphone Server" machine. A voice-file-server provides special
real time capabilities for storage and retrieval of voice messages.  In our
long-range design, connections into the regular telephone system are provided
by a special server, but to avoid the associated complex and distracting issues for
the present, we decided to connect each Etherphone to the normal telephone wall
jack.  This connection not only allows for phone calls to and from the outside
(non-Etherphone) world, but also provides backup phone service during the
sorts of outages that are inevitable during development.

We have made good progress on all fronts, although there is still a long way to
go.  We have a working prototype set of Etherphone hardware.  A test program
enables us to speak into a handset, digitize and encrypt the voice, pass it out
onto a special 1.5 MB Ethernet to an Alto Gateway which reflects the packets
back to the Etherphone where they are received, decrypted, reconverted to
analog, and fed to the earpiece - so that the speaker hears his own voice. 

We have a design and a partial implementation for the Etherphone server, which
will operate in the Cedar environment on a Dolphin or Dorado.  This server has
been designed to perform two classes of activities: those that seem inherently to
require a cenralized approach (telephone directories, overall traffic load
management, enumeration of ongoing conversations, etc.), and those that could
be done by the individual Etherphones (interpretation of dialing and hookswitch
actions, establishment of conversations, and the like.)  We have chosen to
implement this second class in the server in order to keep the Etherphone
processors small and easy to program; the components of the system that will
require frequent change and experimentation will be Cedar programs on the
server.

We have designed the protocols and server algorithms to allow client programs in
user workstations to supercede some or all of the "stand-alone" telephone
functions normally provided by the server and the Etherphones.  This will allow
us to integrate intelligent telephone management functions into our prototype
personal information systems.  It will also allow other applications to use the
Etherphones to record and play back spoken information.  These applications
include voice message systems, display-based editors for modifying spoken
"documents", and facilities for annotating text documents with voice comments.

There can be more than one Etherphone server in an internetwork; servers will
be able to take over the load from broken ones, without loss or destruction of
ongoing conversations.

Because our existing file servers lack the specialized performance characteristics
necessary for recording digitized voice "files",  we have also designed a voice
file server.  This Dorado-based server will be able to record and play several
simultaneous transcriptions or conversations, using the Etherphones as
"transducers."  It will include facilities for playing back partial transcriptions, to
accommodate editing activities.  The voice server will not provide elaborate
directory or file system maintenance functions, because we believe that later
versions will be based on more capable file servers that will have these
provisions.  Our simple voice file server is about half-completed.

Plans

By this summer we hope to have a basic Etherphone server and a basic voice
file server in place and to replace many of the telephones in CSL with
Etherphones. We are currently embarked on a redesign of the Etherphone
hardware and are considering incorporating a second processor for such functions
as silence detection (to reduce traffic) and merging of voice-data streams to deal
with conference calls.  We expect to build two further prototypes before the
"production" run. In our design we intend to utilize the logic from SDD's
voice-box (omitting the tape-recorder) to provide the connections to the
telephone instrument and telephone system. 

*start*
11002 00024 US 
Date: 8 Jan. 1982 1:52 pm PST (Friday)
From: Stewart.PA
Subject: ECHOS. . .echos
To: VoiceProject^.pa
cc: Gunning, McCreight, NDSmith, Lau, Belleville, Stewart

Note to Belleville et. al.:  We need a way to hook up a 4-wire telephone to the
Voice and Telephone Management Unit instead of a 2-wire phone.  I think you'll
have the same trouble if you ever need to use it for interactive voice.  This
might be as simple as a spot on the PC board to tap off the right signal, but there
might need to be a couple of jumpers etc.

--------------------------

Bill Gunning, Ed McCreight and I were chatting about our Echo problems.  Here
are some notes on the situation.

Our system design is for ~50 Larks (Etherphones) hooked up to the Ethernet
along with a Bluejay (Voice File Server) and a Thrush (Etherphone Server). 
Each Lark has a local 4-wire telephone set and also a "back door," a 2-wire
phone line to the central office.

Lark-to-Lark calls are placed over the Ether.  While the round trip delay will be
60-80 milliseconds, echo won't be a problem because the connection is 4-wire
throughout.

Most outside calls will be placed from a Lark using the attached phone line. 
After the connection is established, the local telephone set is connected directly
to the line (in 2-wire mode, even though the phone is 4-wire at other times). 
Echo is not a problem because the delays are very small (It is as though Lark
didn't exist, after call setup.)

Many calls arriving from outside use the same setup, provided that the human
answering the call is sitting near the Lark at which the call arrives (sitting in
one's own office).

Some kinds of calls, however, arrive from the outside to some Lark, and are then
forwarded over the Ethernet to some other Lark.  This happens either when an
attendant handles the call or when a Lark owner informs the system that he'll be
near another Lark, or when the locator has informed the system where a person
is when a call arrives.

When a call is forwarded over the network, the following situation exists:  The
Ethernet party speaks, the voice is packetized and transmitted, and is converted
back to analog at the forwarding Lark some 30-40 milliseconds later.  The analog
"Transmit" signal is then connected to the outgoing line via a hybrid circuit. 
The distant party speaks, the voice passes through the hybrid in the ofther
direction, is packetized by the forwarding Lark, and is converted back to analog
for the Ethernet party some 30-40 milliseconds later.  The hybrid is a device for
converting between the 2-wire outside line, on which voice travels in "both
directions" at the same time, and the 4-wire part of the system, in which the
"Transmit" and "Receive" sides of the conversation are carried separately.

The "Transmit" signal, on the 4-wire side, is supposed to go solely to the distant
party on the 2-wire side while the distant party's voice becomes the "Receive"
signal.  The hybrid is supposed to keep the "Transmit" signal from getting into
the "Receive" signal.  In actuality, these signals are present together on the
2-wire side of the hybrid: "Receive+Transmit".  The hybrid is supposed to
separate them by performing the calculation

	"Receive+Transmit"-"Transmit" = "Receive"

In practice this is quite difficult to do exactly.  Some amount of the Transmit
signal gets mixed in with the Receive signal.  The extent to which the unwanted
Transmit signal is attenuated is called the Echo Return Loss, or Transhybrid
Loss.  Our best guess is that 6 dB is straightforward, 10 dB is tricky but
achievable and more is quite difficult.  There are complex games one can play
with adaptive hybrids which might help.  At some point in complexity, an
adaptive hybrid becomes an echo canceller.

Digital answering machines and other applications of non-interactive voice do
not present an echo problem because the communications are inherently half
duplex.  The machine doesn't care if it hears its own echo.

Telephone company standards.

Refering to section 7 of "Notes on the Network" (by AT&T) on Transmission
considerations, there is a chart (Figure 2) which describes a Talker Echo opinion
model.  This chart depicts the delay of the echo path and the strength of the
echo against a subjective opinion rating.  For 60 millisecond echos, an echo path
loss of some 30dB is considered necessary for 50% of people to think the
connection "good."  A path loss of 40 dB reaches 90% acceptance.  For an echo
delay of 80 milliseconds, the required losses appear to be about 5 dB greater.

The loss values discussed above include transmission losses, and telephone set
acoustic converison losses as well as loss due to the echo mechanism.  A 500-type
telephone set has conversion losses averaging 9 dB with a standard deviation of
about 3.5 dB.

Etherphone system considerations.

We appear to have a number of alternatives available for dealing with the echo
problem.  First, we should note that a fraction of all calls are outside calls, and
as explained above, only a fraction of those would cause trouble.  In addition,
the echo is perceptible only to the local party, not to the outside caller.  It may
be possible for us to persuade our own users to accept a lower grade of service.

a)   Echo suppression.  We can introduce artificial loss in the echo path in order
to achieve the recommended loss.  For example, if our hybrids operate at 10 dB,
we could introduce an additional 20 dB loss in the "Receive" path.  We could
switch this loss in and out according to whether the local party was speaking. 
(This is what most speakerphones do.  We might be able to make it work better
by incorporating information about the enerygy coming in from the hybrid.)

b)  Echo cancellers.  We could install echo cancellers in those circuits used for
forwarded calls.  Echo cancellers are signal processing devices which estimate the
possibly complex echo transfer function and "subtract" the right amount of the
Transmit signal.

Comsat Telesystems corporations markets a line of echo cancellers that provide an
idea of prices.  A single line model with analog interfaces will be available in a
few months for $750 per line in small quantities.  For 50 units, the price would
be $670 apiece.  Comsat also makes a 24 channel T1 echo canceller that sells for
$12,000 ($500/circuit).  This model has digital interfaces.

It may be possible to use something like the NEC digital signal processing chip to
implement a digital echo canceller.  If we build it ourselves it should be less
expensive than a commercial product.  Such a processor would make an
exceedingly good speakerphone as well.   My judgment is that we don't have the
manpower now to develop our own echo canceller, either by NEC chip or by our
own LSI.

We could use echo cancellers in a variety of system configurations.

1)  Echo canceller per Lark, using the present "back door" approach.

2)  A small pool of echo cancellers sufficient to handle the maximum expected
number of forwarded calls.  (Perhaps five.)

3)  Echo Canceller Servers.

The first alternative seems too costly to consider;  the cost of each Lark would
increase by perhaps $700.

The third alternative, echo canceller servers, takes advantage of the small
numbers of simultaneous forwarded calls to reduce the number of servers
needed.  In this scheme, an Ethernet based server would receive the packet
streams containing the "Transmit" and the "Transmit+Receive" signals, digitally
process them, and send the resultant "Receive" packet stream on to the Ethernet
end of the conversation.  Such a configuration need not introduce much
additional delay, since, in principle, the server is not limited by any requirement
to process only one sample per 125 microseconds.  If the server used a commercial
ech canceller, however, we should expect such a processing rate and the server
would introduce about 30 milliseconds of additonal delay.

The second alternative, provision of a small number of echo cancellers, has
several possible configurations.

1)   POTS gateway.  We would reverse our decision to use the "back door" and
instead leave the PARC centrex system and obtain some number of DID (Direct
inward dialing) trunks and in essense, construct a complete PABX.   We might
not have to construct a new machine to be the gateway, we might instead use a
number of otherwise standard Lark machines as a distributed gateway - perhaps
controlled by Thrush.  Only these "gateway" machines would need echo
cancellers.

2)   Line concentrator.  We could build a pool of echo canceller equipped Larks
and a switch which would allow any of the gateway Larks to seize any of the
~50 lines in our system.  A forwarded call would arrive at a Lark, but be
referred to an idle gateway Lark for forwarding.  The gateway Lark would then
use the concentrating switch to seize the appropriate line.  This organization
would preserve our participation in the Centrex system.  The cost would be that
of perhaps 5 echo canceller equipped Larks plus the concentrator.  The
concentrator would not need full DAA capabilities because the individual Larks
could provide services such as Ring detection and even dialling.

3)  Pool.  This scheme is the same as the line concentrator without the
concentrator.  We would obtain an additional five lines for "gateway" circuits. 
When a Lark determines that a call needs to be forwarded, it would use the
centrex flash-and-feep technique to pass the call to an idle server.

Present problems and activities

Bob Belleville's voice and telephone manangement unit, which we propose to use
for the analog portions of the Lark, uses an existing telephone set for a
transducer.  This means that in normal use, the VTMU provides a 2-wire phone,
rather than a 4-wire phone.  The Etherphone system must have a 4-wire phone
in order to avoid echo problems on Lark to Lark (Ethernet only) calls.  The
circuitry needed to provide 4-wire telephone access to the VTMU must be
discussed with Belleville's group.  Perhaps we can get by with not stuffing some
components into the VTMU board and by tapping off signals at the right points. 
perhaps there are some minor changes that would have to be made.

Echo supressor tests.  Dan Swinehart and I are setting up an experiment using
the Lark prototype and an Alto I Etherphone to test the echo supression ideas.  If
we can make it work it may be good enough.  Otherwise we will have to choose
one of the echo canceller schemes or outlaw forwarded calls.

There are a number of experiments we could do in trying to improve hybrid
performance.  We could attempt building a hybrid with a balance network with
adaptive resistance and adaptive capacitance, for example.  We don't have the
manpower within the project at the moment.  Should we co-opt someone at Xerox
but not in the project?  Hire a consultant?  Is it important to pursue the idea?

If we can spring for $750, we should buy at least one echo canceller to try out.

	-Larry

*start*
00518 00024 US 
Date: 8 Jan. 1982 4:44 pm PST (Friday)
From: Ogus.PA
Subject: Prom blowing
To: Stewart
cc: Ornstein, Olmstead, Ogus

Larry,

There is a Blow.config on [Iris]<Workstation>Tools>Prom>.  We have taken the
sources in PromSources.dm, (plus the AltoMesa BCDs needed), and remade a
Blow.bcd which worked.

A word of caution about the hex (or .bin) file that is fed to Blow.bcd.  We
discovered that all lines should be terminated by a CR and a LF.  Otherwise
Blow.bcd chokes.

How is it working?

Roy.
*start*
00811 00024 US 
Date: 11 Jan. 1982 10:29 am PST (Monday)
From: Stewart.PA
Subject: Re: Prom blowing
In-reply-to: Ogus' message of 8 Jan. 1982 4:44 pm PST (Friday)
To: Ogus
cc: Stewart, Ornstein, Olmstead

I'll give it another try.  My .hex files did not have CRLF, only CR.  I'll try it
the other way.   Also, I kept getting "bogus data in PROM" and Blow would stop
after the first record of 16 bytes.  I looked at the PROM data and it was indeed
bogus.  I wouldn't think that the CRLF thing would cause that.

I have written as program to create .mb files from Intel format absolute binary
files, such as come from Duvall's linker.  Using PNEW, I've successfully made a
pair of 2716s for the Etherphone.  (Ethernet downloading works...)

As usual, PNEW took 2 tries. I got the bits reversed.

	-Larry

*start*
00894 00024 US 
Date: 11 Jan. 1982 11:38 am PST (Monday)
From: Swinehart.PA
Subject: The Tables That I Need, Revised.
To: Stewart
cc: Swinehart

1. 1 ea.  256 x 16 (low 8 significant) table, converting u255 to 16 bit linear.  This
could be a file in the form of a BCPL table, which could be compiled into the
Etherphone0 program.

2. set of 256 x 16 (low 12 significant) tables, converting u255 to 12 bit linear,
attenuated by varying amounts (including 0 db?)  These should be in files
containing the bits, maam, only the bits.

3. set of 4096 x 16 tables (low 8 significant), converting 12 bit linear to u255,
attenuated by varying amounts (definitely including 0 db.)  Just the bits

4. set (?) of 4096 x 16 tables (low something significant), producing
silence-detection values from 12 bit linear values.  Just the bits (I don't think
BCPL would handle a 4096-element table.)

/dcs
*start*
03597 00024 US 
Date: 11 Jan. 1982 4:23 pm PST (Monday)
From: ornstein.PA
Subject: Activity Report - Voice Project - REVISED
To: Schroeder
cc: VoiceProject^
Reply-To: Ornstein

The first shot was too long - here's the cut down version. Hope it's OK.

- - - - - - - - - - - - - - - - - -

Introduction

In mid-1981 CSL launched a new research project to investigate ways of
integrating voice into our prototype office systems. The first step is to put in
place a set of basic voice-handling facilities upon which a variety of
experimental systems can then be built. We intend to explore such applications as
voice message systems, display-based editors for modifying spoken "documents",
and facilities for annotating text documents with voice comments. 

Activities

We spent about three months determining a suitable set of facilities and in doing
the system design which was then formulated as a proposal, discussed with the
laboratory, and reviewed by an advisory group.  We decided to incorporate the
standard telephone (both the physical instrument and its communication
functions) into our system. This will permit us to explore ways of improving
telephone services. We decided to use the Ethernet to pass both control
information and voice data, thus giving us a uniform method of dealing with
voice data both for phone conversations and for other experimental uses.

A microprocessor-based "Etherphone" associated with each telephone provides a/d
and d/a conversion, encryption and decryption, and packetizing and
de-packetizing of voice to and from the Ethernet. For the present, we decided to
connect each Etherphone to the normal telephone wall jack.  This not only
allows for phone calls to and from the outside (non-Etherphone) world, but also
provides backup service during the sorts of outages that are inevitable during
development. Later on a special server for handling outside calls will eliminate
the need for this connection. 

Our goal is to keep the Etherphones as small and cheap as possible, so all
system-level jobs, even even such simple things as making "connections"
between phones, are performed by a separate, Cedar-based, Etherphone Server.
This server has been designed to perform both those functions which inherently
require a centralized approach (telephone directories, overall traffic load
management, enumeration of ongoing conversations, etc.), and those that will
require frequent change and experimentation.

Because our existing file servers lack the specialized performance characteristics
necessary for handling real-time voice,  we have also designed a voice
file server.  This Dorado-based server will be able to record and play several
simultaneous transcriptions or conversations, using the Etherphones as
"transducers."  It will include facilities for playing back partial transcriptions, to
accommodate editing activities.

We have made good progress on all fronts.  We have a working prototype set of
Etherphone hardware.  A test program enables us to speak into a handset,
digitize and encrypt the voice, pass it out onto a special 1.5 MB Ethernet to an
Alto Gateway which reflects the packets back to the Etherphone where they are
received, decrypted, reconverted to analog, and fed to the earpiece - so that the
speaker hears his own voice. Design of the Etherphone server is complete and
implementation is under way. The voice file server is about half complete.
 

Plans

By this summer we hope to have a basic Etherphone server and a basic voice
file server in place and to replace many of the telephones in CSL with
Etherphones. 

*start*
00852 00024 US 
Date: 12 Jan. 1982 9:39 am PST (Tuesday)
From: Swinehart.PA
Subject: How to name the tables
To: Stewart
cc: Swinehart

A 4096 x 16 (8) return loss/conversion table that incorporates 20 db of return loss
should be called
	LossTable2.Table.
LossTable0.Table should be a straight 12-bit linear to u-255 table (no loss).

A 256 x 16 (12) hybrid return loss table that incorporates 30 db of loss (don't we
wish) should be called
	HybridTable3.Table.
HybridTable9.Table should contain all zeroes (no echo).

A 4096 x 16 silence function table using silence detection method 1 should be
called
	SilenceTable1.Table.
At present, I assume that there is only a method 1.

I don't care what you call the BCPL source 256 x 16 linearizing table.  But if it's
easier, make it a binary file, and call it LinearTable0.Table.

(I'm ready)

/dcs
*start*
00997 00024 US 
Date: 12 Jan. 1982 5:00 pm PST (Tuesday)
From: ornstein.PA
Subject: Rams and Roms
To: Stewart
cc: ornstein

McCreight has ordered just a couple of the Motorola version of the 2764. It's in a
24 pin pkg (as opposed to the other brands that are 28 pin - extra pins used for
in-situ programming that I don't think we need. Also the 24 pin pkg has no
Ready line). The Motorola version comes in 450 ns. and 350 ns. versions.
McCreight's ordered the cheaper 450 version - it's $55 each in singles quantity.

I suggest we include the question of whether to go to the 2764's with the rest of
the re-design. Is it that 2732's will do when you get rid of the old monitor? 
Probably even the 2764's are a worthwhile space saver though a bit expensive. 

As I said, the dynamic memory seems like a win as it saves space and gives us
plenty of ram for whatever we might want to do. I assume it is at least as cheap
as the statics? Then what about the memory for the slave processor?  

*start*
01191 00024 US 
Date: 12 Jan. 1982 5:14 pm PST (Tuesday)
From: Stewart.PA
Subject: Rams and Roms
To: VoiceProject^.pa

---------------------------

Date: 12 Jan. 1982 5:00 pm PST (Tuesday)
From: ornstein.PA
Subject: Rams and Roms
To: Stewart
cc: ornstein

McCreight has ordered just a couple of the Motorola version of the 2764. It's in a
24 pin pkg (as opposed to the other brands that are 28 pin - extra pins used for
in-situ programming that I don't think we need. Also the 24 pin pkg has no
Ready line). The Motorola version comes in 450 ns. and 350 ns. versions.
McCreight's ordered the cheaper 450 version - it's $55 each in singles quantity.

I suggest we include the question of whether to go to the 2764's with the rest of
the re-design. Is it that 2732's will do when you get rid of the old monitor? 
Probably even the 2764's are a worthwhile space saver though a bit expensive. 

As I said, the dynamic memory seems like a win as it saves space and gives us
plenty of ram for whatever we might want to do. I assume it is at least as cheap
as the statics? Then what about the memory for the slave processor?  

------------------------------------------------------------

*start*
02886 00024 US 
Date: 13 Jan. 1982 10:03 am PST (Wednesday)
From: ornstein.PA
Subject: ETP Parts List
To: Stewart
cc: Ornstein

How does this list look to you? I've generally allowed enough for 3 machines
plus 2 spares of each type. I'll check with Mike to be sure all the standard parts
are adequately stocked. I tried to increase the numbers of the special chips to
allow for the redesign - things like the 8088 itself (is it going to be an 8086?)
and the 8286, etc. However I didn't increase the numbers on the standard parts as
I didn't know how much to add and will verify that we have plenty of them. I
included stuff for dynamic memories (are you sure that 8208 is the right latch?).
If we decide after all to stick with the static RAMs, then we may later have to
buy a few more.

 
Type		| Got	| Buy	| Comments

40 PIN

SLC		|  lots	|   -	|
I8088	  (2)	|  2ES	|  6ES	|  in addition we have three non-ES
I8237-5   (2)	|  10	|   -	|  also have 2 AMD 9517's
AM9513	|   2	|   3	|
I8274		|   2	|   3	|
I8255	   	|   4	|   *	|  
I8203-3	|   0	|   5	|  Dynamic Memory controller

*Don't buy any more 8255's until we see if we're really going to use them

28 PIN

(8251)		|   3	|   -	|  none beyond the first prototype
8259A-2	|   4	|   1	|
WD2001E-02	|   2	|   3	|  3 MHz


24 PIN

I2716	(4)	|  lots	|   -	|  compress to 2 per or better, use 2764
I2764	(1)	|   0	|   5	|  
H6116	(13)	|  36	|   *	|  8 for main Proc, 4 for slave, and 1 for Audio

*Don't buy any more static rams until we try dynamics.

20 PIN

LS244	(3)	|  lots	|   -	|  need 11
I8284		|   3	|   2	|  need 5
I8282	(3)	|   4	|   7	|  redesigned number
I8286	(2)	|   8	|   -	|  redesigned number
I8202		|   0	|   5	|  latches for dynamic memory 


16 PIN

26LS31	|  lots	|   -	|  need 5
26LS32	|  lots	|   -	|  need 5
LS138	(3)	|  lots	|   -	|  need 11
LS139		|  lots	|   -	|  need 5
LS157		|  lots	|   -	|  need 5
LS163	(2)	|  lots	|   -	|  need 8
LS166		|  lots	|   -	|  need 5
LS174		|  lots	|   -	|  need 5
N123		|  lots	|   -	|  need 5
PLAT	(4)	|  lots	|   -	|  need 14
DIP switches	|  lots	|   -	|  need 5

14 PIN

75188		|  lots	|   -	|  need 5
75189		|  lots	|   -	|  need 5
8T09	(?)	|  lots	|   -	|  need 11 (assuming 3 total per machine)
XtalA		|   5	|   -	|
XtalB		|   5	|   -	|
LS00	(2)	|  lots	|   -	|  need 8
LS02	(2)	|  lots	|   -	|  need 8
LS04	(2)	|  lots	|   -	|  need 8
LS08	(2)	|  lots	|   -	|  need 8
LS32	(2)	|  lots	|   -	|  need 8
LS74	(2)	|  lots	|   -	|  need 8
LS164		|  lots	|   -	|  need 5
N38		|  lots	|   -	|  need 5

*start*
00293 00024 US 
Date: 13 Jan. 1982 12:47 pm PST (Wednesday)
From: Stewart.PA
Subject: Re: ETP Parts List
In-reply-to: Your message of 13 Jan. 1982 10:03 am PST (Wednesday)
To: ornstein
cc: Stewart

The latch for the dynamic memories is an 8282, just like the other latches... 
-Larry

*start*
01913 00024 US 
Date: 13 Jan. 1982 4:00 pm PST (Wednesday)
From: ornstein.PA
Subject: Etherphone Redesign
To: Stewart
cc: ornstein, Gifford

This is the beginnings of a comprehensive list of items to remember to consider
in the redesign. Some of the items are big, not thought out issues; others are
small - no particular order. The items come from things I remember we've talked
about and a couple of earlier messages. I suspect you'll remember a number of
others. I'll keep updating if you send me corrections, additions, etc.

1. Addition of second processor and memory - should the audio DMA really go? 

2. Locator - should we add it in?

3. Removal of LS138 for accessing upper half of Ram

4. Use of dynamic memory instead of Ram - associated removal of second LS138

5. Use of 2732 or 2764 instead of 2716's to save space

6. Replacement of 8255 with less logic  

7. Can we get a 3 MHz SLC? If we go to an SLC clock of 12.288 MHz, then
shouldn't we go to a 24.576 crystal in order to divide by two and keep the 50%
duty cycle?  SHould we do this anyway and add another jumper option to the
board for which frequency the SLC gets?

8. Page 1:  We may be able to save a package of N125s by simplifying the MRD'
MWR' IORD' IOWR' stuff.  I don't think that we need to generate separate IO and
M signals because only the processor talks to IO and that case is already taken
care of since MemSel' is part of the enables for the IO address decoder.

Those chips that the DMAs talk to are ONLY talked to by DMA so they can
receive separate nets: DIOWR' and DIORD'.

The Western digital chip is a problem, because it is talked to by both the
processor and the DMA.  It is the only such chip

9. We could change the 7474 DREQ flops to use a (4 section) 74279 if we had a
pulse that occurred after TSN.  We could use framesync if we changed to use a
time slot near the end of the frame, say 20-24.

Severo
*start*
02016 00024 US 
Date: 14 Jan. 1982 10:11 am PST (Thursday)
From: ornstein.PA
Subject: SLC Questions
To: Stewart
cc: VoiceProject^
Reply-To: ornstein

I finally had a good talk with Jim Okazaki. He just got our list of questions
yesterday (so much for the mail) and is going to work on them. He says it will
probably take several days and he will call us next week sometime (or in the
meantime if THEY have any questions about our questions). I really believe he is
trying to help and we should now give him some time to pull together answers.
I'll beat on him next week - I told him we're held up awaiting answers.

I also talked to him about speed. Arnie Leon is the Production chip tester who
uses the Century tester that reportedly won't go above 10MHz. Okazaki,
however, has his OWN tester that he can crank up to whatever. He claims to
have seen some 60 or 70 of the new, re-designed chips and says all that HE's
seen crap out between 7 and 10 MHz. He says they designed the chip for 10
MHz and so it would not be surprising if SOME chips work up to 12 MHz - but
he believes damn few will, that he hasn't seen one that does, and that we'd be
foolish to count on getting more than a very few that would work at 12 MHz. (I
didn't think to ask him howcum, if they designed it for 10 MHz, most chips crap
out below that. Probably it's like our original Dorado design goal of a 20 ns. cycle
that reality has pushed up to 30 ns. Anyway they were REALLY heading for 6
MHz - i.e. a 1.5 Mbit Ether). 

Despite this pessimism, he gave me a new name (George Tu) who (unlike Arnie
Leon and his boss Jim Retuer who work in "production") is in "circuits" - who
presumably can give me more accurate word. Okazaki thinks we may have been
getting conflictiong signals about speedup prospects because there is another
variable - a forthcoming switch to a new (NSIL-3?) process - which will reduce
the cell size and might thus lead to faster chips - EVENTUALLY. Don't hold
your breath says Okazaki.

More anon.

Severo  

*start*
00873 00024 US 
Date: 15 Jan. 1982 8:42 pm PST (Friday)
From: Stewart.PA
Subject: Slave 8088 processor
To: VoiceProject^.pa
cc: Gifford, TonyWest, Stewart

I have a new 8088 slave processor loop that implements:

Silence detection
Input Gain control (up to 6 gain values, gain switching included)
Merging of exactly three conferees
Gain reduction of conferees with up to 3 gains
	(but no control over switching gain)

This loop runs in 81 microseconds on a 5 MHz 8088.
44 microseconds arbitration time for the 6 arbitrations needed seems adequate
margin...

Note to Tony:  This version needs only a 2048 byte ROM between the bus and
the output shift register.

Possible additions:
	Control over merging gain
	Digital echo cancellation with one or two terms
	Control over who is merged (noone, A, B, C, AB, AC, BC, ABC)

Marginal cost is 1 instruction per conferee

*start*
00554 00024 US 
Date: 16 Jan. 1982 12:27 pm PST (Saturday)
From: Swinehart.PA
Subject: Alto II Swap Request
To: Orr, DBrown
cc: VoiceProject^
Reply-To: Swinehart

We'd like to swap the Alto II's that are in the Nursery and in Bob Ritchie's
office, since the latter has an audio board (and L. Stewart's Bravo X keytops, for
that matter.)  This seems easier than installing the audio hardware in the
Nursery Alto II.

These machines should swap identities, as well, by having their Ethernet host
addresses exchanged.

Thanks,
Swinehart and Stewart
*start*
00384 00024 US 
Date: 16 Jan. 1982 12:29 pm PST (Saturday)
From: Swinehart.PA
Subject: Working hybrid tester
To: VoiceProject^
Reply-To: Swinehart

I now have what I believe is a working test (on an Alto I) of an Etherphone
program and microcode to perform subjective tests of various levels of hybrid
echo, modified by various values of return loss.  We can test it Monday.