Creating an OS: Understanding the Basics of Programming and Text Editors

In summary, the conversation discusses the early methods of programming and bootstrapping computers, including the use of front panels, paper tape, patch panels, and EEPROM programmers. The conversation also mentions the development of the Apple ][ and the use of EEPROMs in computer programming. The conversation ultimately leads to the question of how the first computers and EEPROMs were programmed, with one suggestion being to manually enter the code using switches on the computer itself.
  • #1
jd12345
256
2
I am afraid this is going to be a very stupid question but nonetheless i am asking: -

I have been programming for 6 months now and i always program on a text editor. I learned that an OS is also a program which is first loaded onto the computer. Also the text editors are also computer programs.

But I don't understand how text editors and the OS were programmed in the first place?
Where do you "type" programs when you don't have an operating system and text editor yet?
 
Technology news on Phys.org
  • #2
These days on another computer.

I am not sure how the early programs were transferred to the computer memory, I do remember reading about some kind of a switchboard (if that's the correct word to use) that was used in one of the very early computers - programming was done just by flipping the switches. But that was in the absolute beginning, I am sure there were many much more sophisticated ideas used later.
 
  • #3
Last edited:
  • #4
Devils said:
Front panels, paper tape, patch panels etc; and bootstrap from there.

But you already need some equivalent of BIOS to use these, don't you? There is already a code needed to execute the bootstrap procedure. This is the part I am missing.
 
  • #5
The 'loader' was in EEPROM (a non-volatile memory chip) which was programmed with an EEPROM programmer.

http://www.electronickits.com/kit/complete/prog/ck1707.htm
 
  • #6
Devils said:
Front panels, paper tape, patch panels etc; and bootstrap from there.
The Apple ][ was one of the first useable computers & not just a toy.
Correction: The Apple ][ was one of the first useable home computers that was not just a toy. Operating systems predate the Apple II by more than a couple of decades; usable computers by more than three decades.
 
  • #7
Devils said:
The 'loader' was in EEPROM (a non-volatile memory chip) which was programmed with an EEPROM programmer.

I know. Trick is, all EEPROM programmers I have seen require connecting to the computer for the programming to be done. The one you linked to apparently uses Centronics for that purpose. So your answer just shifts us a little bit back in time - how do we program the first EEPROM? Or how do we program the first computer that we will use to program the EEPROM?
 
  • #8
One of my mentors wrote code by punching holes in big cards and feeding the cards into the machine.
 
  • #9
Borek said:
I know. Trick is, all EEPROM programmers I have seen require connecting to the computer for the programming to be done. The one you linked to apparently uses Centronics for that purpose. So your answer just shifts us a little bit back in time - how do we program the first EEPROM? Or how do we program the first computer that we will use to program the EEPROM?

If you follow the regress eventually you will end with some guy keying in a simple program by hand.

Alan Turing programmed in machine code. Just pure numbers.
 
  • #10
D H said:
Correction: The Apple ][ was one of the first useable home computers that was not just a toy. Operating systems predate the Apple II by more than a couple of decades; usable computers by more than three decades.

Don't start lecturing me I've been programming for over 40 years. I first used the Apple ][ in 1979 and DEC & HP before that.

You can go back 2000 years to the Antikythera device or 150 years to the Analytical Engine.
http://en.wikipedia.org/wiki/Antikythera_mechanism
http://en.wikipedia.org/wiki/Babbage_engine
 
  • #11
ImaLooser said:
If you follow the regress eventually you will end with some guy keying in a simple program by hand.

Keying what into what?

I have no problems with writing assembler code on the paper, and debugging it by hand before translating it manually to bytes and POKEing these values into memory using BASIC. Been there, done that - but that already required working BASIC interpreter run from the ROM (EEPROM, EPROM, PROM, whatever). As far as I understand it so far everything that was said was about how to enter the program into already running computer that is already executing some code designed to read the input.

Was there an EEPROM in IBM 701? Quite unlikely, taking into account fact they were invented several years later.
 
  • #12
Borek said:
Keying what into what?
Keyed directly into physical memory via switches that the computer operator had to set by hand. A "digital" interface.

Boot strapping those ancient computers was a pain in the rear. The only things that were hardwired were the ability to tell the computer to start running a program beginning with physical word #0 and the ability to directly set memory via a set of toggle switches. The operator had to manually set the bits in physical word 0, then word 1, and so on until the bootstrap program was loaded into memory. When the program was finally loaded, another button made the computer start running that bootstrap program.
 
  • #13
Borek said:
Trick is, all EEPROM programmers I have seen require connecting to the computer for the programming to be done.
Before that there were write once proms and proms that could only be erased via exposure to UV light via a window that exposed the actual prom itself. There were some programmers with keyboard that let you program data manually, but most used a serial interface to transfer data to the prom burner.

The first popular usage of an actual EEPROM was the DEC VT52 ASCII monitor, which used the EEPROM instead of switches to set things like baud rate, althought the screen display for the EEPROM just displayed virtual switches, so you still needed the user manual or you had to memorize what the settings did. As prom that held the monitors actual code and data got cheaper, later versions of similar monitors would display the EEPROM settings in English (baud rate = ... xon/xoff ... ). I did one of these myself, and recall management complaing about all the space used by the setup text messages until prom sizes doubled from 2K bytes to 4K bytes and got cheaper.

Many of the older computers (1970's and older) used core memory, which retains data during power cycles, so the boot loaders in memory on these machines only had to be occasionally loaded manually, typically using toggle switches on the front panel. Mini computers like the HP 2100 required that the bootstrap loader be manually entered via toggle switches (actually buttons with the older ones using those cool capacitive buttons) if the boostrap loader got corrupted. I think the older still IBM 1130 had a hard wired boot strap loader that would read one card from the card reader to get the initial program (might have been an optional plug in card, since the IBM 1130 had plug in cards similar in concept to ISA cards used on early PCs). I don't recall if the first card would then read other cards, but the next step was to read one sector from the hard disk and boot from there, the same as a PC. Most early mainframes did have some type of hard wired boot strap loader. One interesting twist on boot loaders was used on the MonRobot, an old mini-computer with a drum memory. It turned a music box like drum where the pins on the drum toggled switches to load in the boot strap loader, which read a "block" from the paper tape reader to start up the machine.

Going back further still, the ENIAC vacuum tube computer initially had to be hard wired to "program it" Later versions had equivalent of "ROM" functionality, and the EDVAC added the ability to store both program code and data in the computers memory.

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

There was also "plugboard" programming. One interesting aspect of plugboard programming it that the order of most operations was not specified, sort of an associative language where input and output fields and the operations to be performed were defined, but not the order of those operations.

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

Skipping back to the less ancient past, the Basic interpreter for the Altair 8800 was developed using a PDP based emulator, and a binary paper tape was produced. The story goes that the bootstrap loader to load in the paper tape was developed in flight on the way to Altair.

http://en.wikipedia.org/wiki/Altair_BASIC
 
Last edited:
  • #14
D H said:
Keyed directly into physical memory via switches that the computer operator had to set by hand. A "digital" interface.

When I was an undergraduate in the early 1970s, my physics department acquired a military-surplus DEC PDP-5 computer that had been built in the early 1960s. Its normal I/O devices were a teletype/keyboard and a paper-tape reader/puncher. There was no "operating system." In order to run a program, I had to load it (in previously-compiled binary format) from paper tape. In order to load the program, I had to use switches on the computer's front panel to "toggle in" the binary machine-language instructions for a short paper-tape-reader program.
 
  • #15
Pythagorean said:
One of my mentors wrote code by punching holes in big cards and feeding the cards into the machine.
In my first programming class, back in 1972, we did this. The language we were learning was PL/C, a compact form of PL/1, a language developed by IBM in the '60s.

We wrote our program code on paper, and then typed each line of code onto an IBM (or Hollerith) card by using a key-punch machine. After we were finished with the PL/C cards for our program, we had to do a few more JCL (Job Control Language) cards that were added to the beginning and end of our card decks.

When we were finished with that, we turned the card deck in, and one of the operators would feed our card decks into a card reader, which read the holes on the cards and wrote on a reel-to-reel tape. After a number of "jobs" were written to the tape, the operator would physically take the tape and mount it on the actual computer, which would then compile and execute our programs.

The output, which you would get a day or so later, consisted of a printed listing of the program, status messages from the compiler, and any output that the program produced, assuming that it compiled correctly. If there were errors, the output was an inscrutable (to me) mass of unintelligible stuff - core dump.

Being a beginner, many of my programs ended up like this.
 
  • #16
Mark44 said:
We wrote our program code on paper, and then typed each line of code onto an IBM (or Hollerith) card by using a key-punch machine.
After a while, you'd get to the point that you'd create an outline (pseudo code) for a program, and compose a program while keying in cards. At the two schools I went to back in 1972 and later 1975 (mostly tutoring by this time), they had "open" computer labs, where students placed their own deck of cards into the card readers, which created disk files and scheduled the jobs. The lab operator's job was mostly to separate printouts by the job. Turnaround was a few minutes to an hour or so, depending on time of day and activity. For Fortran, there was a WATFOR complier that included debugging features that would at least show which line of code failed, along with a dump of the variables for that line. For the 1975 school, they also had APL, a high level interactive language, running in a room with a bunch of daisy wheel (hard copy) terminals.
 
  • #17
D H said:
Keyed directly into physical memory via switches that the computer operator had to set by hand. A "digital" interface.

rcgldr said:
Many of the older computers (1970's and older) used core memory, which retains data during power cycles, so the boot loaders in memory on these machines only had to be occasionally loaded manually, typically using toggle switches on the front panel. Mini computers like the HP 2100 required that the bootstrap loader be manually entered via toggle switches (actually buttons with the older ones using those cool capacitive buttons) if the boostrap loader got corrupted. I think the older still IBM 1130 had a hard wired boot strap loader
(...)

Going back further still, the ENIAC vacuum tube computer initially had to be hard wired to "program it" Later versions had equivalent of "ROM" functionality, and the EDVAC added the ability to store both program code and data in the computers memory.

Thanks, I see the picture now.

Mark44 said:
We wrote our program code on paper, and then typed each line of code onto an IBM (or Hollerith) card by using a key-punch machine. After we were finished with the PL/C cards for our program, we had to do a few more JCL (Job Control Language) cards that were added to the beginning and end of our card decks.

When we were finished with that, we turned the card deck in, and one of the operators would feed our card decks into a card reader, which read the holes on the cards and wrote on a reel-to-reel tape. After a number of "jobs" were written to the tape, the operator would physically take the tape and mount it on the actual computer, which would then compile and execute our programs.

Been there, done that. Although for me that was exactly 10 years later, in 1982. We were lagging technologically (which was definitely one of the reasons this part of the world turned umop apisdn around 1990).
 
  • #18
In the beginning (and before my time) ... http://www.bbc.co.uk/news/technology-20395212

The first computer I ever programmed was an IBM 1620, which also worked using decimal arithemtic not binary, and was way ahead of its time in doing arbitrary-length decimal arithmetic in hardware. IIRC, multiplying two 100-digit numbers (with one machine code instruction) took about 2 minutes elapsed time.
 
  • #19
We had one of those, too. I wrote a program to calculate factorials on it. I still have a printout somewhere of the result for 3000!, with all of its digits. I think it took something like six or seven hours to calculate. The display lights on the console cycled through a repeating pattern for each multiplication, taking more and more time for each cycle as the numbers became longer and longer.

As a bonus, I could put a transistor radio on top of the cabinet, tune it to an empty channel, and listen to the "music" broadcast via the RF radiation that the computer emitted!
 
  • #21
harborsparrow said:
This article can give you a quick overview of what an OS is, http://en.citizendium.org/wiki/Operating_system
From that article:
Batch job systems in the 1960s - IBM 360 series, and JCL (Job Control Language) -
Batch operating systems could only execute one program at a time.


1960's batch operating systems such as OS/MFT and OS/MVT could run multiple programs at a time, mainly as multiple parallel batch job streams, but most IBM 360's (all but the 360/67) didn't have virtual memory (no address translation), which limited the functionality. There was also SABRE, a multi-terminal application used for airline reservation systems.

wiki_ibm_os_history.htm

The CDC 6000 series pre-dated the IBM 360 by about a year, and were mostly used for scientific type environments. These had multiple peripheral processors. I only saw them at a data center, and don't remember much about the operating system, The CRT monitors were unusual in that the images were effectively "plotted" on the screen (sort of like an oscilloscope).

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

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

Other mainframes of the 1960s: Burroughs, Honeywell, Sperry, UNIVAC, ...
 
Last edited:
  • #22
Borek said:
Been there, done that. Although for me that was exactly 10 years later, in 1982. We were lagging technologically (which was definitely one of the reasons this part of the world turned umop apisdn around 1990).

With regard to the class I took in '72, where we had to use a keypunch machine, you might not have been all that far behind. I took a class in Fortran in the summer of '80 at the Univ. of Washington, and we used keypunch machines again. The next time I took a programming class a couple of years later, they had Digital Equipment Corp VAX minicomputers with terminals, a big improvement over keypunch machines.
 
  • #24
If you're interested in learning about programming modern kernels, the OSDev wiki is the best free place to start.
 

1. What is an operating system (OS)?

An operating system is a software that acts as an interface between the computer hardware and the user. It manages the system resources and provides common services for computer programs.

2. Why is understanding programming important in creating an OS?

Programming is essential in creating an OS because it allows developers to write instructions that the computer can understand and execute. Without programming, an OS cannot be created as it requires a set of instructions to function.

3. What are the basics of programming?

The basics of programming include understanding programming languages, such as C or Python, and their syntax, data types, control structures, and algorithms. It also involves understanding the concepts of variables, functions, and loops, among others.

4. What is a text editor and why is it important in creating an OS?

A text editor is a software used for writing and editing code. It provides developers with features like syntax highlighting, auto-completion, and debugging tools to make the coding process more efficient. A text editor is crucial in creating an OS as it allows developers to write and test the code for their OS.

5. How do I get started with creating an OS?

To get started with creating an OS, you need to have a good understanding of programming and a text editor. You can start by learning a programming language and then move on to understanding the basics of how an OS works. There are also resources available online, such as tutorials and forums, where you can learn and ask for help from experienced developers.

Similar threads

  • Programming and Computer Science
Replies
17
Views
1K
  • Programming and Computer Science
2
Replies
65
Views
2K
  • Programming and Computer Science
Replies
8
Views
1K
Replies
6
Views
542
  • Programming and Computer Science
Replies
16
Views
1K
  • Programming and Computer Science
2
Replies
37
Views
2K
  • Programming and Computer Science
Replies
22
Views
868
  • Programming and Computer Science
2
Replies
54
Views
3K
  • Programming and Computer Science
Replies
1
Views
744
  • Programming and Computer Science
Replies
29
Views
2K
Back
Top