INSIGHT: Atari

---

Bill Wilkinson

It's tidbit time again this month! I love saving up strange, exotic, or frustrating facts and then dumping them on you all at once.

Oops
Before I do anything else, though, let me quickly fix the big boo-boo in my January column or I will be inundated with threatening letters. In the second assembly language listing there, the one which purported to show you how to output a character to any channel, there are two lines in error. Lines 340 and 350 were given as using a STX instruction. The correct lines are as follows:


    I apologize now if I managed to destroy anyone's hard work. And since I goofed in January, it's only fair to show my ignorance this month.

Hide And Seek
The first of the tidbits this month came to me in the way of an innocent question from Roger Bocek of Campbell, California. He had stopped in at our office to pick up some software, happened to run into me, and said, "Say, I've been meaning to ask you. Why does DOS use three sectors for its boot area when it uses only about 200 bytes of boot code?"
    Five minutes later, after rummaging through the listing in Inside Atari DOS (from COMPUTE! Books, of course), I came up with the brilliant answer: "I dunno." But I always like to find a use for everything, even my own ignorance.
    As we have discussed in this column many times in the past, when you ask BASIC to do I/O (Input/Output) to or from most devices attached to your computer (particularly the disk drive), what actually happens is quite complex. BASIC interprets your request into a call to CIO (Central Input Output), which in turn determines what device you are using and vectors to the appropriate driver routine. We assume here that CIO accesses FMS, the File Management System for the disk, usually called DOS (Disk Operating System).
    Finally, then, FMS makes a call to SIO (Serial Input Output), the routine which does the actual physical reading and writing to the device. In the case of the disk drive, this involves the actual transfer of a single sector of 128 bytes (or 256 bytes in non-1050 double density).
    Most BASIC programmers seldom-if ever have need to read or write a physical disk sector. Most avoid writing because it is dangerous, since disturbing the format of portions of a sector can destroy DOS's ability to manage the disk for you. (Reading a sector, though, can be informative, especially if you are trying to either understand DOS or find lost information.)
    On the other hand, some programmers like to hide things on a disk. Perhaps high game scores, a password, or some sort of software protection. The best place to hide such information is someplace unknown to DOS.

An Extra Sector
Now, the fact that standard Atari DOS (version 2.0S and its derivatives, including OS/A+ and DOS XL versions 2) leaves sector number 720 available has been documented before: DOS manages sector numbers 0 to 719, but the disk drive understands only sectors 1 to 720. DOS has been fixed to think that sector 0 is always in use, but sector 720 remains outside its ken. Many programs, including some found in old issues of COMPUTE!, have read and written data directly to sector 720.
    Lo and behold, thanks to a quirk which began who knows how and where, sector 3 is also free for this kind of use! It is the last sector of the traditional three-sector boot process. But for some reason lost in programming legend, it turns out that none of the disk boot code used by DOS is present in sector 3: sectors 1 and 2 contain all the boot that is needed. So, if you are looking for another 128 bytes of hidden disk space, you now know where to find it.
    A word of warning, though: If you erase, write, modify, or rename the DOS.SYS file, sector 3 will automatically be rewritten by DOS (it thinks it needs to reestablish the boot code). So, if you choose to use sector 3 for your own purposes, be sure to do so on a disk which either never receives a DOS.SYS file or which has one that you feel is reasonably permanent.
    I have not included a program here to access sectors directly because the technique has been shown many times, many places before. For example, Mapping the Atari (COMPUTE! Books) gives some helpful hints, and the Atari technical manuals go into SIO calls in some detail. If enough of you write and request a column on this topic, though, I may present more here in the future.

