*start*
03941 00024 US 
Date: 30 Nov. 1982 8:39 pm PST (Tuesday)
From: Stewart.PA
Subject: Analog changes
To: VoiceProject^.pa
cc: Stewart

I think the following changes will take care of most of the problems:

1.  Gas-tube surge protectors on Tip/Ring and A/A1 where they enter the board.  TII-47's seem OK, See Anixter catalog p 3061.  The center tap should be returned by the shortest route to earth ground.  Perhaps the angle bracket on the corner of the analog board would be better than following back through the Viking connector and the power supply.

2.  10 ohm resistors in series with the deci-ductors.  (Protection)

3.   Additional relay (called 'A') to control the A/A1 leads.  Separate control of the present K4 relay (which handles the TeleSet switchhook.)  Drive both K2 and K3 from the same driver -- which will eliminate possible problems if the relays should fail to track.  Use the free'd section of the 7545X to drive the additional relay.  There will be 4 independent relay control lines from the digital board.  The two existing ones together with (I guess) P1C4 and P1C5.

4.  Replace the 75453Bs with 75454's  (different inversion)  Together with a program change, this should fix the relay chatter on boot problem and make the watchdog timer more reliable.

5.  Provide pads permitting use of the 'other' hybrid transformer.  It is smaller, so it could fit within the same 'footprint' as the present transformer.

6.  Use an electronic holding circuit rather than run DC through the transformer.  This requires the addition of 2 diodes, two resistors, and a transistor.  Place 44 microfarads in series with the resistor  (smaller may be OK, will test)  If electrolytic capacitors are used they should be returned to +12 or some nearby voltage.  (A holding coil is an alternative, if we can find one.)  Place a high-power (two watt?  more?) 20 to 30 volt zener to protect the holding circuit.

7.   Use 1N4004's in the bridge circuit instead of 1N4003's for added voltage rating.

8.  Connect TeleWallSink directly to the output of Codec 1 (and change the gain resistors on the TeleWallSink op amp).  By doing this the Codec1 Filter is always in the TeleWall path, thus meeting the rolloff and harmonic requirements of registration.

9.  If limiting is a real problem (Dan feels it may not be, we should check with Whosis at the FCC about "Live Voice") then it can by done by software in the Slave processor (e.g. software AGC using the silence detector code and the yet-to-be written program 3 of the slave).  Note that this program is in EPROM and quite difficult to disturb!

10.  The layout of the potentially high voltage sections of the Telewall interface should be improved for greater trace separation.  If possible, the power planes should be entirely etched away in this area.

11.   Qualify the power supply transformer for insulation per part 68.  (2500 v RMS was it?)

12.   Try to get statement from transformer manufacturer about insulation of the transformers.

13.   Check out using beefier Zeners on the electronics side of the hybrid  -- 2 watt?  What is there now?

