• Please review our updated Terms and Rules here

Is all of CP/M written in PL/M?

One of my S100 systems used the original Tarbell controller. I seem to recall that it used a 32-byte bipolar PROM to get the first sector from an SD 8" disk loaded.
On the other hand, a commercial system that I worked with had an extensive ROM with diagnostics and loaded the first file from a disk--which had to be in Intel hex format. The BIOS for CP/M was encoded that way and a dummy file set up so that the ROM could find it. The system was created to load a different OS; so s skeleton/dummy filesystem was necessary to get CP/M running. Said filesystem in the intended OS had a directory accessible as a file and containing only ASCII-information, so easily read by, say, a BASIC program without any binary bit-twiddling.
 
CP/M 3.1 for the MSX and Microsoft CP/M 2.2 for the Apple ][ both had a disk-based IPL that chainloaded CP/M. There was an unofficial port of 3.1 to the Apple //e that used the same basic IPL as the MSX version. Nabu CP/M 3.1 also loads a bootsector off the disk that proceeds to load the rest of the OS from disk.
 
So what exactly defines what is the Bootstrap then? I always thought it was defined by the location of the first byte of code that the CPU executes after a physical power-on - eg, if it reads and executes a byte from a ROM, then the ROM code is the bootstrap. If the memory is empty and you load it from switches, then the routine on paper is the bootstrap. If you have hardware that populates the memory at 0000 ( or whever the CPU starts ) then releases reset, then wherever that code comes from is the bootstrap.

It sounds like it's being extended to code that is loaded by other code now, and anything that is required prior to OS initialisation?
 
The early computers didn't have ROM code, but were usually operated by front panels. These mainframes also had fairly sophisticated I/O controllers. The "bootstrap" button on the Honeywell 200 series would execute an I/O operation for the designated controller/unit using a memory address also entered on the front panel. Then the operator would "run" the code that was loaded at that address. The exact steps might vary, even including starting at a different address. The bootstrap code was whatever was in the first record of the I/O device. With ROMs, especially interactive ones, that became fuzzier. But I've not heard of ROMs referred to as the bootstrap - that's typically what is loaded in order to start an OS (or other similar software), and varies according to the particular intent of the operator. Could be an OS, or some sort of "monitor" (that word meant something different back then), or some stand-alone application or utility. I usually think of bootstrap as meaning that the computer is starting some software that is not present in memory when the computer is powered on. But I'm sure opinions vary.
 
Just curious what you would call the deadstart panel on a CDC 6600. We called it the "deadstart panel". Did any other mainframe or mini ever use an array of switches to IPL?
CDC-6600-R-M-6-03.gif
 
cj7hawk said:
So what exactly defines what is the Bootstrap then?
Click to expand...
It is probably easier to think of the boot code as a staged system:

* The first stage is the initial code (can be executed from ROM, toggled in by front panel or entered into a monitor). The execution environment can be very hostile, so this code is usually very small. In many disk-based systems, it only reads a single sector off the boot device and executes it. I've heard it being referred to as IPL and it can be as small as a dozen bytes.
* The second stage is lives on the boot disk and is a bit larger, but still very restricted. In many disk-based systems, it only reads one or more tracks into memory and executes them, but may understand a file system and load a file instead.
* The third stage is where the you actually have enough code to properly implement a file system, relocation, decompression, networking, and anything else you need to fully take over the machine. This code may load one or more files off the boot device or from other machines, build the executable image in memory and may even initialize parts of it. Eventually, it hands over to the code it loaded.
* The fourth stage is where your system is running its final code. The third stage may or may not stay in memory permanently.

Not all systems use all stages, and some have additional steps for one reason or another. Sometimes, the ROM code understands multi-sector reads or file systems (stages one and two), contains parts of the operating system (stages one to three) or even all of it (stages one to four). Other systems run these stages, but load another IPL and run the whole sequence again.

cj7hawk said:
I always thought it was defined by the location of the first byte of code that the CPU executes after a physical power-on - eg, if it reads and executes a byte from a ROM, then the ROM code is the bootstrap.
Click to expand...
I'd say the bootstrap is more defined by its function. For example, I wouldn't use it to refer to a PC BIOS, but to the code loaded by it, which has the function of bootstrapping into a different system.

The code toggled into a front panel is bootstrap code. That doesn't change if the same code is entered into a monitor on the same machine because the front panel got replaced with a monitor ROM (for example on an Altair or PDP/11). It's still the same code, same function. And that is still true if that code got loaded over XMODEM, PXE or HTTPS from a remote machine. It is still bootstrap code.
 
"Bootstrap/IPL/deadstart"--it's all fabricated terms, of arbitrary dimensions. What's true is the machine begins executing instructions at power-up--divisions after that are a matter of invented terminology.
 
On the early DEC Alpha CPUs (for example 21066 in the AXPpci33 aka. "Noname" board), the first code that is executed comes from a small ROM that gets loaded into the CPU's memory cache as a serial bit stream (and you can select the variant of the code to load with a jumper to select which bit in the ROM is used). This code then executes from the cache to initialize the CPU and memory subsystem, then load the remainder of the BIOS (either SRM or ARC) from another ROM. The BIOS then is responsible for initializing the peripherals (including emulating X86 instructions if necessary for PCI or ISA card ROMs) and loading the OS from a device (disk, network).
 
On the CDC STAR, the CPU doesn't start until activated by the MCU (maintenance control unit), a 16-bit mini whose startup program is loaded from drum. Said drum is written with a CE briefcase-sized paper tape reader. The MCU writes the initial startup code to CPU memory.

On the other hand, on the IBM 1620, pressing the LOAD button reads data from the first card in the reader into memory.

With all due deference to the OP, the term "bootstrap" is an artifice.
 
The term bootstrap pre-dates computers. IBM chose the more-clinical IPL (Initial Program Load), as did some others.
 
"Pull one up by one's bootstraps" in that sense. It's clear that IBM didn't like the term and neither did CDC for that matter. Apparently, the mini crowd liked it, however. GE had a "Bootload" switch on the operator's panel for the 645, so there's something there.
 
So at what point does human interaction invalidate the process? Would someone feeding a paper tape into a computer count as a bootstrap, or is the human the bootstrap in that case? I figure things like the WW2 code breaking computers can't count since they were not automated - and I figure a good bootstrap should automate the post-powerup process.
 
some sort of human interaction is required. even "appliances" require someone to turn on power. there's probably not much point to trying to define things in such detail. bootstrapping is what it takes to get a computer to it's target state (CP/M prompt, Linux login, etc). there can be lots of stages involved, some hidden from view. each of those stages could be called bootstrap, just differentiated by their place in the order. we could split hairs about whether a ROM monitor, where you type in a "boot" command, constitutes part of the bootstrap. we could make a case for the code to implement the "boot" command being part of it, though.
 
In fact, can any computer not implementing an operating system or monitor (e.g. IBM 650) be considered to be "bootstrapped"? Each time the task changes, the system is stopped and a new program is loaded into memory. Similarly, the old drum-based systems would simply start executing code already existing on the drum. Or any relatively recent MCU, with code already programmed in the flash memory. No bootstrapping--just reset the thing and away you go...
 
I did have a look around at varying opinions on what constituted a bootstrap and they range from;
* Asking the computer to do the impossible - ie, It's an "Inside Joke" - since a computer cannot pick itself up by it's bootstraps
to
* Most computers have two bootstraps - One to initialise the computer and a second to load the operating system.

So I followed Chuck's line and went back... Way back... All the way to the future and found;
https://bitsavers.org/magazines/Computers_And_Automation/195412.pdf ( 1954 )... Which has a glossary, and to which others have referred to as the earliest example of the use of the term Bootstrapping that they found...

Which provides an initial and an updated definition.

Original: (Pre 1954) -
Bootstrap -- Digital Computer Programming. The coded instructions at the beginning of an input tape, together with one or two instructions inserted by switches or buttons into the computer, used to put a routine into the computer.

Updated: (Subsequent edit?)
Bootstrap -- The instructions at the beginning of a program together with a few instructions entered from the control unit, used to put a program into the computer memory.

Of the era, there was no concept of "Operating Systems" as such, and the computer simply ran a "Program". Hence a bootstrap is not the booting process itself, but how you get a program into computer memory... And an OS is just a fancy program. In fact, Program would refer to anything the computer sees as an instruction. And what we regard as a program today is just a subset of the OS.

Which, if extrapolated, would make the first "byte" the computer executes, with the intent of other actions to get a program into the computer, sufficient that it runs. What it does after that, including loading other programs would not appear relevent though I note each step is successively called "Bootstrap" - Which would appear to simply be dilution of the original term to ignore the fact that the program is already running when an OS is present.

I like the second definition - it appears as though they gave some serious thought to the changing technology, but wanted to keep the definition consistent for all time.

It also includes firmware, roms, disk boots and other categories, and gives a clear demarkation - eg, if you load the whole program straight into memory, then there is no bootstrap (eg, ROM based system) and it also includes that it must be minimal, eg, "few instructions" - Not the entire program. The definition allows for both bootstrapped and non bootstrapped computers and provides a clear demarcation between them, albeing to interpret subjectively.

From this, a tree diagram could be created - eg,
Program already loaded when computer boots? - Not a bootstrap.
Program is not in memory when computer boots? - Is a bootstrap.

In my own example, 256 bytes (large, but reasonably a "few") that loads a program, and sets up the Memory Management Unit - As both of these activities are necessary to get the program into the computer's memory, this would reasonably be a bootstrap. The "Control Unit" input in this case is a physical reset button.

The older "rom-based" computers I used to make? No, the program is present at initialisation. It is NOT a bootstrap.

CCP - it has the control unit instructions, but no, it's neither a "few" instructions and it itself is the program, hence not a "Bootstrap"...

This definition has interesting implications for CP/M.

Amstrad series: Disk Sector 0 is bootstrap.

Osborne 1: ROM is bootstrap.

Kaypro: ROM is bootstrap.

As you can tell, the autist in me loves definitions. :)

Thoughts / criticism / ideas on this welcome?
 
Defining something that already exists doesn't change it, and has no implications really. Booting is just "doing whatever it takes" for the given system. The Heath H89 has a ROM that prompts the user for commands, but one of those commands is "Boot". So the ROM itself is NOT bootstrap, but the code in the ROM implementing the Boot command *IS* bootstrap? What about CP/M 3, where you need to boot a special copy of CP/M 2.2 does nothing but load the CPM3.SYS OS image, which is the final target. I'm not sure how applying an arbitrary label to pieces of code (and stages) that are necessary to make the computer usable changes what is necessary and required. Booting is simply achieving one's goal/reaching their target by the necessary means, and the bootstrap includes those means.

A rose by any other name still attracts aphids.
 
You must log in or register to reply here.
Back
Top