Computers before operating systems

[Avichal]

I was wondering how people ran computers before operating system.
Since there is no OS to load our program, run it and then show the result, was it all done manually?

What was the procedure to load your program into the memory? I have heard something called dumb terminals. Was that used?
When the result came, how did we see it?

 

[turbo]

When I was in college over 40 years ago, computers were big, dumb, monoliths - overseen by a priesthood of geeks. Users were not allowed to make any changes in OS. We were allowed only to make minor programming changes on IBM punch-cards, then present those stacks of cards and hope that they yielded some legible output on the oh-so-many pages of green and white printout paper. It was not a good time.

Learning CUPL and Fortran was not real fun IMO because you never got to get down into the bowels of the beast. I'm sure some older members could elucidate. This is only my limited experience at a state university.

 

[rcgldr]

The Eniac was manually programmed by manipulating switches and cables. Later versions of vacuum tube computers used something similar in concept to ROM's. Wiki article:

http://en.wikipedia.org/wiki/ENIAC

Some types of computers used plug board programming. When these computers started to phase out, languages like RPG which is similar in concept to plug board programing was developed for the later computers. Wiki article:

http://en.wikipedia.org/wiki/Plugboard

Some early transistor based computers had front panels that allowed a person to manually enter machine code. Usually a simpler loader was programmed, and then that loader could read punched cards, paper tape, or from some other device in order to load in a program. One alternative to a fixed circuit or rom for a boot loader was a small music box like drum with tabs used to toggle switches as it turned to enter the loader program (MonRobot).

Eventually simple operating systems that mostly consisted of drivers for the computer peripherals were created. Most of these were disk based as with current systems, a few were tape based. These were similar to the "DOS" on mini-computers or MS-DOS for the PC. The file systems used on disk drives improved over time.

During the 1960's and 1970's mainfame operating systems became fairly robust, and included the ability to run multiple batch jobs at the same time, similar to multi-tasking, except that the batch jobs normally didn't communicate with each other. True multi-tasking systems were also created during this time period.

 

[Avichal]

Okay, you enter machine or perhaps assembly code directly to a computer. But how?
When you enter the code how do you tell the computer to run it?

 

[jtbell]

Okay, you enter machine or perhaps assembly code directly to a computer. But how?
When you enter the code how do you tell the computer to run it?

When I was an undergraduate about forty years ago, I played with a Digital Equipment PDP-5 computer which could be programmed from the front panel. It went something like this:

• You have a list of binary machine-language instructions on a sheet of paper.
• Set the memory address (in binary) that the first instruction is to go in, using a row of 12 front-panel switches.
• Press a button labeled ADDRESS. A row of 12 lights, also labeled ADDRESS, lights up accordingly.
• Set the first instruction on the switches.
• Press a button labeled DEPOSIT. A second row of 12 lights labeled DATA lights up accordingly.
• Press a button labeled NEXT. The ADDRESS lights advance to the next binary number in sequence.
• Set the second instruction on the switches.
• Press the DEPOSIT button.
• Press the NEXT button.
• Set the next instruction on the switches.
• Repeat the preceding three steps until you've entered all the instructions.

When you've entered the entire program,

• Set the switches to the address of the first instruction.
• Press the ADDRESS button.
• Press the RUN button.

I can't find a clear enough picture of a PDP-5's front panel to refresh my 40-year-old memories, so some details may have been different.

 

[nsaspook]

Okay, you enter machine or perhaps assembly code directly to a computer. But how?
When you enter the code how do you tell the computer to run it?

Some early machines had a front panel that would control the processor, and allow you to manually control the memory data, address data ,run/halt and read/write logic lines with a set of toggle switches.
http://www.classiccmp.org/hp/UYK-20/uyk%20panel.jpg
Core memory board.
http://www.classiccmp.org/hp/UYK-20/core.jpg

Manual operation:
You would unset the run switch, set address mode, toggle a address in binary, hit the set switch, set data mode, toggle in the data bits at that address, hit the set button again then repeat for the length of the program. When you were done you would again set the address to the start address of the program, press the set switch and then flip the run switch to start the computer executing instructions at that address.

The easy way:
Set the mode switch to use the ROM based bootloader to load the program from a 8 level tape reader.
http://www.kh6bb.org/new1.jpg

 

[jtbell]

