CURRENT NOTES NOVEMBER 1987 D B A S I C F O R T H E S T Does the "D" Stand for "Dinosaur?" Review by Stephen D. Eitelman INTRODUCTION Another interactive Basic dialect for the ST has arrived. It is named DBASIC. The authors describe it as an old-fashioned Basic, very reminiscent of the Basic's we had/have on our 8-bit machines and refer to it as a "dinosaur" Basic. They then claim that the "D" was chosen more or less at random. Well... DBasic uses line numbers, permits multiple statements per line, contains its own operating system, has little or no "user friendly" ameni- ties like TOS and is indeed, very much like a five or ten year old, 8-bit Basic. In my case, I am familiar with Commodore 64 Basic and in general, I felt very comfortable with DBasic. The most significant feature of DBasic, how- ever, is its number crunching speed. This is the first Basic for the ST written entirely in assem- bly language, as opposed to a high level language (like C) and then compiled. DBasic achieves add- itional speed by being an "incremental compiler" rather than an "interpreter". The difference is that in an incremental compiler, each line is compiled when the [Return] key is hit instead of waiting until run-time to compile each statement. This way, a long FOR-NEXT loop, for example, only gets compiled once instead of every time the loop is executed. In addition to its speed, DBasic is very ac- curate. All floating point functions and calcu- lations are done in double precision. This means 15 significant figures are carried internally with 12 displayed. No particular attempt has been made by the authors to create a structured language; old- fashioned spaghetti code with lots of GOTO's is a natural with this dialect. The GOSUB function, however, does permit the use of labels in addi- tion to line numbers and the manual strongly recommends the use of labels to enhance read- ability. Additionally, the REM statement can be replaced with a semicolon to make the use of explanatory statements a little easier. An unusual marketing approach is being taken with DBasic. They essentially are giving away the software -- the package comes with a supply of labels to be affixed to the copies you give away! The authors feel that piracy is so difficult to stop that the trick to being successful is to create a de facto "standard of the industry" by having a large number of copies of their product in use. The software is not copy protected. The way they intend to make money is by selling the manual which is copyrighted thus making it illegal to copy. The manual is also bound, thus making it more difficult to photocopy. They have already given away a large number of manuals and software copies to user groups ST - 1 - ST CURRENT NOTES NOVEMBER 1987 for evaluation (a few thousand, I understand). While they may be successful in this approach, GFA Basic has a big lead which is going to be difficult to overcome. The authors claim that one cannot have a "luxurious" programming environment with lots of bells and whistles a la ST Basic and still get a fast language. They equate the situation to a 1953 Buick versus a sports car -- a soft luxurious ride that does not corner very well versus a fast but bumpy ride. The analogy seems quite accurate. ST Basic is certainly not very fast but uses the GEM programming environment extensively; DBasic is very fast, but the editor is about as simple an editor as one could have and still be useful. In their comparison of DBasic with other Basic's, the authors avoid any mention of GFA Basic or its companion compiler. GFA strikes me as the kind of compromise between speed and luxury that one gets with today's Detroit "sports sedan" - good handling, speed, and comfort. The authors also refuse to provide any telephone or written technical support. They claim the company is just too small to permit this. The only response available from them is through the order desk and the ONLY thing the order desk will do is take orders. They do accept bug reports by mail and if yours is the first letter to report a bug, you will get a thank you note and a new disk. DBasic is available only from the company: DTACK Grounded, 1570 Pacheco B-7, Santa Fe, NM 87501. Order desk: (505) 989-9576. The cost is $39.95 plus $3.00 shipping and handling. DBasic was written by engineers and seems best suited for number crunching applications. It is not really a good general purpose Basic. There is no capability to access the mouse; there are no sound commands; none of the GEM functions are available. This means no music, no dialog boxes, no menus, no alert boxes, etc. But I found the language to be the best combination of numerical accuracy and speed available on the market today (and the market for Basic's has really proliferated!!). In using DBasic, I found that while I felt quite comfortable with it, I was getting a large number of syntax errors when I began. This turned out to be a result of slight differences between DBasic and what I was used to. I found myself looking up just about every command to see what I had done wrong. It was usually quite apparent from the manual. I did, however, have problems tracking down two problems: * When I first fired up DBasic, I just tried writing a simple one line program 10 X = 50. I immediately got a syntax error. The problem turned out to be that the spaces around the equals sign are not permitted. This was not readily obvious and sort of turned me off initially: one really ought to be able to write such an elementary statement without recourse to the manual! * DBasic will absolutely not let one mix integer expressions with floating point expressions. There are occasions when it is not immediately apparent that this has occurred and yet a syntax error is ST - 2 - ST CURRENT NOTES NOVEMBER 1987 reported. It only took me about three mistakes of this type to immediately suspect the problem every time a syntax error was reported later on! There are commands for converting between integers and floating point variables, FIX and FLT. Loading DBasic into the ST consists of in- serting the program disk into drive A and turning on the power. Once DBasic is loaded, the user is greeted with a simple menu. Selecting DBasic clears the screen and one is now ready to begin programming. MANUAL The manual consists of 281 pages divided into two major portions. The first is a description of the design and major characteristics of the language and covers the internal workings of it. It is easy reading, entertaining and highly use- ful for the most part. The second portion is an alphabetical listing of each of the commands. The listing describes what each command does, its syntax, gives an example, cautions and notes. It is quite thorough. There is no index, but by and large, I found the table of contents to contain sufficient de- tail to get me to where I needed to go to answer the question. The manual contains no error listing. But then, what real good has an error listing ever done? Yes, when an error is reported, most Basic's allow one to find the error message in the list, but generally, there is still no hint as to what caused the error. So why bother? I'm with the authors of DBasic on this one! My biggest complaint about the manual is the lack of discussion on sequential files and random access files. If DBasic is to be some sort of standard, then the manual ought to discuss the kinds of data files that most of us have become accustomed to. The language itself does not make it obvious how to implement simple sequential files or random access files, although it is probably possible, given the large number of apparently flexible file handling commands. The commands are, by and large, unfamiliar, so I feel there should be some equating to more conventional file commands. My other criticism of the manual is rather general. The author spent too many pages dis- cussing his pet peeves and philosophizing on how the programming world ought to be. While this was very educational in many instances, it got a little tedious after a while. The section on floating point accuracy in particular really needs a hard-nosed editor to go over it. After plowing through all his table-pounding ranting and raving, I still did not know how many decimal significant figures to expect. In fairness, he does say that 12 significant figures are printed out in the alphabetical listing under PRINT but this took me a while to find. Note that 15 significant figures are maintained for internal computation purposes. If more than (or less than) 12 places need to be printed out, the command CHR$(x%) is available for this purpose. DBASIC OPERATING SYSTEM As mentioned earlier, DBasic does not use TOS or GEM. They are much ST - 3 - ST CURRENT NOTES NOVEMBER 1987 too slow and, in particu- lar, both DBasic and TOS require use of zero page in memory. DBasic has its own disk formatting program that is very similar to Dave Small's Twister. The sectors are staggered so that entire revolutions of the disk are not wasted getting the next sector under the read/write head. Sectors are 1K long instead of 512 bytes. This results in about a 20% increase in the space available on the disk. DOS is also speeded up by a recording arrangement that minimizes file fragmenting, so that again, the head does not have to travel all over the disk finding bits and pieces of the file. The penalty for this arrangement is that some small amount of space will not be used on the disk. But this is essentially no penalty at all. A COPY program is available for copying the DBasic program disk or DBasic files. There is also a file called DISKPRIM (for disk primitives) that consists of five subroutines that are in- tended to be incorporated in other programs. These subroutines allow one to read and write TOS disks and read and write DBasic disks. In theory, one should be able to import files written in ST Basic under TOS into the DBasic format so as to avoid having to re-type a long program that was originally prepared as an ASCII file under TOS/GEM. I took a quick look at DISKPRIM and made one attempt to actually write a program to do this. It was a failure! And Frank Sommers, our 16-bit editor, insists that I get these articles in on time, so I had to stop fooling around and get the article written! Therefore, I cannot say with absolute conviction that conversion between ST Basic and DBasic is possible, but it certainly would enhance the usefulness of DBasic if it is. SPEED Just how fast is DBasic in comparison with other available Basic's? This question gets difficult to answer due to different lengths of numerical words. The only really meaningful com- parisons should be done with other interactive Basic's that have the same word length. Those requirements reduce the list of comparisons to zero! So we end up having to compare apples and oranges to some extent. The most significant comparison for me was to run the LDW compiler (which should be faster by virtue of off-line compilation and linking) in double precision with DBasic (which always runs in double precision -- so both tests use the same word length) in a test involving the cosine squared of an index running from 1 to 10,000. Believe it or not, DBasic beat the pants off LDW! DBasic was over 5 1/2 times faster. There is still some room for questions here, however. DBasic claims to use a mantissa of 48 bits; LDW uses 64 bits in their "high precision" and 48 bits in their "ordinary" double precision. So the test should have used LDW's "ordinary" double precision to keep the word lengths the same. When I did this, however, the resulting answer was only good to four significant figures. I finally chose to compare the versions that gave me the same number of correct digits. This required the use of LDW's "high precision" 64-bit mantissa. The time was correspondingly slow. The time for LDW 48-bit mantissa test was 12.1 seconds, somewhat faster than DBasic, but the answer was contaminated with nine digits of random numbers! The results of my speed tests are shown in the table below. As the table shows, DBasic is faster than practically everything for ST - 4 - ST CURRENT NOTES NOVEMBER 1987 most tests, regardless of length. In the tests where DBasic lost, the result is due to longer word length. This is especially true for the creation of 1,000 random strings - DBasic allocates a word length of 255 bytes by default. Although this can be changed, I didn't bother. SPEED TESTS (Times in seconds.) =============================================== LDW ---GFA BASIC--- BASIC ST Com- Inter- Test DBasic Ver 1.1 Basic piler preter ======= ======= ======= ======= ======= ======= A 20.1 114.5 38.0 11.5 15.5 B 2.2 8.2 251.0 3.0 13.0 C 3.0 2.9 31.4 3.3 6.1 D 10.5 6.5 69.0 3.7 7.2 E 7.7 21.6 304.0 7.8 23.5 F 5.9 40.2 105.0 34.1 34.3 =============================================== Test Description: A: 1<=I<=10,000 y=cos(I),x=y*y (Fast cos sq) B: BYTE magazine Sieve, 10 iterations, n=2,047 C: BYTE magazine Calculation benchmark D: Generate 1,000 random strings E: Sort random strings F: Print sorted strings to screen The authors show their own series of benchmarks in the benchmarks program on the disk. It is significant that DBasic also beats up badly on MegaMax-C and Mark Williams C with the exception of empty FOR-NEXT loops and integer calculations, neither of which bear much resemblance to the real world. The vaunted superiority of C as a programming language for all seasons has dimmed considerably in my humble estimation. BUGS I didn't find any that are really serious. The only one I found is just sort of a "peculiar- ity": there was an occasion when I wanted to use the expression (Y-X^2). This caused an error message "Illegal power operands" to appear. When I changed the X^2 to X*X, the problem disappeared. The complete line was: 160 X1=X*COS(A)-(Y-X^2)*SIN(A). This line was in a program to generate mathema- tical "chaos" as described in the July 1987 issue of Scientific American, "Computer Recreations". A fascinating subject, by the way. CONCLUSION If you want a Basic that has the "look and feel" of your comfortable old eight bit Basic and that has far and away the best combination of speed and accuracy in ANY language available for the ST, get DBasic. It has some rough edges and does not use GEM, but is just ideal for number ST - 5 - ST CURRENT NOTES NOVEMBER 1987 crunching. Even if number crunching is not your primary need, it is a great Basic for weekend programmers who just want to get something working without a lot of difficulty and want it to run as fast as possible. For about $40 plus $3 S&H, I think DBasic ought to be in every ST owners software library. ST - 6 - ST ental compiler" rather than an "interpreter". The difference is that in an incremental