programming an os

jd12345

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?

Borek

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.

Devils

Front panels, paper tape, patch panels etc; and bootstrap from there.
The Apple ][ was one of the first useable computers & not just a toy.

I used this Heathkit in the 70s; used the front panel (about 16 keys) to enter programs.
http://en.wikipedia.org/wiki/Heathkit_H8
http://en.wikipedia.org/wiki/Apple_II_series

Borek

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.

Devils

The 'loader' was in EEPROM (a non-volatile memory chip) which was programmed with an EEPROM programmer.

http://www.electronickits.com/kit/co...rog/ck1707.htm

D H

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.

Borek

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?

Pythagorean

One of my mentors wrote code by punching holes in big cards and feeding the cards into the machine.

ImaLooser

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.

Devils

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

Borek

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.

D H

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.

rcgldr

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

jtbell

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.

Mark44

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.

rcgldr

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.

Borek

Thanks, I see the picture now.

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