KA780 — VAX-11/780 processor

The KA780 is the processor of a VAX-11/780. QUniLator runs it as a device of its own: the processor, its memory and its console are inside the software, and its UNIBUS adapter puts it on the UniBone’s bus, where the emulated peripherals — a UDA50 disk controller, a DEUNA, a serial multiplexer — answer it as they would a real 780’s adapter. It is listed as cpuvax, of type VAX-11/780.

UNIBUS · UniBone

An emulated processor is UNIBUS-only. A QBone drives a real CPU board and ships no processor emulation.

VMS on an emulated VAX-11/780 builds a whole machine around it, step by step.

What the machine sees

Processor	A VAX-11/780. With VMS idle at its prompt it executes about five times as many instructions a second as the original
Memory	1, 2 or 4 MB, set by memory
Console	The processor’s own console terminal, on the console channel /ws/console/vax. The dashboard’s terminal connects to it on its own
UNIBUS	One UNIBUS adapter. The I/O page and a device’s transfers through the map registers go out on the bus
Boot	START boots bootdevice: RQ0, drive 0 of the UDA50 at 772150, unless set otherwise. See Booting
Clock	Advances with the instructions executed, at the 2 µs an instruction a real 780 takes

There is no time-of-year clock behind it, so VMS asks for the date and time on every boot.

Using it

1. Add cpuvax on the Configurations screen with the peripherals the machine needs: at least a uda with a drive holding a system disk.
2. Set External console to Off on the Machine screen. The VAX talks on its own console, not on the cape’s serial port.
3. Enabling the processor builds the machine and leaves it halted. START on the dashboard boots it.

memory, bootimage, bootdevice, bus_iopage and bus_exclusive are read when the processor is enabled. To change one, disable the processor, change it, and enable it again.

Where the devices are

Everything on this page that says the bus means the UNIBUS, the one the UniBone is plugged into. In a backplane it is the real one, with real cards on it; on a card running on its internal bus, it is the card’s own copy of those signals. Either way it is a single bus, and the emulated devices — uda, deuna, dzv11 and the rest — are cards on it. They answer the VAX at their UNIBUS addresses exactly as a real card in that slot would, and a real card on the backplane is reached the same way. There is no second, simulated bus.

The processor reaches that bus through its UNIBUS adapter, as a real 780 does through its DW780. Inside the VAX emulation there is one more MSCP controller, which never appears on the UNIBUS: a test fixture for running the processor with no devices configured, used only when bootimage names a disk image. A working machine leaves bootimage empty and does not use it.

Booting

START boots what bootdevice names. It is the argument a 780 console’s BOOT command takes, spelled the way SIMH spells it:

bootdevice	Boots
RQ0 (the default)	drive 0 of the UDA50 at 772150, the uda drive whose unit is 0
RQ1, RQ2, RQ3	drive 1, 2 or 3 of the same UDA50
RQ0 /R5:1	drive 0, with boot flags 1 in R5: a conversational boot, which stops VMS at SYSBOOT>
CS	the console floppy, the floppy image names
BOOT RAM, LOAD COPY; START 2, …	780 console commands, run against the console floppy; see Booting from the console floppy’s command files
empty	nothing. START resets the processor, which halts again at once

The boot flags are the value VMB finds in R5, in hex, as SIMH and the 780 console both take them: /R5:10 is 10 hex, 16 decimal. RQ0/R5:1 and RQ0 /R5:1 are the same command. Two values VMS defines:

R5	Effect
1	conversational boot: SYSBOOT> comes up before the system starts, for SET and SHOW on the system parameters; CONTINUE boots on
10000000	boot from root [SYS1] in place of [SYS0] — the top digit is the root number

The VMS installation guide for the version on the disk lists the rest.

The console

The console terminal on /ws/console/vax is the 780’s console terminal, as an LA36 on a real machine was. It works in the two modes the 780’s console has:

• Program I/O mode: every key goes to the program, and the terminal is VMS’s OPA0:. The machine comes out of a boot this way.
• Console I/O mode: the console takes the keyboard, prints >>> and runs the commands typed there. A halted processor puts the terminal in this mode, with HALTED AT and the program counter, and so does CTRL/P.

CTRL/P on a 780 does not stop the processor: the system goes on running, and HALT stops it. Until then the console runs only the commands it can serve without the processor — SHOW, SET, CLEAR, HELP and HALT — and refuses the others with ?CPU NOT IN CONSOLE WAIT LOOP, COMMAND ABORTED, as the real one does. SET TERMINAL PROGRAM hands the keyboard back to the running program; CONTINUE resumes a halted one and hands it back too.

PLEASE ENTER DATE AND TIME (DD-MMM-YYYY  HH:MM)        (CTRL/P typed)
>>>HALT
HALTED AT 80008B1F
>>>E PC
G 0000000F 80008B1F
>>>CONTINUE
22-OCT-2026 16:30

The commands are the 780 console’s, with its abbreviations:

Command	Does
HALT	stops the processor and prints where
CONTINUE	resumes the processor where it stopped, and gives the program the keyboard
NEXT [n]	executes n instructions, printing HALTED AT after each; without n, one, and then each space typed steps once more until another key ends it
BOOT [dev]	runs <dev>BOO.CMD off the console floppy, DEFBOO.CMD without a device; BOOT DUA0 runs DU0BOO.CMD
@file	runs a command file, .CMD by default
START addr	initializes the processor and starts it at addr
INITIALIZE, UNJAM	initializes the processor; the SBI never jams
LOAD file[/START:addr]	reads a file off the floppy into memory
EXAMINE[/q] [addr], DEPOSIT[/q] addr data	general registers (R0–R11, AP, FP, SP, PC, or /G n), PSL, the processor registers SCBB and PCBB (/I), and physical memory (/P, /B, /W, /L, /N:n)
SHOW, SHOW VERSION	the console’s state, and the microcode versions the processor reports
SET DEFAULT, SET RELOCATION:n	the radix and data length, and the relocation added to memory addresses
SET STEP INSTRUCTION, CLEAR STEP	in step mode START and CONTINUE execute one instruction and halt
SET TERMINAL PROGRAM	gives the keyboard back to the program
HELP	prints CONSOL.HLP off the floppy

An address may be *, the location last examined or deposited, + and -, the ones after and before it, and @, the value last examined or deposited; an EXAMINE without an address shows the next location. Numbers are hex unless SET DEFAULT names another radix, and %O, %X and %D name the radix of one number. ! starts a comment. BOOT, START and CONTINUE give the keyboard to the program they start.

The line is edited as on the console’s hardcopy terminal: DELETE (or backspace) removes the last character and echoes it between backslashes, CTRL/U discards the line, CTRL/C abandons it, and RETURN ends it. A command the console does not know is answered with ?'command' IS INCORRECT.

The ID bus, virtual addresses, SET STEP BUS and STATE, and the microcode debugger belong to the 780’s microsequencer, which the emulation does not have. EXAMINE/ID says so and carries on, so RESTAR.CMD runs past it.

The dashboard’s controls work beside the console. HALT stops the processor and brings the terminal to >>>; CONT resumes it and gives the program the keyboard; START boots bootdevice afresh. A CONTINUE, START or BOOT typed at the console releases the dashboard’s HALT switch. The run LED follows the processor, whichever of them stopped it.

The processor’s parameters reach a running machine without a console:

780 console	QUniLator
EXAMINE, DEPOSIT on memory	mem_examine, mem_deposit, mem_data
EXAMINE, DEPOSIT on a UNIBUS register	bus_examine, bus_deposit, bus_data

bus_examine, bus_deposit and bus_data are those two commands on the I/O page and nothing more. They play no part in booting.

Restart and reboot