"My" PDP-5 didn't have a ROM bootloader, so I had to enter a short paper-tape-loader program on the front panel switches. Properly-designed programs didn't overwrite the memory area where the paper tape loader resided, so if I was lucky, I needed to enter it only once, right after I turned the machine on. We kept the list of instructions taped on the front panel for handy reference.

 

[OmCheeto]

When I was an undergraduate about forty years ago, I played with a Digital Equipment PDP-5 computer which could be programmed from the front panel. It went something like this:

• You have a list of binary machine-language instructions on a sheet of paper.
• Set the memory address (in binary) that the first instruction is to go in, using a row of 12 front-panel switches.
• Press a button labeled ADDRESS. A row of 12 lights, also labeled ADDRESS, lights up accordingly.
• Set the first instruction on the switches.
• Press a button labeled DEPOSIT. A second row of 12 lights labeled DATA lights up accordingly.
• Press a button labeled NEXT. The ADDRESS lights advance to the next binary number in sequence.
• Set the second instruction on the switches.
• Press the DEPOSIT button.
• Press the NEXT button.
• Set the next instruction on the switches.
• Repeat the preceding three steps until you've entered all the instructions.

When you've entered the entire program,

• Set the switches to the address of the first instruction.
• Press the ADDRESS button.
• Press the RUN button.

I can't find a clear enough picture of a PDP-5's front panel to refresh my 40-year-old memories, so some details may have been different.

That sounds a bit like the Altair 8800.

I never got one, but your description sounds about right.

Ha! The first line of the article is a hoot:

The era of the computer in every home --- a favorite topic among science-fiction writers --- has arrived!

 

[SteamKing]

When I was an undergraduate about forty years ago, I played with a Digital Equipment PDP-5 computer which could be programmed from the front panel. It went something like this:

• You have a list of binary machine-language instructions on a sheet of paper.
• Set the memory address (in binary) that the first instruction is to go in, using a row of 12 front-panel switches.
• Press a button labeled ADDRESS. A row of 12 lights, also labeled ADDRESS, lights up accordingly.
• Set the first instruction on the switches.
• Press a button labeled DEPOSIT. A second row of 12 lights labeled DATA lights up accordingly.
• Press a button labeled NEXT. The ADDRESS lights advance to the next binary number in sequence.
• Set the second instruction on the switches.
• Press the DEPOSIT button.
• Press the NEXT button.
• Set the next instruction on the switches.
• Repeat the preceding three steps until you've entered all the instructions.

When you've entered the entire program,

• Set the switches to the address of the first instruction.
• Press the ADDRESS button.
• Press the RUN button.

I can't find a clear enough picture of a PDP-5's front panel to refresh my 40-year-old memories, so some details may have been different.

Here is a brochure explaining some of the features of the PDP-5:

http://archive.computerhistory.org/resources/text/DEC/pdp-5/DEC.PDP-5.1964.102646094.pdf

If you go to p.8 of the document, there is a picture and explanation of the console keys.

 

[jtbell]

Looks like I wasn't too far off. Instead of buttons, there were two-way spring switches (console keys) that each acted like two buttons. Instead of a single DEPOSIT, there were separate LOAD ADDRESS and DEPOSIT [data]. Instead of RUN, there was START. To see the data at a particular address (already entered), you had to use EXAMINE. And there was no NEXT; both DEPOSIT and EXAMINE automatically incremented the memory location. So the procedure for entering and running a program would have been:

• Set the switches to the address of the first instruction.
• Key LOAD ADDRESS.
• Set the switches to the first instruction.
• Key DEPOSIT.
• Set the switches to the next instruction.
• Repeat the preceding two steps until the entire program has been loaded.
• Set the switches to the address of the first instruction.
• Key START.

 

[D H]

• ...
• Key START.

You missed a final step: Watch das blinkenlights.

 

[jtbell]

Yep, and another step, not mandatory, but good practice: use LOAD ADDRESS (once) and EXAMINE (multiple times) to check that you entered the program correctly!

 

[Avichal]

That's tiresome but very exciting. You get to interact with the hardware directly unlike nowadays.
Thank you for the information

Also, what are dumb terminals?

 

[D H]

Essentially a teletype in which the output went to a monochrome screen instead of paper.

 

[Avichal]

