ITS Internals Manual

From Computer History Wiki
Revision as of 01:41, 15 September 2023 by Jnc (talk | contribs) (External links: typo)
Jump to: navigation, search

There is some documentation for Incompatible Timesharing System, but principally oriented towards the users and programmers thereof (see links below). This page attempts to provide at least the high-level portions of a manual which describes how the kernel of the system is organized.

Note: This page is under construction.

Basics

  • Jobs
    • User variables/user blocks
    • Interrupts
    • How they get started
  • Memory management
    • Exec address space
    • Paging
  • File system
    • Directories; TUTs
  • I/O
    • Terminals
      • Terminal-type independent output
    • Graphical displays
    • Virtual devices
    • Disk controllers
    • Misc and sundry custom devices
  • Daemons
  • Bootstrapping
  • Networking

Daemons

PEEK output, showing 4 system jobs

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 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 here). It runs in usermode, in part, because ITS does not allow jobs to do system calls 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.

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

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
  • Evans&Sutherland LDS-1
  • Color scope
  • Knight TV
  • Logo TV
  • Imlac PDS-1

Disk controllers

  • Analex
  • Data Disc M-6
  • Custom controller for IBM 2311 drives
  • Custom controller for IBM 2314 compatibles
  • Systems Conceps DC10
  • RP10
  • RH10
  • RH11

The horrible hack hack

ITS has a spartan "HACK HACK" comment in two places. This is taken from the ITS 672 from 1971:

TTYCHN==4       ;TTY CHANNEL
SDCHN==4        ;DISPLAY SPECIAL CHANNEL
DISCHN==6       ;DISPLAY DATA CHNL

LOC 40+2*TTYCHN
        JSR TTYBRK      ;TELETYPE, GETYPEIN AND ALL MANNER OF MISC
        JSR DRECYC      ;HACK HACK

LOC 40+2*DISCHN
        BLKO DIS,DBLKOP ;340 DISPLAY BLKO
        CONO PI,4000+200_<-SDCHN>       ;HACK HACK

The display data interrupt is handled by a BLKO instruction to feed words to the Type 340 display. The magic hack happens when the BLKO instruction overflows, which executes the next instruction. DEC documentation is restrictive about what instructions may go there — typically, a JSR — and strongly forbids any IOT instruction. But here we have a CONO instruction that triggers a display special interrupt on a lower priority channel. The processor remains in interrupt overflow mode, so it executes the second interrupt instruction — JSR DRECYC.

External links