Master 512
Forum by Robin Burton
Beebug Vol. 7 No. 5 October 1988
This month Robin Burton looks at the vexed subject of just how compatible PC software is with the 512 coprocessor.
One of the most common questions that 512 users ask BEEBUG is "How can I tell if this package will run?" or "Why doesn't my new version of Lotus 1-2-3 run, when the old version did?". There is no general answer to these questions, but we will show here some of the reasons why not all DOS software will run on the 512.
The first question is "Do you have DOS+ version 2.1?" If not, and you have problems, this is step one. DOS+ 2.1 fixes all known bugs from earlier versions, and provides new facilities too, including a utility needed for running 'pop-ups' like Sidekick. STL PC+ users should note that 2.1 also has a modified memory map to cater for this too.
Remember, if you seek help from your Acorn dealer, you can expect a fairly short answer if you are not using the current versions of the software. Keep a copy of your old DOS+ version though, because a few programs will not run with 2.1, but do with 1.2!
Compatibility is, to say the least, a large subject, but all the problems finally boil down to the fact that the 512 is not a PC clone. Some areas can be identified, and while there's no magical solution, at least some of the time wasted trying unsuitable software can be avoided by asking the right questions. There are also one or two tricks which might help and we'll look at these too.
PROBLEM AREAS
Strictly, problems can be due to either the 512 hardware, or its DOS+ operating system, but really the two cannot be separated. A complete and comprehensive compatibility list would be the perfect answer, but this isn't practical. There is no complete list, and it would fill several issues of BEEBUG if there was.
A better approach is to understand why packages may or may not run, and to be aware of pointers which apply to selecting software, the aim being to improve the chances of getting it right.
The simplest question is "How much memory does a package need?" For some it's 640k (standard for many PCs), so unless you have expanded your 512, these are out. Check this first. A second point is that DOS+ takes about 90K more memory for workspace than MS-DOS, so even if software is suitable for a 512K MS-DOS machine, do not assume that it is bound to work on the 512.
Next let's take a look at the hardware. It is the easiest area to deal with in many ways, not least because it is a known quantity, and in any case there is little you can do about it. Not surprisingly, to talk about the hardware we must also involve the operating system.
THE DOS ENVIRONMENT
It helps to know that DOS interfaces with applications by means of a system of fixed memory locations and associated operating system calls. These provide access to the software functions and the hardware too.
You are probably familiar with the various types of OS call in the BBC micro, but in DOS they are slightly different. In Acorn terms the nearest equivalent to a DOS call could perhaps be described as a delayed action OSWORD call, because they do not happen immediately on demand.
As you may know, some DOS systems can run more than one application simultaneously, or can split processing between foreground and background tasks (this is where the 'SLICE' command is used). The point is that DOS cannot be called on demand as the BBC micro's OS can, because no program can assume that it has the machine to itself. In consequence programs do not directly control the OS or the processor.
Instead, ten times every second, DOS polls all the programs that are running and examines every one of these defined memory locations to see if any program requires operating system attention. If so DOS carries out the required action before returning control to the user programs. System calls implemented in this way are called 'interrupts', but should not be confused with hardware interrupts.
An application should, in theory, use interrupts to read or write data when connecting to the outside world. In this context the outside world includes all peripherals attached to the machine, and remember that in DOS both the screen and the keyboard are treated as peripherals.
The object of all this is that DOS should always look the same to every user program, and vice versa, regardless of the micro on which it is run. In addition, enhancements can be included in later versions of DOS without disturbing any of the existing facilities. The result is a fixed, standard program environment, which is where the high degree of applications compatibility comes from.
THE HARDWARE INTERFACE
The only remaining question is "How can DOS deal with the hardware, so that it can be installed in different micros, some with slightly, or as in the case of the 512, very different architecture?"
Just as there is a standard protocol for applications wishing to talk to DOS, there is a standard for DOS when talking to hardware. In fact communication between DOS and the hardware is indirect and depends on the 'Basic Input Output System' (BIOS), which is a separate DOS module, customised for each different machine by the hardware supplier. In this way DOS itself need never be altered to cater for hardware peculiarities. Only the BIOS is ever changed, and because DOS provides an interface between the BIOS and the user's program, the operation of the latter should be unaffected.
Unfortunately it is not a perfect world, and just as in the BBC micro, while 'legal' software uses standard calls, not all software obeys the rules.
As an example, you probably know that in the BBC Micro the WD1770 or WD1772 chip controls the disc hardware. You probably also know that this chip can be directly 'programmed' so as to by-pass the disc filing system to read or write non-standard disc formats.
Similarly, in a true PC there are various chips or 'plug in' cards, each dedicated to a particular function, each of which can be be programmed either by using the 'legal' interrupts, or by 'illegal' (but generally faster) direct coding, again just like the BBC Micro.
PROBLEM DEFINED
Now to the crux of the problem. Contrast a true PC with the 512, where every external device is on the other side of the Tube. This means that only software using legal calls has even a chance of working. The real devices are simply not there. In consequence, software which attempts to read or write hardware devices directly will fail. (There's just one exception, and we will come to that in a moment.)
Even with legal calls, correct functioning depends on the ability of the 512's DOS+ and BIOS (actually called the XIOS by Acorn) to suitably translate or amend these calls into something the BBC micro on the other side of the tube will understand.
The job of DOS+ in the 512, therefore, is to translate legal DOS+ interrupts into calls across the Tube, but it can only do this for operations for which the BBC micro has both the appropriate hardware and a suitable software routine. Having finally reached the I/O processor, calls can then be actioned. This is performed by some extra code that the 512 pokes into the I/O processor's memory.
In short, to operate correctly DOS+ programs must only use legal interrupts which, ultimately, the BBC micro must be able to service. This is what determines whether DOS+ software runs or not.
Clearly discs and printers can be dealt with reasonably, and suitable coding can be provided for elementary screen and keyboard handling, but software that tries to read or write hardware devices directly (or even legally for non-existent devices) must fail. This is why, for example, applications written for an Extended Graphics Adaptor (EGA) or a Hercules graphics card will not work. Even if DOS+ accepted the call, what could it do with it?
This gives the first compatibility pointer. The software you examine must be CGA compatible. Anything that demands an EGA, a Hercules or for that matter any other PC extension board will not work.
DOS DIFFERENCES
Now let's consider DOS in general, rather than the 512 or the BBC micro. Necessarily this is a simplification, but it will put things in perspective. The first point is that there are several members of the DOS family. The main ones are PC-DOS, used in IBM PCs, MS-DOS, produced by Microsoft and used by many clones, and DOS+, by Digital Research, a version of which is used by the 512 amongst others.
These are all similar enough to be obviously from the same family, yet at the same time they are different enough to cause compatibility problems with some applications.
A further complication, quite apart from the different implementations of DOS, is that for each type there may be several versions, hence the joke that not all IBM PCs are PC compatible. It depends on the version of DOS they use and the hardware devices catered for. As hardware has developed, DOS has been extended to cater for the changes.
Typically, applications written for a later versions of DOS will probably not function on an earlier version, even of the same type. Fortunately, the reverse is less common, and old software runs on later systems, more often than not (but not always).
512 SPECIFICS
DOS+ supplied with the 512 is compatible with all legally written software which runs with MS-DOS version 2.1, PC-DOS version 2.1, or CP/M(86) (the forerunner of DOS+).
This gives two more questions that you must ask when looking for new software. What type and what version of DOS is it compatible with? If it is not one of the above, you will probably have trouble.
Even when you are sure that DOS and the hardware is right, further confusion arises because some packages 'almost' run, but not quite, or most features work, but not all.
INITIAL SET-UP
Many DOS packages need installing, and have a special program for this purpose, but sometimes this is where the first problem occurs. Bear in mind that some packages will run on the 512, but cannot be installed on it. This can be because of initial defaults, or because 640k is needed for installation, though not necessarily when running.
The solution is to borrow a PC or clone to configure the system for the 512. Often the working system produced by this method can be used quite successfully.
Now to configuring itself. If there is a screen option for mono, choose it, if there isn't, select CGA. If there is a memory size option, select the one that suits the free memory given by 'BACKG'. Remember to allow for background printing, the alarm or the memory disc if you use them.
TRYING NEW SOFTWARE
When you run your new program, if things are still not right, try entering 'COMMAND' before loading the application. This re-loads 'COMMAND.COM', but the result is not quite the same as you get from booting the system. For some packages this seems to cure the problem.
Finally, when buying software, talk to people who should be able to help, like your Acorn dealer, but above all explain the situation. Any dealer worth his salt will understand, and allow a reasonable trial with an agreed refund or exchange if the package won't run. If he is not prepared to do this, the only advice is to take your money to someone who will.