PDP-11‎ > ‎


XXDP Mini User Guide

XXDP is the diagnostics package for PDP-11 systems. Last time I looked (Jan, 2002) version 2.2 and 2.5 were available from: sunsite.unc.edu

These are RL02 image files in *.gz format (3.2 and 3.6 Mb), the most recent (Version 2.5) is dated 1989. I have two older versions on RL02 disk packs, one dated 15-SEP-82 the other has a range of dates in 1981. Both seemed pretty cryptic to a first time user, ie myself. Naturally none of this comes with manuals! I pieced together the information below, and then found a very nice Acrobat document which I recommend: XXDP.pdf
If you are using a RQDX controller and still have a functional RQDX drive you want to format look at this page
I've left my original text below and added some information on the XXDP file format and methods of creating bootable TU58 Images that is not in the Acrobat document.

I am a big fan of John Wilson's E11 program. If you download one of the versions of XXDP from Sunsite, you can run it under E11 on a PC clone. I image SIMH will also work this way, I've just never tried it. One of the features of this is that you can create customized bootable images of the test programs you might want for your particular system this way. I have succeeded in doing this with disk images and TU58 tape images as described at the end of this document. John's PUTR program, V2.0, will mount most XXDP images, but will not create a new image file. PUTR can be used to copy files from one image to another, or transfer the image to a floppy mounted on a PC. Unfortuately I can't get PUTR to mount XXDP images of TU58 tapes nor RX02 and RX01 disks (these use a slightly different format, DOS/BATCH, that I can't get to work). Both of John's programs can be found at: ftp://ftp.dbit.com/pub/

First as indicated above, there are a number of versions of the 
XXDP package, all a bit different.  I've seen it on TU58 tapes, 
RX02 floppies, and a single RL02 disk.  Newsgroup references 
suggest it is often available on magnetic tape.  Given a version 
on one set of media, you should be able to create others.  There 
appear to be two major releases, version 1.x and 2.x.  I recently 
downloaded version 2.5, it has a small monitor and extended 
monitor (the default). The small monitor of version 2.5 is for 
systems with less than 28Kb of memory, its very similar to the 
earlier version 1.x monitor. Version 2.5 has 727 files in the 
directory listing.  My 1982 RL02 distribution has a little more 
than 800 files.  All the verisons I've seen share some common 
features, the most important is that the directory structure is 
unique to these disks.  They are self booting.  Once booted XXDP 
displays some version information and an RT11 style prompt, '.'.  
This is the XXDP monitor, the commands are similar, but major 
version specific. All have a help command, and if a printer is 
available you can get hard copy.  If you have a disk image on a 
PC, you can use my Dos utility Diagdir.exe or John's PUTR program
to obtain a directory and a copy of the help file. 

         VERSION 1.x

The directory command gives you a list of files on the load 
media. I get confused when I look at this listing as there are a 
lot of files with odd seeming extensions.  The help file from my 
1981 distribution says the naming convention for Monitor and 
driver files uses the DEC two letter DEVICE MNEMONIC in the file 
name. All have the *.sys extension.  A monitor file begins with 
HM while a driver file begins with HD. Utility files begin with
HU, HUDI??.sys is the directory utility program.  IE if XX is the 
mnemonic and ?? are wild cards the form is as shown below followed 
by examples for DD,DY, and DL. A different monitor is required for 
each device type.

-------   -------	------		-----------
XX	HMCT??.SYS	HDXX??.SYS	the XX devices
The ?? wild cards above are apparently version numbers.

         VERSION 2.x
There are only two monitors with their associated DRS programs.
One of these pairs and the device driver for the media are required.
The SM versions are for systems with less the 28K of memory.
XXDPSM.SYS - small monitor
DRSSM.SYS  - diagnostic runtime services for small monitor
XXDPXM.SYS - extended monitor
DRSXM.SYS  - diagnostic runtime services for extended monitor
??.SYS     - device specific driver files
DIR.SYS    - the directory utility program

Note that Version 1.x does not support wild cards in the
directory command, D ; however the Version 2.x extended
monitor command, DIR, does.  Both versions use the same
naming convention for diagnostics as indicated below.

I had to ask on the PDP-11 newsgroup to find that the diagnostics 
are named a little differently.  One uses the letters from the 
type of device to form a mnemonic ie for RX02 disks use RX, for 
RL02 disks use RL, for the DLV11 SLU use DL. Again using XX as 
the mnemonic, search the listing for occurances of ?XX???.???, 
sample output from Version 2.5 with a search for RL is shown 

.DIR ?RL???.???


  109  NRLGA0.BIC       1-MAR-89         19    006017
  211  VRLAC0.BIN       1-MAR-89         24    013033
  212  VRLBC0.BIC       1-MAR-89         28    013063
  351  XRLAK0.OBJ       1-MAR-89          7    015535
  592  ZRLGE0.BIC       1-MAR-89         19    031562
  593  ZRLHB1.BIC       1-MAR-89         27    031605
  594  ZRLID1.BIN       1-MAR-89         30    031640
  595  ZRLJC0.BIC       1-MAR-89         23    031676
  596  ZRLKB3.BIC       1-MAR-89         26    031725
  597  ZRLLC1.BIN       1-MAR-89         14    031757
  598  ZRLMB1.BIN       1-MAR-89         23    031775
  599  ZRLNC0.BIC       1-MAR-89         29    032024


Note someone was kind enough to send me the listing above as
an example, but you should be able to generate it with E11
or a real PDP11 if you have the appropriate media. 

The full directory listing shows a number of prefix letters as 
well as different extensions.  I believe the 3 letters following 
the mnemonic are version numbers.  The first letter indicates
the CPU type for the diagnostic, 'Z' is generic and will run
on all CPU types. 

Then there are different extensions, "BIN" (binary), "BIC" 
(binary/chainable) and "OBJ".  You can run both BIN and BIC, but 
apparently only BIC are chainable.  The meaning of an "OBJ" file 
is clear, apparently they can be used with DEC/X11 to create
customized diagnostic series.  I do not know how to do this,
apparently one runs DXCL.BIN, the automated testing configurer
and linker.

To create a bootable XXDP version on new media, you have to
run a version specific program.  For Version 1.x use UPD2
and for Version 2.x use UPDAT as described in the sections below.
Its prompt is the '*' character, the first step for both versions
is to issue the command "zero XXn:" to set up an empty file and
directory structure.  In this discussion XXn is the device mnenonic
for the new media.

XXDP Version 2.x Extended Monitor responds to the following commands 
    (see help topic for details):

LOAD      NOTES     PRINT      RENAME  RUN   SET        START       

As mentioned above, the UPDAT program is used to create customized
versions on new media. This program uses the same commands as the
version 1.x UPD2 program. However, commands SAVM and SAVE are
no longer supported.  The following command has been added to build
bootable media. It will work with tapes or disks.

CREATE XXn:    (XXn = DY0 creates a bootable DY from your system media)

After doing a create, copy the desired diagnostics to the new

XXDP Version 1.x  and Version 2.x SM monitor respond to the following commands:

          R              run a program
          L              load a program
          S              start a program
          C              run a batch job (chain)
          D              list directory of load medium
          F              set the terminal fill count
          E              enable alternate system device
          H              type help information

Help is of coarse useful, and you might want to print it.
One method is to capture the listing with a terminal emulation
program.  Alternatively if you have a printer connected to 
your machine, you may be able to print it directly.  Run the UPD2 
program and use the print option.

The UPD2 program allows one to create new copies of XXDP+ on other 
media, for instance you can custom taylor the diagnostics you 
need onto a floppy disk or TU58 tape.  The HELP.txt file should 
tell you how to use it.  I gather the UPD1 program is a short 
version of this to be used if you don't have much memory.  

Note that if you are building a custom media distribution under 
version 1.x you must have the driver file and the monitor on the 
new disk.  You get the monitor installed on disk media with a SAVM 
command and tape media with a SAVE command (see help file).
For the Directory command to work you also need the directory 
program, HUDI??.sys, in addition to the driver file HDxx??.sys.  
The help file, help.txt, is also recommended.  Copy these files and 
the desired diagnostic programs onto the media with the PIP command. 

XXDP File Structure

One other minnor aside. I got interested in the directory structure, and wrote a C program which will parse it out if you have a disk image of the distribution on a PC's hard disk. Its DIAGDIR.EXE included in RT11ARC.ZIP. This Beta version of the program displayed directories and extracted files. June 19,2001 Ian Hammond posted a preliminary document on the vmsnet.pdp-11 newsgroup which describes the XXDP file structure. Both Ian and John Wilson have been very helpful in getting me as far as I have. Ian hopes to finish his document soon and post it on his web site at http://www.hammo.com/pdp. Until then I am posting a mirror of his most recent post here so I don't lose it along with an addendum he mailed me directly.
In a private communication with John Wilson, he also suggested 
looking at the PUTR.ASM source code, searching for the string:
"subttlDOS/BATCH file structure".  The comments following this
heading describe the format of the XXDP disks.  It appears that some of
the smaller media {TU58 tapes, RX01 and RX02 disks} use a
DOS/BATCH file format while most of the others use what John calls
the XXDP format.  In summary the XXDP format has a Home block which
combines the DOS/BATCH HOME block and associated MFD2 directory pointer.
   boot block          boot block
   home block          home block
   MFD2 block          bitmap blocks
   directory blocks    directory blocks
   bitmap blocks       monitor image
   monitor image       data files
   data files

Although the file structure specifications allow random placement of the
bitmap and directory blocks, I have only seen them as contiguous groups
in the order shown above.  For details see the references above.
I have been interested in how to intialize XXDP images. It appears that most *.sys files share an additional header format. They have a link word as the first word in each block, but they also have an additional SYSHDR which is three WORDS long. SYSHDR {lda_id,bytes,offset}
I was confused about this format, but Ian's addendum clears this up explaining its in absolute loader format, LDA. All the blocks in Version 1 *.sys and most Version 2 *.sys files seem to follow this format. The last block of XXDPSM.sys does not conform, and only the first block of XXDPXM.sys conforms to this. I have no idea why these exceptions exist.

The algorithm I used to extract the conforming *.sys file blocks was as follows:
skip lda_id, which is always 0x1 in a valid SYSHDR
use bytes as the valid number of bytes in this block (after skipping the 1st word)
use offset as the offset into buffer to load next group of data
The data starts 6 bytes after the beginning of SYSHDR or 8 bytes after the beginning of the block. Given that this system skips the link word and the next 3 words and uses the last byte as a checksum, a full 256 word disk block has a bytes value of 0x1fd (509. bytes). For each block read, append (bytes - 6) bytes of data to the memory image, img, of the file starting at location = (image+offset). It appears that when the bytes word != 0x1fd you have read all the data. This final data block is in the last block of the file for all but the two XXDP?M.SYS files. XXDPSM.SYS has an extra block at the end and I do not know what function it preforms. XXDPXM.SYS any has 12 data bytes which conform to this in its first block.

Per above, most Version 1.x and 2.x *.sys files follow this format. In Version 1.x there is a HM????.sys file for each monitor. One strips the memory image per the algorithm above and inserts it in the disk image at the appropriate location per the table above. After stripping the code from the HM????.sys file, its first 0x200 bytes contain a device specific primary boot block. For Version 1.x this block must be copied from the monitor to the disk image boot block.

In Version 2.x the device specific monitor image must be created from XXDPSM.SYS and the *.SYS driver file for the target device. I'd be interested if anyone can tell me why the following works, but it appears the last block in the XXDPSM.SYS file is not used to create the monitor image. This last block contains a link word of 0 as the first word in the last block as expected, but does not have an appropriate SYSHDR header allowing one to strip data bytes from the block. The 2nd to last block contains a SYSHDR header which indicates it is the last data block because the bytes field is less than 0x1FD. My algorithm is to strip data from all but the last block in XXDPSM.SYS and insert it at the appropriate location for the monitor image in the new disk image while counting the total number of bytes inserted. Round this number of bytes up to an integral number of 0x100 bytes to obtain the location, DPTR, for inserting the device driver image. Insert the device driver by stripping the data bytes from the driver file corresponding to the type of physical device for which the disk image is being created. Finally the primary boot block from the device driver must be copied to the beginning of the monitor image (overwritting what was copied in from XXDPSM.SYS) and to the first block in the disk image. The word beginning at byte pointer DPTR + 0x6 is the offset from DPTR to the location of the beginning of the primary boot driver in the newly created image.

I'm puzzeled by the XXDP?M.SYS files. Per above I do not know what is in the last block of XXDPSM.SYS. The XXDPXM.SYS file has the appropriate LDA SYSHDR header in the first block, but none of the remaining blocks. I assume the boot code in XXDPSM.SYS which checks for the existance of XXDPSM.SYS on the disk loads the majority of this file as a data file if it is found. Any thoughts on this would be appreciated.

In version 2.x disk images all the *.SYS files have some common information, including a version field, in the first block. Looking at the raw data in the disk image, the first four words are the link field followed by the three words in the SYSHDR header, {lda_id,bytes,offset}. There appear to be at least 6 additional words with generic usage. The following table describes the uses I know about using their byte offset from the start of the disk image block, ie including the four words above:

offset      usage
  0         link to next block number in file
  2         lda_id, 0x1 when its a valid LDA SYSHDR
  4         # data bytes used (not including link word) in this block
                  normally 0x1FD unless its the last data block in file
  6         byte offset for data in stripped image under construction, this
                  offset monotonically increases by (bytes -6) from prior block
  8         for device driver files, maybe offset to init code?
 0xA		for device driver files, two ascii bytes, the device mnemonic
 0xC        ? (no idea)
 0xE        for device driver files, this is the offset to the primary driver
                  careful, its the offset after stripping the link and SYSHDR info
 0x10       two ascii bytes representing the version number

XXDP Creating TU58 Tape Images

I've written a new MSDOS version of DIAGDIR.EXE which includes options to manipulate an XXDP disk image. The program is described in rt11arc.txt and is available as a self expanding archive. A Linux version and the source code are available by request but as is, the code is not real pretty!

In general I think John Wilson's PUTR program is the best way to manipulate image files, but in the specific case of TU58 and RX02 images (DOS/BATCH format) his version 2.0 doesn't seem to work properly. You can run John's E11 with the XXDP RL02 images and create images of almost all disk formates. After some false starts I was also able to use E11 with my TU58 emulation package to create customized TU58 images which could then be used with a sick PDP-11. The trick here seems to be you must start with a TU58 image file with 512 blocks as E11 does a seek to the last block as part of the validation when the COM port is mounted as DD: The create option in my emulation package makes an empty file which E11 won't mount!

The current version of DIAGDIR is 1.01. As in my other DOS utilities I'm sloppy about parsing command line arguments, there may be no white space between the flag and pattern or filename fields.

Will's Works PDP-11 XXDP Image Viewer  Version: 1.01

usage: diagdir  [-{x,a,d,or f}]  [-i]
  -x surpresses dir listing and extracts files matching pattern
  -a surpresses dir listing and appends files matching pattern
  -d surpresses dir listing and deletes files matching pattern
  -f lists directory for pattern match
  -i initialize a new image filename using files from source image
  default with no options is list the full directory
  pattern match supports '?' and '*', ie use ?DL???.*

The following command line will initialize a new image file, new.tap, using the data files on the source image, xxdp25.dsk.

diagdir xxdp25.dsk -inew.tap
The program searches the source image to determine if it contains Version 1.x or 2.x XXDP files and then creates an image file with the appropriate monitor. I only support DD:, DX:, DY:, and DL: (an RL01 image) and the appropriate driver must be on the source disk. XXDP makes some choices I find odd regarding the directory size and disk format to use which I had to embed in a table in the program. The program will prompt for the device, to create a TU58 image enter DD:. After initializing the disk the program also prompts for file name patterns to append from the source to the new destination file. An empty line, ie just CR terminates the operation. Diagdir supports input redirection form stdin so you can create a command file to automate this procedure.

Alternatively you can use the -x option to extract file from the source to the current directory and then the -a option to append to your new image. The following command line will extract all the *.sys files from the image, xxdp25.dsk, to the current directory.

diagdir xxdp25.dsk -x*.SYS
When creating a new image you can be selective here, but in general you want a minimum of the device driver for the media, the monitor file, the directory utility, and help.txt. If you are running version 2.x you need DRS?M.SYS, the diagnostics control program. In version 1.x you often need HSAA??.SYS to run the diagnostics. Naturally you also need any diagnostic programs you want to run.

Now add these files from the current directory to your new image, new.tap.

diagdir new.tap -a*.*
The command above assumes you started with an empty directory as your work space and adds everything you have extracted into it from your source image. You can use the '*' wild card with the -a option because we are using MSDOS to search the directory and adding hits to the destination image file.
Warning: be cautious with the -a command and wild cards, there is no protection against adding a file more than once! I do not know what XXDP does in this instance, probably just ignores the 2nd copy?

I've created both Version 1.x and 2.5 TU58 images with this program and booted them using my TU58 emulator on a PDP11-23. I hope you have the same experience.

One word of caution, my Version 2.5 TU58 image created with DIAGDIR works fine but allocated 2 less blocks for the monitor image in the boot area than XXDP. Hence the first file on the image begins earlier than it would if created by XXDP. Since it seems to work I left it alone, but my current images are NOT identical to those created via XXDP.