OCTOBUS

Octobus (or OCTObus, as it was written in some documentation) was a high-speed serial command bus for system-internal high speed signal/command transfer. It could send short messages used for synchronization of directly coupled processors in multi-processor configurations including DOMINO I/O controllers.

OCTOBUS card in a ND-5700 crate.

Purpose

Octobus was a part of transforming the original ND-500 design, where the ND-110 processor was an I/O bottleneck, to a multi-processor system with DOMINO I/O boards connected directly to the MF-Bus. The role of OCTObus was to manage and synchronize the processors.

Physical implementation

The MPM-5 (MultiPortMemory) system was extended with the physical wiring and features for Octobus support and was then called Multi-Function bus, or MF-Bus, introduced with the ND-5000 series.

Protocol overview

• An OCTObus message is 32 bits. It includes priority, destination, source, information, etc.
• Each device connected to the OCTObus is called a node.
• There can be up to 62 nodes on one OCTObus.
• An OCTObus can be bridged to another OCTObus if 62 nodes isn't sufficient.
• One node must be set up as MASTER. This node supplies the OCTObus clock (XCLK)
• Any node can be set up as MASTER, the MASTER node is not special.
• All nodes can take control of the bus, by issuing a request (XREQ) intercepted by the MASTER.
• Power failures are tolerated by all nodes.
• Retries are handled by hardware.

Signals

• XREQ - Transmit request
• XCLK - Clock
• XDAT - Data
• XRFO - Refresh oscillator

Data rate

Data rate depends on cable length.

Cable length in meters	Clock frequency in MHz	Data rate in Mbits/s
6	4	1.0
60	1	0.250
120	0.5	0.125

Cabling

The internal backwired OCTObus in the MF-Bus is called a local OCTObus and is TTL. Non-backwired OCTObus is called global OCTObus and uses differential cable.

Protocol Deep Dive

Software Message Format (16-bit I/O Register)

OCTOBUS frames are manipulated by software as 16-bit words in I/O registers. The following table shows bit assignments:

Bit 15	Bit 14	Bits 13–8						Bit 7	Bit 6	Bit 5	Bit 4	Bits 3–0
C	B	DEST/SOURCE						E	K	M	S	Data/Number
Control	Broadcast	Destination/Broadcast						Emergency	Kick	Multibyte	Start/Stop	Info/OMD

C (Bit 15) — Control

1 = Control message (commands, kicks, multibyte envelopes)

0 = Data message (payload bytes)

B (Bit 14) — Broadcast

1 = Broadcast to station type

0 = Unicast to specific station number

Bits 13–8 (6 bits) — Destination/Source

When B=0: Specific station number (1-62 decimal / 1-76 octal)

When B=1: Broadcast type for all nodes of a given class

Station 0 and 63 reserved/illegal

E (Bit 7) — Emergency

1 = Emergency command (master clear, ACCP termination)

0 = Normal command

Combined with command byte for emergency control codes

K (Bit 6) — Kick

1 = Process activation/synchronization signal

0 = Not a kick message

Kick numbers in bits 3-0 specify activation type (1-6)

M (Bit 5) — Multibyte

1 = Part of multi-frame message sequence

0 = Single-frame message

Used with S flag to delimit SOMB/EOMB boundaries

S (Bit 4) — Start/Stop (when M=1)

1 = Start of Multibyte (SOMB)

0 = End of Multibyte (EOMB)

OMD (Output Message Descriptor, 0-15) in bits 3-0

Bits 3–0 (4 bits) — Data/Number/OMD

Control messages: Command code

Kick messages: Kick number (1-6)

Multibyte messages: OMD (0-15) for message queue/handler

Data frames: Payload byte or metadata

Station Number Assignments

Station numbers follow the format: decimal (octal in ND documentation)