What's the difference between the current computer terminal and the dumb terminal?
Did the dumb terminal just take input and store into the memory without processing it? So in a way, it was just another way to load a program into the computer. Was it used before operating systems came?

 

[harborsparrow]

What's the difference between the current computer terminal and the dumb terminal?
Did the dumb terminal just take input and store into the memory without processing it? So in a way, it was just another way to load a program into the computer. Was it used before operating systems came?

This is an excerpt from Wikipedia that is fairly accurate:

In the context of traditional computer terminals that communicate over a serial RS-232 connection, dumb terminals are those that can interpret a limited number of control codes (CR, LF, etc.) but do not have the ability to process special escape sequences that perform functions such as clearing a line, clearing the screen, or controlling cursor position...Smart or intelligent terminals are those that also have the ability to process escape sequences, in particular the VT52, VT100 or ANSI escape sequences.

In the broader context...the term dumb terminal is sometimes used to refer to any type of traditional computer terminal that communicates serially over a RS-232 connection.

 

[harborsparrow]

I first used an IBM 360 system that used punched cards. In that case, each card was one line of code (in text), and the program would be read in line by line (card by card) and compiled, then run.

The operating system was very primitive. People at various terminals could read in a program from cards, and those would all go into a holding area (queue) and then execute one at a time. There was an operator (an actual person) who looked at the queue and could kill a job (if, say, it ran too long) or move a job to the front of the queue. Each program had one or two cards at the front that consisted of instructions to the computer on how to load and run the program (which compiler to use, for example, since compilers were pre-loaded and waiting in memory somewhere, ready to run the program being read in, or else the operator had to load the compiler)--those instructions were in JCL (Job Control Language), and each program was a "job". JCL is still used some places. This was before any timesharing systems, but JCL and the queue and operator WERE the operating system. Before that, as with Eniac, there was nothing; the program had to be hardwired into the computer.

Sorry this is a little muddled. You probably don't want to know about punched card computing anyway :-) This is a batch operating system, as mentioned earlier in the thread.

 

[harborsparrow]

And, before punched cards, there was paper tape. The Univ. of Tenn. still had, in 1971 or 72, a paper tape reader than worked, although no one actively used it anymore.

When timesharing came along, we all thought we had gone to heaven.

 

[lpetrich]

As harborsparrow mentioned, a smart terminal is one that interprets certain character combinations as commands to move the cursor, clear a line, clear the screen, format the text, etc. -- those

One can create ASCII-art GUI's using these escape sequences, like for text editors and games.

Smart terminals are still common, though in virtual form. I mainly have experience with SunOS and OSX, but their terminal apps create smart virtual terminals.


As to present-day OS-less computers, I'd imagine that some small embedded ones are OS-less, but that's about it.

 

[harborsparrow]

To get down to brass tacks, "smart terminals" were really computers themselves. They contained a microprocessor--a big deal in the 1980's--that would allow, via the entry of control codes from a keyboard, a certain amount of local editing of commands before sending entered commands (usually serially) off to a remote processor for execution on "a mainframe" or "a real computer".

I'm talking about, say, the 1980's here.

ANSI VT100 is a standard dictating one way in which a smart terminal could operate so as to be compatible with other smart terminals. With such standards, your smart terminal could break and you could replace it with another made by a different vendor as long as both correctly implemented the VT100 standard--the the remote computer being interfaced to should not need to know the difference.

If you run a Command Window today on a Microsoft Windows Operating system, you get a virtual environment that is quite similar to what a smart terminal was. If you type incorrectly, you could hit the backspace key (and the previously typed character would disappear from the screen, because the keyboard had created a Backspace control code whenever you pressed, say, the Delete key). The backspace action all took place within the "terminal" by means of a local microprocessor. Only when a command had been entered correctly, and you then hit Enter, would the command be "interpreted" by the operating system (which in those days meant, sent serially to a central processing unit on a mainframe computer, rather than being handled by the local microprocessor in the terminal itself).

 

[AlephZero]

As to present-day OS-less computers, I'd imagine that some small embedded ones are OS-less, but that's about it.

I don't think that is very likely. But the term "OS" has changed its meaning a lot over time. In a sense, 99% (or more) of what is in Windows or OSX isn't the "operating system" at all, it's just collection of applications and "cool stuff" that those nice people at Microsoft and Apple think you might find useful.

