Code_ The Hidden Language of Computer Hardware and Software - Charles Petzold [134]
Once you have the command processor in ROM, you can start experimenting with writing data from memory to the disk drive (probably in chunks that correspond to the sector size of the disk) and reading the data back into memory. Storing programs and data on the disk is much safer than storing them in RAM (where they'll disappear if the power fails) and much more flexible than storing them in ROM.
Eventually you might want to add some new commands to the command processor. For example, the S command stands for Store:
S 2080 2 15 3
This command indicates that the block of memory beginning at address 2080h is to be stored on the disk on side 2, track 15, and sector 3. (The size of this memory block is dependent on the sector size of the disk.) Similarly, you can add a Load command:
L 2080 2 15 3
to load the sector from the disk back into memory.
Of course, you'll have to keep track of what you're storing where. You'll probably keep a pad and pencil handy for this purpose. Be careful: You can't just store some code located at one address and then later load it back into memory at another address and expect it to work. All the Jump and Call instructions will be wrong because they indicate the old addresses. Also, you might have a program that's longer than the sector size of your disk, so you need to store it in several sectors. Because some sectors on the disk might be occupied by other programs or data and some sectors might be free, the sectors in which you store a long program might not be consecutive on the disk.
Eventually, you could decide that the manual clerical work involved in keeping track of where everything is stored on the disk is just too much. At this point, you're ready for a file system.
A file system is a method of disk storage in which data is organized into files. A file is simply a collection of related data that occupies one or more sectors on the disk. Most important, each file is identified by a name that helps you remember what the file contains. You can think of the disk as resembling a file cabinet in which each file has a little tab that indicates the name of the file.
A file system is almost always part of a larger collection of software known as an operating system. The keyboard handler and command processor we've been building in this chapter could certainly evolve into an operating system. But instead of trudging through that long evolutionary process, let's take a look instead at a real operating system and get a feel for what it does and how it works.
Historically, the most important operating system for 8-bit microprocessors was CP/M (Control Program for Micros), written in the mid-1970s for the Intel 8080 microprocessor by Gary Kildall (born 1942), who later founded Digital Research Incorporated (DRI).
CP/M is stored on a disk. In the early days of CP/M, the most common medium for CP/M was a single-sided 8-inch diskette with 77 tracks, 26 sectors per track, and 128 bytes per sector. (That's a total of 256,256 bytes.) The first two tracks of the disk contain CP/M itself. I'll describe shortly how CP/M gets from the disk into the computer memory.
The remaining 75 tracks on the CP/M disk are used for storing files. The CP/M file system is fairly simple, but it satisfies the two major requirements: First, each file on the disk is identified by a name. This name is also stored on the disk; indeed, all the information that CP/M needs to read these files is stored on the disk along with the files themselves. Second, files don't have to occupy consecutive sectors on a disk. It often happens that as files of various sizes are created and deleted, free space on the disk becomes fragmented. The ability of a file system to store a large file in nonconsecutive sectors is very useful.
The sectors in the 75 tracks used for storing files are grouped into allocation blocks. Each allocation block contains 8 sectors, or 1024 bytes. There are 243 allocation blocks on the disk, numbered 0 through 242.
The first two