My First Mulitasking Operating Systyem

I have mentioned learning to program on an IBM 1401.  This computer processed class scheduling, attendance records, and grades for the entire Santa Monica Unified School District.  I used my knowledge and access to get myself moved from one section of German to the other because the girl that I was obsessed with was going to be in that section.  Another one of the computer lab rats, Curt, claimed no knowledge of how he had dozens of absences from P.E. and still received an A.

Anyway, the data processing coordinator for the district somehow rescued a computer pound puppy.  It was an odd dual minicomputer system named MINITS (for Miniature Time Sharing System).  It used two Interdata minicomputers, a Model 3 and Model 4, sharing a common 32K RAM space.. A model 4:

The dials on the left and the push buttons at bottom allowed you to enter data into various memory locations, such as when you needed to put the boot code in to load the OS from the drum.  This was a slow process.  One friend, Curt, demonstrated his ability to enter the boot sequence accurately with his toes.

  I do not know if the Model 15 was an Interdata supported product, or something Cerf's team created. The Model 3 was for control of the teletype terminals and modems.

That's a model 33 teletype.  It printed and accepted keyboard input at 10 characters per second (we finally managed to find a 30 character per seconds modem and CRT to attach).  Yes that is a  paper tape punch and reader, which used this stuff:

There are indeed more than 8 rows.  One is a parity bit, and the other is some other out of band signaling information that I have forgotten.  Slow!  I once did a three pass assemble* of the Interdata Model 4 OS from paper tape as my first summer job after graduating.  (That was 12 hours of profound boredom, fixing paper tape jams and tears.  Why three passes?  No hard disk to store intermediate results, like symbol tables)

Anyway back to MINITS.  This was one of Vint Cerf's brainchildren.  The idea was a relatively cheap timesharing system.  We had scads of listings for the operating system, BASIC interpreter, and some of the utilities and games, printed out on a drum printer that was attached to the Univac 1108, that was supposed to be the mainframe to which this would be attached.

The hardware was unique.    It had a large magnetic drum that did two things: every few milliseconds as the drive reached its zero track position, it generates an interrupt that told the operating system, "It is time to give another user some time."  (Clock generated interrupts?  Not sure when these appeared on other minicomputers.)  Also when it came time to swap users, the entire user context (the current contents of his BASIC program or whatever else a user was running, which I believe went from X'5800' to X'8000') would be written to the drum.  The OS would then load the next user's context and give him execution time.

How much time?  The OS had a concept of Terminal Control Block, which specified how many milliseconds he was allowed and the priority of his terminal's task.  By adjusting these numbers on the fly, you could annoy the heck out of a remote user.  (Imagine typing a key on the teletype and waiting a second or two for the echo to print on the paper.)  There was one in the math lab several thousand feet away, and another attached by 110 baud modem at Lincoln Junior High, some miles away.  We also borrowed a teletype to take home on weekends, for breaking into ARPAnet; more about that some other day.)When there were problems, either because someone was manipulating the remote user's TCB or because of hardware problems, the Lincoln math teacher responsible for this learning project, Mr. Winkenhower, would call us to find out why he was not having any luck. 

Anyway, I learned a lot about how operating systems worked in 11th and 12th grades.  The Control-V key would drop you into a debugger where you could by accident do enormous damage requiring a hard reset, including re-entering the boot sequence through the front panel.  The right set of common keystrokes would change RAM in areas that were lethal to the OS.  It was needed, however, to fix some problems on occasion so we could not just disable it.  A fellow student, Curt, and I wrote a utility in Interdata assembly language and then hand compiled it (we had no assembler program) that would do all the  necessary functions but otherwise block access to the debugger.*

I also learned how to redirect the illegal instruction interrupt, which would drop you into the debugger.  At some point I decided to be clever and build an illegal instruction driver that would recognize instructions that were part of the Interdata Model 70 instruction set (think short relative jumps) and it would simulate these perfectly.  Then I foolishly started adding these instructions into the OS.  It came to a near complete standstill as basic OS functions would keep running through the illegal instruction ISR.

*Computers execute instructions stored in RAM as binary numbers usually expressed in hexadecimal.  X'5A' was the Interdata AHM (Add Halfword to Memory) instruction.  (
I remeber because they used many of IBM 360 mnemonics and architecture; 16 general registers all of which except 0 could be index registers; and where X'5A', was a 32 bit add of memory to register on the 360, X'5A' was AHM 16-bit add of memory to register on the Interdata),   It not being very easy for most people to remember all the numbers, we generally wrote in assembler language.  AHM 5,VALUE would add the 16 bits at symbol VALUE to register 5.  The program that converted these easy to remember mnemonics into binary was called an assembler.