info-mac@uw-beaver (02/08/85)
From: Bill Croft <croft@safe>
---seagate.ms (delete the leading X's)
X.na
X.TL
XStanford Ethernet Applebus Gateway (SEAGATE)
X.AU
XBill Croft
X.AI
XStanford University
XMedical Center
XSUMEX Project *, rm TB105
XStanford, CA 94305
Xcroft@sumex.arpa
X
Xbeta release, 1/85
X.AB
XThis note explains how to make your own gateway between
Xethernet and applebus. Such a gateway allows UNIX (or other)
Xsystems on the ethernet to act as
X.I servers
Xfor the Macintosh.
X.AE
X.NH
XIntroduction
X.PP
XThis note describes SEAGATE, a
X.I gateway
X(Apple term:
X.I bridge)
Xthat connects an ethernet using the DARPA
X.I "internet protocols"
X(IP), to an applebus using Apple
Xor IP protocols.
X.FS
X* SUMEX-AIM (Stanford University Medical Experiment in Artificial
XIntelligence) is supported by the Biotechnology Resources Program, National
XInstitutes of Health.
X.FE
XThe IP protocol family was chosen because many campuses
Xand engineering groups are using it on their ethernets; most such
Xgroups have access to Berkeley UNIX.
XWith such a gateway in place, it becomes possible to
Xcreate UNIX server daemons to provide file, printing, mail, etc.
Xservices for the Macintoshes.
X.PP
XIn addition, it would be possible for the UNIX systems to become
Xintegrated into a
X.I "Macintosh Office"
Xsuch that UNIX users could access Apple provided services such as
Xprinting on a
X.I LaserWriter
Xor sending mail to Macintosh users via an Apple file server.
X.PP
XThis distribution of SEAGATE provides all the information and
Xsoftware you should need to setup your own gateway.
XPlease bear in mind that this distribution is not 'supported'
Xand that we can't give extensive help about the mechanics of
Xputting your gateway together. I would like to hear about
Xbug reports or enhancements however.
X.NH
XProtocol packages / servers
X.PP
XUNIX provides a large number of IP based servers. With
Xa stripped down C based IP package, many of the UNIX user level
Xprograms (such as TELNET and FTP) could be ported over to the
XMac straightforwardly. Alas, such a package does not yet exist.
X[I could envision creating such a package by sniping sections out
Xof the 4.2 BSD UNIX kernel].
X.PP
XWhat does exist currently is a port of the MIT IP package
X(for the IBM PC)
Xto the Macintosh. This was done by Mark Sherman of Dartmouth in
Xthe summer of 84. Since there were no commercial C compilers
Xavailable at the time, Mark transliterated the MIT code from C
Xinto Workshop Pascal. At this writing, the TFTP
X(trivial file transfer protocol) and TIME
X(fetch time-of-day from server) programs
Xfrom MIT have been ported.
XThese programs work correctly between Macintoshes, or
Xthrough the gateway between a Macintosh and UNIX.
XWritten by MIT, but as yet unported
Xare the TCP and TELNET packages.
X.PP
XWhile this porting was a large and admirable project,
XI am not sure that it is the right base to build Mac IP services
Xupon. For one thing, the MIT TCP implementation (in the original C)
Xis incomplete and cannot handle data streams in both directions (it's
Xonly good enough for TELNET, where the sending stream is low volume).
XMy hope is that someone will take a relatively full and debugged
XIP package and adapt it to the Mac, all in the C language.
X.PP
XMeanwhile, the gateway provides another alternative. All Apple services
Xon applebus are based on the applebus datagram protocol, called DDP
X(datagram delivery protocol). In addition to passing IP packets
Xback and forth, the gateway will do a small amount of protocol
Xconversion: if it receives a DDP from the applebus
Xdestined for the ethernet, it will 'wrap' it with an IP/UDP header,
Xdoing appropriate address and port number conversions. This
Xallows Apple DDP services to be written as UDP daemons on UNIX,
Xwithout requiring any UNIX kernel changes.
X.PP
XConversely, a UDP
Xpacket received by the gateway from the ethernet will be
Xconverted to a DDP (by stripping the IP/UDP headers) if the UDP
Xdestination port number matches a certain 'magic number'.
XWhile these protocol conversion functions are currently compiled
Xinto the gateway, and easily altered, one could also imagine
Xthem being selected dynamically based on any packet fields (such
Xas host address). This would allow for hosts that understand
XDDP packets directly at the kernel level.
X.NH
XAddressing and routing
X.NH 2
XIP 'nets' versus 'subnets'
X.PP
XThe gateway can be configured to treat each (ether/applebus) cable
Xas a separate IP 'net' number, or as separate IP 'subnets'.
XUnless you are at a site which implements subnets, such as Stanford,
XMIT, or CMU, you will probably use plain 'net' numbers.
X.PP
XAs mentioned above, the gateway can translate DDP addresses (2 bytes
Xof net number, 1 byte of node number) to IP addresses (4 bytes total
Xfor both net number and node number). When subnets are NOT used,
Xa mapping table inside the gateway is used to convert between
Xnetwork/node numbers. The information to setup this table is
Xin the
X.B Configuration
Xsection below. If your site does not use subnets, you can probably
Xskip or skim over the next couple sections below.
X.NH 2
XSubnets
X.PP
XAn IP address can be divided into two parts: the network number,
Xand the 'local address', which is the part not used for the network
Xnumber. For example at Stanford, our net number (for the
Xwhole campus) is 36, so our addresses look like: 36.XX.XX.XX.
XWithin Stanford, we can use the last three bytes anyway we wish.
X36 is an example of a 'class A' network number, which is one byte
Xin length. There are also class B and class C network numbers,
Xwhich are two and three bytes in length, respectively.
X.PP
XA large organization is likely to have many cable segments
Xcomprising its one IP network number.
XTo help gateways and hosts within such a network, it is useful
Xto adopt a 'subnet' notion.
XIn this scheme, one of the 'local address' bytes refered to above,
Xis taken over by the 'subnet number'.
XThis subnet number can then be used by gateways (and/or hosts) to
Xlocate the particular cable segment on which the destination host is found.
XAt Stanford we use the second byte of the IP address; for example,
X36.12.00.05 would refer to local host address 5 on subnet (cable) 12
Xon network 36.
X.PP
XWhen the gateway is configured for subnet operation, each applebus
Xcable segment (DDP network number) is assigned an
XIP subnet number. For example, a given IP subnet number (12 in
Xthe example above) is mapped onto the same applebus DDP network
Xnumber 12, and vice versa. The position of the subnet byte
Xwithin the IP address (second or third byte) can be altered
Xwith configuration parameters.
X.PP
XFor IP hosts sitting on the ethernet or applebus,
Xthis 'subneting' requires no modifications to
Xtheir IP network code.
XThis is because the gateway participates in the ARP broadcast protocol
Xused by a host to find a 'hardware address' (6 byte ether, or one
Xbyte applebus), given the IP address.
XFor example, if an ethernet host with address 36.44.00.01 wishes to
Xfind applebus host 36.12.00.05, the ethernet host broadcasts an ARP
Xsaying in effect 'who has IP address 36.12.00.05'.
X.PP
XThe host being sought would answer directly if it were on the same
Xcable, but it isnt. Instead, the applebus gateway sees that someone
Xis asking for an address on subnet 12 (his own applebus segment).
XSo the gateway answers the ARP, making the ethernet host
XTHINK the desired host has responded.
X.PP
XThe gateway does this ARP stuff in both directions: ether hosts looking
Xfor applebus hosts are guided in the right direction. Applebus hosts looking
Xfor a subnet number OTHER THAN the applebus subnet number, are guided over
Xto the ether side.
X.NH 3
XSubnet addressing limitations
X.PP
XGiven the small size of applebus segments, isn't devoting an entire
XIP subnet to each segment somewhat 'wasteful'?
XFor example, here at Stanford we have already used 30 or so of our
X256 possible subnet numbers, for ethernet cables. If we have already
Xgot this many ethernets, imagine how many applebuses could pop up.
X.PP
XI dont know what the answer is. The IP address space is awfully
Xtiny. There are only 128 class A networks, and 16000 class B numbers.
XThere are two million class C numbers, but these are useless for
Xmost subnet schemes.
X.PP
XIf you are not officially part of the DARPA internet, you can
Xpick any class A or B number that you like. But this
Xseems rather anarchistic. Perhaps the new ISO protocols
Xhave the answer: I have heard they allocate a dozen bytes or so
Xfor the internet address. This seems more in line with the
Xexplosive growth in network interconnectivity we are seeing.
X.PP
XCertainly the most natural mapping between physical cables from
Xone protocol family to another, is to use part (or all of) the
Xnetwork number fields in each family (as we have done).
XHowever the scarcity of IP subnet address space may force other approaches:
X.IP 1 3
XThe gateway could make its
Xapplebus hosts look like part of the same subnet that is used
Xby the ethernet side of the gateway.
XThe gateway could do this by responding to ARPs for a subrange of the hosts
Xon a given ether subnet.
XThis would complicate the protocol and address conversion issues.
X.IP 2
XIn a class B subnet scheme, there are 16 bits of address left up to
Xthe local administration. Perhaps we should be partitioning these
X16 bits in a way other than 8 bits of subnet and 8 bits of host.
XPerhaps 10 bits of subnet and 6 bits of host would be more realistic.
X.NH 2
XRouting protocols
X.PP
XThe gateway broadcasts an applebus RTMP (routing table maintenance
Xprotocol) packet every 30 seconds. This informs the Macintoshes of
Xthe DDP network number of their applebus cable.
X.PP
XWhen routing a packet, if the IP (major) network number
Xof the destination does not match that of any interface,
Xthe packet is forwarded to a 'default' gateway specified at configuration time.
XIn the subnet case, the gateway assumes that there are
Xother 'smarter' gateways or hosts that will answer ARPs for subnets not
Xmatching its own.
X.PP
XActually IP gateways are supposed to use a 'standard'
Xprotocol between themselves (IGP or EGP) to decide how to find other
Xnets and to advertise the accessability of their locally attached
Xcables. At least at Stanford, this has not happened yet.
XFor example, the Stanford gateways still use the old Xerox PUP routing
Xtable protocols to inform themselves of subnet connectivity.
XWhat we will probably do for the time being is add another little
X30 second timeout task to the applebus gateway. It will broadcast
X(on the ether side) a trivial PUP routing table entry showing the connection
Xto its applebus segment(s). Such code would be #ifdef'ed by our site
Xname, so that you could substitute your own local convention.
X.NH 2
XProtocol conversion
X.PP
XIncoming applebus DDPs which are destined for the ethernet are encapsulated
Xin IP/UDP datagrams. The IP fields are derived as follows.
XFirst, the incoming DDP must obviously be in 'long' format, since a
Xdestination network number is required. This net number either
X(1) becomes the destination IP subnet number or (2) is converted to
Xan IP address through the mapping table.
XThe one byte DPP 'node numbers' become the low byte of the IP addresses.
XThe DDP 'socket' numbers are mapped into UDP 'ports' as follows:
Xif the DDP socket is between 0 and 127 (a 'well known socket'),
Xit is translated to the UDP port range 0x300 to 0x37F, the top of the
Xreserved port range on UNIX.
XIf the DDP number is between 128 and 255, it is mapped to the range
X0x4000 to 0x407F, an unreserved port range on UNIX.
X.PP
XOnce again, all of this mapping and conversion is isolated to a small
Xset of mapping functions, so it is easily changed.
XOne could also imagine altering the default mappings by sending a message
Xto a small mapper daemon (socket) within the gateway.
X.NH 2
XDDP routing
X.PP
XAt present the gateway only really knows about routing IPs.
XIn the future it would be desirable to participate more in applebus
XRTMP protocol, and to allow the ethernet (or even the
Xwhole DARPA internet) to be used as a long-haul
Xbackbone between applebus segments.
X.NH
XPrerequisites
X.PP
XTo assemble your own gateway, you will need at least the
Xitems below:
X.RS
X.LP
XThe hardware is a 3 card multibus system: A 'SUN' 68000
XCPU board, an Interlan NI3210 ethernet card, and a homebrew
Xapplebus card (about 8 chips) which takes an afternoon to
Xwirewrap. More details in the hardware section below.
X.LP
XA UNIX (usually VAX) running 4.2 BSD, 4.1 BSD or Eunice. This is because the
Xsource distributed is written in the PCC/MIT 68000 C compiler.
X[This is the same compiler included with the SUMACC Mac C cross
Xdevelopment kit.] You can probably make due with any 68K C compiler
Xand assembler, but it will be harder.
X.LP
X.I "Inside Mac,"
Xupdate service, and the
X.I "Mac software supplement."
X.LP
X.I "Applebus Developer's Kit,"
Xincludes: protocol manual, applebus
Xtaps and interconnecting cable, Mac applebus drivers on SONY disks.
X.LP
XDartmouth's IP package from Mark Sherman (mss%dartmouth@csnet-relay).
XThe gateway distribution includes the binary for TFTP, but if you
Xwant the whole package (and source), you should get it from
XMark.
X.LP
XA Lisa Workshop system is handy to have around; you would need it to
Xcompile Mark's sources. Even if you are doing development in C, Apple
Xreleases Applebus updates as a combination of Mac and Lisa disks.
XThe Mac disks contain the 'driver' binary resources. The Lisa disks
Xcontain source for header files.
X.RE
X.NH
XHardware used
X.NH 2
XCPU board
X.PP
XThe SUN CPU board is a common one used here at Stanford for our
Xgateways and controller projects. We buy ours now from Forward
XTechnology, model FT68-X. It has a 10 MHz 68000 CPU, 256K of RAM, a simple
XPROM monitor (used to download the gateway), 2 RS232 serial ports,
Xclocks, etc.
XAlthough the FT68-X supports DMA via the multibus,
Xthe gateway does not require use of DMA.
XWe made this decision since many older 'SUN' CPU boards
Xdo not have DMA support.
X.PP
XYou will need a 50 cond. ribbon
Xcable that terminates in two ribbon DB25 connectors; these
Xare the console and serial downline load lines. The gateway
Xtakes less than a minute to load at 9600 baud from your UNIX.
X.NH 2
XEthernet board
X.PP
XThe Interlan NI3210 is about the least expensive multibus ethernet
Xcard we have found. It has a low part count because it uses the
XIntel 82586 ethernet chip to do most of the work. In addition it
Xcontains 8K bytes of on board memory that (our driver) chains together
Xas a group of circular buffers. This lets the applebus card
Xbe somewhat lazy about ethernet interrupt latency.
X.PP
XIn addition to the NI3210, you need two cables from Interlan:
Xthe NM10-10 is a flat ribbon cable that connects to the card;
Xthe NA1040-10 is the standard round transceiver cable that goes
Xfrom one end of the flat cable to the tranceiver. The '-10' means
X10 feet long.
X.PP
XYou can use any 'standard' ethernet tranceiver. The NT10 from
XInterlan seems to work well and is both V1.0 and 2.0 compatible.
X.NH 2
XApplebus board
X.PP
XThe wiring of the applebus card is more fully
Xdescribed in the attached file 'seagate.hard'.
XThe main chip it uses is the Zylog
XZ8530 serial communications controller (SCC). This is the same chip
Xused inside the Macintosh. The Z8530 does complete SDLC framing,
Xchecksum, address matching, FM0 encoding and clock extraction.
XThe current card is not DMA (neither is the Macintosh). The
Xsoftware driver for the link layer (LAP) is a modified version
Xof the driver that is inside the Macintosh; after the
Xaddress match interrupt comes in, the driver polls the
XSCC every 35 usecs for a new byte.
X.PP
XThis is the one item that could potentially limit the capacity
Xof the gateway. Given the current gateway and driver architecture,
Xit would be straightforward to replace the current card and lap
Xdriver, with a DMA version. The DMA could be done either to some
Xdual ported memory on board the applebus card, or directly to
Xthe processor memory (if the FT68-X was used).
X.PP
XOur current applebus card was designed around an ARTEC multibus 'slave'
Xprototype card, which contains all the bus interface circuitry for
Xan interrupt/polled controller. Other companies (such as Electronic
XSolutions) offer multibus 'master' prototype boards, that come with
Xthe logic necessary for a multibus DMA interface. It may be
Xsimple to fit the Z8530 into such a board.
X.PP
XAnother possibility would be to take an existing multibus DMA
XSDLC board (surely one must exist?) and use a 'daughter board'
Xwith the proper clock, RS422, and FM0 decoding logic.
XRichard Brown at Dartmouth (richb%dartmouth@csnet-relay) has used
Xa similar scheme to adapt a standard SDLC interface in their existing
Xterminal concentrators, to applebus.
X.PP
XYet another lead: I have heard a rumor the Heurkion 68000 CPU
Xboard uses the Zylog SCC chip. SUN Microsystems also uses it
Xon their 'SUN 2' CPU boards. Possible hangups: do they allow
XDMA to the SCC? What about the clocking and RS422 connections?
XCan these boards be purchased separately, or only as part of
Xan entire workstation?
X.NH 2
XOther hardware.
X.PP
XWe use a 6 slot multibus card cage and backplane, from Electronic Solutions.
XThe power supply is a small switcher from Power-One, model SHQ-150W.
XYou may want to just buy an integrated card cage, box, and power
Xsupply.
X.NH
XSoftware organization
X.PP
XThe gateway software has a simple structure: the applebus and
Xethernet receive-interrupt routines grab packet buffers off a free list,
Xstuff them with data, and enqueue them on the gateway main packet queue 'pq'.
XAt interrupt level 0 (backround),
Xthe gateway pulls packets off this queue and routes them as
Xappropriate. Eventually the ethernet or applebus output routines
Xare called. When there are no packets on the input queue, the backround
Xjust 'idles' performing console IO and scheduling timer routines.
X.PP
XEach interface has an 'interface structure' (ifnet) similar to that
Xused in 4.2 BSD. It contains, per interface, the IP (software) address,
Xthe hardware address (ethernet or applebus), and some parameters used by
Xthe ARP handler.
X.PP
XHere is a brief rundown of the source files used in the gateway:
X.IP "ab.h" 10
XApplebus protocol header definitions. If 'MAC' is #defined, some
XMac OS specific structures are included.
X.IP "arp.c"
XThe code for the IP address resolution protocol. The same code runs
Xon both the applebus and ethernet sides, by getting the hardware specific
Xinformation from the ifnet structure.
X.IP "ether.h"
XStandard 10 megabit ethernet header definition.
X.IP "gw.c"
XThe main gateway code.
X.IP "gw.h"
XGeneral gateway definitions.
X.IP "gwasm.[hs]"
XSome assembler support routines for the gateway.
X.IP "il.[hc]"
XThe driver for the interlan/intel ethernet controller.
X.IP "inet.h"
XInternet Protocol header definitions.
X.IP "lap.[hs]"
XApplebus LAP driver.
X.IP "lapref.s"
XSome special hooks (hacks?) needed to allow LAP polling to coexist
Xwith the software memory refresh on the SUN cpu board.
X.IP "pbuf.[hc]"
XPacket buffer get/free.
X.NH
XConfiguration
X.NH 2
XSoftware
X.PP
XIn file gw.c, choose an IP address for each gateway interface and
Xsubstitute it the 'ifnet' structures. You will only need to change
Xthat one element in each structure initialization.
X.PP
XAlso in gw.c, 'iproutedef' is the default route used when no
Xmatching interface can be found. It should be an address of a
Xgateway on the ethernet cable.
X.PP
XDepending on your
Xlocal ethernet configuration, you may need to add some routing table
Xentries to your gateways or hosts, so that packets for the applebus
Xcan first hop over to the applebus gateway.
X.PP
XIf you are using subnets,
Xset the variables 'ipsubmask' and 'ipsubshift' to correspond to
Xthe values used in your situation.
XIf you are NOT using subnets, set 'ipsubmask' to zero, and fill some
Xentries in the 'ipmap' structure; see the comments on that structure
Xfor proper format and examples.
X.PP
Xgw.h contains the socket mapping functions (macros); you will probably
Xnot need to alter these. Also in gw.h is a 'dartarp' #define, with
Xa comment which reads:
X.IP
XDartmouth implemented the 1st IP package for the Mac (by porting the
XMIT IBM PC version). Dartmouth originally placed the ARP protocol
Xon top of DDP, instead of LAP (all other IP ARPs are directly on top
Xof the hardware link level). Until Dartmouth changes their package,
Xthis define should be used.
X.NH 2
XCPU board
X.PP
XCPU board jumpers: The Forward FT68-X board has a number of jumper
Xareas. In general, these have correct settings as shipped from the
Xfactory. Just as a check list here are our settings:
XJP1 (no +5 on J1): none;
XJP2 (RS232): 2-7, 4-9, 5-6;
XJP3 (2732 PROMs): 1-3;
XJP4 (test points): none;
XJP5 (uart:level5int, timer:6) 2-4, 1-3;
XJP6 (drive BCLK, CCLK, ground BPRN, receive bus INIT): 1-2, 5-6, 7-8, 9-10;
XJP7 (DMA from BA19): 1-3;
XJP8 (INT4 to 1 from bus): 7-8, 9-10, 11-12, 13-14;
XJP9 (cpu board): 1-2, 4-5;
XJP10 (20 bit addressing): 3-4, 7-8, 11-12
X.PP
XThe Forward CPU PROM also looks at connector J2 on reset to get
Xsome configuration information.
X[Our Stanford PROMs for the Forward board are somewhat smarter than
Xthis, but they have our net booting code wired in; so you can
Xget by just fine with the default Forward PROMs.]
XHere are the Forward PROM jumpers:
X17-18 (don't clear memory on reset);
X19-20 ('verbose' mode);
X30-31 (don't run diagnostics on reset);
X45 (optional: can be momentarily grounded for 'reset').
XActually, you have to leave out 30-31 to get the board memory management
Xto power up in a reasonable state.
XWhat I do is leave out 30-31 and live with the fact that reset will
Xclear memory.
XThis gateway has some code (in the refresh interrupt)
Xto check the console 'break' key status,
Xso you CAN get back to the PROM monitor without a reset.
X.NH 2
XNI3210 ethernet board
X.PP
XAgain, the factory settings are pretty good; here are ours:
XW19A (serial multibus arbitration);
XW2A, W3A (surrender to other master);
XW20A (16 bit IO address);
XW21A, W22B, W23A, W24B (IO address XXAX);
XW4A, W5B, W6A, W7B, W8A, W9B, W10A, W11B (IO address AAXX);
XW12B, W13A, W14B, W15A (memory address 5XXXX);
X[note A/B reversal] W16B, W17B, W18B (memory addr X0XXX);
X[note reversal] W25-32B (24 bit address 050000);
XW1A (DC xcvr coupling).
X.NH 2
XApplebus board
X.PP
XS1 = IO map;
XS2 = 0110 0000 0000 (sets IO address 6000);
XS3 = all bits of address significant;
XACK DELAY: XACK to CCLK*6.
X.NH
XOperation
X.NH 2
XDownloading
X.PP
XPlug in the boards and connect the tranceivers/taps. Connect
Xa 9600 baud terminal to serial port A, and a 9600 UNIX tty line
Xto port B.
X.PP
XPower up the gateway, you should get a message on the console: 'Self
Xtest successful', and then the monitor prompt, a '>'.
XType an 'x' followed by a control-uparrow, followed by a carriage
Xreturn (CR). This ensures that 'control-^' is your console escape
Xcharacter. Now type 'it' followed by CR. This puts the console
Xand tty line in 'transparent' mode, so you can log onto UNIX and
Xprepare for the download.
X.PP
XChange directory into the place where the gateway code lives.
XThe loadable binary there is called 'b.out'. Escape back to the
XPROM monitor by typing control-uparrow, then type the letter 'c'
X(stands for 'close' connection). You are now back in the monitor.
XTo download the gateway, type 'l dlq' CR. 'l' is the monitor load
Xcommand; the monitor transmits the remainder of the command line
X('dlq') to serial port B. This executes the 'dlq' command
Xon UNIX (which stands for 'download, quick'). Dlq uses the
Xfile 'b.out' by default. Dlq will now handle the handshaking with
Xserial port B to complete the download.
X.PP
XYou will see a '.' print on the screen every 256 bytes that are loaded.
XAfter about 30 seconds the load will be complete and the gateway code
Xwill begin executing. As a debugging aid, the gateway has linked
Xinto the binary, a symbolic ddt. When the gateway starts, this
Xddt enters a temporary breakpoint and can accept commands at this
Xpoint. See the ddt manual page in the ddt directory. Normally
Xyou will just start the gateway by typing the 'esc' key, followed
Xby 'g' (stands for 'go'). The gateway should now be operational.
X.PP
X.NH 2
XConsole 'commands'
X.PP
XWhile the gateway is running, it accepts a few trivial console
Xcommands. Typing the letter 's' will print some interface statistics.
XYou can escape back to ddt with a 'control-c'. You can
Xthen peek or poke around at locations. [use 'pc'+2, 'esc'g to
Xresume]
X.NH 2
XDebug printouts
X.PP
XWhen first installing the gateway, you may want to get packet traces
Xon the ethernet and/or applebus side to check that things are working.
XThe applebus 'Peek' and 'Poke' programs can help out here as well;
Xusing peek is preferable since it doesnt impose any additional delays.
X.PP
XWith ddt, you can open location 'dbsw' (debug switch) and place a
Xvalue there. Dbsw is a bit mask, with each bit turning on a
Xdifferent section's trace printout. For example, setting dbsw
Xto the hex value FF will turn on all traces; setting it to 1A
Xwill just print the headers of ethernet and applebus output packets.
XSee 'gw.h' for the other switch values.
X.NH 2
XTFTP usage
X.PP
XTwo Dartmouth/MIT programs are included: TFTP and Customize.
XCustomize is first run to setup a small parameter file on the
XMac that holds the Mac's IP address, and the IP address of the
Xgateway; these numbers are four byte values, specified in hex.
XThe other fields shown are unused.
X.PP
XAfter setting up the parameter file once, you can then run
XTFTP. Select from the command menu either 'get' or 'put'.
XIf you are talking to a UNIX, you cannot use the Mac specific 'Macintosh
XMode'; instead select 'ascii' or 'octet' mode.
XFill in the 'local file' name and the 'remote file' name (the dialog
Xmistakenly says 'destination' instead of 'remote').
XFinally fill in the remote host; alas, it too is specified
Xas a hex four byte host number.
X.PP
XWhen you now click 'OK', the transfer should begin. You can
Xwatch the packets flying by if you have a 'peek' running on the net.
X.PP
XIn Mark Sherman's document on his IP package, he warns that this
Xrelease of TFTP etc., is not to be considered 'production quality'.
XTFTP 'gets' seem to crash after doing about 3 consecutive transfers. 'puts'
Xseem more stable, but even these start to bomb out after the 'log'
Xscreen starts to scroll.
X.NH
XThroughput
X.PP
XUsing Mark's TFTP and the Berkeley 4.2 BSD TFTP daemon, we made
Xsome simple timings. On the Mac side, TFTP used a ramdisk to
Xavoid any delays induced by the slow SONY drive.
XFor a UNIX to Mac transfer, we found that
Xthe Mac took 43 ms between data received and ack sent, while
XUNIX spent 25 ms between ack received and next data sent
X.PP
XSince these times were from the applebus peek program, the mac time
Xis artificially high since it includes the 20 ms or so of packet
Xtransmission time on applebus (35 usec / byte). So then, each side
Xhas about a 20 ms delay before responding.
X.PP
XMost of the transfer occured at
X512 data bytes every 70ms = 7314 bytes / sec = 58K baud.
X.PP
XNote however that the IP TFTP protocol is just that, a 'trivial' FTP.
XIt is purely half-duplex in nature.
XWhen we start using Apple's ATP, which can stream several packets
Xper acknowledgement, it should boost throughput significantly.
XGursharan Sidhu tells me that their
Xprocess-to-process (no disks) ATP throughput
Xis 180K baud (out of the 230K available on the cable).
XThis is very good, considering many TCP's running on 10 megabit
Xethernet are lucky to get a few hundred kilobits of thoughput.
X.NH
XFuture plans
X.PP
XHere are some obvious things that could be done next.
X.RS
X.LP
XUse a DMA applebus interface. I guess right now we really don't know
Xhow the present interface will hold up under heavy load: it may
Xdo just fine. But certainly, if you wished the applebus gateway
Xcode to coexist with some other gateway or ethertip (terminal
Xconcentrator) code, DMA would be most considerate of those other
Xprocesses running on the cpu.
X.LP
XWith DMA, you could have one gateway handling a whole group of
Xapplebus interfaces. Alternatively, perhaps it would be best to
Xconnect up the applebus segments as a true 'internet'
Xinterconnected mostly thru Apple supplied bridges, and have
Xjust one or two 'seagate's connecting that whole internet
Xto the ethernet. Certainly this would limit thruput more
Xthan the 1st approach.
X.LP
XBefore you can add multiple interfaces, the 'routeip' and 'routeddp'
Xroutines need to be beefed up a bit to scan a group of interfaces
Xrather than just assuming two interfaces per gateway. [This is
Xcommented in the code.]
X.LP
XHere is the most interesting thing I would try: try to get
Xthe 'per gateway' cost way down, by building a single board version
Xof it. I picked the Intel 82586 ethernet controller for just this
Xreason: all you should need is a board with the 68000, memory,
Xthe 82586 and the Z8530. Hopefully you could get the cost down below
X$1000 per gateway. Then just sprinkle them around campus, using
Xethernet as your 'long-haul' and applebus within a floor, or
Xgroup of offices.
X.LP
XI would like to quickly finish an ATP subroutine package that runs
Xon the UNIX side. This will allow rapid construction of
Xapplebus servers on UNIX. A program equivalent in functionality
Xto FTP or TFTP should be less than 5 pages of Mac C code.
X[Since the Mac MPP applebus
Xdriver package is doing the 'dirty work' of ATP for you].
X.RE
X.PP
X.NH
XAcknowledgements
X.PP
XNick Veizades built and helped debug our applebus hardware interface.
XMark Sherman's Mac IP package allowed easy access to the UNIX TFTP
Xdaemon for general debugging.
XGursharan Sidhu, the 'applebus architect', deserves much credit
Xfor making this protocol family as simple and elegant as it is.
XArnie Lapinig of Apple was always helpful when we needed another
Xtap box or question answered.
X.PP
XIn the Stanford network community, Bill Yundt supplied us with free
Xhardware and Ed McGuigan kept the applebus updates flowing in our direction.
XEd Pattermann (formerly SUMEX director, now at Intellicorp)
Xmade the mistake of turning us onto Macintoshes, when we 'should
Xhave been' hacking on LISP machines.
---seagate.hard
HARDWARE FOR APPLEBUS - ETHERNET GATEWAY
Bill Croft and Nick Veizades
Stanford SUMEX project.
1. INTRODUCTION
The gateway is a multibus system consisting of 3 cards:
"SUN" CPU board, 8 or 10 MHz, 256K RAM
INTERLAN NI3210 10mb ethernet card. This has onboard memory, so DMA
is not needed on the processor. The Intel 82586 ethernet chip
does automatic buffer chaining of packets.
SUMEX applebus card. This is described below; it contains about
6 chips and can be wirewrapped in an afternoon.
2. SUMEX APPLEBUS CARD
2.1 PARTS
ARTEC (phone 415-592-2740) "multibus multipurpose interface board" ($165).
This board comes with the bus buffering and control logic all setup.
All you basically have to do is connect up your data IO lines and chip select.
ZYLOG Z8530 SCC; serial communications controller.
AMD 26LS32B; quad differential line receiver.
AMD 26LS30; dual differential tri-stateable driver.
DB-9, PC board mount, female.
7492; divide by six.
DIP pullup resistor pack (Beckman B98-1-R6.8K) 15 resistors.
XTAL, 22.1184 MHz; this is a "standard" frequency found in most stores.
Single package TTL oscillator, OR:
74S04; clock "oscillator".
2 1K resistors.
100 pf capacitor.
68 pf capacitor.
2.2 WIRING: OSCILLATOR
If you don't use a single package oscillator, this simple circuit
acts as one: (you might run the output though a couple more spare
inverters in the S04 to further "clean it up")
----\/\----- ----\/\-----
| 1K | 68p | 1K |
| |\ | | |\ |
| | \ | | | | | \ |
---| \O---|--| |--|---| \O--|----
| | / | | | / |
| |/ |/ |
| 100p X |
| | | |X| 22.1184|
|----| |-----------|X|--------|
| | |X|
X
2.3 WIRING: 7492 (divide by six)
from pin to pin
OSC 22.1184 MHz B input 1
gnd gnd 10
+5 Vcc 5
gnd reset inputs 6,7
Qd output 8 SCC PCLK 20
The PCLK is derived as follows: 22.1184 MHz divided by 6 gives
3.67864 MHz; this is connected to the SCC PCLK, RTxCA, and RTxCB.
In the digital phase lock loop mode, the SCC divides RTxC by 16
to get the FM0 rate: 3.67864 / 16 = 230400 bits per second.
2.4 WIRING: Z8530 SCC
from pin to pin
gnd gnd 31
+5 Vcc 9
7492 output 8 PCLK 20
PCLK 20 RTxCA,RTxCB 12,28
board DOUT 0 thru 7 board DIN 0 thru 7
board DOUT/IN 0 D0 40
board DOUT/IN 1 D1 1
board DOUT/IN 2 D2 39
board DOUT/IN 3 D3 2
board DOUT/IN 4 D4 38
board DOUT/IN 5 D5 3
board DOUT/IN 6 D6 37
board DOUT/IN 7 D7 4
pullup on each data line D0-D7 1,2,3,4,37,38,39,40
board BRD\ board DOUTE\
board BRD\ RD\ 36
board BWR\ board DINE\
board BWR\ WR\ 35
board BEN\ CE\ 33
pullup INTACK\ 8
pullup IEI 7
INT\ 5 board INT4\
board buffered INT4\ board multibus 37
board ADR0 A/B\ 34
board ADR1 D/C\ 32
TxDA 15 LS30 in A 2
RTSA\ 17 LS30 enb B\ 3
LS32B out A 3 RxDA 13
2.5 WIRING: 26LS32B receiver
from pin to pin
DB9 8 A in + 2
DB9 9 A in - 1
A out 3 SCC RxDA 13
gnd enable\ 12
gnd gnd 8
+5 Vcc 16
2.6 WIRING: 26LS30 driver
from pin to pin
SCC TxDA 15 A in 2
SCC RTSA\ 17 B enb\ 3
out A 15 DB9 4
out B 14 DB9 5
gnd mode 4
gnd gnd 5
+5 Vcc 1
2.7 WIRING: other board straps and switches
S1 - IO MAP
S2 - 0110 0000 0000; sets board address to 0x1f6000
S3 - all bits of address significant
ACK DELAY: XACK to CCLK*6
Copyright (C) 1984 Stanford Univ. SUMEX project.
May be used but not sold without permission.