Atari Diskfile Tutorial -- Part II
For those of you who have read and been entertained by the discussion of the Atari disk in the Basic Reference Manual, this article will let you in on what is really going on. It is a ground level look at how the disk works and what the Atari does with it.
The information is quite useful and lets you access the disk more efficiently in many applications, as well as understand how Basic and DOS work with the disk at the lowest level.
This article, believe it or not, presented its authors with a real moral dilemma.
Why? The information presented here can be used to copy disks that without this information are uncopyable. (Mind you, this information is also freely available in the Atari O.S. manual, if you can understand it.)
There is a horrendous software piracy problem in this country. Consider the effect on the record industry if every time a person bought a cassette tape, he made ten cassette copies of it and gave them to his friends. This is exactly what is happening in the computer industry. (Indeed, the record companies have come out strongly against the sales of blank tapes recently and will no longer support ads for those products, for just this reason).
Immediately after a new program appears on the market, it is copied. The copier then distributes copies to friends, trades them for copies of other programs, and so on. And the writer of the software receives no royalties from the copies of his program.
There are ways of making disks uncopyable. This seems like an ideal solution until you realize that a diskette can be destroyed. A phone can ring near it and erase it; a cat can use it for a scratching post (our cat, Atari, tried this trick once), and so on.
If a user is depending on the disk, and it quits working, then he is in trouble. For this reason the practice of "backing up," or making multiple copies of a disk, was started. Too many users had lost their only copies of badly needed material.
It's a good idea; I keep a minimum of two copies of everything on disk, so if I lose one, I still have what I need. And it has paid off; many times I have had to go to the backup copy when the original died for some reason. I don't know why, but I seem to lose an amazing number of disk files--error 144, error 164, and so on.
And if a manufacturer has made his disk uncopyable, you can't back it up. If the disk becomes unusable, you're out of luck.
The software industry has been debating this problem for ages. The Apple, in particular, has been the subject of controversy, with some manufacturers selling programs written for the express purpose of copying "copy-protected" disks. In their literature they describe how backup copies are necessary, and thereby justify the purchase and use of their programs. But they know, and everyone else knows, that these programs are used to rip off an enormous amount of copy-protected software.
One program in particular, Locksmith, gave me a good laugh. Locksmith is an Apple program written specifically to copy disks that are copy-protected, and has sections to handle all of the latest protection techniques. It has caused a great deal of controversy.
In the Locksmith manual, the writers explain the need for backup copies, how disks can be erased, and so on, and condemn manufacturers for copy-protecting disks for this reason. Then, after going to great lengths to point out that Locksmith is for users to make backup copies of programs, the manual points out that Locksmith cannot make copies of itself.
In other words, they know what's going on--who's kidding whom? They even maintain a database on The Source which tells how to copy many of the copy-protected Apple programs using Locksmith.
Justice has been served, and there are now many, many bootleg copies of Locksmith floating around. As Scott Adams might say, "Yoho, and Jolly Roger."
Well, Atari users are in the same boat; things just haven't escalated quite that far...yet. The Atari disk is a different animal from the Apple disk. An Apple copy program, for instance, is an incredibly complex machine language construction, as the Apple CPU controls the disk directly.
The Atari is different; a copy program is very simple. And some companies are using the fact that most people don't know how easy it is to copy an Atari disk to sell copy programs for fairly outrageous amounts. After all, to a user experienced with Apples, the price seems fair.
Frankly, they are a complete ripoff for the price. I do not feel that forty-odd dollars--the cost of a typical Atari disk-cloner program--is a fair price for twenty-odd lines of Basic code.
So much for the copy program makers. Now how about the poor software manufacturer? What do they do, now that I've revealed How To Rip Off Atari Disks? Send me letter bombs?
For the manufacturer's sake, I'll present a few of the latest techniques in copy protection--which the information presented here will now allow someone to copy. And there is no escalation possible; i.e., you won't be able to figure out a way to copy disks protected with this scheme. There is no way, using Atari hardware, to write a program to copy these disks--period. In this way, the word on how to make uncopyable disks will be spread, as will the word on how overpriced (for what they are) the Atari disk copy programs are.
Yes, there are some old copy protection schemes, which we'll discuss, that this information will allow someone to get around. These schemes don't work against the average pirate's copy programs and have not for some time; the disk information discussed here is old news to your average copy enthusiast.
I seriously doubt that anyone will be hurt by this information; if you are going to copy protect a disk, then you might as well use the techniques I will present which make it truly uncopyable, rather than the older ones which the copy programs can duplicate with no difficulty.
Enough philosophy. Let's learn about the disk.
Take a disk and look at it. Inside that envelope (sleeve) there is a circular piece of very thin plastic. On that plastic is the same material of which cassette tapes are made: various magnetic substances.
There are 40 "tracks" on the disk. Think of the circular grooves in a record and you'll get the idea of what a track is. There are 40 concentric circles on the disk and each of these tracks is divided into 18 "sectors." The division is done by pie-slicing the track into 18 contiguous segments. So we have 40 tracks with 18 sectors per track, or 720 sectors.
Atari disks are set up to hold 128 bytes of data (a byte, for you beginners, is one character) per sector. In other words, there are 720 x 128 bytes of data on an Atari disk, or 92,160 bytes.
To access a given sector of 128 bytes, that sector must be in the visible portion of the disk (the window cut into the disk sleeve), and the read-write head must move in or out until it's on the right track number. It then reads the sector by examining magnetic fields written to the disk surface.
Please Note that the actual recording surface is the back, not the front, side of the disk. Most people set disks down with the label up, which means the surface that the data is recorded on is being rubbed in the dust and dirt below. Also be very careful not to touch the backside of the disk in the exposed portion.
The Atari talks to the disk over the "serial I/O bus cable." This is the cable you daisy chain from device to device. Now here's the secret of the Atari disk: The disk drive is intelligent. It contains a 6507 microprocessor, a little brother to the 6502 in the Atari itself, that is still capable of quite a lot. It also contains 256 bytes of RAM (read-write memory), and 2048 bytes of ROM (read-only-memory). In short, the disk drive has a complete computer of its own. (For you hardware buffs, there are 128 on the PIA-like chip). How is this different, and why is this good?
On the Apple, the disk drive is "dumb." The main computer must tell the disk head to move to here, the disk to spin to there, and tell the head what information to write. This neatly ties the computer up while the disk is running.
Apple has a standard scheme for storing data, a "standard format," and if you use the Apple routines to read/write data, you'll stay in that format. Alas, that format allows your disk to be copyable, so people have modified the Apple disk routines to make custom weird formats, that cannot be read by copy programs. (And then other folks have written programs, such as Locksmith, to read "uncopyable disks" and then other weirder formats were developed, etc. It's a little like the arms race.)
On the Atari, the two computers work with each other. There are a net total of five, count them, five commands that pass between them. Since the 6507 in the disk drive is helping do the work, the Atari's main processor doesn't have to fiddle around with controlling the disk, and thus can be doing something else at the same time the disk is running. There are no other commands and the disk drive 6507 will ignore any but the five we'll discuss.
Best of all, since the Atari disk controller is "off limits" and may not be programmed, as its program is in read-only memory inside the disk and is not modifiable, you cannot develop strange disk formats. There is one, and only one, Atari disk format. Hence we'll never get into one of these Apple disk escalations, for we cannot control the disk that exactly. Believe me, after viewing the present Apple disk copy mess, we're not missing much.
An ordinary Atari user accesses the disk through what is known as the File Management System or FMS. The user never sees the lowest level of disk commands (the five mentioned) because FMS handles all that for him. Included in FMS is the ability to split the disk sectors, each 128 bytes long, into files, access the files through the operating system, get disk directories of file names, NOTE, POINT, and so on. FMS works in turn through the Five Commands (perhaps a movie should be made by that title?) with the disk drive 6507 to get your disk processing done.
FMS on disk is called DOS.SYS.
What are the Five Commands?
1. Get Status. This returns the status of the disk and in particular of the IN 1771 floppy disk controller chip inside the disk. "What?," you say. Me too. I don't use, and have never used, Get Status. One day I may find out what it's for.
2. Format Disk. This command instructs the disk drive 6507 to lay out the tracks and sectors on the disk, and to "clean off" old data. Think of it as the 6507 laying down record grooves that it can follow later. What actually occurs is that the 6507 writes data across the disk, reads it and makes sure it has stayed the same (this verifies that the disk surface is good), and then writes the sector numbers onto the various sectors of the disk. This information it used later to find a given sector.
3. Get Sector. This command instructs the 6507 to get the entire 128 bytes of a sector and ship them to the Atari through the serial I/O bus cable. The Atari issues the Get Sector command and tells the 6507 what sector number, from 1-720, to fetch. The 6507 then gets busy, spins the disk and positions the read/write head, reads the data, and returns it to the Atari.
4. Put Sector. This command instructs the 6507 to take the 128 bytes about to be shipped down from the Atari and put them onto the sector number specified. The 128 bytes are then sent, and the 6507 positions the disk, etc., and writes the data onto it. You probably do not use this command, you use its relative, which is:
5. Put Sector With Verify. Remember, disks are not all that reliable. So when we put a sector onto the disk with this command, it is first written, then immediately re-read and compared with the original 128 bytes. If they match, fine; all is well. If not, then they didn't record correctly, and an ERROR message results. (In truth, I have never seen this particular ERROR message.)
The Atari's designers decided to add a little audio to this whole process, so whenever a Get Sector occurs (like during a program LOAD), a pleasant "beep" is heard on the TV's audio channel. Whenever a Put sector occurs (during a SAVE, for instance), a not-so-pleasant "clunk" is heard. You'll note that the Put commands always seem to take twice as long as the Get commands; this is because the disk is physically putting, then reading, the information onto the disk for a verify. Hence, it takes twice as long.
In the net time I've worked with the Atari, I've used Put Sector with no verify once, when I was running OSS's operating system. They apparently use this command, and it sounds a great deal different than the standard slow "clunk..clunk.." of the Atari save.
Now everything that happens to the Atari disk occurs through these commands.