Type	Stations (Decimal)	Octal Range	Purpose
ND-120 CPU	1	1	Primary processor (ND-100 on ND-500-II systems)
MFbus Controllers	2-7	2-7	Memory and I/O control (ND-5000)
SCSI Controllers	8-11	10-13	Disk/storage control
Matra VME	12-13	14-15	VME bus interface
Multifunction Comm	14-15	16-17	Communication controllers
Hyperchannel	16	20	Network interface
FDDI/Fibernet	17-19	21-23	High-speed network
FPS-5000	20-23	24-27	Floating-point accelerator
Graphics Controller	24-27	30-33	Display/graphics control
ND-5000 CPU	56-62	70-76	Processor (up to 7 CPUs per bus)

How station numbers are assigned

Station numbers are assigned by two different mechanisms depending on which part of the bus a node sits on.

• Nodes on the global OCTObus are numbered 0₈ to 17₈, set manually by thumbwheel switches.
• Nodes on the local OCTObus (the MFbus backwiring) are numbered from 77₈ downwards to 20₈, and are initialised by the MFbus controller into on-board registers.

Initialisation runs in two phases.

Phase I

Automatic. Global nodes initialise; local nodes are inhibited and have no station number. The global nodes then elect a MASTER, normally the node with the lowest station number, usually the ND-100.

Phase II

The node designated as configurator broadcasts "Identify yourself". Only global nodes can answer. The configurator then orders the MFbus controller with the highest station number to configure its crate.

To configure a crate, the MFbus controller uses MFbus register cycles rather than OCTObus messages:

1. Read the Read Module Type (RMT) register of every slot. An RMT of zero indicates an empty slot.
2. Write the Write OCTObus Initial values (WOI) register twice — the data path to the BADAP gate array is only 8 bits wide. WOI carries the 5-bit station number (STANO), the station of the power-fail handler, and the broadcast type.
3. Write bit 7 of MASTA at slot address + 4₈, raising OBRES to reset the OBCON gate array and start the node.

The controller then sends "Identify yourself" to station 77₈ and works downwards until it finds a free number, repeating until every node in the crate is numbered, and finally sends "Finish" to the configurator.

Slot addresses are formed by converting the slot number to octal, multiplying by two and appending four zeros. Address 10₈ in slot 14 gives 16₈ × 2 = 34₈, hence 340000₈ + 10₈ = 340010₈.

Message Types

Ident Message (C=1, E=0, K=0, M=0)

Station identity request/response

Bits 3-0 carry the ident number

Used for station discovery and presence verification

Kick Message (C=1, K=1)

Process activation and synchronization signals

Bits 3-0 specify the kick type (1-6)

No response expected

Emergency Message (C=1, E=1)

High-priority control commands (master clear, ACCP termination)

Hardware priority handling

Bits 3-0 carry emergency command code

Multibyte Message (C=1, M=1)

Multi-frame protocol for complex data and commands

Consists of SOMB, payload frames, EOMB

Supports inter-processor messaging via OMD (Output Message Descriptor)

Data Message (C=0)

Payload frame (body of multibyte message)

Bits 7-0 carry one data byte

Part of an active multibyte message sequence

Multibyte Message Protocol

Multibyte messages allow transmission of variable-length payloads (0-255 bytes) across multiple frames. Used for:

• NUCLEUS inter-processor messaging
• System parameter configuration
• Complex command sequences

Frame Sequence

SOMB (Start of Multibyte): C=1, M=1, S=1, OMD in bits 3-0

Destination station/broadcast type in bits 13-8

Initiates message reception at destination

Data Frame 1: C=0, destination station, low byte = source OMD

Identifies which OMD at the source will receive the reply

Data Frame 2: C=0, destination station, low byte = payload byte count N

Specifies how many payload bytes follow

Data Frames 3..N+2: C=0, destination station, low byte = payload byte i

Payload bytes transmitted one per frame

EOMB (End of Multibyte): C=1, M=1, S=0, OMD in bits 3-0

Signals message completion

Destination processes the complete message

OMD (Output Message Descriptor)

Range 0-15 (4 bits), identifies message queue/handler at destination

OMD 0 reserved for OCTOBUS Test Protocol (station firmware service)

OMD 1-15 available for application messages

Destination replies by sending to the source OMD specified in Data Frame 1

