Previous | Index | Next

Master 512 Forum by Robin Burton
Beebug Vol. 10 No. 8 January / February 1992

More on GEM

This month we'll carry straight on from last month. We've looked at the problems of setting up the 512's GEM system and some of the various file types on the GEM disc. Now we'll get on with ASSIGN.SYS, which is where the GEM configuration data is stored.


ASSIGN.SYS is the file that GEMVDI reads to find out about the available device drivers when the system is started, so if we can present the right information in the correct format everything should work correctly.

Fortunately ASSIGN.SYS is only a text file, containing a list of device drivers and files each driver can use, such as font file names. Admittedly the information is in a particular format, but it's not difficult and so long as you're careful, changing the contents of the file isn't difficult either.

To do this you need to use a text editor, but make sure it's one that doesn't add any 'extras' to the file, such as format control codes and line-feeds, or one that insists that every document is at least a page, including headers and footers and so on. If you have no other preferred program, GEM Write is quite adequate for the purpose, but make sure you turn 'Document mode' off (in the format option in the page menu). If you're more familiar with ED, or any other text editor, use that instead.

Before you start it's a good idea just to have a look at the file, so that you'll get an idea of how its contents are stored. You can do this either in your editor, or by simply using the DOS 'TYPE' command before you start editing.

You'll notice that ASSIGN.SYS contains two different types of line. The first of these always starts with a two digit number, of which the second digit is always '1'. This indicates that the line defines a device driver, and you'll see that the number is followed by the name of the driver in question, which must be one of the files present on the disc. You'll also notice that there's no file extension in the name, because it's always '.SYS' for device drivers.

After this is a semi-colon, which is a separator indicating the end of the driver definition, so the remainder of the line is a description which is ignored by GEMVDI, but it is displayed by GEMSETUP as you'll have noticed if you've tried it. You might as well include a description for your own information, in case you ever need to repeat the exercise, perhaps as a result of changing your printer, for example.

Following the line defining each of the drivers you'll see a number of lines which define the various files (if any) that the particular driver can use for input or output to the device in question. The format of these lines is equally simple. They all start with a couple of spaces to indent them slightly. This isn't functional, but it does make the file a bit easier to read, so you might as well include them yourself. Next is the name of the subsidiary file which the driver can use, and you'll see that many of these are font files with a '.FNT' extension – note that the extension is specified this time. After this is another semi-colon, followed by a description of the file which again is ignored by GEMVDI. Again it's useful to include these for future reference.


Before we examine the usable device drivers in detail, here's a list of all the devices which can (theoretically) be defined, together with their GEMVDI type number.

01    is the screen driver. In a real PC this would be the driver for a particular type of graphics card, the 'plug-in' circuit that controls screen output. The screen driver in the 512's version of GEM is of course a 'special' because of the BBC's hardware.
11   defines a plotter device driver.
21   is the printer device driver.
31   is the METAFILE, more of which later.
41   is a camera device driver.
51   is a tablet device driver.
61   is any other device driver. These could, for example, be application supplied, for specialised input/output hardware.

Of these we can ignore camera, tablet and miscellaneous. No such drivers are supplied with the 512's GEM and the XIOS software doesn't support such additional hardware anyway.

As you'll have seen in the original ASSIGN.SYS file, two of the device driver lines are followed by a list of the specific definition files which can be used for that device. Using this information, together with a list of all the files supplied on the disc, it's therefore possible to amend ASSIGN.SYS to contain the correct files for your system.


The most obvious need is a screen driver, and there are two options in the 512, one each for controlling the two types of display of which you're probably already aware. These are two colour 80 column text modes and four colour, 40 column graphics modes.

The two screen driver files are called 'ACORNBW.SYS' and 'ACORNCOL.SYS', so I hope no explanations are needed for the names. However, there is a later version of ACORNBW.SYS which can be used to some small advantage (see later), but the sharp eyed will have noticed that ACORNCOL.SYS isn't present on disc 2. Guess where it is!

By the way, you probably know that GEM is mouse driven, but in this version the mouse driver is included in the screen driver, so there's neither a separate mouse device in ASSIGN.SYS, nor do you need a mouse driver program (and no, you can't use this mouse driver elsewhere).

Using the version of ACORNBW.SYS on disc 2 is all right most of the time, but it displays everything on a glaring white background, which can be a bit wearing on the eyes after a time, to say the least.

You may already have guessed that the later version of ACORNBW.SYS is tucked away out of sight on disc 4, along with ACORNCOL.SYS.

There's no mention of this in the original Acorn 512 User Guide, but if you were a later purchaser of your 512, Acorn did include an extra small manual which covered some additional points briefly (though this isn't one of them).

