*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.