I have been learning about PCs, the first of which was the Altair 8800. So that users could run programs, Micro-Soft created a BASIC interpreter to allow the program to be mapped to processor instructions. They originally fed the interpreter to the computer as a binary via paper tape.

  • How they manage to install the interpreter directly to the hardware?
  • If an interpreter has been programmed in assembly language, how did it then become something that the computer could understand?
  • How was this automated?
  • Welcome to Retrocomputing Stack Exchange. Please read the tour. I'm not really sure what your actual question is. Are you asking how compilers were made if there were no compilers? Also, keep in mind that we don't answer questions about modern-day practices here (though I don't think that this has changed much since the early UNIXes). – wizzwizz4 Oct 21 '17 at 8:44
  • my question is on how the interpreter are loaded in computer they build?.i saw video of 8800 where the fed using magnetic tape.so it is hard to follow this mechanism. And also every time they have to convert the opcode to machine code before feeding the tape.how they manage to do this? – leaner Oct 21 '17 at 8:57
  • "Are you asking how compilers were made if there were no compilers?" and yes but at the same time how they loaded these program to the hardware every time ,and other part of my question is every-time they need to convert their opcode to binary manually .but for huge process this is difficult... – leaner Oct 21 '17 at 9:06
  • Some of your question was off-topic for this site (the part about how it is done today) so I removed it - the rest is fine. Perhaps you'd like to have a look at some of our policies on Retrocomputing Meta, tagged scope. – wizzwizz4 Oct 21 '17 at 9:40
  • sure will do,i was eager to get some answer on this so i didnt check that , searching for 2 days to get a solution in this........... – leaner Oct 21 '17 at 9:47

Altair BASIC, the first product created by Micro-Soft, was programmed using Assembly. Some of this was assembled by a program running on a PDP-10[citation needed] but some was assembled by hand.

He took out his notebook and quickly scribbled down a loader program in assembly language, then manually translated that into the ones and zeros the Altair would understand.
START-UP Albuquerque and the Personal Computer Revolution

Assembly language is an easy-to-read version of machine code. An assembly compiler converts acronyms, such as MOV, into a series of bytes, interpreted as machine code instructions by the CPU. Depending on the parameters, addressing modes etc. an acronym might have multiple different byte values. MOV in the Intel 8080 (the processor in the Altair 8800) is a notable example - every combination of moving values from one register to another has a separate machine code instruction taking up almost half of the instruction set. There are often added features, such as the ability to reference a section of code or a memory value by a name (known as a label) instead of by the position in the program, but a rudimentary assembler could conceivably be made using a find-and-replace tool. This simplicity is how Paul Allen was able to convert his loader program from assembly to machine code using only a notebook and pen.

Basic 8K on paper tape.

This loader program was originally used to allow the BASIC interpreter to be loaded from a roll of paper tape. The program could be put into a Teletype machine and "typed" into the Altair 8800, where the loader program would store it into memory. From there it could be run on the Altair 8800 by setting the instruction pointer to the start of the interpreter. The loader program itself was entered by typing it by hand into the computer, where another loader program would take the loader program and load that into memory. The loader loader was hard-wired into the computer. This is a problem known as bootstrapping, from the saying "to pull oneself up by one's bootstraps".

The principle of this bootstrapping remained roughly the same in the final version of Altair BASIC. A program running on the computer would know how to interface with the tape reader - after the user's copy of BASIC was put into the paper or cassette tape reader it would be read into the computer's memory and executed. From there programs could either be read into the memory reserved for the BASIC program from another tape or typed in manually. There was also a feature allowing the user to save their programs.

Altair BASIC is an interpreter, not a compiler. This means that the BASIC program is not converted to machine code. Instead it is treated as data that BASIC reads to determine what section of its code to run when. For example, if you have the BASIC program:

A = 1
B = 2
C = A + B

it will not be compiled to machine code. Instead, the interpreter will set the variable A to 1, then set the variable B to 2, then read A and B, then add them, then set C to the result. This makes BASIC much slower than native machine code, but it is has the advantage of being easier to program and debug.

The CPU only understands machine code, but the interpreter "understands" whatever programming language it is designed to interpret. For example, if the command PRINT is being interpreted, the interpreter's instruction pointer will jump to the code that prints things to the screen.

You could view the combination between the interpreter and it's data as a machine code program that executes the interpreted program, but it's not really "compiled" as there is no compilation step in between "representation of the source code" and "execution of said code". If the program that ran BASIC instead replaced PRINT with a jump to the code that prints things to the screen etc. then it could be said to be a compiler that produces a program that requires BASIC as a "runtime library" and the code would run a little bit faster as it's already done all of the lookups and code replacement. However, I do not know of any BASIC compilers.

The interpreter is programmed for one specific processor; this means that it will have to be partially modified to work on a different but similar processor and almost completely reprogrammed to work on a very different processor. The interpreter is also programmed for a specific type of computer but, as the Intel 8080 became very popular after the Altair 8800, Microsoft BASIC only required small modifications to run on other 8080-based computers. Microsoft made a lot of money from this. See the questions with a BASIC tag for more details as to variants of BASIC.

ROM was used in many computers to store BASIC interpreters. This meant that BASIC was already effectively "in memory" and did not need to be loaded in by the user - a very time-consuming process. See Why was BASIC built into so many operating systems? for reasons why BASIC would be included like this.

  • My doubt is interpreter has to be rewritten if instruction set of the processor change.And after the introduction of the ROM the (interpreter or compiler) machine code are hard coded into them. So still then do we have convert our interpreter opcode to machine code and feed it to processor manually? – leaner Oct 21 '17 at 11:23
  • 2
    The interpreter does have to be rewritten if the instruction set of the processor changes, but that will only happen if you take out the processor and put in a new one. As the 8080 was quite popular, Microsoft BASIC was slightly modified and sold to lots of companies. – wizzwizz4 Oct 21 '17 at 11:31
  • 1
    As far as the computer is concerned, ROM is ordinary memory that just so happens to completely ignore all attempts to write to it. The program stored in the ROM is already in machine code. The processor does the work of reading each opcode from memory and running it through its circuitry to execute the opcode. – wizzwizz4 Oct 21 '17 at 11:33
  • 2
    @leaner If it is stored on ROM, the ROM can be manufactured with the program already in it. However, I think that BASIC was provided separately for the Altair 8800, meaning that it has to be loaded from tape into RAM (without being converted in any way) every time the user wants to use BASIC after turning off the computer (RAM gets wiped when the computer turns off). – wizzwizz4 Oct 21 '17 at 11:39
  • 1
    @leaner Post another question! That's what this website is all about. If it hasn't already been asked by somebody else, asking it now will help other people who also want to know. See here for some help on asking questions on this site. – wizzwizz4 Oct 21 '17 at 11:56

The Altair 8800 had a set of switches on the front panel which could be used to store arbitrary data to arbitrary bytes of RAM. The designers of the Altair published a boot loader that was IIRC a little over 50 bytes that could be entered via switches and would allow the machine to load and run a variety of programs from a paper tape reader.

Since using front-panel switches to enter a 50-byte bootloader any time one wanted to load something would have been a nuisance, Micro-Soft published a simplified boot loader which fit in 17 bytes (I haven't examined the code for it, but I suspect it was probably hard-coded things like the size of program to be read). An even smaller bootloader (12 bytes maybe?) was published about a decade ago that not only requires that the code to be loaded must have a certain exact size, but also requires that the bytes be stored in reverse order and that no two consecutive bytes match. The BASIC interpreter would probably not satisfy those requirements, but if one punched a copy of it on a tape following a reverse-punched copy of a more sophisticated bootloader, one could use a 12-byte loader to read the more sophisticated loader, and then use that to read the BASIC interpreter.

  • The 12 byte loader was written by Josh Bensadon quite recently. – scruss Oct 26 '17 at 1:16
  • 1
    @scruss: Thanks. Incidentally, I've come up with a 12-byte boot loader for Lee Hart's 1802 Membership Card (connected to a serial port). If interrupts need to start out disabled, the loader would be 13 bytes (disabling interrupts takes a two-byte instruction, but that instruction can set the X register "for free"). – supercat Oct 26 '17 at 14:08

When I did this sort of thing years ago, I wrote the interpreter in a different language (like C or PL/M) and then used a cross compiler to generate the code and a bit of assembler to set the start address. This was just a jump instruction at FFFF:0 for 8086 ot 0 got the 8085/Z80. The C compilers didn't generate efficient code, especially for the in/out statements so PL/M was the weapon of choice.

This was then converted to a hex format - either Intel or Tektronix. It was tested by downloading the code into an in-circuit emulator plugged into the hardware. This allowed me to put breakpoints in ROM, patch the code etc. After several iterations, it would be ready to release.

The release was in the form of PROMs. On 8-bit platforms, it was used as-is. On 16-bit platforms, it was split in two, odd in one, even in another.

Not sure what you mean by how was this automated. Once the build is complete, it is just a simple script to transfer the file over to the emulator. There wasn't any form of source code control so a copy of the source code, along with the compilers and hex output were dumped on magnetic tape and this was archived with a set of PROMs, the release note and any supporting documentation. This was the master copy: shop floor made a copy of that for mass production.


Any machine-code program that does not rely on routines supplied by a full-on operating system can be "installed directly to the hardware" just as it is done with the BIOS: The machine code is written to some kind of ROM (an actual mask ROM - which is "written to" by sending your data on paper or as a file to a chip maker; an EPROM, which you can write from punch cards, paper tape, or a host computer via a dedicated programming device; or something modern like flash memory), which is then wired up to be in the memory address space where the CPU begins execution after a reset.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.