A 780’s console starts the machine again when it halts on its own or when VMS asks it to, and the emulated console does the same with the command files on the console floppy in image.

A reboot request. VMS asks the console to reboot at the end of a SHUTDOWN that answered yes to an automatic reboot. The console boots the machine as BOOT alone does, with DEFBOO.CMD, and VMS comes up again. With no floppy in the drive the boot is the one START makes from bootdevice.

A halt, with AUTO RESTART on. auto_restart is the AUTO RESTART switch of the 780’s control panel. On, a processor that halts on its own — a HALT instruction in kernel mode, or an error halt — is restarted: the console runs RESTAR.CMD, which starts the restart referee in the memory controller’s ROM at 20003004. The referee decides between restarting the system in memory and booting it afresh; the emulated ROM always decides on a boot, which the console then runs with DEFBOO.CMD. With no floppy in the drive the boot is bootdevice’s. Off, the processor stays halted at >>>.

HALTED AT 00001004
>>>@RESTAR
  ...
START 20003004          ! START RESTART REFEREE
HALTED AT 20003005
>>>BOOT
  ...
START @                 ! AND START IT

   VAX/VMS Version V4.7 28-Oct-1987 13:00

The console keeps the warm and cold start flags of a 780: it sets one when it starts a restart or a boot, and VMS clears it once that has succeeded. A restart that fails goes on to a boot, and a machine whose restart and boot have both failed stays halted at >>>. A HALT from the console or the dashboard is the operator’s and is never restarted. The switch is not read at power-up: enabling the processor leaves it halted, and START boots it.

A VMS console floppy as DEC shipped it has a DEFBOO.CMD for an RM03 or RP06 on the MASSBUS. As the VMS installation guide says, a site copies the command file for its own system disk over it — for the UDA50’s drive 0, DU0BOO.CMD — and that floppy then reboots the machine from the UDA50.

The console floppy

A 780’s console carries an RX01 drive of its own, which VMS calls CSA1:. It is part of the processor, separate from any RX11 or RX211 on the UNIBUS, and image names the floppy in it: an RX01 image of 256256 bytes, in the drive’s physical sector order. The KA780 card on the dashboard shows it beside CSA1, and a click there opens the image library.

The floppy changes at any time, as on the real drive, so a multi-volume kit is fed one floppy after another while the machine runs. What the machine writes reaches the file within a few seconds, and when the floppy comes out. An RX01 has no write protection: a file protected in the image library (mode 444) goes in as any other floppy, and what the machine writes to it is dropped when it comes out.

VMS reaches the drive once it has been connected, and mounts a Files-11 floppy in it as it would any disk:

$ MCR SYSGEN
SYSGEN> CONNECT CONSOLE
SYSGEN> EXIT
$ MOUNT CSA1: label

bootdevice = CS and START boot from the floppy. VMB loads the boot file across as many volumes as the kit has, asking on the console for each one, and a standalone BACKUP kit runs this way. The boot hands VMS unit 1, the unit of CSA1:, which its console floppy driver addresses on every transfer.

Booting from the console floppy’s command files

A real 780 is booted from command files on its console floppy: BOOT RAM runs RAMBOO.CMD, BOOT alone runs DEFBOO.CMD, and the commands in the file halt and initialize the processor, load a program off the floppy, deposit its parameters in the registers and start it. Any bootdevice that names none of the processor’s own devices is such a line of console commands, separated by ;, and START runs it against the floppy in image. Every line of a command file is printed on the console terminal as it runs, as the real console printed it.

ULTRIX-32 is booted and installed this way, with its console floppy in image:

bootdevice	Runs
BOOT RAM	RAMBOO.CMD: ULTRIX’s BOOT, multi-user from the RA disk
BOOT RAS	RASBOO.CMD: the same, single-user
BOOT ANY	ANYBOO.CMD: BOOT, which asks on the console for the file to boot
LOAD COPY; START 2	the installation’s COPY, which asks for the device to copy from and the one to copy to

