Classic Computer Magazine Archive ST-Log ISSUE 35b / SEPTEMBER 1989 / PAGE 70

ANY RESOLUTION

RWABS Monitor

DAVID SMALL AND DAN MOORE

As you may know, RWABS is a favorite hangout of Dan's and mine. Some people go to bars, some to nightclubs, but Dan and I hang out at RWABS, drinking Boodles gin and Strohs beer, hacking the night away.

Ah, the romantic life of a computer programmer.

What's RWABS? RWABS is short for "read/write absolute." It's the place the system goes for any disk I/O. It's also the place people like Dan and I hook into to do things involving the disk.

RWABS Monitor is a utility program that monitors RWABS. Any time RWABS is called (meaning any time a disk request occurs), RWABS Monitor puts a small message in the upper right-hand corner of your screen, telling you about the request.

Typing it in

Listing 1 is the ST BASIC program that will generate your copy of RWABS Monitor. The resulting file, RWABSMON.PRG, is not a BASIC program; however, it is instead 100% machine-language. Type in Listing 1 using ST Check (found elsewhere in this issue) to check your work, and run it with ST BASIC. The file RWABSMON.PRG will be written to the disk in Drive A.

The complete assembly language source code was too large to print in this magazine. It is available on this month's disk version or from the databases of the ST-LOG ST users' group on DELPHI.

Using the program

At first, this program seems sort of like "gee whiz, that's nice, but...." Then you begin to see its usefulness.

For instance, when your hard disk begins the fill-up, slow-down problem, you'll first see it on RWABS. Disk errors also show up in RWABS. It brings you up to date on what your disk is doing. Better, since RWABS Monitor is always active, it's active in the middle of other programs, so you can see what they're doing as well. It's like having a ringside seat at DOS working with the disk.

RWABS Monitor also demonstrates some interesting programming techniques. To make it work, I had to do some novel programming—stuff you can use in your code:

  1. Trap #1 interceptor: This code looks for all RWABS calls and intercepts them, triggering the screen display if it's an RWABS. Ever wanted to know how to write a trap interceptor? They're mighty useful. An easy adaptation of this code would let you direct a copy of all console output to the printer, like for SID debugging printouts. Nice, eh?
  2. Direct screen I/O code: This neat piece of code lets you output strings, bytes, words, longs in hex and other things to a monochrome monitor or color monitor directly. This is extremely valuable during debugging. Sometimes you need a way to output (let's say) a variable without using the operating system. This happens all the time. For instance, you can't output when GEM is busy, when the disk is busy, when you're in a time-limited interrupt, when a graphics screen is up, and on and on.

    Using the font driver included, you can output characters and data anywhere you like at any time. A little work will adapt it to any C or other application. This code works by using the ROM tables that contain character images and copying them selectively to the screen. The code to do color screen updates is particularly hairy because of how the color screen is laid out. It wasn't a lot of fun.

    Originally, the code was done for the "crash" display on the Magic Sac, but I've improved it a lot since then. Since there is no trace of the Atari operating system left when the Sac is running, the display code had to completely stand alone. (Still, if you want to see what a chunk of the Sac looks like, here it is.)

  3. Terminate and Stay Resident: how to keep your program hanging around after it ties itself into the operating system so the next program to be run doesn't get rid of it.

Using the program

To use RWABS Monitor, either double-click on it or put it in your AUTO folder. When run, it'll give you a sign-on display. Then it goes to work. With the next disk access it plots a status line at the top right of your screen. You get:

  1. Drive letter doing the access (A-P).
  2. Which sector the disk access starts at, in hex.
  3. How many sectors are being requested, in hex.
  4. Where the data is headed for in memory, in hex.

It won't work in low-resolution color because there isn't enough room to pack all that information in.

It's fun to watch RWABS Monitor work, particularly on a hard disk or RAM disk. Accesses fly by. Try doing a show-info, for instance; you'll see all kinds of activity.

Let's take one sample (and common) problem and diagnose it with RWABS Monitor.

Your disk is getting a "Disk A is getting an error, Cancel/Retry" message. You want to find out what's wrong, so you load RWABS Monitor and go try out Disk A. You see that Sector 1 is being read and read. There's a long pause. Then you get the disk-error message. Conclusion: Sector 1 is zapped. Go to a disk-fix program and correct it.

Or, in a program load, you see Sector 45 being reread many times just before a TOS ERROR 35 message. Again, Sector 45 is your problem; that portion of your program has died. (A good check-disk program can also help in this diagnosis.)

Finally, if you have a hard disk that has more than a few megabytes of data on it, you'll see the write slow-down problem in detail. TOS will painfully and slowly read the FAT sectors, looking for an empty place to put the data. When it finds an empty area, it'll write the data extremely fast. (Of course, if you're using a program like FATSPEED.PRG, you don't have this problem.)

See what I mean about a front-row seat at disk access?

Conclusion

It may seem esoteric. It might seem like useless information. But after a time, RWABS Monitor grows on you. It really helps you keep an eye on your disks.

My luck with disks of all sorts has never been good, so I feel anything I can do to monitor disk drives is good. They're generally the flakiest part of a computer system. RWABS Monitor has a permanent home in my AUTO folder. I hope it finds a home in yours.