The same field is called different things in different Norsk Data documentation. ND-05.017.01 calls it the CMD number and lists the connected ones with the LIST-SUBPROC-TABLE command; the ACCP console calls it a Subprocess; elsewhere it is the OMD. They are the same 4-bit code field.

A destination must connect a CMD before any message addressed to it will be delivered. A multibyte message sent to an unconnected CMD is discarded.

Worked example: MFbus controller search

At power-up the ACCP module searches for an MFbus controller by sending a multibyte message to each of stations 2 through 7 in turn. With nothing answering, six frames per station are transmitted. For station 2 they are:

Frame (hex)	C	B	Dest	Information	Meaning
8235	1	0	2	0x35	M=1, S=1, code 5 — start of multibyte, CMD 5
0205	0	0	2	0x05	data: sender's own CMD number
0202	0	0	2	0x02	data: payload byte count
0203	0	0	2	0x03	data: payload byte 0
02nn	0	0	2	nn	data: payload byte 1, the sender's own station number
8225	1	0	2	0x25	M=1, S=0, code 5 — end of multibyte, CMD 5

The sequence follows the multibyte protocol exactly: SOMB, a data frame giving the source CMD, a data frame giving the byte count, the payload, then EOMB. If no station replies the module reports "MFbus controller not found at Octobus stations 2-7" on its console.

Command Codes

Control messages (C=1, E=0) use command codes in the low byte:

Code (hex)	Octal	Symbol	Purpose
0x00	000	CMACK	Acknowledge
0x0E	016	CMSYS	System parameter (multibyte header)
0x10	020	CMREA	Read address
0x14	024	CMDWW	Direct write word
0x16	026	CMDRW	Direct read word
0x1B	033	CMRUN	Run
0x1C	034	CMSTO	Stop
0x1D	035	CMCON	Continue
0x1E	036	CMRES	Reset
0x21	041	CMMAC	Master Clear (with E=1: emergency 0xA1/241₈)
0x22	042	CMACO	Continue ACCP (with E=1: emergency 0xA2/242₈)
0x24	044	—	Terminate ACCP (with E=1: emergency 0xA4/244₈)
0x31	061	CMENK	Enable kick
0x36	066	CMMIC	Microcode command
0x39	071	CMCPU	CPU reset (sent as multibyte to OMD 3 on ACCP)
0x3A	072	CMTES	Test command

ND-05.017.01 confirms the routing of OMD 3: on the ND-5000 CPU, multibyte messages with CMD number 3 are handled by the Access Processor (ACP).

Kick Numbers

Kick messages (K=1) use 4-bit kick numbers (bits 3-0) for process synchronization:

Kick #	Symbol	Purpose	Used By
1	N100KICK	Activate ND-5000 process	ND-100 to ND-500/ND-5000
2	—	Alternate activate signal	ND-5000
3	CLRKICK	Clear flag, continue process	Inter-CPU coordination
4	—	Update internal clock	System timing
5	—	NUCLEUS kick	NUCLEUS inter-processor messaging
6	IDLEKICK	Save context, go IDLE	Processor idle/sleep

ND-05.017.01 describes kick number 1 as starting the scan of the execution queue in the ND-5000 CPU. Kick messages are accepted from any station, whereas ident messages are only accepted from a station the destination has been prepared to receive them from.

Hardware Message Format (32-bit on Wire)

The wire format includes bits not visible to software (managed by hardware). Total: 1 start bit + 30 data bits + 1 stop bit = 32 bits.

Priority (4 bits)	Dest (6 bits)	C (1)	B (1)	Source (6 bits)	Information (8 bits)	Parity (2 bits)	Ack (2 bits)
Lost Access Counter	Destination Station	Control	Broadcast	Source Station	Data/Command	Bit Count	Delivery Status

Priority (4 bits)

Hardware-managed Lost Access Counter for bus arbitration

Prevents starvation: stations that lose arbitration gain higher priority

ND-14.001.1 is internally inconsistent here: Figure 30 shows Priority occupying bits 30 to 27, which is four bits, while the accompanying text describes it as a 5-bit field. The figure is consistent with the total frame width and is followed here.

Parity (2 bits)

Two LSBs of count of '1' bits in frame (computed by hardware)

