I think Paul cannot get these files loaded on his Tops20 V4.1 system from hecnet, being barred by lacking decnet and/or Kermit functionality.
In the end (!) the tape recipe works as follows:
Get a FRESH copy of tape BB-D867E-BM_TOPS20_V41_2020_INSTL.TAP-1 (after unzip) from Pdp10 archive into a host directory.
In simh when the monitor Tops20 V4.1 has been fired up or before:
ATT ?F TU0 SIMH G:\TEMP\BB-D867E-BM_TOPS20_V41_2020_INSTL.TAP-1 or your favorite location
Then in Tops20:
ENA CAP
R OPR
SET TAPE MTA0: UNAV This may already have been set
^Z
EXIT
Then in command prompt:
REWIND MTA0: to be safe
SKIP MTA0: 7 FILES files is necessary else you get some special problems! This bypasses the initial files on the tape
R DUMPR
TAPE MTA0:
PRINT TTY: gives you the contents of the savesets
EXIT
With modified former commands (RESTORE) in DUMPR you can also retrieve the files necessary.
$rew mta0:
$skip mta0: 7 fILES
$r dumper
DUMPER>tape mta0:
DUMPER>print tty:
^L
DUMPER tape # 1, "SYSTEM files for TOPS-20 V4.1", Thursday, 7-Apr-83 1221
file last write size (pages) checksum
DDB for PS:<NEW-SYSTEM>
PS:<NEW-SYSTEM>2020-ARPA-MONMED.EXE.1 5-Apr-83 1928 321
PS:<NEW-SYSTEM>2020-ARPA-MONSML.EXE.1 5-Apr-83 1924 321
PS:<NEW-SYSTEM>2020-MONMED.EXE.1 5-Apr-83 1837 326
ETC.
Reindert
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Thomas DeBellis
Sent: Saturday, 25 December, 2021 04:11
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] SIMH TOPS-20 question
OK, that's done: you can look at the following on VENTI2: via anonymous FAL
T41SUB: => TOMMYT:<OINKY.T2041.NEW-SUBSYS> SYSTEM files for TOPS-20 V4.1, 7-Apr-83 1221
T41SYS: => TOMMYT:<OINKY.T2041.NEW-SYSTEM> SUBSYS files for TOPS-20 V4.1, 7-Apr-83 1223
T41UET: => TOMMYT:<OINKY.T2041.UETP-LIB> UETP files for TOPS-20 V4.1, 7-Apr-83 1226
So NFT does what you think it would, viz:
NFT>dirECTORY (OF REMOTE FILES) venti2::T41SUB:*.*.*
Access information for node VENTI2::/ACCOUNT:
User:
Password:
[Fork NFT opening DCN:VENTI2-FAL for reading, writing]
VENTI2::TOMMYT:<OINKY.T2041.NEW-SUBSYS>
ACTGEN.EXE.1;P424242 11 5632(36) 20-Dec-1982 11:52:47
ACTGEN.HLP.1;P424242 1 612(7) 11-Aug-1977 15:44:36
ACTSYM.UNV.1;P424242 20 10104(36) 15-Apr-1982 04:23:27
.
.
.
This is, of course, built into DCL for VMS and RSX. There are hooks for it in Tops-20, but they don't appear to have done it.
I also put a 'directory' of the tape in the top level anonymous directory so you can grab it, viz:
NFT>dir venti2::TOPS-20-4-1-INSTALLATION.TXT
[Fork NFT opening DCN:VENTI2-FAL for reading, writing]
VENTI2::TOMMYT:<OINKY>
TOPS-20-4-1-INSTALLATION.TXT.1 8 18538(7) 24-Dec-2021 21:49:35
The non-ARPA monitors appear to have DECnet (I.E., NODE% points to NSPSRV, not STG), so maybe you can find something useful. However, I did not see some expected DECnet utilities (like FAL and NFT), so I would assume there is a secondary installation tape for that.
This is some really old code; it appears to predate Multinet, or maybe the KS didn't have enough memory to handle both ARPA and DECnet. I'd have to find source someplace.
The UETP files are of interest to me for testing purposes.
On 12/24/21 8:29 PM, Paul Koning wrote:
Ok, thanks.
As you may notice, I'm really rather ignorant about TOPS-20. I've never used it before, and only just barely touched it in recent weeks.
paul
On Dec 24, 2021, at 6:21 PM, Thomas DeBellis <tommytimesharing at gmail.com <mailto:tommytimesharing at gmail.com> > wrote:
Let me know how you make out with that. If worse comes to worst, let me know and I will grab the tape, restore the files and give you an ANONYMOUS FAL pointer to grab them.
On 12/24/21 5:48 PM, Thomas DeBellis wrote:
That would only work for a Tops-20 labeled or ANSI labeled tape.
You want to run DUMPER, then
tape mt0:
rewind
print tty:
The tapes are not in TPC format, they are in TPS format (if the extention is .TAP, .TPS or TPE)
On 12/24/21 4:46 PM, Paul Koning wrote:
On Dec 24, 2021, at 3:17 PM, Peter Lothberg <mailto:roll at stupi.com> <roll at stupi.com> wrote:
Take MRC's "Panda distribution" if you just want
it up and runnning. I'ts somwhere on trailing edge..
-P
What I'm trying to do is fill out the missing bits of the TOPS-20 4.1 DECnet Phase II system I have. I think tape image BB-D867E-BM.tap is the relevant kit.
When I attached it in TPC format I get some messages that look scary but perhaps they are just confusing. I don't know how to ask TOPS-20 what it sees on the tape, though. "dir mt0:" complains that someone else owns the tape.
paul
I want to do some more installing of TOPS-20 bits for DECnet testing. The needed tape images seem to be all there on Bitsavers, but they aren't in a format I recognize. SIMH doesn't seem to like them at all.
Any ideas?
paul
It is Trailing-Edge - PDP-10 Archives - BB-D867E-BM in .gz format
Reindert
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Thomas DeBellis
Sent: Saturday, 25 December, 2021 02:19
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] SIMH TOPS-20 question --> combined tapeset
Hum... Intriguing. Let me grab it and mess around with it. I actually do regular Tops-20 backups and have fixed a number of issues with dumper, so maybe I'll crack it.
On 12/24/21 8:09 PM, R. Voorhorst wrote:
> Thomas,
>
> No, he isn't doing bare metal restore but you cannot get this boot tape directly in dumper because the initial files are blocking the savesets.
> He only wants to retrieve some files in the savesets.
>
> I tried to skip files from the rewind state to the point just beyond dumper as some images of this tape give bad exe errors in 4.1, but I fail to pinpoint the start of the savesets.
> At the spot of dumper, the tape gives ?bad .exe file format and skipping files beyond does not work either, the tape looks damaged?
> Also restoring to a new initialized disk from mtboot itself does not work either at the moment as dumper cannot be started from the tape.
> To be continued.
>
> Reindert
>
> -----Original Message-----
> From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
> Behalf Of Thomas DeBellis
> Sent: Saturday, 25 December, 2021 01:22
> To: hecnet at Update.UU.SE
> Subject: Re: [HECnet] SIMH TOPS-20 question --> combined tapeset
>
> simh format would be known as TPS format to KLH10, internally as "Wilson & Supnik" format. This is what klh10 claims to use by default.
>
> The below is a standard build tape that you boot from, which we always thought was kind of neat.
>
> I missed that he was building from bare metal.
>
> On 12/24/21 7:03 PM, R. Voorhorst wrote:
>> Paul,
>>
>> The tape is simh format
>> Instead of booting the disk you must boot the tape in simh format and
>> the MTBOOT prompt will appear.
>> From there onwards, look at the Tops20 V4.1 installation manual in bitsaver.
>>
>> Swbx04> att -f tu0 simh
>> F:\Shares\Distribution\Pdp_10\Media\Tops-20\BB-D867E-BM.tap
>> Swbx04> b tu0
>> MTBOOT>
>>
>> Tape format for V7tape for instance:
>> ; Tape directory for V7.0 TOPS-20 installation tape
>> ; Bytes: 22519060, Records: 8704, Files(EOF marks): 7
>> TF-Format: raw
>> 0: 2560*597 EOF ; MONITR.EXE
>> 1528320: 2560*125 EOF ; EXEC.EXE
>> 1848320: 2560*8 EOF ; DLUSER.EXE
>> 1868800: 1270 EOF ; DLUSER data
>> 1870070: 2560*36 EOF ; DUMPER.EXE
>> 1962230: 2590*7937 EOF ; DUMPER savesets for <SYSTEM>, etc.
>> 22519060: EOF
>> EOT:
>>
>> This tape follows about the same pattern
>>
>> Reindert
>>
>> -----Original Message-----
>> From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
>> Behalf Of Paul Koning
>> Sent: Friday, 24 December, 2021 22:46
>> To: hecnet at update.uu.se
>> Subject: Re: [HECnet] SIMH TOPS-20 question
>>
>>
>>
>>> On Dec 24, 2021, at 3:17 PM, Peter Lothberg <roll at stupi.com> wrote:
>>>
>>> Take MRC's "Panda distribution" if you just want it up and runnning.
>>> I'ts somwhere on trailing edge..
>>>
>>> -P
>> What I'm trying to do is fill out the missing bits of the TOPS-20 4.1
>> DECnet Phase II system I have. I think tape image BB-D867E-BM.tap is
>> the relevant kit.
>>
>> When I attached it in TPC format I get some messages that look scary
>> but perhaps they are just confusing. I don't know how to ask TOPS-20
>> what it sees on the tape, though. "dir mt0:" complains that someone
>> else owns the tape.
>>
>> paul
>>
>>
Paul,
The tape is simh format
Instead of booting the disk you must boot the tape in simh format and the
MTBOOT prompt will appear.
>From there onwards, look at the Tops20 V4.1 installation manual in bitsaver.
Swbx04> att -f tu0 simh
F:\Shares\Distribution\Pdp_10\Media\Tops-20\BB-D867E-BM.tap
Swbx04> b tu0
MTBOOT>
Tape format for V7tape for instance:
; Tape directory for V7.0 TOPS-20 installation tape
; Bytes: 22519060, Records: 8704, Files(EOF marks): 7
TF-Format: raw
0: 2560*597 EOF ; MONITR.EXE
1528320: 2560*125 EOF ; EXEC.EXE
1848320: 2560*8 EOF ; DLUSER.EXE
1868800: 1270 EOF ; DLUSER data
1870070: 2560*36 EOF ; DUMPER.EXE
1962230: 2590*7937 EOF ; DUMPER savesets for <SYSTEM>, etc.
22519060: EOF
EOT:
This tape follows about the same pattern
Reindert
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf
Of Paul Koning
Sent: Friday, 24 December, 2021 22:46
To: hecnet at update.uu.se
Subject: Re: [HECnet] SIMH TOPS-20 question
> On Dec 24, 2021, at 3:17 PM, Peter Lothberg <roll at stupi.com> wrote:
>
> Take MRC's "Panda distribution" if you just want it up and runnning.
> I'ts somwhere on trailing edge..
>
> -P
What I'm trying to do is fill out the missing bits of the TOPS-20 4.1 DECnet
Phase II system I have. I think tape image BB-D867E-BM.tap is the relevant
kit.
When I attached it in TPC format I get some messages that look scary but
perhaps they are just confusing. I don't know how to ask TOPS-20 what it
sees on the tape, though. "dir mt0:" complains that someone else owns the
tape.
paul
L.S.
This is the follow-up from the Dup-without-Kdp in character mode discussion
somewhat earlier, where I stated it was not supported per the specifications
in Simh comments and Mark P had some comments about that it was supported.
During a moment of spare time, I reactivated a triple node Rsx-11M+ test
set, used for specific Decnet testing for Phase-I to IV. These triple nodes
were setup for using every possible device for Decnet communications,
amongst them the native (non-kdp) Dup. This one in multipoint mode is
character based and is driven through a Rsx Ddcmp software driver to
participate in Decnet communications.
If Simh Dup simulation is supported in native character mode, this would
establish sufficient proof for a well-functioning character based
synchronous line.
When the Dup line is interfaced to a Dmc line, the test reveals flapping
line behaviour: line up - circuit fault - line down; when trying to
transfer data an immediate circuit fault appears.
When the Dup is interfaced to another Dup, there is packet exchange so
basically it should be able to work. However, although there are no problems
with the lower length (8) signaling packets, the moment 22 char packets are
transferred, the receiver complains about bad header as well as bad data crc
checksums, so the packets are somewhat mangled. It prohibits to start
Decnet communications.
It looks like this in the snippet below:
DBG(10561953465)> DUP RCV: Line:0 0000 81 0C C0 00 01 01 1D DF 01 28 04 01
40 02 02 00 .........(.. at ...
DBG(10561953465)> DUP RCV: Line:0 0010 00 0F 00 00 1D 46
.....F
DBG(10561953465)> DUP RCV: rxnexttime=10561870955 (-20000 usecs)
DBG(10561953465)> DUP PKT: Line0: <<< RCV Packet len: 22
DBG(10561953465)> DUP PKT: Data Message, Count: 12, Num: 1, Flags: SQ, Resp:
0, HDRCRC: BAD, DATACRC: BAD
DBG(10561955696)> DUP PKT: Line0: >>> XMT Packet len: 8
DBG(10561955696)> DUP PKT: Control: Type: 2 (NAK) Reason: 1 (HCRC), Flags:
SQ, Resp: 0
DBG(10561955696)> DUP XMT: Line:0 0000 05 02 C1 00 00 01 85 A9
........
DBG(10561955696)> DUP XMT: rxnexttime=10561953465 (-541 usecs)
DBG(10561955696)> DUP PKT: dup_svc(dup=0) - 8 byte packet transmission
complete
Per Mark P's comment that some kind of filtering takes place in non-kdp dup
mode, that might indicate that the source of the problems could be located
in that corner.
That behaviour needs to be examined.
So it looks that basically character mode Dup is (was meant to be)
supported, but that it needs to be tuned; this functional mode was probably
not tested in the past as the accent was on Ddcmp processing within Simh
for Dmc/Dmr and Kdp/Dup device setups.
Reindert
Hi Paul,
How was this tested: 11M+ to 11M+ or 11M+ to PyDecnet?
Reindert
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf
Of Paul Koning
Sent: Thursday, 23 December, 2021 02:36
To: hecnet at update.uu.se
Subject: Re: [HECnet] native Dup sync line revisited --> preliminary tests
reveals problems
> On Dec 13, 2021, at 9:15 AM, Paul Koning <paulkoning at comcast.net> wrote:
>
> ...
> So if the plain sync device emulation were to do the above, that would
give us an emulation that interoperates with the DMC emulation if the
software controlling the device is running DDCMP.
More on this...
I built an M+ system with DUP lines, and unlike what was reported in this
thread, I did NOT see problems talking to other things (like PyDECnet or DMC
emulation) that expect plain data without frame length fields. I don't see
frame lengths in the trace.
I don't understand this because the code is clearly there in the emulator,
so apparently it's not being hit. Not by DECnet/RSX anyway. More to be
studied.
paul
?Supratim,
Thanks for your comments on the HECnet mail-list. Also, I enjoyed reading about
your work modifying the Frodo distribution for a dual ethernet 11/93. Nice work!
I?ve been planning to update the Frodo distribution to update some of the layered product software (BasicPlus2, Datatrieve and APL to use I/D space) and the latest TCP/IP including the new updates to the TYDRV that require a SYSGEN to rebuild.
BestRegards,
Mark
> On Dec 22, 2021, at 2:50 PM, Supratim Sanyal <supratim at riseup.net> wrote:
> ?
> Sorry - Mark already responded.
>
> There is interesting history behind "FRODO" too ...
>
> On 12/22/21 1:35 PM, Mark Matlock wrote:
>
>> Paul,
>> You could also download ftp://ftp.trailing-edge.com/pub//rsx_dists/rsx11mpbl87.dsk.bz2 which is
>> a baseline RSX11M+ V4.6 disk image ready for a SYSGEN from [200,200] It also has DECnet V4.6 already in [137,10] for a NETgen. This DECnet distribution only generates endnotes however and you may want to get an
>> area routing DECnet distribution from MIM.
>>
>> Also a RSX11M+ V4.6 with DECnet (for Unibus systems) and a very old version of Johnny?s BQTCP/IP is available at:
>>
>> http://www.rsx11m.com/PiDP11_DU0.zip
>>
>> It has area routing DECnet running but you would really need to update the TCP/IP but you can FTP
>> that from Mim.update.uu.se and get Johnny?s latest version.
>>
>> Best,
>> Mark
>>
>>
>>
>>
>>> On Dec 22, 2021, at 12:14 PM, Paul Koning <paulkoning at comcast.net> wrote:
>>>
>>>
>>>
>>>> On Dec 22, 2021, at 1:07 PM, Johnny Billquist <bqt at softjar.se> wrote:
>>>>
>>>> Hi, Paul. Sorry I didn't answer earlier. Saw some other mails I should have responded too as well, but been a bit busy.
>>>>
>>>> Anyway. 4.0 is way old and have various issues you do not want or need. Locate M+ 4.6 instead. That's basically the only version I'd recommend.
>>>> And yes, M+ is definitely easier to deal with than 11M.
>>>>
>>>> You can find both tapes at http://bitsavers.org/bits/DEC/pdp11/magtapes/rsx11mplus/
>>>>
>>>> Basically you want BB-J0830-01.L01_RSX11M+_V4.6_BRU_1999.tap, which should be bootable, and contain all you need for M+ itself. There is a second tape (BB-J0830-01.M01_RSX11M+_V4.6_1999.tap), which might be the second tape if the whole thing came on two tapes. (I got M+ 4.6 on TK50, which just came on a single cartridge.)
>>>>
>>>> Then you want DECnet, which is decnet11mp46-netkit.tap. The manuals are online, but of course you can also just ask. And since you seem to have already managed once, it should hopefully not be too complicated.
>>> I used the DECnet 4.0 kit because I could not make sense out of that 4.6 kit. The installation procedure in the manual (DECnet/RSX 4.5, which says it's for M+ 4.3) doesn't work at all with that tape. It says to use FLX to copy PREGEN.CMD from the tape, but the tape isn't anything FLX understands. Instead, it seems to be an ANSI labeled tape with 3 files on it, the first one named "INSTALL". Is that a BRU tape? Or a DSC tape? What do I do with it?
>>>
>>> paul
> --
Are there any thoughts about adding file transfer capabilities to PyDECnet at some point in the future? If a pyDECnet node could implement a FAL server to share a directory and/or offer a way to copy files to/from other nodes over DECnet, that would be really cool. I think it could make a very nice option for moving files between DECnet nodes and modern systems without needing to wrestle with Linux DECnet drivers or install TCP/IP on the DECnet nodes. I don't know how hard it would be to implement, or if there's any way I could contribute.
I'm imagining a silly future in which there is a native Python implementation of an entire RSX-11 or VMS system. :)
While I'm here... is this mailing list disappearing soon due to the Update eviction? I plan to chip in for an Update membership for 2022.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
https://www.nf6x.net/
I'm trying to build a DECnet/RSX system, and since I've never done anything like that I figured I'd try M+ as (right?) the easiest option.
Did a sysgen, that seemed to work ok. Found a DECnet kit on Bitsavers, the 4.0 one marked "3errs", used that to do netgen. That too seemed ok.
Now I'm trying "netins". That fails mid-way and I have no clue why:
>@[5,1]netins
>* Do you want to install and load the CEX system? [Y/N]: y
>* Do you want to install and start DECnet? [Y/N]: n
>* On what device are the network tasks [D=DU0:] [S]:
>INS XX:[5,54]NTINIT
>INS XX:[5,54]NTL
>INS XX:[5,54]MLD
>INS XX:[5,54]EVC
>INS XX:[5,54]NCPRES
>; INS XX:[5,54]CFERES
>; INS XX:[5,54]VNP
>INS XX:[5,54]NMVACP
>SET /SYSUIC=[5,54]
>ASN XX:=LB:
>LOA NM:/HIGH/VEC
>CON ONL NM:
>ASN =LB:
>SET /SYSUIC=[2,54]
>INS XX:[5,54]LOO
>INS XX:[5,54]LOO/TASK=LOO...
>INS XX:[5,54]EVFRES
>SET /UIC=[5,54]
>NCP SET SYS
12:56:33 Task "NTL..." terminated
Odd address or other trap four
R0=000000
R1=000000
R2=000005
R3=000004
R4=151775
R5=157724
SP=120614
PC=160252
PS=170000
Any ideas?
paul
How do I setup the ethernet connection on Windows in order to enable
SimH/VAXVMS to communicate with the world?
I used:
Set xu enable
Set xu eth7 (my Wi-Fi connection)
This gives me:
sim> sho xu
XU address=2013F948-2013F94F, vector=50, BR5, MAC=08:00:2B:00:01:05
type=DELUA, throttle=disabled
attached to eth7
But VMS does not recognize UNA-0.
Groeten,
Rien Timmer