Master 512
Forum by Robin Burton
Beebug Vol. 7 No. 4 August / September 1988
Robin Burton presents another collection of hints for users of the 512 coprocessor.
In this month's forum we will expand on a couple of points from the example batch file given last time, and then look at a feature of the 512 that many owners are quite unaware of.
COLOUR
It seems that there is quite a lot of confusion among new users of the 512, as to the use of colour displays. The 512 emulates a CGA (Colour Graphics Adaptor), and a CGA display in 80 column mode can use sixteen colours, so you might hope the 512 will do this too. Unfortunately this is not so: in 80 column mode the 512 displays only two colours.
The 512's CGA emulation is limited to ensuring that the multi-colour output from an application is translated to two colours, while still producing a legible display. For the reason behind this look no further than the BBC's two 80 column screen modes (mode 0 and mode 3). Both of these are two colours only.
The colours can be any of the BBC's 16, but only two at a time, one for the foreground, and one for the background. In practice, only the non-flashing colours in the range 0 to 7 are of any real use.
Even if your software includes sixteen colours in its options, and you have seen it use several colours and 80 columns on a PC, the 512 still displays only two. The normal choice of colours is white text on a black background, although this can be changed by using the 'colour' command, which performs a VDU 19 to change the screen colours.
The 'colour' command takes two parameters: the first indicates whether the colour to be changed is the foreground colour (1) or the background colour (0), while the second is the number of the colour to be used. The second parameter can be in the range 0 to 15, and is the physical colour number. These are listed in the Beeb's User Guide. The 'colour' command works by simply sending the necessary VDU codes to the Beeb to bring about the colour change. For example, to display green text on a blue background, the two commands required are:
colour 0 4 - Change the background to blue
colour 1 2 - Change the foreground (text) to green.
It does not matter what the colours are to begin with, they will be changed regardless. Another thing to note is the use of spaces, rather than commas, to separate parameters. This is standard practice with DOS+ commands. To set the colours for GEM, use 2 and 3 instead of 0 and 1 for background and foreground respectively.
If you are using GEM, it is possible to have a four colour display, by installing the four-colour screen driver supplied on the miscellaneous disc (number four). This is done using the GEM set-up program and is described in the 512 User Guide. The main drawback of this four-colour driver is that there is a straight trade-off of screen resolution against colour. That is, you double the colours, but you halve resolution. Although 80 column text can be displayed, it isn't suitable for word processing, even with GEM Write, owing to the poor character resolution.
The 'colour' command, when used with the four colour option, is similar except that there is no foreground or background as such. Each of the four colours is referred to by a number between four and seven. For example, to change the first colour (number four) to cyan (BBC colour six), the command is:
colour 4 6
If you later wanted to change colour four, currently cyan, to blue, the colour number does not change, so the command would be:
colour 4 4
THE RAM DISC
Next we will take a look at the RAM disc, which is an area of memory set up to behave as if it were another disc drive. I suggested that this could be used with batch files to avoid disc swapping. In fact it can be useful with many programs, with or without batch files. Some implementations of DOS have a (semi) permanently configured default RAM disc which appears automatically when the system's loaded. This is not possible on the 512, but given its limited memory this is just as well.
Memory is at a premium on the 512. As it is, many programs will not run with less than 640K of memory. You therefore have to be very careful about how much memory you allocate to a RAM disc, as this will reduce the amount of memory available to programs. Some programs need all, or most, of the available RAM, for loading, even if they can cope with less memory when running. These applications will fail with a RAM disc installed, so you must experiment with your own jobs. What works for one may very well not suit another.
While we're on this topic, if you wonder why some programs run quite happily in a 512K MS-DOS machine but won't run in a Master. 512, the reason is that DOS+ takes about 90K more RAM than MS-DOS.
To set up a RAM disc is simplicity itself; even the User Guide explains this well enough. It is what it doesn't tell you that matters. The command is 'memdisk', followed by the number of kilobytes that you want to allocate. For example, to create a 20K RAM disc you would enter:
memdisk 20
If you use a RAM disc you can include its setup commands in your startup batch file. Include the command to create it, together with suitable copy statements to put into it the often needed transient command software, like 'fset', 'chkdsk' and your batch files. When these are called, you wont have to re-insert the systems disc, nor do you need a copy of them on every data or applications disc. Try these commands with the systems disc in drive A – you will soon get the idea:
backg
memdisk 60
copy a:fset.cmd m:
copy a:chkdsk.cmd m:
dir m:
backg
The two 'backg' commands show the memory reduction caused by the RAM disc. The bad news is that memdisk is a program, and it uses memory. As you will see from your screen, the total for a 60K RAM disc is about 150k. The 90K overhead does not vary, so even a 20K RAM disc needs 110K. Bear this in mind when you decide on the suitability of a RAM disc for your particular job.
Important points to note about a RAM disc are that after it is created you are stuck with it until the system is re-booted. You cannot remove it or change its size even if it is empty. This is a real nuisance, and definitely belongs on the bugs/omissions list, although in fairness this is peculiar to neither the 512, nor even DOS+.
Another point is, no matter what size you allocate, the result is always an even number. If you need a 31K RAM disc you must allocate 32K. An attempt to create it as 31K will be rounded down to 30K by the system, which is perhaps not enough if you are being careful with the size. The final point is that your RAM disc is always drive M.
It is not all bad news, however. With the right applications a RAM disc can greatly speed up operations that call for the loading of transient commands, like 'fset'. They only take a few seconds really, but it seems like an age while you wait. A good many applications do not need all the RAM, and some will adjust to use what's left (within reason) after the other allocations are taken.
For example I use PC-Write, which is quite happy to co-reside with a 100K RAM disc while editing a 60K document in memory, adequate for most purposes. If the RAM disc allocation is 128K, PC Write adjusts by reducing the maximum document size down to about 42K, and so on.
Unless you have a hard disc, a RAM disc can save you time, but remember that it is not a real disc. A power cut or any machine failure is fatal, as the contents are lost. Use it for temporary storage, but NOT for critical data files.
MONITORING GOINGS-ON
We will round off with a quick look at the monitor built into the DOS+ boot chip, and the subject of segmented memory. This is the program that gives the * prompt, seen when the 512 is switched on but not booted, or when BREAK is pressed before switching off the 512 or entering the 'NOTUBE' command. This is really only for interest, as it is a tool for patching or debugging. Far better general user development tools exist, even among the free ones in the public domain.
To see the full range of the monitor's commands, from the * prompt type:
H.MON
and press return. It is quite limited, but it does provide the ability to access the BBC's star commands as well as the opportunity of getting into the 512's memory directly.
The first command, 'd', allows an area of memory to be dumped, in hex and ASCII.
The command shown as 'dos' simply enters the boot routine to load DOS+.
'f' allows a specified area of memory to filled with a given byte or word value.
'go' is is for debugging specific areas of programs, by supplying the address from which execution should start.
'mon' enters the monitor. This allows the monitor to be re-entered from within DOS+ by typing:
star mon
's' means set. This is the 512 memory editor. You can move around using the cursor keys, and directly key in values as required.
'sr' is a memory search routine allowing a given string to be located in the 512, again used for debugging and testing.
Finally 'tfer', the most interesting command, transfers memory across the Tube in either direction. The parameters are the address in the I-O processor (the BBC) the address in the 512, the length of data to move and R (read from the BBC), or W (write to the BBC) for the direction of transfer. If you feel adventurous try transferring an area of (used) 512 memory to the BBC, then *SAVEing it to disc, when you find 'putfile' or 'move' too boring.
Even more useful, you can call 'tfer' from Basic. Using a simple memory management procedure and 'OSCLI', you could archive up to half a megabyte of BBC Basic data in the 512. It gives a whole new meaning to 'sideways' expansion, doesn't it?
SEGMENTED MEMORY
You will notice that in the help list for the 512 Monitor, addresses are listed as <segment:offset>. What this means is that the addresses should be specified as two values, separated by a colon, rather than the normal single value. The reason for this is that the 80186 can address up to 1 Mbyte of memory. This requires a twenty-bit address, but all the registers used in the 80186 are only sixteen bits wide. To allow the full address range to be accessed using the value from a single register, addresses are made up of two parts – a segment number and an address offset. The processor takes these two parts and forms a twenty bit address by multiplying the segment number by 16 and adding the address offset.
When we specify addresses for use by the Monitor, the segment number is given, followed by a colon, and finally the address offset. So, for example, an address of &12345 could be specified as 1234:5, which means the 5th byte in segment &1234. There are however, other ways of specifying the same address. For example, 1233:15, because &1233*16+&15 is &12345.