Difference between revisions of "ITS Internals Manual"

From Computer History Wiki
Jump to: navigation, search
m (→‎External links: All done)
(The horrible hack hack.)
Line 34: Line 34:
  
 
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.
 +
 +
==The horrible hack hack==
 +
 +
ITS has a spartan "HACK HACK" comment in two places.  This is taken from the ITS 672 from 1971:
 +
 +
<pre>
 +
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
 +
</pre>
 +
 +
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 &mdash; typically, a JSR &mdash; 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 &mdash; JSR DRECYC.
  
 
==External links==
 
==External links==

Revision as of 07:36, 13 September 2023

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
    • Interrupts
    • How they get started
  • Memory management (pages)
  • File system
  • I/O
    • Terminals
      • Terminal-type independent output
    • Virtual devices
  • Daemons
  • Bootstrapping
  • Networking

Daemons

ITS 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 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).

There is also a system process called the CORE JOB, which before paging used to shuffle processes around in core, but which now ??

At least one ITS machine, DM, had a 'batch' daemon.

How system jobs get started

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.

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

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

Retrieved from "https://gunkies.org/w/index.php?title=ITS_Internals_Manual&oldid=31579"