14.  Use the contact of K1 freed by the new relay (what used to switch A and A1, to switch the other side of the line.  Tip and Ring will enter via the modular connector, go past the surge protector, go through the deciductors, go through the 10 ohm resistors, go through the 1N4004 bridge and then go both to the rest of the ring detector and to the off-hook relay.  The relay to the Blue phone will tap off just before the diode bridge.

I'll be back Wednesday afternoon to help with the new schematics.

Severo, the things I'd like to put in your court are:

Getting the gas surge protectors, see sheet of paper on Coral Sea's mouse.  Mike has the Anixter catalog, of which the sheet is page 3061.

Finding a suitable capacitor to go in series with the transformer (see item 6) . Also a suitable Zener (see item 6).

	-Larry

*start*
00548 00024 US 
Date: 1 Dec. 1982 11:35 am PST (Wednesday)
From: ornstein.PA
Subject: Bob Diamond
To: Stewart
cc: ornstein

Phil Neil called this AM to say the guy he was recommending is

	Bob Diamond
	408 - 629-1251  or  408 - 727-2751 

One of the numbers is work, one home. Doesn't know which is which. Be
discreet if a company answers as consulting such as this is strictly on the side.

I gather from your last night's message that after all you decided we should go
ahead and try to do the stuff necessary to register it - yes? 

S.

*start*
00575 00024 US 
Date: 9 Dec. 1982 12:53 pm PST (Thursday)
From: Stewart.PA
Subject: Lark.mesa changes
To: VoiceProject^
cc: Stewart

A status event with device code 26 and event code disabled means that the tone play-out has finished.

A command event with device code 27 means to interpret the event code as a delay in 10 millisecond units and Dismiss that long before processing the rest of the commands.

A Feep command with a character code <128 means to play a silence of length code * 10 milliseconds.

I haven't changed Lark.mesa yet, only the C end.
	-Larry

*start*
00512 00024 US 
Date: 7 Dec. 1982 1:21 pm PST (Tuesday)
From: Stewart.PA
Subject: Dealer abstract
To: Schroeder
cc: Stewart

Etherphone Digital Board

The Lark (Etherphone) digital board contains two 16-bit microprocessors, 74K bytes of memory, an Ethernet controller, DES encryption, a time-division multiplex digital voice interface, and numerous other gadgets, all interconnected in a fairly interesting manner.  Lark can handle upwards of 200 packets per second of encrypted ethernet voice traffic.

*start*
00345 00024 US 
Date: 14 Dec. 1982 2:20 pm PST (Tuesday)
From: ornstein.PA
Subject: Ringer Equivalence Number
To: Stewart
cc: Swinehart, ornstein

We need to put this number down on the application form for the Experimental
Ident. Number.  Dan says you can help with it - apparently it's the impedence at
the ringing frequency??? 

S. 

*start*
00383 00024 US 
Date: 14 Dec. 1982 3:12 pm PST (Tuesday)
From: Stewart.PA
Subject: Re: Ringer Equivalence Number
In-reply-to: ornstein's message of 14 Dec. 1982 2:20 pm PST (Tuesday)
To: ornstein
cc: Stewart, Swinehart

Use ringer equivalence 1.0A.  That is what is on the bottom of the blue phones.  The electronic ring detect circuit is very small by comparison.

	-Larry

*start*
00300 00024 US 
Date: 14 Dec. 1982 5:18 pm PST (Tuesday)
From: Swinehart.PA
Subject: Re: Ringer Equivalence Number
In-reply-to: Stewart's message of 14 Dec. 1982 3:12 pm PST (Tuesday)
To: Stewart
cc: ornstein, Swinehart

Oh.  Right.  It will be different at different times, peaking at 1.0.

*start*
00722 00024 US 
Date: 18 Dec. 1982 5:13 pm PST (Saturday)
From: Stewart.PA
Subject: New MapParse Stuff
To: VoiceProject^
cc: Stewart

There is a new Teleload.df out there.  It has separate configurations for TeleDeb and MapParse.  All MapParse does is register itself with the Userexec.  Type "MapParse Lark" to the Userexec and it will scan Lark.obj and write Lark.names and Lark.addresses (slow).

When you are debugging, set context to TDX and evaluate BuildSearchTable["Lark"].  BuildSearchTable will read the disk file Lark.addresses and build the symbol table (fast).

You need to run MapParse only once per re-linking of Lark.  I have put Lark.names and Lark.addresses out on [Indigo]<Voice>Obj>.

	-Larry

*start*
01802 00024 US 
Date: 20 Dec. 1982 4:35 pm PST (Monday)
From: ornstein.PA
Subject: File Servers
To: MBrown, Taft, Kolling, Stewart, Swinehart, Overton
cc: ornstein, Taylor, Levin, Clark, Lampson

Over the spring we are going to be bringing both Alpine and Bluejay (the voice
file server) into existence.  Here is a proposed general plan:

Within a few weeks the Alpine machine arrives. We'll put it in the current rack
set; terminal in the Nursery (Mark's preference - no problem). When the
microcode is ready to try out with an "external" T-300, we'll put the drive at the
far end of Ivy - there's just room to squeeze it in.  Mark says that at about that
same time we should be able to decommission Juniper.  So then we'll clear out
the Juniper area and prepare for a more permanent Alpine server in that space.

The Voice project is scheduled to get a Dorado for Bluejay on Mar 25.  I propose
we consider delivering THAT machine into the old Juniper area with one (or
more) associated T-300's.  That will then become Alpine, and the Voice Project
will take over the former Alpine machine - which will already have the T-300
attached.  Voice can make do for some time with that one T-300 (although we
eventually have to find a place where it can live and have a second T-300). 
But we can worry about that later; this plan seems to solve the immediate
problems.

There's some question about what to do when Alpine needs a fourth external
drive; the DskEth board only handles three (plus the on-board T-80). 
Presumably we just add a second DskEth board.  We will have to do a bit of
metal work (the chassis connector panel only has holes for the first three
external drives... mumble, mumble...) but there appear to be no serious problems. 

Does anyone see any problems with all this? 

S. 
*start*
00306 00024 US 
Date: 27 Dec. 1982 11:03 am PST (Monday)
From: ornstein.PA
Subject: Experimental Ident. Number
To: VoiceProject^
Reply-To: ornstein

Our Experimental Id. # is:

		ABI-969-02541-MT-T

				effective Jan 3 to July 4, 1982.

						Can be extended with 1 month notice.

Cheers,

Severo

*start*
05154 00024 US 
Date: 27 Dec. 1982 3:24 pm PST (Monday)
From: Schroeder.pa
Subject: "Voice" section for activity report
To: Ornstein
cc: Swinehart, Stewart, Schroeder

It's that time of year again.  I need your input by early next week.  Here's what
you told us last year.

++++++++++++++++++++

II.	COMMUNICATIONS

A.	Voice Project

In mid-1981 CSL launched a new research project to investigate ways of
integrating voice into our prototype office systems. We are in the process of
building a set of basic voice-handling facilities upon which a variety of
experimental systems will 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

Lark:  Over the past six months the Etherphone (Lark) digital hardware was
redesigned to incorporate a second 8088 processor which operates in a tight
signal-processing loop. This loop allows us to compensate for delayed reflections
which arise in certain situations. It also provides for correct handling of up to
three simultaneous speakers in a conference call. In addition to incorporating the
second processor, several other refinements were made: enlargement of the main
RAM, elimination of one of the DMA chips, increase in the number of parallel
In/Out lines, and simplification of the serial line controller. The Lark monitor
and all of its test hardware have been converted to work with the new hardware.
A modest set of operating system primitives have been written and the Pup
package and Ethernet drivers have been converted to the "C" language for
inclusion. We are presently working on a Remote Procedure Call package that
will be used for all communication except for actual voice transmission
itself. 	

An Etherphone consists of three separate boards (plus a power supply). One is
the digital board discussed above. The second is a considerably smaller board
containing the filters and Codecs which provide for A/D and D/A conversion,
together with analog interfaces (to the telephone line, the phone handset, a
speaker, a microphone, etc.) and a flexible analog switching arrangement
controlled by the digital board's software. Also included are DTMF detection and
generator chips. We have been using a small subset of this logic (on a temporary
board) in proving out the Digital board and are just commencing on the design
of the full Analog board.	

The third board contains the electronics for dealing with a locator, the scheme
for which has not been fully designed. We are planning to incorporate the
locator as a later refinement and have provided both space and sufficient I/O
lines for handling it. 	

Thrush:  Implementation of a basic Etherphone server program (Thrush),
running in the Cedar environment, is nearly complete.  The server will initially
support the use of Etherphones to place simple telephone calls, both to other
Etherphones and to other parties via conventional telephone lines.	

Thrush uses a permanent data base (maintained by the Grapevine system) to
associate individual Lark processors and workstations with individuals. 
Provisions exist to allow a user, by supplying a name and password to a Lark or
to an adjacent workstation, to override the default association.  This paves the
way for personalized, location-independent, telephone services.  Much of the
groundwork has also been laid for the implementation of more ambitious
applications.  Realistic testing of the Thrush server awaits the completion of the
Lark communications software.	

The voice file server program has successfully recorded and replayed voice
conversations, using Ethernet communications, to an Alto equipped with audio
hardware.  Provisions for file backup and file system maintenance are currently
being developed. [S. Ornstein, L. Stewart, D. Swinehart, J. Ousterhout (U.C.
Berkeley), S. Owicki (Stanford)] 	

Plans

We presently have three stitchweld copies of the Lark's digital board and three
copies of the primitive Analog logic.  We plan shortly to start PC layout of the
digital board and with some luck we will be able to start layout of the analog
board in about a month.  We have cut back on our earlier plans to build 50
Etherphones this year for CSL--partly due to budget cutbacks and partly because
it seemed prudent to make a smaller number work first. We presently expect to
build about 10 printed circuit versions this year with which to
experiment.	

When the Lark software is complete, we will be able to test the ability of Thrush
to place and manage simple telephone calls.  We hope to be able to make our first
call later in the summer.  We will then extend its capabilities to deal with
workstation-controlled connections, conversations involving the voice file server,
and more complex telephone capabilities (call-transfer, call-forwarding, hold
features, attendant capabilities, etc.).  We expect to complete most of these
extensions during the remainder of this year.  The voice file server will also be
modified to allow a Thrush server to control its actions.	

++++++++++++++++++++

*start*
02189 00024 US 
Date: 27 Dec. 1982 4:57 pm PST (Monday)
From: Stewart.PA
Subject: Lark timing for delay loops
To: VoiceProject^.pa

The slave processor has some programmed time delays which set it up to access the T1 line shift registers when they are not shifting.  At present, one of the voice modes uses a long string of NOPs to do this job while the other mode uses the LOOP instruction.  The LOOP instruction takes less space.

I have run a program on the main CPU to measure how fast the loops run.

One loop is

loop	OUT xxx ; scope probe
	(5 NOPs)
	OUT xxx
	(50 NOPs)
	JMP loop

The whole loop executes in 33.5 microseconds and the time between the two OUTs is 4.4 microseconds.

A cycle is 127.5 nanoseconds.
Fetching an instruction byte takes 4 cycles.
Instruction fetching is overlaped with execution, if the IFU can keep up.
OUT takes 10 cycles and is a 2 byte instruction
JMP takes 15 cycles, and is a 2 byte instruction (the one that was assembled..)
NOP takes 3 cycles and is a 1 byte instruction.

Adding up the maximum of fetch time and execution time gives 255 cycles or 32.5 microseconds.  I think the left over part is the IFU hiccup just before and after execution of the JMP.  (The IFU is empty just before the JMP so it must be fetched first.  Just after, the IFU has to restart at loop.)

Another program uses the LOOP instruction, which decrements CX and jumps if CX > 0 .

oloop	OUT	xxx	; scope point
	MOV	CX,2
iloop1	LOOP	iloop1
	OUT	xxx
	MOV	CX,2
iloop2	LOOP	iloop2
	JMP	oloop

LOOP is a 2 byte instruction and takes 17 cycles if the branch is taken and 5 if not
MOV takes 4 cycles and is a 3 byte instruction

The total loop takes 243 microseconds and the time between the OUTs is 6.7 microseconds.   (1906 and 53 cycles)

The sum of the maximum of execution or fetch time is 1803.

I looked at ALE and believe that LOOP takes 18 cycles apiece on the 8088.  That matches.

So NOP is 4 cycles per NOP plus IFU slop at the end  (510 nanoseconds)

LOOP is 18 cycles per count plus 5 plus IFU slop (2.23n + .64 microseconds)
Counting the required MOV CX adds constant overhead of 12 cycles or 1.53 microseconds.  New formula is 2.23n + 2.17 microseconds.

*start*
00294 00024 US 
Date: 27 Dec. 1982 5:09 pm PST (Monday)
From: Stewart.PA
Subject: New Lark.obj
To: Swinehart
cc: Stewart

<Voice>Obj>Lark.obj, Lark.addresses, Lark.names  

These should not get stack overflow.  Perhaps they will work better in other ways (or not work at all).
	-Larry

*start*
00387 00024 US 
Date: 27 Dec. 1982 5:17 pm PST (Monday)
From: Stewart.PA
Subject: New Lark.obj
To: Swinehart
cc: Stewart

<Voice>Obj>Lark.obj, Lark.addresses, Lark.names  

These should not get stack overflow.  Perhaps they will work better in other ways (or not work at all).
	-Larry

PS seems to work with NewLarkPackage.  TYhat has never seemed very indicative about Thrush.

*start*
05779 00024 US 
Date: 28 Dec. 1982 4:13 pm PST (Tuesday)
From: Stewart.PA
Subject:  New facilities in Teledeb
To: VoiceProject^.pa
cc: Stewart

There is a process in Lark now that handles TeleDeb packets, so the Lark core image may be inspected and altered while the Lark program is running.

I've changed Alloc.c to record the PC of the caller of Allocate.
There is a procedure in TDX.mesa called PrintZone that dumps sysZone thus:

[ivy]<stewart>temp>Lark.storage

--Lark.storage
adr: A7DA, len:   308, prev: AB2A, next: A7CC
adr: A90E, len:    14, prev: A7CC, next: AA3C
adr: A91C, len:    20, usedby: NoteConnection+6C
adr: A930, len:    20, usedby: NoteConnection+6C
adr: A944, len:     8, usedby: UnmarshallFormatted+18F
adr: A94C, len:     8, usedby: AllocZero+12
adr: A954, len:    68, usedby: StartDispatcherSpecs+2A
adr: A998, len:    18, usedby: CStringToString+20
adr: A9AA, len:    12, usedby: AllocZero+12
adr: A9B6, len:    18, usedby: ShallString+46
adr: A9C8, len:    18, usedby: ShallString+46
adr: A9DA, len:    36, usedby: AllocZero+12
adr: A9FE, len:    62, usedby: UnmarshallFormatted+18F
adr: AA3C, len:    62, prev: A90E, next: AB2A
adr: AA7A, len:    16, usedby: UnmarshallFormatted+18F
adr: AA8A, len:    18, usedby: UnmarshallFormatted+18F
adr: AA9C, len:    18, usedby: UnmarshallFormatted+18F
adr: AAAE, len:    16, usedby: ImportInterface+133
adr: AABE, len:    10, usedby: dBlock+13
adr: AAC8, len:    10, usedby: CStringToString+20
adr: AAD2, len:    10, usedby: CStringToString+20
adr: AADC, len:    12, usedby: CStringToString+20
adr: AAE8, len:    16, usedby: ImportInterface+133
adr: AAF8, len:    20, usedby: NoteConnection+6C
adr: AB0C, len:    10, usedby: ForgetConnections+AD
adr: AB16, len:    10, usedby: ForgetConnections+AD
adr: AB20, len:    10, usedby: ForgetConnections+AD
adr: AB2A, len:    18, prev: AA3C, next: A7DA
adr: AB3C, len:    22, usedby: CStringToString+20
adr: AB52, len:    24, usedby: CStringToString+20
adr: AB6A, len:    10, usedby: dBlock+13
adr: AB74, len:    10, usedby: dBlock+13
adr: AB7E, len:    10, usedby: dBlock+13
adr: AB88, len:    10, usedby: dBlock+13
adr: AB92, len:    10, usedby: dBlock+13
adr: AB9C, len:    56, usedby: AllocZero+12
adr: ABD4, len:   604, usedby: StartNProcess+14
adr: AE30, len:   604, usedby: StartNProcess+14
adr: B08C, len:   604, usedby: StartNProcess+14
adr: B2E8, len:   260, usedby: AllocZero+12
adr: B3EC, len:    36, usedby: AllocZero+12
adr: B410, len:    36, usedby: AllocZero+12
adr: B434, len:   260, usedby: AllocZero+12
adr: B538, len:    10, usedby: AllocZero+12
adr: B542, len:     8, usedby: AllocZero+12
adr: B54A, len:     8, usedby: BindingInitialize+9D
adr: B552, len:    14, usedby: CStringToString+20
adr: B560, len:     8, usedby: AllocZero+12
adr: B568, len:     8, usedby: BindingInitialize+25
adr: B570, len:     8, usedby: AllocZero+12
adr: B578, len:   354, usedby: InitPupLevel1+E0
adr: B6DA, len:    12, usedby: InitPupLevel1+94
adr: B6E6, len:   210, usedby: InitPupLevel1+76
adr: B7B8, len:    12, usedby: InitPupLevel1+94
adr: B7C4, len:   210, usedby: InitPupLevel1+76
adr: B896, len:    12, usedby: InitPupLevel1+94
adr: B8A2, len:   210, usedby: InitPupLevel1+76
adr: B974, len:    12, usedby: InitPupLevel1+94
adr: B980, len:   210, usedby: InitPupLevel1+76
adr: BA52, len:    12, usedby: InitPupLevel1+94
adr: BA5E, len:   210, usedby: InitPupLevel1+76
adr: BB30, len:    12, usedby: InitPupLevel1+94
adr: BB3C, len:   210, usedby: InitPupLevel1+76
adr: BC0E, len:    12, usedby: InitPupLevel1+94
adr: BC1A, len:   210, usedby: InitPupLevel1+76
adr: BCEC, len:    12, usedby: InitPupLevel1+94
adr: BCF8, len:   210, usedby: InitPupLevel1+76
adr: BDCA, len:    12, usedby: InitPupLevel1+94
adr: BDD6, len:   210, usedby: InitPupLevel1+76
adr: BEA8, len:    12, usedby: InitPupLevel1+94
adr: BEB4, len:   210, usedby: InitPupLevel1+76
adr: BF86, len:    12, usedby: InitPupLevel1+94
adr: BF92, len:   210, usedby: InitPupLevel1+76
adr: C064, len:    12, usedby: InitPupLevel1+94
adr: C070, len:   210, usedby: InitPupLevel1+76
adr: C142, len:    12, usedby: InitPupLevel1+94
adr: C14E, len:   210, usedby: InitPupLevel1+76
adr: C220, len:    12, usedby: InitPupLevel1+94
adr: C22C, len:   210, usedby: InitPupLevel1+76
adr: C2FE, len:    12, usedby: InitPupLevel1+94
adr: C30A, len:   210, usedby: InitPupLevel1+76
adr: C3DC, len:    12, usedby: InitPupLevel1+94
adr: C3E8, len:   210, usedby: InitPupLevel1+76
adr: C4BA, len:    12, usedby: InitPupLevel1+94
adr: C4C6, len:   210, usedby: InitPupLevel1+76
adr: C598, len:    12, usedby: InitPupLevel1+94
adr: C5A4, len:   210, usedby: InitPupLevel1+76
adr: C676, len:    12, usedby: InitPupLevel1+94
adr: C682, len:   210, usedby: InitPupLevel1+76
adr: C754, len:    12, usedby: InitPupLevel1+94
adr: C760, len:   210, usedby: InitPupLevel1+76
adr: C832, len:   704, usedby: StartNProcess+14
adr: CAF2, len:   704, usedby: StartNProcess+14
adr: CDB2, len:   404, usedby: StartNProcess+14
adr: CF46, len:    10, usedby: CStringToString+20
adr: CF50, len:    10, usedby: CStringToString+20
adr: CF5A, len:    10, usedby: CStringToString+20
adr: CF64, len:    10, usedby: CStringToString+20
adr: CF6E, len:    14, usedby: CStringToString+20
adr: CF7C, len:    12, usedby: CStringToString+20
adr: CF88, len:    14, usedby: CStringToString+20
adr: CF96, len:    12, usedby: CStringToString+20
adr: CFA2, len:    10, usedby: CStringToString+20
adr: CFAC, len:    10, usedby: CStringToString+20
adr: CFB6, len:    10, usedby: CStringToString+20
adr: CFC0, len:    16, usedby: CStringToString+20
adr: CFD0, len:    14, usedby: CStringToString+20
adr: CFDE, len:    10, usedby: CStringToString+20
adr: CFE8, len:    10, usedby: CStringToString+20
adr: CFF2, len:     8, usedby: AllocZero+12
*start*
00458 00024 US 
Date: 29 Dec. 1982 10:27 am PST (Wednesday)
From: Swinehart.PA
Subject: Re: New facilities in Teledeb
In-reply-to: Stewart's message of 28 Dec. 1982 4:13 pm PST (Tuesday)
To: Stewart
cc: Swinehart

I see 5 values in your dump that represent results of RPC calls.  I suspect these
are legit -- RName, Instance, stuff like that, but otherwise they represent leaks. 
All looked pretty reasonable, given that you accept Allocate at all.

*start*
05662 00024 US 
Date: 29 Dec. 1982 2:03 pm PST (Wednesday)
From: ornstein.PA
Subject: "Voice" section for activity report
To: Swinehart, Stewart
cc: VoiceProject^
Reply-To: ornstein

Comments?  Suggestions??
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

II.	COMMUNICATIONS

A.	Voice Project

The purpose of the Voice Project is to explore ways of integrating voice into our
research-prototype office systems.  We intend to investigate such applications as
voice message systems, display-based editors for modifying spoken "documents,"
and facilities for annotating text documents with voice comments.

Activities
 
Hardware:  A Lark (Etherphone) includes a telephone, a microphone, a small
speaker and associated box containing volume control, light, and toggle switch. 
The main electronics, which support these devices, are housed in a cabinet
approximately one foot square and four inches deep which hangs from a wall
bracket near the user's desk.     

Over the past six months the Lark's Digital-board has been rebuilt in 
printed-circuit form. Eleven copies of the PC version of that board have been
manufactured, checked out, and are now working.  The full-blown Analog board
has been designed and checked out, and two breadboard versions of it have been
built and are presently in use for system-wide testing.  Printed-circuit layout of
the Analog board is in progress and we expect to have copies of the PC board for
checkout by the end of January.  No work has been done on the Locator board. 
Design of the Etherphone case and mounting has been completed and mechanical
parts for prototypes are on order.  All electronic parts for the construction of 15
prototype units have been ordered.

We have consulted with an expert on registration of our equipment with the
telephone company and have attempted to cover the necessary items in our
design.  Over coming months we will proceed with the necessary steps to obtain
official registration.  In the meantime, we have obtained an Experimental
Identification Number from the telephone company (good for six months) which
permits us to connect experimental Etherphones to the telephone network.

Software:  A great deal of work has gone into building a Remote Procedure Call
package for the Etherphone.  This has been useful in testing and exercising the
fundamental idea of Remote Procedure Calls which, in our estimation, despite the
additional work, has proven to be an extremely valuable system-building tool.  It
has allowed us to test the Thrush Etherphone server program with a Cedar-based
Lark simulator and in general to move machine boundaries around at will.  In a
multi-machine system such as this, such flexibility is invaluable in testing
compatibility between the parts.

The basic elements of the Thrush Server are now working and have enabled us
to make phone calls between Etherphones - either by specifying the number in
the usual way on the telephone's keypad or by typing it directly to Thrush.  All
of the connection establishment and take-down protocols are working as well as
the voice transmission protocols.  Thrush can also handle calls between an
Etherphone and the regular telephone network.  The Voice File Server software
is now working and we have been able to store and retrieve voice messages
although some bugs remain to be cleared up.

In general, the software is coming along well.  We have pushed ahead with
functionality in several specific areas in order to verify the interfaces.  In order
to do this we have not spent a lot of effort on efficiency and "ruggedization" so
these things remain to be attended to.  We have, however, spent considerable
effort in providing convenient software tools for remotely controlling, exercising,
and debugging the Lark software which, residing in a small machine, is
otherwise quite inaccessible.  [S. Ornstein, L. Stewart, D. Swinehart, J. Ousterhout
(U.C. Berkeley), S. Owicki (Stanford)]  

Plans

We are presently implementing Workstation control of an Etherphone.  This
involves two parts:  first, the basic facilities in the Thrush program itself that
permit such control to be exercised; and second, a preliminary workstation
program which provides both the mechanisms for exercising such control and a
user interface for specifying what is wanted.  The Thrush part is nearly working
and a rudimentary workstation program will be implemented to test out the
mechanism.  Production of more sophisticated workstation programs and
embedding them in the Cedar workstation environment is part of the later phases
of exploration and experiment to be enabled by our current work.

Over the coming months we intend to harden all of the programs so that a
facility can be provided for real users.  Project participants will be the first
guinea-pigs to use Etherphones as their normal telephones, but before we can do
even that we must provide solid Thrush and Voice File Servers.  We are not
quite ready for that yet but expect to be sometime over the next few months.  We
intend to harden the Lark program in particular to the point where we will make
no further changes and will only fix bugs that appear.  By mid-year we hope to
be able to propogate Etherphones to all other members of the laboratory.  

After the basic facilities are in place and solid, we will build some of the more
more complex, though standard, sorts of telephone capabilities (call-transfer,
call-forwarding, hold features, attendant capabilities, etc.).  After that we will be
in a position to experiment with wholly new uses of voice communication, which
has been our ultimate intention all along.


*start*
05739 00024 US 
Date: 30 Dec. 1982 9:32 am PST (Thursday)
From: ornstein.PA
Subject: "Voice" section for activity report
To: Schroeder
cc: VoiceProject^
Reply-To: ornstein

II.	COMMUNICATIONS

A.	Voice Project

The purpose of the Voice Project is to explore ways of integrating voice into our
research-prototype office systems.  We intend to investigate such applications as
voice message systems, display-based editors for modifying spoken "documents,"
and facilities for annotating text documents with voice comments.  In order to
make this possible, we are first building a set of basic voice-handling facilities. 
These are coming along well along and regular useage should commence over
the next six months.  

Activities
 
Hardware:  A Lark (Etherphone) includes a telephone, a microphone, a small
speaker and associated box containing volume control, light, and toggle switch. 
The main electronics, which support these devices, are housed in a cabinet
approximately one foot square and four inches deep which hangs from a wall
bracket near the user's desk.     

Over the past six months the Lark's Digital-board has been rebuilt in 
printed-circuit form.  Eleven copies of the PC version of that board have been
manufactured, checked out, and are now working.  The full-blown Analog board
has been designed and checked out, and two breadboard versions of it have been
built and are presently in use for system-wide testing.  Printed-circuit layout of
the Analog board is in progress and we expect to have copies of the PC board for
checkout by the end of January.  No work has been done on the Locator board. 
Design of the Etherphone case and mounting has been completed and mechanical
parts for prototypes are on order.  All electronic parts for the construction of
fifteen prototype units have been ordered.

We have consulted with an expert on registration of our equipment with the
telephone company and have attempted to cover the necessary items in our
design.  Over coming months we will proceed with the necessary steps to obtain
official registration.  In the meantime, we have obtained an Experimental
Identification Number from the telephone company (good for six months) which
permits us to connect experimental Etherphones to the telephone network.

Software:  A great deal of work has gone into building a Remote Procedure Call
package for the Etherphone.  This has been useful in testing and exercising the
fundamental idea of Remote Procedure Calls which, in our estimation, despite the
additional work, has proven to be an extremely valuable system-building tool.  It
has allowed us to test the Thrush Etherphone-server program with a Cedar-based
Lark simulator and in general to move machine boundaries around at will.  In a
multi-machine system such as this, such flexibility is invaluable in testing
compatibility between the parts.

The basic elements of the Thrush Server are now working and have enabled us
to make phone calls between Etherphones - either by specifying the number in
the usual way on the telephone's keypad or by typing it directly to Thrush.  All
of the connection establishment and take-down protocols are working as well as
the voice transmission protocols.  Thrush can also handle calls between an
Etherphone and the regular telephone network.  The Voice File Server software
is now working and we have been able to store and retrieve voice messages
although some bugs remain to be cleared up.

In general, the software is coming along well.  We have pushed ahead with
functionality in several specific areas in order to verify the interfaces.  In order
to do this we have not spent a lot of effort on efficiency and "ruggedization" so
these things remain to be attended to.  We have, however, spent considerable
effort in providing convenient software tools for remotely controlling, exercising,
and debugging the Lark software which, residing in a small machine, is
otherwise quite inaccessible.  [S. Ornstein, L. Stewart, D. Swinehart, J. Ousterhout
(U.C. Berkeley), S. Owicki (Stanford)]  

Plans

We are presently implementing Workstation control of an Etherphone.  This
involves two parts:  first, the basic facilities in the Thrush program itself that
permit such control to be exercised; and second, a preliminary workstation
program which provides both the mechanisms for exercising such control and a
user interface for specifying what is wanted.  The Thrush part is nearly working
and a rudimentary workstation program will be implemented to test out the
mechanism.  Production of more sophisticated workstation programs and
embedding them in the Cedar workstation environment is part of the later phases
of exploration and experiment to be enabled by our current work.

Over the coming months we intend to harden all of the programs so that a
facility can be provided for real users.  Project participants will be the first
guinea-pigs to use Etherphones as their normal telephones, but before we can do
even that we must provide solid Thrush and Voice File Servers.  We are not
quite ready for that yet but expect to be sometime over the next few months.  We
intend to harden the Lark program in particular to the point where we will make
no further changes and will only fix bugs that appear.  By mid-year we hope to
be able to propogate Etherphones to all other members of the laboratory.  

After the basic facilities are in place and solid, we will build some of the more
more complex, though standard, sorts of telephone capabilities (call-transfer,
call-forwarding, hold features, attendant capabilities, etc.).  After that we will be
in a position to experiment with wholly new uses of voice communication, which
has been our ultimate intention all along.

*start*
00527 00024 US 
Date: 1 Jan. 1983 5:00 pm PST (Saturday)
From: Stewart.PA
Subject: Removal of AllocZero and CStringToString
To: VoiceProject^.pa
Reply-To: Stewart.PA

I've changed Allocate to always zero the allocated space, changed all calls to AllocZero into calls to Allocate, and removed AllocZero.

I've made a survey and found that most, if not all, instances of calls to CStringToString have literal string arguments.

I have begun replacing CStringToString(syszone, "X") by "\001\001X"

Death to Alloc!	-Larry

*start*
00559 00024 US 
Date: 2 Jan. 1983 7:53 pm PST (Sunday)
From: Stewart.PA
Subject: Lark working
To: Swinehart
cc: Stewart

There is a version that works now.  It is fairly easy to run it out of PBIs by setting up two connections to itself and then flashing the switchhook a few times.  I haven't been able to find all the PBIs but 6 of them were queued on one speaker play queue, which implies that the audio process didn't get service for quite a while or was jammed or something.  I'd like to add facilities to pin down all the PBIs at will.
	-Larry

*start*
00646 00024 US 
Date: 3 Jan. 1983 9:17 am PST (Monday)
From: Swinehart.PA
Subject: Re: Removal of AllocZero and CStringToString
In-reply-to: Your message of 1 Jan. 1983 5:00 pm PST (Saturday)
To: Stewart
cc: Swinehart

You'll find that "\001\001X" won't work, but perhaps "\001\000\001\000X" will. 
Quite possibly most of the places that use constant Mesa-style strings could use
C strings directly -- they'd have to compute the string length sometimes.  For
the Marshall functions, anyway, that's just a little more code, possibly saving
quite a bit of storage and hassle in the string bodies.

If you don't like Alloc, I don't either.

*start*
04347 00024 US 
Date: 14 Jan. 1983 8:26 am PST (Friday)
From: Swinehart.PA
Subject: Design notes: Lark watchdog timer and downloading changes
To: Stewart
cc: Swinehart, VoiceProject^
Reply-To: Swinehart

Summary of our discussion yesterday:

1. Watchdog timer
The Lark ROM will include code to kick the watchdog timer (WDT) at
sufficiently regular intervals while the monitor program is in control.  Before
returning control to some other program, the monitor will kick the WDT again;
this avoids the need to synchronize any counters with other programs.  There
will be a monitor action to inhibit the WDT refresh.  This will result in a system
reset a short time later.

2. Removal of local keyboard control of monitor
The Teledeb (Ethernet-based remote control and debugging) implementation in
the monitor is working well, and the standard Pup package also knows how to
interpret its protocol.  Therefore it seems reasonable to remote the keyboard code
and the RS232 drivers from the monitor ROM.  The Teledeb protocol will need an
additional directive causing a return to the monitor (see the downloading
discussion.)

3. Lark downloading behavior.
Lark will communicate with a sympathetic server whenever it enters the monitor.

a. No sympathetic server (Teledeb) known
When a Lark is first powered up, or when its attempts to communicate with the
last known Teledeb has failed, it will use broadcast techniques to locate one. 
This will take the form of an "I'm here" packet.
	If it works, broadcast an "I'm here" packet whose pup destination address
is a broadcast to net 3.
	If that doesn't work, broadcast a routing table request and use the first
response to locate the gateway, then route the net 3 broadcast through the
gateway.
	The first respondent to the "I'm here" request will be chosen as the
Teledeb server, and will next receive a "Here's my problem" packet, containing:
		NMI or system reset
		Internally or externally (via Teledeb) requested break
		Code (BX at break) indicating reason for break
			(or maybe the whole register bank)
		Contents of both dip switches
		Whatever else.
	Remember the Teledeb host address, along with a distinctive "seal" value
indicating that the Teledeb host is probably valid.
	Whenever a Teledeb control packet arrives, remember its host as the
current Teledeb?  I think so.  This will allow us to switch controllers, or to begin
the control process for a specific Lark from the Teledeb side, and we're all
friends here.

b. Teledeb host known
On system reset or NMI return to the monitor, if the Teledeb host looks valid, try
to use it.  We may decide with experience always to go through the broadcast
process on system reset, but it seems worth trying this way first.

c. Subsequent actions
The Teledeb server will use the "Here's my problem" information along with the
current system state (running Thrush, debugging Thrush, whatever) to decide
what to do next.  In the operational system, it will probably log the problem, if
any, download a new object file, and start it up.  In debugging modes, it will
allow the user to control debugging, downloading, and restarting, as now.

4. Teledeb changes
Teledeb needs to know how to issue the NMI and system reset request actions. 
In addition, it should include facilities for updating static values in an object
file, rather than in the target Lark.  This must include updating checksum fields
and the like.

In some cases, we'll want to issue canned sequences of actions to a Lark.  Rather
than stuffing command files into the Teledeb user interface, we should see if
little command programs that drive the Teledeb and TDX interfaces (possibly
augmented) aren't the way to go.  This is clearly the way Thrush (or some other
cooperating server) is going to want to deal with Lark downloading, in any case.

5. More switch bits
All of the dip switch positions but one have fixed interpretations.  It might be
useful to have a couple of bits that indicate configuration options or the like --
perhaps even whether downloading or debugging should be the rule when a
break occurs.  We've decided to interpret the high order two bits of the host
address switch as configuration bits.  The software will uniformly assume that
the high order two host bits are "01".  This limits host addresses to [100B..200B),
which is to say [40H..80H).
*start*
00455 00024 US 
Date: 14 Jan. 1983 8:31 am PST (Friday)
From: Swinehart.PA
Subject: More selective tones events
To: Stewart
cc: VoiceProject^, Swinehart
Reply-To: Swinehart

My candidate for a new Lark interface is on [Ivy]<Swinehart>Thrush>Lark.mesa. 
I went back to my first suggestion and included a "notify" field following the
"queue" field in the GenerateTones and Feep procedures.  The tones event
should occur only when "notify" is TRUE.

*start*
00997 00024 US 
Date: 18 Jan. 1983 2:47 pm PST (Tuesday)
From: Stewart.PA
Subject: RPCBonsai
To: VoiceProject^.pa
cc: Stewart

Design of a non-interpretive client interface to C RPC for Lark.

Clients will deal directly in RPC packet images.

The sequence for calling will be;
	Construct call packet image
	Make call (returning PBI containing results)
	Inspect results
	Release PBI (using special call to do DISABLE)

struct PBI
*CallBonsai(interface, args, arglength, seal);
	struct ImportInstance *interface;
	int *args, arglength;
	struct Seal1 *seal;
args[0] should have the Swabbed procedure index
arglength is in words
seal is for the use of CallBonsai to set up the signalling correctly


CleanupCall(seal)
  struct Seal1 *seal;
  {
  UnwindPkt(0,0,seal);
  };


For exported interfaces, the BonsaiDispatcher calls procedures directly with
a PBI.

The client procedure inspects the arguments, writes any results into the same PBI and returns the length field for hte reply packet.

*start*
00400 00024 US 
Date: 21-Jan-83 18:26:57 PST
From: kolling.pa
Subject: On contemplating Dan Swinehart's desk
To: CSL^, VoiceProject^
cc: kolling.pa
Reply-To: kolling.pa

I think that I shall never see
a telephone as sweet as thee.
So cute, so neat, all baby blue
you belong right next to a bronzy shoe.

Which leads me to ask,
what do you think:
Shall the girls' phones all
be powder pink?


*start*
01183 00024 US 
Date: 24-Jan-83 17:18:10 PST (Monday)
From: Halbert.PA
Subject: Morse Code tool for Dandelion Tajo
To: HamRadio^.es
Reply-To: Halbert.PA

I have written a Tajo tool that sends code through the Dandelion speaker. It's useful for making code practice tapes, and can also be used to annoy your officemates.

MorseTool can send selected text, and can also send random code groups consisting of characters chosen from the current selection. Character speed and spacing are independently settable (e.g. so you can send 13 wpm characters with 5 wpm spacing), Weighting and pitch are variable.

You can find it on:

	[Iris]<Halbert>MorseTool.bcd
			MorseTool.mesa
			MorseTool.doc

The .doc file describes it in detail, and includes some suggestions for use. But the user interface is fairly clear anyway.

MorseTool.bcd is compiled for Pilot 8.0. The only slightly obscure interface it uses is <APilot80>Faces>Friends>BeepFace.bcd, so it should be easy to recompile it for 9.0 or 10.0, I think.

I solicit suggestions or bug reports. This is my first Mesa program, so be kind.

I have successfully made useful code practice tapes.
--Dan, N6??? (waiting for the FCC)
*start*
01805 00024 US 
Date: 3 Feb. 1983 8:37 am PST (Thursday)
From: Swinehart.PA
Subject: Welcome back
To: Stewart
cc: Swinehart

to electronic PARC.

Analog boards arrived, one is stuffed and it fits in the box.  Beautiful.  When
we tried with the digital board in your office and Thrush, it didn't work
(immediately asserted off-hook, for one thing, but no dial tone was found
anywhere.)  Rather than figure out how your test program works, we decided to
wait for you.

Thrush/Finch/Bluejay are functionally about where we wanted them for a
demonstrable system.  Finch (workstation program) still needs a way to record
and play back messages compatible with the facilities available from the phone. 
Much hardening is now necessary before we can go on to the next thing. 
Bluejay still exhibits some annoying problems, some difficult to deal with.  We
need to get you and John in (on opposite sides of?) the same room.

Downloading has been flakey.  Sometimes it takes 8 to 20 tries to get started. 
Once started, things are fine.  When my Dorado has trouble starting one Lark, it
also has trouble with the other one.  Packets seem to be emerging on the 1.5 side,
but are not responded to until things begin to work.  Weird.  Since the code is in
the ROM, I haven't been tempted to investigate further.

Dorado scheme will be to install the microcode on the disk and boot (the Alto
partition) from there, rather than to boot from the network.  From the Alto
partition it is straightforward to boot Cedar.  It could be set up to boot Cedar
automatically, too, but then one could never get to the Alto side.

Rant back if you like.  You can't hurt me from there.  Say hello to David and
whoever else for me.  Check out how the Altos are being used, if at all.  Endear
yourself to 6-A candidates?

Dan

*start*
01688 00024 US 
Date: 3 Feb. 1983 3:40 pm PST (Thursday)
From: ornstein.PA
Subject: PC Analog Board Eureka!!!
To: Stewart
cc: VoiceProject^
Reply-To: ornstein

The PC analog board appears to work - and sounds terrific.  Although there were
some gaffs, they appear to be externally compensatable.

1. Mike and I apparently managed to get the pin assignments in the modular
cable connections backwards. 

	In the 8 pin Teleset connector, 1 and 8, 2 and 7, 3 and 6, and 4 and 5
	were swapped.  In the 6 pin Telewall connector it was 1 and 6, 2 and 5,
	and 3 and 4.  But since some clever fellow assigned the signals for these
	devices pairwise symmetrically to these pin-pairs, the reversal doesn't
	(appear to) matter for those two connectors.  Is that right - i.e., can we
	simply leave these reversed and just swap the pointy-box pin numbers on
	the EAP drawings?

	In the case of the Speaker Box, the reversal DID matter (since there is no
	such symmetric pairwise association), and Mike compensated by reversing
	the connections at the speaker box end.  The speaker box drawing and all
	other speaker boxes will have to be corrected.  The two breadboard Larks
	are backwards but should be replaced shortly with "real" units so I don't
	see much reason to alter them. 

2. The only other problem we found was that (as you surmized) somewhere
along the line, T1Clock plus and minus got reversed.  Mike swapped those wires
in the inter-board jumper cable, whereupon BOOM, everything worked.  Since
you can compensate for this one by reprogramming the Timer chip, it looks as
though we may be able to live with the Analog board as is. Right? 

Wunderbar, and congratulations!!

S. 
*start*
01064 00024 US 
Date: 4 Feb. 1983 11:56 am PST (Friday)
From: ornstein.PA
Subject: Solicitation of Expert Review
To: Levin, Schroeder, Birrell
cc: Stewart, Swinehart, ornstein, Taylor

The Voice project is gradually arriving at some sort of watershed and it feels like
a good time to be getting together with some relevant pros to review and discuss
our software architecture.  We have a group of "Voice Vigilantes" with whom we
discussed the design early on, but by now the nature of the problem has
narrowed and a smaller, informal, more focussed group seems more suitable. Roy
and Mike were in the original group; Andrew, you will be happy to know that
you are substituted for the combined forces of Lampson, McCreight, Thacker,
Taft, Basket, and Dalal!  In the interests of keeping it small we'll also leave out
the consultants on the Voice project.

If you three can manage to give us an hour or two, I propose Thursday, Feb 10,
10 AM to noon in the CSL Alcove.  Please let me know if you're willing, and
whether that time is OK.

Thanks,

Severo    
*start*
02556 00024 US 
Date: 6 Feb. 1983 4:30 pm PST (Sunday)
From: Stewart.PA
Subject: Analog board checkout
To: VoiceProject^.pa
cc: Stewart

1.   T1Clock is upside-down.  T1Clock+ and T1Clock- must be reversed.

The nets involved are

	Viking 044 -- U5-9			T1Clock+
	Viking 043 -- U5-10		T1Clock-

2.   R9 (near U2) should not be stuffed.  This is an assembly option I didn't tell you about.  If R9 is left out, then crossbar source 4 is silence.  If R9 is installed, then crossbar source 4 is the output of Codec 1 boosted 3 dB (which we don't need).