BOOT RAM brings ULTRIX-32 V1.1 up multi-user from an RA81 on the UDA50, to its login: prompt. With a DEUNA in the machine, set its ultrix11_broadcast to ULTRIX’s broadcast address, 10.0.0.0 for that disk: ULTRIX-32 V1.1 panics at the first other IP broadcast on the LAN otherwise, as the DEUNA page says.

A VMS console floppy boots VMS the same way: BOOT DUA0 runs DU0BOO.CMD, which starts the memory controller’s ROM program, waits for it, and loads and starts VMB from the floppy.

The commands are the console’s, abbreviations included: BOOT, @file (.CMD by default), LOAD file/START:addr, DEPOSIT and EXAMINE with /G, /I, /P, /B, /W, /L and /N:, START addr, WAIT DONE, HALT, UNJAM, INIT, SET DEFAULT and SET RELOCATION. Numbers are hex. A command that fails stops START with an error in the log naming the file, the line and the command, and the processor stays halted at >>>. The same commands, and the rest of the console’s, can be typed at the console’s prompt; see The console.

Empty, 0, and not set

A text parameter such as bootdevice or bootimage can be empty, which is a value of its own: an empty bootdevice boots nothing. A number or a switch is never empty; 0 is its value.

A parameter a configuration does not name takes its default. A saved configuration lists only what differs from the defaults, so one that names no bootdevice boots RQ0, and one that should boot nothing stores "bootdevice": "". The defaults are in the table under Parameters.

Example configurations

A configuration is a JSON file in /var/lib/qunilator/configs/ on the board, written by Save on the Configurations screen. The examples carry comments for reading; the files themselves have none. Image paths are relative to /var/lib/qunilator.

VMS from drive 0

The usual machine, and the one VMS on an emulated VAX-11/780 builds. Nothing on cpuvax is changed from its default, so it boots RQ0.

{
  "title": "VAX-11/780 with VAX/VMS V4.7",
  "devices": [
    // the UDA50 at 772150: the disk controller RQ names
    {"name": "uda", "enabled": true, "params": {}},
    // its drive with unit 0, which is RQ0 to the boot command and DUA0: to VMS
    {"name": "uda0", "enabled": true, "params": {"image": "images/vms47.dsk"}},
    // Ethernet, on the board's interface veth-pdp
    {"name": "deuna", "enabled": true, "params": {"interface": "veth-pdp"}},
    // the processor: 4 MB, and bootdevice left at its default RQ0
    {"name": "cpuvax", "enabled": true, "params": {"memory": "4"}}
  ]
}

Two disks, booting the second

The system disk on drive 1, a data disk on drive 0. VMS comes up with SYS$SYSDEVICE on DUA1:.

{
  "title": "VAX-11/780 booting DUA1",
  "devices": [
    {"name": "uda", "enabled": true, "params": {}},
    // drive 0: a data disk VMS mounts after it is up
    {"name": "uda0", "enabled": true, "params": {"image": "images/data.dsk"}},
    // drive 1: the system disk
    {"name": "uda1", "enabled": true, "params": {"image": "images/vms47.dsk"}},
    // RQ1 is the drive whose unit is 1, which uda1 has by default
    {"name": "cpuvax", "enabled": true, "params": {"memory": "4", "bootdevice": "RQ1"}}
  ]
}

A conversational boot, once

Boot flags are usually wanted for one boot, to change a system parameter, so they are set on the running machine and not saved. In the web interface:

1. On the Configurations screen, the current configuration is the running machine. Open Parameters on the KA780 processor row and set bootdevice to RQ0 /R5:1. The change reaches the machine at once, and the configuration shows MODIFIED.
2. Press START on the KA780 card of the Dashboard. START stops whatever the processor runs and boots afresh, and the console stops at SYSBOOT>.
3. Set the system parameters at SYSBOOT>; CONTINUE boots on.

