This may come as a surprise to you, but chances are you've got DEBUG. If, like most personal computer owners today, you use the MS-DOS or PC-DOS operating system, you received this invaluable and fascinating utility program as part of the package. But since DEBUG resides in splendid isolation on an obscure disk called "DOS Supplemental Programs" that is easily ignored, many users know nothing about it. DEBUG deserves better.

Granted, its primary application is for high-powered programmers, who use DEBUG to find and eliminate problems ("bugs") in their assembly-language code. But the program can also be fun and instructive for us low-powered everyday computer users. If you (or your kids) have any curiousity about what's going on inside your IBM-PC, PCjr, or clone, DEBUG is an excavating tool that lets you dig into nooks and crannies of memory, disks, and programs. It will translate machine-language gobbledygook into a form that is legible to people. It can also do the reverse: It lets you create simple assembly-language programs without shelling out the money for a separate "assembler" program.

If you use the CP/M operating system, you have a powerful variant of DEBUG called "DDT." This acronym (it stands for "Dynamic Debugging Tool") is CP/M's only pun: DDT kills bugs. The general points we make here about DEBUG apply as well to DDT. For specifics of DDT usage, you'll have to turn to those awful CP/M manuals.

The instructions for DEBUG in the MS-DOS manuals look forbidding, too, but the program can be fairly simple to use.

You load the program by typing in "DEBUG"; the disk will spin and you'll then see the no-nonsense DEBUG prompt, a plain hyphen: "-". At the prompt, you type in various one-letter commands -- e.g., "d" (to display the contents of a memory location), "f" (to fill it with new data), "a" (to assemble a program), or "u" (to "unassemble," or turn machine code into human form). Each command is followed by the memory location(s) you want to work on.

A simple example: buried deep in the Read-Only Memory of every IBM-PC is a "release date" telling you how up-to-date your version of the basic IBM control system is. DEBUG will find the date and translate it into a form you can read. At the DEBUG prompt, type the following (the notation " E " means hit the ENTER key):

d f000:f555 fffc E

This command tells DEBUG to display the contents of memory beginning at address f000. The computer returns a string of hexadecimal numbers and, at the right side of the screen, your machine's release date. If your date is earlier than May 1981, incidentally, your system has some bugs that an IBM dealer should fix for you.

Because DEBUG can penetrate into the heart of your computer's operations center, you can use it to change, or "patch," some standard operating instructions or default settings that you don't like.

Let's say, for example, that you've grown sick and tired of that bland cursor found on the IBM-PC and its clones -- that insipid blinking line. There is a way to design an alternative cursor, but you have to know how to get to the right spot in memory.

In a BASIC program, you can redesign your cursor using the "LOCATE" statement. Type in this one-line program:

10 LOCATE,,1,1,9 [E]

Now type "RUN" and voila! There's your new cursor. But it only lasts as long as you're in BASIC. Using DEBUG, in contrast, you can assemble an easy little program (which we've borrowed from Karl Koessel) that will give you a custom-designed cursor any time you want it.

Call up DEBUG. At the "-" prompt, type in the following lines:

F100 LA B4 01 B5 02 B1 0A CD 10 20 [E]

R CX [E]

A [E]

N [E ]

W [E]

That "W" command will write your new program to disk. When it's finished, you'll get the "-" prompt again. Type in "q," to quit DEBUG and go back to the DOS prompt.

Now type in the name of your new program: "CURSOR." The program will run and you'll get your newly designed cursor on the screen.

To get back to the standard cursor, you could write a new program with DEBUG. Or you can just do a warm boot (i.e., hit the CTRL-ALT-DEL combination) and the system will come up in standard fashion.

I don't mean to suggest that cursor-redesign capability is the only virtue of DEBUG. Instead, I'm suggesting that this is a useful and interesting tool that you can turn into a powerful force on your machine. To pursue this further, track down the fine text "Assembly Language Primer for the IBM PC & XT," by Robert Lafore (NAL $21.75). It shows how to get the best of DEBUG.