3.   Ring detect doesn't work.  My bug.  The PC board ring detect circuit is different from the breadboards and I never tried the new one.

The PC board detector shares the diode bridge with the voice path.  C40, the ring detect DC blocking capacitor is on the DC side of the bridge, which doesn't work.

There are (at least) two ways to fix this.

	A)  Replace C40 with a 60 - 100 volt zener.  This will block the on-hook DC but permit rectified ringing voltage to pass.  Also remove C41.

	B)  Replace C41 with a 1N4148 connected to protect the opto-isolator. (Diode arrow pointing towards the + mark for C41)  Rewire the PC board so that the ring detecotr is on the input side of the diode bridge.

I prefer method B.  I have successfully tried it on the breadboard.  The PC board is laid out in a way that makes this change difficult. One side of the wiring can be fixed with two trace cuts and two blue wires.  The orther side can be fixed by connecting one end of C40 to a different (but nearby) terminal on the component side.

4.   The telephone interface diodes are the wrong kind.  1N4004s are only 400 PIV.  We want 1000 volt diodes.  I think the correct part number is 1N4008.

(One could argue that the gas tube surge protectors will protect the 400 volt diodes, and that there are two in series, but the 1000 volt ones are the same size.)

5.  If the PC mount modular connectors can be obtained in black plastic rather than grey plastic, the assembled Larks will look a little better.

6.  The diode bridge has no way to discharge!  The DC side of the bridge goes to C40 (see 3) and to the OffHook relay.  When the phone rings the DC side charges up to 150 volts or so.  This probably doesn't hurt anything, but it is inelegant.  With the fixes proposed in 3B, the bridge can be moved to the switched side of the offhook relay and the problem won't exist.  This also removes the requirement for 1000 PIV diodes, since the off-hook voltages are held to 35 volts by the Zener.

	-Larry