The later version employs a grey background, much better for minimising eye-strain, but there are other benefits too. You'll find that the calculator is better presented in this version, but furthermore, as the original disc 2 version displays the date in the clock in white, effectively there is no date. It is displayed, but you can't see it, so that's not much use! On the grey background of the disc 4 version the date of course becomes visible. OK, that's the good news, what's the bad?

You may already have guessed that the later version of ACORNBW.SYS doesn't work properly. As it's supplied neither the clock nor the calculator work at all (perhaps that's why it was 'hidden' on disc 4!).

In fact there isn't much wrong with the file and it can be corrected quite easily. It's just another typical example of the sloppy and careless way much of the 512's supplied system software was put together. Was some of it ever tested? It's hard to believe it was, but if so, how come so many silly bugs escaped notice? The problem is that the file is a bit too short, 20K short to be precise. Yes, that's twenty kilo-bytes, the sort of minor slip-up anyone could make!

The easiest way to put this right is in 512BBCBASIC, though if you don't have a copy you can 'MOVE' the file to the BBC and use the real BBC Basic to do the job, then 'MOVE' the new file back to DOS afterwards. The following short program will do the trick.


As you can see, all this does is to open the file for update, position the file pointer at the end of the file and extend it by 20K, writing the extra portion as zeros. Note that if you need to move ACORNBW.SYS to the BBC to do this job, you'll have to rename it in both directions and of course the name in the Basic program must be altered to suit. If you have only floppies either temporarily copy ACORNBW.SYS to your 'MOVE.EXE' disc, or alternatively put 'MOVE.EXE' in the RAM disc and call it from there, because you'll need both floppies for the 'MOVE', one for DOS and one for your preferred BBC filing system.

Assuming drive B: is the current DOS drive and that the disc contains both MOVE.EXE and ACORNBW.SYS, with a DFS disc is in drive 0, the command would be:


to move it to the BBC. Then, after shutting down the 512, run the Basic program to amend the file. Next, re-boot the 512 and, with the same disc assignments, use:


to move it back again. Of course, ensure the DOS copy of the file is read-write before you do this with:


if necessary, otherwise the move back to DOS will fail with 'Access denied'. If you prefer to use ADFS in BBC mode just replace '-DISC' in the above two commands with '-ADFS', but above all, do not include the '$' in the BBC path. MOVE doesn't like it, most especially in ADFS!

Having modified the later version of ACORNBW.SYS simply copy it to your working GEM disc and it will work correctly, clock-date, grey background and all.


The colour screen driver doesn't need any special treatment (except of course to find it). Copy it to your working 'GEMSYS' disc from disc 4 if you want to use it, but remember that although it may be useful in GEM Paint, it's not much use for text applications. You'll also notice that 'COL.SYS' is 20K larger that the disc 2 version of 'BW.SYS', so lack of memory can also be a problem if you don't have an expanded 512. In any case, unless you're one of the few with a colour printer, colour isn't really much use even in PAINT, unless you're happy just to view your masterpiece on screen.

By the way, beware! Acorn's extra leaflet warns you that the colour driver isn't supported by Acorn, so remember if you use it, you're on your own if you have problems. Now that's a sobering thought!

80 column text is quite possible with the colour driver, but the text is of very poor quality, because there's a straight tradeoff of half the character resolution for twice the number of colours. However, if you do use colours in PAINT remember that you can change the four colours that are displayed with the 'COLOUR' command (on the boot disc). The format is:


where 'A' is the physical colour number, from 4 to 7, and 'B' is the colour you want it to become, which is between 0 and 7 (unless you want flashing colours!). Note also, if you change colours again later in the same session, that the colour number for 'A' remains the same as the first time.

There is one other oddity in colour displays which might have you scratching your head. Because of the (relatively) low BBC screen resolution in mode zero, two stored GEM pixels are combined into one screen pixel for display. You can see the real pixels if you use the microscope tool, so you can check that all is well, but frequently the normal size image may not appear quite as you expect. For example, a regular pattern of alternating pixels in two colours seen through the microscope as they should be, will appear in the normal-size image as a continuous block of one or other colour.

What happens internally is that each row of eight stored GEM pixels is squeezed into four BBC pixels for display purposes. If, anywhere within the eight 'real' pixels there is even one pixel in 'colour 0' then the pairs of pixels are 'ORed' together to produce each display pixel. However if there is no colour 0 pixel anywhere within the eight, then the pairs of pixels are 'ANDed' together to produce the physical display.

Because of this peculiar method of squeezing two real pixels into one displayed pixel, the effect of changing just one stored pixel can sometimes be equally peculiar in the display. However, there's nothing you can do about this oddity, just be aware of it.

Once again we've run out of space this month, so screen and printer fonts will have to wait until next month. See you then.

Previous | Index | Next

About the Master 512 | Bibliography