Master 512
Forum by Robin Burton
Beebug Vol. 7 No. 8 January / February 1989
Robin Burton takes a look at an MS/DOS implementation of BBC Basic on the 512 co-processor.
BBC micro users have been spoiled. Not only is BBC Basic included with the machine, but it's acknowledged as an excellent implementation.
Many micros have no native language, a problem the BBC user hasn't been 'brought up' to expect. No one feels this more than 512 users. The fact that Acorn did supply BBC Basic with the Z80 only rubs salt into the wound.
|
Several implementations of Basic work on the 512, but even any resemblance to BBC Basic is virtually incidental. I was interested therefore, to be able to borrow a copy of BBCBasic(86) from M-TEC. This is an MS-DOS version of BBC Basic IV, and during the last month I've been trying it in the 512.
The first point to make clear is that this isn't a BBC package transferred to the 512. No-one should be surprised, but if you did expect an exact replica of BBC Basic implemented on the 512 purely to gain memory or speed, you'd be disappointed.
This isn't a criticism, but users of real BBC Basic have expectations (and facilities) that DOS users don't, so let's put things in perspective.
BBCBasic(86) V4.6 is an MS-DOS package which emulates the language that most BBC users cut their teeth on. The fact that, in the 512 with its DOS+ environment and very non-standard hardware it runs well is a credit to the code and its authors (one of these is Richard Russell who wrote the Z80's BBC Basic).
The acid test for a BBC Basic look-alike must be, 'can you transfer programs with little or no change and expect them to work?' The answer here is largely 'Yes'.
The main difference is simple. Remember that in BBCBasic(86) the screen modes are those of an IBM-PC, not a BBC micro, and there are few problems. The fact that a real BBC sits on the other end of the tube is irrelevant. I had to remind myself of this, because so much looks familiar.
IN USE
The software is on a single 360K disc, with over 500 pages of documentation in an A5 ring binder. This is extremely thorough and the information is well presented. Most BBC users will skim through quite large portions of it because so much is similar.
I would have liked the contents list at the front and normal page numbering. Finding items isn't easy – the first job is to find the contents list! It immediately precedes the excellent index, but I'd move the lot to the front of the manual and put dividers between sections to aid searches.
The first job was to make a working disc of the software, which was entirely without incident. The software and numerous example programs are all in a directory 'BBCBasic', so I transferred this to an 800K disc and copied 'COMMAND.COM' to the root directory. No other installation or setting up is needed – just 'CD BBCBasic' and off you go.
There are two ways to run programs. Firstly, you can run 'BBCBasic.EXE' to enter the BBCBasic shell. After this, with a few exceptions, most operations are much as they are in the BBC.
Alternatively, you can type 'BBCBasic <progname>' as a composite DOS+ command. The language is entered and the named program is chained. When it terminates you remain in the BBCBasic(86) environment. *QUIT exits BBCBasic and returns to the DOS prompt.
LOAD, CHAIN and SAVE are the same as in the BBC micro, except for the filing system. The extension '.BBC' is reserved for Basic programs, but can be omitted from commands. Native DOS commands are preceded by a * to run them. Discs can be catalogued by either '*.', showing BBC files, or '*DIR' for other extensions as required.
The cursor keys aren't the same as in BBC mode of course. Pressing the TAB key enters edit mode, while repeated presses provide the same facility as COPY. Left and right cursor then behave as you'd expect, while up or down cursor take you to the start or end of a line – very simple.
There's also a Basic editor which feels very much like Acorn's. Entering or amending programs by either means is very easy, and no-one could possibly have trouble with these facilities.
The graphics demonstrations provided worked well, and quite quickly using PC screen modes. Teletext emulation is included, with several setup programs for different PCs, but it requires an EGA which rules out the 512. That said, no-one would use 512 graphics in preference to the BBC's, so it isn't a factor in evaluating the package.
Among the programs supplied are the old PCW benchmarks. I ran these and was informed that my processor ran at 9.44MHz. Naturally I decided to find out how fast BBCBasic(86) programs do run compared with the real thing, and to test program compatibility at the same time.
COMPATIBILITY
Using MOVE I transferred three BBC programs directly to DOS with no changes, not even the names. I then used the supplied program (FCONVERT) to convert from tokenised BBC format to tokenised BBCBasic(86) format. Everything proceeded without a hitch. What's more the resulting programs worked.
There was, I hardly need say, no BBC assembler, graphics or teletext in these programs. They consist of moderately involved arithmetic and/or array juggling with some text output. In-line assembly is supported, but of course BBCBasic(86) doesn't handle 6502 assembler code, but 8086 code instead.
One program finds the highest prime number equal to or below any value up to 9 digits long. Another creates an integer array of 6000 elements and stores randomly ascending values in it. It then offers the choices of finding a value either by a serial search or a recursive dicotomic search (often called a binary-chop) – in which the list is repeatedly divided in half to find the required entry.
The third program creates a similar array, but stores completely random values in it. It then offers three methods of sorting into ascending or descending order before displaying the results in paged mode.
These were experimental programs, written to test the relative speed of various techniques using Cobol on mainframe systems. As such they make extensive use of integer arithmetic, procedures, REPEAT-UNTIL and FOR-NEXT loops and relational/conditional tests including TRUE/FALSE, all of which have direct analogies in Cobol.
I also transferred a program which opens a named file, reads it and filters the data, removing unwanted codes (double spaces, printer codes, tabs etc) creating a new, text only file.
All the programs performed perfectly and immediately, with not a single alteration. Even exits with Escape using ON ERROR and IFERR=17 worked properly, as did DIM, OPENIN, OPENUP, BGET/BPUT, multiple statements, NEXTs with implicit variables and so on.
PERFORMANCE
One unwelcome surprise was that there was no gain in speed. On the contrary, screen output was drastically slower, especially scrolling. I decided to organise some very direct tests of several aspects to isolate various program functions.
The results are tabulated (see Table 1), but the bottom line is that speed is a real disappointment all round. Apart from disc handling, which of course is quicker (except OPEN/CLOSE) because of the 800K format, almost everything took as long or longer than in my updated (but ancient) series 7 model B.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
There's no obvious reason why greater advantage isn't gained from the 512's 10MHz. After all, it's running at five times the clock-rate of the BBC, doing precisely the same job. The tube can't affect RAM or processor functions, and clearly doesn't in fact affect anything much anyway.
To investigate further, three tests were also run on an 8MHz Amstrad PC, with the following results. Test 1 – 263.37 seconds, test 2 – 2.58 seconds and test 5 – 50.00 seconds. These figures are worse than BBCBasic(86) and clearly demonstrate that neither the 512 nor DOS+ is at fault for the slow processor/RAM operations, (quite the opposite in fact) and it doesn't explain slow screen output either. What it does underline is the excellence of the original 6502-based BBC Basic.
On balance it's doubtful that BBCBasic(86) would outpace a model B or Master, definitely not if text output to screen is required. Don't think that the 512 isn't fast. The reasons are within the package, but I can't guess what they are.
The tests in BBC Basic were identical for each machine and all were entered as single lines. For tests 7 to 10 two sets of figures are given, the first for single density DFS systems and the second for the ADFS (and marked thus).
Tests 1 to 4 were pure memory and CPU operations, with tests 1 and 2 of the form:
TIME=0:FOR I%=1 TO 100000:NEXT:PRINT TIME/100
doing nothing but incrementing a loop, and the BBC is clearly faster. However, indexing an array seems faster in the 512, (tests 3 and 4) so this area is swings and roundabouts, depending on your program.
The much slower screen handling is shown by tests 5 and 6. I assume that legal DOS calls are the reason. The 512 supports direct screen updates and it's pretty clear why. Scrolling causes an enormous overhead, yet I used PC mode 7 for the tests, as it's the quickest (e.g. Test 6 in PC mode 3 took 151.78 seconds.)
When 26 times the data is displayed per line (test 6) the gap between the BBC and 512 reduces, but it's still huge (the 512 figures are not misprints, they both comfortably exceed two minutes.)
512 file handling used the 800K format, because it's the quickest. Comparing tests 7 to 10, it's clear that opening and closing files is where time is lost. Tests 9 and 10 separate the two operations. When a file is open (or large) DOS+ scores well over DFS and extremely well over ADFS. Not a surprise, but it only shows that disc handling isn't hampered by BBCBasic(86).
OTHER FACILITIES
Two versions of the interpreter are provided in the package, the standard one allowing programs of up to 64K, with page at &900 and HIMEM at &10000.
A second version, 'BIGBasic', utilizes all memory up to 640K, giving 265,392 bytes in an un-expanded 512, but the manual cautions that this version is slower! I tried test 1 again, and without actually using extra memory the time increased by five seconds. This is because the processor has to set up the segment registers as well as the actual address, and this all takes time.
The disc also includes utilities to 'unlist' and to compact programs, both operations making programs unlistable. There's a utility to produce ASCII files from listable programs or vice-versa, the equivalent of the BBC's *SPOOL+LIST and *EXEC, and a program to perform a *DUMP.
There are also two conversion programs (one for 64K Basic, one 'big' version) to produce run-only code. This includes all the necessary routines so that programs can be run as 'EXE' files without needing a copy of BBCBasic(86). A licence is needed if you use this to distribute programs, or if you use any of the package in more than one machine.
The manual suggests that run-only programs are the next best thing to compiled code, so I duly 'CRUNCHed' test 1 (see below) and converted it. The result was that the original 29 bytes expanded to over 31K, but it took exactly the same time to run.
NOTE: Because of this statement I also ran tests 1 to 6 using Digital Research's CBasic86. The results are shown in the CB86 columns, 'I' means interpreted, 'C' is compiled. All the compiled programs were smaller than 6K. The times show exactly how 'slow' the 512 and the tube really are if driven hard. It's not the hardware or DOS+ that slows things down (not even the screen!).
For curiosity I also tried test 1 in Basic 5 on an Archimedes with RISC OS. It took just 14.74 seconds.
CONCLUSION
BBCBasic(86) is an excellent implementation of BBC Basic in terms of compatibility and syntax. To be able to run (some) programs without altering a single byte is as much as anyone could hope for. Restrictions are predictable and attributable to hardware, DOS or the filing system. It can't be faulted on that score. It also proved robust and trouble free on the 512.
The documentation is comprehensive, and no one who writes Basic for the BBC micro, with even a rudimentary knowledge of the 512, will have the slightest difficulty in using this package.
Conversely, performance is a great disappointment, I expected to see speeds gains by factors of 2-3. If your objective is handling large amounts of data quickly BBCBasic(86) is not the answer. You do get the benefit of 512 disc handling, but that's equally true for any DOS package.
If your only concerns are larger quantities of data than your BBC micro can handle, but using a familiar language, BBCBasic(86) satisfies this, especially the large memory version. The penalty is that run times will probably be longer than on the BBC micro, especially when screen output is involved.
In spite of the obvious attractions of this package, I would strongly suggest that you investigate at least one other DOS Basic, ideally one with a compiler, before you make any decision.