Corrupt PiDP11_DU0.zip/.dsk from RSX11M.com??

[Adrian Lumsden]

Kia ora,

I'm trying to get SIMH 3.9-0 running on my WIndows 10 system.

I've downloaded PiDP11_DU0.zip from RSX11M.com and extracted the PiDP11_DU0.dsk and started pdp11.exe. The emulator starts up OK but when I come to BOOT RQ0 I get:

    RSX-11M-PLUS V4.6  BL87   2044.KW  System:"PIDP11"

    SAV -- Task file header read error, task removed - ...MCR

    SAV -- Task file header read error, task removed - ...SAV

    SAV -- Task file header read error, task removed - ...PIP

    >RED DU2:=SY:

    MCR    -- Task not in system

    >RED DU2:=LB:

    MCR    -- Task not in system

    >RED DU2:=SP:

    MCR    -- Task not in system

    >MOU DU2:"RSX11MPBL87"/LRU=14/WIN=30/ACP=UNIQUE

    MOU - I/O error on device

    10:14:38  *** DU2:  -- Dismount complete

    IE.RER - file processor read error

I've tried extracting the .dsk file several times, and I've tried downloading fresh copies several times to no avail.

Maybe the bits are arriving upside down because I'm in New Zealand?

Has anybody managed to use these files from the web site recently?

Does anyone have an RSX-11M-Plus image with TCP/IP in it that they'd be prepared to share with me?

It's good to be using the PDP-11 and RSX again. I used to be XDT Computer Systems in the UK. I've got a bunch of stuff on my own disc images that I'd like to drag off and contribute to the community. TCP/IP is probably the easiest way of getting the source code across into Windows isn't it? Any other suggestions gratefully received.

Arohanui,

Adrian Lumsden

[Johnny Billquist]

Hi, Adrian. Long time no see...

Afraid I don't have a quick solution for you. I am slowly working on
getting a prepared disk image for people to use, but I've been making
slow progress. I need a day or two of proper work to finish it.

Anyway, I don't know what the issue might be with that disk image. I
think others have used it fine, but your run obviously show some serious
problems...

As for file transfer, I would certainly agree that ftp using TCP/IP is
by far the easiest way. But I might be biased. ;-)

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/6d91a400-f6ab-4ff9-bf92-fdbdf5cea5e5n%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/6d91a400-f6ab-4ff9-bf92-fdbdf5cea5e5n%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Mark Matlock]

Adrian,
The disk image that you downloaded is from me. The first issue I see from the RSX11M+
boot dialog is that it is booting from DU2: Can you show us the simh configuration file (.ini)
In particular I’d like to see the

attach rq# PiDP11_DU0.dsk

line. Also, you mentioned that you are running simh on Windows 10, not a PiDP-11/70
Raspberry Pi, so if you are using a PiDP-11/70 simh .ini file you should comment the
lines that deal with driving the PiDP-11/70 blinken lights.

Best,
Mark

> --
> You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/6d91a400-f6ab-4ff9-bf92-fdbdf5cea5e5n%40googlegroups.com.

[Anton Lavrentiev]

Hi,
I just downloaded and expanded the DU0: disk image, and ran SimH on my
PC: it boots perfectly fine.
Note that when running on PC, you have to attach DU1: as well --
because the RSX startup script expects an image mounted
there (as it attempts to logically mount it, and will hang, waiting
for that). Here's the command sequence to get everything running
under SimH (you can also download the proper DU1 image from
rsx11m.com, instead of using "empty.dsk" -- but that was just
to "exclude" yet another "variable"):

set cpu 11/70 4m
att rq0 ./PiDP11_DU0.dsk
att rq1 ./empty.dsk
b rq0

When it boots, enter time / date, and answer N for both LAT and TCPIP,
for starters.

Also, both images (DU0/1) check out completely valid (with some of the
standalone tools I have here,
a la VFY) -- I don't see any structure corruption or anything like that.

Hope this helps,
Anton

> To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/FBBC3AC8-7C33-4D96-AC81-BCFA54D79579%40MatlockFamily.com.

[anton.la...@gmail.com]

Sorry forgot to mention:

>  SimH on my PC

... that was the freshest build from the current simh sources pulled from git repo just now

[Adrian Lumsden]

Thanks for your help and suggestions. Firstly I do have an old RSX-11M-Plus system disc from a previous life which does boot and run on SIMH 5.9 without any problems. That's the one that I'm trying to get all the stuff off. It doesn't have TCP/IP in it and I was trying to avoid futzing with those contents too much.

I also have the RSX image extracted from rsx11mplus_4_6_bl87_dsk.zip at Trailing-Edge. That boots and runs OK as you'll see.

I downloaded the two ZIP files from http://www.rsx11m.com/PiDP11_DU0.zip and http://www.rsx11m.com/PiDP11_DU1.zip and unzipped them to make the two PiDP-11 container files.

I've configured a P1DP-11.ini file:

        echo

        echo Running PiDP-11.ini initialisation file.

        show version

        echo

        ; Set up the simulated CPU

        set CPU 11/93

        set CLK 50HZ

        set cpu 4m

        ; Configure some discs

        attach -e rq0 rsx11mplus_4_6_bl87.dsk

        attach -e rq1 PiDP11_DU0.dsk

        attach -e rq2 PiDP11_DU1.dsk

        show rq

    boot rq0

