Master 512
Forum by Robin Burton
Beebug Vol. 9 No. 5 October 1990
This month I'm going to cover one of the several topics which has been on my list of items for the Forum for months, but until now something else has always seemed to crop up instead. At the same time I'll recap on a point I covered in one of the very first issues of Forum, for the benefit of newer readers.
CGA EMULATION
A week or two ago I had a query from a reader which prompted this item. I won't be spending long on it, but it might be interesting for one or two of our newer readers. After all, not all 512 users write programs even in BBC mode.
Essentially my correspondent said that he was delighted with the speed of his 512 (and a friend with an Amstrad PC wasn't quite so pleased), but of course when it came to coloured text displays the Amstrad owner regained his smile. Couldn't something be done to produce colour in 80 column screen modes for the 512, since it's supposed to emulate COLOUR Graphics Adaptor output?
The short answer is no, but the reasons can be presented in two versions. The simple answer is that the 512's 80 column display uses a (BBC) mode 3 screen and that's a two colour display. Fine, but it doesn't explain why (by the way, even if you don't use 'PCSCREEN 7', which is a completely accurate mode 3 screen, the 512 still uses mode 3, but with some direct programming of the BBC's 6845 CRTC to close up the gaps between the lines).
Also as an aside, for those who wonder what a 'single colour' or monochrome display is, strictly this refers to the monitor, not to the computer's display capabilities. After all, a display in the same colour as the background wouldn't be a lot of use, would it?
For the longer version of the answer to this query you need to consider how characters are displayed on the screen by the BBC micro since that is doing the work. If you look at the BBC micro's VDU23 character definitions you can see that each character is made up of 8 bytes in an 8 x 8 bit matrix. If a bit is set to 1 (on) the pixel is displayed in foreground colour, if the bit is off its corresponding pixel is left as background.
In a BBC mode 3 display you'll know that the screen map occupies 16K of RAM. The reason is that if every character takes 8 bytes or 64 bits and there are 25 lines of 80 characters each, it obviously takes 8 x 25 x 80 bytes (= 16,000) to store all the pixels. Each bit of this data can be set on or off (to represent foreground or background) but the problem with displaying more colours is that each pixel must instead be capable of being displayed in any one of the chosen number of colours.
Simple arithmetic therefore shows that to display 80 column text in, say, only four colours, would require that each pixel was represented by one of five values in memory including the background. Even if it was optimised this would take a minimum of three bits (binary values 0 to 4 inclusive) to store and since three bit arithmetic isn't exactly convenient, four bits would be used. This means that the necessary storage for four colours would be 64K bytes. That figure is the entire RAM of the BBC micro including the MOS's memory, and unfortunately shows the absolute impossibility of the idea. If you perhaps thought the 512 or even DOS Plus was the limiting factor, now you know. <More natural would be to allow for four colours including the background, requiring 32K memory, but still impossible with the BBC host – YP>
There's one final point. Before anyone says "But I have 64K of free sideways RAM", remember that this might not be true for model B and B+ hosts, so Acorn couldn't produce DOS Plus under that assumption. The result is that even if you somehow managed to devise a very clever scheme to intercept screen mapping (?), DOS doesn't pass the colour information across the tube anyway, so it still wouldn't work.
REDIRECTION – INPUT
At last! I've been meaning to talk about this for a long time.
One facility found in the BBC micro which is at first sight missing from DOS is a facility to *SPOOL (or some similar operation) screen output directly to disc to create a file of the display.
Such a facility would be just as useful in DOS as it is in the BBC micro. You could use it, for example, to create disc files of directory displays, perhaps for reading into a word processor for record keeping purposes. Alternatively you might have text files containing embedded Tab characters and so on, but which you would like to transfer to disc with all the codes expanded to give a formatted file just as it would be if printed.
Well, for those of you who didn't know, it can be done using a standard DOS facility called 'REDIRECTION' and it's very easy to use. First though (as usual) a bit of explanation about how it works.
Those of you who program in DOS will know that everything except the processor and main RAM is, or can be treated as a peripheral, including the screen and the keyboard. This is the philosophy that permits redirection. Of course the various device types which may be attached to a DOS system vary greatly in their control needs and capabilities, but the core of DOS, the BDOS, doesn't need to know about that. All the BDOS is concerned with is memory management and input/output at the most elementary level.
In simple terms, when you enter a command to type a file to the screen the BDOS makes a request through the BIOS (or the XIOS in the case of the 512) to get the required data. The BIOS actually does the disc controller handling, and the disc controller simply passes the raw data to the BDOS. When a sufficient quantity of data has been received (e.g. a 'cluster full') the BDOS then tells the BIOS to output the data to the standard output device, which is usually the screen, but it needn't be, more of which shortly.
What the type command does not specify in this example is the output device, but if you don't specify it, the console output device is used by default. Likewise the default console input device is the keyboard, which is used when it's not specified, but again this need not be so.
I'd guess most of you have at some time used a command in the form 'COPY CON filename' to create a short .BAT file or text file on disc. What this command really translates to within DOS is:
"Read data from the default console input device (i.e. CON, the keyboard) and write the output data to the default console output device (the screen), but also to the named file".
Without sensible device defaults DOS machines would be very difficult to use, so the standard start-up defines the console input and output devices, plus disc as the filing medium, the printer as the hard copy device, communications ports as auxiliary devices and so on. However, all these very different peripherals are just devices and the BDOS is equally happy to 'talk' with one of them as with another. For example, if you enter:
COPY FILE1.TXT FILE1.BAK
DOS will assume (unless you tell it otherwise) that the filing system is to be used for this operation and the file is copied from one disc file to another.
Likewise if you simply enter.
DIR
DOS assumes that the current directory list is to be output to the screen since no destination was supplied.
However, the way you tell DOS that a different source or destination is to be used is simply by inserting the "<" or ">" symbols respectively at the appropriate point in the command. An example will show this more clearly.
With a (writeable) disc in the current drive try entering:
DIR >CATALOG.TXT
and you'll see that the disc starts up in the usual way, but no directory list appears on screen. After a bit more disc activity the drive stops and the normal DOS prompt re-appears. You'll no doubt have guessed where the data has gone to and you're quite right. It has been re-directed into a disc file called 'CATALOG.TXT' (of course, with an example like this the catalogue might be instantly out of date, as you've just added a new file).
After trying that command enter:
TYPE CATALOGUE.TXT
which needs no explanation, and the directory list will appear on the default output device, the screen. The console output data from the original command was re-directed into the disc file, which is why it wasn't seen on screen, but the point is you can now edit or manipulate the contents of that file in any way you please.
REDIRECTED OUTPUT
OK, that explains redirected output, but what about input? Simple, using the left chevron, "<", the direction of the operation is reversed. Again an example will best explain it.
Suppose we have a program which, after loading, normally requires one or more lines of input. However, because the program's author was lazy and didn't want to process disc files he didn't provide the option for us to supply a filename to allow automatic reading of input data. The result: we normally have to enter everything manually every time the program runs.
No we don't! There's a much easier way! Let's call the program 'FILTER' for illustration, and let's also suppose that we have created a file containing all the lines we wish to feed to the program called 'COMMANDS.IN'. All we need to do to persuade DOS to supply the text to the program from the file, exactly as if it had been typed live on the keyboard, is to enter:
FILTER <COMMANDS.IN
which says to DOS, 'redirect standard input (i.e. the keyboard) to read data from the disc file COMMANDS.IN and pass the data to the program called FILTER.'
INPUT & OUTPUT
Ok, now let's extend our example. Suppose that FILTER reads the input and, after performing its operations, perhaps ensuring that everything is in lower case or that there are no embedded control codes, it displays the data to the standard output device (i.e. the screen). What we want to do though, is to capture a file of the output instead of just getting a temporary display.
No problem! Let's call the new file 'COMMANDS.OUT'. All we need to do is to enter:
FILTER <COMMANDS.IN >COMMANDS.OUT
and the input file, COMMANDS.IN, will be read, processed and written to the new output file, COMMANDS.OUT, automatically.
Of course, these are simple examples and this one may look a bit artificial, but even so I'd bet that virtually everyone who didn't know about redirection before can easily think of plenty of occasions when they wish they had known.
OTHER DEVICES
You'll notice that I've been talking about only the standard input and output devices in these examples. That's only because these are the most easily understood for the purpose of explanation. Re-direction can be applied to any device DOS knows about within the limits of common sense (e.g. don't try reading the printer).
Taking our last example again, if instead of creating an output file you wanted hard copy there are several ways you might go about it. You might create the file as above then print it as a separate operation, but if the file is only a means to an end that way is a bit long-winded. In some cases you might be able to use Ctrl-P to enable the printer while displaying to the screen, but you must usually be on the command line to do this. It frequently doesn't work within programs, so you must do the Ctrl-P before you begin, with the result that you also get the commands on your printout, not always an acceptable result.
Using redirection for other than filenames, or instead of the standard input or output devices is easy. The logical printer in the 512, for example, is known as 'PRN:', so to redirect output from the standard output device to PRN: the command would be:
FILTER <COMMANDS.IN >PRN:
If output to the serial port were required instead the command would be:
FILTER <COMMANDS.IN >AUX:
That's it, again I've run out of space, so I'll have to leave the rest of this subject until next month. In the meantime try a few experiments for yourself.