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.