When I run that in SIMH this is what happens:

        K:\SIMH>pdp11_v3.9-0.exe PiDP-11.ini

        

        PDP-11 simulator V3.9-0

        

        Running PiDP-11.ini initialisation file.

        PDP-11 simulator V3.9-0 [32b data, 32b addresses, Ethernet support]

        

        Disabling CR

        Disabling RK

        Disabling HK

        Disabling TM

        RQ, address=17772150-17772153*, no vector, 4 units

          RQ0, 159MB, attached to PiDP11_DU0.dsk, write enabled, RD54

          RQ1, 159MB, attached to PiDP11_DU1.dsk, write enabled, RD54

          RQ2, 159MB, attached to rsx11mplus_4_6_bl87.dsk, write enabled, RD54

          RQ3, 409KB, not attached, write enabled, RX50

        sim>boot rq0

        RSX-11M-PLUS V4.6  BL87   2044.KW  System:"PIDP11"

        SAV -- Task file header read error, task removed - ...MCR

        SAV -- Task file header read error, task removed - ...SAV

        SAV -- Task file header read error, task removed - ...PIP

        >RED DU:=SY:

        MCR    -- Task not in system

        >RED DU:=LB:

        MCR    -- Task not in system

        >RED DU:=SP:

        MCR    -- Task not in system

        >MOU DU0:"RSX11MPBL87"/LRU=14/WIN=30/ACP=UNIQUE

        MOU - I/O error on device

        10:14:38  *** DU0:  -- Dismount complete

        IE.RER - file processor read error

So I reconfigured P1DP11.ini to:

        echo

        echo Running PiDP-11.ini initialisation file.

        show version

        echo

        

        ; Set up the simulated CPU

        set CPU 11/93

        set CLK 50HZ

        set cpu 4m

        

        ; Configure some discs

        attach -e rq0 rsx11mplus_4_6_bl87.dsk

        attach -e rq1 PiDP11_DU0.dsk

        attach -e rq2 PiDP11_DU1.dsk

        show rq

