I/O Management in CP/M

                    In the era of CP/M, because of the limited capabilities of the hardware, there was no multitasking. Even the types of I/O devices were limited at that time. So managing I/O devices was pretty easy (only if compared with current time). Most of the application programs needed following I/O services:

• Read a character(s) from the keyboard, 
• Write character(s) to the video display. 
• Print character(s) to the printer. 
• Utilise the file system to create a new file, read (access), write, close, and delete a file.

                     That means we need to discuss about only three I/O devices: keyboard, printer, and video display. One might ask about the floppies. But the appropriate place for discussing the floppies would be “Disk Management”, rather than this.

         

Keyboard Input In CP/M

                    At that time, keyboards came in many different formats/types. They might have 65 to 95 keys, that too placed in the different places (the placement of alphabets was borrowed from the type-writer, but function keys, and other keys conceived by the computer nerds, did not have permanent place to live. Manufacturers used to move these keys wherever they wanted). Some of the keyboard manufacturers used serial method to transfer the data/signals, while some others used parallel method. Even more, some keyboards represented characters by 7-bits, while others did it by 8-bits. And that’s where the first component of the CP/M, the BIOS, comes in.

                    As mentioned previously, each manufacturer of computer kits, was supposed to (and did) adapt to the BIOS to set of devices which included with their machines (which also includes the keyboard). In more simple way, each BIOS is customised by the manufacturer for their particular keyboard. So that particular BIOS contains all the information about the keyboard which is connected to the computer. That information includes whether the data transfer is being done in parallel or serial mode, whether the characters are represented by 7-bits or 8-bits, and some more stuff like that. In short, BIOS knows the keyboard completely, inside-out. Just like Chandler and Joey knows each other , but here is a one way connection, keyboard doesn’t know much about the BIOS.

                    No matter what the characteristics of the keyboard are, the BIOS provides the same set, “the standard set of BIOS interface functions”, to the rest of the OS. Just for a moment, assume Mr. Barak Obama as CP/M OS, his interpreter as BIOS, different countries as different hardware, and the people as keyboard. Now let’s take Mr. Obama on a world tour. Mr. Obama goes to France. French government (the hardware manufacturer) gives him an interpreter (BIOS), who knows everything about the French people (keyboard). So, whatever French people say to Obama in French language, Obama (CP/M) gets it in English (standard) interface through the interpreter (BIOS). With this method, no matter where Obama goes, he will get the “data” from the native people in his own language through the interpreter provided by that particular government. That means Obama doesn’t have to carry a bunch of persons who speak foreign languages. In the same manner, no matter how the underlying keyboard/hardware is, the BIOS gives the information to OS in one standard format. That is, same set of BIOS interface functions, aka “OS system calls”. In the time of CP/M there were two system calls for keyboard.

• Check if a key has been pressed. 
• Read the character from the key which has been pressed.

                   This was sufficient for most of the programs/applications. But some applications needed more than that. Suppose in a text processing application Alt>F>S saves the file (like it does is MS-Office applications).But suppose, if some programmer created a similar application, in which there is only one way to save the file, that is pressing Ctrl and S keys at the same time. If some user pressed these two keys at the same time to save the file, then BIOS obediently tells the BDOS that two keys have been pressed at the same time. But our BDOS doesn’t know what does that mean. So BDOS doesn’t pass/forward this information to the application program (in this example, the text processor). Hence, the program doesn’t get its required input.

                    But it is possible to bypass the BDOS. It means the application program the keystrokes from the BIOS itself, without going through BDOS. But this is possible only if the application is programmed to bypass the BDOS. If an application is not programmed to bypass it, a user can’t do it. This kind of bypassing is possible because there is no memory protection in CP/M OS. So any application could address any part of the memory. It is the same level of easiness for the application to use the BIOS call, and to use the BDOS calls. But there is a side-effect of bypassing the BDOS. The applications which can bypass the BDOS are not portable.

