Master 512
Forum by Robin Burton
Beebug Vol. 9 No. 6 November 1990
As promised I'm going to continue with last month's topic, the redirection of standard DOS input and/or output.
MORE ON REDIRECTION
In the last Forum we examined examples of how standard input (which is normally taken from the default console input device, i.e. the keyboard) can be read instead from another source, such as a disc file, simply by modifying the line command entry. We also looked at how output to the standard console output device (usually the screen) can likewise be diverted or redirected to, for example, a disc file, a printer, or to the serial port.
As I said last month, in effect all external devices (i.e. the peripherals including the console) are regarded by the BDOS as simply input or output data channels, so let's dig a little further into this concept.
The reason I've decided to explain this part of DOS is that I always think it's easier to understand something if you have at least a reasonable idea of how it works. In this case it should help you to understand what you can and can't do with redirection, and equally important in my view, why you can do it.
The important part of the idea is the difference in the way DOS is constructed, as compared with, for example, your BBC micro's MOS. That difference is that the DOS operating system is not a single piece of code as it is in the BBC micro. The DOS system consists of two completely separate pieces of software (the BDOS and the BIOS, or the XIOS in the 512) which continually communicate with each other. I've discussed the origins of the reason for these separate elements of DOS operating systems in a recent Forum so I won't go through that again (see Vol.8 No.10).
Suffice it to say that the XIOS in the 512 (i.e. the BIOS in PCs) is the only part of the system which is concerned with physical to logical device mapping, and it actually controls the reading or writing of the data which is to be handled by external devices. The XIOS is the part of the system which is customised to suit the hardware devices supplied by each manufacturer with his system. Of course in the 512 the XIOS is the code which handles the tube interface, rather than directly dealing with hardware controllers, but in principle the concept remains the same.
DEVICE DEFINITIONS
Obviously the various devices attached to a DOS system may have differing attributes or capabilities depending on their type and purpose, so DOS must know the difference between an input only device, an output only device, and an input and output device. Even so, when data is processed by the BDOS, the source or destination of the data is irrelevant. The capabilities of devices only become a consideration when the data is processed by the XIOS (Extended Input-Output System).
The way this control is exercised within the XIOS is via a table which contains groups of bytes, with each group directly relating to each logical device (note, not physical device, as we'll see shortly) attached to, or logically capable of being attached to, the system. Although you might expect devices to be grouped as input, output (or both) DOS doesn't think like this. Strictly speaking all devices can (at least in theory) have any characteristics, so the table entry for each device must define it completely.
I should warn you that some of the following distinctions may seem rather subtle, but they are vital to the design concepts in DOS which make it so flexible. The only initial assumption in the design of DOS is that all devices attached to the system are data transfer ports of some undefined type.
The most important information, so far as DOS is concerned, is how each device processes its data, so the highest level of information, and the first thing the XIOS needs to know is to which main category of device type each logical device belongs. There are two categories, which are generally referred to as character devices, or the only alternative, block devices. You'll therefore find many DOS programming books, particularly those concerned with interrupt calls, containing references to character devices or block devices. This idea is almost self explanatory, but just to ensure that it's quite clear a couple of examples will make it more obvious.
A character device is any device that normally processes data (in either direction) on a byte by byte basis. The most obvious character device is of course the keyboard, but less obvious examples like the serial port, the screen or the printer belong in this category too. The alternative, a block device, is any device which processes data only in pre-defined 'chunks' or blocks, such as disc drives, which incidentally are the only block devices in a standard system.
Within the entry for each device, various bits are set on or off according to the detailed capabilities of the device. One bit, for example determines whether the device can transfer data into the BDOS, that is, it's an input device. Another bit is set on if the device can transfer data out of the BDOS, in which case it's naturally an output device. This is the subtle bit, and is enough to show the way DOS 'thinks' – there's no such thing as an input device, an output device or even an input/output device, there are only devices. What each device is capable of is merely a question of which of its attribute bits are set.
Other bytes within each device entry further describe relevant characteristics. For example, for the serial port, which is treated by DOS as two separate logical devices, there is the (current) data transfer speed for both (AUXIN and AUXOUT). Although there is only one physical connection on the BBC micro (two, or more on some PCs), this single physical device is mapped onto two logical devices within DOS, one input, the other output, which can be addressed quite separately.
In the case of serial devices other bytes are also needed to define the protocol (i.e. odd or even parity, number of data bits, stop bits and so on). For other types of device these entries are irrelevant of course, so they're left empty, but the important point is that all the flags and data possible within an entry exist for all devices, even the screen and keyboard.
SYSTEM DEFAULTS
It's all very well saying that all devices are potentially capable of having all possible characteristics, but clearly in practice this isn't the case, so how are the limitations set?
In short, all this sort of thing is done for you and supplied with the system. However, it's worth saying that it may explain to some of you, now you know a bit more about it, why transferring MS-DOS from a PC to the 512 as outlined in a recent Forum (or even transferring it to another PC) is more likely to fail than to succeed.
In fact it's all part of the hardware manufacturer's job when he defines his machine's peripherals within the BIOS. He must also, in addition to supplying the data in the device table in the form that DOS expects to see it, supply the code which is needed to drive each of the different physical devices (i.e. controllers) he wishes to use in the computer. The final part of the exercise of generating a BIOS for a new machine is therefore to code the jump addresses to the relevant piece of customised code for each device type.
These code addresses, you won't be surprised to know, are also stored in a table much like the device parameters, and the inner (unchanged) part of the BIOS (or XIOS) therefore knows where each piece of code required to drive each device type is located. When the system is booted, therefore, the standard or default data for all the known devices is loaded as part of the operating system.
Items which are not (or originally, in earlier versions of DOS were not) considered to be standard devices (such as a mouse or a RAM disc) are not embedded in the operating system's defaults and do not exist unless they are added later. In many PC versions of DOS this can be accomplished by a list of entries in a file called 'CONFIG.SYS', which the operating system automatically looks for on start-up, much like the action of executing AUTOEXEC.BAT. Each entry in 'CONFIG.SYS' is in effect an additional parameter which defines the system and its facilities. By the way, for those of you new to the 512 don't look for 'CONFIG.SYS', there isn't one in DOS Plus.
THE USER INTERFACE
Anyone not familiar with my style may by now be wondering what the above sketch of a part of the 512's XIOS functions has to do with redirection, so this is where I'll tell you.
When the BDOS wishes to input or output data, it communicates with the XIOS initially by passing an identifier which defines the type of input or output required. The XIOS is responsible for identifying the device type from this and passing or reading the subsequent data to or from that device in the form (and if appropriate at the rate) the particular device dictates.
What you are doing when you redirect input or output is telling the BDOS to specify to the XIOS a different type of device than would be used by default (i.e. the standard) for the particular operation.
Discs of course are a special category of block device, since the code required to handle them is much more complicated than that needed for character devices, needing as it does to cater for several devices of the same type, each with a complex (directory) structure.
So far as character devices are concerned, there are, in the 512 and in most PCs, only two by default, CONIN and CONOUT. What happens when a facility requires input from or output to the console is that DOS exercises a bit of common sense to make life easier for the user or program.
Although either of the two console devices can frequently and conveniently be referred to by the single collective name of CON in commands, when the XIOS investigates the device table it finds that only one device of the two is capable of input, while conversely the other console device is capable only of output. The XIOS therefore reads or writes the data to or from the correct logical device without the need to be further instructed. Likewise in the case of the auxiliary port, AUX, a similar sensible choice is automatically made between the two logical devices, AUXIN and AUXOUT.
However, there is a difference between these two similar choices, and that is that in the case of the console the two logical devices are also two separate (and very different) physical devices. On the other hand, in the case of AUX the two logical devices are actually mapped onto the same single physical device.
In the case of other facilities, like PRN (apart from when you can use Ctrl-P) output to the list device requires either a program which accesses the printer explicitly (e.g. PRINT.CMD) or you must specifically name the device in a redirected command such as:
TYPE FILE.TXT >PRN
(or if you prefer – COPY FILE.TXT PRN).
Next month we'll take a look at a facility which is in some ways similar to redirection, but equally is also different. It's called piping (no, we're not starting cookery lessons!).
I've also found another interesting source for shareware which I'll tell you about. This one has a particularly novel approach to the ordering procedure, and what's more the technique even saves more money than usual too.