[Indigo]<Voice>Stewart>EP1.bravo!1

We are talking about an Alto class machine. The fundamental requirements are that the processor pass data between the audio and the Ethernet at 64,000 bits per second in each direction at the same time. Additional cycles are needed to handle the user interface, and some level of other Ethernet communications (call management functions).

Telephone industry compatible speech or better. Telephone compatibility means 8000 eight bit samples per second, mu-255 encoded. Better means more bits with a linear encoding or more samples per second, or both; for example 12 bit linear encoding at 10K or 12K samples per second. (Mu-law is equivalent to 13 bit encoding at low signal levels, somewhat less at high signal levels.)

For mu-255 encoding, either a single chip codec or a 12 bit linear A/D and D/A seem appropriate. If the linear D/A is used, then table lookup translation of mu-255 coded bytes would be used. Single chip codecs will only work at 8000 samples per second.

An additional hardware requirement is for silence detection. In the Alto-auburn world, the microcode returns the sum of the absolute values of all the samples in an audio control block. This value is close enough to the sum of squares to be useful for silence detection. For a microprocessor, if we cannot afford to look at every sample, then this function must be hardware. Of course, the silence detector can be an analog energy detector!

It seems likely that there will be several audio sources/sinks around. Easy examples are the Telco line from the wall, the user’s handset, a handsfree telephone, a speaker, recorder jacks, etc. The audio peripheral need adequate analog switching or relays or digital conversion to freely connect these devices.

At least a 12 button phone industry keyboard is required, suitably interfaced to the processor. In principle, we could actually use a DTMF pad plus a DTMF decoder, but a switch array seems cheaper. The processor will probably want to synthesize DTMF for user-feedback is a switch array is used. (Note that the KTS proposal requires outpulsing or out-DTMFing anyway). In a system with enough common equipment, the DTMF receiver could be common, elsewhere on the net!

For higher levels of functionality, digital output is required, from a few lights to a single line display, to a several line display. The user input could be anything up to a full typewriter keyboard or touch-panel. (A several line display plus keyboard gives written message capability too.)

The Auburn board was designed for the Alto II, but there is no particular reason why it will not work on an Alto I, provided that Mesa is not used. (Mesa uses up the RAM, so no processor devices can be used.) The Auburn board is a heavyweight device. It provides 12 bit linear coded audio at variable sample rates, and includes a substantial amount of digital and analog switching. It includes microphone/speaker, telephone (4-wire), and line levels. It includes enough digital switching for a DAA and then some. It includes a touch-tone detector and silence detector. It does not include a hybrid or AGC, which are needed for 2-wire devices. The Auburn system includes microcode for sum of absolute value silence detection, for mu-law encoding, for tone generation, and for 16 Kbps ADPCM. Auburn seems to do a little more than needed (variable sample rate), but in general, its extra functionality is not in those directions we find important.

Another possibility is the CAT interface, which is a single codec audio interface for printer ports. It can be used throught the Diablo port of an Alto I, but does not provide any audio switching or digital switching capabilities.

The Alto comes equipped with an ethernet controller, memory, and a processor. It also comes with a keyboard, which could be used for user input. Use of the display for user output is less interesting, unless we can resist the temptation to use more than, say, six lines. (Use of the display also requires a font, etc. etc.) We should probably not use the Alto disk.

Assuming use of Auburn on the Alto I, the software options are reduced basically to bcpl. Bcpl comes with a Pup package for communications, an operating system, timers, multi-processing, debugger, etc.

If we can restrict ourselves to live within the functional capability of the eventual Etherphone II, perhaps by discarding the Alto display and disk, then the use of the Alto I appears to allow us to start work immediately on the ``interesting’’ work of protocols and management rather than dilute our efforts with hardware and development environment work. We still need the analog hybrid and connection to the phone company.

The use of a standard 16 bit microcomputer also has its consequences. Basically the microcomputer is a lot closer to the eventual Etherphone II than the Alto I, but a substantial amount of work is needed to get anything working.

Requirement for ethernet communications very nearly reuires the use of the Stanford (SUN terminal) multibus ethernet controller. There are other possibilities, the Intel chip (1982 at the earliest), the VLSI systems area (many months at least), the Intel board level product ($4000), and the MEC controller (unknown, 1.5 Mbps), but none of them seem very attractive.

There are 8086 multibus single board computers and Z8000 SBC available now for around $1000. The Stanford 68000 board will probably be available in several months if we decide we want them. There is at least one other 68000 multibus computer on the way. The 68000 systems are likely to be at least $2000. Given the performance capabilities of these machines (don’t forget the NSC16000 and TI9900), there is no particular reson to choose one of them.

The 8086 has always seemed more popular arund Xerox, probably because it was available first. There are several projects around which use it. There is a report of a C compiler and there is for sure an assembler. Webster intends to build ethernet printers using the Stanford multibus ethernet controller and an 8086 SBC.

No matter what we do, we would need audio hardware for such a system. We will need it anyway for the eventual Etherphone of course, but that will be a fully integrated design probably with no bus, while this device would need to speak multibus protocol (probably). One disadvantage of microcomputer audio compared with the Alto is that since there is no micro-machine multiplexing (TASK) going on, the microcomputer audio interfacig will need to be buffered.

The best looking development environment for the 16 bit micros, independent of the one chosen, seems to be Unix and C, but we would have to live with a poor development environment and few packages compared to bcpl and swat. If we use C, we have a Pup package of sorts, from Stanford, although we might have to rewrite it to talk 8086 interrupts or something.

Resolved: Build two to five Alto I based Etherphone I’s and thus get started with the protocol and management problems while off to one side pursue the design of Etherphone II, a 20-40 chip integrated machine.