Characteristics of Early PC System

            Before learning more about CP/M, now it is time to learn something about the hardware that was available in the period of CP/M.
            For the convenience, we will discuss the computers with a video monitor (CRT) (Yes, that means not all the computers had video output, but video monitor was one of the requirements for CP/M). As one might guess, early personal computers too had a motherboard. That motherboard had a microprocessor chip, RAM (Random Access Memory), some ROM (Read Only Memory) chips, and several IC’s who are responsible to for all these chips to work in harmony. Furthermore, motherboard used to have some empty slots to insert additional “expansion circuit boards”, which were, and still, are simply called as “cards”. These cards included a video controller card, which was used to connect a video monitor to the computer. Other expansion cards included additional RAM, floppy, and hard disk controllers. The standard devices for input/output were printer or video, or both, and keyboard. The keyboard was plugged directly to the motherboard, which already had a keyboard controller chip built in it.
            At this point, one might ask, what is it so different from today’s hardware? Everything is almost the same except the video output being optional? Well this is a fair doubt, and question. The answer is all these hardware had very limited capabilities. The main memory used to range from few bytes to several kilobytes. The latest microprocessors were 8-bit microprocessors.
            But yet, there were some advantages in this time. Like, the disk block size, and format was fixed for floppies and hard disks as well (though hard disks were used rarely.) This gave a standardised file system design, which was based on this standard disk format.
            And talking about the interrupt* handling, it was easy thing in those days. As there was only one application supposed to run at a time (no multi-tasking), there was no need to switch between applications. For the same reasons, CPU scheduling was not required in the OS. The interrupts were mainly used for handling the I/O devices.
            That’s all we needed to know about the early hardware, till now. The interrupts and CPU scheduling are two new terms here. At this time, we don’t need to know about CPU scheduling, but interrupts are going to prove kind of important in “I/O Management”. An “interrupt” is a mechanism which is used to signal the OS that some event has occurred which requires attention. The interrupt is signaled either by hardware or by software. Hardware may trigger an interrupt by sending a signal to the CPU, usually by the way of the system bus. Software my trigger an interrupt executing a special program, called as “system call”.

Anatomy of CP/M

                        The major reason for creating CP/M was to provide users, software developers (hobbyists), and software and hardware manufacturers one  single, standard interface, as there was no standard interface at that time. To achieve this target of making CP/M a standard, CP/M was built in three different parts: BIOS, BDOS, and CCP.

                        The BIOS (Basic I/O System), is a concept pioneered by Gary Kildall, which we still use in personal computers. This BIOS in CP/M, is similar to a monitor,but with standard specified functions and interfaces. The BIOS is a set of programs, usually stored in a ROM chip which placed on the motherboard. The BIOS directly controls hardware components other than microprocessor, and memory. Each manufacturer of computer kits, who wanted to use CP/M on their computers, was supposed to adapt this BIOS. (Later, all of the manufacturers, almost all of them, adapted this concept of BIOS.) The interface to BIOS, however, is the same, no matter how the underlying devices might work.

                        Gary called the core of the CP/M operating system as the BDOS, for Basic Disk Operating System. It is what we call the kernel today. It is independent of the hardware, and performs more primitive services. That means BDOS is same for all the hardware systems (with no changes), that CP/M is to run on. (In this time, DOS / monitors had to be written differently for each kind of hardware.)  Handling different types of hardware is task of the BIOS. The BDOS implements the CP/M filesystem, and some input/output abstraction*1 on top of the BIOS.

                        After BIOS, and BDOS; third and last component of the CP/M is the user interface: CCP – Console Command Processor. It is a text based user interface. Each of these components have size around 2000 to 4000 bytes. The BIOS, and BDOS are memory resident, that is they are always present in the memory. And, in the case of CCP, it is memory resident unless the memory is required for any other program. In such case, CCP would be over-written by the program (which requires the memory), and after the program finishes the execution, the CCP would be automatically reloaded in the memory. (More on this in “Memory Management”.)

                   The BIOS portion was always adapted to the particular hardware. Adding memory to a computer, for example, meant that the CP/M system had to be reinstalled. Once installed, the operating system (BIOS, BDOS and CCP) was stored in reserved areas at the beginning of any disk which would be used to boot the system. On start-up, the bootloader (usually contained in a ROM firmware chip) would load the operating system from the disk in drive A:

The major complexity of CP/M was reduced in the BDOS, and to a lesser extent, in the CCP and transient commands. This meant that by porting the limited number of simple routines in the BIOS to a particular hardware platform, the entire OS would work. This significantly reduced the development time needed to support new machines, and was one of the main reasons for CP/M's widespread use. Today this sort of abstraction is common to most OSs (a hardware abstraction layer), but at the time of CP/M's birth, OSs were typically intended to run on only one machine platform, and multilayer designs were considered unnecessary.

*1=A standardised interface that provides general system functions but hides all the messy hardware details is called as abstraction.