Ack (2 bits) — Delivery status code

00 = Timeout (15 retries)

01 = Successfully received

10 = Destination busy (255 retries with automatic retry)

11 = Parity error (B=0) or Ambiguous response (B=1)

Source (6 bits)

Station number of transmitter (set by hardware from STANO register)

On reception, this becomes the visible station number in software

Driver and test interface

On the ND-5000, OCTObus is reached through a 680XX driver. The OCTOBUS-DRIVER test command exposes its functions directly:

Function	Purpose
1	Send multibytes
2	Broadcast multibytes
3	Send kick
4	Send ident
5	Send emergency (not implemented)
6	Read transmit status
7	Connect kick
8	Connect ident
9	Connect CMD
10	Access octobus registers (not implemented)

Sending a multibyte message takes a destination station, the destination CMD number, the sender's own CMD number and the message content. The receiving side reports the source station and the message size; because the source is supplied by hardware in the frame, the size and the sender's own CMD must both travel in the message body — which is what data frames 1 and 2 carry.

To send a message and observe it arrive, the operations must be performed in order:

1. OCTOBUS-DRIVER function 9, to connect CMD X
2. OCTOBUS-DRIVER function 1, to send a message to CMD X
3. LIST-SUBPROC-TABLE, to list the contents of CMD X

The driver can also be bypassed entirely. TRANSMIT-OCTOBUS sends up to five raw bytes with C and B given explicitly, and READ-OCTOBUS-RECEIVE returns one byte from the receive FIFO together with the source station and a status of 000 (valid data) or 002 (not valid data). Bypassing the driver requires the interrupt on channel 6 to be disabled first with DISABLE-INTERRUPT, and re-enabled afterwards with ENABLE-INTERRUPT.

OCTOBUS Test Protocol (OMD 0)

Every station serves OMD 0, which implements the OCTOBUS Test Protocol. Used for:

• Station discovery (Identify yourself)
• Get present stations on bus
• Echo single/multi-word messages
• Read/write Octobus registers
• Get station type and firmware version
• Diagnostic and maintenance operations

Protocol verified from TPE (Test Program Equipment) OCTOBUS B00 test suite:

• Test 1: Transmit-receive loopback
• Test 2: Pattern exhaustion
• Test 3: FIFO depth verification
• Test 4: Station discovery and registry
• Test 5: Single-word echo
• Test 6: Multi-word message echo

See Also

• 5616 — Samson ACCess Processor (ACCP), an OCTObus node
• ND-500 — Classic 32-bit coprocessor
• ND-500-II — ND-500 with OCTOBUS via line driver
• ND-5000 — Native OCTOBUS processor
• NUCLEUS — Inter-processor messaging runtime
• DOMINO — I/O controller system
• MPM-5 — Shared memory predecessor
• MFbus — Modern successor bus (ND-5000)

Sources

• ND-14.001.1A DOMINO Standard Hardware Description — chapter 4 "The OCTObus Adapter (OBA)": the wire frame, arbitration, acknowledge codes, hardware-decoded messages, and node initialisation. Note that this manual does not define the information byte; on printed page 110 it defers four times to a document it calls the "OCTObus Protocol Specification", which carries no ND number in any related-manuals list and does not appear to have survived.
• ND-05.017.01 EN ND-5000 Hardware Maintenance — chapter 3 "Octobus Communication", sections 3.3 and 3.3.1: the information byte encoding (E, K, M, S and the 4-bit code). Chapter 8 documents the OCTOBUS-DRIVER, TRANSMIT-OCTOBUS, READ-OCTOBUS-RECEIVE and LIST-SUBPROC-TABLE test commands.
• ND-820026 DOMINO and NUCLEUS Software Guide — the NUCLEUS message layer above OCTObus, and the DOMINO software stack.
• "Sales information ND-5000 series" (found at www.sintran.com, original published by Norsk Data). Filesize 1.1 MB. Accessed on 03 August 2010.

ND-05.017.01 chapter 8 also cites an "Octobus Driver Programming Guide (written by DVT - 15. Oct. 1986)" for per-function detail. That document is likewise unlocated.