Inter-Office MemorandumToAlto Gateway ProjectDateFebruary 10, 1980FromEd TaftLocationPalo AltoSubjectAlto Gateway Microcode PackageOrganizationPARC/CSLXEROX Filed on: [Ivy]GatewayMicrocode.pressThe Gateway Microcode package provides facilities by means of which Mesa or Bcpl programs mayconveniently and efficiently control either of two communication interfaces: the XEOS Alto EIAboard or the ASD Communication Processor. It also includes various other pieces of microcodeuseful in Alto Gateways.The microcode package has the following properties.It permits operating communication lines at relatively high speeds: many lines at 9.6 KB, ora few (probably not more than two) lines at 56 KB, full-duplex.It provides a framework making it possible to control individual lines independently of eachother. That is, the microcode may provide independent software interfaces to each line.The present microcode implements the complete finite state automata for reception andtransmission of data frames (packets) using a subset of the BiSync protocol. The softwarespecifies packet reception and transmission by means of queues of Line Command Blocks.The software is notified (by an interrupt) when reception or transmission of a packet hasbeen completed.Other software interfaces presently implemented are character-at-a-time reception andtransmission via ring buffers and uninterpreted block-at-a-time transmission.Separate versions of the microcode exist for the EIA board and the CommProc. While thetwo pieces of hardware are quite different, the software interfaces and overall organizationof the driver are virtually identical. The only intentional differences have to do withinitialization, exception handling, and interpretation of control and status words. Note,however, that simultaneous operation of an EIA board and a CommProc in the same Alto is not supported.The microcode is usable by both Mesa and Bcpl programs. Slightly different versions of themicrocode are required for the two languages.This document describes the software interface to the Gateway microcode package. Informationavailable from the hardware documentation for the EIA board and the CommProc is not duplicatedhere. Reference is made to the one-page command and status word format summary provided byXEOS, and to the CommProc Functional Specification (hardware) provided by ASD.All information applies to both interfaces and to both Bcpl and Mesa programming unless otherwisespecified. All numbers are decimal unless suffixed with 'B', in which case they are octal.ЪН]Оg║pТiНІОc8qН]rТXН-єqН7BrНІО\ЎqН]rН-єqН7BrНІОVDqН]rН-єqН7BrНЭОOїsrНЇОI╨П.НыОCПТ█П=Т▌НыОBlТеПRqrТфqНыО@ХrТюqrП9ТаНыО?dТНыО<П3НоО9 Т┬ПIТ┴ qrНоО8ТП/qr НоО51Т┬Т┴П>НоО3ґТюП7trТа НоО0хТкП-ТлП(НоО/DТ║П-Т╒П-НоО-юТ║ПVНоО,<ТўПUТ╞НоО*╦ТНоО'сТПGТ НоО&OТПMНоО#jТ Т⌡qrП#НоО!ФТ╒ТёПFНоО bТыП<ТзНоОчТАП6ТБqНоО}Т╔ПJТі uq НоО╪rТ┌ПAТ┐НоО8ТП-НыОSТҐТЎПFНыОоТ∙П-Т√qrП)НыОKТ·П0Т÷П+НыОгqrТtП,rqrНыОБТ┤Т┬ПRНыО ^ТП:qrЪ Э >/[К Alto Gateway Microcode Package2Hardware requirementsThe microcode runs only on an Alto-II with the Extended Memory option (though there is nonecessity for more than 64K of memory actually to be installed).The microcode is usable by Mesa programs only if the Alto has a 2K Control board, with the Mesamicrocode blown into ROM1.EIA boardOne or more EIA boards should be installed as described in the documentation accompanying them.The XEOS wire-wrap interface requires several modifications before it may be used with the EIAmicrocode. These modifications will be detailed in a separate memo. If the IC in location D2 is a74LS174, the modifications have already been made; if it is a 74LS175, they have not. The ASDprinted-circuit interface is expected to incorporate these changes.A modification is required to make the Memory Refresh Task be RAM-related. This involves addinga single wire to the backplane: MRTACTIVE' (slot 11, pin 109) to either TASKA' (slot 10, pin 13) orTASKB' (pin 14), whichever isn't being used by other devices. If both an EIA board and a CommProc areinstalled in the same Alto, TASKB' must be used, because the CommProc uses TASKA'.CommProcThe CommProc installation instructions should be followed. No other modifications are required.Exception: if two additional Ethernet interfaces are also installed in the same Alto, the CommProcinterval timer must be disabled because the task which it uses (task 1) is needed for the second extraEthernet. To do this, while installing the CommProc omit the connection of WAKE1' to pin 114 and1ACT' to pin 119 of slot 16.Organization and data structuresThe EIA microcode runs as part of the Memory Refresh Task. Every 38 microseconds, it checks tosee whether any EIA line is requesting service, and if so performs all processing required. TheCommProc microcode runs as a dedicated task that wakes up only when service is required for datatransfers.In either case, the microcode requires the presence of several data structures in main memory.These data structures are used both for maintaining line state and for communication with software.Line tableAll line state is maintained in a table in main memory, pointed to by an S-register called LINTAB.Five other S-registers are used for scratch; all six must be dedicated to the Gateway microcode. TheS-registers presently assigned are 71 through 75 and 77, which have been chosen not to conflict with the Mesa emulator.Associated with each line is a six-word Line Table Entry (LTE), whose first word lies at LINTAB +6*line, where line is the communication line number (in the range 0 to 7 for EIA boards, 0 to 15 forCommProc). LTEs must lie on even-word boundaries. The structure of an LTE is:Word 0Unused.Word 1EIA board only: Hardware status is stored here every time the EIA linerequests service, for whatever reason. See the "Status Word Format" in theEIA interface documentation. The microcode interprets the INTP flag as arequest for service.Word 2Pointer to current input Line Command Block (LCB), or zero if no LCB isНЇОfЯrТНGОНыОbvНыО_9rТеПEТфНыО]╣ТqrП%НыОZпТ▌П9Т▐qrНыОYLТqrНыОU■tНыОR╞rТ█qrПJТ▌НыОQ+ТЎqrПNТ©qНыОOїrТ ПHТ⌡qrqrНыОN#qrТ©П8qr Тю qНыОL·rТПCНыОI╨Т┐П>qr Т└НыОH6Т≤П!q rqr Т≥ НыОF╡qrТ∙П7qТ√НыОEQТПRНыОA╪tНыО>вrТ╗П:Т╘П&НыО;Рt rТ÷ПOТ═НыО:nТ┌Т┐ПGНыО8ЙТ▀П5trqrТ▄НыО7fqrТНыО2зvНыО/УrТ■qrП%Т∙П3НыО.qТаqrТбП1НыО,МТ▀П0Т▄П0НыО+i НыО(└ТмПQТнНыО'Т█П3Т▌П0НыО#GtТ НыО brТёТєПAqrqrНыОчТ┐ qrПWqНыО}Т█П4Т▌ПCНыО╪rТ°П:qrТ²qrНыО8trТ┴trП1Т┼ qrНыОЄТqrП9qrНоОоТ─Н═НоОЙН═tТҐrТЎqrН═ОfТ┬Т┴П-Н═ОБqrТ╞П8qr Н═О ^ТНоО yТ─Н═ТїТ╗qrqrЪПЇ 2?/]ыrAlto Gateway Microcode Package3set up.Word 3Current input state (described below).Word 4Pointer to current output LCB, or zero if no LCB is set up.Word 5Current output state.Additionally, a few words below the beginning of the line table are reserved for various purposes, aswill be described later. Here is a summary:Word -4CommProc only: Interval Timer interrupt bit mask.Word -3CommProc only: Interval Timer interval.Word -2CommProc only: Interval Timer counter.Word -1Pointer to CRC table.Line statesThe state word is a small integer representing the state of the microcode with respect to a given lineand direction. When a line requests service, the microcode uses the state to dispatch to theappropriate stretch of microcode for handling the line at that point. The microcode updates thestate when appropriate.Associated with the finite state automaton for each software interface is a set of states. Each set isclosed; i.e., the microcode will transition only to other states in the same set. The software isexpected to initialize the input and output state words of each line to the initial states of thesoftware interfaces being used. Thereafter, the microcode maintains the states automatically. Theinitial states presently defined are:0Throwaway mode. Input data is thrown away and output requests are ignored (EIAboard) or cause Send Enable to be reset (CommProc). Unused lines should havetheir states initialized to this value.1BiSync data frame input.2BiSync data frame output.3Character-at-a-time input via a ring buffer.4Character-at-a-time output via a ring buffer.5Uninterpreted block output.When additional software interfaces are implemented, their initial states will be added to this list.Line Command BlocksInput and output data transfers are specified by separate chains of Line Command Blocks (LCBs).The LTE contains pointers to the first LCB in each chain. When a complete packet transfer has takenplace, the microcode stores ending status in the LCB, issues an interrupt (if the software so desires),and begins processing the next LCB in the same chain. Exception: the Character-at-a-time software interfacesuse only a single LCB, which describes a ring buffer that is used indefinitely.An LCB must be aligned on an even-word boundary. The first four words of every LCB have astandard format, regardless of the software interface; additional words are interface-dependent.Words marked '*' are modified by the microcode and must therefore be reinitialized before everyuse of the LCB; other words are never stored into by the microcode.НЇОfЯrТНGОН═ОbНоО_9Т─Н═ТНоО\TТ─Н═Тqrqr НоОYoТ─Н═Т НыОV┼Т┘П?Т├П&НыОUТП,НоОR"Т─Н═tТrП$НоОO=Т─Н═tТrНоОLXТ─Н═tТrНоОIsТ─Н═ТqrНыОE╩t НыОBжrТ┬ПNТ┴НыОARТщП;ТчП"НыО?нТЁП`НыО>JТНыО;eТ≤ПZТ≥НыО9АТ╩Т╪ПGНыО8]ТпПLtr ТяНыО6ыТіТїПJНыО5UТП%НоО2pНёТ┘Т├П;tН═О0ЛrТ╠П"t rН═О/hТП'НоО,┐НёНоО)·НёНоО&╧НёП,НоО#тНёП-НоО ОНёНыОТ╚ПNТ╛НыОRtТНыОmrТ╘Т╙ПDqrНыОИТ│qrqrТ┌П%НыОeТ∙П1qrТ√НыОАТ▀qrqТ▄П-НыО─ТПOНыО©rТЄqrТ╣ПJqrНыО ;ТяПLТрНыОЇТ╔ТіПKНыО 3Т qrП6Ъ Ї Л?/^FAlto Gateway Microcode Package4Word 0Link to next LCB, or zero if none.Word 1Bit mask indicating channel(s) on which an interrupt is to be initiated whenprocessing of the LCB has been completed.Word 2*Ending microcode status (see below). The software must initialize this tozero before appending the LCB to a chain.Word 3*Ending hardware status.The microcode indicates that it has completed processing an LCB by setting bit 0 of the microcodestatus word (word 2), storing an error code in bits 1-15 of the same word, and storing hardwarestatus in word 3. The microcode may store an error code and hardware status prior to the end ofthe transfer, so the software should look only at bit 0 of the microcode status to determine whetherLCB processing has completed.The following error codes are independent of the software interface in use on the line. Other codesare defined by specific software interfaces.0No error.1A fatal hardware status was reported. The hardware status word stored in the LCBwill show what the error was. The microcode will post this code in preference to a softwareinterface-dependent error if both occur during processing of the same LCB.During input, the status bits treated as fatal errors are the following:RPE (Receive Parity Error): Can occur only if parity checking has been enabled.ROR (Receive Overflow Error): Input data late, characters lost.RFE (Receive Framing Error): Can occur only when the line is in asynchronous mode.During output, the fatal error status bits are:FCT (Fill Character Transmitted): EIA board only. Can occur only when the line is insynchronous mode. Indicates that the USRT transmitted a fill character because anew data character was not supplied within one character time after a request. Notethat this is a perfectly normal condition between frames, when there is no data to be sent. It is anerror only if it occurs within a frame. The microcode for block-mode transmission is careful to ignoreFCT status at the beginning of a frame. However, during character-at-a-time transmission, thesoftware must make this distinction.Transmit Overrun: CommProc only.Emulator-level subroutine callsThe Mesa or Bcpl software communicates with the microcode by three means: manipulating theshared data structures, directly manipulating the hardware interface registers, and calling Ramsubroutines that have been included in the microcode. Ram subroutine calls are accomplishedsomewhat differently in Mesa and Bcpl.The following examples show how to call the SilentBoot subroutine, which takes a single argumentand sets the Boot Locus Vector to it, then boots the Alto. Other Ram subroutines are declared andcalled similarly.In the Mesa version of the microcode, subroutine entry points are at fixed locations in the Ram andare intended to be called directly by means of the JRAM Mesa opcode, with argument and resultvalues passed through the Mesa stack in the usual fashion. The entry point to the SilentBootsubroutine is Ram location 1400B. The subroutine is declared and called as follows. This is valid onlyin Mesa versions 4.0 and later.ЪНЇОfЯrТНGОНоОbТ─Н═ТqrНоО_9Т─Н═Т▀П1Т▄Н═О]╣ТqrНоОZпТ─Н═Т╠П<Т╡Н═ОYLТqrНоОVgТ─Н═ТНыОS┌Т°Т²qrП"НыОQЧТ╡П+ТЁП4НыОPzТ П$Т⌡П<НыОNЖТ░П>Т▒П&НыОMrqrТНыОJ█Т┴Т┼ПQНыОI ТП,НоОF$НёНоОC@НёТ⌡ПNqН═ОA╪rТ·Т÷qП?Н═О@[ТПJНыО=≥rПHНоО:ЄqrПMНоО7пqrП=НоО4КqrТ©П$ТюП,НыО2ТП/НоО/!qrТЇtТ╦rП$Н═О-²Т╠П&qrТ╡ Н═О,Т▌Т▐ПHqН═О*╦Т∙ПDТ√П!Н═О){Т┐ПUТ└Н═О(=ТтТуПMН═О'ТП$НоО$>rtrНыО ├tНыО║rТўП9Т╞П"НыОТХП_НыО≥ТлТмПGНыОТП&НыО0Т≤П6Т≥П*НыО╛Т▄ПbНыО(ТНыОCТ┬П6Т┴П-НыО©ТўП3qrТ╞П&НыО ;ТйТкПHНыОЇТ┬Т┴qrП6qНыО VТ$Ї 3>/]ьVAlto Gateway Microcode Package5silentBootAddr: CARDINAL = 1400B; -- Ram entry point for SilentBootSilentBoot: PROCEDURE[bootLocusVector: WORD] =MACHINE CODE BEGINMopcodes.zLIW, silentBootAddr/256, silentBootAddr MOD 256;Mopcodes.zJRAM;END;SilentBoot[177376B]; -- the call --Ram subroutine calls must be complete Mesa statements, not nested expressions. When a Ramsubroutine returns a value, a call to it must be a statement of the form "simpleVariable _Routine[arguments]".In the Bcpl version of the microcode, subroutines are called by executing undefined opcodes thattrap into the Ram. For example, the opcode for SilentBoot is 63000B. Arguments are passed inaccumulators 0, 1, and 3, and the result (if any) is returned in AC0.A Bcpl-callable procedure is available to do this. It is contained in the file CallRam.asm, and iscalled as follows:result = CallRam(opcode, ac0, ac1, ac3)For example:CallRam(63000B, 177376B) // equivalent to Mesa's SilentBoot[177376B]The following table summarizes the Ram subroutine names and the corresponding Mesa Ram entrypoints and Bcpl trap opcodes for all the routines presently defined in the microcode.NameMesa entry pointBcpl opcodeSilentBoot1400B63000BEnableEIA (EIA board)1401B63400BSetLineTab (CommProc)1401B63400BPupChecksum1402B64000BProcessEIA (EIA emulator version only)-----65400BChangeControlReg (CommProc)1403B65400BSetConPtr (1822 version only)1420B-----PREncrypt (1822 version only)1421B-----InitializationPrior to operating the communication hardware or Gateway microcode, the software must perform agreat deal of initialization.Microcode initializationFirst, the microcode must be loaded. There are a large number of possible microcodeconfigurations, depending on whether Mesa or Bcpl is being used, what devices are to be controlled,and how they are to be operated. Packed Ram images for seven standard configurations areavailable in the following files, to be found on [Ivy]. Other configurations can easily beconstructed; see the "Packaging and other facilities" section for information.MesaGateEIA.brMesa, EIA board.MesaGateEIAChain.brMesa, EIA board, and up to 3 Ethernet board to be operatedwith chained input buffers.BcplGateEIA.brBcpl, EIA board.НЇОfЯrТНGОНоОbТXqrqrП#НоО` qrqrНёО_qТFНёО]▓rТXП2qrНёО\НёОZ┼qrНоОW╔qrНыОTюТҐП:ТЎНыОS<ТМПCТННыОQ╦НыОNсТ╚П?Т╛П!НыОMOТ╘Т╙П0qrНыОKкТПAqrНыОHФТґП3ТўП0НыОGbТНоОD}ТXП'НыОA≤ТНоО>ЁqrТXqrП,qrНыО;оТ▐Т░ПIНыО:KТПUНоО7ftН,═ТXН=` НоО4│r Н,═qН=`rqНоО2Щr t Н,═rqН=`rqНоО1yr t Н,═rqН=`rqНоО/Уr Н,═qН=`rqНоО.qr tН,═rЫPЬЪЗЪН=`ЫЬЗqНоО,Мrt Н,═rqН=`rqНоО+ir tН,═rqН=`rНоО)Д tН,═rqН=`rНыО%Xv НыО"srТ┬ПPТ┴НыО ОТНыО7tНыОRrТ$П1Т%П#НыОнТ├ПQТ┤НыОJТыПFТзНыОфТ╗П!Т╘ПCНыОBТПNНоО] Н$@qrНоОoН$@Т└qrТ┘Н$@О КТНоОЩ Н$@qrЪ╡ЇІ>/\U^Alto Gateway Microcode Package6BcplEmuEIA.brBcpl, EIA board, emulator-level processing. (See the "Timinginformation" section for an explanation of the circumstancesunder which this version is required.)MesaGateCP.brMesa, CommProcMesaGateCPChain1822.brMesa, EIA board, up to 3 Ethernets with input chaining, andan Alto-1822 interface.BcplGateCP.brBcpl, CommProcThe Boot Locus Vector should be set to a value that will cause the appropriate tasks to be run inthe Ram, and the Alto should be "silently" booted. This may be accomplished using the SilentBootRam subroutine, presented previously. The correct Boot Locus Vector value for each Ram image iscontained in word zero of that Ram image; see the "Packed Ram" and "LoadRam" packagedocumentation for further details on the format of Ram images. The Bcpl LoadRam procedureobtains the Boot Locus Vector from the Ram image automatically (if the boot argument is true).Caution: the silent boot causes an extended memory Alto's bank registers to be reset to zero.Therefore, the code that executes the silent boot had better be running in bank zero, or else it willperform an unexpected non-local goto. If any other tasks (e.g., the display) are running in extendedmemory, their bank registers will need to be reset also. XMesa programmers beware.Determining which lines existTo determine whether any EIA boards exist, simply store 140000B into location 177700B and thenread location 177704B. If the result is nonzero, at least one EIA board exists. After reading 177704B,you should read 177703B once; otherwise, you may leave the EIA board in a bad state. You mustdo all this before enabling the EIA microcode. Note that the EIA board for line zero must be present in orderfor any other line to work.In order to determine which EIA lines are present, it is necessary to complete the initialization of theLine Table (below) and enable the EIA microcode. Then zero the hardware status word in each LTEand poke each line by storing 14x000B into location 177700B, for x=0 to 7. Within a maximum of608 (=2*8*38) microseconds, the status word for every line that exists will have become nonzero.To determine which CommProc lines exist, store some nonzero value into location 177300B +4*line, for line=0 to 15. If the same nonzero value can be read back, the line exists. The nonzerovalue chosen should not cause Receive Enable (bit 8) or Send Enable (bit 9) to be set, since thatwould cause the CommProc microcode to be awakened.Data structure initializationNext, the main memory data structures must be initialized. LINTAB should be set up as documentedpreviously, with initial states appropriate to the software interfaces to be used on each line.The word at LINTAB-1 must contain a pointer to a 256-word table, CRCTAB, that assists in CRCcomputation. The software must initialize this table using the algorithm presented by the followingBcpl program:НЇОfЯrТНGОНоОbН$@Т├qrТ┤Н$@О` Т┼П'Т▀Н$@О_ТП&НоО](Н$@ НоО[:Н$@Т├qrТ┤П+Н$@ОYІТНоОWхН$@ НыОTЦТ÷ПTТ═НыОS_Т┬ПLТ┴НыОQшТ▀ПDТ▄НыОPWТъПBТЮНыОNсТ╧П2Т╨П(НыОMOТ╡ТЁП7trНыОJjtrТуПOТжНыОHФТ∙П]Т√НыОGbТ├ Т┤П[НыОEчТПSНыОB%tНыО?ArТўqrП"qrТ╞qrНыО=╪Т┌qrП*qrТ┐qrНыО<8Т∙qrП%qrТ√НыО:ЄТ▀trТ▄qr qП@НыО9TТНыО6▓rТ├qrП/Т┤НыО5Т┬П"qr Т┴П-qНыО3┼rТ█trqrqrТ▌trНыО2ТіП+ТїП5НыО/!ТяПOТрqrНыО-²trТ▌trП:Т▐НыО,ТіПNТїНыО*∙ТП2НыО&эtНыО#ЬrТ┘П░rТ┘ПUТ├qrНыО=ТбТцП;qrНыО;┬Т■П-Т∙qrП,НыО:Т├Т┤qrtrtrtrП-НыО8ёqТ ПaТ⌡НыО5БrТнП@ТоНыО4^Т≥ПEТ НыО2зТНыО/!tП$НыО,<Т≥rП,Т qr qrqНыО*╦rТНыО'сТ╪ПEqrТҐqrНыО&OТ█П&qrТ▌qНыО$кrТП#НыО!ФТўqrП(Т╞НыО bТ²П6Т·П'qrНыОчТqrНыОЫtТy rП(ТzНыОu qrТЦТДП,trНыОЯТП;НыОТ┴П9Т┼П&НыО┬ТўП%Т╞П;НыОТПMНоО П@qrtrНоО ;Т╨Т╩П(trqrНыО VТ╣П5ТІП+Ъ pЇ ?/]ЭOAlto Gateway Microcode Package8177300B + 4*line.Of course, executing SilentBoot[177776B] still suffices to reset everything when quitting.Additional initialization for Emulator-level EIA processingThere is a special version of the Bcpl EIA microcode that is functionally equivalent to the standardone but performs EIA processing in the Emulator task rather than the Memory Refresh Task. Thejustification for this variant is described later in the "Timing information" section. Here we describethe additional initialization that this microcode requires.When the Memory Refresh Task discovers that EIA service is required, it initiates an interrupt onchannel 16B, which has highest priority except for the parity error channel. The interrupt routinefor this channel (pointed to directly by the channel's dispatch word, which is location 502B) isexpected to consist entirely of the following two instructions:ProcessEIA; opcode 65400Bbri; 61002BThe ProcessEIA instruction calls a Ram subroutine that performs the necessary EIA processing.ProcessEIA takes no arguments and returns no results.Before enabling the EIA microcode, it is necessary to set up this interrupt routine and to turn onchannel 16B (by "or"ing 2 into Active = 453B). This may not be done using the Bcpl Interruptpackage, since that package performs a context switch and a Bcpl procedure call on every interrupt,which is definitely not what you want. Also, the software must reserve channel 16B early enoughduring initialization so that it will not be usurped by other uses of the Interrupt package.General operationEIA boardThe EIA interface requests service whenever the INTP condition is true (see "Status Word Format" inthe EIA documentation). The microcode examines the status word of the requesting line todetermine what to do. If the RDA (Receive Data Available) flag is set, it performs input processingon the line (i.e., it dispatches on the line's input state). Similarly, if TBMT (Transmit Buffer Empty)is set, it does output processing.Regardless of whether or not RDA or TBMT is set, the microcode stores the hardware status in word1 of the Line Table Entry. This permits the software to monitor the status of an otherwise idle line(e.g., to notice Send Indicator). Note, however, that not all changes in status cause the EIA interfaceto request service. In particular, the dropping of SI or CD causes a request but the raising of thosesignals does not. Therefore, to guarantee that the status is up-to-date, the software should poke theinterface using the command that forces a line to request a wakeup, then wait at least 38microseconds before reading the status word. Poking the interface is accomplished by storing thecommand 14x000B (where x is the line number) into location 177700B.CommProcService requests in the CommProc cause a dedicated task to be awakened. Requests are generatedonly for transmission or reception of data bytes, not by changes of control or status levels. TheCommProc task dispatches on line number, I/O direction, and line state in a manner similar to theEIA microcode.Unlike the EIA microcode, the CommProc microcode does not store hardware status into word 1 ofthe Line Table Entry, since the hardware status register may be interrogated directly by software.At any time, the status word for line may be read from memory location 177300B + 4*line + 3.НЇОfЯrТНGОНыОbqrtrНыО_9П&qrП3НыО[─tП;НыОX°rТ⌡П'qrП:НыОWТ qrП,Т⌡НыОU■Т┐ПVТ└НыОTТП;НыОQ+Т╗П,qrТ╘НыОOїТё qrТєПEНыОN#ТкПKТлqrНыОL·ТП?НоОI╨ Н( qНоОH6rН(qНыОEQrТуПMТжqrНыОCмТП5НыО@ХТ╚qr Т╛П@НыО?dТ╚ qrqrtrТ╛НыО=ЮТ░П9Т▒П*НыО<\ТёТєП;qrНыО:ьТЩПSТЧНыО6KvТНыО2⌠tНыО/ўrТ└qrП(Т┘qrП/НыО.*ТОqrП;ТПНыО,іТ▐qrТ░П:НыО+"Т▌П=Т▐qrНыО)·ТП"НыО&╧Т▒qrqrТ▓НыО%5Т┼П8Т▀П-НыО#╠Т┬ПZТ┴qr НыО"-Т■П4qrqrТ∙НыО ╘Т▐ПbТ░НыО%ТЬПMТЫНыО║Т╗ПRТ╘НыОТ trqrtrП)qrНыОdtНыОrТ≤П(Т≥П7НыОШТ╡ПbНыОwТ⌠ПZТ■НыОСqrТ НыОТ∙ qrП"Т√trП%НыО┼Т╛ТґПZНыОТєТ╔trП(qrtrЪ 0Ї ©?/]LyAlto Gateway Microcode Package9A Ram subroutine is provided by means of which the software may change selected bits in a controlregister without disturbing the other bits. This operation is atomic with respect to CommProc taskexecution.ChangeControlReg: PROCEDURE[lineTimes4: CARDINAL, changeMask: WORD]LineTimes4 should be four times the line number to be affected. The low-order two bits identify thecontrol word to be manipulated. Control word zero is the only one for which this operation is likely to be useful. Thecontrol register bits corresponding to ones in bits 1 through 15 of changeMask are set to the value inbit 0 of changeMask. The remaining bits are not disturbed. Note that bit 0 is not used in any controlregister.GeneralIn general, the microcode performs only data transfer operations between a line and memory, anddoes not touch the interface control registers. This means that it is the software's responsibility toinitialize the interface appropriately (synchronous or asynchronous, full- or half-duplex, baud rate,etc.) and to monitor status bits as required.In the descriptions of the block-mode software interfaces, references are made to the operation ofappending an LCB to a chain. Care must be taken to do this in a race-free fashion. The followingBcpl procedure accepts head, a pointer to the head of an LCB chain (within a Line Table Entry), andlcb, a pointer to an LCB to be appended to the chain.let AppendLCB(head, lcb) be [ lcb ! 0 = 0 let p = head while p ! 0 ne 0 do p = p ! 0 p ! 0 = lcb if head ! 0 eq 0 then if lcb ! 2 ge 0 then head ! 0 = lcb ]Note that it is the software's responsibility to keep track of LCBs it has put on queues, since themicrocode does not hand back pointers to the LCBs that it is finished with.To reset a line that has timed out or is otherwise in need of reinitialization (e.g., when switching to adifferent software interface), the following procedure is offered:Set the line state to zero.Remove the LCB, set the LCB pointer to zero, and reset control registers as required.Set the line state to the initial state of the appropriate software interface.Restart the hardware.НЇОfЯrТНGОНыОbТ└ПaНыО` Т≥ПEТ НыО_ НоО\1ТXqrqr qrНыОYLТЁП2ТЄqП%НыОWхТ├ПsrТ┤НыОVDТ─Т│ПVНыОTюТ╔ТіП"qП,НыОS_НыОOйtНыОLЕrТ║Т╒ПPНыОKaТ· Т÷ПYНыОIщТ╛ПeНыОHYТП-НыОEtТ╗ПUТ╘НыОCПТ▓qrП&Т⌠П,НыОBlТ┐ Т└trqrП'НыО@ХtrТqrНоО>ТXНоО<НоО:Ш НоО9wНоО7СНоО6o НоО4КП<НоО3gНыО0┌Т╟П?qrТ╠НыО.ЧТП-qrНыО,Т│ПUТ┌НыО*∙ТПBНоО'╟НоО$кТД qr qrТЕП%НоО!ФТПNНоОЪtЇ╩>/IPМAlto Gateway Microcode Package10BiSync software interfaceThe microcode implements a subset of the standard BiSync protocol, namely the part dealing withtransparent transmission of data frames. Such frames are used to encapsulate Pups transmitted oversynchronous lines among Nova and Alto Gateways. The microcode does not implement controlmessages, ACKs, or other aspects of full BiSync. Indeed, it is not presently usable as part of asoftware implementation of full BiSync, though it could be made so with some effort.LCB formatThe standard 4-word LCB is extended to contain the following additional information:Word 4*Byte count and half-word selection. Bit 0 = 0 if the next byte to betransferred is the left byte in a word, 1 if the right byte. Bits 1-15 containthe number of bytes remaining.Word 5*Address of word containing next byte to be transferred.Word 6*Partial CRC. The software must initialize this to zero before appending theLCB to a chain.Data bytes are packed two per word, left-to-right, consistent with Mesa, Bcpl, and Pup conventions.Hardware initialization: EIA boardThe following control sequences are suggested to initialize the EIA line appropriately for synchronouscommunication. These are precisely the settings required for the Pup Gateway application.10x400B(where x is the line number) INITIF with DS=1 (communicating with DataSet), HD=0 (full-duplex), STD=0 (no secondary channel). The Baud rate isnormally irrelevant when operating in synchronous mode because the clock is provided bythe modem. If it is desired to connect two Altos with a direct synchronous line (nomodems), exactly one of the Altos should set DS=0 (communicating with Data Terminal)and select an appropriate Baud rate. When operating in half-duplex mode, it is thesoftware's responsibility to manage the S (sending) bit appropriately.13x200BRESET with RRT=1 (reset the USRT chip).11x700BINITRT with NDB=3 (8 data bits per character), NPB=1 (no parity bit),A/S=0 (synchronous). POE and NSB are irrelevant.12x026BINITRG with F/S=0, Data=26B (SYN byte for receiver sync characterregister).12x777BINITRG with F/S=1, Data=377B (all-ones byte for transmitter fill characterregister).After the hardware and data structures are initialized and the EIA microcode enabled, synchronousinput should be initiated (just once) by issuing a "Restart Receiver" command (store 13x100B inlocation 177700B). Thereafter, the EIA microcode tracks the incoming data stream, regardless ofwhether or not an LCB has been provided by the software.Hardware initialization: CommProcCommProc control word n is initialized by storing into location 177300B + 4*line + n, for n=0, 1,2.word 0 _ 60BData Terminal Ready, Request to Send. For test purposes, setting WrapEnable (bit 13) may be useful.НЇОfЯpТНG?НыОbqНыО_9pТ·П!Т÷П>НыО]╣Т▀Т▄ПKНыО\1Т╨Т╩П=НыОZґТЎ rpП/Т©П%НыОY)ТПTНыОUps НыОR▀prpП=НоОOїТ─Н═ТпП*ТяН═ОN#Т√Т≈П0Н═ОL·ТНоОI╨Т─Н═ТП0НоОFуТ─Н═Т√rpТ≈П-Н═ОEQrpТНыОBlТ░П#Т▒П@НыО>ЁsТП"НыО;оpТ│Т┌П+rpП#НыО:KТЪТПKНоО7fsprН≥pТ▒spТ▓rprpН═О5БТ╡rprprТЁН═О4│Т÷Т═П?Н═О3CТдТеП5Н═О2Т║П!Т╒П3Н═О0хТрПOТсН═О/▀ТПFНоО,иpsprН≥rprp rpНоО)ДsprН≥rpТжТвrprpН═О(`rpТrНоО%|psprН≥rpТ rp rpТrpП!Н═О#Ь НоО!sprН≥rpТ═rprpП.Н═О▐ НыО╙Т╒П?rpНыО&ТЄТ╣ПHsprpНыО╒ТюrpТаrpП9НыОТrpП#НыОesП!НыО─pТ▀spТ▄П/rpspspspНыОЭНоО Т─ rН pТкП!rП!Н ОЇТЪ ьЇ■>/\w┘Alto Gateway Microcode Package11word 1 _ 302BWord Select 3 (8-bit bytes), Clock Select 0, Mode Select 2(synchronous). Clock Select is relevant only when running in asynchronous modeor when Wrap Enable is true. The baud rate selected by any of the four values ofClock Select is determined by jumpers on the backplane.word 2 _ 26BSYN byte for receiver sync character recognition.After the hardware and data structures have been completely initialized, input should be initiated(just once) by setting the Receive Enable bit in control word 0. This is most easily accomplished byChangeControlReg[4*line, 100200B]. Thereafter, the CommProc microcode tracks the incoming datastream, regardless of whether or not an LCB has been provided by the software.InputTo enable reception of a packet, the software should set up an LCB as described previously. Word 5should be initialized with a pointer to a buffer and word 4 with its length in bytes. Note that words2 (ending microcode status) and 6 (partial CRC) must be initialized to zero. The LCB should then beappended to the line's input LCB chain.When a packet has been received, the microcode stores status as described previously, requestsinterrupts as specified by word 1 of the LCB, and removes the LCB from the chain. Bits 1-15 ofword 4 (byte count) indicate the number of unused bytes remaining in the input buffer.Microcode status codes peculiar to BiSync input are:3Input line control error (byte after first DLE wasn't STX).4Input buffer overflowed. Assuming the buffer really was large enough for the largest expectedpacket, an overflow most likely means that the receiver lost character sync with the incoming data.Therefore, the microcode drops sync and restarts the receiver when this happens.5Input line control error (in body of packet, byte after DLE wasn't DLE, SYN, or ETX).6Input CRC error.The receiver is then restarted (searching for character sync), regardless of whether or not there isanother LCB on the chain. If a packet starts to arrive and no LCB is set up, the microcode throwsthe data bytes away but still maintains packet frame sync. If a new LCB is provided by the softwarewhile the microcode is in the middle of receiving a packet, the remainder of the packet is stored inthe buffer. The ending status will most likely indicate a CRC error in this case, since the CRC iscomputed only over the data actually stored in the buffer.To assure correct reception of every incoming packet, therefore, it is advisable that the softwareattempt to maintain at least two LCBs on the input chain at all times.OutputTo transmit a packet, the software should set up an LCB as described previously and append it to theline's output LCB chain. It should then initiate transmission in one of the following ways:EIA board: Poke the interface by storing 14x000B into location 177700B.CommProc: Set Send Enable by calling ChangeControlReg[4*line, 100100B].This ensures that the microcode will wake up and notice that a new LCB has been set up. Note that itis OK to poke the interface in this way even when it is already running; ongoing data transfers are not disturbed.When the packet has been transmitted, the microcode stores status and requests interrupts asdescribed previously and removes the LCB from the chain. If there is another LCB on the chain,transmission of that packet begins immediately. Otherwise, the transmitter becomes idle (the EIAНЇОfЯpТНG?НоОbТ─rН pТ]Т^П&Н О` rТ═ПAН О_9Т║ПQН О]ШТП7НоО[:pТ─rН rpТП.НыОXUТґП0ТўП2НыОVяТ├П8Т┤П-НыОUMspТ▀rpТ▄П0НыОSиТП(rpП#НыОPsНыОM,pТ└П$Т┘rpП!НыОK╗Т┐Т└ПLНыОJ#Т┘Т├П"rpП$rpНыОH÷ТrpНыОE╩ТмТнП>НыОD7ТґП!ТўrprpНыОB╡ТПVНыО?нП4НоО<ИНёП+rprpНоО:НёТ≈rТ≤П*Н═О8ёТїП]Т╗Н═О7fТПPНоО4єpНёТ├Т┤rprprprpНоО1©НёТrpНыО.зТґТўПPНыО-VТ°rp Т²П&rpНыО+рТ┬П'Т┴rpНыО*NТ░Т▒ПNНыО(йТ╛П;rpТґrpНыО'FТП:НыО$aТЎПUТ©НыО"щТП!rpП"НыО%sНыО@pТ─ Т│П)rpП-НыО╪ТТ rpП4ТУНоОвsТ pП"sprprpНоОРspП0sprpНыО Т└ПBТ┘rpr НыОґТґП,ТўПGНыО КpТЦП%ТДП7НыОgТґП%rpТўrp НыО ЦТ╟П;Т╠П#rЪ bЇ °>/]o├Alto Gateway Microcode Package12board transmits continuous fill characters; the CommProc's Send Enable flag is reset).BiSync data frame formatA frame consists of the following sequence of bytes:SYN SYN ... SYN DLE STX ... transparent data ... DLE ETX CRC CRCThe frame begins with at least two SYN bytes, which the receiver searches for in order to establishbyte synchronization. The sequence DLE STX signals the start of the data portion of the frame.Within the data portion, all bytes are treated as literal data except DLE, which is an escape character.A literal data byte whose code corresponds to DLE is transmitted by doubling it, i.e., by sending DLEDLE. If the sequence DLE SYN appears, both bytes are ignored. Some synchronous interfaces, though notthe Alto EIA, automatically transmit DLE SYN when a transmit data-late condition occurs.The end of the data packet is indicated by the sequence DLE ETX. Following this are two bytescontaining the 16-bit CRC, transmitted low-order byte first. The algorithm used is the industry-standard CRC-16, computed over the transparent data bytes and the ETX. When the sequence DLE DLEappears, only one of the DLEs contributes to the CRC. When DLE SYN appears, neither byte is included.While no frame is in progress, continuous fill characters (all ones) are transmitted.Uninterpreted block transmission interfaceThis software interface permits transmission of arbitrary blocks of characters, with the microcodeperforming no interpretation whatever. It is useful primarily in conjunction with softwareimplementation of more elaborate synchronous protocols, such as full BiSync.Note that there is no corresponding interface for reception of uninterpreted blocks, since there is noway for the microcode to determine when a frame ends without interpreting the protocol. Forinput, the character-at-a-time (ring buffer) interface is probably the most appropriate.This software interface is not included in the MesaGateCPChain1822 and MesaGateEIAChainconfigurations.LCB formatThree words are added to the basic 4-word LCB:Word 4*Byte count and half-word selection. Bit 0 = 0 if the next byte to betransferred is the left byte in a word, 1 if the right byte. Bits 1-15 containthe number of bytes remaining.Word 5*Address of word containing next byte to be transmitted.Word 6Control command to be issued after transmission of block has beencompleted.The block pointed to by the LCB is expected to contain two data bytes per word, packed left-to-right.OperationTo transmit a packet, the software should set up an LCB and append it to the line's output LCBchain. It should then poke the interface in the manner described above under "BiSync SoftwareInterface: Output".ЪНЇОfЯpТНG?НыОbПWНыО^esНыО[─pП4НоОX°rprprprprprprprprНыОUЇpТ⌡П#rpТ°П0НыОT3ТиП#rprpП)Тй НыОQNТ└П>Т┘rpНыОOйТ└Т┘rpП1rНыОNFpТ≤rprpТ≥П#rП'НыОLЕТПXНыОJ#pТўТ╞rprpНыОH÷Т©ТюrpПHНыОGТ░rpТ▒rprНыОE╩ТЕП6ТФП0НыОBЫpТПUНыО>mqП*НыО;┬pТ╨ПXТ╩ НыО:ТП>ТНыО8─ТПLНыО5⌡Т┼ПLТ▀НыО4ТаП"ТбП:НыО2⌠ТПXНыО/ўТЛП'ТМП0НыО.*НыО*rsТ НыО'█pП*rpНоО$╗Т─Н═ТпП*ТяН═О#$Т√Т≈П0Н═О!═ТНоО╩Т─Н═ТП0НоОжТ─Н═Т ТП,Н═ОR НыОmТіТїПVНыОИНыО1sНыОLpТ╣П3ТІrpП$rНыО хpТґ ТўПTНыОDТЪ °ЇЩ?/\?Alto Gateway Microcode Package13When the packet has been transmitted, the microcode first issues the control command in word 6 ofthe LCB by storing it in location 177700B (EIA board) or 177300 + 4*line (CommProc). Theintended use of this feature is to turn around a half-duplex synchronous line at the end oftransmission. This word should be zero if no control command is to be issued.The microcode then stores status and requests interrupts as described previously and removes theLCB from the chain. If there is another LCB on the chain, transmission of that packet beginsimmediately; otherwise, the transmitter becomes idle.Note that the microcode does not add any SYN characters or other framing at either the beginningor the end of the block. If such characters are required, the software must include them in the datablock.Character-at-a-time software interfaceThis interface implements character-at-a-time reception and transmission via ring buffers. This is themost suitable interface for asynchronous lines. It can also be used for synchronous lines when it isdesired to implement the synchronous line protocol in software.This software interface is not included in the MesaGateCPChain1822 and MesaGateEIAChainconfigurations.LCB formatUnlike the block-oriented software interfaces described previously, this interface requires a singleLCB that is used indefinitely. The standard 4-word LCB is extended by an additional 4 words thatdescribe a ring buffer. The LCB link (word 0) must contain a pointer to itself.Word 4Address of first word of ring buffer.Word 5Address of last word of ring buffer +1 (i.e., the first address plus the lengthof the buffer).Word 6*Address of next word to be read from the buffer.Word 7*Address of next word to be written in the buffer.Data is stored in the buffer one byte per word, right-justified. The input microcode returns status inthe left byte (EIA only), and the output microcode expects the left byte to be zero.The reader and writer of the ring buffer must obey certain conventions to ensure race-freeoperation:There must be only one reader and one writer, though the reader and writer need not beinterlocked in any fashion.An empty buffer is represented by read pointer equal to write pointer. A full buffer isrepresented by read pointer equal to write pointer +1 (modulo wrap-around). Note thatunder these conditions, the word pointed to by the write pointer is not being used.The reader should read the data from the buffer before incrementing the read pointer.The writer should write the data into the buffer before incrementing the write pointer.These conventions are used by the microcode. The ring buffer format and conventions justdescribed are also the ones used by the Bcpl Ring Buffer package (word version).ЪНЇОfЯpТНG?НыОbТ┬Т┴ПNНыО` ТоrpП!rps p Тпsps pНыО_ТХП<ТИНыО]▓ТПNНыОZґТўПEТ╞НыОY)rpТоП&rpП#Тп НыОW╔ТП6НыОTюТ П$Т⌡rpП4НыОS<Т┤П,Т┬П9НыОQ╦НыОM,qТП&НыОJGpТ─П7Т│П0НыОHцТ⌠П3Т■П2НыОG?ТП?НыОDZТЛП'ТМП0НыОBжНыО?sТ НыО<8pТ╩ПdНыО:ЄrpТ÷Т═П)rpП*НыО90ТrpspНоО6KТ─Н═ТНоО3gТ─Н═Т│Т┌П@Н═О1ЦТНоО.ЧТ─Н═ТП)НоО,Т─Н═ТП*НыО)4Т│П@Т┌П'НыО'╟Т s pП<НыО$кТУ ТЖПPНыО#G НоО bТёП?ТєНоОчТНоОЫТЇПFТ╦НоОuТюП*ТаП!r НоОТПSНоОSpТкТлП6НоОnТмПWНыО┴ТХП!ТИП8НыОТПPЪ эЇЎ>/YM4Alto Gateway Microcode Package14InputIf an EIA board is operating in synchronous mode, input must first be initiated (just once) by issuinga "Restart Receiver" command (store 13x100B in location 177700B). A CommProc line must bestarted by ChangeControlReg[4*line, 100200B], whether it is running in synchronous or asynchronousmode.Whenever a character arrives, the microcode attempts to write the data into the input ring buffer. Itthen initiates an interrupt as specified by the interrupt mask in the LCB (if it is nonzero). EIA only:the microcode stores the rightmost 8 bits of the current hardware status into the left byte of eachword at the same time it stores the data into the right byte.If the ring buffer is full when a new character arrives, the microcode posts an error code of 2 in theLCB and throws the character away. Hardware error conditions will cause an error code of 1 to beposted, as described previously. The microcode never zeroes the microcode status word. It is thesoftware's responsibility to sample the status occasionally and zero it after noticing an error. Notethat there is no way to determine which character caused the error.To read the next character, the software should first wait until the ring buffer is not empty (theRingBufferEmpty procedure in the Bcpl Ring Buffer package is usable for this purpose). It shouldthen read the data byte from the buffer and increment the read pointer. The following Bcpl codeillustrates the required operations, which are similar to the ones used by the Bcpl Ring Bufferpackage.let readPointer = lcb ! 6while readPointer eq lcb ! 7 do [ ... ] // buffer emptylet data = readPointer ! 0readPointer = readPointer+1if readPointer eq lcb ! 5 then readPointer = lcb ! 4 // wrap aroundlcb ! 6 = readPointerOutputTo transmit a new character, the software should first wait until the ring buffer is not full (theRingBufferFull procedure in the Bcpl Ring Buffer package is usable for this purpose). It shouldthen store the data byte in the word pointed to by the write pointer, then increment the writepointer. Finally, it should poke the line (to ensure that the microcode wakes up and notices the newcharacter), as described previously under "BiSync Software Interface: Output". It is actually necessary topoke the line only if it was idle at the moment the new character was written into the buffer. This may be determinedby checking to see if, after writing the new character, there is exactly one character in the buffer. However, the cost ofservicing an unnecessary wakeup is only 4 microseconds, whereas the cost of deciding whether or not to issue the wakeupis undoubtedly much greater, so in practice it is probably better just to poke the interface every time.Whenever the microcode finishes transmitting a character, it initiates an interrupt as specified by theinterrupt mask in the LCB (if it is nonzero).The following Bcpl code illustrates the operation of writing a new character into the ring buffer:let writePointer = lcb ! 7writePointer ! 0 = datawritePointer = writePointer+1if writePointer eq lcb ! 5 then writePointer = lcb ! 4 // wrap aroundwhile writePointer eq lcb ! 6 do [ ... ] // buffer fulllcb ! 7 = writePointerNote (CommProc only): When the microcode discovers the ring buffer to be empty, it resets SendEnable to dismiss the data request. A consequence of this is that there is no way to detect atransmit underflow condition for a line being operated in synchronous mode.ЪНЇОfЯpТНG?НыОbsНыО_9pТ└rpП<Т┘П!НыО]╣ТІП&sprpТЇrpНыО\1Т─ Т│sprpП7НыОZґНыОWхТ└ПcТ┘НыОVDТ├П(Т┤rpsНыОTюpТ╔ПcНыОS<ТП=НыОPWТ┤Т┬ПTНыОNсrpТ∙Т√П?НыОMOТ═ПQТ║НыОKкТ÷П.Т═П8НыОJGТПCНыОGbТЁПPТЄНыОEчТ⌠П<Т■П%НыОDZТ⌡П>Т°П"НыОBжТйПBТкНыОARНоО>mТXНоО<ИП8НоО;eНоО9АНоО8]ПDНоО6ыНыО3 sНыО0;pТЎПQТ©НыО.ЇТґПVТў НыО-3ТбТцПFНыО+╞Т─П>Т│П'НыО*+Т┌П#Т┐П-rНыО(йТ█ПkТ▌ НыО'█Т▐П{НыО&OТ┘П7Т├П@НыО%ТПhНыО"PpТ┤Т┬П[НыО лТrpНыОГТ╟П#Т╠П?НоОТXНоО~НоОЗНоОvПFНоОРП8НоОnНыО┴Т∙spТ√ПJНыОТдТеПMНыО │ТПK °Ї :>/ZяFAlto Gateway Microcode Package15Timing informationThe following rough calculations attempt to estimate the fraction of the Alto consumed by theGateway microcode when driving lines at various data rates.EIA microcode timingBiSyncUninterpretedCharacter-blockat-a-timeAlto cycles/byte906573Microseconds/byte151112Fraction of Alto cycles consumed running one line, one direction, at 9.6 KB1.8%1.3%1.4% 19.2 KB3.6%2.6%2.9% 56 KB10.5%7.7%8.4%Remember, of course, that the percentage figures refer to the raw Alto microinstruction executionrate, with no other overhead. A full-screen display consumes about 60% of the Alto's cycles.An orthogonal problem is that of MRT task latency and overrun. If the EIA microcode runs forlonger than the MRT wakeup interval (38 microseconds), the next wakeup will be missed. The lossof MRT wakeups has several noticeable effects, the most serious of which are that the cursor jigglesvertically and the real-time clock loses time.The EIA microcode is careful to service at most one character per run of MRT, even if several linesare requesting service simultaneously. The worst-case running time of the EIA microcode is about 20microseconds. Therefore, in the absence of interference from higher-priority tasks, MRT shouldnever overrun its next wakeup.Unfortunately, when the display is running, it consumes approximately 60% of the Alto's cycles, at apriority level higher than MRT. The MRT wakeup interval is the same as the display horizontal scaninterval. Therefore, if the Alto provides data for the entire scan line, 60% of the machine duringthat interval is taken up by the display and only 40% is left for MRT and lower-priority tasks. Thiscan cause the EIA microcode's worst-case running time of 20 microseconds to be stretched to nearly50 microseconds, easily overrunning the MRT wakeup interval.Therefore, to prevent MRT overruns, it is advisable either to turn off the display entirely or to limitthe width of the display bit map. For example, a half-width display will consume only 30% of theAlto during each scan line, probably leaving enough cycles for MRT and the EIA microcode. Note thatuse of the horizontal tab feature is nearly as costly in Alto cycles as is providing real data for the same portion of thescan line.The disk word task is also higher-priority than MRT, but it consumes only about 15% of the Alto sois less likely to cause MRT overruns. The Ethernet task is lower-priority than MRT so will notinterfere with it at all.For applications in which it is unacceptable to turn off the display, a special version of the EIAmicrocode exists in which MRT, rather than doing EIA processing itself, initiates an interrupt on ahigh-priority channel and lets the Emulator task do the work. This eliminates the MRT overrunproblem entirely, but at a cost of nearly 100 additional microinstructions executed per byte. Only aBcpl version of this special microcode is provided at present. The software must set up an interruptroutine, as described under "Initialization".ЪНЇОfЯpТНG?НыОbqНыО_9pТкП8ТлП%НыО]╣ТП;НыОYЭsН%@ОWН.═Н;─ Н.═ОU■Н;─НыОR╞pТXН%@Н.═Н;─НыОQ+Н%@Н.═Н;─НыОOїНыОN#П$НыОL·rН%@pН.═Н;─НыОKrН%@pН.═Н;─НыОI√rН%@pН.═Н;─НыОF╡Т╗П9Т╘П(НыОE-ТжПGТвНыОBIТІП!rpТЇrpНыО@еТ√rpТ≈ПFНыО?AТ√rpТ≈П?НыО=╪ТП.НыО:ьТ≤rpП(Т≥rpНыО9TТ┌ПKrp Т┐НыО7пТкТлП9rpНыО6KТНыО3gТ┤П+Т┬П9НыО1ЦТ▄rprpП6Т█НыО0_Т╔П!ТіПBНыО.зТ▓ПBrpТ⌠НыО-VТ▓ rpП:Т⌠НыО+рТП(rpНыО(НТ▓rpП-Т⌠П!НыО'iТ∙Т√ПIНыО%ЕТ┌П>Т┐rprp r НыО$┘Т≈П^Т≤НыО#GТ НыО ├pТ█Т▌П#rpП/НыОТфrpП/ТгrpНыО}ТНыО≥Т╨П_rНыОpТ╚rprpТ╛НыО▒Т╧П"Т╨П1rpНыОТ▄ПSТ█НыО┬Т┤Т┬ПYНыОТП-зЇҐ>/UNwAlto Gateway Microcode Package16CommProc microcode timingBiSyncUninterpretedCharacter-blockat-a-timeAlto cycles724246Microseconds/byte1278Fraction of Alto cycles consumed running one line, one direction, at 9.6 KB1.4%0.8%1.0% 19.2 KB2.9%1.7%1.9% 56 KB8.4%4.9%5.6%The CommProc task is lower-priority than MRT and other tasks sensitive to latency, so the latencyconsiderations presented above do not apply.Packaging and other facilitiesThe Gateway microcode is packaged to include all the microcode services required by AltoGateways. However, the microcode source consists of a number of more-or-less independentmodules, stored in a single dump-format file [Ivy]GatewayMc.dm.All the standard Ram images are obtained by compiling one of the top-level Mu source files, whichinserts (using the "#" facility) various assortments of the other files to produce a givenconfiguration. New configurations can easily be constructed, subject to Ram space limitations andR- and S-register availability. (The MesaCPChain1822 configuration fills the entire Ram and uses allthe registers.)All the Mesa Ram images include the Ram portion of the XMesa (extended memory) microcode.Therefore, if Rom1 contains XMesa microcode also, it is possible to run XMesa-based software.The presence of the XMesa microcode in the Ram does not interfere with operation of standardMesa software in machines with the standard Mesa microcode in Rom1.MesaGateEIA.muTop-level source for Mesa, EIA board.MesaGateEIAChain.muTop-level source for Mesa, EIA board, and up to 3 Ethernetboards with chained input buffers (see below).BcplGateEIA.muTop-level source for Bcpl, EIA board.BcplEmuEIA.muTop-level source for Bcpl, EIA board, emulator-levelprocessing.MesaGateCP.muTop-level source for Mesa, CommProc.MesaGateCPChain1822.muTop-level source for Mesa, CommProc, up to 3 Ethernetboards with chained input buffers, and an Alto-1822 interface(see below).BcplGateCP.muTop-level source for Bcpl, CommProc.AltoEIA1.muMain EIA board driver, EIA subroutines, and BiSync softwareinterface.AltoEIA2.muUninterpreted and character-at-a-time EIA software interfaces.CommProc1.muMain CommProc driver, CommProc subroutines, and BiSyncsoftware interface.ЪНЇОfЯpТНG?НыОbsН%@О_9Н.═Н;─ Н.═О]╣Н;─НыОZпpТX Н%@Н.═Н;─НыОYLН%@Н.═Н;─НыОWхНыОVDП$НыОTюrН%@pН.═Н;─НыОS<rН%@pН.═Н;─НыОQ╦rН%@pН.═Н;─НыОNсТ╒П)rpП&ТёНыОMOТП,НыОHцqНыОEчpТЬТЫП@НыОDZТГПYНыОBжТПHНыО?ЯТ▄ПJТ█НыО>mТ ТПLНыО<ИТ║ПEТ╒НыО;erpТ└rpПEТ┘НыО9АТНыО6ЭТ╘ПYНыО5xТаП]НыО3ТТ╡ПFТЁНыО2pТПCНоО/▀ Н"юrpНоО,іН"юТ╧rp Т╨ Н"юО+"ТП.НоО(= Н"юrpНоО%XН"юТіТїrpН"юО#т НоО ОН"юТП$НоОН"юТТП%Н"юО┤Т÷П"Т═Н"юОТНоОН"юП$НоО9 Н"юТ╞rpТ╟rpП!Н"юО╣ НоОп Н"юТ╪П&rpТҐНоО КН"юТ╩П6Н"юОgТіЇ ?/[КAAlto Gateway Microcode Package17CommProc2.muUninterpreted and character-at-a-time CommProc softwareinterfaces, and CommProc interval timer.EIAMRT.muModified version of the Memory Refresh Task, required forthe EIA microcode.EIADispMRT.muVersion of EIAMRT.mu required when GateDisplay.mu isincluded (see below).EmuEIAMRT.muVersion of EIAMRT.mu required when usingBcplEmuEIA.mu.CPMRT.muModified version of the Memory Refresh Task, to accompanythe CommProc microcode. The CPMRT changes are a subsetof the EIAMRT changes, including abolition of the softwareInterval Timer and elimination of the wasteful use of R-registerCLOCKTEMP. The CommProc microcode itself does not require MRT tobe modified. CPMRT is so named simply to distinguish it from EIAMRT.CPDispMRT.muVersion of CPMRT.mu required when GateDisplay.mu isincluded (see below).GateDisplay.muMicrocode for the Alto display and cursor, rewritten to usetwo fewer R-registers than the standard microcode. This isrequired when using Mesa and controlling extra devicesrequiring R-registers, such as additional Ethernet controllers.The registers saved are 21B and 26B. All the display-relatedtasks (MRT, DWT, CURT, DHT, and DVT, tasks 10B through 14Brespectively) must be started in the Ram, and special variantsof the MRT microcode (EIADispMRT.mu, CPDispMRT.mu)are required.ExtraEther1.muMicrocode for one additional Ethernet interface (see below).ExtraEther2.muMicrocode for a second additional Ethernet interface. This isnot presently assembled in any of the standard Ram images.ExtraEther.muA top-level source file demonstrating the use ofExtraEther1.mu and ExtraEther2.mu. This file itself is not used inthe Gateway microcode package.ChainEther0.muMicrocode for controlling the standard Ethernet interface usingchained input buffers (see below).ChainEther1.muChained input microcode for the first additional Ethernetinterface.ChainEther2.muChained input microcode for the second additional Ethernetinterface.Mesa1822.muMicrocode for controlling an Alto-1822 interface (used forconnecting to the Arpanet or the Arpa Packet Radio network).Documentation may be obtained from Larry Stewart (userLStewart).PREncrypt.muMicrocode for encrypting data to be sent through the PacketRadio network.НЇОfЯpТНG?НоОbН"юТ9П%Т:Н"юО` ТП(НоО]╣Н"юТҐТЎП&Н"юО\1Тrp НоОYLН"юТУ ТЖП*Н"юОWхТНоОTЦН"юТёТєН"юОS_ НоОPzН"юТ°Т²П&Н"юОNЖТўrpТ╞Н"юОMrТэТщrpП-Н"юОKНТ─П5Т│rpН"юОJjrprТ▓П$Т⌠Н"юОI Т▌Т▐П&НоОFHpН"юТП!ТН"юОDдТНоОAъ Н"юТхП"ТиН"юО@[Тм rpП(ТнН"юО>вТ%Т&П)Н"юО=SТп rp ТяП)Н"юО;оТ╡ТЁrprpН"юО:KТ√rprprprprp rpТ≈ rН"юО8фpТ╒ТёН"юО7BТзrpТш Н"юО5ЎТНоО2з Н"юТцП<НоО/У Н"юТ╡ТЁП(rН"юО.■ТП:НоО+рpН"юТзТшН"юО*NТ⌠П"rТ■Н"юО(НТНоО&,p Н"юТ┌П&Т┐Н"юО$╗ТП"НоО!ц Н"юТП%ТН"юО ? НоОZ Н"юТдТеН"юОж НоОЯ Н"юТРП:Н"юОmТ▄Т█П#Н"юОИТНТОП"Н"юОe НоО─Н"юТўТ╞П#Н"юОЭТ ЪфЇ╣99XVlAlto Gateway Microcode Package18Pup checksum computationA Ram subroutine is included for efficient computation of the Pup software checksum:PupChecksum:PROCEDURE[initialSum: WORD, address: POINTER, count: CARDINAL]RETURNS[resultSum: WORD]The address should be a pointer to the first word of a Pup and the count the number of words inthe Pup, exclusive of the checksum word (i.e., (Pup.length-1)/2). initialSum must be zero.Timing for this subroutine is 9 Alto cycles per word, or about 425 microseconds for a maximum-length Pup.Interval timer (CommProc only)The CommProc hardware includes a task-driven interval timer. The Gateway microcode packagesupports this; however, the interval timer is not required by present Pup Gateway applications.If the interval timer is to be used, the software must reserve and initialize three additional words justbelow the beginning of the Line Table. These are:Word -4Interrupt bit mask. An interrupt is initiated on the designated channel(s)each time the interval timer expires.Word -3Timer interval, in units of 625 microseconds.Word -2Interval Timer counter. This should be initialized to the timer intervalminus one, and is thereafter maintained by the microcode.The interval timer is enabled by storing 100000B in location 177400B, and disabled by storing 0 intothe same word. While the hardware is enabled, the microcode issues one interrupt per timerinterval.If the interval timer is being used, one should take care to disable it before entering the debugger.Note: the interval timer microcode is not included in the MesaGateCPChain1822 configuration.Additional Ethernet controllersThe Gateway microcode package includes microcode for controlling up to two additional Ethernetinterfaces. For details, consult the memo How to install extra Ethernet interfaces in an Alto. Thetask number, SIO control bit, and control block address assignments are as follows:ControllerTaskSIO bitsControl blockStandard Ethernet714, 15600B - 611BFirst extra Ethernet212, 13630B - 641BSecond extra Ethernet110, 11642B - 653BSource files ExtraEther1.mu and ExtraEther2.mu contain microcode for controlling the first andsecond additional Ethernets. This microcode operates identically to the standard Ethernet microcodeexcept for task number, SIO bits, and control block address. All the standard Ram images exceptMesaGateEIAChain and MesaGateCPChain1822 include ExtraEther1 but not ExtraEther2.In order to operate a second extra Ethernet interface in conjunction with Mesa (which uses nearlyevery available R- and S-register), it is necessary to free up two additional R-registers. This may bedone by replacing the standard display and cursor microcode by the code contained inGateDisplay.mu, which uses two fewer R-registers.ЪНЇОfЯpТНG?НыОbsНыО_9pПTНоО\TНёОZпrpТXrp rprpНёОYLrprpНыОVgТ≤Т≥ПMНыОTЦТЪТПSНыОQЧТїПUТ╗НыОPzТ НыОLбsНыОIщpТ╟ПSТ╠НыОHYТ╩ПRТ╪ НыОEtТ│П6Т┌П3НыОCПТП2НоОAТ─Н═Т╟П,Т╠Н═О?┤ТП%НоО<╒Т─Н═ТП(НоО9ҐТ─Н═ТрП2ТсН═О89ТП9НыО5UТ▀Т▄rprpНыО3пТтП[НыО2LНыО/hТ≤Т≥ПMНыО,┐spТпТяПSНыО(йsТНыО%ЕpТ╔ ТіПSНыО$aТ·П+sП3pТ÷НыО"щТrpПCНоОЬs Н$юН+@tsТ─Н3юТНоОpТ─Н$юН+@Н3юrpТrНоО░pТ─Н$юН+@Н3юrpТrНоОpТ─Н$юН+@Н3юrpТrНыО'pТлПTТм НыОёТ└ПZТ┘ НыОТ╔rpТіПEНыО⌡ТПQНыОІТ═П"Т║П?НыО2Т⌠rprpП6rpТ■НыОўТ.ПQТ/НыО*ТП%rp йЇ Ц>/](`Alto Gateway Microcode Package19The second Ethernet interface conflicts with the CommProc interval timer over use of task 1. Sincethe interval timer is not used in the Pup Gateway application, it suffices to disconnect the intervaltimer task wakeup and active signals (see "Hardware requirements" at the beginning of thisdocument).Another version of the Ethernet microcode exists that provides a somewhat different softwareinterface to the Ethernet. The major difference is that input is specified by means of chains ofcommand blocks that are followed automatically by the microcode, and the microcode also handlesmost of the decisions about switching between input and output. This permits the software to keepthe Ethernet receiver turned on a greater fraction of the time than with the standard microcode(which requires the software to restart the interface after every packet sent or received); we expectthis to improve the performance of Alto Gateways.Files ChainEther0.mu, ChainEther1.mu, and ChainEther2.mu contain the microcode for the standardEthernet interface and the first and second extra interfaces, respectively. The standardconfigurations MesaGateEIAChain and MesaGateCPChain1822 include all three. Programminginformation may be obtained from Hal Murray.Due to Ram space limitations, the MesaGateEIAChain and MesaGateCPChain1822 configurationsdo not include the uninterpreted block and character-at-a-time software interfaces or the microcodefor controlling the CommProc interval timer. These are not required in the Pup Gatewayapplication.ЪНЇОfЯpТНG?НыОbТ▀П0Т▄П3НыО` Т²П1Т·П4НыО_ТЯ ТРПPНыО]▓ НыОZґТЦП>ТДНыОY)ТЇТ╦ПGНыОW╔Т≤ПDТ≥НыОV!Т█П%Т▌П=НыОT²Т╩П_НыОSТ²П'Т·П>НыОQ■ТП1НыОN╟Т┐ПRТ└НыОM,Т<П=Т=НыОK╗ТГПKТХНыОJ#ТП,НыОG?Т╡П2ТЁП'НыОE╩Т≤ПUТ≥ НыОD7ТШП3ТЭП$НыОB╡ЇBk>/%═≈ TIMESROMAN TIMESROMAN TIMESROMAN LOGO TIMESROMAN TIMESROMAN TIMESROMAN TIMESROMAN TIMESROMAN TIMESROMAN TIMESROMAN TIMESROMANЮ▌╨ ╙!╒(І0╠8 ┤AG{O zXа`лh ╨q┴y©─■┤═▐i■#: ФB":Ф┌P┌P*▌J"┌P┌P*▌J":Е┌P┌PB"*iA":ФB: ;Z: ;Z┤"9XФ*▄J"9RФ┼"iТЭ]L"=ґ·#B " 9╘ФB: ;Z: #: ФB:Z"┌P┌P*▌J:Z":ФЩPЕB╔"*:ЎC:Z:Z" **▌J"9kФB"┐B":ДJФ: ;Z":ЕB:Z:Z⌡":·#:Ф:Е*:ЎC"┐B":ДJН":·#B":Е ":Е ":·#*if┌ !cicj/≈∙ЪЪ■н ЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪGatewayMicrocode.pressTaft10-Feb-80 18:14:37 PST∙