[Simh] KDP Documentation
Mark Pizzolato - Info Comm
Mark at infocomm.com
Wed May 29 11:39:14 EDT 2013
Hi Tim,
On Tuesday, May 28, 2013 at 8:54 AM, Timothe Litt wrote:
> I knew I had some documentation for the KMC/DUP combination, though I
> still haven't found the COMIOP/DUP manual (AA-5670A-TC) in my
> collection, or on-line. It may be on the -11 or VAX microfiche, but
> I've contributed my sets to CHM. Don't think they've been digitized.
>
> Anyhow, the following memo describes COM IOP-DUP at a high level, and
> describes in some detail how the KMC controls the DUP. It may be useful
> for your efforts. One note: "flag mode" as used here has nothing to do
> with the FLAG character of bit-stuffing protocols. It's a synonym for
> polled (v.s. interrupt-driven) IO.
>
> By the way, there also was COM IOP-DZ, which did similar things with the
> DZ11.
Thanks for this.
I've got a couple of questions for you or anyone else:
1) The below document mentions the possibility of one or two DUPs related to a single KMC. What tells the KMC which DUP it is to exchange data with, and how does it know the DUP's bus address?
2) You had mentioned previously that the host OS doesn't interact with the DUP device except for a possible initial device probe testing for NXM, and then writing zeros to the registers. What would happen if the OS didn't find/see the DUP at all?
3) How many KMC/DUP devices would work on a given Unibus if there were no power limitations (i.e. how many devices could the OS software interact with)?
4) Was there software support for talking to a bare DUP without a related KMC in any PDP10 operating systems?
5) Was this KMC/DUP combination ever a supported device on PDP11 or VAX systems?
Thanks.
- Mark
> COMMUNICATIONS IOP-DUP
>
>
>
>
> COMMUNICATIONS IOP-DUP
> Page 1-2
>
>
> INTRODUCTION
> ------------
>
>
>
>
> The sychronous communications options on the 2020 are comprised of a
> KMC11 and either one or two DUP11s. This
> combination can also be referred to as COMM IOP-DUP.
>
> The DUP11 forms an interface between a synchronous modem and the
> UNIBUS. Eight bit bytes of data are transferred to
> the DUP over the UNIBUS and are serialized and formatted for transmission.
> The format of the data stream is controlled by
> registers in the DUP which are read and written by either the CPU or a local
> IO Processor. (IOP)
>
> The 2020 utilizes the KMC11 as the local IOP for the DUP11. The KMC is a
> microprogrammed auxilliary microprocessor
> designed for communications functions. The microprogram in the KMC is
> held in a writable control store memory (CRAM 16
> bits x 1K) which is loaded over the UNIBUS by the 2020. This allows changes
> in protocols etc. to be nearly transparent
> to the CPU.
>
> The KMC transfers data between 2020 memory and the DUP using DMA
> and NPR transfers. The DUP11 is operated in flag
> mode (interrupts disabled) and is interrogated by the KMC11 periodically to
> determine if the character being transmitted
> is done or if a character has been assembled by the receiver. This relieves
> the CPU of the extensive interrupt handling
> which would otherwise be necessary to maintain the synchronous data
> stream.
>
>
>
> REFERENCES
> ----------
>
>
>
> 1. KMC11 Users Manual EK-KMC11-OP-001
>
> 2. COMM IOP-DUP Programming Manual AA-5670A-TC
>
> 3. DSKMA Diagnostic Microfiche AH-E373A-DD
>
> 4. DSDUA Diagnostic Microfiche AH-E371A-DD
>
> 5. DUP11 Maintenance Manual EK-DUP11-MM-002
>
> 6. KS10 Maintenance Guide EK-OKS10-MG-001
>
> 7. Terminals and Communications Handbook
>
>
> COMM IOP-DUP Page 1-3
> KMC11
>
>
> The functional operation of the KMC11 is totally dependent on the
> microcode internal to the unit. Since this
> microcode is in a writable control store, no attempt will be made to
> present internal operations of the KMC11 in this
> course. We will deal with the functional interface between the KMC11,
> DUP11, and the UNIBUS.
>
> The KMC11 has 4 UNIBUS addressable registers. (REFER to Fig. 1) All
> communications between the CPU and the KMC11
> are accomplished using these registers. The KMC11 views these as 8 byte
> size registers.(BSEL 0-7, addresses 76XXX0-7)
> They appear to the UNIBUS as 4, word or byte addressable, registers.(SEL 0,
> 2, 4, and 6)
>
> Only the high byte of register SEL 0 (BSEL 1) has a fixed function. This is
> the Maintenance Register. The remainder
> of the UNIBUS register functions are controlled by the KMC11 microcode and
> the CPU software.
>
> The Maintenance Register can be used to alter the KMC11 internal data
> paths for loading the CRAM and for other
> maintenance functions.
>
> For most maintenance functions, the RUN bit of the maintenance
> Register will be cleared. This stops the
> microprocessor clock which allows the CPU to manipulate the UNIBUS
> registers without interference from the KMC11.
>
> Bit 10 of the maintenance register ,when set, causes the 10 low order bits
> of SEL 4 to be used as an address for
> CRAM. SEL 6 can then be used for either reading or writing the addressed
> CRAM location. The read or write is controlled
> by maintenance register bits 10 and 9 + 10 + 13 respectively.
>
> To access CRAM, the 2020 CPU will clear the RUN bit of the Maintenance
> Register. It will then load the desired CRAM
> address into bits 0 -> 9 of SEL 4. If the operation is to write CRAM, the CPU
> will load SEL 6 with the new CRAM data and
> write the Maintenance Register, setting bits 9, 10 and 13. This will cause the
> KMC11 to write the data in SEL 6 to the
> CRAM location specified by SEL 4 bits 0 -> 9. To read CRAM, the CPU will
> write the Maintenance Register bit 10. This
> will cause the data in the CRAM location specified by bits 0->9 of SEL 4 to be
> transferred to SEL 6. The CPU will then
> read SEL 6 to determine the contents of the CRAM location.
>
> The Maintenance Register can be used to single step through instructions
> supplied by the CPU, read CRAM, and single
> step through the microcode for diagnostic purposes.
>
> The KMC11 has its own internal memory (1k x 8 bits) which it uses for data
> storage and computation. This memory can
> not be used for instruction storage nor can the CRAM contents be modified
> by the KMC11.
>
>
>
> COMM IOP-DUP Page 1-4
> KMC11 - UBA - MEMORY DATA TRANSFER
>
>
> The KMC11 receives commands from the CPU through it's UNIBUS registers.
> The microcode interprets the command and then
> takes the proper actions to process the command. The KMC11 can also
> send commands to the CPU by writing it's UNIBUS
> registers and posting an interrupt to the UNIBUS.
>
> There are 3 commands which must occur before transmit and receive
> operations can take place.
>
>
> 1. INITIALIZATION; This command must be performed after loading
> KMC11 microcode to initiate operation.
>
>
> 2. A BASE IN command for each DUP11; This command informs the KMC
> of the line number assignment and CSR base
> address of each DUP11.
>
>
> 3. A CONTROL IN command for each DUP11; This command sets up the
> line parameters for each DUP11 and the polling
> rate to be used in interrogating the DUP CSRs.
>
>
>
> The COMM IOP-DUP handles the modem handshaking and monitoring with
> the exception of the RING and CARRIER lines. The COMM
> IOP-DUP does all of the memory to transmitter and receiver to memory
> data handling. The CPU informs the COMM IOP-DUP of
> the areas in memory to be used for transmit and receive data. This is done
> through BUFFER DESCRIPTOR LISTS for each
> transmit and receive channel.
>
> Each buffer descriptor list points to the start of a series of 3 word (16 bit
> word length) buffer descriptors in
> contiguous memory locations. Each buffer descriptor contains; a starting
> address for the buffer, a byte count, and
> control fields for the starting and stopping of messages etc.. The buffers may
> be scattered throughout main memory with
> the descriptors pointing to them.
>
> The major requirement is that the buffer descriptor list be in a series of
> continuous memory locations. Up to 2
> lists may be sent to the KMC11 for each transmit and receive line. The lists
> are sent to the COMM IOP-DUP when the CPU
> desires to transmit or receive messages.
>
> This is done with a BUFFER ADDRESS IN command. This command has the
> starting address of the buffer descriptor list,
> the line number the list applies to, and a bit controlling whether it is a
> transmit or receive buffer.
>
>
> NOTE
>
> The CPU will also have to set up the UBA pager for the buffer areas in
> memory for address
> translation from 18 bit UNIBUS to KS10 addressing.
>
>
>
> The KMC11 uses the buffer descriptor lists to set up it's DMA addressing
> for each transmit and receive line. Once
> the lists are in the KMC11, the actual data transfer operations are transparent
> to the CPU.
>
>
> NOTE
>
> All transfers initiated by the KMC11 over the UNIBUS are NPRs. The
> only time the KMC11
> "talks" to the 2020 CPU is when the CPU writes the KMCs
> registers, or when posting an
> interrupt on the UNIBUS.
>
>
>
> COMM IOP-DUP Page 1-5
> KMC11 - UBA - MEMORY DATA TRANSFER
>
>
> TRANSMIT
> --------
>
>
> NOTE
>
> The following description is for DDCMP operation of the COMM IOP-
> DUP.
>
>
>
> The CPU will compile the message to be sent in memory and transfer the
> buffer descriptor list to the KMC11.
>
> The KMC11 receives the buffer descriptor list with the command to
> transmit and retreives the first buffer descriptor
> from memory. The KMC then does the required handshaking with the
> modem via the RXCSR register of the DUP11. The KMC
> initiates the message by setting the SEND bit in TXCSR of the DUP and
> transferring a SYNC character and the TSOM bit to
> the TXDBUF.
>
> As each character is transferred from the TXDBUF to the transmitter shift
> register in the DUP, TXDONE will be set in
> TXCSR. The KMC checks the TXCSR for TXDONE by periodically reading the
> register.
>
> The rate at which the DUP11 registers are polled by the KMC is controlled
> by one of the set up commands sent to the
> KMC by the CPU at system initialization.
>
> When the KMC detects TXDONE, it will transfer another character to the
> TXDBUF of the DUP. This will continue until 8
> SYNC characters have been transferred, when the KMC will reset the TSOM
> bit.
>
>
> NOTE
>
> The COMM IOP-DUP microcode in the KMC11 can send 8 sync
> characters automatically in DDCMP
> mode, depending on a control bit within the buffer descriptor. If
> the control bit is not
> set, the sync characters (if any) must be included with the message.
>
>
>
> At this point the KMC will begin transferring message data from 2020
> memory using NPRs. The transfer sequence is
> similar to the NPR slow mode transfer used for the tape unit, but 36 bit mode
> is not set.
>
> As each data word is received from the system, the KMC places it in it's
> internal memory and waits for TXDONE to set.
> When the KMC detects TXDONE on a polling cycle, it transfers an 8 bit
> character to the DUP TXDBUF register using a byte
> mode NPR.
>
> This process is repeated until the number of characters transferred is
> equal to the byte count within the buffer
> descriptor. Depending on the state of control bits in the buffer descriptor ,
> the KMC will either; start transmitting
> data from a second buffer descriptor or buffer descriptor list and interrupt
> the CPU , or terminate the message.
>
> When the last character of the message is transferred to the DUP, the
> KMC will set the TEOM bit in the TXCSR. This
> causes the accumulated CRC to be transmitted immediately after the last
> character.
>
> A second message may start immediately after the first, using another
> buffer descriptor or buffer descriptor list.
> Messages may be strung together this way until no buffer descriptor list is
> pending in the KMC. Alternately, a message
> may be distributed among several buffer descriptors or descriptor lists,
> terminating only when the bit, in the buffer
> descriptor, controlling the setting of the TEOM bit, is set.
>
> COMM IOP-DUP Page 1-6
> KMC11 - UBA - MEMORY DATA TRANSFER
>
>
> RECEIVE
> -------
>
>
> NOTE
>
> The following discussion assumes that the COMM IOP-DUP has been
> initialized and that DDCMP
> is the protocol.
>
>
>
> The COMM IOP-DUP receive operation is initiated when the CPU assigns a
> buffer descriptor list or lists to a receive
> line. The buffer descriptor list tells the KMC11 where in memory to place
> received data. If data is received by the
> DUP11 and no buffer descriptor list is assigned, the COMM IOP-DUP will post
> an error to the CPU via an interrupt.
>
> When the first non-sync character is received and in the RXDBUF, the
> DUP11 sets RXDONE. This is detected by the
> KMC11 on the next polling cycle and the character is transferred to the KMC
> with a byte mode NPR.
>
> If the first character following the leading sync characters is not an SOH,
> ENQ or DLE character the associated DUP11
> is resynchronized. In this case no interrupt is sent to the CPU.
>
> The KMC will assemble the characters into 16 bit words for transfer to
> main memory. As each word is assembled, the
> KMC will issue an NPR transfer, through the UBA, to main memory. The
> transfer sequence resembles the NPR slow mode
> transfers used for tape system data transfer with 36 bit mode disabled.
>
> The first six bytes in DDCMP protocol are the HEADER. This is treated as a
> discrete message by the hardware and CRC
> is done on these six bytes. If a header CRC error occurs, the KMC aborts
> reception, posts an error interrupt to the CPU,
> and resumes searching for sync characters.
>
> The HEADER is analyzed by the KMC11 for the BYTE COUNT and the
> DDCMP quick sync bit. The byte count allows the KMC
> to discern the message CRC characters from the last data character in the
> message. If the quick sync bit is set, the KMC
> will place the applicable DUP11 in sync search mode immediately following
> the end of the message. If the quick sync bit
> is not set, the KMC11 assumes the next message is either abutted to the
> current message or is preceded by at least 8 sync
> characters.
>
> The KMC will continue transferring data from the DUP at each assertion of
> RXDONE, assembling 16 bit words, and
> transferring the words to memory until the number of bytes received equals
> the byte count in the header.
>
> The KMC11 will not post a completion interrupt to the CPU until the entire
> message has been received unless the
> message is larger than the currently assigned message buffer. If the
> message is larger than the current buffer, the KMC
> will post an interrupt to the CPU and continue transferring data to the next
> buffer defined in the buffer descriptor list.
>
> When the last character of the message has been received, the KMC will
> check the CRC and do one of three things:
>
> 1. If CRC was bad, the KMC will post an error interrupt to the CPU and
> immediately enter sync search mode.
>
> 2. If CRC was good and the quick sync bit was set in the header, the KMC
> will start looking for another message
> preceded by less than 8 sync characters.
>
> 3. If CRC was good and the quick sync bit wasn't set, the KMC will examine
> the next character after the CRC and, if
> it is a start of header (SOH), continue reception of the next message,
> placing the data in the next buffer.
>
>
> COMM IOP-DUP Page 1-7
> KMC11 - UBA - MEMORY DATA TRANSFER
>
>
> There are two output commands issued by the KMC11 to the CPU. The
> first is a CONTROL OUT command and is used in
> posting error conditions to the CPU. The second is the BUFFER ADDRESS
> OUT command used to indicate that that a buffer
> assigned by a buffer descriptor has been filled or its' contents transmitted.
> The buffer address out command is also used
> when a complete message has been received, whether or not it has filled a
> buffer. In any case, the KMC will shift its'
> memory NPR operations to the next buffer in the buffer descriptor list or
> to the next buffer descriptor list as
> applicable.
>
>
> COMM IOP-DUP Page 1-8
> DUP11
>
>
> INTRODUCTION
> ------------
>
>
> The DUP11, together with the KMC11, forms a synchronous
> communications subsystem for the 2020. High speed
> synchronous communications capability allows the 2020 to be used in
> computer networking applications such as DECNET. This
> type of application may be a major factor in a buyer's decision on which
> computer system he will purchase.
>
> BASIC BLOCK FUNCTIONS
> ---------------------
>
> The DUP11 basic block can be broken down into three major areas;
>
> 1. THE UNIBUS INTERFACE comprised of the UNIBUS tranceivers, the
> interrupt control logic, the address select logic,
> the reset logic, and the UNIBUS multiplexer.
>
> 2. THE REGISTERS AND CONTROL LOGIC comprised of the five registers
> and part of the TX control and RX control logic.
>
> 3. THE MODEM INTERFACE comprised of the remainder of the TX control
> and RX control logic and the clock logic.
>
> UNIBUS INTERFACE
> ----------------
>
>
> This section of the DUP11 is responsible for getting data into and out of
> the unit to the UNIBUS. The address select
> logic decodes the UNIBUS address lines and determines if the address on the
> lines matches the switch settings on the DUP11
> and what type of data cycle is required.
>
> The interrupt control logic will issue a BR when conditions internal to the
> DUP11 require processor intervention.
> The interrupt logic can be enabled or disabled under software control.
>
> The reset logic initializes the DUP11 when a UNIBUS initialize signal occurs.
> The reset logic will also initialize
> the DUP11 under software control when TXCSR bit 8 is set.
>
> The UNIBUS tranceivers and multiplexer receive and transmit data
> between the UNIBUS and the DUP11 registers under
> control of the address select logic.
>
> DUP11 REGISTERS
> ---------------
>
> There are 5 registers in the DUP11 which are used to control it's operation
> and communicate with the UNIBUS.
>
> 1. The RXCSR register is used to control the operation of the receiver
> section of the DUP11 and to interface with
> the modem. The register is R/W and is word and byte addressable.
>
> 2. The RXDBUF is a read only register which holds the received data in the
> low byte and status information in the
> high byte. The RXDBUF shares the same address with PACSR and is
> word addressable.
>
> 3. The PACSR is a write only register which controls the overall mode of
> the DUP11. This register contains the DEC
> mode bit, the bit which determines whether CRC is to be used or not,
> the secondary address mode bit, and either
> the secondary address or the SYNC character in the low byte. The
> PACSR and the RXDBUF share the same address and
> are word addressable only.
>
> COMM IOP-DUP Page 1-9
> DUP11
>
>
> 4. The TXCSR register is used to control the operation of the transmitter
> section of the DUP11 and to control
> maintenance functions. The register is read/write and word and byte
> addressable.
>
> 5. The TXDBUF register contains the remainder of the control and status
> bits for the transmitter and the low byte
> holds the data to be transmitted. The register is word and byte
> addressable and is a read/write register.
>
> TX CONTROL LOGIC
> ----------------
>
> The transmit control logic is responsible for:
>
> 1. Serializing data to be transmitted and transferring it to the modem.
>
> 2. Transmission of FLAG and ABORT sequences in bit oriented protocols.
> (DEC MODE reset)
>
> 3. Bit stuffing when in bit oriented protocols.
>
> 4. Signaling when the character currently being transmitted is done by
> setting TXDONE in TXCSR.
>
> 5. Computing CRC in either CRC-16 or CRC/CCITT format on transmitted
> data.
>
> RX CONTROL LOGIC
> ----------------
>
> The receiver control logic is responsible for:
> LE;Synchronizing the receiver logic with the received signal.
>
> 1. Assembling the received serial data in the receiver shift register and
> transferring it to the RXDBUF.
>
> 2. Signaling when the latest assembled character is available in the
> RXDBUF by asserting RXDONE.
>
> 3. "Stripping" extra leading SYNC characters after synchronization when in
> DEC mode. LE;Deleting "stuffed" "0" bits
> from the data stream when not in DEC mode.
>
> 4. Detecting FLAG and ABORT sequences when not in DEC mode.
>
> 5. Checking received CRC characters against computed CRC characters in
> CRC-16 or CRC/CCITT formats.
>
> FUNCTIONAL DESCRIPTION
> ----------------------
>
>
> The transmit operation of the DUP11 is somewhat dependent on whether
> a bit oriented protocol (SDLC type protocols) or
> a byte oriented protocol (DDCMP etc.) is being used.
>
> BYTE ORIENTED OPERATION (DDCMP and BISYNC)
> ------------------------------------------
>
>
> For byte mode operation the DEC mode bit in PACSR must be set. This will
> cause the CRC circuits to use the CRC/16
> format to check and generate CRC. This bit also controls whether "0" bits
> are "stuffed" into or stripped from a data
> stream containing more than 5 consecutive "1" bits. When the DEC mode bit
> is set, bit stuffing is not done.
>
> COMM IOP-DUP Page 1-10
> DUP11
>
>
> The CRC PAR INH bit in PACSR is used to enable or disable CRC generation
> or error detection. This bit will usually
> be set on BISYNC protocols and reset for DDCMP.
>
> All "handshaking" with the modem must be completed prior to the start
> of transmission. This is done through the
> RXCSR register. The "handshaking" is not automatic and must be done by the
> program.
>
> The insertion of Sync characters is also a program function. The DUP11
> has no provision for automatically
> transmitting sync characters.
>
> Transmission begins when the program sets the SEND bit in TXCSR and
> loads a sync character into the TXDBUF along with
> the Transmit Start Of Message bit. All sync characters must be loaded by the
> program and the TSOM bit held asserted until
> the start of the last sync character. As each character is sent out, the
> TXDONE bit is set in TXCSR. The program will
> get another sync character, load it into TXDBUF and repeat until the proper
> number of sync characters have been sent.
> After the start of the last sync character the program will clear TSOM. At the
> next assertion of TXDONE the first data
> character will be loaded into TXDBUF and the CRC circuit will start to
> compute the CRC code for the data portion of the
> message.
>
>
> NOTE
>
> The CRC calculation can be inhibited by bit 09 of PACSR. This will
> usually be the case for
> BISYNC type protocols.
>
>
>
> The program will continue to load characters into the TXDBUF, at each
> transition of TXDONE, until the end of the
> message. When the last character is loaded, the TEOM bit will also be set by
> the program. This will cause the CRC check
> character to be transmitted immediately following the last data character. (If
> the CRC is enabled)
>
> BIT ORIENTED OPERATION (SDLC etc.)
> ----------------------------------
>
> For operation in SDLC or other bit oriented protocols the DEC MODE bit in
> PACSR must be reset. This allows bit
> stuffing (The insertion of a "0" bit after each 5 consecutive "1" bits in a data
> stream of more than 5 consecutive "1"
> bits) to prevent confusing data with FLAG and ABORT sequences.
>
> The DEC MODE bit being reset also alters the CRC computation so that the
> CRC conforms to CRC/CCITT format. Some
> protocols may compute the CRC differently and if one of those is in use the
> CRC will be disabled using bit 09 of PARCSR.
> If CRC is disabled the program must compute any required CRC for the
> protocol in use.
>
>
> NOTE
>
> The following discussion assumes that all required "handshaking"
> with the modem has been
> completed and the DUP11 has been initialized.
>
>
>
> To start transmission, the SEND bit must be set in TXCSR and the TSOM bit
> in TXDBUF. This will cause an initial FLAG
> character to be transmitted. FLAGs will continue to be transmitted until the
> TSOM bit is reset. The transmission of FLAG
> characters in this mode is automatic and the characters do not have to be
> loaded into the TXDBUF by the processor. When
> the TSOM bit is reset, the TXDONE bit will be asserted at the conclusion of
> the character in transmission.
>
> COMM IOP-DUP Page 1-11
> DUP11
>
>
> When the program "sees" TXDONE, it will start transferring data to the
> TXDBUF. At each assertion of TXDONE, another
> character of data will be loaded. The CRC computation (if enabled) starts
> with the transfer of the first data to TXDBUF.
> The transmitter also enters the "transparent" state (bit stuffing is enabled)
> when the transmitter starts sending data.
>
> At the conclusion of the message the program sets the TEOM bit in
> TXDBUF and, at the end of the character being
> serialized, (if CRC is enabled) the CRC character is transmitted. At the
> conclusion of the CRC character a FLAG character
> is automatically transmitted.
>
> The program has three options at this point: SEND may be cleared, which
> allows the FLAG character to be completed
> and after a delay of 1 1/2 bit times the transmitter enters the IDLE state.
> TEOM may be held set, which will cause
> continuous FLAG characters to be transmitted. TEOM may be cleared and a
> second data message started without setting TSOM.
>
> The receiver section operates differently for byte oriented and bit
> oriented protocols and the two modes are
> discussed separately in the following section.
>
> BYTE ORIENTED RECEIVER (DDCMP, BISYNC etc.)
> -------------------------------------------
>
>
> For BYTE mode operation, the DEC MODE bit and the SYNC character to be
> used must be loaded into the PACSR prior to
> enabling the receiver. The DEC MODE bit causes the low byte of PACSR to
> be recognized as a SYNC character, and the CRC
> circuitry of both the receiver and transmitter to use CRC-16 for generating
> and checking CRC.
>
> The STRIP SYNC bit of RXCSR may also be set, which allows SYNC
> characters occuring after receiver synchronization to
> be automatically deleted. Synchronization is considered complete when 2
> succesive characters which match the low byte of
> PACSR have been recognized. The STRIP SYNC bit causes any other leading
> SYNC characters to be ignored.
>
> After the initialization and any needed modem handshaking has been
> done, the RCVEN bit in RXCSR may be set. This
> enables the receiver to search the incoming signals until 2 successive SYNC
> characters are detected. All characters
> following the detection of the 2 successive SYNC characters are interpreted
> as data. (Unless the STRIP SYNC bit is set,
> when it is the detection of the first non-SYNC character that will cause all
> following characters to be interpreted as
> data.) When this has occured, the RXACT bit will be asserted and the RXDONE
> bit set. (Also this will disable the STRIP
> SYNC logic until the receiver logic is reinitialized.)
>
> All data following the SYNC characters is included in the CRC calculation.
> For some protocols in the BISYNC family
> the CRC logic must be disabled due to possible control characters in the data
> field.
>
> Once RXDONE is set the program will read the assembled character in the
> RXBUF, reseting RXDONE. This process will
> repeat until the expected number of characters has been received. The
> program will then sample the CRC PAR ERR bit to
> determine if there was an error in the data received. (If CRC was enabled)
> After the CRC is sampled, the RCVEN bit will
> be cleared to reinitialize the receiver.
>
> At this point the entire process may repeat to receive another message.
>
> BIT MODE RECEIVE OPERATION (SDLC etc.)
> --------------------------------------
>
>
> For SDLC family protocols the DEC MODE bit must be reset. This changes
> the CRC checking to CRC/CCITT and enables the
> "stuffed" "0" bits in the data stream to be stripped out, restoring the
> original data. The "0" bits were originally
> inserted to avoid confusion of data with FLAG or ABORT characters. These
> characters are detected by the DUP11 when the
> DEC MODE bit is not set.
>
> COMM IOP-DUP Page 1-12
> DUP11
>
>
> The reset DEC MODE bit also causes a different function to be assigned to
> the low byte of PACSR. This byte may be
> used as a secondary station address for protocols supporting this option. This
> is under the control of bit 12 of PACSR.
>
> After initialization and any necessary handshaking with the modem, the
> RCVEN bit is set. After this bit is set, the
> receiver searches the incoming data for FLAG characters. If the receiver is
> operating in the primary mode, all data
> subsequent to the last initial FLAG character is presented to the program.
> The RSOM bit is set with the reception of the
> initial data character and RXDONE is set when the data is in the RXDBUF.
>
> If the receiver is in the secondary address mode, the character
> immediately following the last initial FLAG is
> compared with the low byte of PACSR. If the character matches the
> contents of that byte, the character immediately
> following is taken as the start of the data field and TSOM is set. If the
> contents do not match, the receiver resumes
> looking for FLAG characters and TSOM is not set.
>
> When the start of the data field is detected, RXACT is set in RXCSR. The
> data continues to be assembled (with any
> "stuffed" zeros removed) and transferred to the RXDBUF with each transfer
> setting RXDONE. The program reads the data from
> RXDBUF (which resets RXDONE) with each assertion of RXDONE.
>
> This process continues until the detection of a FLAG character which
> signifies the end of the message. The detection
> of the FLAG will cause REOM and RXDONE to set. The contents of the
> RXDBUF is invalid when REOM is set.
>
> If CRC checking is enabled, the check will be valid only when REOM is set.
> The entire contents of the message
> between the FLAG characters is included in the CRC check.
>
> INTERRUPT OPERATION
> --------------------
>
> The DUP11 can be operated in two modes; flag mode, and interrupt
> mode.
>
> In flag mode, the DUP11 does not interrupt the processor. The RXCSR and
> TXCSR must be interrogated to determine the
> state of the respective DONE bits and the modem control or status bits.
> The interrogation must occur often enough to
> ensure that characters are removed from, or written into, the respective
> DBUF without causing data late or overrun
> conditions.
>
> In the interrupt mode, the DUP11 interrupts the processor when either
> DONE bit is set and when the modem changes
> status.
>
> There are two discrete types of interrupt which generate different
> vector addresses. Receiver and data set
> interrupts generate vector adress XX0. Transmitter interrupts generate
> vector address XX4. The XX portion of the vector
> is switch selectable.
>
> Whether the DUP11 is in interrupt or flag mode is determined by bits 5
> and 6 of RXCSR and bit 6 of TXCSR. These are
> the interrupt enable bits. Bit 5 of RXCSR controls data set interrupts. Bit 6
> of RXCSR and TXCSR control receiver and
> transmitter interrupts respectively. When each of these bits are set, the
> corresponding interrupt is enabled.
>
> Receiver and transmitter interrupts are initiated by the RXDONE and
> TXDONE bits respectively. If a DONE bit is set
> by the DUP11, and the corresponding interrupt is enabled, an interrupt is
> gated to the UNIBUS.
>
> In the 2020 the DUP11 is operated in the flag mode for data
> communications. The servicing of the DUP11 registers is
> done by the KMC11 which relieves the KS10 CPU of the overhead. In
> diagnostics for the DUP11 on the KS10 the DUP11 is
> operated in the interrupt mode.
>
>
>
>
> --
> This communication may not represent my employer's views,
> if any, on the matters discussed.
>
More information about the Simh
mailing list