You can make a basic multi-tasking OS that will handle threads and processes, read and write a file system of disk, and interact with a keyboard and a network communications link in a very small amount of code - less than a megabyte. IMO it would be a dumb idea to try to build any 21st century computer system without starting from something like that as a solid foundation.

 

[nsaspook]

Sometime a (RT)OS just gets in the way in embedded applications. Most real-time machine interaction level applications require very deterministic behaviours that can be difficult to achieve with a preemptive multi-tasking OS.

http://www.barrgroup.com/Embedded-Systems/How-To/Preemption-Perils

 

[.Scott]

Early computers had "programmer panels" which allowed the operator to force data into memory and then cause those instructions to be executed. Those boot instructions were not entered in assembler, they were entered in machine language. Here are some examples:

Honeywell Series 200:
Push buttons would allow you to force one byte of memory at a time or to set a register. For example, setting memory location 0 to octal 15, then 1 to 0, then setting the a register A to 1, B to 2, and the Program Counter to 0, then hitting run would cause the instruction at 0 (15) to be executed. That instruction was a Move to A field word mark. But since B was one more than A, any word mark would be cleared in advance so all of memory would be cleared to the value in 1 (a zero).
You could also enter an IO device code and read. This would read one record from the device - for example, all the codes from one card in the card reader or the first record recorded on a tape. If that information was executable, you could then hit run and the program would run. Normally, that program woould immediately set up to read more of the program in from subsequent cards or tape record.

IBM 1620 - used in the Mercury space flight missions.
A typewriter-style keyboard would allow entry of data directly into memory. For example, something liek this was used to seek to cylinder zero on the disk drive, read in the first sector, and just to location 100 where that record had just been read: 34000320070636003200708490010000000000100

Honeywell 2000 series: Also used a typewriter-style device.

Early DECs: Mostly toggle switched that would allow words to be entered into sequential memory locations.

Data General NOVA: Similar to early DECs. The work length was 16-bits and a 16-word command string was needed to read in a paper tape program.

 

[yungman]

When I started working in 78, I don't believe there is operating system to talk about, not even DOS. I remember different computer have their own way of booting up. I got a Radio Shack TRS80, I wrote basic programs in it. At work they used a system called CPM for a while. It was more primitive than DOS.

In a lot of sense, the primitive system is not necessary bad. We wrote assembly language programming and it ran fast and use very little memory. I am not trying to compare the complexity of today's software with those old stuffs, but the efficiency of the old programs seems to be lost as programming now uses so many modules calling here and everywhere that slows the program down.

the worst today is, people can't read and write in Hex! They have to use decimals. decimals has not bearing on the machine which uses binary. We were trained to think in Hex and it is so much more efficient once you pay the overhead of learning it.

 

[Mark44]

When I started working in 78, I don't believe there is operating system to talk about, not even DOS.

At that time, most computers had an operating system, but this was just before personal computers really took off. My first experience with computers was in 1972, when I took a computer science class that used PL/C, a compact version of a language called PL/I (sold by, I believe, IBM).
We used keypunch machines to type each line of our programs, with one Hollerith (AKA IBM) card per line. We also had to type a few job control language (JCL) cards to go in front of and behind the cards in our PL/C deck.

Once the program was keypunched, we submitted it, and one of the computer guys would run a bunch of card sets through a card reader, which transcribed the code onto a tape reel. When enough programs were on the reel, somebody would "mount" the reel on the computer (some IBM model that I never saw), and run the programs.

There has to be an operating system that is able to load programs into memory and start running them.

I remember different computer have their own way of booting up. I got a Radio Shack TRS80, I wrote basic programs in it. At work they used a system called CPM for a while. It was more primitive than DOS.

In a lot of sense, the primitive system is not necessary bad. We wrote assembly language programming and it ran fast and use very little memory. I am not trying to compare the complexity of today's software with those old stuffs, but the efficiency of the old programs seems to be lost as programming now uses so many modules calling here and everywhere that slows the program down.

the worst today is, people can't read and write in Hex! They have to use decimals. decimals has not bearing on the machine which uses binary. We were trained to think in Hex and it is so much more efficient once you pay the overhead of learning it.

 

[yungman]