And run that up. You don't need me to talk you through what happened:

        

        PDP-11 simulator V3.9-0

        

        Running PiDP-11.ini initialisation file.

        PDP-11 simulator V3.9-0 [32b data, 32b addresses, Ethernet support]

        

        Disabling CR

        Disabling RK

        Disabling HK

        Disabling TM

        RQ, address=17772150-17772153*, no vector, 4 units

          RQ0, 159MB, attached to rsx11mplus_4_6_bl87.dsk, write enabled, RD54

          RQ1, 159MB, attached to PiDP11_DU0.dsk, write enabled, RD54

          RQ2, 159MB, attached to PiDP11_DU1.dsk, write enabled, RD54

          RQ3, 409KB, not attached, write enabled, RX50

        sim> b rq0

        

        

        RSX-11M-PLUS V4.6  BL87   2044.KW  System:"RSXMPL"

        >RED DU:=SY:

        >RED DU:=LB:

        >RED DU:=SP:

        >MOU DU0:"RSX11MPBL87"

        >@DU:[1,2]STARTUP

        >;                      PLEASE NOTE

        >;

        >;      If you have not yet read the system release notes, please do so

        >;      now before attempting to perform a SYSGEN or to utilize the new

        >;      features of this system.

        >;

        Z[c

        SET -- Inquire cannot determine terminal type

        >;

        >; Please ignore any random characters that may have printed on your

        >; terminal just now.  They came from a SET /INQUIRE=TI: command.

        >; Evidently your terminal does not recognize escape sequences.

        >; This will not affect the running of this command file.

        >;

        >* Please enter time and date (Default:14-AUG-2021 12:48) [S]:

        >ACS SY:/BLKS=1024.

        >CON ONLINE ALL

        >ELI /LOG/LIM

        >CLI /INIT=DCL/CTRLC/DPR="<15><12>/$ /"

        >INS LB:[1,1]RMSRESAB.TSK/RON=YES/PAR=GEN

        >INS LB:[1,1]RMSLBL.TSK/RON=YES/PAR=GEN

        >INS LB:[1,1]RMSLBM.TSK/RON=YES/PAR=GEN

        >INS $QMGCLI

        >INS $QMGCLI/TASK=...PRI

        >INS $QMGCLI/TASK=...SUB

        >QUE /START:QMG

        >INS $QMGPRT/TASK=PRT.../SLV=NO

        >QUE LP0:/CR/NM

        >START/ACCOUNTING

        >CON ESTAT LP0:

        >QUE BAP0:/BATCH

        >QUE BAP0:/AS:BATCH

        >@ <EOF>

        >

        >dev du:

        DU0:     Public Mounted Loaded Label=RSX11MPBL87 Type=RD54

        DU1:     Loaded Type=RD54

        DU2:     Loaded Type=RD54

        DU3:     Loaded Type=RX50

        >mou du1:/ovr/vi

        MOU - I/O error on device

        IE.RER - file processor read error

        12:49:28  *** DU1:  -- Dismount complete

        >mou du2:/ovr/vi

        MOU - I/O error on device

        IE.RER - file processor read error

        12:50:06  *** DU2:  -- Dismount complete

        >

        >mou du1:/for

        >ins $dmp

        >dmp ti:=du1:/bl:0:0

        

        Dump of DU1:

                         Logical block 0,000000 - Size 512. bytes

        

        000000    000260 000404 000003 130121 055420 071441 000400 112737

        000020    000340 177776 012705 000001 003401 010105 012704 003000

        000040    012703 000400 005001 012124 077302 005002 010004 100404

        000060    012706 004100 005046 005046 000137 003074 005705 001002

        000100    012705 172150 013703 000006 013702 000004 042702 100000

        000120    066603 000002 005502 061602 013746 000012 013746 000010

        000140    010346 010246 010367 177636 010267 177630 012704 000310

        000160    005765 000002 001402 000167 000314 077406 012765 176400

        000200    000002 005065 000004 012765 000001 000020 022765 000001

        000220    000020 001474 012704 003354 016501 000026 105714 001464

        000240    120114 101402 022424 000772 005724 005714 001410 071214

        000260    010265 000034 005002 005001 154401 071201 000302 050302

        000300    010265 000006 112715 000071 012701 000010 054626 077102

        000320    032715 100200 001771 100062 032765 000040 000042 001424

        000340    012715 040011 052765 001000 000032 000754 013022 000642

        000360    020025 000240 017426 000662 020027 001140 031042 003100

        000400    040047 004000 000110 000000 000000 000776 071227 000102

        000420    010265 000020 005002 071227 000026 000302 050302 010265

        000440    000006 032765 000400 000012 001403 052767 002000 000002

        000460    012715 000021 032715 100200 001775 100746 010004 052700

        000500    100000 010501 005007 012703 003714 012701 004000 010125

        000520    012704 000043 054626 077402 005715 100466 030115 001770

        000540    012315 006301 100365 012701 004304 005041 020127 004100

        000560    001374 012721 000060 005211 012111 010167 000144 012702

        000600    003736 012722 004204 110061 000004 112361 000010 112361

        000620    000015 001405 016661 000002 000034 011661 000036 012712

        000640    100000 011267 000076 005765 177776 012704 000043 054626

        000660    077402 005715 001011 005712 100770 105737 004216 001004

        000700    005713 001321 005045 000672 005045 000675 100000 003736

        000720    000000 000001 000011 003041 000000 005007 005007 005007

        000740    005007 005007 005007 005007 005007 005007 005007 005007

        000760    005007 005007 005007 005007 005007 005007 005007 005007

        

        >

        >mou du2:/for

        >dmp ti:=du2:/bl:0:0

        

        Dump of DU2:

                         Logical block 0,000000 - Size 512. bytes

        

        000000    000240 000005 012706 001000 010700 062700 000036 112001

        000020    001403 004767 000006 000773 000005 000000 110137 177566

        000040    105737 177564 100375 000207 005015 020012 020040 025052

        000060    052052 044510 020123 047526 052514 042515 042040 042517

        000100    020123 047516 020124 047503 052116 044501 020116 020101

        000120    040510 042122 040527 042522 041040 047517 040524 046102

        000140    020105 054523 052123 046505 025040 025052 005015 000012

        000160    010046 005046 012701 000377 062016 005301 001375 012601

        000200    012600 000207 016701 154042 012767 000001 160362 020127

        000220    061771 101407 005267 160350 020127 144763 101402 005267

        000240    160336 032767 020000 153756 001014 020105 103006 032767

        000260    000400 154164 001006 104741 000404 052767 000002 154150

        000300    000411 012767 000006 160174 012767 000007 160170 012767

        000320    000010 160164 016700 160250 006300 016067 007756 160150

        000340    005000 012702 010000 004767 000014 005702 001401 005201

        000360    010167 154160 000207 010346 012703 000040 010246 005002

        000400    006301 006100 006102 020216 103402 161602 005201 005303

        000420    001367 005726 012603 000207 005002 005003 051003 062002

        000440    005301 001374 000207 012767 001000 164062 004767 000032

        000460    116767 164100 154112 104420 012767 000400 164040 004767

        000500    000010 116767 164056 154070 104421 010067 164032 105067

        000520    164035 012746 014010 104377 103004 012767 002022 154042

        000540    104415 105767 164016 100402 005726 000207 012767 002022

        000560    154020 000207 010046 122767 000001 153702 001415 012702

        000600    003060 012705 030350 012700 000022 012522 005300 001375

        000620    032767 000100 153620 001044 012702 003124 012705 030350

        000640    012700 000010 012225 005300 001375 016725 154032 016725

        000660    154030 016767 000252 157226 016767 157220 000242 016767

        000700    157230 000216 016702 157224 010267 000204 012705 030400

        000720    012700 000005 012225 005300 001375 016767 153756 000176

        000740    012600 000207 010046 004767 176750 103001 104456 005767

        000760    152630 001403 016767 152622 157112 016700 152606 001420

So the M-Plus kit disc boots and runs OK. Neither of the PiDP-11 discs are mountable. That's the same as last night. I suppose that that's not necessarily surprising as they haven't changed.

I did run MD5 checksums on this morning's files and last night's and they are the same"

        This morning's PiDP-11 discs:

        K:\SIMH>certutil -hashfile PiDP11_DU0.dsk MD5

        MD5 hash of PiDP11_DU0.dsk: 0385d8191fc8aaefd14df6f07253421e

        

        K:\SIMH>certutil -hashfile PiDP11_DU1.dsk MD5

        MD5 hash of PiDP11_DU1.dsk: 591a6f02c970d5c77012d17545cf8169

        

        Last night's P1DP-11 discs:

        K:\SIMH\Containers\RSX11M.com>certutil -hashfile PiDP11_DU0.dsk MD5

        MD5 hash of PiDP11_DU0.dsk: 0385d8191fc8aaefd14df6f07253421e

        

        K:\SIMH\Containers\RSX11M.com>certutil -hashfile PiDP11_DU1.dsk MD5

        MD5 hash of PiDP11_DU1.dsk: 591a6f02c970d5c77012d17545cf8169

That would seem to rule out problems with corruption in some way on the download and/or unzipping. I've also run a binary compare between them and it claims that they are identical. Do these MD5 values agree with the ones that you have from a web site download? They will probably not agree with any discs that you have in use because of the many updates that RSX makes to an in-use disc.

That doesn't seem to help very much except to provide more information.

Grateful for any suggestions?

Thanks again for your help.

with best regards,

Adrian

[Mark Pizzolato]

simh 3.9 is at least slightly old (approximately 12 years).  The latest simh codebase (at least something past 3.9) is likely what the disk image in the zip file you're trying to use was built using.

I presume that you didn't/can't actually build Windows binaries, so you can get windows binaries from: https://github.com/simh/Win32-Development-Binaries/blob/Win32-Development-Binaries/simh-4.0-Current--2020-06-09-0912a927.zip

These are more than a year old, but 11 years past what you've been trying to use.  Try the pdp11 from this zip and see if you get better results.

[Anton Lavrentiev]

You have a sizing problem with the attached disks:

DU0 is 318MB and DU1 is 1.7GB long; when attaching them by default,
simh 3.9 only "sees" half of DU0: (check your "show rq" output: it
thinks the device is only 159MB long, so anything beyond that accessed
by the operating system will be returned as 0s -- resulting in
"corruption"). For DU1, the "visible part" is even less... So DU0:
it's an easy fix: use "set rq0 ra81" prior to attaching the disk
image.
As you could see, both boot blocks as you dumped them, appear as
proper boot blocks (BTW, a home block of a drive is usually at LBN1,
and that's where the volume label is stored).

For DU1: it's not that easy because 3.9 does not support RQ devices
that large. So your only luck is to use a dummy device attached there
("att rq1 empty.dsk"). Most likely later versions of the 3.x series
support larger drives, but I haven't checked. Anyways, with DU0 set
as RA81 and DU1 attached to a dummy, the system boots properly.

As for 4.x simulators, they support "autosizing", so both images will
attach just fine: keep in mind, though, that once attached, simh 4.1
changes the images, so they won't be equal to the originals no more,
because it now writes some signatures at the end. So your MD5's won't
longer match.

Hope this helps,
Anton

> To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/d3664deb-52ff-4371-9e09-a9c4330492b6n%40googlegroups.com.

[Anton Lavrentiev]

> simh 3.9 is at least slightly old (approximately 12 years)

Nah, it's just a bit over 9 years young so far:

http://simh.trailing-edge.com/sources/archive/ :

simhv39-0-exe.zip 2012-05-03 15:26 3.0M
simhv39-0.zip 2012-05-03 15:26 3.0M

> To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/cebd6141-ee49-458f-93d4-a4b2d92011d0n%40googlegroups.com.

[Johnny Billquist]

Adrian, I think there is something messed up with what you do.
The results do not match what you would expect in here. See comments
inline...

[...]

In the command script you showed, you attached rsx11mplus_4_6_bl87.dsk
to rq0, but in the output, it appears to be attached to rq2.
This can't be right.

Also, I wonder if there might be some issue here in that you are booting
a disk that was configured for an 11/70, but you're booting it on an 11/93.

I think RSX should handle this fine, but it could be worth trying to
correct the cpu type just to check...

[...]

This time it would seem the output actually match the configuration, and
the system boots fine.

Anton also made a very good observation that the PiDP11_DU%.dsk files
are images that are way bigger than an RD54. As such, you will
definitely get those miserable errors you are seeing, as there will be
plenty of references to disk blocks which does not exist on an RD54.

> Grateful for any suggestions?

I think we know what the core problem is. Disk sizes...
Truncating a disk will never make you happy. :-D

Johnny

[Anton Lavrentiev]

I actually figured out how to get both DU0 an DU1 images work with simh 3.9:

First off, you have to calculate the number of sectors in each image,
just divide the size of the image (in bytes) by 512.:
DU0: 314,880,000 / 512 = 615000
DU1: 1,720,320,000 / 512 = 3360000

Then start simh and set these drives to the RAUSER format with the
number of blocks just calculated,
then attach the actual images, and boot:

sim> set cpu 11/70 4m
sim> set -L rq0 rauser=615000
sim> set -L rq1 rauser=3360000
sim> att rq0 pidp11_du0.dsk
sim> att rq1 pidp11_du1.dsk
sim> sh rq
RQ, address=17772150-17772153*, vector=154, 4 units
RQ0, 314MB, attached to pidp11_du0.dsk, write enabled, RAUSER
RQ1, 1720MB, attached to pidp11_du1.dsk, write enabled, RAUSER
RQ2, 159MB, not attached, write enabled, RD54

RQ3, 409KB, not attached, write enabled, RX50
sim> b rq0
...

Note that using LBNs (the -L switch for the "set rqn" command) for the
sizes is more "precise" to correctly size the devices (which otherwise
takes the size in MBs,
which is not quite obvious a unit -- whether is it a commercial (i.e.
decimal) megabyte or a computer (i.e. binary) one, and what to do if
the size is fractional of either --
assuming that rounding up should work, though?)

Source: section 2.7 of pdp11_doc.doc from here:

http://simh.trailing-edge.com/sources/archive/simhv39-0-doc_masters.zip

Hope this helps,
Anton

> --
> You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/a41b4e33-25e6-12ff-27fa-c537969e0783%40softjar.se.

[Mark Pizzolato]

You might also have solved this problem in simh 3.9 by enabling AUTOSIZE on each of your RQ drives before you attach them.

        sim> SET RQ0 AUTOSIZE
        sim> SET RQ1 AUTOSIZE

        sim> SET RQ2 AUTOSIZE

        sim> SET RQ3 AUTOSIZE

AUTOSIZEing is enabled by default in the 4.x codebase and thus wouldn't have been specifically needed.

[Anton Lavrentiev]

Well, reading more, the doc says the sizes accepted are "commercial"
megabytes (1,000,000 bytes), so at least that is clear, but they will
still have to be rounded up for either drive to fit entirely:
315 for DU0 and 1721 for DU1:

sim> set rq0 rauser=315
sim> ser rq1 rauser=1721
...
I think LBNs are neater :-)

[Anton Lavrentiev]

It wasn't exactly _my_ problem -- I was just trying to help. 

Autosize was actually the first thing I tried, but it didn't work, for some reason... It said something about incorrect command, so I assumed it wasn't available (maybe I wasn't using it right -- there's no online help to check that)...

So I pursued a different approach, which was documented, and found it to work quite well.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/fd011e09-e9f1-433c-a64c-490dc059dce4n%40googlegroups.com.

[Mark Pizzolato]

Well, AUTOSIZING works better with the github 4.x codebase:

PDP-11 simulator V4.0-0 Current        git commit id: 6728b3f4

sim> show rq

RQ      address=17772150-17772153, no vector, BR5, RQDX3, 4 units

  RQ0   159MB, not attached, write enabled

        RD54, UNIT=0, autosize

        AUTO detect format

  RQ1   159MB, not attached, write enabled

        RD54, UNIT=1, autosize

        AUTO detect format

  RQ2   159MB, not attached, write enabled

        RD54, UNIT=2, autosize

        AUTO detect format

  RQ3   409KB, not attached, write enabled

        RX50, UNIT=3, autosize

        AUTO detect format

sim> attach rq0 pidp11_du0.dsk

RQ0: 'pidp11_du0.dsk' Contains an ODS1 File system

RQ0: Volume Name:  RSX11MPBL87 Format: DECFILE11A   Sectors In Volume: 615000

sim> show rq

RQ      address=17772150-17772153, no vector, BR5, RQDX3, 4 units

  RQ0   314MB, attached to pidp11_du0.dsk, write enabled

        RD54, UNIT=0, autosize

        SIMH format

  RQ1   159MB, not attached, write enabled

        RD54, UNIT=1, autosize

        AUTO detect format

  RQ2   159MB, not attached, write enabled

        RD54, UNIT=2, autosize

        AUTO detect format

  RQ3   409KB, not attached, write enabled

        RX50, UNIT=3, autosize

        AUTO detect format

This would have just worked thus avoiding the dancing around needed with 3.9.

In autosize algorithm in simh 3.9 only had the physical size of the disk container 

to work with, which, if the OS that had prepared the disk container hadn't written 

anything all the way out to the end of the logical volume, it would assume that 

this container was that from the actual largest block written, which in this case 

was only some 42,019KB.  Addressing exactly this problem was precisely why

the AUTOSIZE algorithm in 4.x was implemented to examine the container 

contents to detect the file system it contains and then use the file system size 

as the AUTOSIZE size.

[Johnny Billquist]

And I would certainly make the disk sizes larger, in case the files for
some reason or other didn't have all the blocks of the device it was
supposed to represent.

315 MB is a very odd size...

(But yes, I always use rauser=... in my simh)

I absolutely disagree with the automatic detection and magic behavior.

Johnny

[Anton Lavrentiev]

> This would have just worked thus avoiding the dancing around needed with 3.9.

The question was about 3.9, and auto-sizing is not supported there --
I specifically re-checked:

c:\systems\rsx11mplus>pdp11

PDP-11 simulator V3.9-0

sim> set cpu 11/70 4m

Disabling XQ
sim> set rq0 autosize
Non-existent parameter
sim>

Yes, 4.x does auto-size but even before an OS is booted, the very
attachment itself will have the .DSK image modified...

That will require some dancing to make it back to its original form to
re-check MD5, for example.

> To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/e7a15752-e82d-41e9-85aa-651c386afb05n%40googlegroups.com.

[Adrian Lumsden]

Kia ora,

It's Sunday evening here and the good news is that  I have PiPD_DU0,dsk (and PiDP_DU1) up and running on PDP11.exe v4.0 (from simh-4.0-Current--2020-06-09-0912a927.zip on Github). Thank you all for helping me get this going. I had figured out that it was a disc size problem and was pleased to see that confirmed. I decided that it was easier to go to v4.0 that continue to futz around with 3.9.

So now (tomorrow actually) my task is to get networking and TCP/IP working. That'll be a new experience for me. Anybody got any hints or recipes to help me on the way?

All the best,

Adrian

[Johnny Billquist]

Get the RL02 disk image. Mount it. Run IPGEN. Run IPINS. Run IPAPPL.
That should be it.

In STARTUP.CMD, add IPINS at some suitable early point. Add IPAPPL at
some suitable late point.

Oh, and I would recommend you install DECnet first. The ethernet drivers
in DECnet are much better than XEDRV.

Johnny

> <https://groups.google.com/d/msgid/pidp-11/a41b4e33-25e6-12ff-27fa-c537969e0783%40softjar.se>.

>
> >>>
> >>> --
> >>> You received this message because you are subscribed to the
> Google Groups "[PiDP-11]" group.
> >>> To unsubscribe from this group and stop receiving emails from
> it, send an email to pidp-11+u...@googlegroups.com.
> >>>
> >>> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/fd011e09-e9f1-433c-a64c-490dc059dce4n%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/fd011e09-e9f1-433c-a64c-490dc059dce4n%40googlegroups.com>.

>
> >
> > --
> > You received this message because you are subscribed to the
> Google Groups "[PiDP-11]" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send an email to pidp-11+u...@googlegroups.com.
> > To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/e7a15752-e82d-41e9-85aa-651c386afb05n%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/e7a15752-e82d-41e9-85aa-651c386afb05n%40googlegroups.com>.

>
>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/5660cc95-4635-4d2a-99ee-8218af5c8478n%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/5660cc95-4635-4d2a-99ee-8218af5c8478n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Adrian Lumsden]

