Small Tools
Hard Disk Lore and First Aid Part III
by David Small
Once more into the breach. This issue, we'll look just a bit deeper into the ins and outs of disk handling.
GEMDOS and RWABS
When GEMDOS and the Atari ST were designed, it was decided that disk drive accesses of all kinds would go through one call, known as RWABS (pronounced, "rabs"). RWABS is short for "read-write absolute number of sectors." RWABS is thus a system subroutine available to any program for disk access.
When GEMDOS wants to read sectors in, it makes a call to RWABS; when it wants to write, it calls the same place. It's much like a GOSUB to a common routine that handles disk input and output.
Application programs, such as Flash, usually talk to the disk via GEMDOS because they're doing file-related things. Applications tell GEMDOS things like, "open this file and read 10,000 bytes from it." GEMDOS would handle the actual sector requests to do this (via the RWABS subroutine) and slice-and-dice the sectors into whatever is needed.
|
Figure 1. A RWABS interceptor might look like this.
If you're using floppies, RWABS talks directly to the extended BIOS floppy handlers, FLOPRD and FLOPWR, to handle the actual floppy work. You can find out more about FLOPRD and FLOPWR in the extended BIOS manual that is a part of the ST Developer's Kit. You'll also find the actual nit-picking RWABS parameters there (which is good, since I don't have room to cover them here).
A quick summary of the RWABS details is useful, however. To read sectors 50-89 off the first hard disk into location $45678, you'd do:
rwabs (0,$00045678,40,50,2)
This means "Read 40 sectors, starting at number 50 (thus, 50-89), from device 2 (drive C:), into location $45678."
How to Steal RWABS
Now, one handy thing about RWABS is that it may easily be "stolen." You direct the RWABS "hook" to your program and then intercept all RWABS requests; if you want to handle them, you do it directly. Those you don't want, you give back to the system by jumping to wherever the RWABS hook used to point.
Naturally, if you grab RWABS, you must do it with a terminate and stay resident program (TSR), which stays loaded in memory. (Otherwise, the next program you load will clear your program, leaving RWABS pointing into who-knows-what.) The classic example of this is a RAM disk; you set up your RAM disk driver to handle all requests to device #2 (drive C:), and pass any requests that aren't for #2 to the other RWABS drivers, say, floppy or hard disk.
If you write a RWABS interceptor, such as the example in Figure 1, then you are in control of all disk accesses on your machine--RAM disk, floppy disk, and hard disk. Thus, if a RWABS disk request is made for device #2, C:, the one we want to handle, we grab it away from the system and do it ourselves; if it's for the floppies (0-1) or hard disk (3-?), then we go back to the regular system RWABS handler and let the system worry about it.
Now, when your ST first starts up, it only knows about one sort of disk drive, the floppy disk. It doesn't really have much code in the onboard ROMs (programs prestored in the machine's chips) to worry about the hard disks or a RAM disk. The code from those must come from disk.
|
Figure 2. This is a pretly broad overview of GEMDOS and RWABS.
If you want to add a RAM disk, you must load that program from disk. You can either do it by hand, put it in the AUTO folder to be run automatically, or make it into a desk accessory which is loaded at startup time. All three options boil down to the same thing: they're programs loaded at system startup time that stay in the computer's memory as long as it's turned on. They all do the same thing: steal RWABS, direct it to your code first, then if your code doesn't want to handle the request, pass it back to the regular system floppy drivers. You can, therefore, daisy-chain many RWABS handlers (see Figure 2).
Hard Disks ond RWABS
Now, what happens with the hard disk? How is it hooked into RWABS? Essentially, it's hooked in the same way as RAM disks.
The 1985 (first) pass of ST hard disks were "floppy bootable"; you couldn't start up--boot--directly from the hard disk. What you had instead was a floppy with an AUTO folder containing a "hard disk driver"; it was simply a RWABS handler. When run at startup from the AUTO folder, it would direct RWABS to a portion of itself and tell the ST to leave it in memory for good ("terminate and stay resident").
Then, if the TSR driver program saw an RWABS request it thought it should handle it would do all sorts of things to the DMA controller chip to talk to the hard disk, send in the request, handle it, and return directly to the user without bothering the system RWABS any further.
This "hard disk driver" steals RWABS away whenever it gets a request it thinks it ought to handle. On most ST hard disk systems, this means it kicks in for drive C: on up. If you've got a RAM disk installed as C:, then the hard disk handler worries about drives D: on up. The order that the RAM disk and hard disk installers are run will determine the drive letter.
How does the hard disk driver know which requests to handle? Or, translated into user-ese, to which drive letters does the hard disk respond? On start-up, the hard disk driver reads sector 0 of the hard disk, the partition sector. It finds out how many partitions there are and where on the hard disk they begin. Then, the hard disk driver remembers the following:
1. How many drive letters (devices) it has to handle. If we have four partitions, it knows to handle C:, D:, E: and F:. The handler is smart enough to ignore non-GEM (e.g., Magic Sac/Spectre) partitions; they are "skipped over" and no drive letter is assigned to them.
2. The offsets for each partition. For instance, assuming that the total number of sectors used by drives C:, D:, and E: total 30004, any RWABS request to drive F: has to have 30004 added to the "starting sector number" to offset it to the actual F: partition area of the hard disk. Thus, while you perhaps ask for the tenth sector of drive F with your RWABS call, the hard disk driver returns you sector # (30004 + 10), or 30014.
If the hard disk driver cannot read the partition sector when it starts up (at system startup or any other time it is run), then it will not try to handle any hard disk requests ever. Even though the hard disk handler code might be installed in memory, it doesn't think a hard disk is connected and working, so it ignores all hard disk requests. This means you are doomed until you either reset the machine or re-run the hard disk handler with the hard disk working.
The Dread Power Strip Problem
The timing here is mighty important! Let's say you've plugged your hard disk and ST into a common power strip switch, which lots of people do. You then turn them both on with a single flick of the switch.
Your ST starts up instantly, but your hard disk does not. The hard disk has to spin up to 3,600 RPM, stabilize at that speed, move the head to track 0, and do all sorts of recalibration nonsense. A typical hard disk takes 10-30 seconds to get ready.
The ST will start up, briefly read the floppy disk, read in the hard disk driver from that floppy disk, and then try to read the hard disk's partition sector. (We're not covering autoboot yet). The hard drive will tell the ST that it isn't awake yet; the ST will get tired of waiting for it and report an error on reading the partition sector. The hard disk driver will then conclude that there's no hard disk hooked up and tell itself to ignore all hard disk requests. Thus, you'll have no access to the hard disk, which is embarrassing. (At this point, it's reset or cycle power time).
The hard disk must be spinning and ready before you power up the ST if you expect to read in the partition sector (and thus expect to be able to do anything to the hard disk).
An Added Layer Of Complexity: Some hard disk drive controllers (OK, OK, some Atari-only brand controllers) will "crash" if the ST is powered off. This is because the ST "jiggles" the control lines to the hard disk as it is turning off and some hard disks can't handle that. The only way to fix this problem is to cycle the power to the hard disk.
This can lead to an incredibly irritating series of events:
1. You switch on both your ST and your hard disk.
2. Your ST can't instantly read the hard disk and reports "no hard disk connected." The hard disk eventually wakes up.
3. You then switch off your ST to cycle the power--to "try again."
4. Your hard disk locks up when the ST's power is cycled and goes to sleep for good.
5. Now you switch on your ST again; it still reports there's no hard disk connected, since now the hard disk has locked up.
6. You cycle your ST's power once again, but there's still no response.
7. (Usually) it's time for a call for help: "My hard disk is dead!"
For people with this type of hard disk, this means that any time you turn off your ST, you'll also have to turn off the hard disk, turn it back on and let it get up to speed and only then turn your ST back on. Whew!
Enough for now? Next month we'll be back for more!
David Small is the creator of the Magic Sac and Spectre 128 Macintosh emulators for the ST and a Contributing Editor of START Magazine.