The next boot is an ordinary one once bootdevice is RQ0 again: set it back the same way, or press Revert on the configuration, which puts back the saved machine and with it the default RQ0. Revert leaves the machine switched off, and AUX ON/OFF brings it up again.

The same steps can be scripted against the board’s web API, from a shell on any computer that reaches the board. Each parameter is a PUT of a JSON value, under the device name cpuvax, with the web login:

BOARD=unibone                          # the board's host name
AUTH="operator:password"               # the web interface's login

curl -s -u "$AUTH" -X PUT -H 'Content-Type: application/json' \
     -d '{"value": "RQ0 /R5:1"}' http://$BOARD/api/devices/cpuvax/params/bootdevice
curl -s -u "$AUTH" -X PUT -H 'Content-Type: application/json' \
     -d '{"value": "1"}' http://$BOARD/api/devices/cpuvax/params/start_switch

What has been verified

• VMS V4.7 boots from the emulated UDA50 to a login prompt. The project’s hardware test runs that boot on a UniBone every night and before each release.
• DEC’s processor diagnostics EVKAA, EVKAB, EVKAC and EVKAD pass on the emulation core.
• Under VMS V4.7 the console floppy is connected, initialised, mounted, written and read back: a file copied to it compares equal to its original, and the image read off the board decodes as the same Files-11 volume.
• At the console’s >>>: CTRL/P on a running VMS V4.7, HALT, EXAMINE PC and PSL, and CONTINUE, after which VMS answers its date prompt; BOOT DUA0 with a VMS console floppy boots VMS through VMB, and BOOT ANY with the ULTRIX-32 console floppy brings up ULTRIX’s BOOT.
• VMS V4.7’s SHUTDOWN with an automatic reboot comes back up through DEFBOO.CMD off the console floppy. The same reboot request, made at the console with the drive empty, boots bootdevice RQ0. With AUTO RESTART on, a HALT runs RESTAR.CMD and then DEFBOO.CMD, and VMS boots.
• A VMS V5.3 standalone BACKUP kit for the 780 boots from the console floppy: START with bootdevice = CS, then each volume (SYSTEM_1 to SYSTEM_4, then BACKUP) put in through image when the console asks for it. Standalone BACKUP comes up at its $ prompt.

Parameters

Settings

What a configuration stores and an operator sets.

Parameter	Short	Value	Default	What it is
memory	mem	number, MB	4	Main memory size in megabytes.
bootimage	bi	text	empty	Test only: disk image for the emulation’s own MSCP controller. Empty: boot from the uda.
bootdevice	bd	text	RQ0	What START boots: RQ0..RQ3, HK0..HK7 or CS, with boot flags as RQ0 /R5:1, or 780 console commands such as BOOT RAM or LOAD COPY; START 2. Empty: no boot.
image	img	image file	empty	Console floppy (CSA1:): RX01 image. Empty: no floppy.
core_debug	cdbg	text	empty	Trace a device the core carries, e.g. “RQ”. Empty: off.
core_history	chst	number	0	Instructions of history kept. 0: off.
bus_iopage	bio	0 or 1	1	1 = UNIBUS register accesses go on the bus. 0 hides every bus device.
bus_dma	bdma	0 or 1	1	1 = a device’s transfer is answered on the bus, not here.
bus_exclusive	bx	0 or 1	1	1 = the bus owns the I/O page over the core’s own devices.
bus_examine	bex	octal	0	Read this UNIBUS register into bus_data.
bus_deposit	bdep	octal	0	Write bus_data to this UNIBUS register.
bus_data	bdat	octal	0	Data of the last examine, or for the next deposit.
mem_examine	mex	hex	0	Read this physical longword into mem_data.
mem_deposit	mdep	hex	0	Write mem_data to this physical longword.
mem_data	md	hex	0	Data of the last memory examine, or for the next deposit.
batch	b	number	10000	Instructions executed per worker pass.
emulated_time	et	0 or 1	1	1 = machine time advances with executed instructions.
auto_restart	ar	0 or 1	0	AUTO RESTART switch: 1 = a halted processor is restarted from the console floppy.
console_8bit	c8	0 or 1	0	Console terminal: 1 = 8-bit characters, 0 = 7 bits, parity ignored.
iotrace_dump	iotd	0 or 1	0	1 = write the register-access trace to the log.

