Atari DOS
A disk is a very complex piece of hardware. It is a mass storage device; one disk contains about twice the data that fit into the Atari's read-write-memory at one time. In addition, various functions must be supported; these include storage of disk files, random access of data, formatting and copying. All of these are controlled by the Disk Operating System; they are the "support" routines specific to the disk drive and are needed only to run it.
The Atari has a very sophisticated operating system, easily the best in the microcomputer market for the price. It is called the OS (not DOS--that is for the disk alone) and is physically located in the OS 10K ROM cartridge of the 800 and internal to the 400.
The Atari OS is very flexible and can do many unique things because it is "device independent." This means that any input/output device-to-device communications are done not to a specific device, but to a "unit number." Whatever device is assigned to that unit number receives the instructions from the operating system.
For example, let's say that we have output going to unit number 2. An example might be a checkbook balance. Now if that unit number is assigned to device "TV screen," the output goes to the screen. If the unit number is assigned to the printer, the output goes to the printer. The output goes to the device to which the unit number is assigned.
This concept of device independent input/output is very consistent with the rest of the design philosophy of the Atari. For example, colors are not assigned directly; rather, a given screen image is drawn in a color register number. Whatever color is in that color register is then output to the screen.
The ability to reassign devices is extremely useful. Unfortunately, the workings of CIO (the Central Input/Output system) are a bit beyond the scope of this article.
Short detour (I warned you): Here's one bit of information for advanced users that is worth its weight in gold. In order to direct all output going to the TV screen to the printer, use:
C346 < A6,EE from the assembler/editor cartridge debugger.
Screen output can be restored with: C346< A3,F6.
Let me cite an example. I was debugging a game that filled the screen with a graphics display. If output appeared on the screen, it would disturb that display--a rather common problem. By using the above modification, I got the debugging/trace output to appear on the printer instead, leaving the TV image "intact."
Back to Atari DOS. The DOS is a set of assembly language routines dedicated to running the disk drive. They load from disk any time the Atari is turned on with a disk turned on and connected. They are physically located in a file named DOS.SYS on the diskette.
Loading DOS
These routines are absolutely necessary to run the disk drive. If the file named DOS.SYS does not exist, is fouled up, or otherwise cannot be used, then the disk drive can't be used either. The Atari discovers on power-up whether a disk is present and attempts to load DOS.SYS from the plugged-in drive.
If the disk is blank, or anything else is wrong, the message BOOT ERROR appears, and the drive makes an awful "s-nn-aaa-rrr-kk" sound. Don't worry; the snark is the sound of the disk completely resetting its internal functions, the equivalent of "if at first you don't succeed..."
Okay, what happens after the DOS file loads? The Atari takes the disk routines and integrates them into its regular operating system. The routines to handle specific devices (such as the screen editor, cassette, or printer) now have the ability to handle the disk. (The DOS will go away whenever the Atari is turned off or crashed, incidentally.)
Regrettably, these routines occupy roughly 9000 bytes of memory, so you lose 9K for other uses. You need DOS to access the disk, so if you plan to use the disk at any time during the current power-on session, you must load DOS.SYS. This is something every Atari disk user has done--just turned the machine on, without disk, then tried to access the disk. When I did this last I typed a program in for half an hour, and typed SAVE--nope, couldn't do it.
(If you should get stuck this way, save the program to the cassette recorder, power up with DOS, and reload it from the cassette. The cassette handler is always in memory.)
Now for a little more relevant history. Atari has had several DOSes. The "first" DOS was dated 9/24/79, the date that shows up when DOS is typed. In this version, called DOS 1, the utility functions were integrated along with the regular operating system functions. When a user typed DOS, the utility functions were immediately run from memory, and the DOS menu popped up onscreen.
Well, this wasn't a winner, because these menu functions occupied about 3000 bytes of memory and were only needed when a specific disk utility function was required. DOS 1 also had other problems and bugs, so Atari came out with DOS 2.
In DOS 2 the utility functions occupied a separate file called DUP.SYS. When the user typed DOS, the utility routines were loaded from DUP.SYS off of the disk. They weren't in memory all the time.
There are some minor compatibility problems between DOS 1 and 2. Binary files won't work between them, as DOS 2 has a different "header" format, and copying is a problem.
Fortunately, most of the DOS 1 disks have disappeared, leaving users with an improved operating system which has eliminated many of the bugs. Alas, while Atari was working on the bugs, they "released" several preliminary DOS 2 versions, called DOS 2.4, 2.5, 2.8, and 2.S, all of which have bugs in them. Don't use them.
DOS 2.OS is the most bug-free version. (Should you find an older version of DOS. just re-write the DOS files after powering up from a 2.OS disk.)
One minor problem with the new DOS concerned where to load the DUP.SYS menu package in memory. The way it was set up, a user who went to DOS wiped out the lower 6K of memory, including any programs (such as Basic) stored there. The result? If you had a Basic program, went to DOS, and returned to the cartridge, your Basic program would be gone.
The solution Atari provided was MEM.SAV. MEM.SAV is a special file created from the DOS menu. When you type DOS and a file named MEM.SAV exists, then the lower 6K of memory is moved to this file before the utility package (DUP.SYS) is read in. Hence, a copy of the lower 6000 bytes exists on disk. When DOS is left, the MEM.SAV file is read in, restoring memory to what it was. The process can be summed up as follows:
1. User enters a program into memory, including the 3000 bytes "shared" with DOS.
2. User types DOS.
3. Lower 6000 bytes of memory are copied to MEM.SAV on the disk.
4. The utility package (DUP.SYS) is read into the lower 6000 bytes, destroying the program data there.
5. User exits DOS.
6. MEM.SAV is read back in, restoring the lower 6000 bytes, and the user can pick up where he left off.
The process of reading and writing to disk is quite slow, as are all operations with the Atari drives. For this reason I rarely use MEM.SAV; I just save whatever I'm doing to disk first, go to DOS, then recover it from disk later.
Another Sidetrack
Speaking of disk speed, new drives from other manufacturers are becoming available for the Atari. As a general rule, if the drive uses the serial I/O cable to attach to the Atari, it will run as slowly as the Atari disk; this cable is the bottleneck.
When the Atari writes something to disk, it normally re-reads the data written to disk immediately and compares what it finds there with what should have been written. This is a safety feature in case the disk doesn't write correctly. Alas, this slows down the disk drive to one write operation every 1/5 second, a very, very, slow speed. If you wish to cancel this read-after-write process, do this:
1. Power up with DOS 2 into Basic.
2. Type POKE 1913,80
3. Go to DOS and select H: Write DOS files.
The data at location 1913 determines what sort of write the disk drive does: read-after-write (87), or write alone (80). Next time you write to disk, you will notice an immediate increase in the write speed.
In all fairness, I have never once gotten the error message that means the read-after-write failed. Some of my associates have, but only on defective disk drives that gave numerous other errors. In my opinion, the write with no verify is the way to go, as disk operations are quite reliable. The time spent waiting for the Atari to verify data just isn't worth it.
The DOS Menu
Okay, so we have gone to DOS and are now in the DOS menu, Let's look it over.
The top line identifies the DOS and DOS 2.OS. The S means "single density" and refers to the amount of data written on a particular disk. Atari was going to offer a disk drive called the 815, which was a "double-density dual disk drive." For various depressing reasons the 815 was cancelled, so the double-density operating system, called DOS 2.0D, was never released.
Next, there's the copyright line. Then, the menu options begin. Let's take them in order.
A. Disk Directory: Data on Atari DOS disks is organized into individual files. These files have names of eight characters with an optional three-character extender; e.g. FILE.ABC, PROGRAM.BAS, and so on. Note that I said Atari DOS; there are other disk operating systems available which do not use Atari DOS, For instance. Forth doesn't generally use the Atari DOS at all, and an attempt to read the directory on a Forth disk is usually futile.
The directory is a list of the files, by name, which exist on the disk. Option "A" is used to read this list.
When you press A, the Atari asks, SEARCH SPEC, LIST FILE?
This means you can enter one of two items. The first is a "search specification." You can search for all files, in which case a list of everything on disk is produced, or for a specific group of files. This specific search is accomplished with "wild cards." A wild card is a special character which Atari DOS accepts as "any character." The character "?" is used for a wild card for an individual character, and "*" is used to indicate any characters from that position on. For instance, a search spec of *.* will find all files on the disk. *.BAS will find all files with the extension .BAS. JONES*.* will find any files whose first five characters are JONES. ??XYZ? will find AAXYZJ, ZZXYZD, and A1XYZR.
The second spec tells where to write the directory listing. Leaving it blank means write it to the TV screen, also known as "Device E:" (where the E stands for Editor). Here we get into the I/O system, which we have discussed previously. Devices on the Atari are identified by a letter and a colon. Here is a list of some of them:
K: Keyboard. Input only.
E: Screen Editor(TV), Input-Output.
5: Screen output. Output only.
C: Cassette unit. I/O.
P: Printer. Output only.
Dn:name.ext Disk drive #n, file name "name.ext."
The directory option asks where you want to write the listing. You can select any of these devices for output but the keyboard (K:).
You could use P: (printer), D:filename (some disk file), and so on. Note the power of the I/O system: you can write the listing anywhere, including devices or file names. For example, writing a listing to a printer is handy for a reference. Writing it to disk might be nice for a directory program. Writing it to the TV is good for quick lookups. This is a powerful unit.
The directory will then proceed. Physically the directory is located in the middle of the disk. This is because the Atari spends so much time looking at the directory that it was felt that the middle would be a good place; it is equidistant from everywhere else, saving lookup time.
B. Run Cartridge. This option transfers control to the plugged-in cartridge. If you don't have one, the Atari will figure it out and let you know it knows. This is how you get back to Basic, the ASM/EDIT cartridge, and others from DOS. Languages which are "disk based" (such as Microsoft Basic) do not use this option. There are different ways of getting to and from DOS using non-cartridge-based languages.
C. Copy file. This option allows you to copy from any device or disk file to any other device or disk file. It is extremely powerful.
For instance. if we copy from E:,D:TEST whatever we then type on the screen will be sent to the disk file TEST. (Exit using the Break key.) Bang, an instant crude word processor! We can copy directly from the screen to the printer (E:,P:). from the keyboard to the screen. etc. We can display a file on disk by using D:filename.ext,E:. (This includes Basic files, although they are stored in a crunched format and will look strange when listed.)
Finally, we can copy from disk to disk using this option: D:FROM,D:TO will copy all data in the disk file FROM to the file TO. Also, we can copy from disk to disk: D1:FROM,D2:TO will copy from FROM on disk 1 to TO on disk 2. The Atari can support up to four disk drives. D1-D4. The drive is identified by the two switches in the back of the disk unit; they can be set in four positions, and the position in which they are set determines the drive number of the disk.
Another short detour: If you can't get your system to "wake up," check these switches. The Atari will be looking for the disk 1 to get DOS.SYS from, and if no disk currently online has its switches set to 1, the Atari won't find it. This leads to all sorts of strange things. So especially if you have a multi-disk system, check this if you get weird errors.
You cannot use the Copy option on a single disk system to transfer files between separate diskettes. Use the 0 option to do this. 0 reads the entire file into memory then prompts you to change diskettes. Then, it writes the file out to disk.
COPY uses as much memory as possible as an intermediate storage place. If you copy a disk file to the screen, you will note that the entire file is read off disk before it begins copying to the screen. This is the nature of Atari I/O. You will also see that when copying to the printer, you must terminate the input operation before the output begins.
This causes a problem when MEM.SAV is used. When MEM.SAV is active, the Atari assumes that all memory outside the 6K bytes copied on disk is inviolate. On a copy, it will ask you whether to use the rest of memory to speed things up.
If you don't you will have a very slow copy, as only a small intermediate area in memory can be used. This also keeps memory intact for you to return to after you're done with DOS. Should you elect to allow Copy to use the rest of memory. MEM.SAV is invalidated and you lose whatever is on disk. The choice is yours. (The Atari will warn you that a Yes" to its prompt will invalidate MEM.SAV.)
Warning: Files with ".SYS" as the extension will not copy using the wildcard options. While this doesn't really matter with DOS or DUP.SYS, as they may be written with the H option, it is critical with AUTORUN.SYS files. Be sure to force a copy of the AUTORUN.SYS file if you copy a disk this way.
D. Delete File. This is an option to allow you to delete a file from disk. If you use a wildcard, you can get rid of a whole group of files. For example, to delete every file with an extension .ASM, use: *.ASM at the prompt.
Delete will ask you if you wish to delete each individual file by printing the file name, then asking DELETE? Y/N. If you don't want it to verify that you want the file deleted, add a /N at the end of the file specification. For instance, to delete all files with SAM as the first three characters and not get a prompt, use SAM*.*/N. The DOS will then delete everything it finds with those specifications without asking again if you really want to do it.
Delete *.*/N will erase an entire disk.
E. Rename file. This option allows you to rename a disk file. You enter the first file name, then the second. HERMAN,FRED will rename HERMAN to FRED on disk. Wild cards can also be used, but be careful.
This option also allows you to create two files with the same name--a significant problem. If you try to access the file by its name, the first occurrence will get priority, and you will have lost the second file for all practical purposes. But delete or rename will get both occurrences of the file, alas. What to do?
Try this. Turn up the TV sound. Rename the file something else, and listen. Immediately after hearing the first clunk of a disk write (not a beep, that's a disk read), pop the drive door open. This will prevent the Atari from renaming the second file, which would be the second clunk. Do this at your own risk--you could also trash the directory and lose the disk if your timing is wrong.
An alternative is to use a Disk Fixer program, such as the one available from APX, to alter the directory.
F. Lock file. A file that is locked may not be altered or deleted. This is a safety feature; I lock the editor and assembler files on my disks that have them. This prevents something like a wildcard delete from destroying them or something in DOS from accidentally modifying or destroying them.
G. Unlock file. The reverse of F.
H. Write DOS files. This option writes DOS.SYS and DUP.SYS on the current disk. (You are asked which drive number to write the files to.) Remember, you must have the DOS files on a disk to be able to power up using that disk, for the disk operating system must load at that time.
I generally use this option after modifying DOS (let's say with the "fast write" POKE) or after formatting a disk. By the way, old DOS files on the disk will be deleted. And in answer to a question I received, the DOS files do not need to be any place in particular on the disk. They can be put in any time.
I. Format disk. This option takes a new or used disk and completely blanks it out, putting "formatting information" onto the disk. It also sets up a blank directory and other information needed by the Atari to access the disk. And here we go on a short detour:
Fast Format Chips
A disk is laid out with the sectors in which data is saved in a particular order. As the disk spins at 290 rpm these sectors are accessed one by one. Now, depending on how the sectors are laid out, the Atari can access them more quickly. Atari has two popular sector layouts--the B and C layouts. The B layout is the original and is quite slow; there is a discernible pause between disk reads (beep-pause-beep-pause-beep, where each beep is one read.)
The C format is about 20% quicker than the B format, because the disk is laid out more efficiently. Disks that come from Atari use the C layout.
When you format a disk, the way your disk was set up at the factory determines whether it uses the B or C layout. Most drives today have the B layout, but all new drives shipped from Atari have the C layout. Thus, disks formatted on new drives (using the C layout) will do everything 20% more quickly than disks formatted on B drives.
By the way, if you reformat a disk, the new format will be the one laid out by your disk drive, so don't reformat Atari-formatted disks. Instead, if you want to delete old information from them, use Delete *.*
A group of users in Chicago modified the B layout to what is called the Chicago layout. This layout is 30% quicker than the B format and indeed is 10% quicker than Atari's own C layout. However, a price is paid: the disks become rather sensitive.
Atari disk drives have difficulty maintaining a given rpm, which causes several problems, including lots of read-write errors. If you install the Chicago format, and your disk spins at more than 288 rpm, it will skip sectors, doing a complete spin between reads. This is quite slow and has a distinctive "Beepbeepbeep (pause) beepbeepbeep (pause)" sound. If you get this, check your disk.
One other thing about the Chicago chips is that they may be illegal. Atari copyrighted the B format in the ROMs used in the drive. It would annoy them considerably if users didn't buy the new C chips, complete with installation charge, but used the Chicago chips instead.
The legal question about copying the chips, then modifying them, is not one I would care to test. Yet many users have installed Chicago chips in their drives, and some groups even hold swap parties where hardware experts install Chicago chips into other people's drives. Someone with pretty good hardware knowledge and an EPROM copier is needed even to make the Chicago chips from the available instructions (which have shown up in many newsletters), so this choice may not even be available to you.
Yet another consideration is that the difference between the B and C chips available from Atari does not consist solely of the formatting change. The chips are much different, and supposedly other improvements have been incorporated into the C revision. You may be missing out on these improvements if you install a Chicago chip.
Another goodie installed by Atari on later drives is a piece of hardware called a "data separator." The story is this: Atari uses a floppy disk controller chip from Western Digital called the 1771. The 1771 is a fine chip, but has a weakness in clarifying data read from the disk, a process called data separation. Even the manufacturer's own literature tells the user not to rely on the internal data separation of the chip.
So what did Atari do? They didn't use an external separator. Result: bad disk reliability and lots of errors. Soon the more sophisticated users of Atari drives figured out the problem and began installing TRS-80 data separators in their Atari drives.
It seems that the makers of the TRS-80 had done the same thing (not used an external separator) and that TRS-80 disks had very poor reliability as a result. So outside companies began supplying data separators for the TRS-80. Since this machine also used the 1771 controller, the data separators for the TRS-80 fit the Atari.
I installed one some time ago and have been very pleased with the increase in reliability. The cost is $29.95 from one source, Percom, which now supplies kits for the Atari.
You need a soldering iron for two very minor solder touchups and a phillips head screwdriver to remove the cover of the machine. While the modification will violate the Atari warranty, it is worth it.
I recommend it to anyone who doesn't have the Atari data separator, which is everyone with a drive made before January 1, 1982. Percom can be reached at (214) 340-7081. You should call for new pricing and availability information.
Depending on your local dealer, parts availability, and other factors, you may be eligible for a deal whereby you send your drive in for installation of a C formatting chip and an Atari data separator and a general check-up. The Atari separator seems to be pretty good, so you may want to look into this option to upgrade your drive.
A late breaking rumor is that Atari has released yet another add-on board to help control the drive. I don't know whether this is true, but it sounds likely; drive rpm has caused many headaches.
DOS Menu Again
J. Duplicate Disk. (I know, you thought I'd never get back to the DOS menu. Right?) This option allows you to duplicate an Atari disk completely. What it does is read each sector from 1 to 720.
The user can either duplicate from drive to drive or with one drive by swapping disks. Use "1,1" at the prompt to duplicate a disk with one drive, and differing numbers to duplicate between drives.
Duplicate Disk is more or less identical to a copy using *.*. However, the disk duplication is complete, so errors in the disk will also be duplicated. Should you get an ERROR 14 or 164 on the disk, Duplicate Disk may not work, and you should copy individual files from disk to disk to recover what can be recovered. A discussion of sector chaining and what causes an Error 164 is beyond the scope of this article, but can be found in the April and May 1982 issues.
K. Binary Save. This is an option for the advanced user which saves a given area of memory to disk as a binary file. It is an assembly language entity used by the machine. Since this is a beginner's guide, and hexadecimal input is required, I'll leave it at that. See the DOS 2 manual for a lengthy, painful discussion of what happens.
L. Binary Load. This is an option to load a binary file from disk into memory and to execute it directly. Beginners may use it, although they may not understand what is going on. The MacroAssembler/ Editor is only accessible by loading it from a binary file, for instance. And Microsoft Basic is just another binary load file. (Think of a cartridge as a binary load frozen into the cartridge which appears in memory when you plug the cartridge in, and a disk load as data that appears in memory loaded from disk. This will give you an idea as to how the two relate.) And no, you can't copy a cartridge using the Binary Save option--Atari DOS checks for this to prevent people pirating the cartridges.
M. Run at address. Again, this is an advanced-user-only option. It enables DOS to jump directly into a program loaded in memory. It is handy for advanced users who want to run programs without a cartridge, but not so helpful for beginners. Again, knowledge of hexadecimal is required.
N. Create MEM.SAV. This is used to create the initial MEM.SAV file. To eliminate it, use the Delete option. You cannot create MEM.SAV any other way, although a disk that is Duplicated will have the MEM.SAV on the new copy if the FROM disk had it.
O. Duplicate file. This is used to copy a file from one disk to another without using two drives. Wildcards can be used to copy an entire disk.
Disk drives are relatively high-speed mass storage devices. Alas, the 5 1/4" mechanisms represent a tradeoff between reliability and cost. The 8" drives, which are more reliable, also cost much, much more. Atari probably couldn't market an 8" drive for less than $900; so they went with the 5 1/4" mechanism and enabled many more to have disk drives. It was a good tradeoff.
Unfortunately, the way in which Atari designed their drives is developing into a controversy. The number one topic of conversation in many user's groups seems to be peeves about Atari disk drives. The drives are neither reliable nor fast--even compared to the rest of the industry. Apple disk drives, for example, run up to 20 times faster.
Something will undoubtedly be done; Atari has not been deaf to the complaints. For the moment, they have issued several patches to the drives-data separators, rpm fixes--but they may not be able to correct what might be simply a bad design.
See you next time!
Table of Contents
Previous Section: Miner 2049'er
Next Section: Atari Diskfile Tutorial Part I