It's Monday morning and I'm about to dig into getting this all up and running. Thanks again for your help.

I have a couple of questions:

Anton: I'm puzzled by "Yes, 4.x does auto-size but even before an OS is booted, the very attachment itself will have the .DSK image modified..." Are you saying that SIMH PDP11.exe somehow modifies the disc container file above and beyond any changes that the booted operating systems makes through normal usage? When I take a look at the one that I just booted from against the untouched original from the zip file, I see that the former is 512 bytes larger. That looks suspiciously like a disc block's worth.

Johnny: Thanks for the TCP/IP instructions. I thought that the PiDP11_DU0.dsk contained TCP/IP already set up. Is that an old version and the current discs are better to work from?

Regards,
Adrian

[Johnny Billquist]

Adrian...

On 2021-08-16 01:53, Adrian Lumsden wrote:
> It's Monday morning and I'm about to dig into getting this all up and
> running. Thanks again for your help.
> I have a couple of questions:
> Anton: I'm puzzled by "Yes, 4.x does auto-size but even before an OS is
> booted, the very attachment itself will have the .DSK image modified..."
> Are you saying that SIMH PDP11.exe somehow modifies the disc container
> file above and beyond any changes that the booted operating systems
> makes through normal usage? When I take a look at the one that I just
> booted from against the untouched original from the zip file, I see that
> the former is 512 bytes larger. That looks suspiciously like a disc
> block's worth.