Status

What the device reports as it runs. A configuration does not store these.

Parameter	Short	Value	What it is
bus_cycles	bc	number	UNIBUS register accesses made
bus_timeouts	bt	number	UNIBUS accesses that were not answered
bus_interrupts	bint	number	interrupts taken from the bus
dma_words	dw	number	words a device moved through the map
dma_failures	df	number	transfers the map registers refused
dma_byte_offset	dbo	number	transfers the map registers offset by a byte
run_led	r	0 or 1	RUN LED: 1 = processor running, 0 = halted.
halt_switch	h	0 or 1	HALT switch: 1 = processor stopped, 0 = processor may run.
start_switch	s	0 or 1	START action switch: 1 = reset the machine and boot it.
continue_switch	c	0 or 1	CONT action switch: 1 = resume execution after a HALT.
PC	pc	hex	Program counter.
PSL	psl	hex	Processor status longword.
IPL	ipl	hex	Interrupt priority level.
uba_init	ui	number	UNIBUS adapter init in progress.
iopage_dispatches	iod	number	I/O page accesses the processor made
iopage_claimed	ioc	number	I/O page words the bus answers
iopage_reclaims	ior	number	boot device registers reclaimed from the core
bootdev_on_bus	bob	0 or 1	1 = the boot device’s address is answered by the bus, now.
uba_cr	ucr	hex	UNIBUS adapter control register.
intr_pending	ip	number	BR level whose vector the adapter holds.
uba_dr	udr	hex	UNIBUS adapter diagnostic control register.
nexus_req	nrq	hex	Adapter requests the processor has not taken, BR4..BR7.
intr_vector_cell	ivc	octal	Vector the adapter holds for the bus at BR5.
intr_vector_stored	ivs	octal	Vector read back at the last grant.
intr_level_stored	ils	number	Level index it was stored at.
cycle_count	cc	number	Instructions executed since the last start

It also carries the parameters under parameters every card on the bus has.

On this device, slot starts at 0; emulation_speed is read-only and starts at 1.

In detail

memory

The memory the processor has, in megabytes: 1, 2 or 4. The board shares 4 MB with the bus, and the processor’s memory has to fit in it so that a device’s transfer can reach it, so 4 is the most a board can give. The size is read when the processor is enabled; changing it means disabling the processor first.

bootimage, bootdevice

What START boots. bootdevice is the argument of a 780 console’s BOOT command, in SIMH’s spelling: a drive of the UDA50 at 772150, RQ0 to RQ3 for the uda drive whose unit is 0 to 3 — uda0 to uda3 unless a unit was changed — or a drive of the RK611 at 777440, HK0 to HK7 for the hk drive with that unit, from which VMB loads the system over the bus. Boot flags follow as /R5: and a hex value, so RQ0 /R5:1 stops VMS at SYSBOOT> for a conversational boot; with none, R5 is 0. An empty bootdevice boots nothing: START resets the processor and it halts again at once. A change takes effect at the next START, so the boot flags for one boot are set on the running machine and START pressed.

