I read in this article 1GL: First Generation Programming Language that people used to enter machine instructions directly.
I want to see some pictures of their keyboard & monitor. Did they directly enter these instructions into memory? of they were directly send to CPU? at what frequency it used to operate? I want to read more about those computers and programming them.
kindly post some good references. If you have seen or programmed one of those machines please tell me the story.
Well if you go back far enough code was entered through punch cards.
http://en.wikipedia.org/wiki/Computer_programming_in_the_punch_card_era
We still have similar devices (8085 kits, for example) in microprocessor labs in universities - they usually have a hex keypad that you use to enter the machine code into some specified location in RAM, and then you press another key to start execution. Pretty much every computer since the 1950s has had separate RAM, so no, the instructions never go directly into the CPU.
You may want to look at this Wikipedia article for some images of these training kits.
Just to divert slightly from the mainframe approach...
My first experience of low-level was on the Sinclair ZX-81. This had a variant of BASIC built in, but you could program "easily" in Z-80 machine code by this means:
After that I moved up to the BBC micro, which had an awesome 6502 Assembler built directly into its BBC Basic, so it was no longer necessary to go to such extreme lengths to enter the machine code directly.
Ah, the good old days... :-)
Early 80s, I was a kid and my family was fortunate enough to own a personal computer-- An "Apple II". Like many programmers, I got started as a kid because I wanted to create my own games. There was a BASIC language interpreter built in called Applesoft BASIC, but it was too slow to do any reasonable animation. The commercial games, at least I was told, were all written in assembly language. So there began the quest... to learn assembly language... which first meant learning MACHINE language... (the direct entry of hexidecimal numbers rather than three letter text codes representing microprocessor instructions).
The Apple II used the 6502 microprocessor. The first thing you had to learn was the memory map, which was the range and purpose of each section of memory (RAM and ROM). Here is a link to the memory map of the Apple ][e: link text
The black numbers on the left margin are the memory locations. Note it goes from $0000 to $FFFF. The 6502 could only address 16^4 = 65536 or 64k of memory. You can see the RAM ended at $BFFF. The $C000-$CFFF range would access any peripheral cards you placed in the computer. For example the disk drive controller would go in slot #6 and would show up at $C600. I felt really cool as a kid that I could reboot the system by typing $C600G which would execute ("G" for "Go") the disk controller re-boot routine in ROM. The space from $E000 to $FFFF was originally just ROM, but the Apple ][e ("e" for "enhanced") let you switch back and forth ("bank switch") and access that extra 8k of memory.
Do you see the graphics and text areas of the memory map? That how you would display to the screen. In those days (pre-GUI) there was a "text" mode where programs in ROM would continually scan memory between $0400-$0800 (= 4*16*16 = 1024 byte locations each corresponding to a place on the screen). It would take whatever ASCII byte was stuffed there and turn it into a character on your monitor. Here is the 6502 instruction set which among other things allowed you to move bytes around: 6502 Instruction Set
And to put it into context, here is a sub-routine from ROM which adds to floating point numbers called FADD: (full floating point routine collection here)
F46E: A5 F4 FADD LDA X2
F470: C5 F8 CMP X1 COMPARE EXP1 WITH EXP2.
F472: D0 F7 BNE SWPALGN IF #,SWAP ADDENDS OR ALIGN MANTS.
F474: 20 25 F4 JSR ADD ADD ALIGNED MANTISSAS.
F477: 50 EA ADDEND BVC NORM NO OVERFLOW, NORMALIZE RESULT.
F479: 70 05 BVS RTLOG OV: SHIFT M1 RIGHT, CARRY INTO SIGN
F47B: 90 C4 ALGNSWP BCC SWAP SWAP IF CARRY CLEAR,
* ELSE SHIFT RIGHT ARITH.
F47D: A5 F9 RTAR LDA M1 SIGN OF MANT1 INTO CARRY FOR
F47F: 0A ASL RIGHT ARITH SHIFT.
F480: E6 F8 RTLOG INC X1 INCR X1 TO ADJUST FOR RIGHT SHIFT
F482: F0 75 BEQ OVFL EXP1 OUT OF RANGE.
F484: A2 FA RTLOG1 LDX #$FA INDEX FOR 6:BYTE RIGHT SHIFT.
F486: 76 FF ROR1 ROR E+3,X
F488: E8 INX NEXT BYTE OF SHIFT.
F489: D0 FB BNE ROR1 LOOP UNTIL DONE.
F48B: 60 RTS RETURN.
Looking at the routine, the first four hex numbers before the colon are the memory address. So if you wanted to run the FADD routine directly, you'd type F46EG (again, the "G" for "go).
The next two hex numbers, $A5 and $F4, are the instruction codes. If you look at the handy instruction set chart, you see that $A5 means "LDA" or load the accumulator. The accumulator was one of the three memory locations (each one byte) on the 6502 processor for you to do computations with (that was nice of them, eh?). The $A5 version of the LDA command meant that the memory location to load was from the so called "zero page" or first $FF bytes of RAM which were mostly reserved for system use (there were a few bytes free for programmer use. Again, that was so nice of them.) The $F4 is the memory location whose contents (one byte) will be transferred to the accumulator. The next line has the instruction $C5 or "CMP" command, again the zero page version, which then compares the contents of the accumulator with memory location $F8. So that's the lowest level known as "MACHINE LANGUAGE" and yes, we'd sometimes type in little programs or mess with memory for debugging purposes.
The next few columns are more readable; you see the actual "LDA" and "CMP" commands and variables X1 and X2 which represent those memory locations. You also see Woz's comments on what the code is doing (comparing the exponents of two floats). This is known as "Assembly Language" and is what was actually typed in. After you typed it in your assembler would compile the byte codes.
Well, I never did manage to create a reasonable game on the Apple ][ but I sure did learn a lot about programming trying!
The oldest computer I've programmed is the (not very ancient) PDP-8. To get it to a point where you can start loading from paper tape, punched cards or a disk, you need to enter some bootstrap code from the front panel. You start by setting an address where you want to load code, then you can enter each word via the switches on the front, finishing each word by flipping the (spring-loaded) LOAD switch (this will then increment the word pointer, so you can simply enter the next word).
Once you've loaded your bootstrap, you then load the start address into the address register and flip the RUN switch.
(Converting a short remark with lots of follow on questions from OP into a long answer:)
I entered bootstrap loaders through switches on Data General Novas (16 bit machines) in 1969. For an Packard Bell 250 that I toyed with in 1967, there was a Flexowriter equipped with a paper tape reader, to load the program in the delay line memory.
For the Nova, there was one row of 16 toggle switches, and a half dozen other switches whose functions were "Set Memory Address", "Deposit Word and advance memory address", "Single Step" (we used that a lot for early debugging!), "Run" and "Halt", IIRC.
The Nova initially had 4096 words of 16 bit memory, the worlds ugliest RISC instruction set with 4 16 bit registers (stack? who needs a stinking stack?), and something like a 1 microsecond memory cycle time (instructions took several cycles). The machine had a "serial port" that connected to an ASR33 Teletype (10 characters per second), and we splurged for a high-speed paper tape reader and punch.
It initially came as bare hardware, with a paper tape containing a two-pass assembler that read source from, well, the paper tape reader. We initially wrote assembly code source onto punched paper tape directly with the ASR33 Teletype; this including "rubout" punches to wipe out characters that were wrong. Editing was incredibly painful. A cohort wrote a bad editor as the very first thing, that read a paper tape into a buffer in the computer, let us find lines, delete lines, and insert lines
My first job was to implement a Kemeny&Kurtz style BASIC interpreter on this. Two years later we added 4K more words and 100K word head-per-track disk, and I built a multiuser timesharing system on it, both written with that ugly editor. Ugh. I built OSes on various machines for the next 20 years.
The Linkers/Loaders books talks about "linkers", that combine multiple object files. Our assembler didn't bother; it produced, for your assembly code, a directly loadable binary paper tape. That tape was designed to be loaded by a tiny program that was entered, well, back to the opening of this discussion, a 30-odd word bootstrap program entered from the front panel. After each program run (usually ending in "crash") we usually had to re-enter that boot loader; we got pretty good at since we often did it several times a day.
Regarding coding forms: people did write code on such forms, and then somebody else often "punched" them onto paper tape. The purpose of the form was to make sure the person doing the punching put stuff where you said, and made you the coder rather more careful about pensmanship in what you coded (I still print block capitals pretty neatly). It didn't take us long to realize that you could code free-form, and after that I did most of my coding on graph paper with faint lines so it looked sort of neat before typing it into the editor.
You couldn't effectively hack online with the text editor; it didn't hold enough text for you to cut and paste arbitrarily, so you had to edit in one pass and make changes from beginning to end in order. Consequently, newspaper style editing on paper as you coded intially was far more effective. After first coding, we'd run program listings and then write on those listing what edits we wanted to make, before we went and made them. Screen editors with giant buffers are much nicer!
The Packard Bell 250 was similar to the Data General machine, except it (remarkably) had a built-in loader program and came with an editor. Because it had a delay line memory (think of this as sometihing like a disk track), you place instructions along the delay line such that when the previous instrution was done, the next instruction just so happened to be coming under the "heads". Talk about painful to optimize... It had one great property; when you got frustrated, you could just whack the CPU and the mechanical shock would make the machine forget everything. Very satisyfing for a moment. Then you had to start over.
Ah, be associated with "ye olden days".