At that time, most computers had an operating system, but this was just before personal computers really took off. My first experience with computers was in 1972, when I took a computer science class that used PL/C, a compact version of a language called PL/I (sold by, I believe, IBM).
We used keypunch machines to type each line of our programs, with one Hollerith (AKA IBM) card per line. We also had to type a few job control language (JCL) cards to go in front of and behind the cards in our PL/C deck.

Once the program was keypunched, we submitted it, and one of the computer guys would run a bunch of card sets through a card reader, which transcribed the code onto a tape reel. When enough programs were on the reel, somebody would "mount" the reel on the computer (some IBM model that I never saw), and run the programs.

There has to be an operating system that is able to load programs into memory and start running them.

I don't remember that clearly anymore, I think the TRS80 take basic directly. You type the basic and type run and it will.

In the CPM, you type in assembly language. If you type "Debug" and hit enter, it goes into debug mode and you type machine language code and run. It's been too long, I since totally left the field of programming. I avoid computer for years, totally skip the DOS. The first computer OS I learned since was Windows 95. So there is a big gap in my knowledge.

I remember the days of key cards. The TRS 80 was not much more than that, you just type on the screen with keyboard instead of the punching machine. It was quite natural to transition from key punch to those computers. The cpu was Z80 those days.

 

[Chronos]

I used to stand in line at the computer lab at night to run my shoe box of punch cards on the IBM 360 at school. Get one lousy card out of sequence and ... God, I miss Fortran. Years later, I typed pages of hex to program my Apple IIe in what was then called 'machine language'. Mistype one lousy hex code out of 80 pages and ... you quickly learn the fine art of partial compilation.

 

[SteamKing]

There were a whole slew of OSes in the 1970s, just not very many were PC oriented because the system resources were so meagre for these machines.

The large mainframe computers like IBM and Control Data had OSes which were time-share oriented. You would log onto the machine thru a terminal and usually submit your data to be run using a deck of cards or, if you were lucky, by submitting the card images stored in a data file. You got your results back either in another data file or by printer. If you had a really swish system, you might even get some plots.

The mini-computer makers, like DEC, had OSes similar to the mainframe makers, oriented for time-sharing. DEC had RSX-11 for their PDP-11 minis and when the VAX 780 machines came along, they developed VMS. All of these various OSes were proprietary.

For Intel 8080/Zilog Z80 machines, Digital Research's CP/M was the king-of-the-hill. There were compilers available for several different programming languages besides BASIC. Apple had Apple DOS, but this OS was no great shakes in the feature department.

When IBM was developing the PC, as the story is told, they came knocking on the door at Microsoft and at Digital Research, looking for an OS. CP/M was basically ready to go for the PC, since the 8086 processor could execute 8080 code. Microsoft had nothing on the shelf, just a few language products. It's still not clear why Digital Research could not strike a deal with IBM, but the cannier Bill Gates knew that a small company in Seattle had an operating system which worked on an 8086 processor. Gates was able to convince the IBM reps that he had an OS suitable for the new PC and was able to strike a deal. After the IBMers went back to NY, Gates quickly bought the source code and the rights to what became DOS for $50,000 from the cross-town computer shop, who were none the wiser as to Gates' ultimate purpose.

 

[lpetrich]

Bill Gates's father was a corporate lawyer, so I think that his father helped him outwit IBM there. IBM got the rights to "PC-DOS", but he kept the rights to "MS-DOS". When the cloners got into business, Bill Gates knew what to sell them: MS-DOS.


As to OSes, there used to be lots of different proprietary ones without much compatibility between them. This changed with the rise of Unix in the 1980's, and most of the mainframe and minicomputer ones fell to the wayside. However, Unix vendors got into a big fight over standards in the late 1980's and early 1990's, and the "Unix wars" caused a lot of the trouble for the commercial Unix flavors. That made it easier for Microsoft to push Windows NT, and that enabled the rise of open-source Unix flavors like Linux. The biggest desktop Unix flavor is now not Linux but MacOS X, which is essentially an updated version of NextStep, Steve Jobs's would-be next big thing in the late 1980's. But Linux is now the biggest server OS, and Linux and OSX version iOS are now the biggest smartphone and tablet OSes.

 

[jtbell]

When I started working in 78, I don't believe there is operating system to talk about, not even DOS.

When I started graduate school in physics in 1975, my department used a DEC PDP-10 computer with the TOPS-10 operating system. In 1978 we migrated to a DEC VAX 11/780 which used the VAX/VMS operating system.