Anything else in bootdevice is a line of 780 console commands, separated by ;, which START runs against the console floppy in image as the real console would: BOOT RAM runs RAMBOO.CMD off the floppy and BOOT alone DEFBOO.CMD, BOOT DUA0 runs DU0BOO.CMD, @file runs a command file (.CMD by default), and LOAD COPY; START 2 loads a program off the floppy and starts it. The console’s own commands are understood, with their abbreviations: DEPOSIT and EXAMINE with /G, /I, /P, /B, /W, /L and /N:, register names and memory addresses; LOAD file/START:addr; START addr, which starts the processor with PSL 041F0000; WAIT DONE, which lets the program run until it halts, for at most 30 seconds; HALT, UNJAM, INIT, SET DEFAULT and SET RELOCATION. Numbers are hex, and @ stands for the value last examined or deposited. Every line of a command file is printed on the console terminal as it runs; a command that fails stops START with an error naming the file, the line and the command. The same commands, and the rest of the console’s, are typed at its >>> prompt, which CTRL/P on the console terminal brings up.

bootimage stays empty on a working machine: the disks are the uda drives, cards on the UNIBUS like any other. A file named here is instead attached to a test MSCP controller that is part of the VAX emulation itself and never appears on the UNIBUS. It answers at the same 772150, so bus_exclusive has to be 0 for it, and it boots whatever bootdevice names. It is there for testing the processor with no devices configured; enabling the processor fails when it names no disk image file or an empty one.

bootimage is read when the processor is enabled.

image

The console floppy: the RX01 drive that is part of a 780’s console, which VMS calls CSA1: once SYSGEN CONNECT CONSOLE has made it known. image names the RX01 image in it, 256256 bytes, and empty leaves the drive empty. It is the processor’s own drive, separate from the RX11 or RX211 on the UNIBUS, which VMS calls DY or DX.

bootdevice set to CS boots from it, which is how a 780 starts standalone BACKUP, and console commands in bootdevice run the command files and programs on it.

The floppy can be changed at any time, as on the real drive. What the machine writes reaches the file within a few seconds, and when the floppy is changed or the processor disabled. An RX01 has no write protection, so a protected file (mode 444) goes in as any other floppy and keeps none of what is written to it.

core_debug, core_history

Debugging aids for the emulation itself. core_debug names a device the processor carries inside it, such as RQ, and writes the core’s own trace of it to /tmp/simh-<device>.log on the board. core_history keeps that many of the last instructions executed and writes them to /tmp/vax-history.log after an interrupt arrives from the bus; it can only be changed while the processor is halted.

bus_iopage, bus_dma, bus_exclusive

How the processor’s UNIBUS adapter meets the bus. All three are on for a working machine, and are there to take the bus out of the picture when comparing against the emulation alone.

bus_iopage: the processor’s accesses to the I/O page become bus cycles and reach the devices on the bus. Off, the machine sees only the devices the processor carries inside it.

bus_dma: a device’s transfer to or from memory goes out on the bus and is translated through the adapter’s map registers there, as on a real UNIBUS, so a card that is not emulated can take part. Off, the transfer is answered inside the program.

bus_exclusive: the bus answers the whole I/O page, including the addresses of the controllers the processor carries inside it. Off, it answers only the addresses those leave free.

bus_iopage and bus_exclusive are read when the processor is enabled.

bus_examine, bus_deposit, bus_data

What a real 780’s console does with EXAMINE and DEPOSIT on a UNIBUS register, and a way to reach a device before an operating system has a driver for it. Writing an address (octal, as a UNIBUS address) to bus_examine reads that register and leaves the word in bus_data. To write one, set bus_data first, then write the address to bus_deposit. Every write makes the access, the same address again included, so a register can be read repeatedly. The access is made by the processor, so it needs the processor enabled; applying a configuration makes none.

mem_examine, mem_deposit, mem_data

The other half of what a 780’s console reaches: the processor’s own memory, by physical address, in hex. Writing an address to mem_examine leaves the longword there in mem_data; to change it, set mem_data and write the address to mem_deposit. As on the bus, every write makes the access.

bus_cycles, bus_timeouts, bus_interrupts, dma_words, dma_failures

