RSX Utility that lists the home block and updates the checksums on ODS-1 real and virtual disks

Lately, I've had occasion to do a lot of work on ODS-1 virtual disks on RSX. Specifically, I've been playing around with the contents of the home blocks.

  ODS-1 home blocks are the real root of a Files-11 ODS-1 file system. It tells you where the index file is, and that's where all the file headers are.

  The home block is located on the second logical block of a disk or virtual disk file. There are provisions in the FIles-11 code for locating it somewhere else, in case block 2 is bad, but really, how likely is that? I've never seen it occur, so I don't worry about it. For my purposes, it's always at block 2.

  RSX doesn't really provide any tools for listing the contents of the home block. There's DMP, of course, but, unless you're looking at PDP11 instructions (which naturally is grouped three bits at a time), octal is not the easiest format for looking at the bit contents of numbers. I wrote HOMCHK (home block check), which lists the home block contents in hex (hex allows you to easily see what bits are set or cleared, by inspection, much easier than octal or decimal).

  The home block also contains two checksums - one about three quarters of the way into the block, and one at the end of the block. Why are there two checksums? Beats me. Each one of these is the sum of all the preceding words, up to the checksum word. I was experimenting with changing the home block values, which meant that the checksums would need to be updated, to allow the disk file to be mounted as a virtual disk - MOU gets upset when the checksums aren't right. In order to deal with this, I added the ability to HOMCHK to indicate the state of these checksums (good or bad), and to update them if you want, by using the /UP switch. The other supported switch is /DU - it will produce a hex  dump of the whole home block..

  Anyway...don't use this unless you know what you're doing...it will definitely blast two checksums into block 2 of any file or disk...

 Here's the code.....

homchk.mac 



  To make...
  mac homchk=homchk
  tkb
  TKB>homchk/pr:0=homchk
  TKB>/
  Enter Options:
  TASK=...HCK
  LIBR=FCSRES:RO ;optional, can save memory on a busy system
 //

  Note the use of the /PR:0 switch on the task output file. This builds the task as privileged, but with no mapping of the IO page. This allows the task to do QIOs to a mounted disk, without consuming task address space for the IO page.

  To use...
  >run HOMCHK
  HCK>infile
  or install it 
  >ins HOMCHK
  >HCK infile

 HOMCHK will work on real disks as well as virtual disks. Be sure and put a colon at the
 end of the device spec, or it will think it's a filename.

 HCK>du4:

 

  

RSX utility for converting Track, Sector order virtual RX50 disks to LBN order.

  My collection of PDP11s and VAXen include several members of the PRO family. These desktops systems were fielded, too little and too late, to compete with the IBM PC. The system software, called P/OS, was based on RSX11m+.  

  DEC apparently wanted to prevent any "fratricide" to sales of conventional PDP11 systems, so they initially limited the user interface to a series of  annoying menus. Later on, the Pro Tool Kit, intended for use by developers,  included  a command line interface that produces a very RSX DCL/MCR  sort of user experience, making the PRO family a pretty good way to have an 11 at home.

  The DEC PRO family included two entries that were  systems based on the F11 chipset - the PRO-325 (floppy drive only) and the PRO-350, which had floppies and a hard disk. I've never even seen a PRO-325, so I'm figuring, there couldn't have been all that many of them. There was also the PRO-380, which had a J11 CPU. Although it was speed limited to 10 MHz, it was still considerably faster than the PRO-350.

  PRO-380s came along late and didn't sell all that well. DEC continued the tradition of using  machines from previous generations as console processors for new products, and used the left over PRO-380s as consoles for several VAXen in the 8000 series. In order to communicate with the VAX processors, these PRO-380s were equipped with a relatively exotic card - the  RTI (real time interface) card. These provided 2 RS-232 serial lines, I IEEE-488 port, and 24 bidirectional TTL level IO pins.

 A goodly while back, I found a PRO-380 on EBAY, that had apparently been a VAX Console processor - it had a VAXConsole badge instead of a PRO-380 badge, and had an RTI card installed.  But, it proved difficult to find any software to drive the RTI card.

  I asked around, and Wolfgang Eichberger was generous enough to share some floppy images that contained some RTI software. This included diskette BL-X9978-BK, titled "PRO/RTI MAINT V2.0". That sounds promising...bound to be some RTI software on there. If I at least got a driver, I could pull it apart and see what I could tell it to do.

  I tried mounting it as an RSX virtual disk, using VCP. No soap, it failed with a "MOU - no home block found or structure not supported" error message. LD on VMS was similarly not well pleased with this disk image. Well, that was a little disappointing. A look at the dsk file with DMP showed that MOU was right - block 2, the most likely place for a home block, was nothing like a home block. 

  A little more DMP investigation showed that this disk image had been saved in track, sector order, instead of logical block order. The difference is, that images in track, sector order will reflect the sector interleave and track skew of the physical disk. Interleave and skew are used to give the drive's physical mechanisms time to get ready before the next logical block comes around. Interleave involves writing the logical blocks on the physical disk, for example, in the order 1,3,5,7,9,2,4,6,8. If you need to read blocks 1 and 2, you have time to get 1 read and handled, before block 2 comes around. This avoids not being ready in time and having to wait a complete revolution for 2 to come around again. In like wise, at each track step, the start order is skipped over a couple of blocks, to allow you to read the last block of a track, and have a little time to get ready for the first sector of the next track to come by.

