MULTI-TASK DDT SYMBOLIC DEBUGGER
	N O T A    B E N E

	This program is NEW and not thoroughly tested.
Bugs may appear and you may have to tailor it to your liking.
However, since all DDT functionality is unaltered and the
multi-user features only appear if MU$DBG is defined at DDT
assembly (and are  only usable if that DDT is linked with
DDTMU), this software is included. It should help those who
have only small amounts of address space left in their tasks
below 32K. The DDTKNL module requires only 133 words (decimal)
if hardware floating point support is not needed; 199 words
are needed if floating point is to be supported. The scheme
used is a last resort where you don't have enough address space
to insert a normal debugger (even Octal debugging Tool -ODT).
However, you may like DDT enough to use it generally. Look at
the DDT source for documents. The first part contains a brief
manual section, and the code is the final reference for
conditionals, etc. Also buried in DDT source is how to get it to
have an effective "memory breakpoint" which basically single
steps through the program and monitors a memory cell to see
if it changes and breaks if it does. The code is there but
a conditional assembly normally excludes it.
	Use with some care, but use this stuff. If there are
any problems, let me know and I'll try to fix them.
			Glenn Everhart
			206-1, RCA GSD Engineering Staff
			Rt. 38, Cherry Hill, N.J. 08358
			(609)-338-6022
			home: (609)-261-3709

  DDT22M is a debugger that will let you debug very large
programs with DDT. It is a separate conditionally
assembled version of DDT which you link with DDTMU into a debugging
task named DDT22M (it MUST run under that task name).
To use the package, you link your task normally but adding also
a small program called DDTKNL whose purpose in life is to
communicate with a version of DDT22M that is already active when
you start your task. (See the comments at the front of DDTKNL.)
Then DDT22M gains control again and allows you to issue DDT commands
to map to your task. The main RESTRICTION of this is that your
task must NOT MOVE in physical memory while DDT is debugging it.
DDT is actually addressing arbitrary PHYSICAL MEMORY which
happens to be occupied by the task it is set to debug. If the
task moves, DDT does not know that and it will not do sensible
things. Note that if you get a Bad Entry breakpoint anytime
after the initial startup of the task to be debugged (it is normal
to get one at first once the task is initialized, so you can
tell DDT to map to it and then Go to start it and get the DDT
task into a fixed wait loop) it probably means your task has
moved. You can remap to it by another UL'tsknam' command to DDT
but must be a bit careful. I may do an automatic UL'tsknam'
later on, but am reluctant to just now since that will introduce
incompatibilities with IAS which is used at sites I wish to support.
Also, that is a bandaid because there is no guarantee the task will
not be moved after it is located. In IAS users have to locate the
task physically themselves and set virtual mapping registers
for DDT. In RSX11M and RSX11M+ I have code to do the mapping by
task name.
    To use, first link your program with DDTKNL/DA. That would be
a link of form (assuming sources and objects in [3,177]):
   TASK/FP/CP=INPUT1,INPUT2,...,[3,177]DDTKNL/DA
and will allow your task to be run under DDT control.
	Now run DDT22M. Use a command like
RUN [3,177]DDT22M/TASK=DDT22M
which will force the task name to be right. Be sure the system
is fairly quiet since you don't want stuff moving around.
Now DDT will type a message and await your starting it.
Type $G (ESC, G) to start the DDT task up. It will sit
there and await a message from your task now.
	Now run your task. it will send a message to DDT and suspend
itself, so DDT will restart and should type a BE0000 (or some such)
message. Now use the $UL'tsknam'  command to map DDT to your
task, the $UM command to turn on the DDT virtual map, and then
enter breakpoints and finally you may type $G to start your
task up again. Your task will now run and appear to be controlled
by DDT.
	A word of caution: the terminal is not attached, so don't type
too fast or DDT may not get your typed characters. If MCR sees
them they will produce error messages; nothing to worry about
but a nuisance. DDT probably won't understand a partial command
either. It may be a good idea to be sure DDT's priority is higher
than your task's. DDT22M priority in [3,177] will default to
60, which will usually be OK. You may want to set your terminal
/FDX to use this stuff.
    It is possible to assemble DDT22 to attach its console LUNs
by defining AT$$$ (see the source) but this could cause problems
if the task being debugged wants to use the terminal, so the default
is not to attach in DDT. Systems with pairs of nearby termimals may
want to run the two tasks from different ones. In IAS, this could
prevent the communication from working right, but the terminal handler
there allows type-ahead even with no attached LUNs so the right
solution there is not to attach TI:.
			Glenn Everhart.  11/19/80