What the UNIBUS adapter has carried since the processor was enabled: register accesses, those nothing answered, and interrupts taken from devices. bus_timeouts rising during a boot is normal: the operating system probes addresses to find out which devices are there.

dma_words counts the words devices moved through the map registers (a byte written counts as one), and dma_failures the transfers the map refused because no valid map register covers the page — on a real adapter, a device writing where the operating system has not mapped anything. All of them start again from 0 when the processor is enabled.

dma_byte_offset

A map entry with the byte offset bit set moves the transfer one byte up, so the processor’s address is odd where the device’s is even. This counts the transfers that took that path, which is the one a driver’s unaligned buffer takes.

batch

How many instructions the processor runs before it looks at the switches and the power state again. The default is long enough that the check costs nothing and short enough that a HALT takes effect at once.

emulated_time

The machine’s clock advances with the instructions it executes, at the 2 µs an instruction a real 780 takes, so the interval timer and every device delay keep pace with the processor whatever else the board is doing. VMS calibrates its timing loops once at boot; on the wall clock, a boot the board’s other work interrupts during that moment mis-times every driver wait from then on. Set to 0, the clock follows the wall, which is there to compare against real-time behaviour.

run_led, halt_switch, start_switch, continue_switch

The processor’s front panel, which the dashboard’s RUN, HALT, START and CONT controls drive. start_switch and continue_switch act once and fall back to 0. Enabling the processor builds the machine and leaves it halted; START boots it from bootdevice.

auto_restart

The AUTO RESTART switch of the 780’s control panel. Off, a processor that halts on its own - a HALT instruction in kernel mode, or an error halt - stays halted with the console at its >>> prompt. On, the console starts it again as a real 780’s does: it runs RESTAR.CMD off the console floppy, whose restart referee in the memory controller’s ROM decides between restarting the system in memory and booting it afresh, and a boot runs DEFBOO.CMD. The emulated ROM finds no system to restart, so a restart always goes on to DEFBOO.CMD.

An operating system that asks the console to reboot the machine, as VMS does at the end of a SHUTDOWN with an automatic reboot, is booted with DEFBOO.CMD whatever the switch says. With no floppy in the drive, the boot is the one START makes from bootdevice.

The console remembers that a restart or a boot is under way until the operating system reports it complete, so a machine whose restart and boot both fail stays halted at >>>. The switch is not read at power-up: enabling the processor leaves it halted, and START boots it.

console_8bit

The console terminal shows seven bits of each character, which is what ULTRIX’s console needs: multi-user ULTRIX sends it with even parity in bit 7, and a terminal of the time ignored that bit. Set it for a guest that writes eight-bit characters to the console.

PC, PSL, IPL, uba_init, iopage_dispatches, iopage_claimed

Where the processor is, read whenever it stops and as it runs: the program counter, the processor status longword and the interrupt priority level it runs at, all in hex. uba_init, iopage_dispatches and iopage_claimed describe the UNIBUS adapter: whether it is being initialised, how many I/O page accesses the processor has made, and how many words of the I/O page the bus answers (4096 is all of it).

iopage_reclaims, bootdev_on_bus

A reset of a controller the processor carries inside it takes the boot device’s registers back from the bus. They are handed back to the bus at once; this counts how often that happened, and bootdev_on_bus says whether the bus has them now.

uba_cr, intr_pending, uba_dr, nexus_req, intr_vector_cell, intr_vector_stored, intr_level_stored

The UNIBUS adapter’s registers and interrupt state, for diagnosing a machine that is not taking a device’s interrupts. intr_pending is the bus request level whose vector the adapter is still holding; non-zero for long says the processor is not taking what it was given. nexus_req shows the requests BR4 to BR7 the adapter has posted and the processor has not yet taken.

iotrace_dump

Writes the processor’s last 64 accesses to the boot device’s registers, and the interrupts between them, to the log, together with the instruction history when core_history is on. It acts once and falls back to 0.