 ANTIC VOL. 2, NO. 2 / MAY 1983 / PAGE 28

Invisible Sector

by Chuck McMath

Suppose someone stole your disks, or copied them without permission. Could you prove it? It is possible to create a permanent, secret label on your disks, and I'm not talking about invisible ink.

This label, residing on the disk itself, could hold your name, the date, a serial number, or any other important data�without using any space on the disk! It would be invisible, yet readily available to you, the owner. Sound exotic, intriguing, impossible? The fact is, it's easy, straightforward, and possible because of a quirk in Atari DOS. But first, you'll need to understand how the disk is organized.

Disk Organizaion

Any disk you use is divided into 720 sectors. Each of these sectors holds 128 bytes. Theoretically, a disk could hold 90K bytes (720 sectors, times 128 bytes, divided by 1024 bytes per kilobyte). However, some of the sectors are reserved by DOS for the directory and miscellaneous diskmanagement tables. One of these tables is the Volume Table of Contents (VTOC). The VTOC maintains a record of which sectors on the disk are currently in use. The table is made up of 90 contiguous bytes, with each bit representing one sector (90 bytes, times 8 bits per byte, equals 720 bits, corresponding to the 720 sectors on the disk). Since each bit represents a sector, this table is referred to as a "bit map." (Each bit corresponds to one sector on the map.)

When you save a file onto disk, the File Management System (FMS) writes the data to certain sectors. Along with writing in the sector, the FMS marks the sector "used" in the VTOC, simply by placing a zero in the VTOC bit position corresponding to the written sector. This prevents the FMS from using that sector for another file (unless you delete this file, in which case the sectors are marked as "free").

So far, so good. Now for the bad news � at least from the system's point of view. From our point of view this is the good news! The FMS interprets all 720 bits as corresponding to sectors 0 to 719. This in itself is no problem, except that the disk drive will not accept commands for sector zero. This means that not only will sector zero in the bit map never be marked (because of the drive's limitation), but that sector 720 will not be used by the FMS, since there is no bit to represent it. Since it can't be represensed in the VTOC, the FMS can never store information there!

Here's where we step in. Just because the FMS will not access this sector doesn't mean that we shouldn't (or can't). That sector is exactly where we will write our "invisible" data. Since the FMS doesn't count this sector in the first place, we will lose nothing by using it, but we will gain 128 bytes to store anything we want. For a more detailed expalanation of the VTOC and its interaction with the FMS, see Bill Wilkinson's Inside Atari DOS.

Invisible Writing

Unfortunately, we cannot directly read from or write to a specific sector in BASIC. Listing 1 is a short Assembly Language program that will either read from or write to sector 720. The calling sequence for this is:

X = USR(1536,CODE,ADR(BUFR$))

where CODE is 82 (decimal) for read, and 87 for write. BUFR$ must be at least 128 bytes long, and depending on the operation, contains the data to be written or the data just read. The routine itself is not complicated; it merely sets the following parameters:

Next, it jumps to the DOS diskhandler routine (whose starting address is $E453), which does all of the work. These disk commands are fully explained in the Atari Operating System User's Manual (Chapter 5), which gives detailed examples of the necessary values for all parameters when using different disk commands.

Basic Read-Write

Listing 2 is an example of a program that will access sector 720 from BASIC. This example shows a sample organization of our invisible sector that includes a label, an owner's name, a serial number, and a date. The only restriction on using sector 720 is that you only have 128 bytes to use, so you must plan wisely. In most cases, this amount of storage is not a limitation.

When the program is run, it first POKEs the Assembly routine into memory on Page Six. It then asks whether you want to read or write. For a write, it asks you for the information it wants. Then the Assembly routine is executed. One valuable location to check after performing these operations is location 771 (decimal). This contains the disk status. After the read or write, the program checks the status to make sure the operation was successful. If the value contains a 1, the operation went as planned. If the value is not a 1, the value gives the error code for the operation. Then, if the operation was a read, the program prints out what it found.

Listing 3 is an even shorter BASIC program that provides a directory of files on a disk. This is a fairly standard technique of reading the directory as a file, so I won't explain it too much. However, before listing the files on the disk, this program first reads and prints out the data from sector 720. This shows how this sector could be used to: indicate ownership, or date of creation, or anything else you want. After reading the label, the directory is opened as a file, and the files in the directory are read out of this file. When you read the "FREE SECTORS" message, you know you are done, so you close the file and end.

Conclusion

There you have it. With very little effort, you can easily use this "invisible" sector for a hidden label or for other information. With these labels on your disks you have an undeniable claim of ownership. After all, who can erase an invisible label?

mnemonic    location (hex)  explanation
---------------------------------------
DUNIT       $301            the disk unit (usually 1)  
DCOMND      $302            the command (82=read;87=write with verify)
DBUF        $304-30S        address of buffer (low byte, then high)
DAUX1       $30A            for these commands, sector number (low byte,
DAUX2       $30B                 then high)

[CODE]