Yes. simh v4 puts some of its own metadata into your disk image.

> Johnny: Thanks for the TCP/IP instructions. I thought that
> the PiDP11_DU0.dsk contained TCP/IP already set up. Is that an old
> version and the current discs are better to work from?

Ah. I wasn't thinking much here.
Yeah, I believe that disk already have TCP/IP installed. In which case
you want to run [IP]IPCONFIG and change your configuration to whatever
you want, and that should pretty much be it.

Also, you probably do want to update the whole thing. Check the manual
for update instructions, or go fancy and setup RPM, and then update
using that...

Johnny

> <https://groups.google.com/d/msgid/pidp-11/5660cc95-4635-4d2a-99ee-8218af5c8478n%40googlegroups.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/pidp-11/5660cc95-4635-4d2a-99ee-8218af5c8478n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: b...@softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/c9ec99c2-9925-4d0a-be27-8ad5c02ce5e8n%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/c9ec99c2-9925-4d0a-be27-8ad5c02ce5e8n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Anton Lavrentiev]

> I see that the former is 512 bytes larger. That looks suspiciously like a disc block's worth.

https://github.com/simh/simh/issues/1059

simh should keep its metadata separately -- not within the disk image container, IMO

disk image container is an image of disk data from the platters -- no extras should be allowed there,