Using track,sector order on a virtual disk preserves the  interleave and skew of a normal disk, but is not what the virtual disk utilities want to see - they want the blocks to start with the first block, and proceed in sequential order. When I tried to mount this sector, track order image, MOU effectively was looking at block 700 something when it thought it was looking at block 2.

  But, not a real problem. I had recently written a utility that unpacked RX50 teledisk images to LBN order virtual disk files. Part of that utility was a MAP function that, given a block number of a track, sector image, would return where that block should go in an LBN disk image. I took that function and added a little code around it, to make the TSTOLBN utility (Track, sector to LBN).  

  TSTOLBN takes the name of a track, sector dsk file as an input, and the output file name of an LBN order dsk file to be created. Like this...

>run tstolbn
TTL>lbnfile.dsk=tsfile.dsk

  The output file is then readable by VCP and LD.

  Here's an actual example. First, I try and VCP connect and mount the original track and sector order virtual disk file

>vcp conn prorti.dsk
VCP - Device VF0: has been assigned.
>mou vf0: /ovr
MOU - no home block found or structure not supported

OK, so I disconnect it.

>vcp  disco vf0:

Then I create a new file, in LBN order, VCP connect it...and mount it successfully.
I included part of the  directory listing to show that everything is all roses now.
>
>run tstolbn
TTL>prortilbn.dsk=prorti.dsk
>vcp conn prortilbn.dsk
VCP - Device VF0: has been assigned.
>mou vf0: /ovr
>dir vf0:[*,*]


Directory VF1:[ZZUPDATE]
12-FEB-18 16:46

D00038.TSK;2        24.     C  25-SEP-84 13:47
UPDATE.INS;1        1.      C  25-SEP-84 13:48
D00038.MSG;1        4.      C  25-SEP-84 13:48
HG0100.TSK;2        29.     C  25-SEP-84 13:48

Total of 58./61. blocks in 4. files



  So, now I have some RTI software to investigate.

   Here's the source code for TSTOLBN.

tstolbn.mac


To make...
 >mac tstolbn=tstolbn
 >tkb
 TKB>tstolbn=tstolbn
 TKB>/
 Enter Options:
 TASK=...TTL
 LIBR=FCSRES:RO       ;this is optional - saves memory on a busy system
 //
>

 To use...
 >run tstolbn
 TTL>outfile=infile

 or install it and use direct from the command line

 >ins tstolbn
 >TTL outfile=infile

 Outfile extension defaults to .dsk, infile extension to .dsk