// Copyright (C) 1984 by Xerox Corporation. All rights reserved. // DicentraIntro.doc, HGM, 28-Dec-83 3:01:13 What's a Dicentra? It's a D machine on a Multibus. We built it for use as a gateway. The flexibility of the Multibus allows you to add another ethernet board by setting the switches and plugging it in. A Dicentra can also be used as a high powered widget controller. Many manfacturers provide Multibus interfaces to their widgets. With the Dicentra, you get to write your software in Mesa rather than struggling with a brand X development environment. A Dicentra not a workstation. When UMC is critical, as it is in workstations, you have sacrifice the flexibility of a bus structure. Besides, we don't yet have a disk controller or a display controller. Hardware: A basic system is 4 boards: a CP (processor), a Misc board, a Memory board, and an Ethernet controller. You also need a chassis, a card cage, a power supply, and an MP. The microcode and Germ come from PROMs. The Mesa program gets loaded from a boot server on the ethernet. The Dicentra CP is essentially a DLion CP without tasking, and PROM rather than RAM control store. Except for IO operations, it runs DLion microcode unchanged. The CP board has sockets for 8K of microcode. The basic cycle time is 125ns per instruction. Memory operations introduce wait states. A simple calibration program runs at 73% of a DLion. Most of the interesting parts of the misc board are accessed via an internal Z bus. On the Z bus there are several CIO chips that are used to generate the clocks and interrupts needed by Mesa. Their IO ports are used to access the germ (3 EPROMs) and the parameter file (2 EEROMs). There are also 4 SCC chips to drive 8 RS232 lines. The SCC is net follow on to the SIo in the DLion. It contains two internal baud rate generators, and supports ASYNC, BISYNC, and SDLC. The first 2 lines also have V35 interfaces for use with 56KB modems. (This saves a $400 adapter box.) 3 more CIO chips are setup for use with RS366 (dialers) and/or general purpose IO. There is also a DES chip for encryption. The memory board contains 512K words. It does not support byte opertions. (This may be a fatal constraint if you want to coexist with 8086 or 68000 systems or simple disk controllers.) The access time is 300ns, and the cycle time is around 400. There is a parity bit on each word. Although the Multibus supports up to 23 bits of word addresses, the format of the Map restricts useful memory to 20 address bits (2 memory boards). Additional memory must live in hyperspace and be accessed with special microcode. We buy the 10MB Ethernet controller from 3Com. It has on board buffering for 2 complete receive packets, and one transmit packet. The software gets an interrupt on each collision, but the hardware contains a counter to assist with the backoff timing. It's not wonderful, but we can get them and they work. The 3MB Ethernet boards have turned out to be more of a problem than we expected. We can't get any more and the few that we have don't quite work right. David has all the info from Stanford. Things will get better soon. There is also a ControlStore/Debugger board. It is necessary for debugging microcode and can also be used as writable ControlStore. It contains 16K of control store that can be loaded either via the Burdock interface or via the Multibus. The debugger half of the board contains a simple history buffer. It's invaluable for debugging microcode and a large class of hardware troubles. Software: There are 3 parts of the software: the microcode, the germ, and the environment the client program gets to use. The Klamath microcode seems reasonable stable. The normal microcode package I use fits in 4K and includes SDLC support for phone lines. Some time I'll probably try to squeeze in support for TTYs. The germ can boot from a 10MB net, a 3MB net, or a phone line. The germ gets the default boot file and location from the EEROM. The Alt-Boot button can be used to manually override this. The main environment is based upon UtilityPilot. Any reasonable program that doesn't use a disk or display (or unreasonable amounts of VM) will work. Several months ago I could get a Gateway into 256K words. Since then the 512K Memory boards have arrived and I have been tossing in any modules that looked interesting. Now (13-Nov) I'm down to 900 free pages. If you have all the pieces on your disk, you can be running a new boot file in 5 minutes. TeleDebugging works fine. I have a hack that gets you to the debugger if the Alt-Boot button is down for several seconds. The main problem with running a PupGateway without a disk is that people expect a boot server as part of the package. So far, we have ducked this by including a fake boot server. It "forwards" boot requests to a server on another net. Booting through gateways works fine. Configuration: The flixibility of the Multibus makes it easy to assemble systems that don't make sense. There are 3 areas that limit workable configurations. The first limitation is slots, cooling, and power. Our engineering model Dicentras have 9 slots and plenty of power. Cooling may be a problem. The second limitation is device latency. The 3Com 10MB boards have on board buffers for 2 receive packets. We will miss an occasional packet, but that covers the normal hard case. The current SDLC microcode can keep up with 2 active 56KB lines. 8 lines at 9600 should be easier. (A DLion starts to mangle packets on a single line at 45KB.) The third limitation is CPU saturation. By this I mean running out of CPU cycles for hundreds of milliseconds rather than the microsecond time scale covered by the previous paragraph. Currently, the CPU will keep up with 2 56KB full duplex lines. That's 100KB of throughput in the phone line to phone line case, or 200KB in the phone to ethernet case. Alternatively, a Dicentra can forward 400 to 500KB of ethernet to ethernet traffic. (That's about the same as an Alto or Dolphin.) The DES chip can be driven at 1.4MB, so encrypting phone lines doesn't have a serious impact on throughput.