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
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
No comments:
Post a Comment
Comments?