The telephone sits on the desk; the microprocessor unit fits in a shoebox underneath the desk.

The microprocessor unit can be logically separated into two parts:

Bob Belleville is currently building hardware that corresponds to Part 1 and we are hoping simply to use that. His device will sit directly underneath the telephone and interface to it. (It is the possible third physical piece mentioned above.) If we copy his hardware directly, packaging and all, we will end up with some unnecessary things (most notably a tiny tape recorder). However it would save us considerable work. If we can't use his device directly (not ready in time or not suitable), we will at least be able to copy relevant parts of his design into our microprocessor unit. For the present we are planning to use his device. [See the Appendix.]

HARDWARE

Figure EPBlock.sil shows a block diagram of the Etherphone II. In order to get under way, we decided not to wait for either Alan Bell's or Intel's or AMD/Mostek's proposed 10 Mbit Ethernet controllers. Instead we decided to use the 1.5 Mbit SLC chip designed by the MEC for use in the Lotus copier program. We understand that this chip can run faster than it's 1.5 Mbit advertised speed. We understand that the limiting factor in the design has been fixed, and that 3 Mbit chips will be available soon. We have in hand a number of the 1.5 Mbit chips and are planning to put up a Gateway between the Parc (3 MB) Ethernet and a special 1.5 Mbit local Ethernet. (Apparently a single jumper on the Alto backpanel can halve the speed of one of its Ethernet controllers). If the 3 Mbit chips become a reality before we're ready to go, we will forget the Gateway. A diagram may be found as Figure Etherphone3.sil.

Our choice of the SLC biased our choice of microprocessor. The SLC was designed to talk to an Intel 8085 bus. We might, therefore, simply have chosen to use an 8085, an 8 bit machine. But there is a faster, more modern machine, the 8088 which internally is a (16 bit) 8086 but externally (its bus) looks (approximately) like the 8 bit 8085. We might have used an 8086 but did not feel that the additional potential bus bandwidth (16 bit bus vs. 8 bit bus means twice as fast) was worth the additional complexity in bus hardware. The 5 MHz 8088 completes a bus cycle in 4 clock cycles, a byte every 800 ns, which gives 10 Mbit/s bus bandwidth. That is insufficient for the 10 Mbit Ethernet, but by the time there are 10 Mbit Ethernet controllers, there will be faster versions of the 8088. There is, in fact, a planned 8 MHz version of the 8088 although most of the peripheral chips won't run that fast. Alternatively, we could go to the 8086 16 bit bus and still run the same software.

The bandwidth argument goes as follows:

In the worst case, both members of a phone call may talk at once. So the bus must service 8 x 64 Kilobits = 256 Kilobits per second. Of course this is average speed and we haven't included the processor's use of the bus to run the program or any other Ethernet traffic (control packets, conferencing . . . ). However, even for a 5 MHz machine, 256 KBits seems like a small part of its bus bandwidth.

The SLC includes its own quite nice channel logic. It will use a DMA channel only to multiplex its bus access requests with those of the other devices; other than that it doesn't need any DMA facilities since it handles the bus itself. The SLC has independent DMA controllers for transmit and receive. Each controller interprets a chain of control blocks in memory.

We are planning to use the Advanced Micro Devices Z8068 encrypt/decrypt chip. This chip can run very fast, so we will have to slow it down to prevent it from hogging the bus. It will operate through use of two DMA channels, one for input and one for output.

We plan to use the Intel 8237 DMA part (which has a convenient "autoinitialize" feature that restarts data transfer at the beginning of a buffer when the buffer fills/empties). Each DMA part offers 4 independent channels and the parts can be cascaded using one of the channels. Two chips thus provide 7 channels.

Digitized voice arrives from (and/or goes to) the codec at one 8-bit sample every 125 ms. We will use DMA channels to get it into the memory. In fact we are thinking of using two channels for each direction. We'll assign two buffers to two DMA channels for (say) codec input. When the first buffer fills from the codec, the hardware will swap channels and the codec will start filling the second buffer. The first will be autoinitialized in preparation for refilling from its beginning, but will remain inactive (until after the second has finished filling). Meanwhile an interrupt causes the program to deal with the first buffer (passing it through the much faster encryption chip before the codec channel swap again needs the first buffer).

So the 8 DMA channels (two chips) we expect to use are:

In addition to a small amount of bootstrap ROM we expect to utilize about 4 K bytes of ROM (RAM during development) for program and 4 K bytes of RAM for buffers. Our present intentions are to use mostly RAM and to include sufficient ROM for an Etherboot loader and perhaps teleswat functions. We are planning to use only static memories.

We intend to have two RS-232 interfaces (there is a convenient dual channel compatible chip). One channel will be for controlling the audio-handling hardware (Belleville's hardware). The other is for communicating with a mother ("Midas") Alto at first, and later to communicate with the keyboard/display of the Etherphone II B. We plan to download and interact with the Etherphone via the Ethernet after the kernel is working.

We will use the Intel 8259 interrupt controller which includes priority logic and interrupt vectoring.

We have in hand an SDK-86 (borrowed from Belleville) which is a small Intel 8086 prototyping kit including a monitor in ROM. We are able to speak to the 8086 from an Alto via DLS and an RS-232 interface included on the board. The ROM monitor on the board knows how to display and modify memory and registers, how to set breakpoints (hexadecimal), and how to load a program in Intel hexadecimal absolute loader format.

We plan to experiment with the more complex peripheral chips by wiring them up on a wire-wrap board and connecting them to the 8086 with ribbon cable to a wire-wrap Augat board. (The SDK-86 includes bus drivers for an external bus.) Our plan is to try to replace the 8086 with an 8088 while retaining the bootstrap/monitor ROMS. Once we understand the operation of the DMA parts, the SLC, and perhaps the Encryption chip, we will build a complete 8088 system on a Dorado stitchweld board. Mike Overton has completed a chassis holding a single Dorado board. The reason for the two level prototyping structure is to avoid too many reweldings of the stichweld board.

We have not selected a keyboard/display for the Etherphone IIB. We may try to obtain or borrow a Sunrise for the task.

SOFTWARE

We plan to use the 8086 assembler, linker/loader, and C compiler developed by Bill Duvall for Bob Belleville's Cub project. The assembler is free, but the C compiler is not owned by Xerox, although several groups (Belleville, Webster) are using it. A license will be $1000, including some degree of support. The compiler is not quite Unix version 7 compatible, it lacks things like bit fields in structures.

Since our debugging will have to be at the level of assembler listings, hexadecimal breakpoints, and load maps, we will try to keep the program in the Etherphone very simple.

Some portions of the grant universities' C Pup package may be useful for the Etherphone software. Bcpl to C transliteration is straightforward and we already have a working bcpl Etherphone 0 program on the Alto.

SUPPORT

We have a friendly Intel salesman, who is providing samples for most of the stuff we need and supplying us with some very useful application notes and gotcha sheets on the various parts.

Bob Belleville has been very helpful in lending us the SDK-86, supplying us with all the useful parts of his Cub software, and to some extent, in incorporating some of our needs into his thinking for the "voice box."

We have had good conversations with Simon Lau, an engineer working for Belleville on the voice box.

We (finally) located the right people at MEC and have learned enough about the SLC to be confident that we can make it work. In particular we now understand the assumptions that the SLC makes about the design of the rest of the microprocessor system.

Bill Duvall has an office in building 96 and will be close enough to help with development tool problems, at least for a while.

Dave Boggs has agreed to help in setting up a 3 Mbit to 1.5 MBit Ethernet gateway, should we need one.