ITS Internals Manual - Revision history

Jnc: /* Terminals and controllers */ Add MC details

2023-12-01T12:00:58Z

Terminals and controllers: Add MC details

← Older revision		Revision as of 12:00, 1 December 2023
Line 68:		Line 68:
	** GE Datanet 760 controller with four CRT consoles.		** GE Datanet 760 controller with four CRT consoles.
	** A few ARDS terminals.		** A few ARDS terminals.

	* The AI KA10:		* The AI KA10:
	** TK10 — 16 low-speed lines.		** TK10 — 16 low-speed lines.
	** Systems Concepts DK-10: 16 medium-speed lines with DMA.		** Systems Concepts DK-10: 16 medium-speed lines with DMA.
	** Datapoint 3300 CRT terminals.		** Datapoint 3300 CRT terminals.

	* The DM KA10:		* The DM KA10:
	** "Morton box" controller with 32 very high-speed lines.		** "Morton box" controller with 32 very high-speed lines.
	** Imlac PDS-1 "intelligent terminals", or actually full ~~minicomputers~~.		** [[Imlac PDS-1]] "intelligent terminals", or actually full [[minicomputer]]s.

	* The ML KA10:		* The ML KA10:
	** "Morton box".		** "Morton box".
	** One Imlac PDS-1.		** One Imlac PDS-1.

	* The MC KL10:		* The MC KL10:
	** (~~Various,~~ to do.)		** Many lines attached to two [[DH11 asynchronous serial line interface\|DH11]]'s and one [[DL11 asynchronous serial line interface\|DL11]] (main console [[DECwriter II\|LA36]]) on the main [[front end]] [[PDP-11/40]] attached to the [[DTE20 Ten-Eleven Interface\|DTE20]].
			** Many lines attached to a DH11 and one DL11 (not sure what that was connected to) on the IO/11 front end PDP-11/40 attached to the [[DL10 PDP-11 Data Link\|DL10]].
	** One Imlac PDS-4.		** One Imlac PDS-4.

	* All KS10:		* All KS10:
	** DZ11 controller.		** [[DZ11 asynchronous serial line interface\|DZ11]] controller.

	==Disk controllers==		==Disk controllers==

Larsbrinkhoff: New section for terminals and their controllers.

2023-12-01T08:21:53Z

New section for terminals and their controllers.

@@ Line 61: / Line 61: @@
 * Logo TV
 * Imlac PDS-1
 ==Disk controllers==

Jnc: /* Daemons */ typo

2023-10-17T18:56:06Z

Daemons: typo

