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.
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:
- Read the Read Module Type (RMT) register of every slot. An RMT of zero indicates an empty slot.
- 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.
- 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:
- OCTOBUS-DRIVER function 9, to connect CMD X
- OCTOBUS-DRIVER function 1, to send a message to CMD X
- 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.