Master 512
Forum by Robin Burton
Beebug Vol. 10 No. 7 December 1991
I've had several queries lately about the GEM collection supplied with the 512. I'm not very familiar with these programs because, apart from a quick look now and again when I get a query, I never use them.
Once again we're indebted to David Harper who has spent some time investigating the system and its many foibles (i.e. bugs and quirks!) Before getting buried in GEM though, since it's a lengthy topic, I think mention of a couple of other points is in order.
REASONABLE REQUESTS
The first matter is one of good manners and common sense. I've not mentioned it for some time, and only a few are guilty. To the rest of you I therefore apologise for going through all this again.
If you have a 512 related problem you can write to me, c/o Beebug, and I'll help if I can. Obviously I can't promise a solution, especially if it's application specific, but I will try. However, if you'd like a reply you must supply return postage, an address label, as well as packing if you send discs.
It may seem a small point, but it's normal courtesy if nothing else, especially when you're using a free service. There are several hundred of you but just one of me, so help me to spend time on your problem, instead of writing your address.
Also, if you think I might be able to help please be absolutely explicit. I had a short letter a few weeks ago that said, in effect, 'I'm having problems running application XYZ in my 512, can you help me because I'm told it should work?'. Not much to go on, is it?
The sort of information I need to make sense of a question before I can start to think about an answer includes: What sort of problems? How far does the program get when you run it? Does any of it work? What happens when it fails? Are there any error displays? Which version of DOS Plus are you using? Have you tried both 1.2 and 2.1? Did you load a second COMMAND.COM? Which version of the package do you have? How much memory does your 512 have? What steps have you tried to fix the problem? Do you use floppies or a winchester? Have you access to a PC for program installation? Do you have the original issue discs?
With the right information I'll know what you've done and won't waste time duplicating your efforts or asking more questions.
For the query above I found, after three letters and much wasted time, that the application in question had been installed for a PC VGA display and it was the installed copy which didn't work on the 512! Furthermore the user didn't have the issue discs. I declined to help further because, quite apart from the fact that it was a lost cause, I can't help anyone to pirate software. If you have a problem with a package but you don't have a legitimate copy of the software, don't ask.
If you have a legitimate copy make sure you supply all the information you can.
All of the above plus anything else you can think of that might be relevant. Send a copy of the software and the issue discs (all discs returned) and I'll do my best. Dr. Philip Draper did it all exactly right, and he now has a working copy of TimeWorks DTP.
I don't keep copies of software for which I'm not licensed, or which I don't use, so it's virtually certain that I won't have a copy of your particular package. For example I don't have a single spreadsheet or database on my discs; not even shareware versions, because I don't use them.
I do appreciate how little support and help there is for 512 users, after all I've been one myself for about six years, and that's exactly why I try to help.
Thanks, I feel better now that's over.
TRYING SOFTWARE
On a related matter I had a letter from Ron Thompson a while ago outlining his procedure for trying new software. The rules are simple, but as the mention of reloading COMMAND.COM proved a few months back, it's easy to overlook basics, so here's a quick checklist.
If you're trying a program for the very first time, with no idea whether it will work or not, you can avoid risks and ensure you've tried everything by following the points below. All this assumes of course that the 512 will read the discs. If not, go to the last paragraph of this section.
If you normally use a winchester, don't. It's best avoided until you're positive the software isn't going to do something stupid. A corrupted floppy disc is a nuisance, but a corrupted hard disc is a minor disaster, even with good back-ups!
Ideally re-boot for each step, even if the system doesn't crash, and it's a good idea to use a copy boot disc with no AUTOEXEC file too, so as to to avoid any unusual or personalised setting up of your system. If any attempt fails, try the next option.
1. Try with DOS Plus 2.1 and nothing else loaded.
2. Try a second copy of COMMAND.COM.
3. Try with Problem Solver, if you have it.
4. Try a second copy of COMMAND.COM and Problem Solver.
5. Try with DOS Plus 1.2 only.
6. Try steps 1 to 3 using DOS Plus 1.2.
If you have a winchester you can also try the software from that for each of the above steps, but only so long as you're sure there won't be any ill effects and you have up to date backups.
If all that fails, you can try installing the program on a PC if you have access to one, but remember to choose CGA mono display if that's one of the installation options. You can then see if a copy of the installed version works. Ron put it quite neatly: if it still fails, give up.
GEM
Both of the main issues of the 512's DOS Plus, 1.2 and 2.1, have included a version of the GEM collection (General Environment Manager) on the issue discs.
Most 512 users will quickly move on to other applications that suit their needs better, but to the new 512 user the supplied GEM software can be extremely useful. There's both a word processor and a graphics package thrown in too, so without spending any cash you can actually run programs
Unfortunately, like numerous other programs in the 512's supplied software, the testing and debugging of the GEM collection leaves much to be desired.
I guess that Acorn's lack of interest in the 512 itself is directly reflected in the standard of testing applied to its supplied software. This is an unfortunate and less than encouraging introduction to the system for any new 512 user.
Like many applications, GEM needs to be configured for your own system before you use it fully and this is where you meet your first batch of problems. The program you need is GEMSETUP, but that's on disc 4, the miscellaneous disc, not on either of the two GEM discs. What's more, Acorn's so called 512 User Guide fails to even mention it (I wonder how many potential 512 users have given up at this stage over the years).
Assuming you discover the program at all, you now meet 'phase II' problems. Nine times out of ten GEMSETUP doesn't work! It seems to run OK, it even tells you it has saved your configured settings on the GEM start-up disc, so all appears to be well... until you try to run GEM, that is.
Apparently the program writes garbage to the disc more often than not, so GEM either hangs or crashes immediately you try to use it. It is true that if you repeatedly try GEMSETUP it might work eventually, but it's a slow and frustrating process since you'll crash the machine on every unsuccessful attempt. Before writing this Forum I tried it five times, with a 100% failure record (and a re-boot needed every time).
David has supplied me with information which allows the system to be set up and used much more easily, though as you might expect it means doing a bit of direct file editing.
The first impression gained from the GEM discs is usually 'what a lot of files!'. True, but you need be concerned only with one of them here. If you want to try to get GEM working properly don't forget to use copies of the issue discs (use 'copy an entire disc' in DISK.CMD). This month we'll look into what files are included and what they're for, then next month we can investigate changing the system.
GEM FILES
Like most applications, when it starts up, GEM expects to find certain files which indicate to the software how it should configure itself for the system in question. As is also common in many DOS applications, the file extensions in GEM are meaningful, each telling the system the purpose of the file.
Let's start with a look in directory GEMSYS for example. Three of the files are nothing to do with GEM system setup, these are OUTPUT.APP, OUTPUT.RSC and FORMAT.COM. The last of these is simply an 800K disc formatter, which GEM uses, so it must remain here. However, as I've mentioned before in the Forum, you can copy this file to your other working discs and use it as a direct means of formatting 800K (only) discs instead of going through the long-winded procedures in DISK.CMD.
The other two files mentioned above are pretty obviously concerned with output of some sort. The '.APP' extension tells us that OUTPUT.APP is a program file, much like an .EXE file. To be recognised in GEM as an executable program file though, the extension must be APP. By the way, don't think you can change any executable file extension to another type, you can't. Every executable file must be constructed in exactly the right way for its type, so the internal format of .COM, .CMD, .EXE and .APP (and any others in other systems) programs is completely different.
The RSC extension, as in OUTPUT.RSC, means resource. In simple terms an RSC file holds variables and strings which are used by the corresponding .APP program. In this case therefore, OUTPUT.APP gets some of its data and its text messages from OUTPUT.RSC.
You may also see a file called DEFAULT.OPT, which, as its name suggests, contains default options saved from OUTPUT.APP if the 'make default' command has been used. Now you know about these files you can ignore them from now on.
You'll also have noticed a number of files with a '.FNT' extension. These are all font files which contain the definitions of the various character fonts which can be used in GEM. When you get into GEM you'll find that you can change the current screen display typestyle by selecting different ones from a menu. These are all in the '.FNT' files.
Another file you will see (it's actually the one called in the GEM.BAT file) is called GEMVDI.EXE. This is clearly a normal .EXE file, and while the GEM portion of the name is obvious, the VDI bit isn't. It means 'Virtual Device Interface' (I know, "What's a virtual device?").
A virtual device is any input/output device attached to the computer. Notionally GEM can process input or output through any number of devices (screen, keyboard, printer etc.) and each of these might and usually does have completely different physical characteristics. So that any program can interface with a range of different hardware configurations in different machines, in DOS each device type has driver, a program which 'knows' the actual physical characteristics of each real device while presenting a 'standard' appearance to an application. Of course, the range of actual devices may also vary from system to system.
In effect GEMVDI is a further refinement of this idea, so that GEM need only ever talk to GEMVDI for all input or output. GEMVDI receives data in internal (GEM) format, but with a code which tells GEMVDI which device to send the data to. GEMVDI therefore ensures that the data is presented to the device driver in the correct format for the device type. When input is received it is initially passed to GEMVDI, which buffers it if necessary before passing it to the main application again in the internal format the application can process. GEMVDI therefore allows GEM to talk to physical devices without GEM needing to know anything about them. You can now forget about GEMVDI.
The file we're really interested in is ASSIGN.SYS. Obviously from the extension type it's a system file (as opposed to a program or data file), but what about ASSIGN. This is the file which contains the data which informs GEMVDI about the range of device drivers and fonts the system can use. As you might guess, it assigns the various device drivers to a particular type of input or output in GEMVDI so GEM can use them.
Sorry, we're out of space for this month. If you want to know what happens next, read next month's 512 Forum!