More Hide And Seek
Many game programmers like to hide their signatures in their work, often to the consternation of their employers, the game manufacturers. Famous examples include the message evoked from Super Breakout (the Atari home computer version) when you push CONTROL, SHIFT, and I at the same time. Or how about the power dot in the old Atari VCS Adventure game, which got you into an otherwise inaccessible room? In fact, the practice is so widespread that some players spend hours looking for these hidden messages in each new game, even the games that don't have any.
    Well, it turns out that game programmers are not the only ones who like to get their ego stroked at the same time they put one over on management. Paul Laughton, the prime programmer behind Atari BASIC and Atari DOS (and Apple DOS and ... but that's another story), told me of one signature that even got into some of Atari's operating system ROMs.
    If you want to see this signature, you'll have to find a 1200XL and be patient. Simply remove all cartridges, disconnect all peripherals, and turn it on. Push the HELP key to get to the self-test program, and with SELECT, choose all tests before pushing START. Then wait. The self-test program will cycle through the ROM and RAM tests and the sound register tests before it gets to the keyboard test.
    Now how the heck can you have a meaningful keyboard test which is self-running? Answer: You can't. To really test a keyboard, someone should hit at least some keys. Nevertheless, the program makes a valiant effort to pretend that it is hitting some random keys. Or does it? Aha! If you look fast and carefully, you will find that the keyboard taps out "Michael Colburn" every single time.
    It goes without saying that Michael Colburn had a hand in writing the self-test code. You have to try this on a 1200XL because Atari discovered this signature and changed it when the 600XL and 800XL OS ROMs were produced. The message "Copyright 1983 Atari" is tapped out now, but that's not nearly so interesting as the original.

The Wrong Keyboard
More on the keyboard self-test: It seems kind of sad to me that Atari managed to find the energy and time to change that signature but couldn't see fit to fix the test itself.
    If you try the manual mode of the keyboard test on a 600XL or 800XL, you will notice two things wrong: (1) The keyboard layout pictured on the screen is mixed up. The layout shown is actually the 1200XL scheme, including even the F1 to F4 function keys. (2) The display does not show you all legal keypress combinations. In particular, it shows no CONTROL+SHIFT combinations (that is, three-key combinations) at all. And it can't see CONTROL-1 or BREAK. On a 1200XL, the same key combinations are invisible and the CONTROL+function key combinations don't display properly.
    Well, I always said I thought the self-tests were a waste of valuable ROM space, but it would have been nice if they did their jobs right. (My other objection: If you are going to have self-tests, then test everything you can. Like the serial bus, reporting all devices which respond. Like collision detection and other aspects of the GTIA. Like whether the joysticks and paddles work. We have an 800XL which thinks the joystick button is always pushed, but no self-test detects that fact.)

Streamlined Snails
This not-so-little tidbit is a dig at Tom Halfhill. Since he gets to edit my columns before you see them, the very existence of these paragraphs shows his senses of humor and fair play. (See, Tom, I told them you were a nice guy. Now will you leave this in?)
    In the December 1984 and January 1985 issues of COMPUTE!, Tom wrote a pair of wellbalanced and interesting articles on the new MSX computers. If you didn't read them at the time, I urge you to go back and do so. I'm not sure that I agree with all of Tom's conclusions (as you are about to see), but the articles give you the best info I have seen yet on most aspects of this possible new Japanese invasion.
    Anyway, the only reason that I bring all this up is that Tom had Assistant Editor Philip Nelson run a simple benchmark program on all the computers that COMPUTE! regularly reports on. Tom then concluded that MSX BASIC showed "streamlined performance." Why'd you go do that? You know that I love to eat benchmarks alive. Here goes:
    Aside from the fact that the benchmark sorts an array in perhaps the most inefficient way possible, there is nothing wrong with the program as presented. It isn't much good at measuring arithmetic performance, but it is at least as good as the classic BYTE Prime Number benchmark at showing efficiencies (or lack thereof) in logical and branching operations. And the timing numbers presented seem reasonable and correct. So what's my problem?
    Well, first of all, I'm a bit tired of seeing little old 8K Atari BASIC pitted against 32K monsters like MSX BASIC. And I don't really like it when documented, easy-to-use methods of speeding up Atari programs are ignored. Tom says that an Atari 800XL takes 8:55 (minutes: seconds) to run the little benchmark. True. But turn off the screen direct memory access which uses so much CPU time (via POKE 559,0 or with the F2 key on a 1200XL), and the timing immediately drops to 6:10. Which is faster than MSX BASIC's 6:20.
    Let me play devil's advocate: Isn't this cheating? There are ways to speed up that program on other computers, too. For example, the Commodore 64 loses some time to screen DMA also, doesn't it? Answer: Okay, valid objection. But Atari computers, in general, pay the biggest penalty for text mode screens, and I think benchmark programs should at least include a footnote to this effect or maybe mention effective clock rates. (Would it be more legit if we just put a GRAPHICS 19 statement in? That helps almost as much. All right, all right, next subject.)

Faster BASICS
Well, then, how about trying a bigger, more competitive BASIC on that same Atari computer? Glad you asked. BASIC XL handles that program in 4:08. That's two-thirds the time of MSX BASIC and more than a minute and a half faster than the IBM PC. (Just for the record, running the benchmark in FAST mode with the screen turned off gives a time of 2:42, more than twice as fast as the IBM PC. And all these times are without the Newell FastChip, which would make even more of a difference.)
    I admit I am prejudiced towards BASIC XL. Also, it was handy so I used it first. But another timing of which I am proud is Cromemco 32K Structured BASIC, which handled that program in 4:33 (floating point mode) and 3:13 (integer mode) and which runs on the same Z80 processor at the same clock rate doing the same 14-digit BCD arithmetic as the MSX machine. (And if you count the Cromemco S-10 as a personal computer-which you should if you call an IBM PC or a Commodore 8032 by that name-then I will be glad to dispute Tom's claim that MSX BASIC "may be the most powerful BASIC on any personal computer.")
    One more thing before I draw my conclusions: I would very much like to change that benchmark just a little bit. Add lines 1 through 99, each consisting of just a REMark statement, and change the names of the variables to VARIABLE1, VARIABLE2, etc. If MSX BASIC holds true to the standard Microsoft BASIC patterns, its speed will suffer considerably. And so will all the other derived-from-Microsoft times. (Atari BASIC will slow down from the extra lines, but not from the long variable names. BASIC XL in FAST mode and Cromemco BASIC will not change by even a second.)
    So the question becomes: Why is MSX BASIC so doggoned slow? Here we have a 32K language running on a very fast 8-bit processor, and it really only shows off halfway decently when you run very small benchmark programs with one- or two-character variable names. Why? Because Microsoft has never significantly improved BASIC. The versions of the BASIC language used in all these machines (even the IBM PC with its so-called 16-bit processor) are still derived from the original Microsoft BASIC designed for an 8K Altair many years ago.
    When you are trying to fit a computer language as complex as BASIC into 8K (and that includes Atari BASIC), you have to make sacrifices somewhere, and performance is usually the first thing to go. But why, when a computer manufacturer gives you 32K of room for a language, do you need to keep the same scheme? Isn't it time to rethink the methodology of the interpreter? Data General and Hewlett-Packard and Digital Equipment Corporation knew how to build superfast interpreters back before microcomputers were even dreamed of. But they usually ran those languages in 64K memory spaces, the same total size as most of today's 8-bit micros.

Optimizing A Language
When we started building Cromemco 32K Structured BASIC back in 1978, we had already written an 8K BASIC using many of the same techniques Microsoft used. But since this time we had 32K to work with, we studied the minicomputer languages and started from scratch with better methods. If we were to do it again today, we'd start from scratch again and get even more power and better times. Microsoft has never done this.
    To be fair, BASIC is not exactly a hot item around Microsoft nowadays. Apparently Microsoft assigns higher priority to other languages, operating systems, operating environments, and word processors, than to redesigning BASIC. Why not leave "improvements" to BASIC to junior programmers, as a maintenance chore?
    In his January article, Tom wondered if the hardware technology of the MSX might not be a little tired and boring compared to what other manufacturers will be showing soon. Somehow I can't help but wonder and hope if someday maybe-just maybe-BASIC users will get bored with tired software technology, too.
    Boy, did I get on my soap box this month. Well, it's relaxing (for me, at least) once in a while, and I promise that next month will bring something different.