there's plenty of other ways to supplement metadata than to actually store it in the disk images...

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/c9ec99c2-9925-4d0a-be27-8ad5c02ce5e8n%40googlegroups.com.

[Adrian Lumsden]

Hmm. Interesting (in the Spock sense). What meta data is being held in there and is it relevant to the last time that 'disc' was used with the SIMH PDP-11? 

One of the things that I like to do is to these days is to avoid using BRU to backup a disc. I keep original copies of some of my 'real' discs from back in the day  and then use copies of them. I can do this for exploring things that are going to make big changes (installing TCP/IP for example) and, if it goes badly or if I want to back out for some reason, I can just restore the 'disc' by making a new copy from the original. This will blow away any metadata that's been written to that disc. Where does that leave SIMH? And speaking of BRU, wouldn't a BRU save and restore to a new container file loose the metadata anyway?

I've read through the simh/issues/1059 thread and, from a quick skim, I don't see a good justification for preserving meta data in this way and don't remember seeing what those metadata are. I suppose that I could go to read the code.

I'm obviously new to SIMH PDP11 v4.0 so there's obviously stuff that I'm not fully conversant with. I'm looking forward to finding out more. 

All the best,

Adrian

[Adrian Lumsden]

Hello Johnny,

> Yeah, I believe that disk already have TCP/IP installed. In which case
>   you want to run [IP]IPCONFIG and change your configuration to whatever
>   you want, and that should pretty much be it.

