XXDP Mini User GuideXXDP 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 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.
DEVICE MONITOR DRIVER DEVICES
MNEMONIC FILE FILE SUPPORTED
------- ------- ------ -----------
XX HMCT??.SYS HDXX??.SYS the XX devices
DD HMDD??.SYS HDDD??.SYS DL11/TU58
DY HMDY??.SYS HDDY??.SYS RX211/RX02
DL HMDL??.SYS HDDL??.SYS RL11/RL01
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
below:
.DIR ?RL???.???
ENTRY# FILNAM.EXT DATE LENGTH START VERSION
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
FREE BLOCKS: 2929
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):
BOOT BOOTSM CHAIN CLEAR COPY DATE DEFSM
DEFXM DELETE DIRECTORY ENABLE HELP INFONBOOT INITIALIZE
LOAD NOTES PRINT RENAME RUN SET START
SMALLMON SWITCHES TYPE UPDAT V2.4 VERSION
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
media.
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 StructureOne 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.
DOS/BATCH XXDP
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: 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 ImagesI'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.tapThe 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*.SYSWhen 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. |
PDP-11 >