Category : Assembly Language Source Code
Archive   : D86V372.ZIP
Filename : D08.DOC

CHAPTER 8 COMMONLY ASKED QUESTIONS


Setting Registers

Q: Why isn't there a debugger command to modify register
settings?

A: You can do so with an immediate assembly language command. For
example, to set the AX register to 100 type MOV AX,100 You
can now also set segment registers this way: MOV DS,0 REMEMBER
that if there isn't a leading zero, all constants fed to D86
are assumed to be decimal. If you want hex constants, supply
a leading zero.

Q: How do you reset the CS register? MOV CS,value doesn't work.

A: You issue a far JMP instruction to be executed immediately.
For example, to set CS to 0 and IP to 400 hex, type JMP 0:0400



Modifying Memory

Q: Why aren't there commands for changing memory to different hex
values, or for filling memory with a given value?

A: You can do this very effectively with D86's patch memory mode.
Just issue an immediate JMP to the location you want modified,
press the F7 key to enter patch-memory mode, and then issue
any A86 directive to initialize memory: DB for bytes, DW for
words, DD for doublewords, etc. Remember, you have the full
power of the A86 language at your disposal. You can provide
lists of values on a single line:

DW 0100,0101,MY_SYMBOL

You can make ASCII initializations with strings on DB lines:

DB 'This is a string',0D,0A,0

You can use the DUP construct to fill memory with a given
value or sequence of values:

DB 100 DUP 0, 10 DUP (1,2,3)


Screen Problems

Q: My debugger screen gets corrupted whenever the program being
debugged outputs to the console. What can I do about it?
8-2

A: This problem exists because D86 cannot quickly refresh the
screen on computers using the CGA (Color Graphics Adaptor)
video interface, without filling the screen with annoying
"snow". So on a CGA computer D86 tries to keep track of what
it has output, and refresh only the parts of the screen that
have changed. The strategy fails if the program itself
changes the screen. You can restore a trashed screen by
pressing the Alt-F9 key.

I haven't had the chance yet to implement a more sophisticated
screen interface, allowing you to switch between the program's
and the debugger's screen. Until I do, you have these
options:

* You can keep pressing Alt-F9 a lot.

* If your program is making simple, teletype-style outputs
using MS-DOS function calls, you can redirect standard
output to your printer for the debugging session.

* If you're really doing serious development of a
heavily-video program, you should consider getting a second,
monochrome-interface monitor for your computer. Starting
from your CGA display, invoke D86 with the +V option. D86
will come up on your monochrome monitor, but the program's
cursor will remain on the CGA monitor.


Debugging ROM

Q: I tried stepping into a ROM BIOS routine. It worked for a
while, but when I got to a certain instruction and stepped,
the computer crashed. What's wrong?

A: My official policy on stepping into ROM is, "all bets are
off". D86 does better than many debuggers at stepping into
ROM, but there are still some fairly insurmountable problems.
First, D86 itself calls the BIOS. Not all BIOS routines are
reentrant; you could get unfortunate interactions between the
call being stepped and calls made by D86 while you are
stepping. Second, ROM cannot be modified and hence traps
cannot be set within ROM. D86 doesn't try to detect failed
trap-setting, so the program may be set loose in situations
where D86 thinks (and you think) it will retain control.

This will always happen if you try the F2 key in ROM. It will
also happen if you try to use the F1 key on an instruction
that loads a segment register. For arcane reasons, the
single-stepping feature built into the 8088 doesn't work on
such instructions, so D86 must single step them with a trap.
Thus, F1 on a segment-loading instruction in ROM will set the
program loose.