I've scanned [IP] for IPCONFIG.* and can't find anything. I've scanned the whole disc too and still can't find one. There's an IFCONFIG (.txt and .tsk) in [IP]. Is that the one that you meant?

Where's the best place to get the latest BQTCP .dsk from? Is it the one on  ftp://madame.update.uu.se/bqtcp.dsk or from http://mim.update.uu.se/tcpip.htm.

All the best,

Adrian

[Johnny Billquist]

Hi.

On 2021-08-16 23:31, Adrian Lumsden wrote:
> Hello Johnny,
>
> > Yeah, I believe that disk already have TCP/IP installed. In which case
> >   you want to run [IP]IPCONFIG and change your configuration to whatever
> >   you want, and that should pretty much be it.
>
> I've scanned [IP] for IPCONFIG.* and can't find anything. I've scanned
> the whole disc too and still can't find one. There's an IFCONFIG (.txt
> and .tsk) in [IP]. Is that the one that you meant?

Hmm. It might be that the TCP/IP on that disk image is rather old then.
IFCONFIG is a separate thing.

IPCONFIG.CMD is just an IND file used to configure things. I created it
a couple of years ago to make the whole configuration and management
easier to do, and not have people to go and edit various files to get a
setup.

> Where's the best place to get the latest BQTCP .dsk from? Is it the one
> on ftp://madame.update.uu.se/bqtcp.dsk or
> from http://mim.update.uu.se/tcpip.htm.

Madame is just an alias for Mim. :-)

ftp://mim.update.uu.se/bqtcp.dsk, or bqtcp.tap (if you are ftp:ing from
RSX...)

Johnny

> <https://groups.google.com/d/msgid/pidp-11/c9ec99c2-9925-4d0a-be27-8ad5c02ce5e8n%40googlegroups.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/pidp-11/c9ec99c2-9925-4d0a-be27-8ad5c02ce5e8n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: b...@softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/9cb0bb04-81ed-4eb0-83bc-1b97005defe5n%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/9cb0bb04-81ed-4eb0-83bc-1b97005defe5n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Adrian Lumsden]

Thanks Johnny. I'll give that a go later. Meanwhile some stuff to fix on a web site...

All the best,

Adrian

[Adrian Lumsden]

I've finally got back to getting this PiDP image up and running and have made some progress. The main thing that slowed me down missing "Do not expect ICMP traffic (ping mostly) to traverse the NAT boundary." which caused me to think that all my failing test PINGs were a sign that I hadn't configured things correctly. So now I can TELNET into the RSX system and have run an FTP client to connect just to test.

Now I'm trying to tidy up a little before I start to really dig in. I have a couple of questions if I may:

Startup.cmd does DFL "-360"=SYS$UTC_OFFSET/GBL. That's six hours west of UTC. I'm in New Zealand which is 12 hours east of UTC so I make that an offset of 720 minutes. It is currently 2021-09-09 10:17:00 UTC / 2021-09-09 21:17:00 NZST. If I run NTP I get:

>dfl "720"=SYS$UTC_OFFSET/gbl

>ntp -s

NTPDATE - Clock error is 44 secs.

NTPDATE - Tick delta: 2632

NTPDATE - Error is 2632. Clock synced to Thu Sep 09 03:05:45 2021

>tim

03:05:47 9-SEP-2021

So that looks about 18 hours short of giving me the correct local time. Am I missing something?

I'm finding that the FTP Server is timing out on me and shutting down the connection while I fumble around. Is there a way to change the time out value?

Thanks for your help with this. It feels weird to be typing command lines again. Weird but much better and quicker than a GUI interface, particularly as the muscle memory comes back. It's slightly complicated as I am also bringing an AlphaServer DS10 back to life and that's a (slightly) different set of muscle memories. 

All the  best,

Adrian

[Johnny Billquist]

Hi, Adrian.

On 2021-09-09 11:30, Adrian Lumsden wrote:
> I've finally got back to getting this PiDP image up and running and have
> made some progress. The main thing that slowed me down missing "Do not
> expect ICMP traffic (ping mostly) to traverse the NAT boundary." which
> caused me to think that all my failing test PINGs were a sign that I
> hadn't configured things correctly. So now I can TELNET into the RSX
> system and have run an FTP client to connect just to test.

Excellent!

> Now I'm trying to tidy up a little before I start to really dig in. I
> have a couple of questions if I may:
>
> Startup.cmd does DFL "-360"=SYS$UTC_OFFSET/GBL. That's six hours west of
> UTC. I'm in New Zealand which is 12 hours east of UTC so I make that an
> offset of 720 minutes. It is currently 2021-09-09 10:17:00 UTC /
> 2021-09-09 21:17:00 NZST. If I run NTP I get:
>
> >dfl "720"=SYS$UTC_OFFSET/gbl
> >ntp -s
> NTPDATE - Clock error is 44 secs.
> NTPDATE - Tick delta: 2632
> NTPDATE - Error is 2632. Clock synced to Thu Sep 09 03:05:45 2021
> >tim
> 03:05:47 9-SEP-2021
>
> So that looks about 18 hours short of giving me the correct local time.
> Am I missing something?

