INSIGHT: Atari
Bill Wilkinson
As I write this, I have just returned from the Las Vegas Comdex show.
Comdex stands for "COMputer Dealers' Exposition," but it is really a show for those who would sell to the computer dealers. And sell they did. Everything from magic acts to talking robots to sit-down demonstrations (very welcome after walking through literally acres and acres of booths). And, of course, IBM was there in force, occupying an entire building and demonstrating the usual stuff on the PC and, not surprisingly, some me-too-ish software on the PCjr.
Compatible Disk Drives
The only Atari-compatible hardware products that I saw at Comdex were some disk drives (though I understand that one or two graphics tablets were shown there, also). And that, of course, brings up my next topic.
When you consider the fact that Atari doesn't even make a double-density disk drive, it's more than a little surprising and pleasing to discover the amazing degree of compatibility exhibited by the various non-Atari disk drives.
Since OSS provides the disk operating system (DOS XL) which many of the drive manufacturers supply with (or as an option to) their disks, I can't make judgments as to quality, reliability, etc., without an obvious conflict of interest. I can, however, comment on the features common to all Atari-compatible drives (except those made by Atari itself).
The 815 Drive's Legacy
Historically, the reason for the compatibility is the ill-fated Atari 815 drive. For those of you relatively new to the world of Atari, that was the dual, double-density disk drive announced by Atari for delivery in early 1982. Notice the word "was."
Although never produced in quantity, the 815 survived long enough to cause Atari, Inc., to produce DOS 2.0d ("d" for double), and a few lucky people even have a copy of it. (I'm not lucky.) In fact, even Atari DOS 2.0s can access an 815 style double-density drive for most functions (just don't try to copy files or duplicate disks).
The folks at Percom Data Corporation, though, didn't know the 815 was going to die when they started designing their double-density drives. They did, however, want a way to switch from single to double density without having to physically flick a switch. Hence the configuration block was born. Give Percom credit.
Give the other manufacturers credit, also, for recognizing the Percom system as a viable and usable standard. Would you be surprised to find that the same double-density DOS XL diskette works unchanged in drives or controllers from (in alphabetical order) Amdek, Astra, Concorde, Indus, Micro Mainframe, NCT, Percom, Rana, SPI, and Trak? If you are not surprised, you are not aware of the hodgepodge of the CP/M world.
Each of the companies mentioned can tell you of the advantages of their drives or controllers.
A final comment on the configuration block scheme mentioned above. A controller capable of implementing all the options of the configuration block can, in theory, support virtually any size disk drive. At Comdex I saw floppy disk drives with densities over a megabyte. Yum.
XL Compatibility
I have received more than a little correspondence from readers asking what they can do about the lack of software compatible with their 1200XL (and, now, the 600XL and 800XL). Up until now, my stock answer has been that they should go beat on the heads of the software manufacturers (the ones who didn't follow Atari's rules).
Now, though, there is a little relief in sight. Atari has, at long last, made available something known as the Atari Translator Disk. This disk, when booted from any 810-compatible drive into any XL machine with 64K of RAM, will (for all practical purposes) turn your XL computer into a non-XL Atari 800. Virtually all software, including protected games and the like, will then boot and run properly. (Of course, you don't turn the power off to boot anymore.)
For those who are stuck with incompatible software, this seems like a neat solution. For those who are stuck with incompatible software and no disk drive, this looks like a frustrating solution. Point of interest: I do believe that this software could be loaded via cartridge instead, since one need not turn off the power to change or remove cartridges on an XL machine. Atari, are you listening?
Anyway, if you need the disk, check with your local authorized Atari dealer. If he doesn't have it, hasn't heard of it, or is nonexistent, try Atari's customer service department.
Reading Binary Files
In March, I presented a short program in Atari BASIC which would read a binary object file directly into the memory locations it was originally assembled for (or saved from).
This month, I will start to parallel that listing in machine language. Please understand that this may not be the fastest or easiest way to perform the task. I use the BASIC parallel method as a way of making the program understandable to those who are just beginning to learn machine language.
As a first step, you might look through the listing, noting where the BASIC line equivalents are. They are easy to find. Starting at line 1000, any line number ending in 00 is a comment line which reflects the line in the BASIC program which I presented last month. Note, also, that the line numbers in this listing are 10 times the BASIC line numbers (simply for convenience and readability).
While examining the listing, you probably noted that there seems to be more nonparallel code than otherwise. In truth, this simple pseudo-BASIC program does indeed require a fairly substantial amount of support. The support is in two forms: definitions of variables (including buffers) and I/O subroutines.
A Page 6 Assembly
You may also have noticed that I assembled the listing in the infamous page 6 memory block. I plead guilty. Actually, in testing this program, I assembled it twice: once at $600, as shown, and once at $6000 (just by changing line 110). I then used the $600 version to read in the $6000 version, and it worked!
Anyway, since I will be giving you complete source code here, I don't feel too guilty. Obviously, you can change line 110 to anything you wish if you need to stay out of page 6.
There are two other "cheats" in this listing. In line 220, I place NAME at location $580; and, in lines 250 and 270, I place START and ADDR at location $CE. Are these locations truly safe to use? In general, no. If you have been reading my series on self-relocatable code, you know that there are no truly safe locations. But for the purposes of this demonstration, I think we can use them as is, since they are compatible with usage by the Atari Assembler Editor (and MAC/65 and—I believe—AMAC) and Atari BASIC (and BASIC XL but not Microsoft BASIC).
One other comment before we begin analyzing the operation of the listed code. If you wish to use this program as a callable USR routine from Atari BASIC, you need to add this line:
125 PLA; clean up stack for BASIC
BASIC And ML Compared
Now, onward and downward, into the depths of machine language. I will discuss the lines which I feel are relevant and important by line number.
Line 130. We could have accomplished the same thing by giving a RUN address at the end of the listing, but this gets us started in a visible way.
Line 210. Note the use of the $9B (an AT ASCII RETURN code) to terminate the message. The 0 is for safety and because I am paranoid.
Double Usage
Lines 230, 240, 260. If you consider LOW and HIGH together, they form a 16-bit word. Since QUIT needs to be a word, why not join usage? This is not recommended procedure, but it works if you are careful.
Lines 250, 270. This isn't surprising if you think about the fact that line 310 in the BASIC code could have been written as FOR START = START TO QUIT, thus eliminating the need for the extra variable, ADDR.
Lines 300–321. These are the same equates you have seen many places, including in the Atari OS listings and Inside Atari DOS though the actual mnemonics may differ slightly.
Lines 550–566. When you get to this routine, it expects the OS channel designator (which is 16 times the Atari BASIC file number) in the X register, the command value in the A register, and the address of the buffer to use in the Y register (low byte) and on the stack (high byte). The routine assumes that you will not be doing I/O which requires over 255 bytes of buffer (a valid assumption for this program, but not for all circumstances).
Checking For Errors
CMDJOIN sets up the appropriate IOCB and calls CIO to do the real work. It returns the error status to the user in A, Y, and the flags. In this program, only OPEN looks for the error status. (Because PRINT and INPUT to/from channel zero had better work, and if CLOSE fails it's too late anyhow.)
Lines 500–545. These are the various I/O entry points. Note that they expect the X and Y registers set up as in CMDJOIN. They assume that the high byte of the buffer address is in A and push it on the stack to make room for the command byte. They are simple and effective.
Next month we'll look at the rest of this listing.