by Roy T Beck
I remember way back in the days when NEWDOS2.1 was new, an occasion when Harv Pennington came to the OCTUG and explained the directory structure of TRSDOS 2.1. Not having disk drives then (I was still using cassette tapes), his lecture sailed over my head at about 10,000 feet above MSL (My Sensibility Level?). He did a very good job of presenting the ins and outs of the mysterious disk sectors by means of flip charts, but I really got very little out of it. Fortunately, fragments of his lecture did adhere to the lobes of my cerebellum, and when I later equipped my Model I with 2 drives (sigh, so long ago), I soon became fascinated with the GAT, the HIT, the PFDE, etc. With Harv's book 'TRS-80 Disk & Other Mysteries", plus the fragments of his lecture rattling around in my brain, plus SuperZap, courtesy of Apparat in Denver, Colorado, I soon became a full fledged byte zapper, only embarrassing myself occasionally!
Having thus explored TRSDOS V2.1,2.3, and now 6.X (see my article on copy limited disks in issue V1N6), it is high time to delve into the corresponding areas of CP/M. YES, CP/M also has a directory structure, but it is simpler than TRSDOS by far. That's not surprising, given the age of CP/M; it predates almost everything! GAT sector? Nope. HIT sector? Nope, more'sthe pity, as the HIT sector is truly an inspired feature of TRSDOS. Too bad IBMDOS doesn't have it. But of course, IBMDOS was derived from CP/M, so I guess that's one area where they followed a previous bad decision. I (or someone else) will explain the philosophy and beauty of the HIT table at some later date. Suffice it for now to say that it is a powerful tool, and neither CP/ M nor IBMDOS uses it.
CP/M has essentially no passwords, either, another area where TRSDOS shines. There is a feature in CP/M called the User number which functions to a slight degree as the beginnings of a subdirectory system. In this respect, CP/M has a slight edge over TRSDOS, which has no subdirectories in its basic arrangement. MISOSYS' DISKdisk does overcome that lack to a great degree, but is essentially an add-on to TRSDOS. IBMDOS really shines in the matter of subdirectories, and deserves full credit for them, even though first time users (strugglers?) may curse them.
' One ofthe weak areas of CP/M is the fact that Digital Research never made an attempt to define any standard disk formats other than the 8" SS SD. The result is that every implementer of CP/M went off on his own, and we now have dozens of disk formats for different machines and different disk sizes. It would take too much of my limited time to attempt to gather and collate all of the different formats, and a duplication of effort to boot, as Monte has already done most of this. He had to in order to create the disk format interchange program with its more than 100 different formats.
Instead, the intent of this article is to explain the configuration of our "standard" MM formats as implemented in our current version 2.32 of MM CP/M. I will begin with the SS DD System disk as received from MM. There are three areas of interest on this disk, namely the system (including the Boot), the directory, and the data storage area.
By the way, when CP/M was new, the sector was almost invariably 128 bytes in length. CP/M also uses 128 bytes as the size of a logical record. Oldtimers in CP/M used the term "sector" and "record" interchangeably, and this confusion of terms still exists, to some extent. It is important to understand that CP/M always handles data in 128 byte logical records internally, but has a mechanism for blocking and deblocking logical records into sector size blocks, 256 bytes in our case. Remember that the disk drive must read or write a full sector each time; the disk controller cannot read or write more or less than one full sector at a time. Therefore, every sector on our system disk is 256 bytes long and contains two logical records. This is an important point.
The system area begins on track 0, sector 1, and extends through track 1, sector 18, on a SS disk. The first sector is, of necessity, the Boot sector, because this is the sector the ROM of either a Mod 4 or a Mod 4P will read into memory. On the SS DD MM system disk, the sectors are 256 bytes in length. The Boot sector is, of course, the actual loader for the CP/M system. The remainder of the system tracks and sectors contain the rest of the BIOS, the CCP, and the BDOS. This is all limited to 9K in length, because there are two SS tracks of 18 sectors, each containing 256 bytes.
The next significant area of the disk is the directory which allows DOS to find the files stored in the data area of the disk. The rest of this article will be devoted to the structure of the directory.
The final portion of the disk is the data storage area where all files except the actual CP/M system files are stored. The DOS disk has 170K of storage space for files, but since the system disk, as delivered, contains numerous transient programs, there is essentially no space for additional user files on this disk. Of course, if you have double sided drives, you can prepare a double sided DOS. This will increase your data storage space by about 180K, making the machine more flexible. Of course the system disk can also be tailored to your specific needs by deleting unnecessary files, and this will free up some data space on the system (DOS) disk. Since it is possible to replace the Mod 4 and 4P drives with double sided drives, and to install 4 half height drives in a Mod 4 or 4D, there is plenty of opportunity to increase the available data storage space in our machines.
Now, on to the MM SS DD directory structure! The SS DD MM system disk has 3 directory sectors in use, shown in a Super Utility printout below. Before proceeding further, I had better point out the CP/M practice on interleaving sectors. Most DOSes interleave sectors in order to provide sufficient time for the CPU to handle the data from one sector before the next one comes around. In most other DOSes the interleaving is accomplished at format time, by placing the sectors around the disk in a pattern which insures sufficient rotational time between reading or writing successsive sectors of a given file. CP/M is different in this respect. The sectors are formatted around the disk in numerical order from 1 to whatever. In order to provide the necessary time between successive sectors' appearance at the read/write head, a sector Interleave is established and controlled by a table within the BIOS. If you notice the sector numbers at the left edge of the three sectors shown, you will see they are in the order 1,3,5. These are the physical sector numbers, as recorded in the data address marks (DAM). This indicates the logical order of reading the physical sectors is:
While this interleaving can be ignored when reading the directory, it is crucial to reading the sectors of a file in the correct order.
The CP/M directory consists of a group of 16 sectors (32 logical records of 128 bytes each) starting at track 2, sector 1. Each directory entry consists of 32 bytes, for a total of 8 entries per sector. The first byte of each entry serves a dual purpose. If it is OOh through OFh, it is the User number of the file. If it is E5H, then the directory entry is either blank or killed. (Because CP/M only resets this one byte when it kills a file, it is easy to recover a killed file as long as the actual file sectors have not been written over by some other file. All TRSDOS' except V1.3 for the Mod 3 follow this same practice). The next 11 bytes of the directory entry hold the filespec, with 8 bytes for the filename and 3 for the extension. Byte #13 is supposed to hold the "extent" number, but the entries for MDM730.C0M and MDM730.DOC in the second sector image both contain 01 in this position, and there appears not to be a 00 extent. I don't understand this. Explanation of bytes #14 and #15 will be deferred to a later article. Byte #16 indicates the number of logical (128 byte) records actually used in this extent.
Each of the last 16 bytes points to an "allocation block" on the disk. These bytes correspond to the similar bytes of a TRSDOS file entry, except that each entry in the CP/M directory identifies one allocation block. The TRS entry points to a track and sector location on the disk and tells how many contiguous sectors contain portions of the file. CP/M only identifies the block, as all blocks are of equal length. By having the capability of pointing to as many as 16 different portions of a disk, CP/M can reuse allocation blocks which become available anywhere on a disk as the result of killing off of old files. Further, CP/M normally can have additional extents in the case of fragmented large files scattered all over a disk. When a second or higher extent is needed, byte 13 of the next extent is set one digit higher than the previous extent in order to identify all the extents of a file and to show the order of usage. The anomalies in the MDM730 files make me wonder if Monte followed this convention.
When examining the directory of a TRSDOS disk (except V1.3), we are accustomed to seeing a multiplicity of ..../SYS files, which we know are the TRSDOS system files. But there are never any SYS files in a CP/M directory. This Is because CP/M has only one system file, and the loader knows where to find it by track and sector number. Also, the BIOS knows where to look for the directory, so there is no BOOT/SYS or DIR/SYS file entry, either.
I previously mentioned the allocation block, but it deserves more attention. In CP/M, the allocation block corresponds to the gran as used in TRS DOSes. In most CP/M's an allocation block is identified by only a single byte, and therefore the highest allocation block number is FFH (255D). (There can be exceptions to this, see "Inside CP/M" referenced at the end of this article.)
We will consider now only the SS DD MM system disk. Since two tracks are devoted to the system file, the remaining available space is 38 tracks of 18 sectors each, which works out to 684 sectors or 1368 logical records. Since the largest allocation byte is 255, and there are two logical records per sector, the ratio of 1368/256 is about 5.33, and the next larger whole number is 6. This means each allocation byte must hold 6 logical records, at a minimum. But CP/M can only have allocation blocks ranging in size from 1K to 16K in powers of 2, so Monte chose 2K for us.
But now we need to examine the implications of byte #16, which shows how many logical records are actually used in the extent of which it is a part. I worked through all the logical record counts and all the corresponding allocation block assignments, and confirmed that Monte has assigned 16 logical records to each allocation block on the system disk. 16 records of 128 bytes each thus gives 2K bytes per allocation block, which agrees with the 2K choice. Of course, 2K is the minimum space assignment for a file, even if the file contains only one byte. Note also that allocation blocks 00 and 01 are not shown in any of the various extents. This is because the directory itself occupies allocation block #00 and 01.
I began this essay with the idea that I could easily discuss the whole directory in one article. But here I am, out of space and with much more to say. I wish to acknowledge the valuable information I acquired by study of the excellent manual Monte supplied with our CP/M. That is "Inside CP/M, A Guide for Users and Programmers" by David E. Cortesi. In addition, I perused an article by Gene Cotton which appeared in Interface Age for December of 1981, which was also very useful.
Post a comment