What version of NTP is it? The latest version is 1.6, and the fix in
that version was about an error if you had large offsets to UTC, which
sounds exactly like the problem you are having.

> I'm finding that the FTP Server is timing out on me and shutting down
> the connection while I fumble around. Is there a way to change the time
> out value?

Hmm. Actually not. But that's a good point. Maybe something I should
add. I might do that this weekend. Probably would be another logical name.

> Thanks for your help with this. It feels weird to be typing command
> lines again. Weird but much better and quicker than a GUI interface,
> particularly as the muscle memory comes back. It's slightly complicated
> as I am also bringing an AlphaServer DS10 back to life and that's a
> (slightly) different set of muscle memories.

It just gets more fun every minute.

Oh, and by the way. I would suggest you install RPM, and then install
TTCPIP, which is the development version, so you get all the new stuff
immediately. (With the caveat that I could accidentally break things...)

Johnny

>
> All the  best,
> Adrian
>
>

> <http://mim.update.uu.se/tcpip.htm>.

>
> Madame is just an alias for Mim. :-)
>
> ftp://mim.update.uu.se/bqtcp.dsk

> <ftp://mim.update.uu.se/bqtcp.dsk>, or bqtcp.tap (if you are

> <https://groups.google.com/d/msgid/pidp-11/9cb0bb04-81ed-4eb0-83bc-1b97005defe5n%40googlegroups.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/pidp-11/9cb0bb04-81ed-4eb0-83bc-1b97005defe5n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: b...@softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/78ff11fe-9620-4680-8316-45dfdf0a1d52n%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/78ff11fe-9620-4680-8316-45dfdf0a1d52n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Johnny Billquist]

On 2021-09-09 11:38, Johnny Billquist wrote:
> Hi, Adrian.
>
> On 2021-09-09 11:30, Adrian Lumsden wrote:
>> I'm finding that the FTP Server is timing out on me and shutting down
>> the connection while I fumble around. Is there a way to change the
>> time out value?
>
> Hmm. Actually not. But that's a good point. Maybe something I should
> add. I might do that this weekend. Probably would be another logical name.

And I felt a little bored, so I already did it. There is now a logical
name FTPD$TIMEOUT which is the timeout to use in seconds. If set to 0,
no timeout is used.
This requires version 1.31 of FTPD, which is installed as FTP$$$.

[Adrian Lumsden]

Kia ora Johnny,

I'm taking up your suggestion of installing RPM. I'm trying to FTP RPM.PKG across to the P1DP-11 system. I'm using the Windows command line FTP because of what seemed like timeout problems with WinSCP when it tries to automatically download a directory listing when it logs in and it never completes. The Windows FTP client gives me this:

ftp> open localhost 2121

Connected to Aorus.

220-=============================================================

220-Welcome.

220-

220-This is a running RSX-11M-PLUS system.

220-=============================================================

220 Welcome

530 Please login with USER and PASS.

User (Aorus:(none)): System

331 Please specify the password.

Password:

230-Logged in to system.

230 Login successful.

ftp> bin

200 Switching to binary mode.

ftp> send rpm.pkg

200 Port command successful. Consider using PASV.

425 Failed to establish data channel.

ftp> close

221-Thank you for using this ftp service.

 Data traffic was 0.00 bytes in 0 files.

 Total traffic was 0.00 bytes in 0 transfers.

221 Closing connection.

ftp> quit

There aren't any errors logged in IP$log:error.log. Well, there are but they are all old ones ;-) Nothing from what I'm doing.

Can I download a disc image with your latest BQTCP on it and then I can just mount that and update from there. Does it also have RPM on it?

Thanks again.

All the best,

Adrian

[Johnny Billquist]

Hi, Adrian.

Well, how about you read http://mim.update.uu.se/rpm.htm ?

I know I (intentionally) created some confusion with the name RPM. This
RPM have nothing to do with the Linux Redhat Package Manager, but is
instead the RSX Package Manager.

Start with the instructions on how you bootstrap RPM itself, then
hopefully the rest shouldn't be too hard either. But feel free to ask
questions as needed.

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/50a5fe21-e6e3-4c06-9eaa-29fe38d2f1dcn%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/50a5fe21-e6e3-4c06-9eaa-29fe38d2f1dcn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Johnny Billquist]

Oh. I realized I had more direct questions I could comment on here.

First of all, don't try to ftp to Windows. The RPM packages are files
that won't survive going through non-RSX systems.

Second, the failure of the ftp failing to get the transfer working is
possibly because you seem to be trying to run ftp to the host system.
Since the second connection required for the data transfer usually
happens on a well known port as well, this might very well not work
across to the simh instance. Try passive mode, as suggested, to see if
that won't work better. (This is a rather complicated situation, for
which there might be multiple possible reasons for failing, and even
explaining it is non-trivial.)

But you really need to do the ftp directly from Mim to your RSX system.

Johnny

On 2021-09-10 00:30, Adrian Lumsden wrote:

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/50a5fe21-e6e3-4c06-9eaa-29fe38d2f1dcn%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/50a5fe21-e6e3-4c06-9eaa-29fe38d2f1dcn%40googlegroups.com?utm_medium=email&utm_source=footer>.