How was the first assembler for a new home computer platform written?

Question

How did the 8-bit computers (Spectrum, Commodore, Atari, Amstrad etc) typically "bootstrap" from bare electronics into a platform with a working assembly language and OS?

What I mean: An assembler is not an application exactly trivial to write. There's a text editor, there's a parser/lexer that converts the mnemonics and parameters to machine code, there are I/O procedures to save the sources and the binary, at the very least. It's a fairly largish piece of code that you have no programming language to write in, not even an assembler! And there's even no OS to use procedures for I/O, it still needs to be written. And there were no simulators/emulators for existing platforms to use, since this was a brand new platform.

How was this problem handled? How did programmers approach bootstrapping the micros from 'bare metal' to a 'marketable product with a working assembler'?

Answer 1

Gates and Allen used remote terminal access to a minicomputer (Harvard's DEC PDP-10) to cross-assemble, and simulate, their implementation of BASIC for the Altair 8800. Commodore Basic (for the 6502) is reportedly derived from Altair Basic, and also cross-assembled using Macro-10 on a DEC 10.

Woz (and many other early Apple programmers) could code 6502 machine code in absolute hex, which could then be burned into EPROMs to boot the machine into a monitor, from which more hex machine code (or a single line of mini-assembler mnemonics) could be entered. Many programmers in those days memorized raw hex or octal machine opcodes instead of (or in addition to) assembly language mnemonics.

It's a reasonable guess that some other microcomputer system developers may have used cross-assemblers on the first CP/M systems and/or Intel MDS development systems to write early development tools for later 8-bit systems. And those systems were, in turn, used to cross-develop for subsequent systems.

It appears that the very first textual mnemonic assembly language programs, for the EDSAC and other early vacuum tube computers, were manually translated to hex, octal or binary machine code on paper, by hand, and entered into the computer by front panel switches, punched cards, or paper tape. Thus, the "computers" used for the very first cross-assemblers may well have been a roomful of women with pencils. (See the 2017 movie, Hidden Figures, or the 2008 Book When Computers were Human .)

Answer 2

As someone who did it.... We wrote an assembler for an 8080, as there was nothing affordable from Intel. We wrote it in ALGOL 60, if I recall, and ran it on a mainframe.

the first thing we ran through it was .. itself, re-coded in assembler. Oh, and a boot-loader, though I think maybe we had already hand-assembled a minimal version of that into binary.

After that there was no stopping us :-)

Answer 3

The same answer as everybody else, just with more detail:

What I mean: An assembler is not an application exactly trivial to write.

Oh, but it is. A "first" assembler on a platform simply reads some bytes, transforms them in a more or less 1:1 relationship to other bytes, that's it.

The target architecture was very simple. There was no shared objects / DLLs or anything like that. At least the assembler I used on a Atari 800XL either had no binding/linking stage, or I didn't know about it/did not see a need for it. There certainly were no standard libraries or anything like that. You would skip all convenience features as well.

There's a text editor,

They are pretty easy to write as well. For starters, you don't absolutely need a full fledged modern editor. If in doubt, you can get away with something line-number based like the early BASICs. And even if you wanted to handcraft an actual editor, that would not be that hard either.

there's a parser/lexer

For recognizing the assembler commands, you can use a simple lookup table or direct string comparison. You wouldn't need very complex "formula" parsing either. Don't forget that the CPUs of that time were very simple as compared to today. The 6502 had 3(!) registers (A, X, Y) and only a handful of flags. The datasheet lists only roughly 60 (!) different instructions, 11 addressing modes.

All commands, flags, addressing modes, op codes, timings and instruction-adressing combinations fit on two (!) single-sided pages of paper. The physical CPU had only 40(!) pins.

there are I/O procedures to save the sources and the binary,

You'd need those anyway, and, again, those were kind of trivial back then. You could easily start off with everything on tapes, and then it's just about streaming some bytes in/out.

I recall disassembling/reverse engineering the firmware of one of the Atari 800 XL floppy drives (as well as the OS) back then. It was doable, not too bad.

a fairly largish piece of code

Really not. It was common back then to publish whole games in print magazines (and books), and teenage boys would easily type in thousands of lines of code over the course of a rainy weekend. When your machine has only a few KB of usable RAM anyway, the size of your code will have a natural limit.