← Older revision		Revision as of 18:56, 17 October 2023
Line 39:		Line 39:
	On ITS, a "dragon" is a permanent system job, and a "demon" is a temporary system job which is started on demand; this terminology is somewhat different (in both in the distinguishing characteristics, as well as in the actual words used) from the classic [[daemon]] terminology. ITS also has both classic daemons (which are ordinary processes, which load their code from the [[file system]], run in the same CPU mode as normal user processes - and thus have a private [[address space]]), and what we are calling 'system processes' [temporary placeholder - I need to send that email to COFF] (whose code is statically linked in with the kernel, and thus loaded into [[main memory]] at [[bootstrapping]] time, and run in 'executive' mode, and thus share the kernel's address space).		On ITS, a "dragon" is a permanent system job, and a "demon" is a temporary system job which is started on demand; this terminology is somewhat different (in both in the distinguishing characteristics, as well as in the actual words used) from the classic [[daemon]] terminology. ITS also has both classic daemons (which are ordinary processes, which load their code from the [[file system]], run in the same CPU mode as normal user processes - and thus have a private [[address space]]), and what we are calling 'system processes' [temporary placeholder - I need to send that email to COFF] (whose code is statically linked in with the kernel, and thus loaded into [[main memory]] at [[bootstrapping]] time, and run in 'executive' mode, and thus share the kernel's address space).

	On startup, ITS starts a job called SYSJOB (would this be considered a 'dragon' in ITS terminology?), which does some system tasks (complete list [https://github.com/PDP-10/its/blob/master/doc/sysdoc/usr.102#L664 here]) as a regular job; it is something of a 'system process' as its code is part of the kernel - but it appears to run in user mode (there some confusion over this; see [https://github.com/PDP-10/its/blob/master/doc/sysdoc/usr.102#L664 here]). It runs in ~~usermode~~, in part, because ITS does not allow jobs to do [[system call]]s from exec mode.		On startup, ITS starts a job called SYSJOB (would this be considered a 'dragon' in ITS terminology?), which does some system tasks (complete list [https://github.com/PDP-10/its/blob/master/doc/sysdoc/usr.102#L664 here]) as a regular job; it is something of a 'system process' as its code is part of the kernel - but it appears to run in user mode (there some confusion over this; see [https://github.com/PDP-10/its/blob/master/doc/sysdoc/usr.102#L664 here]). It runs in user mode, in part, because ITS does not allow jobs to do [[system call]]s from exec mode.

	There is also a system process called the CORE JOB, which before paging used to shuffle processes around in core, but which now allocates main memory to jobs that need it, and also takes care of user variable blocks, which have to be allocated consecutively, by shuffling those around.		There is also a system process called the CORE JOB, which before paging used to shuffle processes around in core, but which now allocates main memory to jobs that need it, and also takes care of user variable blocks, which have to be allocated consecutively, by shuffling those around.

Larsbrinkhoff: /* Jobs */ Typo.

2023-09-15T09:57:36Z

Jobs: Typo.

← Older revision		Revision as of 09:57, 15 September 2023
Line 29:		Line 29:
	ITS terminology for what is know generally known as a [[process]] is ''job''. A 'child process' is an ''inferior job'' and the parent is the ''superior''. The top-level job, HACTRN, can normally handle eight inferiors, though this isn't a hard limit.		ITS terminology for what is know generally known as a [[process]] is ''job''. A 'child process' is an ''inferior job'' and the parent is the ''superior''. The top-level job, HACTRN, can normally handle eight inferiors, though this isn't a hard limit.

	A job has a address space, consisting of 256 pages of 1024 words each. Each page may individually be mapped to some backing store, and have access read/write bits set. Backing store is normally anonymous core memory or files, but it can also be PDP-6 or PDP-11 memory.		A job has an address space, consisting of 256 pages of 1024 words each. Each page may individually be mapped to some backing store, and have access read/write bits set. Backing store is normally anonymous core memory or files, but it can also be PDP-6 or PDP-11 memory.

	Jobs can be created by the system itself, see ''How system jobs get started'', or by a user application opening a file on the USR: device which creates an inferior. The superior can read and write the inferior core image with normal .IOT read/write calls, and there is a ''LOAD'' system call to specify an on-disk file core image to load.		Jobs can be created by the system itself, see ''How system jobs get started'', or by a user application opening a file on the USR: device which creates an inferior. The superior can read and write the inferior core image with normal .IOT read/write calls, and there is a ''LOAD'' system call to specify an on-disk file core image to load.

Larsbrinkhoff: A little background info about jobs.

2023-09-15T09:57:07Z

A little background info about jobs.

← Older revision		Revision as of 09:57, 15 September 2023
Line 24:		Line 24:
	* Bootstrapping		* Bootstrapping
	* Networking		* Networking

			==Jobs==

			ITS terminology for what is know generally known as a [[process]] is ''job''. A 'child process' is an ''inferior job'' and the parent is the ''superior''. The top-level job, HACTRN, can normally handle eight inferiors, though this isn't a hard limit.

			A job has a address space, consisting of 256 pages of 1024 words each. Each page may individually be mapped to some backing store, and have access read/write bits set. Backing store is normally anonymous core memory or files, but it can also be PDP-6 or PDP-11 memory.

			Jobs can be created by the system itself, see ''How system jobs get started'', or by a user application opening a file on the USR: device which creates an inferior. The superior can read and write the inferior core image with normal .IOT read/write calls, and there is a ''LOAD'' system call to specify an on-disk file core image to load.

	==Daemons==		==Daemons==

Jnc: /* External links */ typo

2023-09-15T00:41:27Z

External links: typo

← Older revision		Revision as of 00:41, 15 September 2023
Line 107:		Line 107:
	** [https://github.com/PDP-10/its-vault/blob/master/files/sysdoc/its.histry SYSDOC; ITS HISTRY] - log of changes from ITS 946 to 1263		** [https://github.com/PDP-10/its-vault/blob/master/files/sysdoc/its.histry SYSDOC; ITS HISTRY] - log of changes from ITS 946 to 1263
	** [https://github.com/PDP-10/its/tree/master/doc/_info_/disk.info DISK INFO] - explanation of the volume hierarchy		** [https://github.com/PDP-10/its/tree/master/doc/_info_/disk.info DISK INFO] - explanation of the volume hierarchy
	** [https://github.com/PDP-10/its/blob/master/doc/info/tips.2 TIPS > - useful tips		** [https://github.com/PDP-10/its/blob/master/doc/info/tips.2 TIPS] - useful tips
	** [https://github.com/PDP-10/its-vault/blob/master/files/%25sys/1412.doc The DMS Batch System]		** [https://github.com/PDP-10/its-vault/blob/master/files/%25sys/1412.doc The DMS Batch System]
	* [https://dspace.mit.edu/handle/1721.1/6194 ITS Status Report] - these cover very old versions of the system		* [https://dspace.mit.edu/handle/1721.1/6194 ITS Status Report] - these cover very old versions of the system

Jnc: /* External links */ +useful tips

2023-09-15T00:40:48Z

External links: +useful tips

← Older revision		Revision as of 00:40, 15 September 2023
Line 107:		Line 107:
	** [https://github.com/PDP-10/its-vault/blob/master/files/sysdoc/its.histry SYSDOC; ITS HISTRY] - log of changes from ITS 946 to 1263		** [https://github.com/PDP-10/its-vault/blob/master/files/sysdoc/its.histry SYSDOC; ITS HISTRY] - log of changes from ITS 946 to 1263
	** [https://github.com/PDP-10/its/tree/master/doc/_info_/disk.info DISK INFO] - explanation of the volume hierarchy		** [https://github.com/PDP-10/its/tree/master/doc/_info_/disk.info DISK INFO] - explanation of the volume hierarchy
			** [https://github.com/PDP-10/its/blob/master/doc/info/tips.2 TIPS > - useful tips
	** [https://github.com/PDP-10/its-vault/blob/master/files/%25sys/1412.doc The DMS Batch System]		** [https://github.com/PDP-10/its-vault/blob/master/files/%25sys/1412.doc The DMS Batch System]
	* [https://dspace.mit.edu/handle/1721.1/6194 ITS Status Report] - these cover very old versions of the system		* [https://dspace.mit.edu/handle/1721.1/6194 ITS Status Report] - these cover very old versions of the system

Larsbrinkhoff at 08:28, 14 September 2023

2023-09-14T08:28:20Z

← Older revision		Revision as of 08:28, 14 September 2023
Line 37:		Line 37:
	Other daemons include COMSAT (the mailer daemon); NAMDRG, which maintains the list of logged in users which appears on all free Knight TV consoles, and PFTHMG DRAGON, which maintains usage (time logged on, and CPU use) statistics. At least one ITS machine, DM, had a 'batch' daemon.		Other daemons include COMSAT (the mailer daemon); NAMDRG, which maintains the list of logged in users which appears on all free Knight TV consoles, and PFTHMG DRAGON, which maintains usage (time logged on, and CPU use) statistics. At least one ITS machine, DM, had a 'batch' daemon.

	===Graphical displays===		===How system jobs get started===

			One of the things the SYS JOB does when it starts is to run SYS; ATSIGN DRAGON which is a central daemon. This dragon is also called TARAKA and lives in the CHANNA directory (names taken from the book "Lord of Light"). TARAKA is responsible for starting other dragons in there, which start with the file name RAKASH. One of those is RAKASH CNAVRL which launches COMSAT .

			When ITS wants to start a system job (does that term mean a 'system process', or is it a daemon?), it calls NUJBST with the SIXBIT job name in T. The core image in SYS: ATSIGN ''T'' will be started. This is used to start (all?) HACTRN; the Arpanet NETRFC handler; the TCP handler; the CHAOS agent; and demons.

			T is stored in a ring buffer, and is read out on a "slow clock" tick by USTART. A new job is created, and its user PC is set to 1. The job accumulators are loaded with code from NUSTCD, which opens the file, calls LOAD, and jumps to the starting address. In ancient times, the NUSTCD code would first try the file on the SYS: device, and then fall back to the UT2: device; this is a remnant from when ITS ran off DECtape with the system tape mounted on unit 2.

			==Graphical displays==

	* Type 340 point-plotting display		* Type 340 point-plotting display
Line 46:		Line 54:
	* Imlac PDS-1		* Imlac PDS-1

	===Disk controllers===		==Disk controllers==

	* Analex		* Analex
Line 56:		Line 64:
	* RH10		* RH10
	* RH11		* RH11

	~~===How system jobs get started===~~

	One of the things the SYS JOB does when it starts is to run SYS; ATSIGN DRAGON which is a central daemon. This dragon is also called TARAKA and lives in the CHANNA directory (names taken from the book "Lord of Light"). TARAKA is responsible for starting other dragons in there, which start with the file name RAKASH. One of those is RAKASH CNAVRL which launches COMSAT .

	When ITS wants to start a system job (does that term mean a 'system process', or is it a daemon?), it calls NUJBST with the SIXBIT job name in T. The core image in SYS: ATSIGN ''T'' will be started. This is used to start (all?) HACTRN; the Arpanet NETRFC handler; the TCP handler; the CHAOS agent; and demons.

	T is stored in a ring buffer, and is read out on a "slow clock" tick by USTART. A new job is created, and its user PC is set to 1. The job accumulators are loaded with code from NUSTCD, which opens the file, calls LOAD, and jumps to the starting address. In ancient times, the NUSTCD code would first try the file on the SYS: device, and then fall back to the UT2: device; this is a remnant from when ITS ran off DECtape with the system tape mounted on unit 2.

	==The horrible hack hack==		==The horrible hack hack==

Larsbrinkhoff: Flesh out some I/O devices.

2023-09-14T08:25:51Z

Flesh out some I/O devices.

@@ Line 17: / Line 17: @@
 ** Terminals
 *** Terminal-type independent output
 ** Virtual devices
 * Daemons
 * Bootstrapping
@@ Line 33: / Line 36: @@
 Other daemons include COMSAT (the mailer daemon); NAMDRG, which maintains the list of logged in users which appears on all free Knight TV consoles, and PFTHMG DRAGON, which maintains usage (time logged on, and CPU use) statistics. At least one ITS machine, DM, had a 'batch' daemon.
 ===How system jobs get started===

Jnc: Add stuff from Talk:Daemon

2023-09-13T15:12:50Z

Add stuff from Talk:Daemon

← Older revision		Revision as of 15:12, 13 September 2023
Line 6:		Line 6:

	* Jobs		* Jobs
	** User variables		** User variables/user blocks
	** Interrupts		** Interrupts
	** How they get started		** How they get started
	* Memory management ~~(pages)~~		* Memory management
			** Exec address space
			** Paging
	* File system		* File system
			** Directories; TUTs
	* I/O		* I/O
	** Terminals		** Terminals
Line 21:		Line 24:
	==Daemons==		==Daemons==

	~~ITS has both classic~~ [[~~daemon]]s (which are ordinary processes, which load their code from the [[file system]], run in the same CPU mode as normal user processes - and thus have a private [[address space]])~~, ~~and what we are calling '~~system ~~processes [temporary placeholder - I need to send that email to COFF~~] ~~(whose code is statically linked in with the kernel, and thus loaded into [[main memory~~]~~] at [[bootstrapping]] time, and run in 'executive' mode, and thus share the kernel's address space).~~		[[Image:KnightTV.png\|thumb\|right\|400px\|PEEK output, showing 4 system jobs]]

	~~On startup, ITS starts a job called SYSJOB which does some system tasks as a regular job. One of the things it does when it starts, is to run SYS; ATSIGN DRAGON which is a central daemon. (~~On ITS, a "dragon" is a permanent system job, and a "demon" is a temporary system job which is started on demand~~.) This dragon~~ is ~~also called TARAKA and lives~~ in the ~~CHANNA directory~~ (~~names taken~~ from the ~~book Lord of Light.~~) ~~TARAKA~~ is ~~responsible for starting other dragons~~ in ~~there, which start~~ with the ~~file name RAKASH. One of those is RAKASH CNAVRL which launches COMSAT (~~the ~~mailer daemon~~).		On ITS, a "dragon" is a permanent system job, and a "demon" is a temporary system job which is started on demand; this terminology is somewhat different (in both in the distinguishing characteristics, as well as in the actual words used) from the classic [[daemon]] terminology. ITS also has both classic daemons (which are ordinary processes, which load their code from the [[file system]], run in the same CPU mode as normal user processes - and thus have a private [[address space]]), and what we are calling 'system processes' [temporary placeholder - I need to send that email to COFF] (whose code is statically linked in with the kernel, and thus loaded into [[main memory]] at [[bootstrapping]] time, and run in 'executive' mode, and thus share the kernel's address space).

	~~There~~ is ~~also~~ a system process ~~called~~ the ~~CORE JOB~~, ~~which before paging used to shuffle processes around~~ in ~~core~~, ~~but which now ??~~		On startup, ITS starts a job called SYSJOB (would this be considered a 'dragon' in ITS terminology?), which does some system tasks (complete list [https://github.com/PDP-10/its/blob/master/doc/sysdoc/usr.102#L664 here]) as a regular job; it is something of a 'system process' as its code is part of the kernel - but it appears to run in user mode (there some confusion over this; see [https://github.com/PDP-10/its/blob/master/doc/sysdoc/usr.102#L664 here]). It runs in usermode, in part, because ITS does not allow jobs to do [[system call]]s from exec mode.

	~~At least one ITS machine~~, DM, ~~had a 'batch' daemon~~.		There is also a system process called the CORE JOB, which before paging used to shuffle processes around in core, but which now allocates main memory to jobs that need it, and also takes care of user variable blocks, which have to be allocated consecutively, by shuffling those around.

	~~==How system jobs get started==~~		Other daemons include COMSAT (the mailer daemon); NAMDRG, which maintains the list of logged in users which appears on all free Knight TV consoles, and PFTHMG DRAGON, which maintains usage (time logged on, and CPU use) statistics. At least one ITS machine, DM, had a 'batch' daemon.

	When ITS wants to start a system job, it calls NUJBST with the SIXBIT job name in T. The core image in SYS: ATSIGN ''T'' will be started. This is used to start HACTRN, the Arpanet NETRFC handler, the TCP handler, the CHAOS agent, and demons.		===How system jobs get started===

			One of the things the SYS JOB does when it starts is to run SYS; ATSIGN DRAGON which is a central daemon. This dragon is also called TARAKA and lives in the CHANNA directory (names taken from the book "Lord of Light"). TARAKA is responsible for starting other dragons in there, which start with the file name RAKASH. One of those is RAKASH CNAVRL which launches COMSAT .

			When ITS wants to start a system job (does that term mean a 'system process', or is it a daemon?), it calls NUJBST with the SIXBIT job name in T. The core image in SYS: ATSIGN ''T'' will be started. This is used to start (all?) HACTRN; the Arpanet NETRFC handler; the TCP handler; the CHAOS agent; and demons.

	T is stored in a ring buffer, and is read out on a "slow clock" tick by USTART. A new job is created, and its user PC is set to 1. The job accumulators are loaded with code from NUSTCD, which opens the file, calls LOAD, and jumps to the starting address. In ancient times, the NUSTCD code would first try the file on the SYS: device, and then fall back to the UT2: device; this is a remnant from when ITS ran off DECtape with the system tape mounted on unit 2.		T is stored in a ring buffer, and is read out on a "slow clock" tick by USTART. A new job is created, and its user PC is set to 1. The job accumulators are loaded with code from NUSTCD, which opens the file, calls LOAD, and jumps to the starting address. In ancient times, the NUSTCD code would first try the file on the SYS: device, and then fall back to the UT2: device; this is a remnant from when ITS ran off DECtape with the system tape mounted on unit 2.