> On Aug 14, 2017, at 11:49 PM, Glen Slick via cctalk <cctalk@classiccmp.org> > wrote: > > On Sun, Aug 13, 2017 at 9:00 AM, Ulrich Tagge via cctalk > <cctalk@classiccmp.org> wrote: >> Hi all, >> >> maybe someone can help. >> I would like to install TCP/IP on my RT-11 system. >> After a short search I have found the following, which I would use: >> http://www.classiccmp.org/PDP-11/RT-11/freeware/decus11/110939/rthtml/tcpget.htm >> But the images are in DSK format, but I can't write them with PDP11GUI, >> which is the only way I have at the moment. > > I would take a quick look at those .DSK images to see what I can make > of them, but none of the download links on that page work for me. > > For example, I can't download this .DSK image. Do these links work for > other people? > ftp://shop-pdp.kent.edu/du3:/tcpip.pkg/tcpipm.dsk
Glen - Try this link ftp://shop-pdp.net/pub/tcpip/tcpip/tcpipm.dsk As far as the DSK format, the files from at Alan’s site are logical disk images. Logical block 0,1,2,3 from from a DY sized volume starting at Track 1. In this case track 0 is ignored. This is what RT-11 expects and uses for Logical Disks (LD:). I’ve used Kermit and FTP to copy this file from my OSX disk to a RT-11 DU type drive as a file. They mount and operate as LD: drive without additional conversion. SIMH on the other hand as I understand it, expects disk images to represent the sectors of a disk. I did a few checks and its appears faithful to the RX02 format. It expects 256 byte sectors for track 0 (qty 26) and 512 byte sectors for the rest of the disk as Don pointed out. You need to prepend 6556. bytes of zero to the above file to get things started. But this is not the entire story. $ dd of=pad.dsk if=/dev/zero bs=256 count=26 6656 bytes transferred in 0.000230 secs $ cat pad.dsk tcpipm.dsk >tcpipm_V2.dsk When you attach tcpipm_V2.dsk in SIMH to an RY device (DY to RT-11), the expected boot block is visible as (RT-11) Block #0. .dump/rad50/ascii/end:0 dy:/term DY:/X/E:0 BLOCK NUMBER 000000 000/ 000240 000005 000404 000000 000000 041420 116020 000400 * ..........C....* D E FT J*H X82 FP 020/ 004067 000044 000015 000000 005000 041077 047517 026524 *7.$.......?BOOT-* ALW 6 M AX JW9 L$W GJD 040/ 026525 067516 061040 067557 020164 067157 073040 066157 *U-No boot on vol* GJE Q2N O. Q3G EG. QZ1 R6 QM9 060/ 066565 006545 005012 000200 105737 177564 100375 112037 *ume....._.t.}…* For an RT-11 Volume, the next logical block #1 should be the home block. In this case, its not. Instead it is found at block #7, but offset (early) -256. bytes from its normal location in the block. The first directory block should start at block #6. Here there directory blocks starting at block #3 and #4. So the padding is not enough here. The 6 sector skew and interleave implemented in the handler come into play. I haven’t looked at the code, but SIMH probably expects the disk to be sequential copies of physical sectors for the floppy drives. This makes sense, as the emulator presents them to the DY: handler where it will de-skew the data. Thus a DSK file representing logical blocks will not work for a floppy image in this case. A small program can probably be written to skew/Interweave the data to make them usable directly in SIMH. Images of most other DEC media probably don’t encounter the problem, as their device handler or driver doesn't implement either skew or interleave directly. Most of the ones I encounter leave that to the disk media formatting and/or controller firmware. Jerry j...@ieee.org