And there's even no OS to use procedures for I/O, it still needs to be written.

Again, I/O was very simple back then. A handful of different hardware models (tape drive and 1 or 2 different floppy drives), no choice of file system - heck, no file system at all for the tape, and extremely limited FS for floppies as well. No concurrency, no virtual memory, no swapping, no nothing. Definitely possible to handcode in assembler.

And there were no simulators/emulators for existing platforms to use, since this was a brand new platform.

No simulators/emulators (though I don't know for sure), but cross compilation is, again, pretty simple. That is, if you had (as a larger company) access to existing computers, you would probably write your code there.

How was this problem handled? How did programmers approach bootstrapping the micros from 'bare metal' to a 'marketable product with a working assembler'?

I don't know how they actually did that, but I really would not be much surprised to learn that all the original code was hand-written in cross-compiled assembler or straight hex code.

Remember that rather large things like the Ultima games (starting with II, I think) were hand-written in Assembler. It was doable.

Answer 4

The 1974 Altair 8800 kick-started the industry but at the time offered no keyboard, no screen, just a bunch of switches and lights connected directly to the bus and a counter to help you input or output sequential values. So you'd work out the binary representation of your program by hand and input it byte by byte, bit by bit.

The world's introduction to the 6502 wasn't so much more advanced: 1976's KIM-1 has a hexadecimal display and input pad but you're still hand-assembling and inputting.

So by the time you really get to the boom, in 1980 or so, the market has had half a decade of building terminals, tape interfaces and the rest, often in an ad hoc fashion, from which to put together the second-wave machines. You're not bootstrapping from nothing, you're standing upon experience with the CPUs and with how you can add a bunch of things to them. Through CP/M you already have a huge number of development tools for the 8080 and Z80. Throw in a minicomputer and you've probably got the grunt to simulate. If you're after about 1980 and considering filling your machine with PALs or ULAs then the manufacturer of those will probably lease you the minicomputer and supply the simulation software.

So my answer is: they weren't building from nothing by then, and definitely not in isolation.

Answer 5

It is worth remembering that by the time the home hobby microcomputers appeared, Computer Scientists had more that 25 years experience in building assemblers and designing bootstrap loaders.

As a summer job in the mid-1960s, I worked as an operator in an IBM datacenter with a IBM 1401 - 16K of RAM, no disk, 5 tape drives a cardreader/punch and a printer. Programs were on decks of 80 column cards. You loaded the card deck in the hopper and pressed "Start" This read the first card into the start of memory and executed the instructions encoded on the card. I believe that it read 2 more cards to get the bootstrap fully loaded and then started to read the rest of the deck to get the actual application program read and started.

At university we had a PDP-8 that used papertape as a program storage media. You had to key in the bootstrap using toggle switches. I don't recall how many instructions had to be keyed in but it was very few before the PDP-8 had enough code to start to read the tape and finish loading the program.

In the late 1960's as an undergraduate, I wrote an emulator that ran on the PDP-10 and emulated the IBM-360.

By the time the micro-computers appeared, the concept of using cross-assemblers to produce executable code was pretty well understood and emulators allowed code to be tested even before an actual hardware chip was available. There was usually a long delay between the time a new chip functional design was finalised and the actual chip was available.

Without the modern tools for chip design (CAD, design emulators, etc.) and cheap workstations for engineers to use, it was not that easy to make the masks for the chips and to test actual chips prior to going into production. It was completely impossible to wait for a "real" chip to start programming all of the software.

These problems had all been worked out long before the microchip.

Answer 6

Early assemblers were either cross-assembled or hand-translated. Writing a Z80 assembler in Forth takes just a handful of screens (if you are using mnemonics based on TDL's extension of the Intel 8080 mnemonics rather than the original Zilog Z80 mnemonics). Its main job, once you are talking about a practised coder, is resolution of jump targets.

To put this in perspective: the Nascom Z80 editor/assembler occupied a whopping 4kB of code (the data structure for labels took 2 bytes for each label, namely only its value: for every use of a label, the source was searched from the front for its definition, with the label table being filled in order of definitions, so assembly times grew as O(n^3) with source size). There was a disassembler taking up 3kB, and a very thorough debugger (using NMI and a few hardware bits in lieu of a "trace" flag/feature) taking up another 1kB and using the disassembler internals.

As a result, translating such code into binary (once you had it on paper) was less arduous than it would seem at first glance and once you had the relevant bugs under control, you could host natively.

Answer 7

I used to regularly program my organization's mainframe in hand-coded machine language. It was a 60s vintage machine (a GE400 system), but it had an online patcher so I could modify the operating system on the fly by sticking a deck of cards into the reader and typing a one-character command on the console.

The patches were originally written in assembler, then hand-translated into machine language (in this case in octal). Punch the numbers into a card with a symbolic offset for the starting address, and the patcher basically did a "go to this address, load this instruction". It wasn't far removed from loading up a PDP-8 by using the front panel toggle switches.

Answer 8

The first assemblers for home computers were almost certainly written on non-home computers, whose first assemblers were written on their predecessors and so on back to the very first assembler which was undoubtedly implemented in good old fashioned machine code.

Answer 9

The availability of cross-platform tools such as the Ocode bootstrap method for BCPL, and the Pcode bootstrap for Pascal, were also useful for creating and testing programs written in high-level languages, and then porting them to new systems.

BCPL in particular was designed with machine-architecture portability in mind - which no doubt gave rise to the ethos of portability in C.

Answer 10

Well Here is how I did it, and occasionally still do. In my day it was the system hardware guys who created the 1st code. We needed it to test and fix the hardware.

At this point (1978) the big advantage was the terminal (24 lines by 80 characters), and the UART (serial port, COM port). although on one occasion, I built a unit just using a 12 digit 7 segment display and a scientific calculator keyboard (40 keys).

The 1st step is to write a monitor.

It needs operations to

1. Accept a character, print a character
2. Accept and print a lines
3. Display and change memory
4. Set a break point, step and run programs

and at the second step

Load and save programs. The earliest cheap mechanism was audio cassette tapes (30/1800 bytes per second/minute ).

This was not a great deal of code. maybe a few hundred lines of code. You wrote it and coded it by hand, Gridded notepads were the key.

The big break through for me was something called a rom emulator.

(This is a modern kit version to attach to a PC http://www.sparetimegizmos.com /Hardware/EPROM_Emulator.htm. The 1st one I bought for about $100 (I was getting paid at this point!) had a simple display, and a 20 key keyboard, so you could edit the memory and.. program eproms).

I could connect it to the rom socket and and it enabled me to edit memory interactively. All I needed then was some sort of display.

Once the monitor was working, Assembler was next.

First a simple line by line assembler. recognized Mnemonics, and register names, and simple labels.

Next was a 2 pass assembler which provided for relocatable code. This needed the load function as you needed to load the program twice, once to allocate memory, and generate code, and the 2nd to update addresses.

I wrote my 1st multi-tasking operating system in 4k ROM + 2K ram this way.

The CPM and the PC extended the monitor into a bios, add in Floppy drives and you need file system, and as the saying goes bob's your uncle you have a system.

And that was it til I discovered Forth and life became really interesting.

Forth is not a compiler, it really is a linker, which can be easily extended and normally includes an assembler, and often makes you ask why you need high level languages. You do because optimizing compilers are real time and resource savers, but they were still at least 5 years away or $100K plus in the early 80s.

Once you "get" Forth you wonder what is all the fuss about OSes etc., is, then you get older and realize that they would be very useful when they finally create a good one.

On the other hand Do not write in assembler, write in "C" at a minimum.

Answer 11

There's nothing special about an assembler. It takes one type of instruction and does a 1:1 mapping to another type (the hex values for machine code). The simplest ones were quite simple - in the Red Book for the Apple][+ ( pdf ), on pages 91-93 in rather large type (complete with comments) is the entirety of the assembly code - less a page (256 bytes) and a half in size, on the order of 150 instructions.

Such could easily be written by hand and blown to a prom with little difficulty. From this, larger and more complex applications can be built. But the simplest and first assemblers on the personal computers of the day? Trivially hand coded and loaded.

Answer 12

You might be considering them in terms of modern CPUs. The older machines (8 bit 1970s and earlier like the 6502) had a very simple opcode set. It was consequently much easier to write an assembler/disassembler than you might think, and would have been easier even if coded in machine code too.

Disclosure - I wrote one, although not in machine code.